Skip to content

Commit 6a0802f

Browse files
ToolboxAidToolboxAid
authored
Merge pull request #82 from ToolboxAid/pr/26172-OWNER-031-governance-phase1-closeout
PR_26172_OWNER_031-governance-phase1-closeout
2 parents 0916041 + 622161a commit 6a0802f

5 files changed

Lines changed: 259 additions & 0 deletions

File tree

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

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -33,3 +33,44 @@ PRs that change backlog status or Build Path status must document:
3333
- matching Build Path tile changed
3434
- phase percentage before and after
3535
- skipped sync, if any, with reason
36+
37+
## Governance Phase 1 Closeout
38+
39+
Status: Approved
40+
Owner: OWNER
41+
42+
## Source of Truth
43+
44+
BACKLOG_MASTER.md is the source of truth for work item status.
45+
46+
## Tile Status Rules
47+
48+
- Build Path tile status derives from backlog status.
49+
- Game Journey tile status derives from backlog status.
50+
- Manual tile status changes are prohibited.
51+
- Tiles must not maintain independent status state.
52+
- Status changes must be made at the backlog/source level first.
53+
- Visual indicators must synchronize from the approved status model.
54+
55+
## Approved Status Model
56+
57+
- [ ] Planned
58+
- [.] Wireframe
59+
- [-] Building
60+
- [x] Complete
61+
- [!] Blocked
62+
- [D] Deprecated
63+
64+
## Overlay Rules
65+
66+
- Planned = 70% black overlay
67+
- Wireframe = 80% black overlay
68+
- Building = 90% black overlay
69+
- Complete = 0% overlay / fully transparent
70+
- Blocked = yellow indicator
71+
- Deprecated = red indicator
72+
73+
## Completion
74+
75+
Completion comes from backlog status.
76+
A Build Path or Game Journey item is complete only when the backlog item is marked complete.

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

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
# Governance Phase 1 Complete
2+
3+
Status: Approved
4+
Owner: OWNER
5+
6+
## Declaration
7+
8+
Governance Phase 1 is complete.
9+
10+
## Completed Foundation
11+
12+
The following governance areas are now established:
13+
14+
- Status Model
15+
- Batch Governance Mode
16+
- PostgreSQL-only persistence direction
17+
- Table-first UI standard
18+
- Referenced Asset Protection
19+
- Tool Imagery Standards
20+
- Team Assignment Governance
21+
- PR Workflow Governance
22+
- Build Path Synchronization Governance
23+
- Naming Registry Governance
24+
- Project Instructions read-first guidance
25+
26+
## Operating Mode
27+
28+
Game Foundry Studio now moves into Execution Phase.
29+
GFS moves into Execution Phase.
30+
31+
Governance becomes maintenance-only unless:
32+
33+
- OWNER makes a new decision
34+
- a new platform capability requires governance
35+
- a conflict is discovered
36+
- a team is blocked by missing governance
37+
38+
## Rule
39+
40+
Development should not wait on additional governance unless OWNER says governance is blocking.

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

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
# Naming Registry Governance
2+
3+
Status: Approved
4+
Owner: OWNER
5+
6+
## Purpose
7+
8+
Capture approved Game Foundry Studio names to reduce rename churn.
9+
10+
## Approved Product Names
11+
12+
- Game Foundry Studio
13+
- Build. Play. Share.
14+
- Game Journey
15+
- Game Hub
16+
- Build Path
17+
- Idea Board
18+
- Messages
19+
- Emotion Profiles
20+
- TTS Profiles
21+
- Text To Speech
22+
- System Health
23+
- Project Instructions
24+
- BACKLOG_MASTER.md
25+
26+
## Approved Environment Names
27+
28+
- Local - VS Code environment
29+
- DEV - local Docker
30+
- IST - local Docker
31+
- UAT - VPS
32+
- PROD - VPS
33+
34+
## Approved Package Terms
35+
36+
- Export Project Package
37+
- Import Project Package
38+
- Validate Project Package
39+
- .gfsp
40+
- Game Foundry Studio Project
41+
42+
## Approved Team Naming
43+
44+
Teams must use NATO phonetic naming.
45+
46+
Examples:
47+
- Team Alfa
48+
- Team Bravo
49+
- Team Charlie
50+
- Team Delta
51+
- Team Echo
52+
- Team Foxtrot
53+
54+
## Rule
55+
56+
Do not rename approved terms without OWNER approval.

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

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
# PR Workflow Governance
2+
3+
Status: Approved
4+
Owner: OWNER
5+
6+
## Purpose
7+
8+
Define the standard pull request workflow for Game Foundry Studio.
9+
10+
## Standard Flow
11+
12+
1. Start from main.
13+
2. Pull latest origin/main.
14+
3. Verify clean worktree.
15+
4. Create a PR branch.
16+
5. Make scoped changes only.
17+
6. Validate the change.
18+
7. Commit with a clear OWNER/team message.
19+
8. Push the branch.
20+
9. Open a draft PR.
21+
10. Review the PR.
22+
11. OWNER approves merge.
23+
12. Merge to main.
24+
13. Pull latest main before starting the next PR.
25+
26+
## Rules
27+
28+
- Direct commits to main are prohibited unless OWNER explicitly approves.
29+
- Draft PRs are preferred until validation is complete.
30+
- Each PR must have a clear scope.
31+
- Do not mix unrelated scopes.
32+
- Do not start dependent PRs until the required base PR is merged.
33+
- Always return to main before starting the next PR.
34+
- If validation fails, stop and report.
35+
- If conflict occurs, stop and report.
36+
- If OWNER decision is required, stop and report.
37+
38+
## Batch Governance Mode
39+
40+
For governance, documentation, and administrative work, use Batch Governance Mode by default.
41+
42+
Use stacked sequential PRs only when dependency order requires it.
43+
44+
## OWNER Shortcut: PRs
45+
46+
Keyword:
47+
PRs
48+
49+
Meaning:
50+
Generate the complete stacked sequential Codex PR chain required to finish the current workstream.
51+
52+
Applies to:
53+
- OWNER
54+
- Team Alfa
55+
- Team Bravo
56+
- Team Charlie
57+
- Any future NATO-named team
58+
59+
Behavior:
60+
- Determine completed work.
61+
- Determine open work.
62+
- Determine remaining work.
63+
- Batch related work where practical.
64+
- Generate the complete PR chain.
65+
- Include start gates.
66+
- Include validation.
67+
- Include commit messages.
68+
- Include PR names.
69+
- Include merge dependencies.
70+
71+
Default assumptions:
72+
- Batch Governance Mode
73+
- Throughput-first execution
74+
- Minimal conversational checkpoints
75+
76+
Stop only for:
77+
- Start gate failure
78+
- Merge conflict
79+
- Validation failure
80+
- OWNER decision

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

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -42,3 +42,45 @@
4242
## Rule
4343

4444
Ownership may only be reassigned by OWNER governance.
45+
46+
## Current Team Assignment Governance
47+
48+
This current rule supersedes any prior permanent discipline ownership assumptions in this file.
49+
50+
## Team Naming
51+
52+
Team names must use NATO phonetic naming.
53+
54+
Examples:
55+
- Team Alfa
56+
- Team Bravo
57+
- Team Charlie
58+
- Team Delta
59+
- Team Echo
60+
- Team Foxtrot
61+
62+
## Assignment Rule
63+
64+
Work stays with the assigned team until either:
65+
66+
1. Complete
67+
68+
OR
69+
70+
2. OWNER says move it.
71+
72+
Work stays with the assigned team until complete or OWNER says move it.
73+
74+
Only OWNER may reassign work.
75+
76+
## Owner of Record
77+
78+
Once a backlog item is assigned, the assigned team is the owner of record until completion or OWNER reassignment.
79+
80+
## Active Teams
81+
82+
Active teams may change from day to day.
83+
84+
OWNER will identify which teams are available when starting team work.
85+
86+
Project Instructions must not assume a permanent team roster.

0 commit comments

Comments
 (0)