commandkit/docs/roadmap/implementation.md

Performance implementation plan

Status: ready for implementation; Stages 1–11 have not started.

Date: 2026-10-09.

Scope and authority

Implement PF-01 through PF-06 from the performance roadmap. Read this entire plan before starting and complete the numbered stages in order. Each stage is a separate Luna implementation assignment and must leave the repository buildable. The roadmap owns the target and selected OD-1/OD-2 approaches; this plan owns execution choices, sequencing, and implementation evidence.

Follow the architecture policy, accepted ADRs, agent policy, testing policy, and documentation policy. Public Go declarations and the CLI reference own existing contracts. Private names proposed below identify implementation responsibilities, not new public APIs or durable internal interfaces.

This file replaces the completed ReleaseKit plan. Release tooling is already implemented and is outside this sprint. Stage 11 repairs navigation that still identifies this file as the ReleaseKit plan. The previous record is available through Git history; do not restore its assignments here.

No required product or architecture questions remain open. Measurements assess the selected improvements; they do not authorize substituting persistent mutable backends or segmented YAML delivery for the user's choices.

Baseline and implementation choices

The planning baseline is 6612b54, with a clean worktree. Production code still matches the efficiency review at 54cfbd8; intervening changes are documentation. The root facade, internal Cobra adapter, inspection families, and release tooling are implemented. No performance benchmarks were found in the indexed code, and this planning pass has not executed tests, benchmarks, or profiles. Reinspect current state before implementation and record the actual measurement revisions.

Use the following concrete choices:

• Render PromptKit's requested format in its handler, then pass completed bytes to a shared delivery helper. Preserve the existing report DTOs and serializers.
• Index backend commands directly to neutral declarations. Walk Cobra's existing parent links inside the adapter to reconstruct only the selected path.
• Scan YAML opening lines with byte offsets. Return complete framed bytes plus whether the native document has directives, so the aggregate writer can use one analysis. Retain the full framed buffer selected in OD-2.
• Prepare and clone pending command registrations before updating the existing registry. Keep batch validation atomic and preserve owned declaration storage.
• Lazily cache one neutral bridge tree per App, invalidating it after a successful nonempty registration. Construct fresh mutable backend state for each invocation, then reuse it for parsing, help, and usage within that invocation, as selected in OD-1.
• Represent registered configuration metadata with a private generic prepared suite containing normalized declarations, ordered scopes, name lookup, and discovery inventory. Use name/short-name maps for selector duplicate checks. Keep scope selection in preflight and handlers as inexpensive indexed passes. Selected-scope memoization and additional selector-membership indexes are deferred; their mutable bookkeeping is unnecessary for removing the observed quadratic scope searches.

PF-05 and the bounded PF-06 changes above are included in the sprint despite their lower priority. Implement the straightforward algorithms and measure their cost; do not silently omit either coverage ID. Escalate concrete correctness conflicts or material regressions rather than add a new consumer restriction or change the selected scope.

Instructions for every stage

1. Start with developer orientation, inspect Git state, and read the assigned sources and prior stage evidence. Prefer knowledge-graph tools for code discovery. Preserve unrelated work and read applicable policies.
2. Implement the assigned stage and necessary supporting tests/documentation. Preserve public signatures and the fields of value structs such as Invocation, CommandSpec, and ConfigSuite; do not add execution state to them. The App handle may gain private implementation fields. Cobra/pflag objects and errors stay inside their adapter.
3. Preserve grammar, conversion of every supplied singleton occurrence, explicit presence, collection ownership, callback lifecycle, supported error identity, diagnostic delivery, and report semantics. Reuse existing coverage; add only missing protection for the change's realistic risks. Do not assert private helper counts or fixed timings in behavioral tests.
4. Format changed Go files. Run the stage's focused validation and measurements. Dependency preparation, if needed, is separate from offline measurement. Apply the measurement protocol's workspace, local-toolchain, and offline environment settings to Go validation commands as well. Tests and benchmarks added by this plan are development evidence, not new release gates. Leave the opt-in ReleaseKit publication exercise unselected.
5. Record actual commands, results, fixture dimensions, relevant comparisons, and unresolved issues in the stage's evidence field. Never replace pending evidence with an expected result. Investigate a regression before proceeding; absence of a timing speedup is not permission to invent a faster contract.
6. Review staged changes and commit each completed stage under the agent policy. Report its commit, checks, and remaining work. Proceed only when its completion conditions hold. Update the roadmap's overall status when implementation begins and ends; detailed execution results belong here.

