Align adoption plans with main-relative loading releases

This commit is contained in:
2026-11-10 15:49:05 +00:00
parent 0c7622375f
commit 40420a217a
6 changed files with 187 additions and 119 deletions

View File

@@ -1,5 +1,7 @@
# Next Major Release Implementation Plan
**Updated:** 2026-11-10
**Status:** Ready for the implementation sprint. This document assigns work;
it does not describe implemented behavior or authorize a release.
@@ -43,9 +45,10 @@ and [ReleaseKit contract](library-adoption.md#releasekit-adoption-work). Work in
Woodpecker; if unavailable, choose an available Go 1.27 patch and use it
consistently in the image, runbook, validation, and runtime attribution.
Include the C compiler and cgo prerequisites for the selected race check.
2. Select the exact versions from the master roadmap: ConfigKit v1.1.0,
PromptKit v0.20.0, CommandKit/ckconfig/ckprompt v0.6.0, and ReleaseKit v0.9.0,
all under `go.maximumdirect.net`. Move the ReleaseKit runtime `buildinfo`
2. Select the exact versions from the master roadmap: ConfigKit v1.2.0,
PromptKit v0.21.0, CommandKit core v0.6.0, ckconfig/ckprompt v0.7.0,
and ReleaseKit v0.9.0, all under `go.maximumdirect.net`.
Move the ReleaseKit runtime `buildinfo`
import and tool registration together. Move ConfigKit/PromptKit consumers in
Stages 2–4. Retire old requirements after their imports disappear; defer
final `go mod tidy` until all real consumers are wired. Prepare dependencies
@@ -87,9 +90,13 @@ execution in this stage.
rule. Reject supplied obsolete, null, or invalid versions with migration
guidance; when no header is supplied, decode against v3 defaults and schema.
Do not require headers on fragments or construct a pretend main source.
Supply explicit `OverlayFilesystem` rooted at the invocation directory for
a selected overlay (see [Open Questions](#open-questions)). Do not substitute
the overlay base for the main file's native relative-import context.
Follow the resolved [companion resource base](configkit.md#companion-resource-base-and-overlays--resolved).
Let ConfigKit derive the selected overlay context from the main; leave
`OverlayFilesystem` and `OverlayFallback` unset. Native selection uses
`overlays/<name>.yml` beside the main, with no aggregate `overlays.yml`.
Return recorded main source/context evidence for Stage 3's prompt loader;
no main context means optional companions are skipped, with no CWD fallback.
Use field-named literals for the expanded ConfigKit input/options types.
3. Define the final shape now: global preprocessing/chunking, output,
reporting, and diagnostic-directory settings; root defaults for eligible
stage settings; ordered `pipeline.stages` with `module`, optional `id`,
@@ -115,6 +122,9 @@ execution in this stage.
Evidence: native result/failure and source metadata cover discovery, exhaustion,
selected file errors, imports, overlays, v3 defaults, and changed override order.
Verify selected overlays follow the main directory even with a wider containment
root, and fail without a usable context or named file. Check that the returned
main context supports Stage 3 without another application load.
Exercise final v3 examples after the glossary fields are connected.
## Stage 3: Build the shared PromptKit engine and account for its sources
@@ -129,14 +139,19 @@ Own engine assembly in `internal/framework/llm/runtime.go`,
templates, schema references, and resource files. Remove version selection
and descriptive prompt version metadata, without changing response-schema
versions. Keep the embedded schemas supplied through `WithSchemaFS`.
2. Load embedded prompt inputs in their own filesystem underlay. Add exactly
one higher-priority operator underlay containing native optional imports of
2. Load embedded prompt inputs in their own filesystem underlay. When an
application main context exists, add one higher-priority operator underlay
containing native optional imports of
`prompts.yml` and recursive `prompts/` (`*.yml` and `*.yaml`), with imports
enabled and host root/base set to the invocation directory. Both sources
compose as strict peers. The app's `--config`, absence of a main file, and
overlay selection do not change the import base. Use one acquisition path
for all engine consumers. Do not pre-read/import these files in Audita,
manufacture filenames as IDs, or add an operator-source selector.
enabled and a concrete context derived from Stage 2's recorded application
main context. Preserve its lookup base, containment, and source accounting.
Both sources compose as strict peers. PromptKit's `MainRelative` refers to
its own main, so do not assume it binds to Audita's separate application load.
Do not feed Audita's document into PromptKit or reload it for its directory.
Without an application main context, omit automatic operator inputs and keep
the bundled/embedded tiers. Overlay selection does not relocate the base.
Use one acquisition path for all engine consumers, without a private parser,
directory walker, filename-derived IDs, or operator-source selector.
3. Use native root resources, collection IDs, sibling inheritance, and whole
same-ID replacement. Remove the generated backend main layer and the
curated profile projection. Preserve helpful classification of bad shipped
@@ -153,7 +168,9 @@ Own engine assembly in `internal/framework/llm/runtime.go`,
Evidence: optional absence, both inputs, nested imports and source-relative
messages, peer conflicts, whole replacement, untouched defaults, and edit/rerun
capture. Exercise external config elsewhere and absent main with the same CWD.
capture. Exercise explicit/discovered main files elsewhere, independence from
the invocation directory, recorded-context handoff, and absent-main skipping
while embedded resources remain usable. Preserve consumed-source evidence.
## Stage 4: Adapt native requests, role clients, and artifact redaction
@@ -199,7 +216,7 @@ secret-safe failure evidence. Leave stage client selection to Stage 12.
## Stage 5: Install CommandKit routing and native configuration/resource scopes
Read [CommandKit operator experience](commandkit.md#agreed-operator-experience)
and the released v0.6.0 guide linked there. Replace the routing/parser/inspection
and the released consumer guide linked there. Replace the routing/parser/inspection
parts of `internal/cli`; keep `cmd/audita` responsible for process lifetime and
streams, not the command declarations.
@@ -234,7 +251,7 @@ for inspection or overriding native grammar or status behavior.
Own the remaining `internal/cli` adapters. Use
[the resolved command scope](commandkit.md#request-preview-validation-and-smoke-commands--resolved)
and `WithRequestPreparation`, `WithRequestValidation`, and `WithSmokeTesting`
from ckprompt v0.6.0. Install all capabilities with the Stage 5 declarations.
from ckprompt v0.7.0. Install all capabilities with the Stage 5 declarations.
1. Forward the released native requests, overrides, namespaces, formats, and
outcomes. Use the same engine acquisition as processing. For Audita-owned
@@ -339,9 +356,11 @@ through its default-source and entry-contract sections.
the selected entry fields without slug restrictions, global ID uniqueness,
or validation of arbitrary extension contents.
2. Add one application underlay with optional native `glossary.yml` and
recursive `glossary/` imports mounted at `glossary_collections`. Set host
base/root to the invocation directory, independent of discovered/explicit
app main. Preserve peer conflicts, nested relative imports and placement,
recursive `glossary/` imports mounted at `glossary_collections`. Use a
non-file input with imports enabled and `MainRelative: configkit.MainRelative()`
so ConfigKit binds it to the selected application main during the same load.
Supply no fallback; absent main context skips the optional imports. Preserve
peer conflicts, nested relative imports and placement,
source attribution, and native cross-tier whole-record upsert. Do not use
filename identity, a private walker, or infer that main `imports: []`
cancels the application underlay. Use the separate PromptKit underlay for
@@ -555,23 +574,3 @@ in the real repository during this sprint.
actual major tag/module-path selection, checked-in release notes, and source
publication, remains separate. Do not claim implementation completion on
the basis of the earlier library probes or any unresolved required behavior.
## Open Questions
### Which directory should contain selected overlays?
The roadmap selects native overlays, but does not give `LoadLayered` its
required explicit overlay context. Native automatic discovery selects the main
file during loading, so its path cannot be used to choose that context in advance.
- **Recommendation, used by Stage 2:** use the invocation directory as the
overlay root (`./overlays/<name>.yml`), with or without a main file. This is
consistent with the selected automatic glossary and PromptKit contexts and
permits a single native load. Main-file imports still use their own context.
- **Alternative:** expose an explicit overlay-root selector, defaulting to the
invocation directory. This supports centralized overlays independent of the
invocation directory at the cost of another selection to wire through all
commands and comparison sides. If main-file-relative overlays themselves are
required, seek a native layered-loading facility for that behavior before
adding a second discovery/load pass. The old main-relative behavior carries
no compatibility requirement for this release.