PR_26172_OWNER_017-project-instructions-bootstrap-install

docs_build/dev/ProjectInstructions/PROJECT_INSTRUCTIONS.md

@@ -0,0 +1,46 @@
+# Project Instructions Operating System
+
+Read `README.txt` first.
+
+This file is the root index for the append-first Project Instructions operating system under `docs_build/dev/ProjectInstructions/`.
+
+## Purpose
+
+The Project Instructions operating system provides additive governance for:
+
+- backlog ownership
+- team assignments
+- multi-team branch and scope rules
+- Build Path status synchronization
+- tile overlay status behavior
+- deprecation workflow
+- archive and history preservation
+
+## Preservation
+
+Existing Project Instructions remain preserved in their current locations. This operating system adds structure without deleting or rewriting existing documentation.
+
+## Folders
+
+- `addendums/` contains additive governance rules.
+- `backlog/` contains the central backlog file, `BACKLOG_MASTER.md`.
+- `team_assignments/` contains current team assignment records.
+- `deprecation/` contains deprecation workflow documentation.
+- `archive/` contains retained reference material.
+- `archive/history/` contains timestamped history snapshots.
+
+## Merge Control
+
+No PR in this operating system is merged without explicit owner approval.
+
+## OWNER Governance
+
+OWNER override wording:
+
+`OWNER override approved: <reason>`
+
+OWNER follows the same safety rules:
+- One active OWNER branch at a time.
+- One active OWNER assignment at a time.
+- OWNER may override team locks, but may not silently delete, rewrite, or remove protected instructions.
+- OWNER override must be explicitly documented.

docs_build/dev/ProjectInstructions/README.txt

@@ -0,0 +1,28 @@
+Read this file first.
+
+Folder purpose:
+This folder is the append-first Project Instructions operating system for Game Foundry Studio. It organizes active governance, backlog, team assignment, deprecation, and history material without deleting or rewriting the existing Project Instructions files elsewhere in the repository.
+
+Preservation rules:
+Preserve all existing documentation. Add new files or append explicit references unless the owner explicitly approves deletion or rewrite. When a conflict appears, stop, explain the conflict, and request owner approval before changing existing instruction text.
+
+Backlog workflow:
+Backlog work is tracked under backlog/. BACKLOG_MASTER.md is the planned source for backlog item status, notes, and references. Backlog item text is treated as immutable once created; status and notes may change under the governance addendums.
+
+Team assignment workflow:
+Team assignments are tracked under team_assignments/. A team pulls work from BACKLOG_MASTER.md, marks the item building when assigned, and records the active assignment under the owning team. Teams work only on assigned items unless an OWNER override explicitly changes the assignment.
+
+No direct commits to main:
+Do not commit directly to main unless the owner explicitly instructs that exception. Normal work must use PR branches, draft PRs, validation evidence, and owner-controlled merge approval.
+
+OWNER override rule:
+An OWNER override must use this wording:
+OWNER override approved: <reason>
+
+The override must explain why normal team, branch, assignment, or backlog routing is being changed.
+
+History snapshot rule:
+When a governance or instruction state needs a history snapshot, add a new file under archive/history/ using:
+CCYYMMDD_HHMMSS.md
+
+Do not rewrite history snapshots after creation unless the owner explicitly approves.

docs_build/dev/ProjectInstructions/TEAM_START_COMMANDS.md

