76 lines
2.3 KiB
Markdown
76 lines
2.3 KiB
Markdown
# Checkpoint 2: Framework Composition
|
|
|
|
## Status
|
|
|
|
This document describes planned work, not implemented behavior.
|
|
|
|
## Goal
|
|
|
|
Prove the core contracts compose before adding real stage modules or portable
|
|
Audita infrastructure.
|
|
|
|
This checkpoint should produce a minimal runner that can execute fake registered
|
|
components from source input to artifact output in tests.
|
|
|
|
## Scope
|
|
|
|
In scope:
|
|
|
|
- input adapter registry;
|
|
- extractor registry;
|
|
- validator decision model;
|
|
- decision-cardinality checks;
|
|
- minimal runner;
|
|
- fake-component runner tests.
|
|
|
|
Out of scope:
|
|
|
|
- real input parsing;
|
|
- real input modules;
|
|
- real extract modules;
|
|
- pipeline-profile config loading;
|
|
- module capability validation;
|
|
- real LLM calls;
|
|
- prompt assets;
|
|
- response schema assets;
|
|
- diagnostics run directory;
|
|
- real D&D artifact schemas.
|
|
|
|
## Target End State
|
|
|
|
The repository should contain a minimal framework composition layer:
|
|
|
|
- `internal/framework/pipeline` registers and builds input adapter constructors
|
|
and extractor constructors by stable key.
|
|
- `internal/framework/validate` provides shared validator decision helpers and
|
|
cardinality checks.
|
|
- `internal/framework/pipeline` executes configured extractors against a
|
|
`SourceDocument`, applies validator chains, and returns approved and rejected
|
|
artifacts.
|
|
|
|
The runner should operate on already parsed source documents in this checkpoint.
|
|
Raw input parsing and concrete input module behavior remain deferred to the
|
|
Seriatim input module checkpoint.
|
|
|
|
Pipeline-profile resolution, module metadata, and capability validation are
|
|
deferred to checkpoint 3. This checkpoint only needs constructor registries and
|
|
minimal runner composition.
|
|
|
|
Implementation staging belongs in
|
|
[`implementation.md`](implementation.md).
|
|
|
|
## Done Criteria
|
|
|
|
- `go test ./...` passes.
|
|
- Fake adapter/extractor/validator registrations work in tests.
|
|
- The runner operates on `SourceDocument`, not transcript-specific structures.
|
|
- The runner does not import concrete D&D extract module packages.
|
|
|
|
## Review Questions
|
|
|
|
- Does the runner know only about sources, extractors, validators, and artifacts?
|
|
- Are registries simple enough to evolve?
|
|
- Are validation decisions expressive enough for deterministic and LLM-backed
|
|
validators?
|
|
- Is any domain-specific behavior creeping into framework packages?
|