Element reuse

Element reuse (Gate A)

When you reuse an existing user-visible element on a new surface, you risk shipping the same intent into a context it wasn't authored for. The canonical scenario: a greeting string lives in the codebase, authored for a first-touch wizard. A developer building a daily-home widget needs a greeting line, greps, finds it, reuses it. The diff looks clean — an existing key, the cheapest-looking change. The user then sees "Hi — I'm your assistant, let me show you around" every single morning. Lint passes (the import resolves), code review passes (the diff is fine in isolation), visual review of the surface alone passes (the copy "reads OK" if you don't know the journey). It's only visible if someone asks: what context was this authored for, and does it match this new surface? That question is this gate.

Run at both moments:

• Design time — Section 0a of the spec, for every existing element the spec proposes to reuse.
• Audit time — first action when any borrowed string/component is detected on the captured surface. This catches implementation drift: the spec said "fresh string authored for daily-driver", but the implementation reached for the nearest existing string to save time. The design-time gate saw new authorship; the audit-time gate catches the silent substitution.

Procedure

Step 1 — Locate the existing usage

Grep for the existing usage of the proposed element (a string key, a component import, a copy pattern), across this project's user-visible code directories (discover them at runtime — translation files, components, screens):

grep -rn "<exact-string-or-key>" <user-visible-code-dirs>

For each hit, capture: file:line, the surface it fires on (read the surrounding code to confirm), the role it plays there (intro / confirmation / CTA / status / error), and when the user sees it.

No grep evidence → no finding. "I think this is reused somewhere" without a file:line is not a verdict-eligible claim.

Step 2 — Classify both contexts

Classify both the existing usage site and the proposed reuse site as exactly one surface type — first-touch / daily-driver / settings / error / promotional / bridge. (This is the journey-map taxonomy; the gate is downstream of it.) If the target surface hasn't been mapped yet, stop and build the journey map first — without it the gate is guessing.

Step 3 — Apply the verdict matrix

A fixed lookup; the cells are universal truths about surface-type fit, not project-tunable:

Existing context → Proposed context	Verdict
first-touch → daily-driver	REJECT — write new copy
first-touch → settings	REJECT — write new copy
first-touch → error	REJECT — error surfaces have their own register
first-touch → first-touch (different stage)	CAUTION — re-introduction is itself a pattern
daily-driver → daily-driver (similar role)	OK
daily-driver → first-touch	OK — welcome surfaces can inherit ambient copy
daily-driver → settings	OK if neutral; REJECT if it implies first-use
settings → daily-driver	REJECT — settings register is too formal for active surfaces
settings → settings	OK
error → any non-error	REJECT — error register doesn't translate
any → promotional	CAUTION — promotional surfaces interrupt; copy must earn the interrupt
any → bridge	REJECT — bridges need authored transition copy, not borrowed

• REJECT = do not ship the reuse; author new copy that fits the proposed context.
• OK = proceed.
• CAUTION = explicit judgment call; name in writing why the reuse is intentional. An empty CAUTION row is functionally a REJECT.

If you find yourself wanting to "soften" a matrix cell, the real problem is almost always unclear surface classification — re-examine the classification, not the verdict.

Step 4 — Document the audit

For designs, append a section to the spec with one row per proposed reuse:

## Section 0a — Element-reuse audit

| Proposed reuse | Existing in (file:line) | Existing context | New context | Verdict |
|---|---|---|---|---|
| <key or component> | <path:line> | <type> | <type> | OK / CAUTION / REJECT |

For audits, surface findings inline as a gap, tagged at the project's highest severity tier — mismatched-context reuse is a real user-visible bug, not a polish concern.

If no reuse was proposed, say so explicitly — "no element reuse proposed; all strings/components are new". Silence is not a no-reuse claim. And if the OK count is unusually high (most copy is borrowed), surface that as its own meta-finding: the project's voice may be over-DRY at the cost of context fit.

Non-negotiables

REJECT verdicts are binding — refuse to ship work where a REJECT was overridden without authoring new copy ("the user might not notice" is wrong; the user does notice, and that's the whole bug class). Grep evidence with file:line is required for any verdict. CAUTION demands a written rationale. The gate applies to any user-visible element with an authored intent — strings, components, copy patterns, narration variants — not just translation strings.