@@ -0,0 +1,80 @@
+# TEAM_START_COMMANDS
+
+## Start Team Alpha
+
+Ready-to-copy command:
+
+```text
+OWNER override approved: Start Team Alpha from the ProjectInstructions release gate.
+
+Read docs_build/dev/ProjectInstructions/README.txt first.
+Read docs_build/dev/ProjectInstructions/backlog/BACKLOG_MASTER.md.
+Read docs_build/dev/ProjectInstructions/team_assignments/TEAM_ASSIGNMENTS.md.
+
+Pull one [ ] item for Team Alpha from BACKLOG_MASTER.md.
+Stop if Team Alpha already has an active branch.
+Stop if Team Alpha already has an active assignment.
+Stop if no [ ] Team Alpha backlog item is available.
+
+Change the selected backlog item from [ ] to [.].
+Add the selected assignment under Team Alpha in TEAM_ASSIGNMENTS.md.
+Create one Team Alpha branch for the selected assignment.
+Work only that assignment.
+```
+
+## Start Team Beta
+
+Ready-to-copy command:
+
+```text
+OWNER override approved: Start Team Beta from the ProjectInstructions release gate.
+
+Read docs_build/dev/ProjectInstructions/README.txt first.
+Read docs_build/dev/ProjectInstructions/backlog/BACKLOG_MASTER.md.
+Read docs_build/dev/ProjectInstructions/team_assignments/TEAM_ASSIGNMENTS.md.
+
+Pull one [ ] item for Team Beta from BACKLOG_MASTER.md.
+Stop if Team Beta already has an active branch.
+Stop if Team Beta already has an active assignment.
+Stop if no [ ] Team Beta backlog item is available.
+
+Change the selected backlog item from [ ] to [.].
+Add the selected assignment under Team Beta in TEAM_ASSIGNMENTS.md.
+Create one Team Beta branch for the selected assignment.
+Work only that assignment.
+```
+
+## Start Team Gamma
+
+Ready-to-copy command:
+
+```text
+OWNER override approved: Start Team Gamma from the ProjectInstructions release gate.
+
+Read docs_build/dev/ProjectInstructions/README.txt first.
+Read docs_build/dev/ProjectInstructions/backlog/BACKLOG_MASTER.md.
+Read docs_build/dev/ProjectInstructions/team_assignments/TEAM_ASSIGNMENTS.md.
+
+Pull one [ ] item for Team Gamma from BACKLOG_MASTER.md.
+Stop if Team Gamma already has an active branch.
+Stop if Team Gamma already has an active assignment.
+Stop if no [ ] Team Gamma backlog item is available.
+
+Change the selected backlog item from [ ] to [.].
+Add the selected assignment under Team Gamma in TEAM_ASSIGNMENTS.md.
+Create one Team Gamma branch for the selected assignment.
+Work only that assignment.
+```
+
+## Day Work / EOD Merge Reminder
+
+Ready-to-copy reminder:
+
+```text
+Commit/push during the day is allowed only on assigned team/OWNER/PR branches.
+
+Merge to main is EOD-only and owner-approved, unless the owner explicitly says:
+"Merge this PR now."
+
+Do not treat sequential PR completion as merge approval.
+```

docs_build/dev/ProjectInstructions/addendums/build_path_sync.md

@@ -0,0 +1,35 @@
+# Build Path Status Sync Governance
+
+## Purpose
+
+This addendum keeps the central backlog and Toolbox Build Path aligned.
+
+## Source Of Truth
+
+`docs_build/dev/ProjectInstructions/backlog/BACKLOG_MASTER.md` is the source of truth for tool status.
+
+## Build Path Sync
+
+`toolbox/index.html` Build Path tiles must match tool status from `BACKLOG_MASTER.md`.
+
+When a central backlog tool status changes, update the matching Build Path tile.
+
+Status and Build Path changes should be in the same PR when practical.
+
+## Phase Percentages
+
+Phase percentages are calculated from tools in each phase.
+
+Rules:
+- completed tools count as complete
+- planned, wireframe, building, and blocked tools remain in the denominator
+- deprecated tools are excluded from the denominator
+- phase percentage must be recalculated when a tool status changes
+
+## Validation
+
+PRs that change backlog status or Build Path status must document:
+- backlog item changed
+- matching Build Path tile changed
+- phase percentage before and after
+- skipped sync, if any, with reason

docs_build/dev/ProjectInstructions/addendums/deprecation.md

@@ -0,0 +1,32 @@
+# Deprecation Governance
+
+## Purpose
+
+This addendum defines how Project Instructions backlog and Build Path items become deprecated while staying traceable.
+
+## Deprecation Group
+
+Deprecation is its own group and must not be hidden inside normal completion work.
+
+## Traceability
+
+Deprecated items must preserve:
+- original item text
+- deprecated status
+- owner approval reference
+- replacement path, if any
+- archive/removal decision, if any
+
+## Owner Approval
+
+Owner approval is required before archive or removal.
+
+No team may remove a deprecated item solely because it is deprecated.
+
+## Build Path Display
+
+Deprecated Build Path items use red overlay if visible.
+
+Deprecated items do not count against current MVP completion.
+
+If a deprecated item remains visible, it must communicate Deprecated status to creators without relying on color alone.

docs_build/dev/ProjectInstructions/addendums/multi_team.md