No concurrency guarantee, public freeze step, new parser, provider cache, library version change, or release publication is needed. Application callbacks retain their effects. Do not forbid registration from callbacks to simplify caching; refresh metadata-dependent presentation when successful registration has made the invocation's prepared metadata stale, without repeating input callbacks.

Measurement protocol

Use standard Go benchmarks named with prefix BenchmarkPerformance. Use the same fixtures and measurement scope before and after a change. Record Go version, GOOS/GOARCH, CPU/machine description, source revision, and fixture dimensions. Separate app construction plus first execution from execution on an existing app. Exclude fixture construction from repeated-execution measurements and include it only when explicitly measuring construction/registration.

Use in-memory provider fixtures and io.Discard for ordinary delivery measurements. Observe outcomes so invalid fixtures cannot appear as fast success. Actual ConfigKit/PromptKit loading is covered by existing integration tests; these measurements isolate CommandKit overhead and do not contact providers. Keep a few representative shapes rather than a Cartesian product of dimensions.

With module caches prepared, the common measurement command is:

GOWORK=off GOTOOLCHAIN=local GOPROXY=off GONOPROXY=none GOSUMDB=off go test -mod=readonly -run '^$' -bench '^BenchmarkPerformance' -benchmem -benchtime=200ms -count=5 . ./internal/cobra

Narrow -bench and the package list for each stage. Save raw output outside the worktree and summarize representative ns/op, B/op, and allocs/op results here, including variation or inconclusive differences. When measurements span a different machine or Go version, repeat the baseline in an isolated checkout with the same benchmark sources before making a timing claim. Profile CPU or allocations only when needed to explain a remaining cost or regression. No new benchmark-analysis dependency or permanent numeric pass threshold is selected.

Stage inventory

Stage	Deliverable	Roadmap coverage
1	Dispatch and registration baseline benchmarks	PF-02, PF-03, PF-05
2	Inspection and scope baseline benchmarks	PF-01, PF-04, PF-06
3	PromptKit rendering for the selected format	PF-01
4	Direct declaration lookup and ancestry traversal	PF-02
5	YAML preamble analysis with complete framed delivery	PF-04, OD-2
6	Registration without copying existing entries	PF-05
7	Cached immutable bridge metadata	PF-03, OD-1
8	An invocation-owned adapter session	PF-03, OD-1
9	Root dispatch, help, and usage integration	PF-03, OD-1
10	Prepared configuration suite metadata	PF-06
11	Final behavioral/performance audit and documentation	PF-01–06

Stage 1: establish dispatch and registration measurements

Status: not started. Prerequisite: orientation and this plan.

Files: new performance_dispatch_test.go, internal/cobra/performance_test.go, and evidence here. Production code stays unchanged in this stage.

1. Create small test-only command fixtures: a small flat registry with 8 custom commands, a wide registry with 128 custom commands, and a nested path of depth 24 with sibling commands. Add one flag-heavy leaf case with 24 flags. These dimensions are benchmark inputs, not supported-size limits.
2. Add root benchmarks for repeated success, local --help, explicit help COMMAND, parser usage failure, and handler-returned usage. Use the small fixture for the full path set and the wider/deeper fixtures for success and help. Add construction plus first-execution cases for small and wide apps. Use real routing and bindings with a cheap typed handler and stable streams.
3. Add adapter Parse benchmarks for shallow/wide and deep neutral trees to isolate PF-02 from root report work. Keep the neutral declarations outside the timed region; include backend construction in the Parse measurement.
4. Add registration benchmarks comparing individual and batch registration of 8 and 128 preconstructed declarations. Include fresh New plus registration in both timed paths so the comparison has the same construction overhead.
5. Run and record the baseline under the measurement protocol. Preserve benchmark inputs for subsequent stages. Verify setup and expected outcome classes; fix the fixture if it unexpectedly measures an error path.

Validation: compile both packages with go test -mod=readonly -run '^$' . ./internal/cobra, then execute the new benchmarks. No timing assertions, production instrumentation, or full dependency test matrix is needed.

Completion: reproducible baseline results distinguish registration, cold execution, repeated execution, parsing, and help/usage costs.

