Next Major Release Roadmap

Updated: 2026-11-10

Status: Target decisions are recorded across this roadmap and its four child roadmaps; the implementation and selected dependency changes are complete. The implementation plan owns the sprint sequence.

Objective and Document Ownership

Align Audita with the supported happy path of ConfigKit, PromptKit, CommandKit, and ReleaseKit so operators and maintainers encounter the same conventions across the application suite. Choose the best target state for Audita; maintaining compatibility with current behavior carries no weight in this major release.

The release also includes reusable glossary configuration composed through ConfigKit and stages that select different glossary inputs. This is required feature scope alongside the library upgrades; the glossary roadmap owns the configuration handoff and derived runtime representations.

This document owns shared adoption principles, dependency selection, and cross-library decisions, including the ReleaseKit target below. The linked outlines own feature-specific outcomes and acceptance criteria:

Outline	Responsibility
ConfigKit	Stable configuration API, loading, discovery, presence, secrets, and provenance
PromptKit	Native resources and bundled catalog, role integration, execution, and source accounting
CommandKit	Standard operator interface, configuration commands, full ckprompt inspection, and reporting
Stage-Specific Glossary Inputs	Reusable glossary configuration, stage selections, and derived runtime vocabulary

This master roadmap and the three library outlines replace the removed import-upgrade.md. They retain its relevant technical evidence but supersede its recommendations to disable the OpenRouter bundle, defer CommandKit adoption, limit standard inspection, or preserve Audita's backend ownership restrictions without a domain justification. They do not select unrelated work in future.md.

Agreed Adoption Principles

ConfigKit: fully adopt and adapt to its stable public API and native conventions. Diverge only where an identified Audita requirement makes it necessary; a local convenience is not sufficient justification.
PromptKit: follow the mature library's supported path, including its bundled OpenRouter backend and profiles. Significant blockers or pain points may justify a focused upstream feature request before adding substantial local integration machinery.
CommandKit and integrations: adopt the standard suite experience, including the full ckprompt inspection command set. The libraries are young; problematic or incomplete behavior is a candidate for an upstream change request rather than a permanent Audita workaround. For standard commands passed through by Audita, link concisely to upstream documentation instead of maintaining a local reference, warnings, or caveats about upstream capabilities. Document Audita's own inputs, wiring, and domain-specific behavior.
ReleaseKit: adopt go.maximumdirect.net/releasekit v0.9.0 and move as much release machinery upstream as possible. Audita may select any number of ReleaseKit-owned validators. Retain local release validation only with a documented domain-specific justification. Treat its maturity as broadly similar to PromptKit, though somewhat lower; significant gaps are candidates for focused upstream requests.
Major-release cutover: old configuration, CLI, output, and release-workflow behavior impose no compatibility requirement. Do not add compatibility aliases, dual formats, transition modes, or legacy-behavior tests merely to ease adoption. Release guidance may require a hard cutover. Domain requirements still guide the target, but existing implementations and contracts are open to redesign. Audita's application configuration uses version: 3 with a hard cutover, as resolved in the ConfigKit outline.
Remove redundant code: reducing Audita's maintenance burden is an explicit adoption goal. Retire local mechanisms, settings, wrappers, and tests superseded by supported upstream behavior. Keep the domain logic and integration code that Audita needs; retaining existing code is not a success criterion.
Audita continues to own transcript formats, correction ordering, domain validation, structured-response contracts, and truthful partial-success behavior. Inspect each other restriction against a concrete domain need.
Standard library inspection and native redaction are part of the target. Retire the curated profile summary in favor of the standard inspection and preview interfaces, as resolved in the PromptKit outline.

For each friction point, record the desired outcome, whether the constraint is library behavior or an Audita domain requirement, the proposed adaptation or upstream request, and its acceptance evidence. Distinguish agreed decisions from recommendations. The CommandKit outline records the released reporting capabilities and adoption evidence.

Baseline and Selected Dependency Set

The reviewed application revision is cbcb1b3778d747ced7825d09d9e7536cabc0f0fa. Its module file uses old-path ConfigKit v0.7.1 and PromptKit v0.14.0, with no CommandKit. The source minimum is Go 1.26.0; the release runbook selects Go 1.26.8.

The following published versions are selected for adoption. The reviewed set uses CommandKit core v0.6.0 with both integrations at v0.7.0. The CommandKit and main-relative ConfigKit availability gates are satisfied:

