Skip to content

Commit 8a6833d

Browse files
ToolboxAidToolboxAid
authored
Merge pull request #83 from ToolboxAid/pr/26172-OWNER-032-historical-governance-consolidation
PR_26172_OWNER_032-historical-governance-consolidation
2 parents 6a0802f + f425234 commit 8a6833d

5 files changed

Lines changed: 266 additions & 0 deletions

File tree

‎docs_build/dev/ProjectInstructions/addendums/branch_context_governance.md‎

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
# Branch Context Governance
2+
3+
Status: Approved
4+
Owner: OWNER
5+
6+
## Purpose
7+
8+
Require Codex and teams to confirm branch context before changing files.
9+
10+
## Session Start Context
11+
12+
At the start of work, report or validate:
13+
14+
- current branch
15+
- expected branch
16+
- current commit
17+
- local/origin sync status
18+
- worktree status
19+
- active team
20+
- active assignment
21+
22+
## Stop Conditions
23+
24+
Stop and report before changing files when:
25+
26+
- current branch does not match the expected branch
27+
- local branch is behind or ahead unexpectedly
28+
- worktree has unrelated changes
29+
- active assignment is missing or unclear
30+
- active team does not match the branch or OWNER instruction
31+
- the requested work would modify files outside the approved scope
32+
33+
## Continuation Rule
34+
35+
After a branch is created, the branch remains the working context.
36+
37+
Do not automatically return to `main` after:
38+
39+
- commit
40+
- push
41+
- draft PR creation
42+
- validation
43+
- review updates
44+
- additional commits
45+
46+
Return to `main` only after the PR is merged, the branch is retired, or OWNER explicitly says to return to `main`.
47+
48+
## GitHub Authority
49+
50+
GitHub is authoritative for open PR state, merged PR state, review state, and remote branch state.
51+
52+
Local git state must be reconciled with GitHub before making OWNER-level cleanup decisions.

‎docs_build/dev/ProjectInstructions/addendums/branch_lock_governance.md‎

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
# Branch Lock Governance
2+
3+
Status: Approved
4+
Owner: OWNER
5+
6+
## Purpose
7+
8+
Keep active work attached to the correct assigned team, branch, and OWNER decision.
9+
10+
## Active Work Lock
11+
12+
- Work must occur on the assigned team or OWNER branch.
13+
- An assigned work item keeps its owner of record until complete or OWNER reassignment.
14+
- Work must not move to another team, branch, or PR without OWNER approval.
15+
- A team with no active assignment, active branch, or active PR is inactive.
16+
- Project Instructions must not assume a permanent team roster.
17+
18+
## Branch Rules
19+
20+
- Start from current `main`.
21+
- Pull latest `origin/main` before creating a work branch.
22+
- Keep work on the active branch until the PR is merged, the branch is retired, or OWNER says to return to `main`.
23+
- Do not commit directly to `main` unless OWNER explicitly approves.
24+
- Do not merge stale historical branches directly unless they are current, clean, still needed, and OWNER-approved.
25+
26+
## OWNER Override
27+
28+
OWNER may override a branch lock or team assignment.
29+
30+
When OWNER overrides, the PR or report must document:
31+
32+
- original assigned team or branch
33+
- override decision
34+
- reason for the override
35+
- new assigned team or branch, if any
36+
37+
## Protected Instruction Boundaries
38+
39+
Branch lock work must not silently delete, rewrite, or weaken protected Project Instructions guidance.
40+
41+
Protected guidance includes:
42+
43+
- source-of-truth rules
44+
- approved naming rules
45+
- status model rules
46+
- team assignment rules
47+
- PR workflow rules
48+
- Governance Phase 1 completion guidance
49+
50+
If protected guidance must change, OWNER approval is required.

‎docs_build/dev/ProjectInstructions/addendums/release_gate.md‎

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
# Release Gate Governance
2+
3+
Status: Approved
4+
Owner: OWNER
5+
6+
## Purpose
7+
8+
Define release gates for Project Instructions governance without making governance a blocker by default.
9+
10+
## Rule
11+
12+
Release gates are validation gates.
13+
They do not block development unless OWNER says governance is blocking.
14+
15+
## Project Instructions Release Gate
16+
17+
Before a governance, documentation, or administrative PR is merged, validate:
18+
19+
- Project Instructions folder exists.
20+
- Required source-of-truth files still exist.
21+
- Governance Phase 1 completion guidance remains intact.
22+
- PR workflow guidance remains intact.
23+
- Team assignment governance remains intact.
24+
- Active team registry guidance remains compatible with temporary active teams.
25+
- No protected Project Instructions guidance was deleted.
26+
- No permanent team roster or permanent discipline ownership was restored.
27+
- No direct-to-main commit rule was bypassed.
28+
- No application code changed unless the PR explicitly scopes application code.
29+
30+
## Required Source Files
31+
32+
The release gate should confirm these files when relevant to the PR:
33+
34+
- `docs_build/dev/ProjectInstructions/README.txt`
35+
- `docs_build/dev/ProjectInstructions/PROJECT_INSTRUCTIONS.md`
36+
- `docs_build/dev/ProjectInstructions/backlog/BACKLOG_MASTER.md`
37+
- `docs_build/dev/ProjectInstructions/addendums/governance_phase1_complete.md`
38+
- `docs_build/dev/ProjectInstructions/addendums/pr_workflow.md`
39+
- `docs_build/dev/ProjectInstructions/team_assignments/team_ownership.md`
40+
41+
## Validation Result
42+
43+
If a gate fails, stop and report:
44+
45+
- failing check
46+
- current branch
47+
- current worktree status
48+
- recommended OWNER action
49+
50+
If every relevant check passes, the PR may proceed through the standard PR workflow.

