# Design Record: Durable Fix-Branch Workflow

- **Date:** 2026-08-15
- **Status:** Accepted
- **Related plan:** [Access, Navigation, Icon, and Intern Picker Fix Plan](../plans/2026-08-15-access-navigation-icon-intern-picker.md)

## Context

The repository keeps five persistent feature refs: `work/platform`,
`work/projects`, `work/tasks`, `work/attendance`, and `work/reports-ui`.
A proposed nested repair name such as `work/platform/fix/example` cannot coexist
with the existing `work/platform` ref because Git cannot use one ref as both a
leaf and a prefix.

## Decision

Use `work/fix/<feature>/<what-fix>` for each targeted repair. Create its clean,
isolated worktree from the taskmaster-verified current `main`. The `<feature>`
segment identifies the owning persistent area; it does not nest below that
persistent branch.

The forbidden form is `work/<feature>/fix/<what-fix>`. A repair owner preserves
other worktrees, records RED and GREEN evidence, commits locally, and does not
push or merge without separate authority.

Every targeted repair starts from the taskmaster-verified latest `main`, uses TDD RED → GREEN, adds Javadoc during implementation, records companion evidence, undergoes independent review, and uses a normal, non-force merge only when separately authorized.

## Consequences

- Persistent feature branches remain available for their iteration ownership.
- A repair can be reviewed and handed off as one immutable branch head.
- Contributor documentation, local coordination authority, and generated SRS
  traceability use the same spelling.

## Validation

The executable documentation validator checks the exact approved statement in
each of the six tracked guides and independently rejects an injected positive
nested-branch recommendation in every guide. The copied root coordination
authority uses the same rule and is checked separately for consistency. The
evidence record also verifies requirement counts, generated SRS use-case count,
and local Markdown links.