Current delivery and branch audit — 24 October 2026

This current snapshot supersedes conflicting earlier branch instructions and implementation-status claims below. Earlier dated notes remain historical evidence, not current acceptance. No status, hierarchy, native PR association or repository change is proposed by this description patch.

• Outcome: Verify consolidation approval, actual consumers and policy exceptions without implementing deletion.
• Recorded status: In Progress. Accepted whole-child completion is not established.
• Verified implementation position: Current target has no local labels.yml/issue-types.yml/ISSUE_TEMPLATE/PULL_REQUEST_TEMPLATE/branch-labels.yml. Existing review: repo-governance - Verify consolidation approval [LABEL-UPDATE-REQUEST] #337 wording demanding required local templates conflicts with ci: repo-governance - Configure shared PR template reuse #248’s explicit shared-only policy. Presence/absence and a register entry do not establish human approval or working routing.
• Outstanding acceptance: Locate exact approver/date/scope and consumer evidence; reconcile shared-only policy, drift exceptions and outstanding implementation with no blanket deletion/restoration.

Branch instructions

• Repository: lightspeedwp/ThisOneTimeOnAcidCom
• Implementing issue(s): this existing child; GitHub sync counterpart review: repo-governance - Verify consolidation approval [LABEL-UPDATE-REQUEST] #337 in the same repository. Linear GitHub-sync mapping retrieved; GitHub issue body/parent not independently re-read in this audit. Do not use a closing/development association until independently verified.
• Parent epic context: native parent verified; coordination only. No implementation branch/file plan belongs to the epic itself.
• Allowed closing target(s): none now. Whole-child acceptance and independent GitHub/Linear mapping/association review are required before proposing a closing target; never the parent.
• Branch state: not applicable
• Branch: not applicable — current outcome needs no repository change
• Base: not applicable
• Naming policy: target instructions, contributor guide, validator, local branch guide, organisation strategy. Classification rationale: review/decision evidence only, not a repository implementation. No exact new name is recommended; no branch mutation or reuse is approved.
• Pull request template: not applicable
• PR association safeguard: No parent identifier/link in a future branch name, PR title/body, coding prompt, development link or closing directive. Association/status automation settings remain unverified; do not assume “Related to” text or a hyperlink is harmless. Child references in this description are not proposed PR text.
• Constraints: preserve unrelated work; do not create/switch/rename/delete branches, force-push, merge, deploy, change settings or close records under this draft. Shared locked configuration/templates require human review. Residual protected-file declarations remain relevant despite absent guard workflow; do not equate absent automated enforcement with permission. Workflow ownership conflicts require controller/owner resolution, not local edits to managed dependency workflows.
• Conflicts or missing evidence: Human approval source and exact accepted exceptions remain unresolved. Record decision/evidence here after approved preview; do not resolve conflicts by silently editing canonical shared configuration.

Expected file changes

Plan status: not applicable — review/decision findings can be recorded on this issue without repository changes.

No repository operations are proposed.

• Out of scope: Template restoration, blanket deletions, workflow repairs, taxonomy mutation and inferred phase completion.
• Remaining discovery: Human approval source and exact accepted exceptions remain unresolved. Record decision/evidence here after approved preview; do not resolve conflicts by silently editing canonical shared configuration.
• Scope-change gate: stop for revised exact scope and approval before adding materially different paths or operations. No unbounded “other files as needed”. Protected-file approval never overrides a prohibition on routine agent edits.

Evidence and handoff packet

