docs: define durable fix branch workflow

2026-08-15 14:18:13 +07:00
parent 8be1b754e1
commit f013ad7707
6 changed files with 87 additions and 0 deletions
@@ -0,0 +1,37 @@
+# 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.
+
+## 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 documentation evidence record checks the required spelling, rejects the
+nested form, verifies requirement counts and generated SRS use-case count, and
+resolves local Markdown links.