# Localization pipeline specifications

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.

## What stays human

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.

## Conventions

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 ubiquitous `The <component>`).
- `FR-NNN` ids 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-N` and 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.

Implementation plans and task breakdowns are separate artifacts and are deliberately absent here.

## Scope

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.