• Recipient and request: originating issue-management audit; read-only exact existing-record preview for approval, not a new intake or implicit specialist invocation.
• Selected record: this existing child description, separate from the coordination parent; no writes performed.
• Implementing targets and criteria: this child’s existing outcome and acceptance criteria remain in force. Verify consolidation approval, actual consumers and policy exceptions without implementing deletion. Outstanding gates: Locate exact approver/date/scope and consumer evidence; reconcile shared-only policy, drift exceptions and outstanding implementation with no blanket deletion/restoration.
• Sources checked: current Linear description/status/native parent/relations/explicit pullRequests and GitHub sync metadata; target instructions, contributor guide, validator, local branch guide, organisation strategy; the exact source paths/revisions above and current repository inventory. Shared template config checked at 47aee0722033f65d4d9d57429b410b518646b817. Some path evidence is inventory-only and is labelled as such; it is not full content/behaviour validation.
• Branch/PR evidence: Current remote inventory includes historical epic/repo-governance-lightspeedwp/ThisOneTimeOnAcidCom#237 and broad governance/testing branches; scope/base/diff fit was not verified, so none is recommended for reuse. An open application-instrumentation pull request overlaps shared configuration; refresh its head, changed paths and scope before choosing a branch or editing shared files. No reuse is approved. No native linked PR was returned for this child; descriptive/historical references are not native associations.
• Association and closing rationale: Linear GitHub-sync mapping retrieved; GitHub issue body/parent not independently re-read in this audit. Do not use a closing/development association until independently verified. No complete-child acceptance or closing target established. Linear GitHub documentation lookup identified the integration article but did not expose its detailed association content; current workspace linking/status rules remain unverified. No parent identifier/link in a future branch name, PR title/body, coding prompt, development link or closing directive. Association/status automation settings remain unverified; do not assume “Related to” text or a hyperlink is harmless. Child references in this description are not proposed PR text.
• Unresolved points and exclusions: Human approval source and exact accepted exceptions remain unresolved. Record decision/evidence here after approved preview; do not resolve conflicts by silently editing canonical shared configuration. Template restoration, blanket deletions, workflow repairs, taxonomy mutation and inferred phase completion.
• Approval state: draft only. Exact description-preview approval is still required; repository edits/branch actions/PRs/settings/native associations retain separate boundaries. Existing GitHub issue sync is active, so approved description changes may propagate externally; no duplicate GitHub body write is proposed.

Review-only outcome: branch, base, PR template and repository file plan are not applicable. If the human decision later requires repository documentation, preview only a bounded correction to .github/docs/GOVERNANCE-INVENTORY.md or the actual change-request register with protected-file review first.

Phase 2 Governance Consolidation — Change Request

Description

This change request reconciles the approval scope and evidence for Phase 2 Governance Consolidation (Spec 001 Phase 2). It does not itself grant approval or establish implementation completion.

Changes Requested

Consolidate duplicate governance files from ThisOneTimeOnAcidCom into the canonical lightspeedwp/.github repository:

Assess each local asset against canonical ownership and actual consumers. Preserve or restore repository-local templates required by the current router; blanket deletion is not authorised by this record.

Files Being Consolidated

• .github/labels.yml — Canonical label definitions (historically reported: 158 labels; not a verified current inventory)
• .github/PULL_REQUEST_TEMPLATE/** — PR templates routed by branch prefix (historically reported: 11 templates); preserve required local routing templates
• .github/ISSUE_TEMPLATE/** — Issue templates for future use
• .github/issue-types.yml — Organisation-wide issue type definitions (historically reported: 24 types; not a verified current inventory)
• .github/branch-labels.yml — Branch-specific label mappings

Related Specification

• Specification: Spec 001 Phase 2: Repository Restructuring & Canonical Governance Config
• Location: .github/specs/001-repo-governance-layout-and-agentic-workflows/
• Status: PR docs: Spec 001 Phase 2 — Repository Governance Consolidation is merged. The register records approval, but its human approval source remains unverified. The supplementary implementation tasks remain unchecked; merge and registration do not establish phase completion.
• Constitution Principle II: Locked file changes require approved change requests

Rationale

✅ Single source of truth — Eliminate configuration drift between consumer and canonical repos
✅ Unified automation — Enable organization-wide labeling and template routing
✅ Governance consistency — Implement Constitution Principle II for locked file management
✅ Specification compliance — Complete Phase 2 deliverables as documented in Spec 001

Implementation Status

• Merged PR docs: Spec 001 Phase 2 — Repository Governance Consolidation contributes to consolidation; it does not prove completion of all tasks.
• Workflow and drift-detection changes are recorded implementation context, not proof of exercised routing or effective drift prevention.
• The change-request register records approval; reconcile it with the human approval source and exact scope.

Approval

Reconcile the scoped approval and conditions for consolidation under Spec 001. This description is not approval of blanket deletion or additional implementation.

Acceptance criteria

• Identify the approver, evidence, date and exact authorised scope
• Reconcile the register with that evidence
• Verify each proposed deletion against its consumers
• Preserve required local routing templates
• Reconcile drift-prevention rules with permitted local exceptions
• Record validation evidence and outstanding implementation work

Definition of Ready

• Requested path groups and related specification identified
• Approval source verified
• Local exceptions and policy conflicts resolved

Definition of Done

• Scoped approval outcome recorded
• Conditions and exceptions documented
• Remaining implementation and validation handed off
• No phase-completion claim based solely on the merged PR