Evidence: pending.

Stage 2: establish report and scope measurements

Status: not started. Prerequisite: Stage 1.

Files: new performance_reports_test.go and evidence here. Production code stays unchanged in this stage.

1. Use direct PromptKitSuite callbacks returning fixed inspection records. Measure prompt text/YAML with 4 and 128 inputs, and profile text/YAML with small and larger nested ExtraParams maps. Construct fixtures outside the timed loop; use App.Execute so parsing and delivery are represented.
2. Add isolated framing and aggregate config show --scope all benchmarks with two native document fixtures: approximately 4 KiB and 1 MiB with many short lines. Keep native content and provider callbacks fixed. Include an ordinary preamble and a directive-bearing preamble, without multiplying every size by every marker variation. Measure single-scope display as a reference case.
3. Measure config scopes, named selection, and aggregate validation with 2 and 32 scopes. Give every aggregate fixture the requested capability and use cheap acquisition callbacks. Add suite registration with 4 and 64 distinct selectors to expose duplicate-check cost without using duplicate declarations.
4. Run and record these baselines before handler or scope changes. Label isolated helper results separately from complete command execution. Adjust internal benchmark calls after later signature refactors only as necessary to measure the same logical operation and fixtures.

Validation: compile the root package and run the new report/scope benchmarks under the common protocol. Confirm the fixtures produce the intended formats and success outcomes outside timed setup; existing integration coverage remains the owner of actual library loading semantics.

Completion: PF-01, PF-04, and PF-06 have comparable baseline measurements.

Evidence: pending.

Stage 3: render only the selected PromptKit format

Status: not started. Prerequisite: Stage 2.

Files: promptkit.go, promptkit_test.go, relevant report benchmarks, and evidence here.

1. In runPromptKitPrompt and runPromptKitProfile, select YAML or text before calling either text formatter. Preserve report DTO construction and all acquisition, cancellation, nil-result, and diagnostic handling.
2. For YAML, encode into a bytes.Buffer and use its bytes directly. For text, format once and convert the completed string to bytes without copying it through an additional builder. Preserve profile text-formatting errors.
3. Reduce writePromptKitReport to shared delivery of completed bytes plus diagnostics. Keep the pre-delivery cancellation check, checked writer, and incomplete-report outcome handling. Both formats finish rendering before this delivery step. No lazy public formatter API is needed.
4. Reuse the real inspection tests for report fields, input order, nil parameter maps, nested ExtraParams, cancellation, and output failures. Add focused missing cases rather than collaborator-call assertions or broad snapshots.
5. Rerun prompt/profile measurements and compare them with Stage 2. Explain any text-path regression or unexpectedly unchanged YAML allocation result.

Validation: root PromptKit inspection and cancellation tests, followed by the applicable report benchmarks. Use go test -mod=readonly -count=1 . for root behavioral validation. Preserve public error identity and existing report confidentiality; this change introduces no redaction policy.

Completion: YAML requests do not construct text reports, and text delivery has no redundant intermediate builder.

Evidence: pending.

Stage 4: index backend declarations and traverse parents

Status: not started. Prerequisite: Stage 3.

Files: adapter, adapter tests, relevant benchmarks, and evidence here.

1. Change the construction index to map backend command pointers directly to neutral declarations. Update Parse, RenderHelp, and UsageLine to use direct lookup instead of scanning declaration-to-backend entries.
2. Reconstruct a selected path by walking the backend's Parent() links and reading each mapped declaration's name, excluding the root. Reverse the collected names once. Remove recursive root-based parent discovery.
3. Keep neutral failures for missing trees/unmapped selections and exact-path verification. Do not rely on Cobra prefix matching to define accepted paths.
4. Extend adapter coverage only where needed for a deep path, wide siblings, unknown paths, root selection, and help/usage path resolution. Existing parsing and flag-state tests remain applicable.
5. Compare adapter and complete dispatch benchmarks with Stage 1. The tree still rebuilds here; distinguish reduced path-search cost from that remaining cost.

Validation: go test -mod=readonly -count=1 ./internal/cobra ., then the applicable parse and dispatch benchmarks.

Completion: declaration lookup uses the index and ancestry traversal is proportional to selected depth after backend construction.

Evidence: pending.

Stage 5: scan YAML preambles without splitting documents

Status: not started. Prerequisite: Stage 4.

