Add a staged implementation plan for porting relevant code from audita

docs/roadmap/4-portable-audita-infrastructure.md

@@ -31,73 +31,30 @@ Out of scope:
 - transcript mutation;
 - correction ledger terminology;
 - Audita module or validator behavior;
-- real D&D prompts or schemas unless needed as inert registry tests.
+- real D&D prompts or schemas;
+- domain-specific prompt or schema assets;
 - embedded built-in pipeline profiles.
 
-## Proposed Stages
+## Target End State
 
-### Stage 1: LLM Runtime
+The repository should contain reusable runtime infrastructure adapted from
+Audita where it directly supports Notarius contracts:
 
-Port or adapt the OpenAI-compatible structured-output client and scheduler.
+- an OpenAI-compatible structured-output LLM client behind the existing
+  `StructuredLLMClient` interface;
+- an LLM scheduler for bounded concurrency;
+- an embedded response-schema registry pattern;
+- an embedded prompt registry pattern;
+- a diagnostics run directory pattern using extraction-oriented artifact names;
+- config structs, loading, defaults, redaction, and validation for named
+  pipeline profiles.
 
-Keep the contract transport-neutral:
+Framework code should remain source-agnostic and domain-agnostic. Provider HTTP
+details should stay inside the LLM runtime package. Prompt and schema registries
+should use placeholder/test assets until real extractor prompts and schemas are
+introduced by later checkpoints.
 
-- framework code should depend on a `StructuredLLMClient` interface;
-- provider-specific HTTP details should remain in the LLM runtime package;
-- errors must redact configured secrets.
-
-### Stage 2: Response Schema Registry
-
-Port or adapt the embedded JSON response-schema registry pattern.
-
-The registry should track:
-
-- schema key;
-- schema ID;
-- schema version;
-- schema name;
-- JSON schema content;
-- schema hash.
-
-Use placeholder or test schemas if real extractor schemas are not ready.
-
-### Stage 3: Prompt Registry
-
-Port or adapt the embedded prompt registry pattern.
-
-The registry should track:
-
-- prompt ID;
-- prompt version;
-- prompt source;
-- embedded path;
-- prompt hash.
-
-Do not add D&D prompt assets here unless the implementation naturally overlaps
-with checkpoint 6. Test prompts are acceptable for registry tests.
-
-### Stage 4: Diagnostics Run Directory
-
-Port or adapt the diagnostics run directory pattern.
-
-Initial diagnostics should cover:
-
-- invocation metadata;
-- redacted effective config;
-- selected pipeline ID;
-- resolved pipeline definition and digest;
-- source document artifact;
-- run report placeholder;
-- error log on failure.
-
-Avoid Audita-specific artifact names such as correction ledger.
-
-### Stage 5: Pipeline Profile Config
-
-Add config structs, loading, defaults, and validation for named pipeline
-profiles.
-
-Initial config areas:
+Config should support:
 
 - `llm_profiles`;
 - `pipelines.<pipeline_id>.input`;
@@ -123,17 +80,20 @@ Structural module selection should come from pipeline config. CLI flags may
 override operational settings and artifact lane selection, but should not offer
 ad hoc `--extractor` or `--chunker` wiring.
 
-Add validation for unknown pipeline IDs, unknown module keys, missing required
-slots, missing capabilities, unknown LLM profiles, empty artifact-lane sets, and
-invalid lane selections.
+Config validation should fail fast for unknown pipeline IDs, unknown module
+keys, missing required slots, missing capabilities, unknown LLM profiles, empty
+artifact-lane sets, and invalid lane selections.
 
-If the CLI shell is ready, add:
+If the CLI shell is ready, the checkpoint should expose discovery/validation
+commands for config and pipeline profiles:
 
 ```sh
 notarius config validate
 notarius pipelines list
 ```
 
+Implementation staging belongs in [`implementation.md`](implementation.md).
+
 ## Done Criteria
 
 - `go test ./...` passes.