Repository navigation
✨🧑💻 - Dogfooding show exact head PR readiness in copilot status #462
Description
Is there an existing issue or feature request for this?
- I have searched the existing issues and feature requests.
What area does this improvement affect?
None
What actions does this improvement affect?
No response
Description of the idea or improvement
Extend /copilot status with a deterministic, read-only PR readiness view. For a PR conversation, resolve its exact event identity and current canonical head; for an issue use only its explicitly linked PR. Reuse the existing PR approval assessment contracts to show CI, coverage evidence, Bugbot, native reviews and actionable blockers for that exact head. Separate unavailable, pending, blocked and satisfied evidence. A successful check name or stale assessment must never certify readiness. Keep recommendation and guarded-approval authorization unchanged. One compact localized correlated reply with safe links and a primary next action, no model, approvals, repairs or lifecycle mutations. Preserve existing issue status and the SDD-readiness feature from #454. Use a bounded catalogue companion when appropriate.
Current limitations or challenges
During live dogfooding, developers have to inspect several comments and check surfaces to understand why a PR cannot proceed. The status command should explain the current head using the same strict evidence rules as approval assessment, including policy-unavailable and changed-head cases, without presenting old evidence as current.
Expected impact
A developer can ask status on an issue or PR and see verified current readiness and the next action. Accept replay without duplicate replies, missing optional linked context, incomplete/denied evidence, policy off/recommend/guarded, exact producer provenance and a head change during collection. English and Spanish catalogs, documentation and catalog evidence ship together. Plan at least 32 distinct risk-derived cases; retain all approval safety controls and existing budgets.
Alternatives considered
No response
Version of copilot
master
Additional context or comments
No response
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
vypbot commentedon Oct 11, 2026
SDD work status
Current status: The SDD is published; implementation can begin after branch verification.
SDD:
specs/guarded-pull-request-approval-status.md· Branch:feature/462-dogfooding-show-exact-head-pr-readiness-in-copilot-status· First commit:f8c53913c3a9e031fbc998efe7c9af663474d0c3Links: SDD · Branch · Commit
[-]Dogfooding show exact head PR readiness in copilot status[/-][+]✨ - Dogfooding show exact head PR readiness in copilot status[/+]vypbot commentedon Oct 11, 2026
Hi! I’m @vypbot, the Copilot assistant for this repository.
I can answer questions, explain the codebase, propose implementation and test plans, review issues and pull requests for potential bugs or security problems, and help authorized maintainers apply changes.
Try
/copilot helpto see the available commands, or mention @vypbot with your question.efraespada commentedon Oct 11, 2026
SDD Q1: Use the event's PR marker and exact repository/PR number, then a current canonical PR read. Bind evidence to repositoryId, pullNumber, headSha and baseSha; final reread must match both SHAs and policy identity. Unresolvable identity means unavailable; a changed head/base/policy means pending/superseded with a retry action, never satisfied. A same-number issue is not linkage.
SDD Q2: On an issue, accept exactly one authoritative explicitly linked open PR; zero is not-applicable, more than one is ambiguous and asks for /copilot status in the selected PR conversation. Do not select by newest number, scan branch names or assume issue number equals PR number. Optional unavailable linkage is unavailable evidence, distinct from verified absence.
SDD Q3: Valid off reports approval assessment not-applicable/disabled and makes no readiness claim; keep independently verified native facts if available. Recommend uses the same strict evidence decision, labels its satisfied outcome a recommendation snapshot and requires human review; it never approves. Guarded reports the read-only snapshot and existing observer as the next operational surface, without submitting a review or promising merge. Preserve existing producerAttested and all safety invariants. No new configuration flag.
SDD Q4: Required evidence follows the installed policy and existing ApprovalEvidence contract. Identity/current revision, strict policy, complete files/review history, trusted producer and required checks, configured coverage, Bugbot current complete evidence and native review blockers remain independent. Failed/denied/incomplete required reads are unavailable, missing running checks are pending, proven failed checks or unsafe prerequisites are blocked. Missing optional issue context is not-applicable and does not invalidate an exact PR. No guessed zeros or successful check-name inference. Reuse domain decision codes and expose safe localized primary recovery.
SDD Q5: Reuse parsePullRequestApprovalPolicy, decidePullRequestApproval and ApprovalEvidence/ApprovalCheckFact/ApprovalBugbotFact/ApprovalReviewFact through a read-only projection of PullRequestApprovalPort. Do not invoke ObservePullRequestApprovalUseCase.execute because it can publish assessments and submit approvals. Preserve checks' sourceAppId, workflowName, headSha, runId and attempt, current verified testedMergeSha and parents, numeric coverage head/base, Bugbot head/coverage/outcome/counts and reviews' commitId/completeness. Legacy assessment prose and matching names alone are inadmissible evidence. Provider DTOs stay in adapters.
SDD Q6: Use existing exact repository/conversation/source-comment correlation. A replay updates/reuses its single reply with newly verified current evidence; a new source comment gets a new reply. Fence the current source and final PR head/base/policy before publishing; if evidence changed during collection publish a superseded/pending snapshot without any stale satisfied fields. Existing notification budget, lifecycle and waiting labels remain intact.
SDD Q7: Compact report: PR and abbreviated verified head, overall state, independent CI/coverage/Bugbot/review states, policy mode/limitations and one primary action with safe PR/check/run/docs links. Priority unavailable identity/evidence, then proven blocked, then pending, then satisfied; show secondary blockers as short details. Unavailable asks to restore documented read access/inspect run and retry; blocked points to the proven failed prerequisite; pending waits/retries current revision; satisfied recommends human review where applicable and explicitly remains a snapshot. English/Spanish complete catalogs and atomic fallback. Plan at least 32 distinct cases with no-write/no-model assertions, replay/head races, documentation and catalog acceptance.
130 remaining items
vypbot commentedon Oct 13, 2026
Implementation plan
Acceptance: The catalogued companion SDD, implementation, tests, English and Spanish catalogs, and documentation are complete; at least 32 distinct risk-derived cases verify exact-head readiness and read-only behavior, and catalog validation passes without changing existing status, SDD-readiness, or approval-authorization behavior.
Need something else? Mention the bot with a question or use
/copilot help.vypbot commentedon Oct 13, 2026
Branch synchronization needs attention. Open the current status.
vypbot commentedon Oct 13, 2026
Branch synchronization needs attention. Open the current status.
vypbot commentedon Oct 13, 2026
Branch synchronization needs attention. Open the current status.