Plan the ConfigKit and PromptKit upgrade implementation
This commit is contained in:
387
docs/roadmap/implementation.md
Normal file
387
docs/roadmap/implementation.md
Normal file
@@ -0,0 +1,387 @@
|
||||
# ConfigKit And PromptKit Upgrade Implementation Plan
|
||||
|
||||
## Purpose And Scope
|
||||
|
||||
Implement [ConfigKit And PromptKit Upgrades](upgrade-kit.md). That document
|
||||
owns the desired behavior and operator migration; this document owns execution
|
||||
order. Each numbered stage is one bounded implementation prompt for a
|
||||
gpt-5.6-terra coding agent. Complete and validate stages in order.
|
||||
|
||||
The inspected baseline pins ConfigKit v0.3.0 and PromptKit v0.10.0. Adopt
|
||||
exactly ConfigKit v0.4.0 and PromptKit v0.11.0, not whatever release happens to
|
||||
be newest during implementation. The release guides and public APIs are
|
||||
available in the sibling checkouts `../ConfigKit` and `../promptkit`; consult
|
||||
the target tags or downloaded modules if those checkouts have advanced.
|
||||
Build and test Notarius with `GOWORK=off`, without local dependency replacements.
|
||||
|
||||
Read `docs/development.md` and all five policies in `docs/policy/` before
|
||||
implementation. In particular, simplify machinery without narrowing operator
|
||||
choices or elevating incidental details into requirements. Preserve existing
|
||||
contracts unless this roadmap expressly changes them. Use graph discovery for
|
||||
code, then inspect the relevant source and tests; locations below identify the
|
||||
reviewed baseline, not a requirement to preserve private file structure.
|
||||
|
||||
## Decisions And Boundaries
|
||||
|
||||
- Configuration selection becomes `--config-overlay` and `overlays/<name>.yml`,
|
||||
with no legacy alias or fallback. Keep empty, omitted, and `default` selection
|
||||
behavior. Do not rename PromptKit profiles or pipeline/runtime profile types.
|
||||
- Keep configuration version 5, source-file-relative declarations, CLI override
|
||||
precedence, strict loading, inspection provenance, and redaction.
|
||||
- Add only the global `promptkit.transient_retries` setting: nonnegative integer,
|
||||
default **2 additional attempts**, explicit zero disables. No arbitrary cap,
|
||||
per-binding setting, new CLI retry flag, or new total-deadline setting.
|
||||
- PromptKit owns transient HTTP retries and structural repairs; Notarius keeps
|
||||
stage/validator retry budgets and disposition unchanged. The existing shared
|
||||
scheduler retains its completion-scoped permit through upstream waiting.
|
||||
- Add provider-neutral failure metadata and request-local execution summaries.
|
||||
Do not change domain artifacts, result receipts, prompt content, validators,
|
||||
acceptance policy, or introduce a new telemetry service/artifact.
|
||||
- Successful retry recovery is ordinary success, not a warning. Debug remains
|
||||
opt-in. Existing token fields keep their meaning; observed usage is separate.
|
||||
- No release, tag, push, source-license change, or binary packaging is part of
|
||||
these stages. Record upgrade implications in current integration/operator
|
||||
documentation; the eventual release note is a separate release task.
|
||||
|
||||
For each stage, inspect the starting worktree, implement code with its focused
|
||||
tests and current-behavior documentation, run the listed relevant checks, and
|
||||
make one coherent local commit under agent policy. Report checks and any gaps.
|
||||
Do not repeat passed checks for unchanged content merely to make a commit.
|
||||
|
||||
## Stage 1 — Cut Over Configuration Selection To Overlays
|
||||
|
||||
**Goal:** Adopt ConfigKit v0.4.0 and finish its narrow operator-facing rename in
|
||||
one coherent change. This is one prompt: it is a naming migration, not a new
|
||||
configuration engine.
|
||||
|
||||
**Inspect:** `internal/core/config/load.go`, `loaded_config.go`, configuration
|
||||
document/path/operational tests; `internal/cli/run.go`,
|
||||
`configkit_commands.go`, CLI configuration and example contract tests;
|
||||
`examples/profiles/development.yml`; upstream v0.4.0 migration guide.
|
||||
|
||||
**Work:**
|
||||
|
||||
1. Upgrade ConfigKit to v0.4.0 in `go.mod`/`go.sum`. Change `LoadOptions.Profile`
|
||||
to `Overlay` and pass it into `configkit.Options[Document].Overlay`. Rename
|
||||
only helpers, fields, locals, fixtures, and descriptions representing the
|
||||
selected configuration layer.
|
||||
2. Replace `--config-profile` with `--config-overlay` for `run`, `config validate`,
|
||||
`config effective`, `config explain`, and `pipelines list`. Update usage,
|
||||
flag parsing, argument classification, explicit-empty handling, and error
|
||||
paths together. Retired flags use normal unknown-flag behavior.
|
||||
3. Move `examples/profiles/development.yml` to
|
||||
`examples/overlays/development.yml`; update maintained-example discovery and
|
||||
selected-layer fixtures. Check file-relative paths after moving. Leave
|
||||
`examples/llm-profiles/`, PromptKit profile sources, and ordinary explicit
|
||||
imports alone unless an import actually points at the moved example.
|
||||
4. Consume upstream overlay provenance and diagnostic names directly. Do not
|
||||
rebuild composition, implement directory fallback, or translate metadata
|
||||
back to profile vocabulary.
|
||||
5. Update `docs/config.md`, `docs/cli.md`, `docs/integrations/pkg-configkit.md`,
|
||||
`docs/internal/configuration.md`, relevant portions of `docs/internal/cli.md`,
|
||||
and `docs/consumers/subprocess.md`. Review README, operations, and other
|
||||
consumer examples for affected invocations. Explain the clean migration and
|
||||
distinction from LLM profiles. Preserve accepted ADR-0018 and release history.
|
||||
|
||||
**Acceptance:** All five commands select overlays consistently. Representative
|
||||
existing tests cover selected/base/empty/default behavior, overlay and explicit
|
||||
override precedence, declaration-relative paths, redacted effective/explain
|
||||
output, and source-aware failure labels. Include a selected legacy-only file
|
||||
case proving there is no silent fallback. Retain ordinary-import behavior and
|
||||
LLM profile coverage; do not duplicate every upstream parser case.
|
||||
|
||||
**Validate:** `GOWORK=off go test ./internal/core/config ./internal/cli`,
|
||||
`GOWORK=off go mod tidy -diff`, `git diff --check`. Review occurrences of
|
||||
`config-profile` and `examples/profiles` in current docs/code semantically;
|
||||
historical docs and explicit legacy-rejection tests are not defects.
|
||||
|
||||
## Stage 2 — Upgrade The PromptKit Runtime Baseline
|
||||
|
||||
**Goal:** Adopt the compatible upstream dependency and document its changed
|
||||
default before adding Notarius controls. One small prompt.
|
||||
|
||||
**Inspect:** `internal/framework/llm/promptkit_client.go`, asset/profile identity
|
||||
helpers and tests, `go.mod`, and upstream v0.11.0 release/consumer documentation.
|
||||
|
||||
**Work:**
|
||||
|
||||
1. Pin PromptKit v0.11.0 and tidy. Keep the Go version and provider catalog
|
||||
selections unless the actual dependency graph requires a change; the target
|
||||
release does not require either. Do not alter embedded D&D model settings.
|
||||
2. Update `promptKitBuiltinProfileCatalogID` to the v0.11.0 identity in accordance
|
||||
with the existing checkpoint fingerprint convention. No other cache policy
|
||||
change or blanket invalidation is part of this work.
|
||||
3. Update the pinned integration links in `docs/integrations/pkg-promptkit.md`,
|
||||
including the relocated upstream `docs/policy/release.md`. Record the
|
||||
LGPL-3.0-or-later dependency license and reference its license/notices; do not
|
||||
relicense Notarius or invent a new distribution workflow.
|
||||
4. Remove the obsolete no-provider-retry-loop statement in `docs/internal/llm.md`.
|
||||
Describe the now-active upstream default and per-attempt timeouts in the
|
||||
appropriate integration/operations sections. Do not yet describe the setting
|
||||
or observations from later stages as implemented.
|
||||
|
||||
**Acceptance:** The prepared-execution adapter builds and its existing tests
|
||||
pass without prompt/catalog changes. Current documentation acknowledges the
|
||||
dependency's default retry behavior and license accurately.
|
||||
|
||||
**Validate:** `GOWORK=off go test ./internal/framework/llm ./internal/cli`,
|
||||
`GOWORK=off go mod tidy -diff`, `git diff --check`.
|
||||
|
||||
## Stage 3 — Wire The Explicit Transient Retry Setting
|
||||
|
||||
**Goal:** Make retry policy inspectable and configurable through the one shared
|
||||
engine. One prompt covering a single vertical configuration slice.
|
||||
|
||||
**Inspect:** `internal/core/config/{document,config,load,operational_document,
|
||||
loaded_config,validation}.go`, effective-config tests;
|
||||
`internal/cli/catalog.go:buildProductionLLMClient`;
|
||||
`internal/framework/llm/promptkit_client.go:NewPromptKitClient` and HTTP tests.
|
||||
|
||||
**Work:**
|
||||
|
||||
1. Add `TransientRetries *int` to `PromptKitDocument` and a resolved integer to
|
||||
`PromptKitConfig`. Supply 2 through both the document default path and the
|
||||
runtime `Default()` path. Preserve explicit zero; never use zero as omission.
|
||||
Include it in document-to-runtime conversion and effective configuration.
|
||||
2. Reject negative values through both existing document and direct runtime
|
||||
validation entry points. Follow current source-aware diagnostics; do not
|
||||
impose a new maximum. Keep ConfigKit's existing decoding behavior.
|
||||
3. Add `TransientRetries *int` to `PromptKitClientConfig`: nil follows upstream
|
||||
default, non-nil includes explicit zero. Production construction always
|
||||
supplies the resolved configuration value. Pass it into `promptkit.Config`,
|
||||
not per-request options. All calls through the injected shared client thus
|
||||
share the setting without module changes.
|
||||
4. Add the setting to `examples/dnd-complete.config.yml` and `docs/config.md`;
|
||||
keep the minimal example minimal. Update configuration/LLM internal guides
|
||||
for the new plumbing and operations for the zero-value opt-out.
|
||||
|
||||
**Acceptance/tests:** Demonstrate omitted default, explicit zero, a positive
|
||||
override, negative rejection, and effective/explain inspection. Use an existing
|
||||
CLI factory test to prove the resolved value reaches construction. Exercise
|
||||
built-in generation with a local HTTP server: eligible failure then success,
|
||||
disabled retries, exhausted configured count, and a noneligible 400 response.
|
||||
An injected `LLMClient` stub does not test built-in HTTP retry wiring. Avoid
|
||||
testing the upstream jitter formula or every equivalent HTTP status.
|
||||
|
||||
**Validate:** `GOWORK=off go test ./internal/core/config ./internal/cli ./internal/framework/llm`
|
||||
and `git diff --check`.
|
||||
|
||||
## Stage 4 — Preserve Typed Failure And Exhaustion Metadata
|
||||
|
||||
**Goal:** Distinguish provider failures without coupling callers to PromptKit.
|
||||
One prompt; defer execution observations to the next stage.
|
||||
|
||||
**Inspect:** `internal/framework/contracts/errors.go`, adapter error conversion
|
||||
in `promptkit_client.go`, redaction helpers, and existing pipeline handling of
|
||||
`ErrLLMGeneration`, `ErrLLMCapacityExceeded`, and invalid structured output.
|
||||
|
||||
**Work:**
|
||||
|
||||
1. Extend the existing application-owned `LLMGenerationError` rather than
|
||||
creating a parallel provider-error hierarchy. Retain `StatusCode()` and
|
||||
`errors.Is(err, ErrLLMGeneration)`. Add application-owned failure-kind,
|
||||
exhaustion, and exhausted-generation attempt metadata/accessors; use uint64
|
||||
for upstream attempt counts. Preserve the existing constructor's callers
|
||||
with sensible unspecified/generation metadata, adding a metadata constructor
|
||||
or private adapter helper as needed.
|
||||
2. Define kinds for `transport`, `provider_status`, `malformed_response`, and
|
||||
generic `generation`. Exhaustion is an independent boolean and attempt count,
|
||||
not a replacement kind. Zero attempts means unavailable in this error
|
||||
projection, not proof no request happened. The count comes from
|
||||
`RetryExhaustedError.Attempts()` and covers the exhausted generation, not all
|
||||
repair generations combined.
|
||||
3. Use `errors.Is`/`errors.As` on upstream sentinels/types. Keep cancellation and
|
||||
deadline identity first, capacity handling intact, and HTTP status available
|
||||
through an exhaustion wrapper. Do not unwrap application errors to upstream
|
||||
provider objects or classify by prose. Preserve sanitized diagnostic text.
|
||||
4. A malformed provider envelope is a generation failure; schema-invalid model
|
||||
content stays `ErrInvalidStructuredOutput`. Do not change outer retry or
|
||||
validator disposition logic. Document classification at the integration and
|
||||
internal LLM boundaries.
|
||||
|
||||
**Acceptance/tests:** Adapter tests cover transport, malformed response,
|
||||
noneligible status, exhausted eligible status with count/status preserved, and
|
||||
cancellation/deadline/capacity regression behavior. Check typed fields and
|
||||
identities, not full messages. Existing credential-redaction cases remain valid
|
||||
for nested exhaustion diagnostics; use fake secrets only.
|
||||
|
||||
**Validate:** `GOWORK=off go test ./internal/framework/contracts ./internal/framework/llm ./internal/framework/pipeline`
|
||||
and `git diff --check`.
|
||||
|
||||
## Stage 5 — Project Request-Local Execution Observations
|
||||
|
||||
**Goal:** Return a lightweight terminal summary even when generation fails.
|
||||
One prompt focused on contracts and adapter mapping, without persistence changes.
|
||||
|
||||
**Inspect:** `internal/framework/contracts/contracts.go`, `CompleteStructured`,
|
||||
`responseFromResult`, prepared execution tests, upstream `observations.go` and
|
||||
prepared-execution observer documentation.
|
||||
|
||||
**Work:**
|
||||
|
||||
1. Add an optional `Execution *LLMExecutionSummary` field to
|
||||
`StructuredCompletionResponse` (`execution,omitempty`). Own these DTOs in
|
||||
Notarius contracts; do not alias or serialize upstream event types.
|
||||
2. The summary contains uint64 `attempts`, `transient_retries`, `repair_calls`;
|
||||
integer millisecond `capacity_wait_ms`, `generation_ms`, `retry_delay_ms`,
|
||||
`duration_ms`; `outcome`, `failure_kind`, `status_code`, `retries_exhausted`;
|
||||
and `usage`. Usage contains prompt/completion/total/cached/cache-write counts,
|
||||
each with `value`, `known`, `complete` fields. Do not omit these booleans or
|
||||
known-zero values. The summary needs no prompts, response text, endpoints,
|
||||
credentials, raw errors, or new copies of run/profile identifiers.
|
||||
3. Map terminal outcome/failure values explicitly to application-owned strings.
|
||||
Preserve the distinctions exposed by v0.11.0 (including canceled, deadline,
|
||||
capacity, invalid output, configuration/load/render failures); unknown future
|
||||
failures map to `other`. Reuse relevant application failure vocabulary from
|
||||
Stage 4, without forcing every execution error into a generation error.
|
||||
4. Attach a local observer to the `RunRequest` before `PrepareExecution` freezes
|
||||
it. Retain the `ExecutionFinished` projection only: upstream supplies aggregate
|
||||
counts, durations, and usage. Do not sum attempt events and terminal totals,
|
||||
retain an event log, or reconstruct a second accounting system. Synchronous
|
||||
request-local collection needs no global state or asynchronous queue.
|
||||
5. Attach that summary to every subsequent return from `RunPrepared`, including
|
||||
context/capacity/provider failure and post-result decode/validation failure.
|
||||
Preparation failure has no execution event and returns no summary. Preserve
|
||||
upstream execution outcome as such: a later Notarius decode error remains a
|
||||
separate returned error, not a fabricated upstream terminal event.
|
||||
6. Keep existing successful-result token and repair fields unchanged. Observed
|
||||
`repair_calls` represents execution activity and is not a renamed legacy
|
||||
`RepairAttempts`. No observation field is a billable-cost guarantee.
|
||||
|
||||
**Acceptance/tests:** Success, failed execution, cancellation, and no-observation
|
||||
preparation failure retain the right presence. Test known zero versus unknown
|
||||
and partial aggregate usage with controlled provider responses. One concurrent
|
||||
completion case proves no summary cross-contamination. Check relationships and
|
||||
nonnegative durations, not exact timing. Document the DTO and mapping in
|
||||
`docs/internal/llm.md`; public dependency semantics stay in pkg-promptkit.
|
||||
|
||||
**Validate:** `GOWORK=off go test ./internal/framework/contracts ./internal/framework/llm`
|
||||
and `GOWORK=off go test -race ./internal/framework/llm`.
|
||||
|
||||
## Stage 6 — Carry Summaries Through Existing Debug Paths
|
||||
|
||||
**Goal:** Make observations useful to operators without a new output channel.
|
||||
One prompt, limited to debug propagation and terminal allowlists.
|
||||
|
||||
**Inspect:** `internal/framework/pipeline/debug.go`, its response-content/fallback
|
||||
helpers, terminal recording tests, and `debugLLMScope.references`. Trace
|
||||
`debugLLMCallReference` through the existing timed stage/terminal envelopes;
|
||||
updating only the detailed response file is insufficient. The CLI's separate
|
||||
run-summary files do not need a new run-wide accounting mechanism.
|
||||
|
||||
**Work:**
|
||||
|
||||
1. Project the optional execution summary into existing debug response artifacts
|
||||
and per-call references used by stage/terminal records. Explicitly preserve it
|
||||
when `Debug.Response` or `RunResult` is absent and through content splitting
|
||||
and fallback construction. Keep copies detached if existing clone paths
|
||||
could otherwise share mutable pointers.
|
||||
2. Use explicit typed fields as the allowlist for this metadata-only terminal
|
||||
projection. Do not carry raw upstream events, newly copied provider diagnostics, or model
|
||||
content into safe terminal summaries. Preserve established redaction and
|
||||
detailed-trace content boundaries.
|
||||
3. Leave warnings, normal console output, receipts, domain artifacts, checkpoint
|
||||
payloads, and no-debug behavior unchanged. No new telemetry file or aggregation
|
||||
of observed token totals into legacy totals.
|
||||
4. Update `docs/internal/state.md`/relevant debug internals and `docs/operations.md`
|
||||
to identify where this diagnostic information is available. Link to the
|
||||
canonical explanation rather than repeating every field in consumer docs.
|
||||
|
||||
**Acceptance/tests:** Through the real debug wrapper and existing recorder seam,
|
||||
verify success and failed/canceled completions retain summaries in response and
|
||||
safe terminal records. Verify content splitting/fallback does not discard them,
|
||||
and debug disabled writes nothing. Reuse existing redaction tests, adding only
|
||||
the new projection assertions. No new warnings result from recovered retries.
|
||||
|
||||
**Validate:** `GOWORK=off go test ./internal/framework/pipeline ./internal/cli`,
|
||||
`GOWORK=off go test -race ./internal/framework/pipeline`, `git diff --check`.
|
||||
|
||||
## Stage 7 — Verify Retry Composition And Finish Operator Guidance
|
||||
|
||||
**Goal:** Validate the cross-boundary behavior that individual stages cannot
|
||||
prove, then reconcile current documentation. One prompt; no generalized retry
|
||||
test framework or runtime redesign.
|
||||
|
||||
**Inspect:** Existing adapter HTTP fixtures, scheduler cancellation tests,
|
||||
pipeline stage retry/debug tests, CLI production tests; current config, LLM,
|
||||
operations, and consumer documentation.
|
||||
|
||||
**Work and acceptance:**
|
||||
|
||||
- Add one representative local-HTTP scenario combining a recoverable transient
|
||||
status with structurally invalid generated content followed by a successful
|
||||
repair. Prove transient budgets apply independently per generation and
|
||||
terminal attempt/repair/usage accounting is not doubled. Use small explicit
|
||||
budgets rather than executing the illustrative 18-request worst case.
|
||||
- Exercise cancellation during provider-directed retry waiting without a long
|
||||
real sleep: signal that the request was received, cancel a context while a
|
||||
long Retry-After is pending, and wait with a bounded test timeout. Preserve
|
||||
cancellation identity and the terminal observation. Do not build a second
|
||||
backoff implementation or test exact random delays.
|
||||
- Review shared scheduler tests for completion-scoped permit ownership and
|
||||
cancellation/release. Add a focused integration case only where existing
|
||||
coverage does not protect that boundary across the new retry path. Keep
|
||||
upstream backend capacity algorithms upstream.
|
||||
- Confirm a recovered generation passes through ordinary success without
|
||||
producing process warnings. Preserve existing outer stage retries and semantic
|
||||
feedback. Do not alter limits to hide budget multiplication.
|
||||
- Finish operations guidance: distinguish transient, structural, and stage/
|
||||
validator budgets; give the 18-attempt single-producer illustration with its
|
||||
assumptions; explain per-attempt timeout versus overall caller cancellation,
|
||||
Retry-After waits, cost/latency implications, incomplete usage accounting, and
|
||||
the outer scheduler holding its permit during waits. No new total deadline or
|
||||
exactly-once guarantee is implied.
|
||||
- Review all canonical docs changed earlier for consistency. Keep exact fields
|
||||
and defaults in config, flags in CLI, dependency semantics in integrations,
|
||||
mechanism in internals, and operating implications in operations. Keep the
|
||||
migration note about overlays distinct from unchanged LLM profiles. Retain
|
||||
historical ADR/release content; no new ADR is needed for these upgrades.
|
||||
|
||||
**Validate:** Run the focused adapter/pipeline/CLI tests and race tests covering
|
||||
modified concurrency paths. Review tests for unnecessary upstream duplication
|
||||
or exact-prose/change-detector assertions; consolidate rather than multiply them.
|
||||
|
||||
## Stage 8 — Final Integration Verification And Handoff
|
||||
|
||||
**Goal:** Verify the complete upgraded application and documentation against the
|
||||
feature roadmap. One final verification prompt; fix only defects within scope.
|
||||
|
||||
**Work:** Review all feature acceptance items and staged diffs. Confirm no
|
||||
upstream types escaped the LLM boundary, no references to the retired config
|
||||
flag remain in current examples/help, no unintended LLM profile rename occurred,
|
||||
and no source-only/license/release scope expanded. Check edited relative links.
|
||||
Leave the roadmap available for the user's completion review; do not publish a
|
||||
release or delete planning documents automatically.
|
||||
|
||||
**Validation commands:**
|
||||
|
||||
```sh
|
||||
GOWORK=off go test ./...
|
||||
GOWORK=off go vet ./...
|
||||
GOWORK=off go build ./...
|
||||
GOWORK=off go mod tidy -diff
|
||||
GOWORK=off go test -race ./internal/framework/llm ./internal/framework/pipeline
|
||||
GOWORK=off go run ./cmd/notarius config validate --config examples/dnd-minimal.config.yml
|
||||
GOWORK=off go run ./cmd/notarius config validate --config examples/dnd-complete.config.yml
|
||||
GOWORK=off go run ./cmd/notarius config validate --config examples/dnd-complete.config.yml --config-overlay development
|
||||
git diff --check
|
||||
```
|
||||
|
||||
Reuse already-passed checks for the same unchanged candidate where appropriate.
|
||||
The example/CLI tests own maintained examples; the commands above are a one-time
|
||||
migration smoke check, not new permanent release gates. No live model calls or
|
||||
real API keys are required. Report environment/dependency-access failures
|
||||
separately from implementation failures; do not claim blocked checks passed.
|
||||
|
||||
**Completion criteria:** Both exact dependency pins are active; overlay migration,
|
||||
retry setting, typed errors, observations, debug propagation, tests, examples,
|
||||
and current documentation satisfy the feature roadmap. Report commits and
|
||||
checks, plus any residual limitation. Future release preparation should explain
|
||||
the breaking overlay cutover, retry default/opt-out, and upstream license change
|
||||
in a minor-release note, but is not part of this implementation.
|
||||
|
||||
## Open Questions
|
||||
|
||||
None. The feature roadmap supplies the policy choices needed for implementation.
|
||||
The DTO naming and stage boundaries above settle remaining implementation choices
|
||||
without adding new product restrictions or compatibility promises.
|
||||
@@ -12,8 +12,9 @@ Adopt ConfigKit v0.4.0 and PromptKit v0.11.0 in one coordinated work set:
|
||||
Preserve application/framework boundaries and keep the two upgrades as distinct
|
||||
implementation workstreams. Neither requires a redesign of pipeline execution.
|
||||
|
||||
This is a feature roadmap describing the target state and required changes,
|
||||
not an implementation sequence. It does not authorize release publication.
|
||||
This feature roadmap owns the target state and scope. The ordered work and
|
||||
stage-specific verification belong to the [implementation plan](implementation.md).
|
||||
Neither document authorizes release publication.
|
||||
|
||||
## Current Baseline
|
||||
|
||||
|
||||
Reference in New Issue
Block a user