Module	Version	Reviewed source commit
`go.maximumdirect.net/configkit`	v1.2.0	`c1c7e87f2cdf77a0cbf3327831ac05578e756b9e`
`go.maximumdirect.net/promptkit`	v0.21.0	`171fb11f4e967a1da3af57843c6467954b14ba09`
`go.maximumdirect.net/commandkit`	v0.6.0	`1613ff95cab60581de5d86f6e9e2a3cc091a44a0`
`go.maximumdirect.net/ckconfig`	v0.7.0	`64f6453b8453f914f272d427bb4ae6f59deacd2b`
`go.maximumdirect.net/ckprompt`	v0.7.0	`f369d6a78253b6e6fcb1e023fb2e9c3af1d20ff0`
`go.maximumdirect.net/releasekit`	v0.9.0	`2180aa868ec2caa95fc8279fd59d5f0ebac41bd4`

The integration tags are integrations/ckconfig/v0.7.0 and integrations/ckprompt/v0.7.0 in CommandKit's repository. Use the released module selection guide. The integrations select ConfigKit v1.2.0 and PromptKit v0.21.0. The combined consumer minimum is Go 1.27.0. Use field-named ConfigKit struct literals for the new input and layered-option fields. Changes to these selected versions require an ordinary compatibility review rather than assuming later releases are interchangeable.

CommandKit release gate — satisfied: the published v0.6.0 core provides both the independent shared debug binding for capture and the resolved reporting-mode accessor for quiet destination validation. The matching released integrations were reviewed together. The CommandKit outline records the API contract and review evidence. The selected release set removes the upstream availability blocker; Audita implementation and acceptance are complete under the implementation plan.

Main-relative loading gate — satisfied: ConfigKit v1.2.0 implements the requested companion import binding and derived layered-overlay context. Follow the shared resource-base decision. Load application configuration first, construct PromptKit using its recorded context, then expose both through the CommandKit integrations. Glossary-stage execution follows the library foundations; the implementation plan retains that order. No preliminary discovery/load pass or local directory walker is needed.

The reviewed target dependency graph includes ReleaseKit v0.9.0, but Audita's direct tool still uses old-path v0.4.1. The release, workflow, and validator review is complete, with no identified upstream blocker. The agreed ReleaseKit adoption work below remains to be implemented and accepted in Audita.

ReleaseKit Adoption Work

Workflow and Validator Selection — Resolved

Adopt ReleaseKit v0.9.0's standard publication and asynchronous delivery workflow. This implements the ownership decision in ADR 0001. Audita already delegates publication, builds, and delivery to ReleaseKit; the upgrade modernizes that integration and removes duplicated generic tests. No additional Audita-owned release validator or upstream feature request is needed for the reviewed requirements. Audita's domain tests remain in the ordinary offline suite executed by ReleaseKit.

The selected workflow is:

Prepare the release note and final committed candidate, then push that candidate to the authoritative main branch.
Use one ReleaseKit publish invocation to validate the candidate, check the required builds and version identity, and publish the annotated tag. Keep check available for diagnosis; do not require it before publish repeats validation.
Use the maintained Woodpecker tag-delivery workflow to invoke ci-deliver from the tagged source. Deliver the hosted release page, Linux amd64 and arm64 binaries, and checksums asynchronously. Successful tag publication completes the source release; report artifact delivery separately.
Use ReleaseKit's standard recovery commands and procedures for publication and delivery failures, without a separate Audita recovery layer.

Use the reviewed upstream publication guide, delivery guide, and configuration reference for standard behavior. Select these checks through the native release profile:

Capability	Selection	Reason
Standard offline Go test suite and candidate/publication guards	Retain ReleaseKit's built-in checks	Validate Audita's behavior and the exact source being published.
Race detection	`validation.go.race: true`	Audita's concurrent processing and cancellation warrant race detection in the single standard suite.
Full Go vet	`validation.go.full_vet: true`	Add static checks; ReleaseKit disables test-time vet to avoid duplication.
Go formatting	`validation.go_format: true`	Enforce consistent formatting through the shared implementation.
Local Markdown links and heading references	`validation.markdown: {}`	Protect documentation navigation using upstream defaults.
Committed workspace files	`validation.module_distribution.workspace_files: true`	Keep development workspace files out of releases.
Filesystem module replacements	`validation.module_distribution.local_replacements: true`	Prevent releases depending on local dependency checkouts.
Application builds and version identity	Retain `build.targets` for `linux/amd64` and `linux/arm64`, with ReleaseKit's native version check	Verify the required production binaries and their embedded version.
Additional compile-only targets	Omit `validation.go.compile_targets` initially	Limited additional value alongside the required application builds.
File-size limits	Omit `validation.file_size` initially	No application-specific size ceiling has been selected.
Forbidden-file paths	Omit `validation.forbidden_files` initially	Delivery uses the existing CI secret; no release-token file is configured.