@@ -0,0 +1,55 @@
+# Multi-Team Codex Execution Governance
+
+## All-Team Preferred Codex Execution Method
+
+Preferred execution model:
+Single Codex session with multiple sequential PRs.
+
+Applies to:
+- Team Alfa through Team Zulu
+- Team OWNER
+
+Purpose:
+Reduce back-and-forth between owner and Codex while keeping PRs reviewable and scoped.
+
+Rules:
+- One Codex session may execute multiple sequential PRs.
+- Each PR must still have one clear purpose.
+- Each PR must create or use its own approved branch.
+- Each PR may be committed and pushed during active work.
+- Each PR may be opened as a draft PR during active work.
+- Do not commit directly to main.
+- Do not merge to main during active work unless the owner explicitly says: "Merge this PR now."
+- If later PRs depend on earlier unmerged PRs, Codex must either:
+  - stack the dependent PRs, or
+  - stop and request owner approval for the dependency model.
+- Codex should reduce chit-chat by planning the full sequence before starting.
+- Codex must still hard-stop for conflicts, dirty worktree, scope mismatch, missing assignment, or protected instruction deletion.
+
+## Day Work / EOD Merge Rule
+
+During active work:
+- Work happens on assigned team branches, OWNER branches, or scoped PR branches.
+- Commits are allowed only on assigned non-main branches.
+- Pushes are allowed and expected.
+- Draft PRs are allowed and expected.
+- Direct commits to main are prohibited.
+- Merges to main are prohibited unless explicitly approved by the owner.
+
+At end of day:
+- Owner reviews ready PRs.
+- Owner explicitly approves which PRs merge.
+- Only owner-approved PRs may merge to main.
+- After merge, return to main and pull latest main.
+- Do not treat sequential PR completion as merge approval.
+
+Commit/push during the day is allowed only on assigned team/OWNER/PR branches.
+
+Merge to main is EOD-only and owner-approved, unless the owner explicitly says:
+"Merge this PR now."
+
+## Conflict Note
+
+Existing ProjectInstructions wording that appears to require immediate or automatic merge remains preserved for traceability.
+
+This addendum clarifies that merge to `main` remains owner-controlled. If a workflow rule appears to conflict with this addendum, stop and request explicit owner approval before merging.

docs_build/dev/ProjectInstructions/addendums/preservation.md

@@ -0,0 +1,42 @@
+# Preservation And Archive Governance
+
+## Purpose
+
+This addendum protects Project Instructions material from accidental deletion, rewrite, or drift.
+
+## Append-First Documentation
+
+Project Instructions documentation is append-first.
+
+Allowed default actions:
+- add new files
+- append dated notes
+- append references
+- add new governance addendums
+- add archive snapshots
+
+## Owner Approval Required
+
+Do not delete Project Instructions material unless the owner explicitly approves deletion.
+
+Do not rewrite Project Instructions material unless the owner explicitly approves rewrite.
+
+If a requested change conflicts with existing Project Instructions, stop before editing. Explain:
+- the conflicting files
+- the conflicting rule text
+- the requested change
+- the recommended action
+
+Then request owner approval.
+
+## Archive Instead Of Delete
+
+When material is no longer active, archive it instead of deleting it. Archive entries must preserve enough context to explain why the material moved out of active use.
+
+## History Snapshots
+
+History snapshots go to:
+
+`docs_build/dev/ProjectInstructions/archive/history/CCYYMMDD_HHMMSS.md`
+
+Use 24-hour local time for `HHMMSS` unless the owner specifies another time basis.

docs_build/dev/ProjectInstructions/addendums/team_release_readiness.md

@@ -0,0 +1,31 @@
+# Team Release Readiness Gate
+
+## Purpose
+
+This gate prevents Team Alpha, Team Beta, Team Gamma, or Team OWNER from starting regular assigned work before the ProjectInstructions operating system is ready.
+
+## Release Rule
+
+Teams may start only when all of the following are true:
+
+- `docs_build/dev/ProjectInstructions/backlog/BACKLOG_MASTER.md` exists and is populated.
+- `docs_build/dev/ProjectInstructions/team_assignments/TEAM_ASSIGNMENTS.md` exists.
+- OWNER governance exists.
+- One-active-branch-per-team rule exists.
+- No-direct-main rule exists.
+- Out-of-scope stop rule exists.
+- Build Path sync rule exists.
+
+## Gate Outcome
+
+If every requirement is true, team start commands may be issued.
+
+If any requirement is missing, stop and report:
+- missing requirement
+- expected file or rule
+- current branch
+- recommended owner action
+
+## No Silent Starts
+
+Teams must not infer readiness from an incomplete stack. Readiness must be documented before team work begins.

docs_build/dev/ProjectInstructions/addendums/tile_overlay_status.md

@@ -0,0 +1,36 @@
+# Build Path Tile Overlay Status Governance
+
+## Purpose
+
+This addendum defines visual overlay status rules for Build Path tiles.
+
+## Overlay Mapping
+
+| Backlog Status | Meaning | Tile Overlay |
+| --- | --- | --- |
+| `[ ]` Planned | Planned | black overlay 70% |
+| `[?]` Wireframe | Wireframe | black overlay 80% |
+| `[.]` Building | Building | black overlay 90% |
+| `[x]` Complete | Complete | 100% transparent / no visible overlay |
+| `[!]` Blocked | Blocked | yellow overlay 80% |
+| `[-]` Deprecated | Deprecated | red overlay 80% |
+
+## Completion Denominator
+
+Blocked items remain in the completion denominator.
+
+Deprecated items are excluded from the completion denominator.
+
+## Badge Text
+
+Blocked and Deprecated tiles must show badge text.
+
+Badge text must be visible enough for a creator to understand why the tile is blocked or deprecated without relying on color alone.
+
+## Validation
+
+PRs that change tile overlay behavior must document:
+- status mapping affected
+- badge text affected
+- phase percentage denominator effect
+- skipped UI validation, if any, with reason