docs: align repair branch coordination authority
This commit is contained in:
@@ -55,6 +55,7 @@ Conflict-prevention rules:
|
|||||||
|
|
||||||
- `work/platform` owns `src/main/resources/db/migration/**`, Maven/dependency configuration, Compose, container build files, and CI workflow files. Other branches request schema changes instead of independently allocating migration versions.
|
- `work/platform` owns `src/main/resources/db/migration/**`, Maven/dependency configuration, Compose, container build files, and CI workflow files. Other branches request schema changes instead of independently allocating migration versions.
|
||||||
- `work/reports-ui` owns shared templates/fragments, shared design tokens, and general UI assets. Each domain branch owns its module-specific controllers and pages while consuming those shared fragments.
|
- `work/reports-ui` owns shared templates/fragments, shared design tokens, and general UI assets. Each domain branch owns its module-specific controllers and pages while consuming those shared fragments.
|
||||||
|
- A targeted repair shall use a clean, isolated `work/fix/<feature>/<what-fix>` branch and worktree from the taskmaster-verified current `main`. Do not use `work/<feature>/fix/<what-fix>`: the persistent `work/<feature>` ref already occupies that Git ref prefix.
|
||||||
- `work/tasks` exposes focused Task query/transfer operations required by Project workflows. `work/projects` owns the transaction that removes a member or completes a Project.
|
- `work/tasks` exposes focused Task query/transfer operations required by Project workflows. `work/projects` owns the transaction that removes a member or completes a Project.
|
||||||
- `work/platform` owns HolidayAPI credential storage and the tested HTTP client. `work/attendance` owns preview interpretation, selection, deduplication, import, and day-off effects.
|
- `work/platform` owns HolidayAPI credential storage and the tested HTTP client. `work/attendance` owns preview interpretation, selection, deduplication, import, and day-off effects.
|
||||||
- Attendance time and Task work time remain separate. No branch may make one mutate or prove the other.
|
- Attendance time and Task work time remain separate. No branch may make one mutate or prove the other.
|
||||||
|
|||||||
@@ -70,6 +70,11 @@ Use exactly these persistent branches unless the user changes the plan:
|
|||||||
| `work/attendance` | Policy, calendar, attendance, corrections, leave, metrics |
|
| `work/attendance` | Policy, calendar, attendance, corrections, leave, metrics |
|
||||||
| `work/reports-ui` | Shared Thymeleaf UI, dashboards, reports, exports |
|
| `work/reports-ui` | Shared Thymeleaf UI, dashboards, reports, exports |
|
||||||
|
|
||||||
|
For a targeted repair outside the next iteration, create a clean isolated
|
||||||
|
`work/fix/<feature>/<what-fix>` worktree from the taskmaster-verified current
|
||||||
|
`main`. Do not use `work/<feature>/fix/<what-fix>`: the persistent
|
||||||
|
`work/<feature>` ref already occupies that Git ref prefix.
|
||||||
|
|
||||||
Create one isolated worktree per branch. Give each implementation agent explicit ownership, tell it other agents share the repository, forbid reverting others' work, require medium-milestone local commits, and forbid push unless separately authorized.
|
Create one isolated worktree per branch. Give each implementation agent explicit ownership, tell it other agents share the repository, forbid reverting others' work, require medium-milestone local commits, and forbid push unless separately authorized.
|
||||||
|
|
||||||
Before any owner edits its module, require it to:
|
Before any owner edits its module, require it to:
|
||||||
|
|||||||
@@ -79,6 +79,7 @@ The product joins attendance oversight and Project delivery without pretending t
|
|||||||
3. **Attendance and Project work stay distinct.** The product may report them together, but one never derives or proves the other.
|
3. **Attendance and Project work stay distinct.** The product may report them together, but one never derives or proves the other.
|
||||||
4. **Deadlines are enforced at every path.** Scheduled workers improve timeliness, while request-time guards preserve correctness when scheduling is late.
|
4. **Deadlines are enforced at every path.** Scheduled workers improve timeliness, while request-time guards preserve correctness when scheduling is late.
|
||||||
5. **Prefer explicit, reviewable operations.** Feature-owned controller/service/repository flows, constrained state transitions, focused integrations, and shared report datasets serve clarity over speculative machinery.
|
5. **Prefer explicit, reviewable operations.** Feature-owned controller/service/repository flows, constrained state transitions, focused integrations, and shared report datasets serve clarity over speculative machinery.
|
||||||
|
6. **Fixes preserve branch ownership.** A targeted repair uses a clean `work/fix/<feature>/<what-fix>` branch from verified `main`, not `work/<feature>/fix/<what-fix>`; persistent `work/<feature>` refs already occupy that Git ref prefix.
|
||||||
|
|
||||||
## Accessibility & Inclusion
|
## Accessibility & Inclusion
|
||||||
|
|
||||||
|
|||||||
@@ -9,20 +9,23 @@ feature-branch ownership areas.
|
|||||||
## Implementation steps
|
## Implementation steps
|
||||||
|
|
||||||
1. Prove RED: the contributor guides lack the realizable repair-branch name.
|
1. Prove RED: the contributor guides lack the realizable repair-branch name.
|
||||||
2. Add one branch rule everywhere contributors, coordinators, and requirement
|
2. Add one branch rule to contributor guides, design records, plans, and tracked
|
||||||
reviewers rely on it: `work/fix/<feature>/<what-fix>` from verified `main`.
|
coordination authority: `work/fix/<feature>/<what-fix>` from verified
|
||||||
|
`main`.
|
||||||
3. State why `work/<feature>/fix/<what-fix>` is invalid while its persistent
|
3. State why `work/<feature>/fix/<what-fix>` is invalid while its persistent
|
||||||
`work/<feature>` ref exists.
|
`work/<feature>` ref exists.
|
||||||
4. Regenerate the local SRS after amending the existing operational requirement;
|
4. Regenerate the local SRS after amending the existing operational requirement;
|
||||||
do not add a requirement ID or a use case.
|
do not add a requirement ID or a use case.
|
||||||
5. Prove GREEN with the executable six-guide regression, requirement/use-case
|
5. Prove GREEN with the executable six-guide regression that independently
|
||||||
counts, local-link resolution, and an immutable base-to-candidate whitespace
|
rejects a positive nested-form recommendation in every guide,
|
||||||
check. Commit the tracked guidance locally; do not push or merge.
|
coordination-authority consistency, requirement/use-case counts, local-link
|
||||||
|
resolution, and an immutable base-to-candidate whitespace check. Commit the
|
||||||
|
tracked guidance locally; do not push or merge.
|
||||||
|
|
||||||
## Exit criteria
|
## Exit criteria
|
||||||
|
|
||||||
- The tracked guides, design record, implementation plan, and evidence record
|
- The tracked guides, design record, implementation plan, root coordination
|
||||||
agree on the same repair-branch spelling.
|
authority, and evidence record agree on the same repair-branch spelling.
|
||||||
- The local authoritative, explained, simple, and generated SRS catalogues keep
|
- The local authoritative, explained, simple, and generated SRS catalogues keep
|
||||||
exactly 260 unique requirement IDs and the SRS keeps 14 use cases.
|
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
|
- The forbidden nested form is documented only as forbidden, not as a usable
|
||||||
|
|||||||
@@ -33,6 +33,8 @@ push or merge without separate authority.
|
|||||||
## Validation
|
## Validation
|
||||||
|
|
||||||
The executable documentation validator checks the exact approved statement in
|
The executable documentation validator checks the exact approved statement in
|
||||||
each tracked guide and rejects an injected positive nested-branch recommendation.
|
each of the six tracked guides and independently rejects an injected positive
|
||||||
The evidence record also verifies requirement counts, generated SRS use-case
|
nested-branch recommendation in every guide. The copied root coordination
|
||||||
count, and local Markdown links.
|
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.
|
||||||
|
|||||||
Reference in New Issue
Block a user