requirement-forge-refiner

# Requirement Forge Refiner ## What This Produces - **Output**: `.lattice/standards/requirement-standards.md` (or custom path from `.lattice/config.yaml` → `paths.requirement_standards`) - **Two modes**: - **Overlay** (`mode: overlay`): A slim document containing only sections that differ from the built-in defaults. The `requirement-quality` atom reads its embedded `defaults.md` first, then applies this document's sections on top. This is the expected common case. - **Override** (`mode: override`): A comprehensive standalone document that fully replaces the atom's embedded defaults. For teams whose product process differs fundamentally from the defaults. - **Default mode**: Overlay — produces only what the team wants to change - **Config key**: `paths.requirement_standards` in `.lattice/config.yaml` - **Consumed by**: `requirement-quality` atom (via config resolution) → `requirement-forge` molecule (composes the atom) - **Template**: Read `./assets/template.md` for the full document structure, default content, and interview guidance comments ## Scope Clarification This refiner defines how requirements are *structured and expressed* for this project. It does not define: - What to build (that is the requirement-forge molecule's job) - Architecture or technical design (that is the architecture-refiner's job) - Domain modeling patterns (that is the ddd-refiner's job) The standards produced here answer: what is an epic, what is a feature, what is a scenario, how are ACs ...