Merge PR_26177_OWNER_012-project-instructions-cleanup-backlog-canonicalization

PR_26177_OWNER_012-project-instructions-cleanup-backlog-canonicalization

Author: ToolboxAid

docs_build/dev/ProjectInstructions/PROJECT_INSTRUCTIONS.md

@@ -58,6 +58,20 @@ Existing Project Instructions outside `docs_build/dev/ProjectInstructions/` rema
 
 `docs_build/dev/ProjectInstructions/addendums/team_backlog_sod_eod_standard.md` defines required Start of Day team briefings, End of Day team summaries, active team backlog fields, completion percentage update points, backlog-driven next PR selection, and official military team-name spelling.
 
+## Canonical Governance Owners
+
+When active guidance overlaps, use these canonical owner documents:
+
+- Workflow and Product Owner testable completion: `docs_build/dev/ProjectInstructions/addendums/pr_workflow.md`
+- START / WORK / END lifecycle, branch gates, mandatory hard stops, and EOD main lock: `docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md`
+- Page-level Playwright organization and completion coverage: `docs_build/dev/ProjectInstructions/addendums/test_structure_standardization.md`
+- API/environment model and `Browser -> API -> Database` rule: `docs_build/dev/ProjectInstructions/addendums/environment_governance_model.md`
+- Environment variable, URL, R2 prefix, and feature flag configuration: `docs_build/dev/ProjectInstructions/addendums/environment_configuration_standards.md`
+- Team backlog fields, completion percentages, and next logical PR ownership: `docs_build/dev/ProjectInstructions/addendums/team_backlog_sod_eod_standard.md`
+- Team ownership and assignment routing: `docs_build/dev/ProjectInstructions/team_assignments/team_ownership.md`
+
+Other active addendums may summarize these rules, but they must point back to the canonical owner document and must not create a competing active rule.
+
 ## Environment Governance
 
 `docs_build/dev/ProjectInstructions/addendums/environment_governance_model.md` defines the official environment model, environment invariance rule, shared API/service contract rule, required Supabase/Postgres/R2 services, required R2 prefixes, and SQLite retired status.
@@ -97,7 +111,7 @@ OWNER override wording:
 `OWNER override approved: <reason>`
 
 OWNER follows the same safety rules:
-- One active Team OWNER branch at a time.
+- Team OWNER follows the same one-active-branch discipline as every team.
 - 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

@@ -16,7 +16,7 @@ No direct commits to main:
 Do not commit directly to main. Normal work must use PR branches, draft PRs, validation evidence, and owner-controlled merge approval.
 
 Branch lifecycle:
-Every PR follows exactly three phases: START, WORK, END. The canonical lifecycle is `docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md`.
+The canonical START / WORK / END lifecycle is `docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md`.
 
 OWNER override rule:
 An OWNER override must use this wording:

docs_build/dev/ProjectInstructions/TEAM_START_COMMANDS.md

@@ -13,14 +13,7 @@ Use `docs_build/dev/ProjectInstructions/` as the only active Project Instruction
 Read `docs_build/dev/ProjectInstructions/addendums/team_backlog_sod_eod_standard.md` before implementation.
 
 Branch Lifecycle (Canonical):
-- Every PR follows exactly three phases: START, WORK, END.
-- Follow `docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md`.
-- START begins on synchronized `main` and creates the PR branch only after all gates pass.
-- WORK remains on the PR branch. Never checkout `main`.
-- END merges, returns to synchronized `main`, publishes branch, HEAD SHA, and date/time, then stops all work.
-- No commits on `main`.
-- No implementation on `main`.
-- No validation on `main` except start validation.
+- Follow `docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md` for START / WORK / END lifecycle, branch gates, mandatory hard stops, and EOD main lock.
 
 ## Start Team Alfa
 

docs_build/dev/ProjectInstructions/addendums/branch_context_governance.md

@@ -7,6 +7,10 @@ Owner: OWNER
 
 Require Codex and teams to confirm branch context before changing files.
 
+Canonical branch lifecycle reference: `docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md`.
+
+This file owns branch context confirmation and stop conditions; it must not create a competing START / WORK / END lifecycle rule.
+
 ## Session Start Context
 
 At the start of work, report or validate:

docs_build/dev/ProjectInstructions/addendums/branch_lock_governance.md

@@ -7,6 +7,10 @@ Owner: OWNER
 
 Keep active work attached to the correct assigned team, branch, and OWNER decision.
 
+Canonical branch lifecycle reference: `docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md`.
+
+This file owns branch lock enforcement and OWNER override handling; it must not create a competing START / WORK / END lifecycle rule.
+
 ## Active Work Lock
 
 - Work must occur on the active team branch.
@@ -39,21 +43,13 @@ Keep active work attached to the correct assigned team, branch, and OWNER decisi
 
 ## Branch Lifecycle (Canonical)
 
-Every PR follows exactly three phases:
+The canonical branch lifecycle lives in:
 
 ```text
-START
-WORK
-END
+docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md
 ```
 
-The canonical lifecycle lives in `docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md`.
-
-Branch lock governance enforces:
-- START on synchronized `main`.
-- WORK only on the PR branch.
-- END by merging, returning to synchronized `main`, publishing branch, HEAD SHA, and date/time, then stopping all work.
-- Mandatory hard stops before commits on `main`, dirty branch creation, non-`0 0` main sync, baseline SHA mismatch, unvalidated merge, or new unrelated workstream before synchronized main return.
+Branch lock governance enforces ownership and branch-lock compliance with that canonical lifecycle.
 
 ## OWNER Override
 

docs_build/dev/ProjectInstructions/addendums/codex_artifact_and_reporting_standard.md

