PR_26172_OWNER_031-governance-phase1-closeout

docs_build/dev/ProjectInstructions/addendums/build_path_sync.md

@@ -33,3 +33,44 @@ PRs that change backlog status or Build Path status must document:
 - matching Build Path tile changed
 - phase percentage before and after
 - skipped sync, if any, with reason
+
+## Governance Phase 1 Closeout
+
+Status: Approved  
+Owner: OWNER
+
+## Source of Truth
+
+BACKLOG_MASTER.md is the source of truth for work item status.
+
+## Tile Status Rules
+
+- Build Path tile status derives from backlog status.
+- Game Journey tile status derives from backlog status.
+- Manual tile status changes are prohibited.
+- Tiles must not maintain independent status state.
+- Status changes must be made at the backlog/source level first.
+- Visual indicators must synchronize from the approved status model.
+
+## Approved Status Model
+
+- [ ] Planned
+- [.] Wireframe
+- [-] Building
+- [x] Complete
+- [!] Blocked
+- [D] Deprecated
+
+## Overlay Rules
+
+- Planned = 70% black overlay
+- Wireframe = 80% black overlay
+- Building = 90% black overlay
+- Complete = 0% overlay / fully transparent
+- Blocked = yellow indicator
+- Deprecated = red indicator
+
+## Completion
+
+Completion comes from backlog status.
+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

@@ -0,0 +1,40 @@
+# Governance Phase 1 Complete
+
+Status: Approved  
+Owner: OWNER
+
+## Declaration
+
+Governance Phase 1 is complete.
+
+## Completed Foundation
+
+The following governance areas are now established:
+
+- Status Model
+- Batch Governance Mode
+- PostgreSQL-only persistence direction
+- Table-first UI standard
+- Referenced Asset Protection
+- Tool Imagery Standards
+- Team Assignment Governance
+- PR Workflow Governance
+- Build Path Synchronization Governance
+- Naming Registry Governance
+- Project Instructions read-first guidance
+
+## Operating Mode
+
+Game Foundry Studio now moves into Execution Phase.
+GFS moves into Execution Phase.
+
+Governance becomes maintenance-only unless:
+
+- OWNER makes a new decision
+- a new platform capability requires governance
+- a conflict is discovered
+- a team is blocked by missing governance
+
+## Rule
+
+Development should not wait on additional governance unless OWNER says governance is blocking.

docs_build/dev/ProjectInstructions/addendums/naming_registry.md

@@ -0,0 +1,56 @@
+# Naming Registry Governance
+
+Status: Approved  
+Owner: OWNER
+
+## Purpose
+
+Capture approved Game Foundry Studio names to reduce rename churn.
+
+## Approved Product Names
+
+- Game Foundry Studio
+- Build. Play. Share.
+- Game Journey
+- Game Hub
+- Build Path
+- Idea Board
+- Messages
+- Emotion Profiles
+- TTS Profiles
+- Text To Speech
+- System Health
+- Project Instructions
+- BACKLOG_MASTER.md
+
+## Approved Environment Names
+
+- Local - VS Code environment
+- DEV - local Docker
+- IST - local Docker
+- UAT - VPS
+- PROD - VPS
+
+## Approved Package Terms
+
+- Export Project Package
+- Import Project Package
+- Validate Project Package
+- .gfsp
+- Game Foundry Studio Project
+
+## Approved Team Naming
+
+Teams must use NATO phonetic naming.
+
+Examples:
+- Team Alfa
+- Team Bravo
+- Team Charlie
+- Team Delta
+- Team Echo
+- Team Foxtrot
+
+## Rule
+
+Do not rename approved terms without OWNER approval.

docs_build/dev/ProjectInstructions/addendums/pr_workflow.md

@@ -0,0 +1,80 @@
+# PR Workflow Governance
+
+Status: Approved  
+Owner: OWNER
+
+## Purpose
+
+Define the standard pull request workflow for Game Foundry Studio.
+
+## Standard Flow
+
+1. Start from main.
+2. Pull latest origin/main.
+3. Verify clean worktree.
+4. Create a PR branch.
+5. Make scoped changes only.
+6. Validate the change.
+7. Commit with a clear OWNER/team message.
+8. Push the branch.
+9. Open a draft PR.
+10. Review the PR.
+11. OWNER approves merge.
+12. Merge to main.
+13. Pull latest main before starting the next PR.
+
+## Rules
+
+- Direct commits to main are prohibited unless OWNER explicitly approves.
+- Draft PRs are preferred until validation is complete.
+- Each PR must have a clear scope.
+- Do not mix unrelated scopes.
+- Do not start dependent PRs until the required base PR is merged.
+- Always return to main before starting the next PR.
+- If validation fails, stop and report.
+- If conflict occurs, stop and report.
+- If OWNER decision is required, stop and report.
+
+## Batch Governance Mode
+
+For governance, documentation, and administrative work, use Batch Governance Mode by default.
+
+Use stacked sequential PRs only when dependency order requires it.
+
+## OWNER Shortcut: PRs
+
+Keyword:
+PRs
+
+Meaning:
+Generate the complete stacked sequential Codex PR chain required to finish the current workstream.
+
+Applies to:
+- OWNER
+- Team Alfa
+- Team Bravo
+- Team Charlie
+- Any future NATO-named team
+
+Behavior:
+- Determine completed work.
+- Determine open work.
+- Determine remaining work.
+- Batch related work where practical.
+- Generate the complete PR chain.
+- Include start gates.
+- Include validation.
+- Include commit messages.
+- Include PR names.
+- Include merge dependencies.
+
+Default assumptions:
+- Batch Governance Mode
+- Throughput-first execution
+- Minimal conversational checkpoints
+
+Stop only for:
+- Start gate failure
+- Merge conflict
+- Validation failure
+- OWNER decision

docs_build/dev/ProjectInstructions/team_assignments/team_ownership.md

@@ -42,3 +42,45 @@
 ## Rule
 
 Ownership may only be reassigned by OWNER governance.
+
+## Current Team Assignment Governance
+
+This current rule supersedes any prior permanent discipline ownership assumptions in this file.
+
+## Team Naming
+
+Team names must use NATO phonetic naming.
+
+Examples:
+- Team Alfa
+- Team Bravo
+- Team Charlie
+- Team Delta
+- Team Echo
+- Team Foxtrot
+
+## Assignment Rule
+
+Work stays with the assigned team until either:
+
+1. Complete
+
+OR
+
+2. OWNER says move it.
+
+Work stays with the assigned team until complete or OWNER says move it.
+
+Only OWNER may reassign work.
+
+## Owner of Record
+
+Once a backlog item is assigned, the assigned team is the owner of record until completion or OWNER reassignment.
+
+## Active Teams
+
+Active teams may change from day to day.
+
+OWNER will identify which teams are available when starting team work.
+
+Project Instructions must not assume a permanent team roster.