Files: show.go, show_test.go, configkit_test.go, framing benchmarks, and evidence.

1. Introduce a private preamble analysis using bytes.IndexByte to locate line boundaries and byte trimming for classification. Track marker positions, preamble end, directives, and inline marker content. Stop when the opening framing decision is complete. Preserve Unicode whitespace behavior and accepted space/tab marker forms; do not add a general YAML parser or limits.
2. Have frameEffectiveYAML return complete framed bytes and a directive flag from that analysis. Update its internal callers/tests for the result pair. Remove the independent full-document split in hasYAMLDirective and use the same analysis for aggregate completion-marker decisions.
3. Retain the complete native buffer and framed buffer per document. Preserve placement of labels around inline content/block scalars, authored comments, directives, native byte slices, quoted scope labels, and boundary newlines. Keep the existing aggregate document-end marker where directives require it.
4. Leave acquisition-before-output, direct single-scope writing, cancellation boundaries, and write-error outcomes intact. Do not introduce segmented native delivery, indentation wrappers, or reserialization of provider documents.
5. Reuse TestEffectiveYAMLFramingPreservesOneNativeDocument and aggregate acquisition/delivery tests. Fill meaningful gaps for absent trailing newline, CRLF, directive preambles, and control characters in labels. Verify native content preservation as well as decoded values and document count.
6. Compare framing/aggregate measurements with Stage 2, emphasizing allocation growth with line count. Report the full framed copy as an intentional retained cost under OD-2.

Validation: root framing/configuration behavior with go test -mod=readonly -count=1 ., then the relevant report benchmarks.

Completion: each document has one opening analysis, no document-wide line index, and the selected complete-buffer delivery model.

Evidence: pending.

Stage 6: install validated registrations without copying the registry

Status: not started. Prerequisite: Stage 5.

Files: registry.go, registry_test.go, registration benchmarks, and evidence.

1. Preserve the nil-app check. Validate each declaration and check its name against both existing registrations and pending entries. Clone declarations into private pending storage before modifying the app.
2. After the whole batch succeeds, initialize the app's map if needed and add the pending entries to it. Leave existing entries untouched. An empty batch remains a successful no-op on a non-nil app.
3. Preserve batch failure behavior for invalid later declarations, duplicates within a batch, existing paths, and reserved help/version paths. Keep existing cloning boundaries rather than sharing caller-owned child slices.
4. Reuse atomicity and callback-free registration tests. Add a missing late-failure or within-batch collision case only if existing coverage is insufficient.
5. Compare individual/batch registration with Stage 1. Sorting and metadata preparation remain separate until Stage 7.

Validation: registry/declaration behavior with go test -mod=readonly -count=1 ., then registration benchmarks.

Completion: registration copies only pending declarations and preserves all-or-nothing validation without rebuilding the existing registry map.

Evidence: pending.

Stage 7: cache immutable bridge metadata per app

Status: not started. Prerequisite: Stage 6.

Files: app.go, parser.go, registry invalidation, root parser/registry tests, dispatch benchmarks, and evidence.

1. Add a private cached neutral tree pointer to App. Split bridge translation into a cache accessor and an uncached builder. Build lazily on first use; sort root names and child lists once per registry state while creating owned flag/operand metadata. The cached neutral tree is read-only thereafter.
2. Invalidate the pointer at successful nonempty registration's completion point. Failed and empty registrations retain valid cached metadata. Built-in construction remains before first use; do not create metadata eagerly for each individual command registration.
3. Keep this cache free of contexts, streams, parsed values, provider views, and Cobra/pflag objects. Adapter construction reads the neutral tree without mutating it. A pointer to the neutral tree identifies a prepared metadata generation for Stage 9, avoiding a separate counter.
4. Protect observable behavior after success, failure, and empty registration following earlier execution/help. Check that newly installed configuration and PromptKit families appear after an earlier help request without provider loading. Preserve owned declarations and sorted metadata.
5. Compare cold and repeated execution with Stage 1. Account for the one retained neutral tree per app and confirm rebuilding occurs only when needed through source review and measurements, not public allocation/count assertions.

Validation: root registry/parser/help tests and dispatch benchmarks. Each invocation still creates fresh backend values at this stage. Use go test -mod=readonly -count=1 . for root behavioral validation.

Completion: unchanged registrations reuse translated metadata; successful registration is visible to later parsing and help.

