diff --git a/docs_build/dev/ProjectInstructions/addendums/branch_context_governance.md b/docs_build/dev/ProjectInstructions/addendums/branch_context_governance.md
new file mode 100644
index 000000000..9baa13442
--- /dev/null
+++ b/docs_build/dev/ProjectInstructions/addendums/branch_context_governance.md
@@ -0,0 +1,52 @@
+# Branch Context Governance
+
+Status: Approved
+Owner: OWNER
+
+## Purpose
+
+Require Codex and teams to confirm branch context before changing files.
+
+## Session Start Context
+
+At the start of work, report or validate:
+
+- current branch
+- expected branch
+- current commit
+- local/origin sync status
+- worktree status
+- active team
+- active assignment
+
+## Stop Conditions
+
+Stop and report before changing files when:
+
+- current branch does not match the expected branch
+- local branch is behind or ahead unexpectedly
+- worktree has unrelated changes
+- active assignment is missing or unclear
+- active team does not match the branch or OWNER instruction
+- the requested work would modify files outside the approved scope
+
+## Continuation Rule
+
+After a branch is created, the branch remains the working context.
+
+Do not automatically return to `main` after:
+
+- commit
+- push
+- draft PR creation
+- validation
+- review updates
+- additional commits
+
+Return to `main` only after the PR is merged, the branch is retired, or OWNER explicitly says to return to `main`.
+
+## GitHub Authority
+
+GitHub is authoritative for open PR state, merged PR state, review state, and remote branch state.
+
+Local git state must be reconciled with GitHub before making OWNER-level cleanup decisions.
diff --git a/docs_build/dev/ProjectInstructions/addendums/branch_lock_governance.md b/docs_build/dev/ProjectInstructions/addendums/branch_lock_governance.md
new file mode 100644
index 000000000..42fe1d0bf
--- /dev/null
+++ b/docs_build/dev/ProjectInstructions/addendums/branch_lock_governance.md
@@ -0,0 +1,50 @@
+# Branch Lock Governance
+
+Status: Approved
+Owner: OWNER
+
+## Purpose
+
+Keep active work attached to the correct assigned team, branch, and OWNER decision.
+
+## Active Work Lock
+
+- Work must occur on the assigned team or OWNER branch.
+- An assigned work item keeps its owner of record until complete or OWNER reassignment.
+- Work must not move to another team, branch, or PR without OWNER approval.
+- A team with no active assignment, active branch, or active PR is inactive.
+- Project Instructions must not assume a permanent team roster.
+
+## Branch Rules
+
+- Start from current `main`.
+- Pull latest `origin/main` before creating a work branch.
+- Keep work on the active branch until the PR is merged, the branch is retired, or OWNER says to return to `main`.
+- Do not commit directly to `main` unless OWNER explicitly approves.
+- Do not merge stale historical branches directly unless they are current, clean, still needed, and OWNER-approved.
+
+## OWNER Override
+
+OWNER may override a branch lock or team assignment.
+
+When OWNER overrides, the PR or report must document:
+
+- original assigned team or branch
+- override decision
+- reason for the override
+- new assigned team or branch, if any
+
+## Protected Instruction Boundaries
+
+Branch lock work must not silently delete, rewrite, or weaken protected Project Instructions guidance.
+
+Protected guidance includes:
+
+- source-of-truth rules
+- approved naming rules
+- status model rules
+- team assignment rules
+- PR workflow rules
+- Governance Phase 1 completion guidance
+
+If protected guidance must change, OWNER approval is required.
diff --git a/docs_build/dev/ProjectInstructions/addendums/release_gate.md b/docs_build/dev/ProjectInstructions/addendums/release_gate.md
new file mode 100644
index 000000000..5fe7ed1f0
--- /dev/null
+++ b/docs_build/dev/ProjectInstructions/addendums/release_gate.md
@@ -0,0 +1,50 @@
+# Release Gate Governance
+
+Status: Approved
+Owner: OWNER
+
+## Purpose
+
+Define release gates for Project Instructions governance without making governance a blocker by default.
+
+## Rule
+
+Release gates are validation gates.
+They do not block development unless OWNER says governance is blocking.
+
+## Project Instructions Release Gate
+
+Before a governance, documentation, or administrative PR is merged, validate:
+
+- Project Instructions folder exists.
+- Required source-of-truth files still exist.
+- Governance Phase 1 completion guidance remains intact.
+- PR workflow guidance remains intact.
+- Team assignment governance remains intact.
+- Active team registry guidance remains compatible with temporary active teams.
+- No protected Project Instructions guidance was deleted.
+- No permanent team roster or permanent discipline ownership was restored.
+- No direct-to-main commit rule was bypassed.
+- No application code changed unless the PR explicitly scopes application code.
+
+## Required Source Files
+
+The release gate should confirm these files when relevant to the PR:
+
+- `docs_build/dev/ProjectInstructions/README.txt`
+- `docs_build/dev/ProjectInstructions/PROJECT_INSTRUCTIONS.md`
+- `docs_build/dev/ProjectInstructions/backlog/BACKLOG_MASTER.md`
+- `docs_build/dev/ProjectInstructions/addendums/governance_phase1_complete.md`
+- `docs_build/dev/ProjectInstructions/addendums/pr_workflow.md`
+- `docs_build/dev/ProjectInstructions/team_assignments/team_ownership.md`
+
+## Validation Result
+
+If a gate fails, stop and report:
+
+- failing check
+- current branch
+- current worktree status
+- recommended OWNER action
+
+If every relevant check passes, the PR may proceed through the standard PR workflow.
diff --git a/docs_build/dev/ProjectInstructions/addendums/team_start_and_release.md b/docs_build/dev/ProjectInstructions/addendums/team_start_and_release.md
new file mode 100644
index 000000000..3f85bbf25
--- /dev/null
+++ b/docs_build/dev/ProjectInstructions/addendums/team_start_and_release.md
@@ -0,0 +1,61 @@
+# Team Start And Release Governance
+
+Status: Approved
+Owner: OWNER
+
+## Purpose
+
+Preserve useful historical team-start and release-readiness rules in the current Governance Phase 1 model.
+
+## Team Start Rule
+
+OWNER identifies available teams when starting work.
+
+Before a team starts, validate:
+
+- current branch and expected branch are known
+- worktree is clean or unrelated changes are understood
+- `main` is current when a new branch is required
+- active assignment is selected or confirmed by OWNER
+- assigned team uses NATO phonetic naming
+- work remains with the assigned team until complete or OWNER reassignment
+
+## Assignment Flow
+
+For backlog-driven work:
+
+1. Read `docs_build/dev/ProjectInstructions/backlog/BACKLOG_MASTER.md`.
+2. Select only the OWNER-approved backlog item.
+3. Use the approved status model from `status_model.md`.
+4. Create or use the approved team branch.
+5. Record active work in the active team registry when required.
+6. Open a draft PR after validation.
+7. Merge only through OWNER-approved PR workflow.
+
+## Team Command Examples
+
+Use these as naming examples, not as a permanent roster:
+
+- Start Team Alfa
+- Start Team Bravo
+- Start Team Charlie
+- Start Team Delta
+- Start Team Echo
+- Start Team Foxtrot
+
+## Release Readiness
+
+A team or OWNER PR is release-ready when:
+
+- scope matches the OWNER request
+- validation passes
+- no application code changed unless explicitly scoped
+- no protected Project Instructions guidance was deleted
+- branch context is correct
+- active assignment or OWNER ownership is clear
+- PR summary states the validation result
+
+## Gate Behavior
+
+Release readiness is a validation gate.
+It does not block unrelated development unless OWNER says governance is blocking.
diff --git a/docs_build/dev/ProjectInstructions/team_assignments/ACTIVE_TEAM_REGISTRY.md b/docs_build/dev/ProjectInstructions/team_assignments/ACTIVE_TEAM_REGISTRY.md
new file mode 100644
index 000000000..5ca625819
--- /dev/null
+++ b/docs_build/dev/ProjectInstructions/team_assignments/ACTIVE_TEAM_REGISTRY.md
@@ -0,0 +1,53 @@
+# Active Team Registry
+
+Status: Approved
+Owner: OWNER
+
+## Purpose
+
+Track temporary active teams without creating a permanent team roster.
+
+## Rule
+
+Active teams may change day to day.
+OWNER identifies available teams when starting work.
+Project Instructions must not assume a permanent team roster.
+
+## Active Criteria
+
+A team is active when it has at least one of:
+
+- OWNER-assigned work
+- active branch
+- draft or open PR
+- active release or cleanup responsibility
+
+If a team has no assignment, no active branch, and no active PR, it is inactive and may be omitted from the active registry.
+
+## Registry
+
+| Team | Active Assignment | Branch | PR | Status | OWNER Decision |
+|------|-------------------|--------|----|--------|----------------|
+| Team OWNER | none | none | none | Available | Governance Phase 1 complete |
+
+## Update Rules
+
+Update the registry when:
+
+- OWNER starts a team
+- OWNER reassigns work
+- a branch is created
+- a PR is opened
+- a PR is merged
+- a branch is retired
+- a team becomes inactive
+
+## Reassignment
+
+Only OWNER may reassign work.
+Assigned team remains owner of record until complete or OWNER reassignment.
+
+## Reset Rule
+
+After closeout, the active registry may reset to no active non-OWNER teams.
+This reset does not delete historical ownership, PR history, or backlog source-of-truth records.