docs: define durable fix branch workflow
This commit is contained in:
@@ -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.
|
||||
Reference in New Issue
Block a user