‎docs_build/dev/ProjectInstructions/addendums/team_start_and_release.md‎

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
# Team Start And Release Governance
2+
3+
Status: Approved
4+
Owner: OWNER
5+
6+
## Purpose
7+
8+
Preserve useful historical team-start and release-readiness rules in the current Governance Phase 1 model.
9+
10+
## Team Start Rule
11+
12+
OWNER identifies available teams when starting work.
13+
14+
Before a team starts, validate:
15+
16+
- current branch and expected branch are known
17+
- worktree is clean or unrelated changes are understood
18+
- `main` is current when a new branch is required
19+
- active assignment is selected or confirmed by OWNER
20+
- assigned team uses NATO phonetic naming
21+
- work remains with the assigned team until complete or OWNER reassignment
22+
23+
## Assignment Flow
24+
25+
For backlog-driven work:
26+
27+
1. Read `docs_build/dev/ProjectInstructions/backlog/BACKLOG_MASTER.md`.
28+
2. Select only the OWNER-approved backlog item.
29+
3. Use the approved status model from `status_model.md`.
30+
4. Create or use the approved team branch.
31+
5. Record active work in the active team registry when required.
32+
6. Open a draft PR after validation.
33+
7. Merge only through OWNER-approved PR workflow.
34+
35+
## Team Command Examples
36+
37+
Use these as naming examples, not as a permanent roster:
38+
39+
- Start Team Alfa
40+
- Start Team Bravo
41+
- Start Team Charlie
42+
- Start Team Delta
43+
- Start Team Echo
44+
- Start Team Foxtrot
45+
46+
## Release Readiness
47+
48+
A team or OWNER PR is release-ready when:
49+
50+
- scope matches the OWNER request
51+
- validation passes
52+
- no application code changed unless explicitly scoped
53+
- no protected Project Instructions guidance was deleted
54+
- branch context is correct
55+
- active assignment or OWNER ownership is clear
56+
- PR summary states the validation result
57+
58+
## Gate Behavior
59+
60+
Release readiness is a validation gate.
61+
It does not block unrelated development unless OWNER says governance is blocking.

‎docs_build/dev/ProjectInstructions/team_assignments/ACTIVE_TEAM_REGISTRY.md‎

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
# Active Team Registry
2+
3+
Status: Approved
4+
Owner: OWNER
5+
6+
## Purpose
7+
8+
Track temporary active teams without creating a permanent team roster.
9+
10+
## Rule
11+
12+
Active teams may change day to day.
13+
OWNER identifies available teams when starting work.
14+
Project Instructions must not assume a permanent team roster.
15+
16+
## Active Criteria
17+
18+
A team is active when it has at least one of:
19+
20+
- OWNER-assigned work
21+
- active branch
22+
- draft or open PR
23+
- active release or cleanup responsibility
24+
25+
If a team has no assignment, no active branch, and no active PR, it is inactive and may be omitted from the active registry.
26+
27+
## Registry
28+
29+
| Team | Active Assignment | Branch | PR | Status | OWNER Decision |
30+
|------|-------------------|--------|----|--------|----------------|
31+
| Team OWNER | none | none | none | Available | Governance Phase 1 complete |
32+
33+
## Update Rules
34+
35+
Update the registry when:
36+
37+
- OWNER starts a team
38+
- OWNER reassigns work
39+
- a branch is created
40+
- a PR is opened
41+
- a PR is merged
42+
- a branch is retired
43+
- a team becomes inactive
44+
45+
## Reassignment
46+
47+
Only OWNER may reassign work.
48+
Assigned team remains owner of record until complete or OWNER reassignment.
49+
50+
## Reset Rule
51+
52+
After closeout, the active registry may reset to no active non-OWNER teams.
53+
This reset does not delete historical ownership, PR history, or backlog source-of-truth records.

0 commit comments

Comments
 (0)