Evidence: pending.

Stage 8: introduce an invocation-owned adapter session

Status: not started. Prerequisite: Stage 7.

Files: the adapter, its tests/benchmarks, and evidence. Root execution remains functional through the existing package-level adapter helpers during this stage.

1. Add an internal Session handle with private backend root, neutral metadata, and reverse declaration index. Use Prepare(*Command, ParseOptions) *Session; construction normalizes options and builds a fresh mutable tree. A missing tree is represented by a session whose operations return neutral failures. Methods are Parse([]string) Result, RenderHelp([]string) (string, *Failure), and UsageLine([]string) (string, *Failure). They expose no backend types.
2. Move existing parse/help/usage logic into those methods. Reuse the prepared tree and Stage 4's index/path traversal. Help renders to a private buffer; temporarily redirect and restore the selected backend's output/error streams so generated bytes remain under root delivery control.
3. Keep package-level helpers as thin one-session conveniences for current root calls and focused adapter benchmarks/tests. They must delegate to the same methods, not maintain parallel parsing or help implementations.
4. Keep malformed/nil-tree results neutral. Metadata remains read-only; parsed values belong to the session. Test parse followed by help and usage on one session, and fresh values/streams on separately prepared sessions. Do not add a public session API, pool, persistent backend cache, or reset framework.
5. Add a small parse-plus-help session benchmark using an existing fixture. Label it as a new internal measurement; existing end-to-end benchmarks are still the before/after evidence for root integration in Stage 9.

Validation: go test -mod=readonly -count=1 ./internal/cobra ., then adapter benchmarks.

Completion: the adapter can perform parsing and metadata presentation on one prepared invocation tree while legacy root entry points still compile.

Evidence: pending.

Stage 9: reuse the adapter session throughout root execution

Status: not started. Prerequisite: Stage 8.

Files: execute.go, builtins.go, private parser coordination, execute_external_test.go, dispatch benchmarks, and evidence.

1. Introduce private execution coordination local to App.Execute, retaining the app, parse options, neutral tree pointer, and session. Prepare after the existing context/stream checks. Keep early nil-app/context outcomes and generic usage fallbacks functional without a usable session.
2. Route parse, root/group/local help, usage after parse/input failures, and usage returned by handlers through that local coordination. Keep the existing input preparation and callback order, including supplied-value validation for help. Normal domain handlers still receive the public Invocation.
3. Handle the reserved top-level help command explicitly in the dispatcher after its ordinary typed preparation/checks: use its private helpInput, resolve the target with helpCommandTarget, and render through the local session. Share target/render logic with its registered built-in handler. A one-off private convenience may prepare a session for direct internal helper calls; the Execute path must use its existing session. Preserve runnable help metadata and the semantics of help --help and unknown targets.
4. Do not store the active session on App, add it to public Invocation, or put it in caller contexts. For help/usage presentation, compare the current cached metadata pointer with the session's pointer. If successful registration by a callback changed metadata, prepare presentation against the new tree without rerunning parsing, factories, checks, or handlers. This preserves registration freedom without caching stale presentation.
5. Preserve outcome normalization, cause/error identity, diagnostic ownership, delivery errors, and incomplete-report reporting. Remove obsolete duplicate preparation paths once all root execution branches are integrated.
6. Reuse the existing help-entry and fresh-invocation tests. Fill gaps for a successful flag-bearing invocation followed by help and omitted/false/empty values, distinct streams/contexts, handler usage, and registration followed by metadata presentation. Test contracts, not exact session-construction counts.
7. Compare complete help/error/repeated/cold execution with Stage 1. Stable metadata should need one backend preparation through each ordinary invocation, including explicit help; verify structurally and through measurements.

Validation: root dispatcher/help/outcome/cancellation tests, adapter tests, with go test -mod=readonly -count=1 . ./internal/cobra, then complete dispatch benchmarks. Use existing facade boundary coverage/review to confirm that signatures and backend isolation are unchanged.

Completion: every normal Execute path uses the selected OD-1 lifecycle and all existing public handler and presentation semantics remain intact.

Evidence: pending.

Stage 10: prepare configuration scope metadata once

Status: not started. Prerequisite: Stage 9.

Files: config.go, selectors.go, configuration handler files, configuration/cancellation tests, scope benchmarks, and evidence. Keep public ConfigSuite/ConfigScope unchanged.

