2.0 KiB
Design Record: Durable Fix-Branch Workflow
- Date: 2026-08-15
- Status: Accepted
- Related plan: Access, Navigation, Icon, and Intern Picker Fix Plan
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.