Seven feature specifications covering the automation of the pt-BR localization pipeline, from change detection through to review handoff. Each is independently implementable and independently useful; they are numbered in dependency order, not priority order.
| ID | Feature | Depends on |
|---|---|---|
| 001 | Localization change detection across all reader-visible surfaces | — |
| 002 | Localization coverage and reachability integrity | — |
| 003 | Localization work orders | 001 |
| 004 | Deterministic translation from approved memory | 003 |
| 005 | Constrained translation of novel content | 004, 006 |
| 006 | Verification of translated output before review | — |
| 007 | Review handoff and approved-translation capture | 006 |
001, 002 and 006 have no dependencies and deliver value alone. 005 is deliberately gated on 006: generated translation should not be attempted until verification is proven, including its negative tests.
Content approval by a native reviewer, final merge, arbitration of escalated term decisions, and all source-language fixes. These are governance positions from CLAUDE.md §3 and §9, not automation gaps.
House SDD form, per the Ripple SDD constitution and lint-agent:
- EARS phrasing for functional requirements:
shall, with an explicit trigger (When/While/Where/If…then, or the ubiquitousThe <component>). FR-NNNids stay bare — they never leave their own spec.- Acceptance criteria carry the feature-directory prefix,
<feature-directory-name>-AC-N, because those ids travel into tasks, commits and test markers. - An FR never cites an AC id. Traceability runs one way.
- Deferred edge cases use
DEF-Nand must state a reason. A decision that changes required behaviour belongs in the requirements, not here.
Checked against the five lint categories (weasel words, unbounded quantifiers, undefined edge cases, implementation leakage, bare identifiers) and the EARS requirement syntax: zero findings across 43 requirements and 35 criteria.
Each feature directory also carries a plan.md and a tasks.md. They are separate artifacts from the specification: spec.md states required behaviour and is the reviewable contract, while the plan and task breakdown record how it was built and may go stale as the code moves. Read spec.md for what the pipeline must do.
These specifications are written to be product-agnostic: they describe a localized set, a source language and a target language, and name no product, version or locale. The pipeline that implements them is not yet product-agnostic. Its scope declaration carries a single locale and a single flat file list, and the governance file currently excludes every product other than Payments Direct 2.0 from translation.
Extending the pipeline across products is therefore a separate piece of work and is not specified here. It would need scope entries keyed by product, version and locale rather than one flat list, and the exclusion in CLAUDE.md §1 lifted or made per-scope. Specification 002 defers multi-locale behaviour; multi-product behaviour is unspecified.