docs: define durable fix branch workflow

This commit is contained in:
sechmachine
2026-08-15 14:18:13 +07:00
parent 8be1b754e1
commit f013ad7707
6 changed files with 87 additions and 0 deletions
@@ -0,0 +1,29 @@
# Access, Navigation, Icon, and Intern Picker Fix Plan
## Scope
Record the durable workflow for the targeted fixes in this plan. This plan does
not change product behavior, dependencies, schemas, or the five persistent
feature-branch ownership areas.
## Implementation steps
1. Prove RED: the contributor guides lack the realizable repair-branch name.
2. Add one branch rule everywhere contributors, coordinators, and requirement
reviewers rely on it: `work/fix/<feature>/<what-fix>` from verified `main`.
3. State why `work/<feature>/fix/<what-fix>` is invalid while its persistent
`work/<feature>` ref exists.
4. Regenerate the local SRS after amending the existing operational requirement;
do not add a requirement ID or a use case.
5. Prove GREEN with exact searches, requirement/use-case counts, local-link
resolution, and whitespace validation. Commit the tracked guidance locally;
do not push or merge.
## Exit criteria
- The tracked guides, design record, implementation plan, and evidence record
agree on the same repair-branch spelling.
- The local authoritative, explained, simple, and generated SRS catalogues keep
exactly 260 unique requirement IDs and the SRS keeps 14 use cases.
- The forbidden nested form is documented only as forbidden, not as a usable
branch name.
@@ -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.