1. Introduce private preparedConfigSuite[C] with the normalized public suite, ordered scope slice, map[string]ConfigScope[C] lookup, and discovery DTO. Prepare it once in RegisterConfig after normalization. Use the existing ordering comparator: app, promptkit, then other identifiers alphabetically. Normalize/copy metadata before preparation so it remains instance-owned.
2. Replace the previous-selector loop in normalizeConfigSuite with seen-name and seen-short maps, retaining validation order, scope-reference deduplication, and the same collision categories. Preserve all existing naming rules.
3. Pass the private prepared suite into standard command constructors and preflight/run helpers. Use its ordered slice for aggregate selection and its map for named lookup, capability preflight, and acquisition. Update validate/show/sources/explain together; no public integration signature changes.
4. Construct the discovery inventory from declared/installed operations during registration and retain the private DTO. Encode text/YAML at invocation time. This preparation must not call NewContext, acquisition, input checking, native writers, or other runtime callbacks.
5. Keep selection validation in preflight and handlers, now using prepared metadata. Keep selector applicability scans and fresh context projection. Do not add mutable selected-scope memoization or public/internal input hooks solely to avoid a second inexpensive validation pass.
6. Reuse discovery ordering/capability, selector projection/requiredness, unknown scope, provider-error, and cancellation coverage. Ensure aggregate operations check every selected capability before acquisition; discovery remains metadata-only. Add only missing post-registration ownership/collision cases.
7. Compare scope execution and suite registration with Stage 2, including the normal two-scope case. Record the retained slice/map/DTO cost and any timing tradeoff; extra metadata is private to the registered suite.

Validation: root configuration and cancellation tests plus scope/selector benchmarks. Use go test -mod=readonly -count=1 . for root behavioral validation. Preserve native reporting and per-operation output timing.

Completion: scope sorting/discovery preparation occurs at registration, scope lookup is indexed, and duplicate selector checks are linear in selector count plus declared scope references.

Evidence: pending.

Stage 11: audit the completed target and reconcile documentation

Status: not started. Prerequisite: Stages 1–10.

Files: this plan, performance.md, internal overview, developer/README navigation, and stale references to the retired ReleaseKit plan. Focused corrections only where the audit proves an incomplete target.

1. Audit PF-01–06 against source and observed behavior: selected formatting, indexed ancestry, prefix-only YAML analysis, full framed buffering, pending registrations, immutable cache invalidation, invocation sessions across all help/usage paths, and prepared configuration metadata. Identify authoritative evidence for each target rather than infer completion from stage statuses.

2. Run the default suite once for the complete sprint:

   GOWORK=off GOTOOLCHAIN=local GOPROXY=off GONOPROXY=none GOSUMDB=off go test -mod=readonly -count=1 ./...
   

   Keep live services, the optional release publication exercise, and additional race/platform/coverage gates unselected. Review production imports and exported declarations using existing boundary checks and source evidence.

3. Rerun representative benchmarks with unchanged fixtures and comparable environment. Summarize before/after data by PF ID, separate cold/repeated and isolated/whole-command costs, and record remaining full-tree/full-buffer work. Reuse a recent identical measurement when source and environment are unchanged. Explain material regressions or collect more evidence before declaring success.

4. Update internal documentation to describe implemented cache/session ownership and prepared metadata. Current CLI/GoDoc contracts should remain unchanged; update them only for an actual clarification without inventing a new promise.

5. Update README and docs/development.md so current implementation navigation points to this performance plan and roadmap. In releasekit.md, initial.md, and remediation.md, remove or replace obsolete ReleaseKit-plan references with the owning completed roadmap/runbook as appropriate. Remove its obsolete final-stage fragment references. Do not preserve the retired stage assignments or restart completed release work.

6. Check affected document links/fragments, prose status, and whitespace. Mark the roadmap implemented only when every selected target has evidence. Record the stage commits, measurement revisions, check results, and any qualifications here, then commit the audit and leave a clean workspace.

Validation: the default suite, comparative measurements, facade/import review, and affected documentation/link checks described above. Reuse unchanged stage evidence where it directly proves the final target.

Completion: all six target improvements and both selected approaches are implemented with relevant behavioral and efficiency evidence; maintained docs identify their current owners. No performance guarantee or additional release gate has been introduced.

Evidence: pending.