Mark MVP implementation complete in roadmap
This commit is contained in:
@@ -2,12 +2,12 @@
|
||||
|
||||
## Status
|
||||
|
||||
This is the active roadmap for reaching the first functional Notarius MVP.
|
||||
The first functional Notarius MVP implementation is complete enough to start the
|
||||
deferred documentation pass.
|
||||
|
||||
The previous numbered checkpoint roadmaps have been implemented and retired.
|
||||
This document captures the remaining work needed to turn the implemented
|
||||
architecture into a usable MVP, with the current architectural review findings
|
||||
folded in as first-class work.
|
||||
This document now records the implemented MVP scope and the remaining
|
||||
release/documentation work before alpha `0.1.0`.
|
||||
|
||||
Implementation staging belongs in [`implementation.md`](implementation.md).
|
||||
|
||||
@@ -36,163 +36,71 @@ The MVP remains intentionally narrow:
|
||||
- config-driven pipeline profiles;
|
||||
- OpenAI-compatible structured LLM execution through the existing LLM client.
|
||||
|
||||
## MVP Work Areas
|
||||
## Implemented MVP Behavior
|
||||
|
||||
### Framework/Domain Asset Boundaries
|
||||
The MVP now includes:
|
||||
|
||||
This is the highest-priority remaining architecture correction.
|
||||
- framework/domain asset boundaries: D&D spell prompt and response schema assets
|
||||
are owned by `internal/modules/extract/dnd/spells`, while framework prompt and
|
||||
LLM packages provide only generic primitives;
|
||||
- production CLI wiring that registers `seriatim`, `dnd/spells`, and the
|
||||
default `generic`, `appendorder`, `noop`, and `json` modules;
|
||||
- a config-driven `notarius run` command that reads Seriatim input, resolves a
|
||||
configured pipeline, invokes the runner, and writes durable output plus
|
||||
diagnostics;
|
||||
- fixture-driven CLI acceptance coverage using maintained example config and
|
||||
transcript fixtures with a fake LLM path, so `go test ./...` exercises the MVP
|
||||
without network access.
|
||||
|
||||
Framework packages must remain source-agnostic and domain-agnostic. D&D spell
|
||||
prompt assets, response schema assets, prompt IDs, response schema keys, and
|
||||
domain-specific prompt/schema tests should not live in `internal/framework/llm`
|
||||
or `internal/framework/prompt`.
|
||||
|
||||
Target state:
|
||||
|
||||
- `internal/framework/llm` provides generic structured-output client,
|
||||
scheduler, schema metadata, schema loading, and schema lookup/registration
|
||||
primitives.
|
||||
- `internal/framework/prompt` provides generic prompt metadata, prompt loading,
|
||||
rendering, hardening, and lookup/registration primitives.
|
||||
- `internal/modules/extract/dnd/spells` owns the D&D spell prompt assets,
|
||||
response schema assets, stable prompt ID, stable response schema key, and
|
||||
module-specific prompt/schema tests.
|
||||
- Framework tests use placeholder/test assets only.
|
||||
- The D&D spells extractor depends on generic framework APIs, not
|
||||
framework-owned D&D constants.
|
||||
|
||||
This work should not change the external artifact shape or module key. It is an
|
||||
ownership and package-boundary correction.
|
||||
|
||||
### Production Application Catalog Wiring
|
||||
|
||||
The implemented modules and registries are currently exercised mostly through
|
||||
tests that inject catalogs. The MVP needs a production assembly point that
|
||||
builds the catalog and stage registries used by real CLI commands.
|
||||
|
||||
Target state:
|
||||
|
||||
- a small app-level package or CLI wiring function constructs the production
|
||||
`pipeline.ModuleCatalog`;
|
||||
- production wiring registers `seriatim`;
|
||||
- production wiring registers `dnd/spells`;
|
||||
- production wiring registers the default `generic`, `appendorder`, `noop`, and
|
||||
`json` modules;
|
||||
- `notarius config validate --pipeline ...` validates real configured
|
||||
pipelines without test-only catalog injection;
|
||||
- `notarius pipelines list` reports production-registered modules where useful
|
||||
for discoverability.
|
||||
|
||||
The production wiring should not move domain behavior into the CLI. The CLI may
|
||||
compose modules, but module packages should continue to own their own behavior
|
||||
and metadata.
|
||||
|
||||
### Default Production Stage Modules
|
||||
|
||||
Pipeline defaults are already part of the architecture:
|
||||
The production pipeline defaults are:
|
||||
|
||||
- `chunk: generic`;
|
||||
- `merge: appendorder`;
|
||||
- `normalize: noop`;
|
||||
- `output: json`.
|
||||
|
||||
The MVP should make those defaults real production modules rather than
|
||||
test-only conveniences.
|
||||
|
||||
Target state:
|
||||
|
||||
- `generic` chunking creates ordered chunks over generic source units and is
|
||||
configurable enough for transcript MVP use;
|
||||
- `appendorder` merge serializes artifact candidates in deterministic source
|
||||
and chunk order;
|
||||
- `noop` normalize passes merged artifacts through unchanged while preserving
|
||||
diagnostics;
|
||||
- `json` output encodes approved artifacts, rejected artifacts, warnings,
|
||||
manifest data, and relevant run metadata in a durable JSON shape;
|
||||
- each default module declares module specs and capabilities compatible with
|
||||
pipeline validation;
|
||||
- default modules are registered by production app wiring.
|
||||
|
||||
If a default module remains implemented in `internal/framework/pipeline`, its
|
||||
production registration still needs to be explicit and discoverable. If its
|
||||
logic grows beyond a small generic helper, move it under `internal/modules`.
|
||||
|
||||
### `notarius run`
|
||||
|
||||
The MVP needs a functional run command that drives the already-implemented
|
||||
pipeline runner.
|
||||
|
||||
Target state:
|
||||
|
||||
- command shape:
|
||||
The implemented command shape is:
|
||||
|
||||
```sh
|
||||
notarius run <pipeline-id> --input path/to/source.json
|
||||
notarius run <pipeline-id> --input path/to/source.json --only spells
|
||||
```
|
||||
|
||||
- required flags and arguments produce clear usage errors;
|
||||
- `--config` selects the config file;
|
||||
- `--only` filters artifact lanes without changing structural pipeline config;
|
||||
- operational overrides may cover output directory, work directory,
|
||||
concurrency, and LLM profile/model settings where already supported by config;
|
||||
- structural stage selection remains config-driven;
|
||||
- the command parses input through the configured input adapter;
|
||||
- the command constructs the configured LLM client and scheduler;
|
||||
- the command invokes the pipeline runner;
|
||||
- the command writes durable output and diagnostics;
|
||||
- failures return stable non-zero exit codes and useful error messages.
|
||||
Current output and diagnostics behavior:
|
||||
|
||||
The command should be covered by fixture-driven CLI tests with fake LLM behavior
|
||||
where network calls would otherwise be required.
|
||||
- output is written under `<output-root>/<run-id>/`, defaulting to
|
||||
`./notarius-output`;
|
||||
- JSON output includes a manifest, grouped approved artifacts, rejected
|
||||
artifacts, and warnings;
|
||||
- artifact records include generic source references;
|
||||
- output-stage warnings remain out-of-band from artifact payloads and are
|
||||
captured for CLI reporting and diagnostics;
|
||||
- run manifest data includes source digest, resolved pipeline digest, LLM
|
||||
profile/model metadata, prompt/schema identifiers, and validation status;
|
||||
- diagnostics redact secrets and include invocation metadata, redacted effective
|
||||
config, resolved pipeline, manifest, warnings, run report, and error logs.
|
||||
|
||||
### MVP Output And Diagnostics Behavior
|
||||
Maintained MVP fixtures:
|
||||
|
||||
The MVP should produce inspectable files that are stable enough for downstream
|
||||
experiments, without pretending to be a final public artifact contract.
|
||||
- `examples/dnd-spells.config.yml`;
|
||||
- `examples/seriatim-minimal-transcript.json`;
|
||||
- `internal/cli/testdata/invalid-seriatim-empty-segments.json`.
|
||||
|
||||
Target state:
|
||||
|
||||
- output path behavior is deterministic and documented in code/tests;
|
||||
- JSON output includes approved artifacts grouped or ordered predictably;
|
||||
- each artifact includes its generic source references;
|
||||
- rejected artifacts and validation decisions remain inspectable;
|
||||
- output-stage warnings remain out-of-band from the durable artifact payload but
|
||||
are captured for CLI reporting and diagnostics;
|
||||
- run manifest data includes source digest, resolved pipeline digest, relevant
|
||||
model/profile information, prompt/schema identifiers, and validation status;
|
||||
- diagnostics redact secrets and include the resolved effective configuration
|
||||
needed to debug a run.
|
||||
|
||||
### MVP Fixtures And Acceptance Tests
|
||||
|
||||
The MVP should be continuously testable without external services.
|
||||
|
||||
Target state:
|
||||
|
||||
- maintained Seriatim transcript fixture for the D&D spells MVP;
|
||||
- maintained minimal config fixture for the MVP pipeline;
|
||||
- fake LLM path for deterministic CLI and runner tests;
|
||||
- config validation tests using the production catalog;
|
||||
- `notarius run` fixture test from input file to output JSON;
|
||||
- failure tests for missing config, unknown pipeline, invalid input,
|
||||
invalid lane selection, LLM failure, and validation rejection;
|
||||
- `go test ./...` is sufficient to exercise the MVP path without network
|
||||
access.
|
||||
|
||||
### Documentation Pass Preparation
|
||||
## Remaining Release And Documentation Work
|
||||
|
||||
The full documentation pass is intentionally deferred until MVP functionality
|
||||
exists. It should happen before tagging alpha `0.1.0`.
|
||||
|
||||
The MVP implementation should still leave clear hooks for the documentation
|
||||
rewrite:
|
||||
Remaining work before alpha `0.1.0`:
|
||||
|
||||
- command behavior should be stable enough to document in `docs/cli.md`;
|
||||
- config behavior should be stable enough to document in `docs/config.md`;
|
||||
- output behavior should be stable enough to document in integration docs;
|
||||
- examples should be generated from or validated against maintained fixtures
|
||||
where practical.
|
||||
- move implemented CLI behavior into `docs/cli.md`;
|
||||
- move implemented config behavior into `docs/config.md`;
|
||||
- document run output and diagnostics behavior in canonical docs;
|
||||
- update integration docs for Seriatim input, D&D spell artifacts, and JSON
|
||||
output where needed;
|
||||
- update `README.md` with a shortest useful command based on the maintained
|
||||
examples;
|
||||
- keep examples validated by tests.
|
||||
|
||||
## Out Of Scope For MVP
|
||||
|
||||
@@ -234,9 +142,9 @@ rewrite:
|
||||
|
||||
## Deferred Documentation Pass
|
||||
|
||||
After MVP behavior is implemented and before alpha `0.1.0`, complete a full
|
||||
documentation pass/rewrite. That pass should move implemented behavior out of
|
||||
roadmap documents and into canonical docs required by
|
||||
Before alpha `0.1.0`, complete a full documentation pass/rewrite. That pass
|
||||
should move implemented behavior out of roadmap documents and into canonical
|
||||
docs required by
|
||||
[`../policy/documentation.md`](../policy/documentation.md), including at least:
|
||||
|
||||
- `README.md`;
|
||||
|
||||
Reference in New Issue
Block a user