Add documetation policy
This commit is contained in:
209
docs/policy/architecture.md
Normal file
209
docs/policy/architecture.md
Normal file
@@ -0,0 +1,209 @@
|
||||
# Architecture Policy
|
||||
|
||||
## Purpose
|
||||
|
||||
This document defines Audita's development architecture and invariants for maintainers and LLM coding agents. It describes how the project is intended to be changed safely, based on behavior implemented in this repository today.
|
||||
|
||||
User-facing behavior belongs in the README and focused runtime docs. Future or proposed work belongs only under `docs/roadmap/`.
|
||||
|
||||
## Project Shape
|
||||
|
||||
Audita is a single-process Go CLI for transcript polishing. The executable entrypoint is `cmd/audita`; command handling lives in `internal/cli`.
|
||||
|
||||
The implemented `audita process` flow is:
|
||||
|
||||
1. load effective config;
|
||||
2. read and validate transcript JSON and glossary YAML;
|
||||
3. normalize transcript segments;
|
||||
4. chunk the working transcript into sections;
|
||||
5. resolve configured module instances;
|
||||
6. run correction modules and validator chains;
|
||||
7. apply approved proposals deterministically;
|
||||
8. write transcript output, reports, and diagnostics artifacts.
|
||||
|
||||
The current built-in modules are `glossary`, `homophones`, `spoken_word`, and `grammar`. The default configured module sequence repeats `glossary`.
|
||||
|
||||
For external behavior and compatibility details, prefer links to existing behavior docs:
|
||||
|
||||
- [Architecture overview](../architecture/architecture.md)
|
||||
- [Public contract](../architecture/public-contract.md)
|
||||
- [Diagnostics](../architecture/diagnostics.md)
|
||||
- [Structured LLM](../architecture/structured-llm.md)
|
||||
- [Validators](../architecture/validators.md)
|
||||
- [Prompts](../architecture/prompts.md)
|
||||
- [Output schemas](../architecture/output-schemas.md)
|
||||
- [Configuration](../configuration.md)
|
||||
|
||||
## Core Design Principles
|
||||
|
||||
- **Hexagonal architecture:** keep domain behavior behind narrow internal contracts. CLI, filesystem, config loading, diagnostics writing, and LLM transport are adapters around the core processing flow.
|
||||
- **Composable modules and validators:** correction stages and validators should remain small, explicit, and independently testable.
|
||||
- **Deterministic orchestration around LLM calls:** LLM responses are nondeterministic inputs. Proposal indexing, validator ordering, proposal application, reports, and output serialization must remain deterministic.
|
||||
- **Bounded and observable concurrency:** use the implemented schedulers and configured concurrency limits for LLM call sites. Preserve utilization diagnostics when changing scheduling or orchestration.
|
||||
- **Conservative correction behavior:** validate proposed corrections before application; apply accepted proposals through deterministic apply-time safety checks.
|
||||
- **Standard-library-first:** prefer the Go standard library. Narrow third-party dependencies are acceptable when they materially improve maintainability, such as `gopkg.in/yaml.v3` for YAML parsing.
|
||||
- **Current-behavior documentation:** non-roadmap docs must describe implemented behavior only.
|
||||
|
||||
## Architectural Boundaries
|
||||
|
||||
`internal/core` owns domain data handling and stable runtime contracts that do not require CLI or provider transport knowledge:
|
||||
|
||||
- config defaults, loading, validation, redaction, and catalogs;
|
||||
- transcript and glossary schemas;
|
||||
- normalization and chunking;
|
||||
- output-schema encoding;
|
||||
- diagnostics artifact naming and run-directory helpers;
|
||||
- public process report shapes.
|
||||
|
||||
`internal/framework` owns orchestration contracts and reusable runtime mechanics:
|
||||
|
||||
- module and validator interfaces;
|
||||
- proposal generation, proposal application, and prompt context;
|
||||
- runner orchestration;
|
||||
- LLM scheduler, OpenAI-compatible adapter, redaction helpers, and diagnostics writers;
|
||||
- structured response schema registry;
|
||||
- process report and correction-ledger assembly.
|
||||
|
||||
`internal/modules/*` owns module-specific correction stages. `internal/validators/*` owns built-in validator implementations, registry, chains, and execution-class metadata. `internal/prompts` owns embedded prompt assets and prompt metadata.
|
||||
|
||||
`internal/cli` owns command parsing, exit codes, stdout/stderr behavior, config command behavior, filesystem input/output wiring, and top-level process orchestration. CLI concerns should not move into modules, validators, or schema logic.
|
||||
|
||||
Tests should stay close to the behavior they protect. Shared test helpers are acceptable when they remove clear duplication without hiding module-specific behavior.
|
||||
|
||||
## Modules and Validators
|
||||
|
||||
Modules implement `contracts.TranscriptModule`. A module must provide:
|
||||
|
||||
- a stable key;
|
||||
- a replacement policy;
|
||||
- a validator chain;
|
||||
- proposal generation from explicit request inputs.
|
||||
|
||||
Module packages should stay separate. Do not collapse module-specific prompts, scope, or validation choices into a broad generic stage abstraction.
|
||||
|
||||
Validators implement the shared validator contract and return one decision per candidate proposal. Deterministic validators and LLM-backed validators are both composable chain elements. Validator identity and execution class metadata are stable enough to affect ordering, diagnostics, reports, and correction-ledger classification.
|
||||
|
||||
Future module or validator changes should preserve:
|
||||
|
||||
- explicit inputs and outputs;
|
||||
- no hidden global state;
|
||||
- explicit config dependencies;
|
||||
- deterministic proposal index handling;
|
||||
- validation before final mutation;
|
||||
- stable reason codes and validator keys where already exposed.
|
||||
|
||||
## LLM Integration and Concurrency
|
||||
|
||||
LLM calls are external effects behind narrow contracts. Production structured completions use `contracts.StructuredLLMClient`; the implemented provider adapter is OpenAI-compatible HTTP code in `internal/framework/llm`.
|
||||
|
||||
Structured response schemas are registered in `internal/framework/responseschema`. Provider-side schema enforcement is not a substitute for local validation: Audita still validates proposal structure, validator decision cardinality, and apply-time safety.
|
||||
|
||||
Concurrency is bounded by configured scheduler limits:
|
||||
|
||||
- total LLM concurrency;
|
||||
- proposal LLM concurrency;
|
||||
- validation LLM concurrency.
|
||||
|
||||
The scheduler is context-aware and releases permits on success, failure, and cancellation. Runner code may collect section-level work concurrently, but transcript mutation is applied later in deterministic proposal-index order.
|
||||
|
||||
Diagnostics for LLM interactions should be useful for debugging without leaking configured secrets. Use the existing redaction helpers and `llm.ConfiguredSecrets`.
|
||||
|
||||
## State, Inputs, and Outputs
|
||||
|
||||
Audita does not implement resume, checkpoint, manifest, or remote storage behavior. Runtime state is in memory plus per-run diagnostics artifacts written under the configured work directory.
|
||||
|
||||
Transcript input accepts the implemented JSON forms documented in the public contract. Parsed source transcripts are normalized into Audita's internal transcript shape before chunking and module execution.
|
||||
|
||||
Proposals and validator decisions are intermediate runtime data. Approved proposals are applied through `internal/framework/proposals`, which clones transcript state, orders by proposal index, and records applied or skipped changes.
|
||||
|
||||
Transcript output is encoded through `internal/core/outputschema`. Reports and correction ledgers are machine-readable artifacts derived from runner outputs; their public shape should not be changed casually.
|
||||
|
||||
## Configuration and CLI Boundaries
|
||||
|
||||
Config behavior is owned by `internal/core/config`; command usage and process wiring are owned by `internal/cli`.
|
||||
|
||||
`audita process` uses implemented precedence: defaults, config file, environment, then CLI flags. `config validate` validates defaults plus a file config and intentionally does not apply environment overrides. `config print-effective` applies defaults, file config, and environment overrides, then prints redacted JSON.
|
||||
|
||||
Do not duplicate full CLI or config reference material here. Use [Configuration](../configuration.md), the README, and [Public contract](../architecture/public-contract.md) for current external behavior.
|
||||
|
||||
When adding config fields or CLI flags, update:
|
||||
|
||||
- config defaults, file/env/CLI application, and validation;
|
||||
- CLI flag extraction if applicable;
|
||||
- redaction when secrets are involved;
|
||||
- tests for precedence and source-specific behavior;
|
||||
- user-facing docs if external behavior changes.
|
||||
|
||||
## Errors, Logging, and Diagnostics
|
||||
|
||||
Errors should be phase-specific enough for CLI users and subprocess callers. The CLI writes human-readable errors to stderr and preserves transcript JSON-only stdout behavior on successful stdout output.
|
||||
|
||||
Run diagnostics are best-effort after run-directory creation. Failed runs are retained. Successful run retention follows the implemented work-dir retention policy.
|
||||
|
||||
Diagnostics and reports must not leak configured LLM secrets. Config redaction and LLM payload/error redaction are separate responsibilities and should remain separate.
|
||||
|
||||
Process reports, diagnostics metadata, utilization diagnostics, and correction ledgers are part of the public contract. Prefer additive, compatible changes.
|
||||
|
||||
## Testing Expectations
|
||||
|
||||
Use targeted package tests for touched behavior and `go test ./...` for substantial changes.
|
||||
|
||||
When changing modules, inspect or add:
|
||||
|
||||
- package-local module tests under `internal/modules/*`;
|
||||
- prompt rendering or proposal-generation tests when prompt inputs change;
|
||||
- parity or release fixtures when public output behavior changes.
|
||||
|
||||
When changing validators, inspect or add:
|
||||
|
||||
- validator package tests;
|
||||
- registry and chain tests under `internal/validators`;
|
||||
- framework validator tests for batching, malformed output, diagnostics, and cardinality.
|
||||
|
||||
When changing LLM integration or concurrency, inspect or add:
|
||||
|
||||
- `internal/framework/llm` scheduler/client/redaction tests;
|
||||
- `internal/framework/runner` orchestration and utilization tests;
|
||||
- structured-output malformed classification tests.
|
||||
|
||||
When changing config, CLI, schema, output, reports, or diagnostics, inspect or add:
|
||||
|
||||
- `internal/core/config` tests;
|
||||
- CLI tests under `internal/cli`;
|
||||
- schema and output-schema tests under `internal/core`;
|
||||
- report, diagnostics, parity, and release-fixture tests.
|
||||
|
||||
## Dependency Policy
|
||||
|
||||
Audita should remain dependency-light. Prefer standard-library solutions for CLI parsing, HTTP, JSON, filesystem, synchronization, and tests.
|
||||
|
||||
Third-party dependencies should be narrow, justified, and preferably de facto standard for their purpose. YAML parsing is the current direct dependency exception.
|
||||
|
||||
Do not add broad frameworks for CLI, dependency injection, workflow orchestration, logging, or plugin systems without a concrete implemented need and focused tests.
|
||||
|
||||
## Documentation Expectations
|
||||
|
||||
Follow [Documentation Policy](./documentation.md). Architecture policy must stay concise and aligned with implemented behavior.
|
||||
|
||||
Do not use architecture docs as changelogs. Do not describe planned modules, adapters, modes, persistence, or configuration unless they are implemented. Put future work under `docs/roadmap/`.
|
||||
|
||||
## Architectural Invariants
|
||||
|
||||
- Keep LLM transport behind `StructuredLLMClient` and framework adapter boundaries.
|
||||
- Keep correction modules narrowly scoped and package-separated.
|
||||
- Keep validators modular, composable, and identified by stable keys.
|
||||
- Keep CLI/config/filesystem concerns out of module and validator domain logic.
|
||||
- Preserve deterministic transcript mutation and output handling around nondeterministic LLM calls.
|
||||
- Keep LLM concurrency bounded, configurable, and observable where implemented.
|
||||
- Keep run diagnostics and reports redacted and machine-readable.
|
||||
- Keep public CLI, config, output-schema, diagnostics, report, prompt, module, and validator contracts stable unless a change is explicit and tested.
|
||||
- Prefer small shared helpers over broad rewrites.
|
||||
- Avoid new dependencies unless they are narrow and clearly justified.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- No plugin framework is implemented.
|
||||
- No generic workflow engine is implemented.
|
||||
- No resume, checkpoint, manifest, or remote storage system is implemented.
|
||||
- No multi-process service mode is implemented.
|
||||
- No provider SDK abstraction beyond the current structured LLM client contract and OpenAI-compatible HTTP adapter is implemented.
|
||||
@@ -1,791 +0,0 @@
|
||||
# Pre-1.0 Code Quality and Deduplication Audit
|
||||
|
||||
## 1. Executive summary
|
||||
|
||||
Audita is in good shape for a limited pre-1.0 cleanup pass. The repository is small, package boundaries are mostly explicit, and the core public contract is already documented around `audita process`, config loading, output schemas, diagnostics, reports, embedded prompts, modules, and validators. The highest-value improvements are targeted centralization, not a rewrite.
|
||||
|
||||
Top three refactoring targets before 1.0:
|
||||
|
||||
1. Centralize module proposal plumbing and prompt payload construction across the four production modules.
|
||||
2. Centralize effective config loading plus schema/module catalog validation so `process`, `config print-effective`, and `config validate` cannot drift.
|
||||
3. Centralize diagnostics artifact names, stage names, and validator classification metadata used by reports and the correction ledger.
|
||||
|
||||
No major architectural risk is apparent. The main pre-1.0 risk is public-behavior drift from repeated policy strings, catalog values, artifact paths, and nearly identical command/module scaffolding.
|
||||
|
||||
This report was written to `docs/roadmap/audit.md`. `docs/roadmap/` already exists in the repository, although its previous `publish.md` file is currently deleted in the worktree by an unrelated change.
|
||||
|
||||
## 2. Repository map reviewed
|
||||
|
||||
Reviewed documentation:
|
||||
|
||||
- `README.md`
|
||||
- `docs/configuration.md`
|
||||
- `docs/architecture/architecture.md`
|
||||
- `docs/architecture/public-contract.md`
|
||||
- `docs/architecture/diagnostics.md`
|
||||
- `docs/architecture/output-schemas.md`
|
||||
- `docs/architecture/prompts.md`
|
||||
- `docs/architecture/validators.md`
|
||||
- `docs/architecture/structured-llm.md`
|
||||
- `docs/integration/subprocess-operations.md`
|
||||
- `docs/release-checklist.md`
|
||||
|
||||
Reviewed implementation areas:
|
||||
|
||||
- `cmd/audita`
|
||||
- `internal/cli`
|
||||
- `internal/core/config`
|
||||
- `internal/core/schema`
|
||||
- `internal/core/io`
|
||||
- `internal/core/normalization`
|
||||
- `internal/core/chunking`
|
||||
- `internal/core/diagnostics`
|
||||
- `internal/core/outputschema`
|
||||
- `internal/core/reporting`
|
||||
- `internal/framework/contracts`
|
||||
- `internal/framework/modules`
|
||||
- `internal/framework/proposal_generation`
|
||||
- `internal/framework/proposals`
|
||||
- `internal/framework/runner`
|
||||
- `internal/framework/validators`
|
||||
- `internal/framework/llm`
|
||||
- `internal/framework/responseschema`
|
||||
- `internal/framework/promptcontext`
|
||||
- `internal/framework/warnings`
|
||||
- `internal/modules/glossary`
|
||||
- `internal/modules/homophones`
|
||||
- `internal/modules/spoken_word`
|
||||
- `internal/modules/grammar`
|
||||
- `internal/prompts`
|
||||
- `internal/validators`
|
||||
- package tests and CLI parity/release fixtures under `internal/cli/testdata`
|
||||
|
||||
Major execution paths reviewed:
|
||||
|
||||
- `audita process <transcript.json> --glossary <glossary.yaml>`
|
||||
- `audita config validate --config <path>`
|
||||
- `audita config print-effective [--config <path>]`
|
||||
- default module sequence resolution and repeated glossary instance naming
|
||||
- proposal generation, validator execution, proposal application, report writing, diagnostics writing, and retention
|
||||
|
||||
Important absent or not-applicable areas:
|
||||
|
||||
- No `pkg/` directory exists.
|
||||
- No `examples/` directory exists.
|
||||
- No `docs/internal/` directory exists.
|
||||
- No `internal/app`, `internal/stage`, `internal/storage`, `internal/artifacts`, or `internal/manifest` packages exist. Their closest equivalents are `internal/cli`, `internal/framework/runner`, `internal/core/diagnostics`, and `internal/core/reporting`.
|
||||
|
||||
## 3. High-confidence deduplication opportunities
|
||||
|
||||
### 3.1 Module proposal plumbing is duplicated across all production modules
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/modules/glossary/module.go`
|
||||
- `internal/modules/homophones/module.go`
|
||||
- `internal/modules/spoken_word/module.go`
|
||||
- `internal/modules/grammar/module.go`
|
||||
- `internal/modules/*/prompt.go`
|
||||
- `internal/framework/proposal_generation`
|
||||
- `internal/framework/promptcontext`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- Each module has the same `Module` struct shape, `Validators` copy behavior, `Propose` flow, section transcript extraction, transcript description extraction, `proposal_generation.GenerateCandidates` request construction, prompt metadata map construction, and stage-name formatting.
|
||||
- Each module also has a near-identical prompt payload builder with local `promptSegment` and `promptTranscriptSection` types, glossary JSON marshaling, transcript section JSON marshaling, transcript description block rendering, and two-message return shape.
|
||||
- `collectSectionProposals` already passes a section transcript to each module, but each module then filters that transcript again by section metadata.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- A diagnostics or prompt-context bug fix would need to be repeated in four modules.
|
||||
- Prompt metadata fields and stage names are diagnostics-visible and could drift by module.
|
||||
- The double section filtering is currently harmless, but it obscures the runner/module contract.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Add a small shared helper for module proposal execution, likely in `internal/framework/proposal_generation` or a narrow `internal/modules/modulekit` package.
|
||||
- Keep domain-specific prompt IDs and prompt text local to each module.
|
||||
- Move transcript section prompt payload construction into a shared prompt-context helper, for example `promptcontext.MarshalTranscriptSection`.
|
||||
- Provide one helper for prompt metadata maps instead of manually expanding `prompt_id`, `prompt_version`, `prompt_source`, `embedded_path`, and `sha256` in every module.
|
||||
- Preserve current module `Key`, replacement policy, and validator chain ownership.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- Keep one golden or table-driven prompt payload test per module for domain-specific wording.
|
||||
- Add shared tests for transcript section JSON shape, empty transcript handling, categories copy behavior, and prompt metadata fields.
|
||||
- Add a parity test that all four module `Propose` methods still write diagnostics under the same module instance directory and produce the same correction mapping.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Low to medium. The behavior is highly duplicated, but prompt and diagnostics behavior is sensitive. Refactor behind existing module tests and CLI parity fixtures.
|
||||
|
||||
### 3.2 Effective config loading is repeated between commands
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/cli/run.go`
|
||||
- `internal/core/config`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- `runProcess` and `runConfigPrintEffective` both resolve config path, start from defaults, optionally load/apply file config, then apply environment overrides.
|
||||
- `runConfigValidate` separately loads a file, applies it to defaults, and validates it.
|
||||
- Path source metadata is computed in `internal/cli`, not `internal/core/config`, even though the precedence contract is documented as config behavior.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Config precedence is part of the public contract. If a future setting is added, three command paths may need coordinated updates.
|
||||
- `config print-effective` is the user-visible diagnostic for effective config. It should use the same loader as `process`, except for intentionally omitted CLI overrides.
|
||||
- The current code is understandable, but the behavior is repeated in a way that makes drift likely as config grows.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Add a narrow effective-config loader in `internal/core/config`, returning `Config`, source path, source type, and version metadata.
|
||||
- Keep command-specific CLI flag parsing in `internal/cli`.
|
||||
- Model the intentional differences explicitly:
|
||||
- `process`: defaults + file + env + CLI overrides
|
||||
- `config print-effective`: defaults + file + env
|
||||
- `config validate`: file schema + default-backed config validation, no env
|
||||
- Move `resolveConfigPath` or an equivalent path resolver into `internal/core/config`.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- One table-driven config loader test covering explicit `--config`, `AUDITA_CONFIG`, default search paths, missing explicit paths, and missing default paths.
|
||||
- CLI tests asserting `process` and `print-effective` share file+env behavior.
|
||||
- A regression test that `config validate` remains file-only and does not read environment overrides.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Low. Behavior is already explicit and well tested; the refactor can be done by moving code without changing precedence.
|
||||
|
||||
### 3.3 Module catalog validation is split across config, contracts, and module factory
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/core/config/validation.go`
|
||||
- `internal/framework/contracts/contracts.go`
|
||||
- `internal/framework/modules/registry.go`
|
||||
- `internal/validators/chains.go`
|
||||
- `internal/framework/validators/models.go`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- Module keys appear in multiple places:
|
||||
- config default CSV: `glossary,homophones,glossary,spoken_word,grammar`
|
||||
- module factory constants and known-key map
|
||||
- built-in validator chains
|
||||
- confidence threshold lookup
|
||||
- individual module `Key()` methods
|
||||
- `Config.Validate` checks only that module names are non-empty. An unsupported configured module can pass `audita config validate` and fail later in `process` runner setup.
|
||||
- `contracts.ResolveModuleRunSpecs` only assigns instance names; it does not validate production module support.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- `audita config validate` is documented as a CI/preflight command. Letting unsupported modules pass weakens that preflight.
|
||||
- Module key drift could affect thresholds, validator chains, reports, and unsupported-module errors.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Introduce a small canonical module catalog or key package that can be imported by config validation, module factory construction, validator chain resolution, and threshold lookup without creating a cycle.
|
||||
- Keep module construction in `internal/framework/modules`; the catalog should expose keys and validation only.
|
||||
- Make `Config.Validate` reject unknown built-in module keys through that catalog.
|
||||
- Keep repeated module instances valid.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- `internal/core/config` test: unknown `pipeline.modules` fails validation.
|
||||
- `internal/cli` test: `audita config validate --config` rejects an unsupported module before runtime.
|
||||
- Existing `internal/framework/modules` unknown-module tests should continue to pass.
|
||||
- Validator chain tests should assert every catalog module has a built-in chain.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Medium. This tightens validation behavior. It is desirable before 1.0, but if unknown modules were intentionally allowed for future extension, document that explicitly instead.
|
||||
|
||||
### 3.4 Output schema support is hardcoded in config validation and registry
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/core/config/validation.go`
|
||||
- `internal/core/outputschema/registry.go`
|
||||
- `docs/architecture/output-schemas.md`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- `Config.Validate` hardcodes `bare-segments` and `audita-v1`.
|
||||
- `outputschema.Resolve` owns the actual output schema registry and returns the runtime error for unsupported schema names.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Adding or deferring a schema requires updating multiple places.
|
||||
- Public behavior could drift: a schema might validate in config but fail at output time, or vice versa.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Make `internal/core/outputschema` expose `IsSupported`, `SupportedKeys`, or a validation function.
|
||||
- Have config validation call that helper or consume shared constants.
|
||||
- Keep actual encoding logic in `outputschema`; config should not know encoder details.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- Config validation test for every output schema returned by the registry.
|
||||
- Output schema registry test that unsupported `seriatim-intermediate` still fails clearly until implemented.
|
||||
- CLI test that unsupported `--output-schema` fails before output write.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Low. This is a straightforward catalog centralization.
|
||||
|
||||
### 3.5 Diagnostics artifact names and report metadata paths are repeated
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/core/diagnostics/run_dir.go`
|
||||
- `internal/cli/run.go`
|
||||
- `internal/core/reporting/report.go`
|
||||
- docs under `docs/architecture` and `docs/integration`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- Artifact filenames such as `source-transcript.json`, `source-transcript-parsed.json`, `normalized-transcript.json`, `normalization-summary.json`, `chunking-summary.json`, `utilization-diagnostics.json`, `correction-ledger.json`, `invocation.json`, `effective-config.json`, `report.json`, and `error.log` are repeated between run-directory writers and `buildProcessReport`.
|
||||
- `runProcess` writes `utilization-diagnostics.json` and `correction-ledger.json` by raw string on both success and failure paths.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- These names are part of the documented diagnostics contract.
|
||||
- A filename change would need to be made in multiple places, and report metadata could point at files that are no longer written.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Define diagnostics artifact name constants in `internal/core/diagnostics`.
|
||||
- Add a helper that returns `reporting.DiagnosticsMetadata` for a run directory and status.
|
||||
- Add named methods for utilization diagnostics and correction ledger writes, or at least constants used by `WriteJSONArtifact`.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- Unit test that `diagnostics.MetadataForRunDirectory` matches files written by `RunDirectory`.
|
||||
- CLI success/failure tests should continue to assert report metadata paths and actual file existence.
|
||||
- Add a test for failure report metadata including `error.log`.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Low. This is mostly string centralization, with high public-contract value.
|
||||
|
||||
### 3.6 Validator execution class is duplicated and partially hardcoded
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/validators/registry.go`
|
||||
- `internal/validators/metadata/metadata.go`
|
||||
- `internal/validators/*/validator.go`
|
||||
- `internal/framework/runner/runner.go`
|
||||
- `internal/cli/review_artifacts.go`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- Validator constructors wrap validators with execution class metadata.
|
||||
- `BuiltInValidatorDefinition` also has an `LLMBacked` field.
|
||||
- Runner uses `metadata.ClassOf` to order deterministic validators before LLM-backed validators.
|
||||
- Correction ledger classification uses a local hardcoded map of LLM-backed validator names.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Adding a new LLM-backed validator could be ordered correctly by runner metadata but appear in the wrong correction-ledger section.
|
||||
- Validator class is domain metadata, not report-building policy. It should have one source of truth.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Make validator classification resolvable by validator instance or stable key from a single metadata source.
|
||||
- Remove the unused or redundant `LLMBacked` field, or make it the canonical source used by constructors, runner ordering, and ledger formatting.
|
||||
- Replace the local ledger map with `metadata.ClassOf` when possible, or a registry lookup by stable key.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- Correction ledger test that LLM-backed decisions are classified from validator metadata, not a local string map.
|
||||
- Registry test that every registered LLM-backed validator reports the same class through every public metadata path.
|
||||
- Runner ordering test should remain in place.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Low to medium. The implementation is small, but correction-ledger shape is diagnostics-visible.
|
||||
|
||||
### 3.7 Malformed structured-output classification is duplicated
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/framework/proposal_generation/generate.go`
|
||||
- `internal/framework/validators/llm_validators.go`
|
||||
- `internal/framework/llm/openai_compatible_client.go`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- Proposal generation and LLM validators both classify malformed structured-output errors by scanning error message substrings.
|
||||
- The marker lists are currently the same, but they are maintained independently.
|
||||
- The actual errors originate in the LLM adapter.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Proposal-generation malformed payloads become warnings with zero proposals, while validator malformed payloads reject affected batches with warnings. If classifiers drift, similar adapter failures could be downgraded in one workflow and hard-fail in another.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Prefer a typed error or exported classifier from `internal/framework/llm`.
|
||||
- If typed errors are too invasive, create one shared classifier function in a lower framework package used by both proposal generation and validators.
|
||||
- Preserve the different handling semantics at each call site.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- Shared classifier table for all adapter malformed-output errors.
|
||||
- Proposal-generation test and validator test should assert the same representative malformed adapter errors are downgraded.
|
||||
- Adapter tests should assert typed/classified errors wrap useful context and still redact secrets.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Medium. Error typing can accidentally affect retry and wrapping behavior; do this with focused tests.
|
||||
|
||||
## 4. Medium-confidence opportunities
|
||||
|
||||
### 4.1 CLI flag registration and override extraction are large and repetitive
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/cli/run.go`
|
||||
- `internal/core/config/flags.go`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- Each process flag has a field in `processFlags`, a registration entry in `newProcessFlagSet`, a case in `fs.Visit`, and an assignment in `config.ApplyCLIOverrides`.
|
||||
- File config and environment config also set many of the same effective config fields.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Adding a new config option requires multiple edits. Missing one edit could create a flag that displays but does not override, or a config field with no CLI override.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Avoid a generic reflection-heavy flag system before 1.0.
|
||||
- Consider a small metadata table only for simple scalar flags, or a focused helper that maps visited flags to `CLIOverrides`.
|
||||
- Keep nontrivial semantics, such as legacy concurrency alias precedence, explicit in code.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- CLI override parity test for every stable flag that mutates config.
|
||||
- A test that default flag values reflect file+env effective config before CLI overrides.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Medium. A broad flag abstraction would be riskier than the current duplication. Do only a small helper if it clearly reduces missed updates.
|
||||
|
||||
### 4.2 Config source application repeats field-level assignments
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/core/config/file_config.go`
|
||||
- `internal/core/config/env.go`
|
||||
- `internal/core/config/flags.go`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- The same effective fields are assigned from file config, env vars, and CLI overrides.
|
||||
- Some semantics differ intentionally: file config supports `api_key_env`, env supports `OPENROUTER_API_KEY` fallback, CLI uses direct values.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Field additions are easy to miss in one source.
|
||||
- Error messages and trimming behavior can drift.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Do not force all config sources through one generic mapper.
|
||||
- Add small setter helpers for repeated config subdomains such as LLM target, concurrency, thresholds, normalization, and diagnostics.
|
||||
- Keep source-specific parsing and error labels local.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- Cross-source table proving file, env, and CLI all reach the same effective fields where they are meant to.
|
||||
- Tests for intentional differences: API key env resolution, `OPENROUTER_API_KEY` fallback, CLI direct API key, and transcript description trimming.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Medium. Useful, but only after the effective loader and catalog cleanup.
|
||||
|
||||
### 4.3 Prompt metadata and response schema metadata map construction repeats
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/modules/*/module.go`
|
||||
- `internal/framework/proposal_generation/generate.go`
|
||||
- `internal/framework/validators/llm_validators.go`
|
||||
- `internal/prompts`
|
||||
- `internal/framework/responseschema`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- Prompt metadata maps are manually expanded in module proposal generation and validator diagnostics.
|
||||
- Response schema metadata maps are built independently in proposal generation and validator diagnostics.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Metadata fields are diagnostics-visible and useful for reproducibility.
|
||||
- Adding a metadata field requires updating multiple call sites.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Add `Metadata.Map()` or a typed diagnostics metadata struct in `internal/prompts`.
|
||||
- Add `responseschema.Metadata()` or a method returning a stable diagnostics shape.
|
||||
- Prefer typed structs over `map[string]any` where possible.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- Prompt metadata rendering test should assert all registered prompts expose stable metadata.
|
||||
- Proposal and validator diagnostics tests should assert the shared metadata helper is used.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Low.
|
||||
|
||||
### 4.4 Secret redaction logic is split across config, LLM diagnostics, and adapter errors
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/core/config/redaction.go`
|
||||
- `internal/framework/llm/diagnostics.go`
|
||||
- `internal/framework/llm/client_common.go`
|
||||
- `internal/framework/proposal_generation/generate.go`
|
||||
- `internal/framework/runner/runner.go`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- Config redaction replaces non-empty API keys with `[REDACTED]`.
|
||||
- LLM diagnostics replace configured secret values and `Bearer <secret>`.
|
||||
- Adapter error sanitization separately replaces secrets and bearer values.
|
||||
- Proposal and validator paths separately assemble secret lists.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Secret redaction is a public guarantee.
|
||||
- New secret-bearing config fields could be missed in one path.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Add a small redaction helper package or keep it in `internal/framework/llm` only if it remains LLM-specific.
|
||||
- Centralize `[]string` secret extraction from `config.Config`.
|
||||
- Keep config structural redaction separate from byte/string payload redaction, but share the redaction token and value replacement behavior.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- One test that a proposal-generation error, validator diagnostic artifact, effective config artifact, and surfaced provider error all redact the same configured secrets.
|
||||
- Existing subprocess no-secret-leak test should remain as an end-to-end guard.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Medium. The current coverage appears strong; change carefully.
|
||||
|
||||
### 4.5 Test fakes and fixture helpers are duplicated across packages
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/modules/*/module_test.go`
|
||||
- `internal/framework/proposal_generation/generate_test.go`
|
||||
- `internal/framework/validators/llm_validators_test.go`
|
||||
- `internal/cli/run_test.go`
|
||||
- `cmd/audita/main_integration_test.go`
|
||||
- `internal/cli/release_fixtures_test.go`
|
||||
- `internal/cli/parity_test.go`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- Several packages define fake structured LLM clients, fixture path helpers, read/write helpers, diagnostics glob assertions, and run-directory helpers.
|
||||
- The four module test files have particularly similar fake clients and proposal-diagnostics assertions.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Refactors in LLM or diagnostics behavior require updating many tests.
|
||||
- Some duplicated tests are valuable because they preserve per-module public behavior; the issue is helper duplication, not coverage volume.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Add package-local helper files where duplication is within a package.
|
||||
- For cross-package fakes, prefer a small internal test support package only if it does not create import cycles or hide test intent.
|
||||
- Keep module-specific assertions local.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- This is test infrastructure cleanup. Existing tests should remain semantically equivalent.
|
||||
- Add helper tests only if helpers contain nontrivial behavior, such as fake response sequencing.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Low.
|
||||
|
||||
### 4.6 Stage-name construction is inconsistent enough to centralize, but not enough to redesign
|
||||
|
||||
Affected files/packages:
|
||||
|
||||
- `internal/modules/*/module.go`
|
||||
- `internal/framework/proposal_generation/generate.go`
|
||||
- `internal/framework/validators/llm_validators.go`
|
||||
- `internal/framework/runner/observability.go`
|
||||
|
||||
Duplicated or near-duplicated behavior:
|
||||
|
||||
- Modules pass stage names like `<module_instance>:proposal:section-0001`.
|
||||
- `proposal_generation` has a default builder using `<module_instance>:proposal-generation:section-0001`, but production modules bypass it.
|
||||
- Validators build `<module_instance>:<validator>:batch-0001`.
|
||||
- Utilization extracts module instance by splitting stage names on `:`.
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Stage names affect diagnostics filenames and observability grouping.
|
||||
- Current behavior works, but the naming grammar is implicit.
|
||||
|
||||
Recommended refactor:
|
||||
|
||||
- Add narrow helpers for proposal and validator stage names.
|
||||
- Preserve current production stage names unless there is a deliberate pre-1.0 diagnostics compatibility decision.
|
||||
- Keep filename sanitization in `internal/framework/llm`.
|
||||
|
||||
Suggested tests:
|
||||
|
||||
- Unit tests for stage-name helper output.
|
||||
- Utilization test that module instance extraction still works for proposal and validator stage names.
|
||||
|
||||
Risk level:
|
||||
|
||||
- Medium. Renaming stages can change diagnostics filenames, so avoid unnecessary churn.
|
||||
|
||||
## 5. Boundary and responsibility concerns
|
||||
|
||||
### CLI owns too much report and diagnostics metadata assembly
|
||||
|
||||
`internal/cli/run.go` is doing orchestration, command parsing, config loading, output routing, report assembly, diagnostics metadata path assembly, and correction-ledger construction. This is acceptable for a small CLI, but two pieces are drifting beyond command responsibility:
|
||||
|
||||
- diagnostics artifact path metadata belongs closer to `internal/core/diagnostics`;
|
||||
- report assembly and correction-ledger mapping belong closer to `internal/core/reporting` or a narrow reporting adapter package.
|
||||
|
||||
Recommended home:
|
||||
|
||||
- `internal/core/diagnostics`: artifact constants and diagnostics metadata path construction.
|
||||
- `internal/core/reporting`: pure mapping from runner/config/diagnostics state into report payloads.
|
||||
- `internal/cli`: command parsing, invocation wiring, exit codes, stdout/stderr behavior.
|
||||
|
||||
### Config validation lacks catalog ownership
|
||||
|
||||
`internal/core/config` currently validates only generic module list shape and hardcodes output schema keys. Because modules and output schemas are public contract values, config validation should use a catalog owned by the relevant domain.
|
||||
|
||||
Recommended home:
|
||||
|
||||
- output schema validation: `internal/core/outputschema`;
|
||||
- module key validation: a small catalog package or lower-level constants package importable by config, module factory, validator chains, and threshold lookup.
|
||||
|
||||
### Runner owns adapter shims between contracts and validator framework
|
||||
|
||||
`internal/framework/runner` contains `validationLLMClientAdapter` and `llmDiagnosticsWriterAdapter`. This is not a serious problem today because runner wires proposal and validation workflows. If these adapters grow, move them to `internal/framework/validators` or a small integration package so runner remains focused on orchestration.
|
||||
|
||||
### LLM malformed-output policy is spread across callers
|
||||
|
||||
The LLM adapter emits the errors, while proposal generation and validators classify them by message text. The policy decision is caller-specific, but the classification should live with the LLM/framework error type.
|
||||
|
||||
## 6. Path, key, and naming construction review
|
||||
|
||||
Centralized enough:
|
||||
|
||||
- LLM diagnostics artifact suffixes and stage sanitization are centralized in `internal/framework/llm/diagnostics.go`.
|
||||
- Output file writing is routed through `internal/core/io.WriteFile`.
|
||||
- Run directories are created in `internal/core/diagnostics.NewRunDirectory`.
|
||||
|
||||
Needs cleanup:
|
||||
|
||||
- Core diagnostics artifact names are repeated between `RunDirectory` writer methods and `buildProcessReport`.
|
||||
- `utilization-diagnostics.json` and `correction-ledger.json` are raw strings in both success and failure paths.
|
||||
- Proposal and validator diagnostics subdirectory construction repeats `filepath.Join(diagnosticsDir, moduleInstance)`.
|
||||
- Proposal and validator stage names are manually formatted in multiple packages.
|
||||
- Module keys are repeated across config defaults, module factory, validator chains, confidence threshold lookup, and module implementations.
|
||||
- Output schema names are repeated between config validation and `outputschema`.
|
||||
|
||||
Recommendation:
|
||||
|
||||
- Start with artifact constants and metadata helpers because that is the lowest-risk path/key cleanup.
|
||||
- Then centralize stage-name helpers without changing current production naming.
|
||||
- Defer any broader "path manager" abstraction.
|
||||
|
||||
## 7. Resolution and catalog review
|
||||
|
||||
Modules:
|
||||
|
||||
- Runtime module construction has a production registry in `internal/framework/modules`.
|
||||
- Instance naming for repeated modules is centralized in `contracts.ResolveModuleRunSpecs`.
|
||||
- Unknown module failure exists in the factory, but config validation does not catch unknown modules.
|
||||
- Built-in validator chain resolution separately maps module key to validator keys.
|
||||
|
||||
Output schemas:
|
||||
|
||||
- Encoding is centralized in `internal/core/outputschema`.
|
||||
- Validation is duplicated in config.
|
||||
|
||||
Prompts:
|
||||
|
||||
- Prompt asset lookup and metadata are centralized in `internal/prompts`.
|
||||
- Prompt metadata map construction is repeated at call sites.
|
||||
- Prompt source selection is intentionally built-in only and should remain that way for 1.0.
|
||||
|
||||
Validators:
|
||||
|
||||
- Validator construction is package-owned under `internal/validators`.
|
||||
- Chains are centralized in `internal/validators/chains.go`.
|
||||
- Execution class metadata exists, but reporting/correction-ledger classification does not fully use it.
|
||||
|
||||
Schemas:
|
||||
|
||||
- Transcript and glossary parsing/validation are centralized in `internal/core/schema`.
|
||||
- Structured LLM response schemas are centralized in `internal/framework/responseschema`.
|
||||
- Output schema registry and response schema registry are appropriately separate.
|
||||
|
||||
Recommendation:
|
||||
|
||||
- Introduce only small catalog helpers for module keys, output schema keys, prompt metadata maps, response schema metadata maps, and validator execution class.
|
||||
- Avoid user-configurable modules, validators, prompts, or schemas before 1.0 unless already planned elsewhere.
|
||||
|
||||
## 8. Config and command-loading review
|
||||
|
||||
Consistent behavior:
|
||||
|
||||
- The documented precedence for `process` is implemented: defaults, file config, environment, CLI.
|
||||
- `config print-effective` intentionally omits CLI process flags and uses defaults, file config, and environment.
|
||||
- `config validate` intentionally requires `--config` and does not require transcript/glossary inputs.
|
||||
- Missing explicit config paths are hard failures; missing default paths are non-fatal.
|
||||
- Environment parsing and CLI parsing both preserve legacy total-concurrency alias behavior.
|
||||
|
||||
Likely accidental or high-risk differences:
|
||||
|
||||
- Unsupported module names pass `Config.Validate` and `audita config validate`.
|
||||
- Output schema support is duplicated instead of delegated to the output schema registry.
|
||||
- Config path resolution lives in CLI even though it is part of config behavior.
|
||||
|
||||
Intentional differences:
|
||||
|
||||
- File config resolves `api_key_env`; env and CLI set direct API key values.
|
||||
- `OPENROUTER_API_KEY` is an environment fallback only for the primary LLM.
|
||||
- `transcript-description` has CLI/config support but no `AUDITA_*` environment variable, matching documentation.
|
||||
|
||||
Recommendation:
|
||||
|
||||
- Build a shared effective config context helper and keep source-specific parsing semantics explicit.
|
||||
- Tighten catalog validation before 1.0 if unknown modules are not meant to be accepted.
|
||||
|
||||
## 9. State, manifest, or progress handling review
|
||||
|
||||
Audita does not currently have a manifest/checkpoint/resume model. State is per-run diagnostics and report artifacts.
|
||||
|
||||
Consistent behavior:
|
||||
|
||||
- `process` creates one diagnostics run directory when diagnostics initialization succeeds.
|
||||
- Failures after run-dir creation write `error.log`, best-effort report artifacts, and retain diagnostics.
|
||||
- Success writes optional `--report-json`, run-dir `report.json`, utilization diagnostics, and correction ledger.
|
||||
- Retention is centralized in `diagnostics.ShouldRetainRunDirectory`.
|
||||
- There is no resume/retry/force behavior to preserve.
|
||||
|
||||
Drift risks:
|
||||
|
||||
- Success and failure paths both write utilization and correction-ledger artifacts with duplicated raw filenames.
|
||||
- Report diagnostics metadata is assembled independently from the run-directory writer methods.
|
||||
- Retention mode `never` currently still retains successful run directories in `ShouldRetainRunDirectory`, which may be intentional per tests or a naming/documentation mismatch. Do not change it in a dedup pass without first confirming semantics.
|
||||
|
||||
Recommendation:
|
||||
|
||||
- Centralize artifact names and report metadata path construction.
|
||||
- Keep retention behavior unchanged unless a separate bug review confirms the intended meaning of `never`.
|
||||
|
||||
## 10. Refactors to avoid before 1.0
|
||||
|
||||
- Do not introduce a generic workflow engine. The current sequential runner is clear and explicit.
|
||||
- Do not add a plugin architecture for modules, validators, prompts, or schemas before 1.0.
|
||||
- Do not redesign the CLI or replace `flag` with a larger framework only for deduplication.
|
||||
- Do not collapse all config source parsing into a reflection-based mapper; source semantics differ intentionally.
|
||||
- Do not merge module packages into one generic module type. Keep domain-specific prompt assets, keys, validator chains, and replacement policies visible.
|
||||
- Do not rewrite diagnostics or reporting schemas broadly. Centralize names and mapping helpers first.
|
||||
- Do not change diagnostics stage names casually; they affect artifact filenames and debugging workflows.
|
||||
- Do not consolidate deterministic and LLM validator behavior just because both return decisions. Their failure and batching semantics differ.
|
||||
- Do not generalize transcript/glossary schema parsing into a broad schema framework.
|
||||
- Do not reduce duplicated tests where the duplication protects distinct public command/module behavior.
|
||||
|
||||
## 11. Recommended implementation sequence
|
||||
|
||||
1. Centralize diagnostics artifact constants and diagnostics metadata path construction.
|
||||
2. Centralize output schema validation through `internal/core/outputschema`.
|
||||
3. Introduce a small module key catalog and use it in config validation, module factory, validator chains, and threshold lookup.
|
||||
4. Add an effective config loading context helper for defaults + file + env, then update `process` and `config print-effective`.
|
||||
5. Extract shared module proposal plumbing and prompt transcript-section payload construction.
|
||||
6. Centralize prompt metadata and response schema metadata map construction.
|
||||
7. Centralize validator execution-class lookup and update correction-ledger classification.
|
||||
8. Centralize malformed structured-output classification through a typed/shared LLM error helper.
|
||||
9. Add or consolidate focused test helpers for module LLM fakes, diagnostics assertions, and fixture paths.
|
||||
10. Do a final dead-code and legacy sweep for redundant helper fields such as unused validator definition metadata.
|
||||
|
||||
Each item can be a separate commit with package-level tests and at least one CLI regression where public behavior is involved.
|
||||
|
||||
## 12. Test strategy
|
||||
|
||||
Tests to add before refactoring:
|
||||
|
||||
- `internal/core/config`: unknown module key fails validation, if unsupported modules are not intended to be accepted.
|
||||
- `internal/core/config`: every output schema registry key validates through config.
|
||||
- `internal/core/diagnostics`: report metadata paths match run-directory artifact names.
|
||||
- `internal/validators`: validator class by key/instance is consistent for all registered validators.
|
||||
- `internal/framework/llm`: shared malformed structured-output classifier covers all current adapter malformed errors.
|
||||
|
||||
Tests to add during refactoring:
|
||||
|
||||
- `internal/framework/promptcontext`: transcript section prompt payload preserves IDs, speaker, timestamps, text, and categories.
|
||||
- `internal/framework/proposal_generation`: shared module proposal helper preserves current stage name, diagnostics dir, schema metadata, and malformed-output warning behavior.
|
||||
- `internal/cli`: `process` and `config print-effective` share defaults+file+env behavior.
|
||||
- `internal/cli`: `config validate` remains file-only and does not read env overrides.
|
||||
- `internal/cli`: correction ledger classifies deterministic and LLM validator decisions through canonical metadata.
|
||||
|
||||
Existing tests to run after each cleanup:
|
||||
|
||||
- `go test ./internal/core/config ./internal/core/outputschema`
|
||||
- `go test ./internal/core/diagnostics ./internal/core/reporting`
|
||||
- `go test ./internal/framework/proposal_generation ./internal/framework/validators ./internal/framework/runner`
|
||||
- `go test ./internal/validators/...`
|
||||
- `go test ./internal/modules/...`
|
||||
- `go test ./internal/cli ./cmd/audita`
|
||||
- Run `go test ./...` before merging a multi-package cleanup.
|
||||
|
||||
Validation note:
|
||||
|
||||
- During this report-only pass, no full test suite was run. A lightweight `go list ./...` completed package listing but emitted a sandbox warning while trying to write the Go module stat cache outside the repository.
|
||||
|
||||
## 13. Appendix: findings not worth acting on
|
||||
|
||||
### Separate module packages
|
||||
|
||||
The four production module packages contain visible repetition, but keeping separate packages is useful. The module domains, prompt assets, validator chains, and tests are distinct enough that a single generic module package would hide important behavior.
|
||||
|
||||
Do not refactor now beyond shared proposal/prompt plumbing.
|
||||
|
||||
### Report type duplication between runner and reporting
|
||||
|
||||
`runner.ModuleResult` and `reporting.ModuleReport` look similar. Keeping separate runtime and public report shapes is reasonable because runner owns execution state and reporting owns serialized public schema.
|
||||
|
||||
Only centralize mapping helpers; do not merge the types.
|
||||
|
||||
### Transcript and glossary parsing stay separate
|
||||
|
||||
Transcript JSON and glossary YAML parsing have different formats, validation rules, and error messages. There is no useful shared parser abstraction to extract.
|
||||
|
||||
### Response schema registry and output schema registry stay separate
|
||||
|
||||
Structured LLM response schemas and transcript output schemas are both "schemas", but they serve different users and have different lifecycles. Do not combine their registries.
|
||||
|
||||
### `flag` package usage
|
||||
|
||||
The CLI command surface is small. Replacing `flag` with a larger CLI framework would not pay for itself before 1.0.
|
||||
|
||||
### Local test duplication that protects public behavior
|
||||
|
||||
Some test duplication in CLI, subprocess, parity, and release fixtures is intentional. These tests exercise different public surfaces and should remain explicit even if helpers are shared.
|
||||
|
||||
### Filesystem state as diagnostics state
|
||||
|
||||
Audita has no resume/checkpoint semantics. Treating diagnostics artifacts as filesystem outputs is currently acceptable. A manifest system would be speculative before there is a resume or audit workflow that needs it.
|
||||
577
docs/roadmap/documentation.md
Normal file
577
docs/roadmap/documentation.md
Normal file
@@ -0,0 +1,577 @@
|
||||
# Documentation Roadmap
|
||||
|
||||
## Purpose
|
||||
|
||||
This roadmap defines the work required to bring Audita documentation into compliance with `docs/policy/documentation.md` and the implemented architecture described by `docs/policy/architecture.md`.
|
||||
|
||||
This is an implementation plan for future documentation cleanup. It does not rewrite the main documentation. Future implementation passes should document only current behavior outside `docs/roadmap/`, keep planned or unimplemented work in roadmap files, and verify claims against repository code and tests rather than stale documentation.
|
||||
|
||||
## Repository Documentation Inventory
|
||||
|
||||
- `README.md`: keep and rewrite. It should remain the project orientation and quickstart, but it currently carries too much reference material and includes stale links such as `docs/diagnostics.md`, `docs/structured-llm.md`, and `docs/subprocess-operations.md`.
|
||||
- `docs/policy/documentation.md`: keep and lightly update only if needed. It is the canonical documentation policy.
|
||||
- `docs/policy/architecture.md`: keep and lightly verify after the migration. It is the canonical architecture policy for developers and coding agents.
|
||||
- `docs/development.md`: move and rewrite as `docs/policy/development.md`. Contributor workflow belongs under `docs/policy/`.
|
||||
- `docs/configuration.md`: move and rewrite as `docs/config.md`. Configuration reference belongs at the canonical config path.
|
||||
- `docs/architecture.md`: merge or delete after the internal docs are created. Its useful content should become an internal overview or links to canonical internal docs.
|
||||
- `docs/architecture/architecture.md`: split and rewrite into `docs/internal/overview.md` and `docs/internal/pipeline.md`.
|
||||
- `docs/architecture/public-contract.md`: split across `docs/cli.md`, `docs/config.md`, `docs/operations.md`, and integration docs where applicable.
|
||||
- `docs/architecture/diagnostics.md`: split across `docs/operations.md` and `docs/internal/diagnostics-reporting.md`.
|
||||
- `docs/architecture/structured-llm.md`: split across `docs/internal/llm-runtime.md` and `docs/integrations/openai-compatible-llm.md`.
|
||||
- `docs/architecture/validators.md`: move and rewrite as `docs/internal/validators.md`.
|
||||
- `docs/architecture/prompts.md`: move and rewrite as `docs/internal/prompts.md`; remove deferred and unimplemented prompt override material.
|
||||
- `docs/architecture/output-schemas.md`: move and rewrite as `docs/internal/output-schemas.md`; remove deferred or unimplemented schema material such as `seriatim-intermediate`.
|
||||
- `docs/documentation/policy.md`: merge/delete in favor of `docs/policy/documentation.md`. It duplicates policy material in a noncanonical location.
|
||||
- `docs/integration/subprocess-operations.md`: move and rewrite as `docs/integrations/subprocess.md`.
|
||||
- `docs/release-checklist.md`: merge current-behavior checks into `docs/policy/development.md` or move to a clearer policy/internal location; remove pre-release or deferred-feature guardrail language from non-roadmap docs.
|
||||
- `docs/roadmap/audit.md`: currently deleted in the worktree. Treat this as unrelated state unless a later task explicitly restores or updates it.
|
||||
- `docs/roadmap/implementation.md`: currently deleted in the worktree. Treat this as unrelated state unless a later task explicitly restores or updates it.
|
||||
- `examples/`: create new. No examples directory is currently present, but policy expects copyable examples when practical.
|
||||
|
||||
## Policy Compliance Assessment
|
||||
|
||||
Required or expected canonical documents are missing:
|
||||
|
||||
- `docs/cli.md`
|
||||
- `docs/config.md`
|
||||
- `docs/operations.md`
|
||||
- `docs/internal/`
|
||||
- `docs/policy/development.md`
|
||||
- `examples/`
|
||||
|
||||
Recommended documents that should be added:
|
||||
|
||||
- `docs/troubleshooting.md`
|
||||
- `docs/integrations/openai-compatible-llm.md`
|
||||
- `docs/integrations/transcript-glossary-files.md`
|
||||
|
||||
Documents in the wrong canonical home:
|
||||
|
||||
- `docs/configuration.md` should become `docs/config.md`.
|
||||
- `docs/development.md` should become `docs/policy/development.md`.
|
||||
- `docs/integration/` should become `docs/integrations/`.
|
||||
- Implemented internal architecture content under `docs/architecture/` should move to `docs/internal/`.
|
||||
- `docs/documentation/policy.md` should merge/delete in favor of `docs/policy/documentation.md`.
|
||||
|
||||
Content that should not remain outside `docs/roadmap/`:
|
||||
|
||||
- Deferred or unimplemented output schema content in `docs/architecture/output-schemas.md`.
|
||||
- Deferred or unimplemented prompt override, generated transcript description, and report prompt ledger content in `docs/architecture/prompts.md`.
|
||||
- Pre-release or future-feature guardrail language in `docs/release-checklist.md`, unless moved to roadmap or rewritten as current contributor workflow.
|
||||
|
||||
Examples and links:
|
||||
|
||||
- `examples/` is missing.
|
||||
- README links to nonexistent documentation paths.
|
||||
- Links to `docs/configuration.md`, `docs/development.md`, and `docs/integration/` should be updated after canonical moves.
|
||||
- A repository-wide link/path check should be part of final validation.
|
||||
|
||||
## Target Documentation Set
|
||||
|
||||
### `README.md`
|
||||
|
||||
- Audience: users and operators.
|
||||
- Purpose: concise project orientation and shortest useful workflow.
|
||||
- Canonical scope: what Audita does, install/build basics, minimal command shape, and links to canonical docs.
|
||||
- Recommended outline: overview, quickstart, minimal configuration pointer, common command pointer, documentation map, development pointer.
|
||||
- Sources to inspect: `cmd/audita/main.go`, `internal/cli/run.go`, `internal/cli/process_flags.go`, README tests or CLI integration tests.
|
||||
- Acceptance criteria: no long CLI or config reference; no stale links; all linked docs exist.
|
||||
|
||||
### `docs/cli.md`
|
||||
|
||||
- Audience: users and operators.
|
||||
- Purpose: canonical CLI reference.
|
||||
- Canonical scope: commands, flags, common workflows, output destinations, stdout/stderr behavior, and exit behavior.
|
||||
- Recommended outline: command overview, `process`, `config validate`, `config print-effective`, config path selection, process outputs, examples, exit behavior.
|
||||
- Sources to inspect: `internal/cli/run.go`, `internal/cli/process_flags.go`, `cmd/audita`, CLI tests.
|
||||
- Acceptance criteria: every implemented command and flag is documented; examples match parser behavior; config details link to `docs/config.md`.
|
||||
|
||||
### `docs/config.md`
|
||||
|
||||
- Audience: administrators, operators, and advanced users.
|
||||
- Purpose: canonical configuration reference.
|
||||
- Canonical scope: config path resolution, precedence, YAML schema, environment overrides, CLI override relationship, secrets, validation.
|
||||
- Recommended outline: loading model, precedence, file schema, environment variables, CLI relationship, secrets, examples, validation.
|
||||
- Sources to inspect: `internal/core/config/*`, config tests, CLI config commands.
|
||||
- Acceptance criteria: replaces `docs/configuration.md`; documents implemented defaults and validation only; examples validate.
|
||||
|
||||
### `docs/operations.md`
|
||||
|
||||
- Audience: operators.
|
||||
- Purpose: operational behavior and recovery/debugging reference.
|
||||
- Canonical scope: run directories, diagnostics artifacts, reports, correction ledger, retention, output writes, failure inspection.
|
||||
- Recommended outline: process run lifecycle, output files, diagnostics directory, reports, retention, operational failure modes, recovery steps.
|
||||
- Sources to inspect: `internal/core/diagnostics`, `internal/framework/processreport`, `internal/cli`, reporting tests.
|
||||
- Acceptance criteria: no resume, checkpoint, or remote storage claims; operational artifacts match implemented filenames and report behavior.
|
||||
|
||||
### `docs/troubleshooting.md`
|
||||
|
||||
- Audience: users and operators.
|
||||
- Purpose: concise guide for recurring implemented failures.
|
||||
- Canonical scope: symptoms, likely causes, inspection steps, and safe fixes.
|
||||
- Recommended outline: config validation errors, transcript/glossary schema errors, LLM request errors, output/report write failures, diagnostics lookup.
|
||||
- Sources to inspect: CLI tests, config tests, schema tests, LLM tests, reporting tests.
|
||||
- Acceptance criteria: every entry maps to implemented behavior; no speculative remediation.
|
||||
|
||||
### `docs/policy/documentation.md`
|
||||
|
||||
- Audience: maintainers and coding agents.
|
||||
- Purpose: canonical documentation policy.
|
||||
- Canonical scope: documentation layout, audience boundaries, roadmap rules, maintenance rules.
|
||||
- Recommended outline: keep current structure unless policy itself needs small alignment.
|
||||
- Sources to inspect: documentation policy and final documentation tree.
|
||||
- Acceptance criteria: remains the only canonical documentation policy.
|
||||
|
||||
### `docs/policy/architecture.md`
|
||||
|
||||
- Audience: developers and coding agents.
|
||||
- Purpose: canonical architecture policy.
|
||||
- Canonical scope: development principles, boundaries, invariants, dependency policy, testing expectations.
|
||||
- Recommended outline: keep current policy; update links after docs migration only if necessary.
|
||||
- Sources to inspect: package layout and policy docs.
|
||||
- Acceptance criteria: no stale links; no duplicated CLI/config reference.
|
||||
|
||||
### `docs/policy/development.md`
|
||||
|
||||
- Audience: developers and coding agents.
|
||||
- Purpose: contributor workflow and change expectations.
|
||||
- Canonical scope: repo layout, setup, tests, conventions, adding config/CLI/module/validator/docs/examples.
|
||||
- Recommended outline: setup, repository layout, running tests, change workflow, adding features, documentation expectations, release checks.
|
||||
- Sources to inspect: `docs/development.md`, tests, `go.mod`, package layout.
|
||||
- Acceptance criteria: replaces `docs/development.md`; no future-feature roadmap content; includes practical validation commands.
|
||||
|
||||
### `docs/internal/overview.md`
|
||||
|
||||
- Audience: developers and coding agents.
|
||||
- Purpose: implemented internal architecture overview.
|
||||
- Canonical scope: core/framework/module/validator/adapter layout at a high level.
|
||||
- Recommended outline: package map, main execution path, boundary summary, where to add new code.
|
||||
- Sources to inspect: `internal/core`, `internal/framework`, `internal/modules`, `internal/validators`, `internal/cli`.
|
||||
- Acceptance criteria: concise internal entry point; links to detailed internal docs.
|
||||
|
||||
### `docs/internal/pipeline.md`
|
||||
|
||||
- Audience: developers and coding agents.
|
||||
- Purpose: implemented process pipeline.
|
||||
- Canonical scope: transcript loading, normalization, chunking, module proposal generation, validation, deterministic application, output/report handoff.
|
||||
- Recommended outline: inputs, pipeline phases, runner outputs, failure behavior, tests.
|
||||
- Sources to inspect: `internal/framework/runner`, `internal/core/normalization`, `internal/core/chunking`, CLI process tests.
|
||||
- Acceptance criteria: no unimplemented workflow engine or resume claims.
|
||||
|
||||
### `docs/internal/modules.md`
|
||||
|
||||
- Audience: developers and coding agents.
|
||||
- Purpose: module authoring and maintenance reference.
|
||||
- Canonical scope: current module packages, module contracts, proposal behavior, prompt assets.
|
||||
- Recommended outline: module contract, implemented modules, prompt ownership, proposal output, tests.
|
||||
- Sources to inspect: `internal/modules/*`, `internal/framework/contracts`, `internal/framework/proposal_generation`.
|
||||
- Acceptance criteria: keeps module packages separate; no plugin architecture claims.
|
||||
|
||||
### `docs/internal/validators.md`
|
||||
|
||||
- Audience: developers and coding agents.
|
||||
- Purpose: validator architecture reference.
|
||||
- Canonical scope: validator registry, chains, deterministic and LLM-backed validators, decision handling.
|
||||
- Recommended outline: validator contract, chain registration, classifications, batching, failure behavior, tests.
|
||||
- Sources to inspect: `internal/validators`, `internal/framework/validators`.
|
||||
- Acceptance criteria: documents composable validators without inventing new validator APIs.
|
||||
|
||||
### `docs/internal/llm-runtime.md`
|
||||
|
||||
- Audience: developers and coding agents.
|
||||
- Purpose: internal LLM runtime and scheduler reference.
|
||||
- Canonical scope: `StructuredLLMClient`, OpenAI-compatible adapter boundary, retries, redaction, scheduler permits, structured response handling.
|
||||
- Recommended outline: client interface, request/response handling, retries/timeouts, concurrency, diagnostics, tests.
|
||||
- Sources to inspect: `internal/framework/llm`, `internal/framework/responseschema`, `internal/framework/structuredoutput`.
|
||||
- Acceptance criteria: documents only implemented OpenAI-compatible HTTP behavior.
|
||||
|
||||
### `docs/internal/diagnostics-reporting.md`
|
||||
|
||||
- Audience: developers and coding agents.
|
||||
- Purpose: diagnostics, report, and correction ledger implementation reference.
|
||||
- Canonical scope: artifact names, metadata, process report mapping, correction ledger, retention interaction.
|
||||
- Recommended outline: diagnostics ownership, artifact metadata, process report builder, ledger mapping, tests.
|
||||
- Sources to inspect: `internal/core/diagnostics`, `internal/core/reporting`, `internal/framework/processreport`, CLI report tests.
|
||||
- Acceptance criteria: filenames and report fields match code; no planned artifact claims.
|
||||
|
||||
### `docs/internal/prompts.md`
|
||||
|
||||
- Audience: developers and coding agents.
|
||||
- Purpose: implemented prompt registry and prompt asset reference.
|
||||
- Canonical scope: embedded prompt assets, prompt metadata, rendering inputs, module prompt ownership.
|
||||
- Recommended outline: registry, assets, metadata, module usage, tests.
|
||||
- Sources to inspect: `internal/prompts`, `internal/framework/promptcontext`, module prompt tests.
|
||||
- Acceptance criteria: removes unimplemented filesystem overrides and deferred prompt ledger content.
|
||||
|
||||
### `docs/internal/output-schemas.md`
|
||||
|
||||
- Audience: developers and coding agents.
|
||||
- Purpose: implemented output schema registry reference.
|
||||
- Canonical scope: supported output schemas, config validation, output emission.
|
||||
- Recommended outline: registry, `bare-segments`, `audita-v1`, validation, tests.
|
||||
- Sources to inspect: `internal/core/outputschema`, `internal/core/config`, schema/output tests.
|
||||
- Acceptance criteria: documents only implemented schemas.
|
||||
|
||||
### `docs/integrations/subprocess.md`
|
||||
|
||||
- Audience: operators and external-process integrators.
|
||||
- Purpose: subprocess invocation contract.
|
||||
- Canonical scope: invoking `audita process`, stdin/stdout/stderr expectations where implemented, files, reports, exit codes.
|
||||
- Recommended outline: invocation model, outputs, diagnostics, errors, parent-process guidance.
|
||||
- Sources to inspect: `internal/cli`, subprocess-oriented docs, CLI integration tests.
|
||||
- Acceptance criteria: no non-existent streaming API or server mode.
|
||||
|
||||
### `docs/integrations/openai-compatible-llm.md`
|
||||
|
||||
- Audience: developers and operators integrating an LLM endpoint.
|
||||
- Purpose: OpenAI-compatible LLM contract.
|
||||
- Canonical scope: chat completions request behavior, JSON schema response format, retries, timeouts, redaction, configured endpoints.
|
||||
- Recommended outline: endpoint expectations, authentication, response format, retry/timeout behavior, diagnostics and redaction.
|
||||
- Sources to inspect: `internal/framework/llm`, config LLM settings, LLM tests.
|
||||
- Acceptance criteria: no provider SDK or non-OpenAI-compatible API claims.
|
||||
|
||||
### `docs/integrations/transcript-glossary-files.md`
|
||||
|
||||
- Audience: users, operators, and external systems producing input files.
|
||||
- Purpose: accepted transcript and glossary file contracts.
|
||||
- Canonical scope: implemented JSON/YAML shapes and validation behavior.
|
||||
- Recommended outline: transcript shape, glossary shape, validation errors, example files.
|
||||
- Sources to inspect: `internal/core/schema`, schema tests, CLI input tests.
|
||||
- Acceptance criteria: does not invent a formal versioned schema beyond implemented fields.
|
||||
|
||||
### `examples/`
|
||||
|
||||
- Audience: users and operators.
|
||||
- Purpose: copyable, maintained examples.
|
||||
- Canonical scope: minimal and fuller config, tiny transcript, tiny glossary.
|
||||
- Recommended files: `minimal-config.yml`, `production-config.yml`, `tiny-transcript.json`, `tiny-glossary.yaml`.
|
||||
- Sources to inspect: config defaults/tests, schema tests, CLI tests.
|
||||
- Acceptance criteria: no secrets; config examples validate; examples are linked from README, CLI, and config docs.
|
||||
|
||||
### `docs/roadmap/documentation.md`
|
||||
|
||||
- Audience: maintainers and coding agents.
|
||||
- Purpose: staged documentation migration plan.
|
||||
- Canonical scope: future documentation work only.
|
||||
- Recommended outline: this file.
|
||||
- Sources to inspect: repository docs, code, tests, documentation policy, architecture policy.
|
||||
- Acceptance criteria: remains action-oriented and does not rewrite current documentation prematurely.
|
||||
|
||||
## File-by-File Rewrite Guidance
|
||||
|
||||
### README
|
||||
|
||||
Cover project purpose, shortest useful command, build/test basics, and links to canonical docs. Avoid full CLI flag lists, full config schema, diagnostics reference, module internals, and architectural history. Link to `docs/cli.md`, `docs/config.md`, `docs/operations.md`, `docs/troubleshooting.md`, and policy docs after those files exist. Do not carry forward stale links to nonexistent `docs/diagnostics.md`, `docs/structured-llm.md`, or `docs/subprocess-operations.md`.
|
||||
|
||||
### `docs/config.md`
|
||||
|
||||
Rewrite from `docs/configuration.md`. Cover path resolution, precedence, YAML schema, env overrides, CLI override relationship, validation, and secrets. Link to `docs/cli.md` for command syntax and to examples for copyable files. Inspect `internal/core/config/*` and config tests. Avoid duplicating every CLI flag except where needed to explain precedence.
|
||||
|
||||
### `docs/cli.md`
|
||||
|
||||
Build from `internal/cli/run.go`, `internal/cli/process_flags.go`, and CLI tests. Cover `process`, `config validate`, and `config print-effective`. Include implemented output destinations and subprocess-friendly behavior. Link to `docs/config.md` for configuration details and `docs/operations.md` for diagnostics and reports. Avoid documenting unsupported command aliases or future commands.
|
||||
|
||||
### `docs/operations.md`
|
||||
|
||||
Merge operational material from diagnostics and subprocess docs. Cover run directories, diagnostics artifacts, reports, correction ledger, retention, output/report writes, and safe failure inspection. Inspect `internal/core/diagnostics`, `internal/framework/processreport`, and CLI tests. State that resume, checkpoint, and remote storage are not implemented only if needed to avoid user confusion.
|
||||
|
||||
### `docs/troubleshooting.md`
|
||||
|
||||
Create concise symptom/cause/inspect/fix entries for implemented failures. Inspect config validation tests, schema tests, LLM adapter tests, reporting tests, and CLI integration tests. Avoid broad operational advice that is not supported by the repository.
|
||||
|
||||
### `docs/policy/development.md`
|
||||
|
||||
Move and rewrite from `docs/development.md`. Cover setup, package layout, tests, conventions, and how to add config fields, CLI flags, modules, validators, docs, and examples. Merge any still-useful current-behavior release checks from `docs/release-checklist.md`. Avoid roadmap, pre-1.0 history, and deferred-feature guardrail language.
|
||||
|
||||
### `docs/internal/*`
|
||||
|
||||
Move implemented architecture details out of `docs/architecture/*`. Keep these docs concise and developer-facing. Remove deferred or unimplemented sections such as `seriatim-intermediate`, prompt overrides, generated transcript descriptions, report-level prompt ledgers, plugin systems, workflow engines, resume, and remote storage.
|
||||
|
||||
### `docs/integrations/subprocess.md`
|
||||
|
||||
Move from `docs/integration/subprocess-operations.md`. Keep stdout/stderr, file outputs, exit behavior, diagnostics/report handling, and parent-process guidance that matches current CLI behavior. Do not document non-existent streaming APIs.
|
||||
|
||||
### `docs/integrations/openai-compatible-llm.md`
|
||||
|
||||
Derive from implemented `internal/framework/llm` behavior and the current structured LLM architecture doc. Cover OpenAI-compatible chat completions, `response_format.type=json_schema`, retries, timeouts, and redaction. Do not claim support for provider SDKs or non-OpenAI-compatible APIs.
|
||||
|
||||
### `docs/integrations/transcript-glossary-files.md`
|
||||
|
||||
Create from implemented schema loading and validation. Cover the file shapes accepted by Audita and link to examples. Do not invent a formal external schema version beyond what the code validates.
|
||||
|
||||
### `docs/documentation/policy.md`
|
||||
|
||||
Delete after verifying any unique useful policy content is already in `docs/policy/documentation.md`. Do not keep two documentation policy homes.
|
||||
|
||||
### `docs/release-checklist.md`
|
||||
|
||||
Either merge current-behavior contributor checks into `docs/policy/development.md` or move a concise checklist to a clearer policy/internal location. Remove future-feature or deferred-work guardrails from non-roadmap documentation.
|
||||
|
||||
## Examples Plan
|
||||
|
||||
Create maintained, non-secret examples only for implemented behavior.
|
||||
|
||||
### `examples/minimal-config.yml`
|
||||
|
||||
- Purpose: smallest useful config with `version: 1`, output schema, and `api_key_env`.
|
||||
- Expected validity check: `go run ./cmd/audita config validate --config examples/minimal-config.yml`.
|
||||
- Link from: `README.md`, `docs/config.md`, `docs/cli.md`.
|
||||
|
||||
### `examples/production-config.yml`
|
||||
|
||||
- Purpose: fuller config showing modules, LLMs, concurrency, chunking, normalization, thresholds, context, and diagnostics.
|
||||
- Expected validity check: `go run ./cmd/audita config validate --config examples/production-config.yml`.
|
||||
- Link from: `docs/config.md`.
|
||||
|
||||
### `examples/tiny-transcript.json`
|
||||
|
||||
- Purpose: small copyable transcript input for CLI examples and schema documentation.
|
||||
- Expected validity check: schema tests or a no-live-LLM CLI parser path if practical.
|
||||
- Link from: `README.md`, `docs/cli.md`, `docs/integrations/transcript-glossary-files.md`.
|
||||
|
||||
### `examples/tiny-glossary.yaml`
|
||||
|
||||
- Purpose: small copyable glossary input for CLI examples.
|
||||
- Expected validity check: schema tests or a no-live-LLM CLI parser path if practical.
|
||||
- Link from: `README.md`, `docs/cli.md`, `docs/integrations/transcript-glossary-files.md`.
|
||||
|
||||
Do not add examples for resume, remote storage, prompt overrides, plugin systems, UI/server mode, unsupported output schemas, or other unimplemented behavior.
|
||||
|
||||
## Internal Documentation Plan
|
||||
|
||||
### Pipeline
|
||||
|
||||
- Path: `docs/internal/pipeline.md`
|
||||
- Purpose: document the implemented transcript processing pipeline.
|
||||
- Inputs and outputs: normalized transcript, sections, configured module specs, proposal results, validation results, runner output.
|
||||
- Boundaries: runner orchestrates; modules propose; validators filter; accepted proposals are applied deterministically.
|
||||
- Config fields used: modules, output schema, chunking, normalization, thresholds, concurrency, context, diagnostics.
|
||||
- Adapters used: LLM client through framework contracts; filesystem/reporting through CLI and diagnostics boundaries.
|
||||
- Failure behavior: module and validator warnings, rejected proposals, run/report error status.
|
||||
- Tests to inspect: runner tests, proposal generation tests, CLI parity and release fixture tests.
|
||||
- Architectural invariants: keep nondeterministic LLM effects isolated from deterministic transcript state handling.
|
||||
|
||||
### Modules
|
||||
|
||||
- Path: `docs/internal/modules.md`
|
||||
- Purpose: document implemented correction modules and their contracts.
|
||||
- Inputs and outputs: `contracts.ProposalRequest`, module proposals, warnings, replacement policies.
|
||||
- Boundaries: one package per module; prompt assets remain module-specific; shared framework plumbing stays outside module packages.
|
||||
- Config fields used: configured module keys, LLM settings, chunking/context where applicable.
|
||||
- Adapters used: LLM client only through contracts and proposal generation framework.
|
||||
- Failure behavior: proposal warnings and malformed LLM output handling as implemented.
|
||||
- Tests to inspect: `internal/modules/...` and proposal generation tests.
|
||||
- Architectural invariants: keep module scope narrow and avoid hidden global state.
|
||||
|
||||
### Validators
|
||||
|
||||
- Path: `docs/internal/validators.md`
|
||||
- Purpose: document validator composition and decision handling.
|
||||
- Inputs and outputs: candidate proposals, validator decisions, rejection reasons, warnings.
|
||||
- Boundaries: validator registry and chains live in `internal/validators`; runtime mechanics live in `internal/framework/validators`.
|
||||
- Config fields used: thresholds, validation LLM settings, validation concurrency, validation prompt limits.
|
||||
- Adapters used: LLM-backed validators use the LLM contract rather than direct transport.
|
||||
- Failure behavior: rejected proposals, warning behavior, malformed output policy.
|
||||
- Tests to inspect: validator registry, chain, batching, malformed output, protected terms, and LLM validator tests.
|
||||
- Architectural invariants: validators remain modular and composable.
|
||||
|
||||
### LLM Runtime
|
||||
|
||||
- Path: `docs/internal/llm-runtime.md`
|
||||
- Purpose: document structured LLM calls and bounded scheduling.
|
||||
- Inputs and outputs: structured prompt requests, response schemas, parsed responses, scheduler permit results, diagnostics metadata.
|
||||
- Boundaries: transport stays behind `StructuredLLMClient`; scheduler manages permits; response schema registry owns schema metadata.
|
||||
- Config fields used: model, base URL, API key, timeout, retries, total/proposal/validation concurrency, validation max prompt tokens.
|
||||
- Adapters used: OpenAI-compatible HTTP adapter.
|
||||
- Failure behavior: retries, timeout/context handling, malformed structured output handling, redacted errors.
|
||||
- Tests to inspect: LLM client, scheduler, redaction, response schema, structured output tests.
|
||||
- Architectural invariants: keep concurrency bounded and explicit; do not leak secrets in diagnostics.
|
||||
|
||||
### Diagnostics and Reporting
|
||||
|
||||
- Path: `docs/internal/diagnostics-reporting.md`
|
||||
- Purpose: document diagnostics artifacts, process reports, and correction ledger generation.
|
||||
- Inputs and outputs: run directory artifacts, diagnostics metadata, process report JSON, correction ledger entries.
|
||||
- Boundaries: diagnostics owns artifact names and metadata; processreport maps runner output to reporting structures; CLI chooses output destinations.
|
||||
- Config fields used: work dir, work-dir retention, transcript description.
|
||||
- Adapters used: filesystem through diagnostics/CLI boundaries.
|
||||
- Failure behavior: report status/error mapping and artifact write errors as implemented.
|
||||
- Tests to inspect: diagnostics tests, processreport tests, CLI report fixture tests.
|
||||
- Architectural invariants: preserve diagnostics filenames and report JSON shape unless intentionally changed and documented.
|
||||
|
||||
### Prompts
|
||||
|
||||
- Path: `docs/internal/prompts.md`
|
||||
- Purpose: document implemented prompt registry, embedded assets, and metadata.
|
||||
- Inputs and outputs: prompt identifiers, prompt asset content, rendered prompt payloads, diagnostic metadata.
|
||||
- Boundaries: prompt assets remain owned by module/framework areas that use them; no filesystem override mechanism is implemented.
|
||||
- Config fields used: transcript description/context where applicable.
|
||||
- Adapters used: none directly; prompts are consumed by LLM-backed framework code.
|
||||
- Failure behavior: missing or malformed embedded prompt assets should surface through tests or runtime errors as implemented.
|
||||
- Tests to inspect: prompt registry and module prompt tests.
|
||||
- Architectural invariants: keep prompt metadata consistent with diagnostics.
|
||||
|
||||
### Output Schemas
|
||||
|
||||
- Path: `docs/internal/output-schemas.md`
|
||||
- Purpose: document implemented output schema registry and report/output relationship.
|
||||
- Inputs and outputs: configured output schema key, validated schema support, emitted transcript output.
|
||||
- Boundaries: output schema registry lives in `internal/core/outputschema`; config validation consumes registry support.
|
||||
- Config fields used: output schema.
|
||||
- Adapters used: none directly.
|
||||
- Failure behavior: unsupported schema keys fail validation.
|
||||
- Tests to inspect: output schema and config validation tests.
|
||||
- Architectural invariants: do not document unsupported schemas as current behavior.
|
||||
|
||||
## Integration Documentation Plan
|
||||
|
||||
### `docs/integrations/subprocess.md`
|
||||
|
||||
- External system or contract: parent process invoking the `audita` CLI.
|
||||
- Current usage in Audita: `audita process` writes output/report files and emits subprocess-friendly diagnostics and errors.
|
||||
- Version or compatibility notes: document only the current CLI behavior and implemented exit behavior.
|
||||
- What to document: invocation model, command examples, output files, report JSON path, stderr/stdout expectations, diagnostics, exit codes.
|
||||
- What not to document: streaming protocols, server mode, remote job control, resume APIs.
|
||||
|
||||
### `docs/integrations/openai-compatible-llm.md`
|
||||
|
||||
- External system or contract: OpenAI-compatible chat completions endpoint using JSON schema response format.
|
||||
- Current usage in Audita: configured primary and validation LLM clients issue structured chat completion requests with retries/timeouts and redaction.
|
||||
- Version or compatibility notes: document compatibility based on request behavior in `internal/framework/llm`, not provider marketing claims.
|
||||
- What to document: endpoint configuration, authentication, request/response expectations, `response_format.type=json_schema`, retries, timeouts, redaction.
|
||||
- What not to document: unsupported provider SDKs, non-OpenAI-compatible APIs, unimplemented model-routing features.
|
||||
|
||||
### `docs/integrations/transcript-glossary-files.md`
|
||||
|
||||
- External system or contract: transcript JSON and glossary YAML files accepted as inputs.
|
||||
- Current usage in Audita: CLI loads transcript and glossary files before processing and validates their shape through core schema code.
|
||||
- Version or compatibility notes: document implemented fields and validation behavior only.
|
||||
- What to document: accepted file shapes, required/optional fields, common validation errors, tiny examples.
|
||||
- What not to document: a formal versioned external schema that the code does not enforce.
|
||||
|
||||
## Recommended Implementation Sequence
|
||||
|
||||
### Stage 1: Roadmap Creation
|
||||
|
||||
- Goal: create this documentation roadmap.
|
||||
- Files to create/update/delete/move: create `docs/roadmap/documentation.md` only.
|
||||
- Repository areas to inspect: documentation policy, architecture policy, existing docs, CLI/config/package/test layout.
|
||||
- Acceptance criteria: roadmap is action-oriented, staged, and limited to future documentation work.
|
||||
- Suggested validation commands: `git diff --check -- docs/roadmap/documentation.md`.
|
||||
- One prompt: yes.
|
||||
|
||||
### Stage 2: Canonical Layout and README Links
|
||||
|
||||
- Goal: establish canonical paths and remove obvious stale links without rewriting all content.
|
||||
- Files to create/update/delete/move: create target directories, move/rewrite shells for `docs/config.md`, `docs/policy/development.md`, `docs/integrations/subprocess.md`, and update README links; remove old duplicates only after content is preserved.
|
||||
- Repository areas to inspect: docs policy, README, moved docs.
|
||||
- Acceptance criteria: canonical paths exist; README does not link to nonexistent docs; old paths are either redirected by content moves or removed.
|
||||
- Suggested validation commands: `rg "docs/(diagnostics|structured-llm|subprocess-operations)\\.md" README.md docs`; `rg "docs/configuration\\.md|docs/development\\.md|docs/integration/" README.md docs`.
|
||||
- One prompt: yes.
|
||||
|
||||
### Stage 3: README and CLI Reference
|
||||
|
||||
- Goal: make README concise and create complete `docs/cli.md`.
|
||||
- Files to create/update/delete/move: `README.md`, `docs/cli.md`.
|
||||
- Repository areas to inspect: `cmd/audita/main.go`, `internal/cli/run.go`, `internal/cli/process_flags.go`, CLI tests.
|
||||
- Acceptance criteria: README is orientation only; all implemented commands and flags are covered in `docs/cli.md`; examples match parser behavior.
|
||||
- Suggested validation commands: `go test ./internal/cli ./cmd/audita`; stale-link grep checks.
|
||||
- One prompt: yes.
|
||||
|
||||
### Stage 4: Config Reference and Examples
|
||||
|
||||
- Goal: rewrite `docs/config.md` and add maintained copyable examples.
|
||||
- Files to create/update/delete/move: `docs/config.md`, `examples/minimal-config.yml`, `examples/production-config.yml`, `examples/tiny-transcript.json`, `examples/tiny-glossary.yaml`; remove `docs/configuration.md` after migration.
|
||||
- Repository areas to inspect: `internal/core/config/*`, config tests, schema tests.
|
||||
- Acceptance criteria: config reference matches implemented defaults, precedence, env vars, validation, and secrets; examples contain no secrets and validate where practical.
|
||||
- Suggested validation commands: `go test ./internal/core/config`; `go run ./cmd/audita config validate --config examples/minimal-config.yml`; `go run ./cmd/audita config validate --config examples/production-config.yml`.
|
||||
- One prompt: yes.
|
||||
|
||||
### Stage 5: Operations and Troubleshooting
|
||||
|
||||
- Goal: create operational and troubleshooting references.
|
||||
- Files to create/update/delete/move: `docs/operations.md`, `docs/troubleshooting.md`.
|
||||
- Repository areas to inspect: `internal/core/diagnostics`, `internal/framework/processreport`, `internal/core/reporting`, CLI failure/report tests.
|
||||
- Acceptance criteria: implemented artifacts, retention, reports, correction ledger, and failure inspection are documented; no resume or remote-storage claims.
|
||||
- Suggested validation commands: `go test ./internal/core/diagnostics ./internal/framework/processreport ./internal/cli`.
|
||||
- One prompt: yes.
|
||||
|
||||
### Stage 6: Internal Architecture Docs Migration
|
||||
|
||||
- Goal: move implemented architecture details into `docs/internal/` and remove roadmap content from non-roadmap docs.
|
||||
- Files to create/update/delete/move: `docs/internal/overview.md`, `docs/internal/pipeline.md`, `docs/internal/modules.md`, `docs/internal/validators.md`, `docs/internal/llm-runtime.md`, `docs/internal/diagnostics-reporting.md`, `docs/internal/prompts.md`, `docs/internal/output-schemas.md`; migrate/delete relevant `docs/architecture/*`.
|
||||
- Repository areas to inspect: `internal/core`, `internal/framework`, `internal/modules`, `internal/validators`, `internal/prompts`.
|
||||
- Acceptance criteria: internal docs document implemented behavior only; deferred or unimplemented content appears only under `docs/roadmap/`.
|
||||
- Suggested validation commands: `go test ./internal/framework/llm ./internal/framework/runner`; `go test ./internal/validators/...`; `go test ./internal/modules/...`; `rg "deferred|not implemented|future|planned|experimental|aspirational" docs --glob '!docs/roadmap/**'`.
|
||||
- One prompt: split if needed into pipeline/modules/validators and LLM/diagnostics/prompts/output schemas.
|
||||
|
||||
### Stage 7: Integration Docs
|
||||
|
||||
- Goal: create external contract docs for implemented integrations.
|
||||
- Files to create/update/delete/move: `docs/integrations/subprocess.md`, `docs/integrations/openai-compatible-llm.md`, `docs/integrations/transcript-glossary-files.md`; remove `docs/integration/` after migration.
|
||||
- Repository areas to inspect: CLI behavior, `internal/framework/llm`, `internal/core/schema`, integration-related tests.
|
||||
- Acceptance criteria: integration docs describe actual external contracts and do not claim unsupported APIs.
|
||||
- Suggested validation commands: `go test ./internal/cli ./cmd/audita`; `go test ./internal/framework/llm`; schema package tests.
|
||||
- One prompt: yes.
|
||||
|
||||
### Stage 8: Development Policy and Duplicate Cleanup
|
||||
|
||||
- Goal: finish contributor workflow docs and remove duplicate policy locations.
|
||||
- Files to create/update/delete/move: `docs/policy/development.md`, `docs/documentation/policy.md`, `docs/release-checklist.md`, any remaining old architecture/config/development paths.
|
||||
- Repository areas to inspect: policy docs, development docs, test layout, final documentation tree.
|
||||
- Acceptance criteria: one canonical documentation policy, one canonical development workflow, no duplicate or stale canonical-home references.
|
||||
- Suggested validation commands: `find docs -type f | sort`; grep checks for old paths and duplicate policy paths.
|
||||
- One prompt: yes.
|
||||
|
||||
### Stage 9: Final Documentation Validation
|
||||
|
||||
- Goal: repository-wide documentation review after migration.
|
||||
- Files to create/update/delete/move: all documentation and examples touched by prior stages only as needed for fixes.
|
||||
- Repository areas to inspect: final docs tree, README, examples, code-backed docs.
|
||||
- Acceptance criteria: canonical docs exist, stale docs removed, examples valid, no unimplemented claims outside roadmap, Go tests pass.
|
||||
- Suggested validation commands: `go test ./...`; all grep/link checks in this roadmap; example validation commands.
|
||||
- One prompt: yes.
|
||||
|
||||
## Validation Plan
|
||||
|
||||
No markdown or documentation linter configuration was found. Use repository behavior tests, whitespace checks, grep checks, and manual review.
|
||||
|
||||
Automated checks:
|
||||
|
||||
- `git diff --check`
|
||||
- `go test ./internal/core/config`
|
||||
- `go test ./internal/cli ./cmd/audita`
|
||||
- `go test ./internal/core/diagnostics ./internal/framework/processreport`
|
||||
- `go test ./internal/framework/llm ./internal/framework/runner`
|
||||
- `go test ./...`
|
||||
|
||||
Example checks after examples exist:
|
||||
|
||||
- `go run ./cmd/audita config validate --config examples/minimal-config.yml`
|
||||
- `go run ./cmd/audita config validate --config examples/production-config.yml`
|
||||
|
||||
Recommended grep and path checks:
|
||||
|
||||
- `rg "docs/(diagnostics|structured-llm|subprocess-operations)\\.md" README.md docs`
|
||||
- `rg "docs/configuration\\.md|docs/development\\.md|docs/integration/" README.md docs`
|
||||
- `rg "deferred|not implemented|future|planned|experimental|aspirational" docs --glob '!docs/roadmap/**'`
|
||||
- `find docs -type f | sort`
|
||||
- `find examples -type f | sort`
|
||||
|
||||
Manual review:
|
||||
|
||||
- Confirm README is concise and links to canonical docs.
|
||||
- Confirm CLI and config docs do not duplicate each other.
|
||||
- Confirm internal docs are developer-facing and not user manuals.
|
||||
- Confirm operations and troubleshooting docs describe current behavior only.
|
||||
- Confirm future work appears only under `docs/roadmap/`.
|
||||
- Confirm examples contain no secrets or private transcript data.
|
||||
|
||||
## Open Questions
|
||||
|
||||
No questions block the roadmap. Use these defaults unless a later implementation prompt says otherwise:
|
||||
|
||||
- Use the canonical paths from `docs/policy/documentation.md`, even when that requires moving existing docs.
|
||||
- Treat `docs/configuration.md`, `docs/development.md`, `docs/integration/`, and `docs/architecture/*` as migration sources, not final homes.
|
||||
- Do not restore deleted roadmap files unless separately requested.
|
||||
- Prefer concise canonical docs over preserving historical wording from stale files.
|
||||
@@ -1,329 +0,0 @@
|
||||
# Pre-1.0 Deduplication Implementation Plan
|
||||
|
||||
This plan turns `docs/roadmap/audit.md` into staged, prompt-sized cleanup work for an LLM coding agent. Each stage should be implemented in order and kept small enough to review as an independent commit.
|
||||
|
||||
## Operating rules
|
||||
|
||||
- Read `docs/roadmap/audit.md` before starting any stage.
|
||||
- Preserve public CLI, report, diagnostics, config precedence, prompt metadata, and output-schema behavior unless a stage explicitly calls out an intended behavior change.
|
||||
- Keep the four production module packages separate: `glossary`, `homophones`, `spoken_word`, and `grammar`.
|
||||
- Do not introduce plugin systems, generic workflow engines, broad CLI framework rewrites, reflection-heavy config mappers, or merged module packages.
|
||||
- Prefer narrow helpers, catalogs, constants, and pure mapping functions over broad abstractions.
|
||||
- Run the targeted tests listed in each stage before moving to the next stage.
|
||||
- Run `go test ./...` before declaring the full sequence complete.
|
||||
- Ignore unrelated worktree changes, including the existing deletion of `docs/roadmap/publish.md`, unless the user explicitly asks to handle them.
|
||||
- Do not reduce parity, release-fixture, subprocess, or module-specific behavior coverage while consolidating helpers.
|
||||
|
||||
## Stages
|
||||
|
||||
### Stage 1: Diagnostics artifact constants and metadata paths
|
||||
|
||||
Goal:
|
||||
|
||||
- Centralize diagnostics artifact names and report diagnostics metadata path construction without changing any filenames or report fields.
|
||||
|
||||
Key edits:
|
||||
|
||||
- Define constants in `internal/core/diagnostics` for:
|
||||
- `source-transcript.json`
|
||||
- `source-transcript-parsed.json`
|
||||
- `normalized-transcript.json`
|
||||
- `normalization-summary.json`
|
||||
- `chunking-summary.json`
|
||||
- `utilization-diagnostics.json`
|
||||
- `correction-ledger.json`
|
||||
- `invocation.json`
|
||||
- `effective-config.json`
|
||||
- `report.json`
|
||||
- `error.log`
|
||||
- Add a diagnostics helper that builds `reporting.DiagnosticsMetadata` from a run directory path and failure/success status.
|
||||
- Update `RunDirectory` methods to use the constants.
|
||||
- Update CLI report assembly and utilization/correction-ledger writes to use the constants/helper instead of raw strings.
|
||||
|
||||
Behavior changes:
|
||||
|
||||
- None. All artifact names, report JSON keys, and path values must remain byte-for-byte compatible except for normal timestamp/order differences in existing outputs.
|
||||
|
||||
Tests:
|
||||
|
||||
- Add or update `internal/core/diagnostics` tests proving metadata helper paths match the artifact constants.
|
||||
- Run `go test ./internal/core/diagnostics ./internal/core/reporting ./internal/cli`.
|
||||
- Run any existing CLI report/diagnostics tests touched by this stage.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- No raw core diagnostics artifact filename strings remain in CLI report metadata assembly.
|
||||
- Existing success and failure reports still point to files that are actually written.
|
||||
- Retention behavior is unchanged.
|
||||
|
||||
### Stage 2: Output schema validation and module catalog
|
||||
|
||||
Goal:
|
||||
|
||||
- Move public key validation to small canonical catalogs so config validation, runtime resolution, and factory behavior cannot drift.
|
||||
|
||||
Key edits:
|
||||
|
||||
- Add `SupportedKeys`, `IsSupported`, or an equivalent validation helper to `internal/core/outputschema`.
|
||||
- Update `config.Validate` to use `internal/core/outputschema` for output schema validation.
|
||||
- Add a small canonical module key catalog that is importable by:
|
||||
- `internal/core/config`
|
||||
- `internal/framework/modules`
|
||||
- `internal/validators`
|
||||
- `internal/framework/validators`
|
||||
- Use the module catalog for default module key constants, known-key checks, validator chain keys, and confidence-threshold lookup.
|
||||
- Keep module construction in `internal/framework/modules`; the catalog must not construct modules.
|
||||
|
||||
Behavior changes:
|
||||
|
||||
- Intended behavior change: unsupported configured module keys should fail during config validation, including `audita config validate`.
|
||||
- Repeated supported module keys remain valid.
|
||||
- Output schema behavior remains unchanged for `bare-segments`, `audita-v1`, and unsupported names.
|
||||
|
||||
Tests:
|
||||
|
||||
- Add `internal/core/config` tests for unsupported module keys and repeated supported module keys.
|
||||
- Add config validation tests that every supported output schema validates.
|
||||
- Add or update output schema registry tests for supported and unsupported schemas.
|
||||
- Update module registry and validator chain tests to use the shared catalog where appropriate.
|
||||
- Run `go test ./internal/core/config ./internal/core/outputschema ./internal/framework/modules ./internal/framework/validators ./internal/validators/... ./internal/cli`.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- Unknown modules fail before runner setup in config validation paths.
|
||||
- No duplicated hardcoded output schema support list remains in config validation.
|
||||
- No import cycle is introduced.
|
||||
|
||||
### Stage 3: Effective config loading context
|
||||
|
||||
Goal:
|
||||
|
||||
- Centralize config path resolution and defaults+file+env loading while keeping command-specific CLI overrides explicit.
|
||||
|
||||
Key edits:
|
||||
|
||||
- Move config path resolution from `internal/cli` into `internal/core/config` or add an equivalent exported helper there.
|
||||
- Add an effective config loader that returns:
|
||||
- effective `config.Config`
|
||||
- config path
|
||||
- config source (`flag`, `env`, `default`, or empty)
|
||||
- config version pointer when a file was loaded
|
||||
- Use the shared loader in `audita process` before applying CLI overrides.
|
||||
- Use the shared loader in `audita config print-effective`.
|
||||
- Keep `audita config validate` as file-only: load file, apply to defaults, validate, and do not apply environment overrides.
|
||||
|
||||
Behavior changes:
|
||||
|
||||
- None. Preserve existing precedence:
|
||||
- `process`: defaults, file config, environment, CLI flags
|
||||
- `config print-effective`: defaults, file config, environment
|
||||
- `config validate`: file config applied to defaults only
|
||||
- Preserve explicit config path failure behavior and missing default path non-fatal behavior.
|
||||
|
||||
Tests:
|
||||
|
||||
- Add table-driven config loader tests for:
|
||||
- explicit `--config`
|
||||
- `AUDITA_CONFIG`
|
||||
- default search paths
|
||||
- missing explicit path
|
||||
- missing env path
|
||||
- missing default paths
|
||||
- Add or update CLI tests proving `process` and `config print-effective` share file+env behavior.
|
||||
- Add or update CLI tests proving `config validate` ignores environment overrides.
|
||||
- Run `go test ./internal/core/config ./internal/cli ./cmd/audita`.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- Config precedence is unchanged.
|
||||
- Config source/path/version metadata in invocation and reports is unchanged.
|
||||
- Config command stdout/stderr and exit-code behavior is unchanged except for the intended unknown-module validation from Stage 2.
|
||||
|
||||
### Stage 4: Prompt/schema metadata and stage-name helpers
|
||||
|
||||
Goal:
|
||||
|
||||
- Centralize diagnostics-visible metadata and stage-name construction without changing production diagnostics names.
|
||||
|
||||
Key edits:
|
||||
|
||||
- Add a helper or method in `internal/prompts` that returns the stable prompt metadata diagnostics shape currently expanded by call sites.
|
||||
- Add a helper or method in `internal/framework/responseschema` that returns the stable response schema metadata diagnostics shape currently expanded by call sites.
|
||||
- Add shared proposal and validator stage-name helpers in the lowest package that avoids import cycles.
|
||||
- Use the helpers in proposal generation, LLM validators, and production modules.
|
||||
|
||||
Behavior changes:
|
||||
|
||||
- None. Preserve current production stage names:
|
||||
- module proposal stages keep their existing `proposal` naming form;
|
||||
- validator batch stages keep their existing validator/batch naming form.
|
||||
- Preserve all prompt metadata and response schema metadata field names and values.
|
||||
|
||||
Tests:
|
||||
|
||||
- Add prompt metadata helper tests covering every registered prompt.
|
||||
- Add response schema metadata helper tests covering every registered response schema.
|
||||
- Add stage-name helper tests for no-section, section, and validator batch cases.
|
||||
- Run `go test ./internal/prompts ./internal/framework/responseschema ./internal/framework/proposal_generation ./internal/framework/validators ./internal/modules/...`.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- No manual prompt metadata map expansion remains in production module proposal plumbing.
|
||||
- No duplicated response schema metadata map construction remains in proposal generation and LLM validators.
|
||||
- Existing diagnostics fixture/path assertions still pass.
|
||||
|
||||
### Stage 5: Shared module proposal and prompt payload plumbing
|
||||
|
||||
Goal:
|
||||
|
||||
- Remove duplicated proposal execution and transcript-section prompt payload construction while preserving module-specific domain behavior.
|
||||
|
||||
Key edits:
|
||||
|
||||
- Add a narrow shared proposal execution helper, preferably in `internal/framework/proposal_generation` unless import cycles require a small module helper package.
|
||||
- The helper should own:
|
||||
- transcript description extraction from config;
|
||||
- `GenerateCandidates` request construction;
|
||||
- prompt metadata attachment;
|
||||
- stage-name selection;
|
||||
- conversion from generated corrections/warnings to `contracts.ProposalResult`.
|
||||
- Add shared transcript-section prompt payload construction in `internal/framework/promptcontext`.
|
||||
- Update each production module to provide only:
|
||||
- module key;
|
||||
- replacement policy;
|
||||
- validator chain;
|
||||
- prompt ID;
|
||||
- domain-specific `BuildProposalMessages` call or message builder.
|
||||
- Remove each module's redundant section transcript filtering if the runner already passes section-limited transcripts.
|
||||
|
||||
Behavior changes:
|
||||
|
||||
- None. Preserve module keys, replacement policies, validator chains, prompt IDs, diagnostics directories, proposal indexes, warning behavior, and correction mapping.
|
||||
|
||||
Tests:
|
||||
|
||||
- Add promptcontext tests for transcript section payload shape, empty transcript handling, section index, and category copying.
|
||||
- Keep one module-specific prompt test per production module for domain wording and constraints.
|
||||
- Add or update module proposal tests proving diagnostics are still written under the same module instance directory.
|
||||
- Run `go test ./internal/framework/promptcontext ./internal/framework/proposal_generation ./internal/modules/... ./internal/cli`.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- Four production modules share proposal execution plumbing.
|
||||
- Module packages remain separate and readable.
|
||||
- CLI parity and release fixture behavior is unchanged.
|
||||
|
||||
### Stage 6: Validator classification and malformed LLM output policy
|
||||
|
||||
Goal:
|
||||
|
||||
- Use one source of truth for validator execution class and one shared classifier for malformed structured-output errors.
|
||||
|
||||
Key edits:
|
||||
|
||||
- Make validator execution class resolvable by stable validator key and by validator instance.
|
||||
- Replace the correction-ledger hardcoded LLM-backed validator map with the canonical metadata source.
|
||||
- Remove redundant validator metadata fields only after all call sites use the canonical source.
|
||||
- Add a shared malformed structured-output classifier in `internal/framework/llm` or another low-level framework package.
|
||||
- Update proposal generation and LLM validators to use the shared classifier while preserving their different handling outcomes.
|
||||
|
||||
Behavior changes:
|
||||
|
||||
- None. Proposal-generation malformed payloads still downgrade to warnings with zero proposals for affected sections.
|
||||
- Validator malformed payloads still reject affected batches with warnings.
|
||||
- Correction-ledger deterministic vs LLM validator sections should be unchanged for current validators.
|
||||
|
||||
Tests:
|
||||
|
||||
- Add validator metadata tests proving every registered validator has the expected execution class by key and instance.
|
||||
- Add correction-ledger tests proving deterministic and LLM-backed decisions are classified through canonical metadata.
|
||||
- Add shared malformed-output classifier tests covering current adapter malformed-output messages.
|
||||
- Update proposal-generation and validator tests to assert representative malformed adapter errors are still downgraded.
|
||||
- Run `go test ./internal/validators/... ./internal/framework/validators ./internal/framework/proposal_generation ./internal/framework/llm ./internal/cli`.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- No local hardcoded LLM-backed validator map remains in correction-ledger construction.
|
||||
- Proposal-generation and validator malformed-output classifier lists cannot drift.
|
||||
- Existing runner validator ordering is unchanged.
|
||||
|
||||
### Stage 7: Redaction and adapter workflow cleanup
|
||||
|
||||
Goal:
|
||||
|
||||
- Reduce duplicated secret extraction/redaction setup while preserving all no-secret-leak guarantees.
|
||||
|
||||
Key edits:
|
||||
|
||||
- Add a shared helper that extracts all configured LLM secret values from `config.Config`.
|
||||
- Use the helper in proposal-generation diagnostics and validator diagnostics setup.
|
||||
- Keep config structural redaction (`Config.Redacted`) separate from byte/string payload redaction.
|
||||
- Keep adapter error redaction behavior compatible with current surfaced errors.
|
||||
- Move runner adapter shims only if Stage 6 or this stage makes them materially larger; otherwise leave them in runner.
|
||||
|
||||
Behavior changes:
|
||||
|
||||
- None. Redaction token and no-secret-leak behavior remain unchanged.
|
||||
|
||||
Tests:
|
||||
|
||||
- Add or update tests proving proposal diagnostics, validator diagnostics, effective config artifacts, and surfaced adapter errors redact the same configured secrets.
|
||||
- Keep existing subprocess no-secret-leak tests.
|
||||
- Run `go test ./internal/core/config ./internal/framework/llm ./internal/framework/proposal_generation ./internal/framework/validators ./internal/cli ./cmd/audita`.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- Secret-list assembly is no longer duplicated between proposal and validator paths.
|
||||
- No plaintext configured API key appears in diagnostics, reports, stdout, or stderr in existing redaction tests.
|
||||
- No unrelated adapter behavior changes.
|
||||
|
||||
### Stage 8: Test helper cleanup and dead-code sweep
|
||||
|
||||
Goal:
|
||||
|
||||
- Consolidate test-only duplication and remove dead/redundant code left by prior stages.
|
||||
|
||||
Key edits:
|
||||
|
||||
- Consolidate package-local fake LLM clients, fixture readers, diagnostics glob helpers, and run-directory helpers where duplication is clear.
|
||||
- Use cross-package test support only if it does not obscure test intent or introduce awkward imports.
|
||||
- Remove redundant metadata fields, constants, or helper functions made obsolete by earlier stages.
|
||||
- Keep module-specific prompt and behavior assertions local to each module package.
|
||||
|
||||
Behavior changes:
|
||||
|
||||
- None.
|
||||
|
||||
Tests:
|
||||
|
||||
- Run all package tests touched by helper cleanup.
|
||||
- Run `go test ./internal/modules/... ./internal/framework/... ./internal/cli ./cmd/audita`.
|
||||
- Run `go test ./...` before completing the full sequence.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- Test helpers are simpler without reducing coverage.
|
||||
- No parity or release fixture assertions are removed unless replaced by equivalent or stronger assertions.
|
||||
- No production behavior changes.
|
||||
|
||||
## Final verification
|
||||
|
||||
Before declaring the staged cleanup complete:
|
||||
|
||||
- Run:
|
||||
- `go test ./internal/core/config ./internal/core/outputschema`
|
||||
- `go test ./internal/core/diagnostics ./internal/core/reporting`
|
||||
- `go test ./internal/framework/proposal_generation ./internal/framework/validators ./internal/framework/runner`
|
||||
- `go test ./internal/validators/...`
|
||||
- `go test ./internal/modules/...`
|
||||
- `go test ./internal/cli ./cmd/audita`
|
||||
- `go test ./...`
|
||||
- Inspect `git diff` for accidental public CLI, config, report, diagnostics, prompt metadata, stage-name, or output-schema changes.
|
||||
- Update docs only when behavior intentionally changes, especially the intended Stage 2 unknown-module validation change.
|
||||
- Keep commits stage-sized and mention behavior-preservation tests in each commit message or PR description.
|
||||
|
||||
## Assumptions
|
||||
|
||||
- Unknown configured module keys should become config-validation failures before 1.0.
|
||||
- Diagnostics filenames and stage names are public enough to preserve unless a stage explicitly says otherwise.
|
||||
- Each stage should be implemented and reviewed separately.
|
||||
Reference in New Issue
Block a user