@@ -55,15 +55,15 @@ Codex responses must include:
 Every tool MVP PR report must include:
 - Product Owner testable outcome
 - What Playwright tests
-- What Mr. Q should manually test
+- What the Product Owner should manually test
 - Whether the PR is part of a stacked MVP sequence
 - Previous PR dependency
 - Next PR dependency
 
 The report must answer:
 
 ```text
-What can Mr. Q test after applying this ZIP?
+What can the Product Owner test after applying this ZIP?
 ```
 
 If a tool MVP PR has no Playwright lane, the report must state why and list the manual Product Owner validation instead.

docs_build/dev/ProjectInstructions/addendums/codex_project_instructions_startup.md

@@ -23,25 +23,13 @@ Codex must use this as the only active source of truth for:
 
 ## Branch Lifecycle Start Gate
 
-Every PR follows exactly three phases:
+Codex must follow the canonical lifecycle in:
 
 ```text
-START
-WORK
-END
+docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md
 ```
 
-Codex must follow the canonical lifecycle in:
-
-`docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md`
-
-Startup enforcement:
-- START begins on synchronized `main`.
-- WORK remains on the PR branch. Never checkout `main`.
-- END merges, returns to synchronized `main`, publishes branch, HEAD SHA, and date/time, then stops all work.
-- STOP if current branch is `main` before commit.
-- STOP if attempting to push `main`.
-- STOP if a new PR starts before returning to synchronized `main`.
+This startup addendum only requires Codex to read and apply that canonical lifecycle; it must not define a competing lifecycle rule.
 
 Deprecated Project Instructions material outside `docs_build/dev/ProjectInstructions/` is reference-only and must not override active governance.
 

docs_build/dev/ProjectInstructions/addendums/environment_configuration_standards.md

@@ -11,6 +11,10 @@ This addendum is governance/documentation only. It does not change runtime behav
 
 ## Source Model
 
+Canonical environment/API model reference: `docs_build/dev/ProjectInstructions/addendums/environment_governance_model.md`.
+
+This file owns environment variable names, URL configuration, R2 prefix configuration, and feature flag configuration only.
+
 This standard builds on:
 
 ```text
@@ -88,12 +92,10 @@ R2 project, backup, export, import, or future storage paths must stay under the
 
 ## API/Service Contract Configuration
 
-One shared API/service contract is required across Local (VS Code), DEV, IST, UAT, and PROD.
+The canonical shared API/service contract rule lives in `docs_build/dev/ProjectInstructions/addendums/environment_governance_model.md`.
 
-Rules:
+This section owns configuration-only API URL requirements:
 
-- Browser/UI/runtime code must follow `Browser -> API -> Database` for authoritative product data.
-- `Local API` means the same shared API/service contract running locally, not a separate local-only API implementation.
 - API URLs may differ by `.env` only.
 - Do not split Local API and Public API contracts.
 - Do not create environment-specific API/service contracts.

docs_build/dev/ProjectInstructions/addendums/multi_team.md

@@ -1,5 +1,11 @@
 # Multi-Team Codex Execution Governance
 
+Canonical workflow reference: `docs_build/dev/ProjectInstructions/addendums/pr_workflow.md`.
+
+Canonical branch lifecycle reference: `docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md`.
+
+This file owns multi-team execution coordination and must not create competing workflow or branch lifecycle rules.
+
 ## Four Active Delivery Teams
 
 The single authoritative four-team ownership definition is:
@@ -65,7 +71,7 @@ Rules:
 ## Day Work / EOD Merge Rule
 
 During active work:
-- Work happens on assigned team branches, OWNER branches, or scoped PR branches.
+- Work happens on active non-main team 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.

docs_build/dev/ProjectInstructions/addendums/pr_workflow.md

@@ -46,31 +46,11 @@ This section supersedes older active wording that implies returning to `main` be
 
 ## Branch Lifecycle (Canonical)
 
-Every PR follows exactly three phases:
-
-```text
-START
-WORK
-END
-```
-
 The canonical START, WORK, END, Daily Synchronization, and Mandatory Hard Stops rules live in:
 
 `docs_build/dev/ProjectInstructions/addendums/project_instructions_single_source_eod_lock.md`
 
-PR workflow must follow that lifecycle exactly.
-
-Summary:
-- START happens on synchronized `main` only and creates the PR branch only after all required gates pass.
-- WORK happens only on the PR branch.
-- END validates, commits, pushes, opens/updates the PR, merges, returns to synchronized `main`, publishes branch, HEAD SHA, and date/time, then stops all work.
-- No commits on `main`.
-- No implementation on `main`.
-- No validation on `main` except start validation.
-- Never checkout `main` during WORK.
-- STOP before commit if current branch is `main`.
-- STOP if current branch changes unexpectedly.
-- STOP if attempting to push `main`.
+PR workflow must follow that lifecycle exactly and must not create a competing lifecycle rule.
 
 ## PR Lifecycle States
 
@@ -153,7 +133,7 @@ Do not stop after every small PR unless blocked by branch state, failed validati
 Each tool MVP PR plan or template must include:
 - Product Owner testable outcome
 - What Playwright tests
-- What Mr. Q should manually test
+- What the Product Owner should manually test
 - Whether the PR is part of a stacked MVP sequence
 - Previous PR dependency
 - Next PR dependency
@@ -162,6 +142,8 @@ Visible acceptance must be Creator-facing first. Architecture can be handled und
 
 ## Product Owner Testable Definition
 
+Canonical owner: this section is the active canonical Product Owner testable completion rule.
+
 A request to complete a page, tool, MVP, or testable experience means Product Owner testable by default. Codex must deliver a working Product Owner testable feature, not a shell or foundation page, unless the Product Owner explicitly requests a shell/foundation PR.
 
 A Product Owner testable outcome means the Product Owner can: