# Backlog Closure Taxonomy And Label Governance V01 Issue: [#304](https://github.com/pinklon/ai-capability-discipline/issues/304) Date: 2026-06-27 ## Purpose This document makes issue closure classification and label governance mechanical enough to validate in repository workflow. It prevents evaluation, documentation, or architecture-decision work from being mistaken for implementation completion. ## Required Closure Classification Taxonomy Every closeout record must use exactly one primary closure-reality class: - Implemented - Partially implemented - Documentation only - Evaluation only - Architecture decision only - Workflow/process scaffold only - Source/corpus inclusion only - Superseded by another issue - Duplicate or not planned - Correctly closed but follow-up implementation required - Incorrectly closed - Needs reopening - Needs owner review Secondary flags may be attached when relevant: - missing labels - missing parent/child link - missing implementation ticket - ambiguous acceptance criteria - ambiguous closure reason - risk of hidden unfinished work - runtime behavior not changed despite implementation-sounding title - implementation exists but validation evidence weak ## Required Closeout Fields Every issue or PR closeout record must explicitly record: - Issue number. - Issue title. - Primary closure-reality class. - Secondary flags or `none`. - State reason. - Closing PR number or `none`. - Whether the closing PR implemented the stated scope. - Whether the closing PR only evaluated, documented, or designed the topic. - Parent issue reference or `standalone`. - Follow-up implementation issue reference, `none needed`, or `missing`. - Label set applied to the issue. - Label set applied to the PR. - Issue labels at closeout. - Whether labels were present at creation. - Whether any label repair was needed. - Who or what performed label repair, or `none`. - Linked child issue exists. - Parent issue state was preserved. - Issue close semantics were correct. - `codex-automerge` absent unless explicitly authorized. - Recommended next action. - Owner-review requirement when closure is ambiguous. ## Required Issue And PR Label Policy Child issues and PRs must carry the label set required by their lane before implementation, PR creation, and closeout. A child issue is not execution-ready when labels are missing, even if the prose is otherwise complete. For the current grounded-assistant governance lane, the required labels are: - `enhancement` - `priority:P1` - `area:grounded-assistant` - `area:data-boundary` - `area:workflow` - `area:operating-model` - `area:production-readiness` - `type:governance` - `type:operations` Closed issues missing labels must be flagged. PRs that close issues but have no labels must be flagged. Draft PR creation must not be treated as complete if the linked child issue has no labels. Label cleanup must be additive unless the owner explicitly authorizes removal or replacement. The #350 child issue was initially created without required labels and repaired after creation. Future closeout records must treat that pattern as a process defect and must report whether labels were present at creation, whether repair was needed, and who or what performed the repair. ## Required Parent/Child Rules - Parent or meta issues must remain open unless explicitly closed by the owner. - A child issue may close only its own bounded scope. - A PR body must use `Refs #parent` for parent/meta context and `Closes #child` only for the child issue it actually completes. - If a child issue closes while the parent remains open, the closeout record must state that split explicitly. - If a closed issue depends on future work, the follow-up issue must be linked or the closeout must state `missing follow-up implementation ticket`. ## Required Follow-Up Ticket Rules No issue should be closed as completed unless one of the following is explicitly recorded: - Implemented. - Partially implemented with follow-up issue. - Documentation only with no implementation planned. - Evaluation only with follow-up issue. - Architecture decision only with follow-up issue or no implementation planned. - Superseded by linked issue. - Duplicate of linked issue. - Not planned with rationale. - Needs owner review before closure. ## Required Execution Routing And Manual-Toil Control Tony must not be asked to perform local Git, GitHub CLI, validation, sync, cleanup, residue scan, closeout, or repo ceremony commands unless he explicitly requests manual commands. When GitHub-side action is available through the assistant execution surface, the assistant should perform that action directly. When local repo execution is required, the assistant should provide a Codex-ready executor handoff or ticket, not manual commands for Tony. When the next action is a repo-governance improvement, backlog correction, validation hardening, or operating-model adjustment, the assistant should provide an executable ticket or executor handoff by default rather than an abstract recommendation. ## Post-Closeout Next-Action Contract After a PR merge and local closeout receipt, the assistant or executor must not stop at acknowledgement when a next action is known, recommended, or mechanically derivable from repo-controlled artifacts. The closeout response must include exactly one of: 1. an executable Codex ticket, 2. a GitHub-side action the assistant can perform, 3. an explicit owner decision point with allowed options, 4. a Codex-ready clarification packet, 5. or a no-next-action statement with rationale. ## Relationship To Ticket-First Rule The post-closeout next-action contract is a ticket-first enforcement point. If the next step is a repo-governance improvement, backlog correction, validation hardening, metadata cleanup, or operating-model adjustment, the default output is a Codex-ready ticket unless the next action is blocked by missing owner intent. ## Relationship To Anti-Manual-Toil Rule The contract must not route known follow-up work back to Tony as manual repo ceremony. If the assistant can perform a GitHub-side action, it should perform that action. If repo-local evidence, validation, generated artifacts, or closeout proof is required, the assistant should provide an executable Codex ticket or executor-ready handoff. ## Relationship To No-Assumption Owner-Clarification Gate If the next step is ambiguous, the assistant must apply the No-Assumption Owner-Clarification Gate and provide a Codex-ready clarification packet or explicit owner decision point rather than guessing. ## Disallowed Closeout-Only Response Pattern A closeout-only acknowledgement is not acceptable when a next action is known, recommended, or mechanically derivable from repo-controlled artifacts. ## Required Output Types After Closeout Every merge/local-closeout response must record one post-closeout output type: - executable Codex ticket - GitHub-side action - explicit owner decision point - clarification packet - no-next-action statement with rationale ## No-Assumption Owner-Clarification Gate If intent, requirements, acceptance criteria, owner decision, dependencies, execution boundary, closure semantics, or expected outcome are unclear, the assistant or executor must not infer, assume, or silently proceed. The next action must be one of: - Ask Tony for clarification directly. - Produce a Codex-ready clarification packet or owner-review packet. - Mark the item owner-review required. - Defer the item with explicit rationale and no implementation. Candidate assumptions may be documented to expose possible interpretations, but they are not approved requirements unless Tony explicitly confirms them or the repository contains controlling evidence. ## Candidate Assumptions Versus Approved Requirements Candidate assumptions are tentative readings of unclear scope, dependency, close semantics, acceptance criteria, or owner intent. They may be used to frame a clarification request, owner-review packet, or deferred note. Approved requirements come only from explicit owner confirmation or controlling repository evidence such as an issue body, PR body, accepted plan, validation receipt, or authoritative governance artifact. Candidate assumptions must not be treated as implementation scope, closure authority, relabeling authority, follow-up issue authority, or package authority. ## Clarification-Required Stop Condition Execution must stop and request Tony clarification when ambiguity would affect implementation, closure, relabeling, follow-up issue creation, owner-review disposition, dependency ordering, execution boundary, validation expectation, or expected outcome. If local or repo work is required to make the ambiguity reviewable, the assistant or executor must produce a Codex-ready clarification packet or owner-review packet instead of guessing. The packet must separate candidate assumptions from owner-confirmed requirements. ## Owner-Review Required Status When Ambiguity Blocks Execution Backlog items, closeout records, and follow-up recommendations must use an owner-review required status when ambiguity blocks execution or closure. Owner-review required means no implementation, closure, reopening, relabeling, or follow-up issue creation proceeds until Tony confirms the decision or the repo contains controlling evidence. ## Relationship To Ticket-First And Anti-Manual-Toil Governance The no-assumption owner-clarification gate does not route unclear work back to Tony as manual repo toil. When the next action requires repo-local evidence, validation, generated artifacts, or closeout proof, the assistant must either ask Tony for the missing decision or produce an executor-ready clarification packet that a repo-local executor can complete. Ticket-first governance applies only after scope and owner intent are clear enough to define a bounded issue. If the issue itself is unclear, the first ticket-ready artifact should be a clarification or owner-review packet, not an implementation ticket. ## Owner-Review Gate For Ambiguous Closures A closeout requires owner review when: - The title sounds like implementation but the merged PR only evaluates, documents, or designs. - The issue has no linked PR and was closed as completed. - The issue body references follow-up work but no follow-up issue exists. - Parent or child relationships are missing or unclear. - Acceptance criteria do not distinguish implementation from evaluation or documentation. - Labels are absent or materially incomplete. ## Evaluation-Only Does Not Equal Implementation An evaluation-only closure may be correct, but it does not implement runtime behavior, source activation, queue mechanics, database adapters, workflow automation, or operational capability unless the closing PR actually changes those surfaces and validation proves the behavior. ## Documentation-Only Does Not Equal Implementation A documentation-only closure may be correct, but it does not create a capability. It must either state that no implementation is planned or link a follow-up implementation issue. ## Architecture Decision Rule An architecture decision must spawn a follow-up implementation ticket or explicitly state no implementation planned. Architecture documents may define direction, but they do not by themselves implement source registries, OKF bundles, retrieval indexes, queue engines, state machines, autonomous jobs, hooks, observability, runtime adapters, or production workflows. ## Mechanical Enforcement Contract Repository-local validation must check that: - This governance document exists. - All closure-reality classes are present. - Required closeout fields are present. - Required label policy is present. - The evaluation-only, documentation-only, and architecture-decision rules are present. - The execution-surface anti-manual-toil rule is present in governance docs and templates. - The ticket-first response rule is present in governance docs. - The post-closeout next-action contract is present in governance docs and templates. - The executor routing rule is present in governance docs and templates. - The no-assumption owner-clarification gate is present in governance docs and templates. - Candidate assumptions are explicitly distinct from approved requirements. - Clarification-required stop conditions require stop and request Tony clarification before execution continues. - The audit document exists and includes OKF, Google SDLC, multi-agent orchestration, label hygiene, parent/child linkage, and follow-up implementation sections. - Any repo-local JSON audit export, if committed in the future, contains required fields for each row. ## Operator-Only GitHub Audit Command CI does not need GitHub credentials for this validation. Operators with `gh` auth can refresh the live audit inputs with: ```bash gh issue list --repo pinklon/ai-capability-discipline --state closed --limit 1000 --json number,title,body,state,stateReason,labels,closedAt,assignees,milestone,url,closedByPullRequestsReferences gh issue list --repo pinklon/ai-capability-discipline --state open --limit 1000 --json number,title,body,state,labels,createdAt,updatedAt,url gh pr list --repo pinklon/ai-capability-discipline --state merged --limit 1000 --json number,title,state,mergedAt,labels,headRefName,baseRefName,url,body,mergeCommit ``` The exported data must be reviewed before issue reopening, closing, or follow-up implementation issue creation.