67 lines
3.2 KiB
Markdown
67 lines
3.2 KiB
Markdown
|
# Stage-Specific Glossary Inputs
|
||
|
|
|
||
|
|
**Updated:** 2026-11-07
|
||
|
|
|
||
|
|
**Status:** Accepted scope for the next Audita major release. Initial outline;
|
||
|
|
detailed design and implementation remain pending. The
|
||
|
|
[master roadmap](library-adoption.md) owns sequencing and release completion.
|
||
|
|
|
||
|
|
## Baseline and Target
|
||
|
|
|
||
|
|
The current [CLI](../cli.md) accepts one glossary input for a processing run.
|
||
|
|
The [pipeline configuration](../config.md) supports repeated glossary stages,
|
||
|
|
but does not select a different glossary input for each occurrence.
|
||
|
|
|
||
|
|
Allow operators to run ordered glossary stages against different glossary inputs
|
||
|
|
within one processing run. For a D&D transcript, the first glossary stage can
|
||
|
|
use `party.yml` and the second can use `spells.yml`. Each stage uses its selected
|
||
|
|
glossary and processes the transcript resulting from earlier stages. Operators
|
||
|
|
need not combine those inputs into one glossary or run Audita separately for
|
||
|
|
each pass.
|
||
|
|
|
||
|
|
This example describes the intended behavior, not a selected configuration syntax.
|
||
|
|
The major-release policy permits a hard cutover; the current single-glossary CLI
|
||
|
|
and pipeline representation do not constrain the target design.
|
||
|
|
|
||
|
|
## Sequencing and Work Outline
|
||
|
|
|
||
|
|
Implement after ConfigKit, PromptKit, CommandKit, and ReleaseKit adoption, and
|
||
|
|
before final release validation and preparation. This lets the feature use the
|
||
|
|
adopted configuration and CLI conventions and avoids adapting it twice. Keep the
|
||
|
|
requirement visible during library design without expanding those migrations
|
||
|
|
into feature implementation.
|
||
|
|
|
||
|
|
1. Define how a stage selects its glossary, how input paths resolve, and how
|
||
|
|
defaults and CLI selection interact with stage configuration.
|
||
|
|
2. Carry the selected glossary through loading, stage execution, proposal
|
||
|
|
generation, and validation. Review glossary consumers outside the glossary
|
||
|
|
module so their input semantics are deliberate.
|
||
|
|
3. Make repeated stages and their selected inputs understandable in inspection,
|
||
|
|
diagnostics, and reports. Account for all consumed glossary files in input
|
||
|
|
handling and output-collision protection.
|
||
|
|
4. Verify the selected behavior and update configuration, CLI, input contracts,
|
||
|
|
pipeline documentation, maintained examples, and hard-cutover guidance as the
|
||
|
|
implementation lands.
|
||
|
|
|
||
|
|
## Acceptance Direction
|
||
|
|
|
||
|
|
Use distinct party and spell fixtures with controlled model responses to show
|
||
|
|
that each stage receives the intended glossary, that one stage's input does not
|
||
|
|
leak into another, and that the second stage sees the first stage's accepted
|
||
|
|
transcript changes. Verify meaningful errors for invalid selections or inputs,
|
||
|
|
and retain the selected domain validation and partial-success behavior. Exact
|
||
|
|
test cases follow the design; live provider calls are unnecessary.
|
||
|
|
|
||
|
|
## Open Decisions
|
||
|
|
|
||
|
|
Detailed choices are deliberately deferred to the feature-design discussion:
|
||
|
|
|
||
|
|
- Stage representation, glossary references versus inline file paths, and
|
||
|
|
defaults or CLI overrides.
|
||
|
|
- Which glossary is used by other modules and validators, including protected
|
||
|
|
term checks and overlapping terms across inputs.
|
||
|
|
- Stage identity and input attribution in inspection, errors, and reports.
|
||
|
|
|
||
|
|
The capability and its inclusion in the next major release are settled. These
|
||
|
|
questions refine the design; they do not reopen whether to deliver the feature.
|