TC-6192: record E2E CI-dispatch acceptance evidence in fullsend.md - #301
Conversation
Add fullsend.md §Acceptance run → "E2E acceptance via CI dispatch (TC-6192)" documenting the CI-gated verify-pr dispatch proven end to end on PR #300 / TC-6254: qualifying PR triggers the workflow, wait-for-checks releases after CI reaches terminal, verify-pr posts to both the PR and Jira. Records all four acceptance criteria — CI-pass run (python-tests success → Overall WARN), CI-fail run (python-tests failure still releases the wait → CI Status FAIL, sub-task auto-created), report on both surfaces, and idempotency (re-run same head, no duplicate reports). Notes DENIED egress = split-trust policy working, and the interim personal-token Jira authorship pending the SA (TC-6191). Implements TC-6192 Assisted-by: Claude Code Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reviewer's GuideAdds a detailed TC-6192 acceptance subsection to fullsend.md, providing evidence that qualifying pull requests dispatch verify-pr after CI completes for both passing and failing checks, publish reports to GitHub and Jira, and avoid duplicate comments on reruns. Sequence diagram for CI-gated verify-pr dispatchsequenceDiagram
participant PR as Qualifying PR
participant Workflow as fullsend-verify-pr
participant Wait as wait-for-checks
participant CI as python-tests
participant Verify as verify-pr
participant GitHub as GitHub PR
participant Jira as Jira
PR->>Workflow: pull_request event
Workflow->>Wait: Start and await terminal CI result
CI-->>Wait: success or failure
Note over Wait: allowed-conclusions includes failure
Wait->>Verify: Release dispatch
Verify->>GitHub: Post or update sticky report
Verify->>Jira: Post or update task comment
Sequence diagram for idempotent verify-pr rerun reportingsequenceDiagram
participant Verify as verify-pr rerun
participant PR as GitHub PR
participant Jira as Jira task
Verify->>PR: Find report for same commit SHA
PR-->>Verify: Existing report comment
Verify->>PR: Edit report in place
Verify->>Jira: Update single task comment
Jira-->>Verify: One comment retained
Flow diagram for CI result reportingflowchart LR
Start[Qualifying PR] --> Checks[python-tests completes]
Checks --> Wait[wait-for-checks releases]
Wait --> Verify[verify-pr runs]
Verify --> Report[Report CI status]
Report --> Pass[CI PASS / Overall WARN]
Report --> Fail[CI FAIL / Overall FAIL]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="fullsend.md" line_range="340" />
<code_context>
+comment is authored by **Marco Rizzi** (it would be the Service Account under the
+SA token — TC-6191, on hold).
+
+**Results — all four acceptance criteria proven:**
+
+| Acceptance criterion | Result |
</code_context>
<issue_to_address>
**nitpick:** The subsection claims that all four acceptance criteria are proven, but the results table contains five separate criteria: dispatch, reporting to both surfaces, passing CI, failing CI, and rerun idempotency. This makes the acceptance evidence internally inconsistent and leaves readers unsure whether one row is extra or one criterion was omitted from the stated count.
**Suggested fix:** Change the heading to state “all five acceptance criteria proven,” or consolidate the rows so they match the intended four-criterion count.
```suggestion
**Results — all five acceptance criteria proven:**
```
</issue_to_address>Sourcery assessment
Approved.
|
🤖 Finished Verify Pr · ✅ Success · Started 4:28 PM UTC · Completed 4:37 PM UTC Commit: Runtime: claude · Model: claude-opus-4-8 · Effort: high · Cost: $3.45 |
|
[sdlc-workflow/verify-pr] Re: @sourcery-ai[bot] review — Classified as nit — minor wording/consistency observation (the subsection heading says "all four acceptance criteria proven" while the results table lists five rows); it does not affect correctness. No sub-task created. |
Verification Report for TC-6192 (commit 2a912ef)
Overall: WARNAll intent, security, and acceptance checks pass. Acceptance Criteria: 5 of 5 documented with concrete evidence (CI-pass run This comment was AI-generated by sdlc-workflow/verify-pr v0.13.9. |
The acceptance results table lists five criteria; the lead-in sentence said "four". Corrects the count to match (Sourcery nit surfaced by the verify-pr WARN on PR #301). Implements TC-6192 Assisted-by: Claude Code Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
🤖 Finished Verify Pr · ✅ Success · Started 4:42 PM UTC · Completed 4:50 PM UTC Commit: Runtime: claude · Model: claude-opus-4-8 · Effort: high · Cost: $3.98 |
Verification Report for TC-6192 (commit fb82d2f)
Overall: WARNAll intent, security, and acceptance checks pass. Acceptance Criteria: 5 of 5 documented with concrete evidence (CI-pass run This comment was AI-generated by sdlc-workflow/verify-pr v0.13.9. |
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
🤖 Finished Verify Pr · ✅ Success · Started 7:24 AM UTC · Completed 7:32 AM UTC Commit: Runtime: claude · Model: claude-opus-4-8 · Effort: high · Cost: $3.65 |
Verification Report for TC-6192 (commit 45e618b)
Overall: WARNTwo checks WARN, none FAIL -> Overall WARN (informational). Commit Traceability: commit 45e618b (vendor Jira-table limitation note) has no TC-6192 reference - 2/3 commits reference the task. CI Status: could not be fetched inside the sandbox (no gh CLI / no network egress) and is recorded as unknown/pending - not a failure. Acceptance Criteria: all five criteria are documented as proven in the new fullsend.md section "E2E acceptance via CI dispatch (TC-6192)" with concrete workflow-run IDs and commit SHAs; verification is necessarily indirect since this is recorded acceptance evidence for a CI-gated path that cannot be re-executed in-sandbox. Review feedback contains only nits (four/five wording, from sourcery-ai[bot], already classified and addressed) - no code change requests, no sub-tasks created. This report is informational; a human reviewer decides whether to merge. This comment was AI-generated by sdlc-workflow/verify-pr v0.13.9. |
The acceptance results table lists five criteria; the lead-in sentence said "four". Corrects the count to match (Sourcery nit surfaced by the verify-pr WARN on PR #301). Implements TC-6192 Assisted-by: Claude Code Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
In the CI-dispatched (sandbox) verify-pr path the CI Status check had no data — no gh CLI or egress in the sandbox — so it degraded to WARN "CI status could not be retrieved" (PR #301, TC-6192). Extend the split-trust prefetch so the pre_script fetches the PR head-SHA CI check-run outcomes on the trusted runner and embeds them in the sandbox bundle; correctness.md Check 1 reads them in sandbox mode and keeps the `gh` on-demand path for interactive mode. - pre-verify-pr.sh: prefetch repos/<repo>/commits/<sha>/check-runs into check-runs.json, reduced to name/status/conclusion/details_url - pre_verify_pr.py: build_github_bundle embeds github.check_runs (defaults to []); _github_from_dir reads check-runs.json - verify-pr-input.schema.json: add required github.check_runs (github is additionalProperties:false, so the new key must be declared) - correctness.md: Check 1 sandbox-mode branch reads pre-fetched check-runs; 1b notes failure logs are unavailable in the sandbox - dispatch-template.md, SKILL.md Step 0.7: document github.check_runs - test_pre_verify_pr.py: cover check_runs in the bundle and transform E2E re-verification on a live dispatched PR (PASS on green, FAIL on red) is deferred to a CI run. Implements TC-6257 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Assisted-by: Claude Code
1 participant
What
Records the TC-6192 E2E acceptance — the CI-gated
verify-prdispatch path proven end to end — infullsend.md§Acceptance run (new subsection "E2E acceptance via CI dispatch (TC-6192)"). TC-5815 proved the agent; this proves the CI-dispatch path.Acceptance run (vehicle: throwaway PR #300 / task TC-6254)
A qualifying PR (
tc-6192-e2e-acceptance→verify-pr-fullsend, head on the upstream repo sopull_requestsecrets + OIDC are available) linked to Jira TC-6254 (status Review,ai-generated-jiralabel, Git PR field = PR #300). All five acceptance criteria proven:wait-for-checksreleases afterpython-teststerminal, thenverify-prruns34990552632=success → verify-pr34990553318posted (CI PASS, Overall WARN) for327157734991800394=failure → wait still releases → verify-pr34991800865posted (CI FAIL, Overall FAIL) for64b818c; sub-task TC-6255 auto-created64b818c: PR stayed at 2 report comments (second edited in place), Jira stayed at 1 commentCI result is data, not a gate:
allowed-conclusionsincludesfailure, so a failing check still releases the wait and verify-pr reportsCI Status = FAIL. DENIED sandbox egress (github/raw) = split-trust policy working. Jira report authored under the interim personal token pending the SA (TC-6191).The PR #300 vehicle, branches, test issues (TC-6254/TC-6255), and scaffolding files are disposable and removed after this evidence lands.
Implements TC-6192.
🤖 Generated with Claude Code
Summary by Sourcery
Document end-to-end evidence that CI-gated verify-pr dispatch runs and reports correctly for both passing and failing checks.
Enhancements:
Documentation: