Clean up completed documentation roadmaps
This commit is contained in:
@@ -1,157 +1,29 @@
|
||||
# MVP Roadmap
|
||||
# Future Work
|
||||
|
||||
## Status
|
||||
Current Notarius behavior is documented in the canonical README, CLI,
|
||||
configuration, operations, internal, and integration docs. This roadmap records
|
||||
future work only.
|
||||
|
||||
The first functional Notarius MVP implementation is complete enough to start the
|
||||
deferred documentation pass.
|
||||
## Candidate Product Work
|
||||
|
||||
The previous numbered checkpoint roadmaps have been implemented and retired.
|
||||
This document now records the implemented MVP scope and the remaining
|
||||
release/documentation work before alpha `0.1.0`.
|
||||
- Additional input adapters, such as Markdown or note-export formats.
|
||||
- Additional D&D extractors beyond spell casts.
|
||||
- Cross-lane entity normalization.
|
||||
- Cross-chunk semantic deduplication.
|
||||
- Configurable validator chains with production validator modules.
|
||||
- Multiple effective LLM profiles in one run.
|
||||
- Parallel execution where it preserves deterministic manifests and diagnostics.
|
||||
- Additional output encoders.
|
||||
|
||||
Implementation staging belongs in [`implementation.md`](implementation.md).
|
||||
## Candidate Operational Work
|
||||
|
||||
## MVP Goal
|
||||
- Packaged release artifacts for alpha distribution.
|
||||
- A documented versioning and release process.
|
||||
- Optional generated example output fixtures with a regeneration procedure.
|
||||
- Additional diagnostics or reporting views if operator workflows need them.
|
||||
|
||||
The MVP should let a user run Notarius against a Seriatim minimal transcript
|
||||
JSON file, select a configured pipeline profile, extract D&D spell-cast
|
||||
artifacts with an LLM-backed extractor, validate those artifacts, and write
|
||||
durable JSON output plus diagnostics.
|
||||
## Non-Goals To Revisit Deliberately
|
||||
|
||||
The intended command shape is:
|
||||
|
||||
```sh
|
||||
notarius run dnd-session --input session-014.json
|
||||
notarius run dnd-session --input session-014.json --only spells
|
||||
```
|
||||
|
||||
The MVP remains intentionally narrow:
|
||||
|
||||
- one production input module: `seriatim`;
|
||||
- one production extract module: `dnd/spells`;
|
||||
- one generic chunk module sufficient for transcript-scale processing;
|
||||
- generic append-order merge;
|
||||
- generic noop normalization;
|
||||
- generic JSON output;
|
||||
- config-driven pipeline profiles;
|
||||
- OpenAI-compatible structured LLM execution through the existing LLM client.
|
||||
|
||||
## Implemented MVP Behavior
|
||||
|
||||
The MVP now includes:
|
||||
|
||||
- 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.
|
||||
|
||||
The production pipeline defaults are:
|
||||
|
||||
- `chunk: generic`;
|
||||
- `merge: appendorder`;
|
||||
- `normalize: noop`;
|
||||
- `output: json`.
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
Current output and diagnostics behavior:
|
||||
|
||||
- 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.
|
||||
|
||||
Maintained MVP fixtures:
|
||||
|
||||
- `examples/dnd-spells.config.yml`;
|
||||
- `examples/seriatim-minimal-transcript.json`;
|
||||
- `internal/cli/testdata/invalid-seriatim-empty-segments.json`.
|
||||
|
||||
## 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`.
|
||||
|
||||
Remaining work before alpha `0.1.0`:
|
||||
|
||||
- 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
|
||||
|
||||
- D&D item extraction;
|
||||
- NPC extraction;
|
||||
- combat extraction;
|
||||
- D&D rules validation beyond the spell extractor's deterministic checks;
|
||||
- Markdown or Obsidian input;
|
||||
- cross-lane entity normalization;
|
||||
- cross-chunk semantic deduplication beyond whatever a simple normalizer can
|
||||
safely support;
|
||||
- a general DAG or workflow engine;
|
||||
- ad hoc CLI flags for structural module selection;
|
||||
- release-quality documentation before the MVP behavior is implemented.
|
||||
|
||||
## MVP Done Criteria
|
||||
|
||||
- D&D prompt and response schema assets are owned by the D&D spells module, not
|
||||
by framework packages.
|
||||
- Production CLI commands use a real app catalog rather than test-injected
|
||||
module catalogs.
|
||||
- A config profile can bind `input: seriatim` and an artifact lane with
|
||||
`extract: dnd/spells`.
|
||||
- Default `generic`, `appendorder`, `noop`, and `json` modules resolve through
|
||||
production wiring.
|
||||
- `notarius config validate --config <file> --pipeline <id>` works with the
|
||||
MVP config.
|
||||
- `notarius pipelines list --config <file>` works with the MVP config.
|
||||
- `notarius run <pipeline-id> --input <file>` reads a Seriatim transcript,
|
||||
extracts D&D spell artifacts, validates them, and writes JSON output.
|
||||
- `notarius run <pipeline-id> --input <file> --only spells` runs only the
|
||||
selected artifact lane.
|
||||
- The run manifest records source digest, resolved pipeline digest, LLM profile
|
||||
and model, prompt/schema identifiers, and validation status.
|
||||
- Output warnings are available to CLI/diagnostics without becoming artifact
|
||||
payload fields.
|
||||
- MVP fixture tests cover the full path without network access.
|
||||
- `go test ./...`, `go vet ./...`, and `go build ./cmd/notarius` pass.
|
||||
|
||||
## Deferred Documentation Pass
|
||||
|
||||
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`;
|
||||
- `docs/cli.md`;
|
||||
- `docs/config.md`;
|
||||
- `docs/operations.md`, if diagnostics/run recovery behavior warrants it;
|
||||
- `docs/internal/` architecture and package-boundary docs;
|
||||
- `docs/integrations/` updates for Seriatim input, D&D spell artifacts, and
|
||||
JSON output;
|
||||
- maintained `examples/` files.
|
||||
- A general workflow language.
|
||||
- Structural module selection through ad hoc run flags.
|
||||
- Storing secrets in config files, diagnostics, manifests, or examples.
|
||||
|
||||
Reference in New Issue
Block a user