Do not duplicate these checks in profile checks, custom release hooks, or surrounding scripts. Any future local release validator requires a documented domain-specific justification; reusable gaps should be addressed upstream.

Release Integration Acceptance

The direct tool and runtime version accessor use the same v0.9.0 module identity. The launcher and Woodpecker bootstrap follow the v0.9.0 adoption recipes and tag-delivery template, including host target selection, full tool-package invocation, and prepared tag checkout verification. Audita retains its product, Linux production targets, delivery destination, and CI secret mapping, with delivery.forge: "gitea". Local validation and CI use the selected Go 1.27-or-newer toolchain; maintainer setup includes the C compiler and cgo prerequisites for race detection.

ReleaseKit owns generic bootstrap, launcher, and selected native validation mechanisms. Audita retains focused evidence for its product settings, targets, destination, and version integration. Acceptance covers the selected validators, both production builds, version identity, and assembled launcher/CI wiring, without publishing a release. The disposable local check below is evidence for local candidate validation and does not establish hosted delivery. Adopted policy and runbook describe the selected workflow, validator rationale, and native recovery.

Shared Evidence, Validation, and Completion

The review verified release identities, requirements, and relevant upstream contracts. On 2026-11-10, published tags matched the selected commits above. All packages in the four newly selected releases passed their tagged suites with Go 1.27.3, GOWORK=off, and no local replacements; two PromptKit packages needed local HTTP test listeners permitted. The ckprompt module graph selected exactly the ConfigKit, PromptKit, ckconfig, and core versions above. Upstream coverage includes companion discovery, optional file/directory combinations, precedence, absent-main handling, and prompt content-file context.

Earlier disposable checks using Go 1.27.3 established:

Audita's existing core configuration tests pass after import/API adaptation; the application build still fails at the expected PromptKit API changes.
CLI parent overrides do not rerun ConfigKit inheritance. PromptKit same-ID replacement drops omitted provider settings; distinct native inheritance can retain them. Profile null endpoints permit backend fallback.
Tagged CommandKit core, ckconfig, and ckprompt v0.6.0 suites pass independently with released dependencies, GOWORK=off, and no local replacements.
A separate consumer of all three published v0.6.0 modules passes 33 cases covering debug capture, reporting-mode ordering, aliases, and quiet transcript destination validation. That earlier graph selected ConfigKit v1.1.0 and PromptKit v0.20.0 and brought in ReleaseKit v0.9.0.
A disposable Audita copy with the ReleaseKit tool and runtime version import migrated to v0.9.0, and toolchain references aligned, passes the selected native validators, Linux amd64 and arm64 builds, and the native version-output check. This exercised local check only; no release was published and hosted delivery was not exercised.

These are review results, not implementation acceptance. They involved no live provider calls and do not prove migrated Audita behavior or cross-platform execution. Use controlled provider boundaries and proportionate tests under testing policy; live diagnostics are not release gates.

Completion requires all four library adoption targets, stage-specific glossary inputs, resolved decisions, migrated examples, useful native inspection, the selected domain behavior, a passing assembled application, and the adopted ReleaseKit workflow. Every retained local release validator must have a domain-specific justification. Acceptance tests must assert the target contracts; update or remove tests whose sole purpose is preserving superseded behavior. Upstream requests need an explicit disposition before calling the dependent behavior complete. Any temporary workaround must name its reason and removal condition; it is not architecture by default.

Completion also includes retiring superseded local machinery and its obsolete configuration, documentation, and tests. Preserve evidence for the selected domain behavior and real integration boundaries without duplicating upstream implementation tests. Code removal is a desired result, with no deletion quota.

Refresh attribution for the exact selected dependencies and toolchain under OSS policy. The reviewed library grants remain LGPL-3.0-or-later; remove old catalog entries when no longer incorporated and retain shared license texts. Do not copy upstream policy inventories.

17 KiB Raw Blame History