From 5424aae3debceb280e495ff7afeb9e6d42994011 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Sat, 4 Jul 2026 01:17:51 +0000 Subject: [PATCH] Mark MVP implementation complete in roadmap --- docs/roadmap/mvp.md | 188 +++++++++++--------------------------------- 1 file changed, 48 insertions(+), 140 deletions(-) diff --git a/docs/roadmap/mvp.md b/docs/roadmap/mvp.md index 8c937d6..563e6ee 100644 --- a/docs/roadmap/mvp.md +++ b/docs/roadmap/mvp.md @@ -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 --input path/to/source.json notarius run --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 `//`, 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`;