Docs: add coordinated batch QA lane#4145
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughIntegrates Batch QA Lane as a formal coordinated workflow stage across PR-processing and audit documentation. Defines when QA lanes are required (release-affecting, RC/final prep, CI/tooling, generator/output, workflow/process, broad runtime), how they are declared and coordinated using agent-coord primitives, their integration into Plan→Goal handoff and batch execution, verification gating in coordinator closeout, and collection/validation/reporting in post-merge audit. ChangesBatch QA Lane documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related issues
Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b10593ccbb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Greptile SummaryThis PR formalises the QA lane as a first-class batch coordination primitive in
Confidence Score: 4/5This is a documentation-only change that adds a new coordination lane to the agent workflow; it cannot break running code and is safe to merge. The QA lane additions are internally consistent and well-integrated throughout pr-processing.md. The one gap is that post-merge-audit.md is now missing the matching QA-evidence audit steps, which the file's own 'update all copies together' note says should happen in the same change. An auditor working directly from post-merge-audit.md will silently omit QA checks until a follow-up PR syncs the two files. .agents/workflows/post-merge-audit.md — the independent audit prompt and return block there were not updated to match the QA-evidence additions made to pr-processing.md. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Coordinator starts batch] --> B{Release-affecting or\nCI/tooling/workflow change?}
B -- Yes --> C[Declare QA lane in private batch state]
B -- No, docs-only/low-risk --> D[Record 'not required'\nwith one-line rationale]
C --> E[QA owner: agent-coord claim\nstable agent id + branch/worktree]
E --> F[QA runs in parallel with audit/closeout\nonce changed areas are known]
F --> G{Release-blocking\nfindings?}
G -- Yes --> H[Block readiness/promotion\nuntil fixed or waived]
G -- No --> I[Bundle non-blocking findings\nin handoff per Follow-Up Tracking Policy]
H --> J[Include QA Evidence block\nin final batch handoff]
I --> J
D --> J
J --> K[Coordinator closeout step 6:\nVerify QA evidence or 'not required' rationale]
K --> L{QA evidence missing,\nblocked, or UNKNOWN?}
L -- Yes --> M[Readiness blocker\nuntil fixed/waived]
L -- No --> N[Release-readiness/promotion\ndecisions proceed]
N --> O[Post-merge audit:\nCollect QA lane + QA Evidence block\nFlag missing/stale QA as review-gate violation]
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[Coordinator starts batch] --> B{Release-affecting or\nCI/tooling/workflow change?}
B -- Yes --> C[Declare QA lane in private batch state]
B -- No, docs-only/low-risk --> D[Record 'not required'\nwith one-line rationale]
C --> E[QA owner: agent-coord claim\nstable agent id + branch/worktree]
E --> F[QA runs in parallel with audit/closeout\nonce changed areas are known]
F --> G{Release-blocking\nfindings?}
G -- Yes --> H[Block readiness/promotion\nuntil fixed or waived]
G -- No --> I[Bundle non-blocking findings\nin handoff per Follow-Up Tracking Policy]
H --> J[Include QA Evidence block\nin final batch handoff]
I --> J
D --> J
J --> K[Coordinator closeout step 6:\nVerify QA evidence or 'not required' rationale]
K --> L{QA evidence missing,\nblocked, or UNKNOWN?}
L -- Yes --> M[Readiness blocker\nuntil fixed/waived]
L -- No --> N[Release-readiness/promotion\ndecisions proceed]
N --> O[Post-merge audit:\nCollect QA lane + QA Evidence block\nFlag missing/stale QA as review-gate violation]
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Code Review: Add coordinated batch QA laneSummary: Well-scoped docs-only change that formalizes QA as a first-class batch lane in the PR-processing workflow. The section is logically structured, the QA Evidence block template is concrete and actionable, and all integration points (coordinator closeout, coordination state, handoff FYI, post-merge audit checklist) are updated consistently within 1. Cross-file sync gap —
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_33e29e23-8cfd-488e-b4fa-ca71ca6e6a4d) |
Code Review: Docs — add coordinated batch QA laneSummary: Documentation-only change to What works well
Issues1. Paragraph break missing (minor formatting bug) Lines 403–404 in the file are directly adjacent without a blank line: In CommonMark, a single newline inside a paragraph does not create a new paragraph — both sentences will render as one flowing paragraph, burying the mixed-batch rule. (Inline comment posted.) 2. Deferred sync work has no tracking issue The PR body notes that
Those files now describe a QA-less workflow while this file describes a QA-lane workflow. The PR intentionally deferred the work and chose not to open a follow-up issue. That's a risky call — the inconsistency is invisible to future contributors and to the next post-merge audit unless a concrete tracker item exists. Recommend opening a follow-up issue before merging, or adding a 3. The QA Evidence template includes: These six values are used across the file but never formally defined in one place a reader can anchor to. The inline hint ( VerdictThe core logic is sound and the PR is low-risk (docs-only). The missing blank line is a straightforward fix. The deferred sync-work tracking and the disposition-values cross-reference are worth addressing before merge to avoid silent drift in the skill files. |
Code Review: Docs add coordinated batch QA laneOverview: This PR documents a first-class Batch QA Lane in Two issues need attention: Issue 1 (blocking): Sync-note violated — post-merge-audit.md has zero QA references Line 1347-1349 of the file has an explicit directive: "Sync note: this scope algorithm is intentionally mirrored in Running The PR body defers this sync and intentionally omits a follow-up issue. Deferred plus untracked means the gap is invisible to future contributors and to the next auditor using the skill chain. A tracking issue should be opened before merge. Issue 2 (minor): process-gap disposition values have no definition anchor The QA Evidence block template (lines 435-436) lists Issue 3 (minor): Seven-field template for a not-required QA lane adds noise When QA is intentionally omitted, agents still must fill all seven fields, writing not-applicable for most of them. A one-line shorthand for the not-required case in the template would reduce noise for low-risk batches. Verdict: The QA lane design is well-structured and fills a real coordination gap. Issue 1 is the most actionable since it means the new requirements will be silently skipped in common audit workflows. |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_5925dd59-48a4-45e5-8a6e-308503bac0d7) |
Code Review: Docs — Add Coordinated Batch QA LaneOverall: Good intent — first-class QA lanes, Critical: PR description contradicts the actual diffThe PR body explicitly states:
Yet the diff touches four files:
This is a self-contradiction. The description says the cross-file sync was deferred, but the commit includes it. One of the two must be corrected: either update the PR description to reflect that the sync was intentionally included (and explain why the scope changed), or revert the three extra files and open the follow-up. As written, the description misleads reviewers about the actual scope of change. Notable: Semantic ambiguity in
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c813c7454d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_0d328f9f-b320-4c7a-93ab-642858d0f798) |
Code Review: Batch QA LaneOverviewThis PR introduces a formal Batch QA Lane as a first-class sibling to implementation and audit work in the agent workflow documentation. The core intent is sound: QA evidence should be explicit, owned, and verifiable before release or batch-readiness decisions. The template, required/not-required distinction, and tiered output ordering are well-thought-out. Critical: PR description directly contradicts the actual diffThe Review / Churn Notes section explicitly states:
But the diff contains substantive changes to all four files:
The PR body also says "Follow-up issue: not opened. The out-of-scope sync work is bundled here for maintainer visibility" — but the changes aren't bundled as comments or a separate section; they're committed as live doc changes. The PR body needs to be updated to accurately reflect what was actually changed, or the out-of-scope changes need to be reverted. Including the deferred files is arguably the right call from a consistency standpoint — an incomplete QA lane definition that only touches Minor issues1. QA Evidence block lacks an explicit staleness anchor The template does not include a 2.
3. Sync note triangle is incomplete in
|
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_5cd699e0-6639-4787-9776-8acd715fbabc) |
justin808
force-pushed
the
jg-codex/4127-batch-qa-lane
branch
from
32224e8 to
aac7ce8
Compare
|
Batch handoff for batch-2026-06-20-newer-issues / issue #4127 Immediate maintainer attention: none. FYI / decisions made:
Confidence note:
|
Code Review — PR #4145: Docs: add coordinated batch QA laneOverviewThis PR formalizes QA as a first-class batch lane with claim/heartbeat coordination, mandatory evidence blocks, and audit verification hooks. The structure is sound and the integration across A few issues worth discussing before merge: Process integrity: stated scope vs. actual scopeThe Review / Churn Notes say:
Yet the PR modifies five files. The description frames the cross-file changes as "deferred/rejected" findings from
This is a process gap the new QA lane is specifically designed to catch — it's worth resolving explicitly rather than leaving it in the notes.
|
Code Review: Docs — Batch QA LaneOverall: Well-structured addition. The canonical QA Evidence block template is clear, the status taxonomy is unambiguous, and the derivation rule ( BugIndentation in ObservationsSync maintenance surface. The derivation rule and the QA-coverage status definitions ( Unresponsive QA owner path. The canonical section says an unresponsive owner maps to
None of these are blockers. The indentation fix is the only code change needed before merge. |
Review: Batch QA Lane Documentation (current head
|
Adversarial PR Review — #4145: Docs: add coordinated batch QA laneHead SHA: `a10c72cee630347176c6c912af3802992d95a673` ScopeDocs-only change to 5 internal agent workflow files. No runtime, CI job, or application code paths affected. `required-pr-gate`: SUCCESS; all code-analysis checks passed or skipped. Two checks still QUEUED (`markdown-format-check`, `markdown-link-check`) and one IN_PROGRESS (`claude-review`). `mergeStateStatus: BLOCKED` reflects those pending checks. FindingsDISCUSS — `"done"` used as a QA lane final state in the table examples but never formally enumeratedThe new worked-issue/QA-lane coverage table in `.agents/workflows/post-merge-audit.md` (lines 315, 318) uses `done` as the Final state for completed QA lanes: Neither the PR-target final-state enum in `pr-processing.md` (`merged`, `ready-gates-clean`, `ready-no-merge-authority`, …) nor the worked-issue state vocabulary (`merged`, `closed`, `parked`, `blocked`, `no-PR`, `done-unmerged`, `UNKNOWN`) contains a bare `done`. QA lanes don't produce merges, so `done-unmerged` is the closest existing term — but the examples diverge from it. If `done` is the intended terminal state for QA lanes, it needs a one-line definition in the Batch QA Lane section alongside `not_applicable`. Without it, agents reading the table header note ("Final state is the operational lane outcome") have no canonical source for what valid QA lane terminal states are, and may produce inconsistent table entries. Suggested fix: Add to the Batch QA Lane section in `pr-processing.md` a sentence like: "Valid QA lane terminal states in the coverage table are: `done` (QA completed), `blocked` (release-blocking finding unresolved), `not_applicable` (QA not required), and `waived` (explicit waiver recorded)." DISCUSS — "developer-workflow changes" category boundary is unspecified for process documentation updatesThe Batch QA Lane section in `pr-processing.md` (line 455) lists "developer-workflow changes" as a required QA trigger. This PR is itself a change to developer workflow files (`.agents/workflows/.md`, `.agents/skills/.md`) and records `QA required: no` in its own evidence. The exemption path says "docs-only, no-code process" batches may skip QA, but the text never explicitly names where the line is between "process documentation update" (exempt) and "developer-workflow change" (requires QA). A future agent following the rule literally might interpret any update to `.agents/workflows/*.md` as a "developer-workflow change," creating a recursive obligation where every workflow documentation edit requires a QA lane that runs the same process being documented. Suggested fix: Add a parenthetical to the "developer-workflow changes" category — e.g., "developer-workflow changes (meaning changes to runtime tool behavior, CLI commands, or build/CI paths, not to process documentation)." NON_BLOCKING_DECISION — Validation evidence SHA in PR body is stale vs. current headThe PR body records: "Current-head required CI: `pr-ci-readiness` → `READY` for PR #4145 at `01671ca9579b72b120d0dd3c1229c28a7b876d17`." Current `headRefOid` is `a10c72cee630347176c6c912af3802992d95a673`. The PR's own stated merge criterion says "Local validation evidence above remains current after the final push." `required-pr-gate` shows SUCCESS at the current head, so the actual CI gate is met — this is a documentation staleness issue against the PR's own process, not a CI blocker. Noting for completeness; does not block merge. FOLLOWUP — `Release-blocking status` derivation rule duplicated verbatim in three filesThe mapping
If a new QA status is added later, all three must be updated. Two of the three occurrences could reference the canonical location instead: "derive Release-blocking status per `pr-processing.md` → Batch QA Lane." FOLLOWUP — No transition note for in-flight batches predating this changeOnce this merges, the next post-merge audit covering a batch started before this PR will find no QA Evidence block in prior handoffs. Under the new rules, absent QA evidence maps to Merge GateNo BLOCKING findings. Two DISCUSS items require a maintainer decision before the merge gate is satisfied:
The two FOLLOWUP items (duplicated derivation rule, no transition note) are advisory and do not block merge. `merge_authority: auto_merge_when_gates_pass` applies after pending CI checks complete and the two DISCUSS items are resolved or explicitly waived. |
Code ReviewOverall: Solid, well-structured documentation PR. The QA lane contract is internally consistent across all five files, the capitalization convention (uppercase Two minor concerns: 1. Missing mixed-batch example. The Batch QA Lane section (pr-processing.md lines 462–467) describes mixed batches — applying QA only to the qualifying subset of a batch — but none of the seven QA Evidence examples demonstrates this case. In practice a mixed batch (e.g., three doc PRs plus one CI config PR) is probably more common than the all-or-nothing cases shown. An eighth example would clarify how 2. Minor intra-file redundancy in pr-batch/SKILL.md. Lines 347–350 ("For every batch that requires QA under the canonical workflow's Batch QA Lane decision, make sure the QA lane is represented...") largely repeat what lines 150–160 already state in the same file. Two mentions of the same rule in close proximity within a single skill file could create confusion if they're ever updated out of sync. Consider trimming the later paragraph to a forward reference only, or merging both into one place. Neither issue affects correctness of this PR's changes. Everything else — the release-blocking status derivation rule, the waiver verification requirements, the |
Review: Batch QA Lane DocumentationThe five-file change is coherent and the core QA lane concept is defined consistently — capitalization convention (`UNKNOWN` vs `unknown`) is stated correctly in every file, the Evidence block structure is sound, and the scope algorithm mirrors correctly. A few issues below that range from minor wording imprecision to a genuine staleness-definition gap worth closing before this pattern is relied on in production audits. Issues found1. Cross-reference imprecision — "section label" that isn't one (minor) `plan-pr-batch/SKILL.md` line 75–76 and `pr-batch/SKILL.md` lines 95–97 and 153–154 both refer to the "Allowed fallback evidence:" label in `pr-processing.md` as if it is a section heading or named definition block. In `pr-processing.md` it is a single bold inline label inside a bullet (line 486), not a section header. A reader skimming for a section titled "Allowed fallback evidence:" will not find one. The cross-references should say "the bold label Allowed fallback evidence: within the Batch QA Lane section bullet on private-state fallback" (or simply quote the one-sentence rule directly). 2. `Tested at` third option not propagated (minor, but affects audit correctness) The canonical QA Evidence block (`pr-processing.md` line 503) defines: 3. `QA lane` field is unstructured (design note) `pr-processing.md` line 501 packs six distinct data points (agent id, branch/worktree, claim status, last heartbeat status, owner requirement, UNKNOWN caveat) into a single free-form string field. The `post-merge-audit` step must verify claim/heartbeat state from this field, but without a defined separator the values cannot be reliably parsed or validated. Consider either a structured sub-block or a defined delimiter (e.g., `|`) so audit verification can be mechanical rather than natural-language. 4. "Stale" QA evidence is never defined (gap) Both `pr-processing.md` (line 791, 888) and `post-merge-audit/SKILL.md` (line 164) flag "stale" QA evidence as a readiness blocker, but no file defines what makes QA evidence stale (commits pushed after `Tested at` SHA? Force-push? Time window?). `post-merge-audit/SKILL.md` line 125–126 implicitly handles this by requiring `Tested at` to match the current PR head SHA, which is the right operationalization — but it should be stated as the definition so agents following the rule know why they're checking SHA parity, not just that they should. 5. `Batch Plan Format` "QA Lane decision" field has no template (minor) `plan-pr-batch/SKILL.md` line 175 adds `Batch QA Lane decision and QA Evidence expectations:` to the Batch Plan Format but provides no example or template value. The Goal Prompt template (line 194+) does show: `Batch QA Lane: <required: lane/owner/scope/private-state or UNKNOWN fallback | not required: rationale>`. The Batch Plan field should either link to the Goal Prompt format or provide its own equivalent inline template, otherwise the two plan artifacts may diverge in content. 6. Field name casing inconsistency in Completed Batch Handoff Prompt (nit) `post-merge-audit.md` line 87 uses "release-blocking status" (lowercase) in a checklist that the QA agent fills in, but the canonical QA Evidence block field is `Release-blocking status` (title case, line 510 of `pr-processing.md`). An agent filling out the handoff prompt may use inconsistent casing, making post-hoc extraction brittle. No concerns with:
|
Address-review summaryScan scope: full review loop through 2026-06-23T09:07:40Z. Mattered
Optional
Skipped
Next default scan starts after this comment. Say |
1 participant
Why
Refs #4127.
Batch processing has clear implementation, closeout, and audit mechanics, but QA can still be treated as an informal side activity. This documents the MVP QA lane so release-affecting, CI/tooling, generated-example, developer-workflow, and broad behavior batches have explicit QA ownership, evidence, and audit verification before readiness or release-promotion decisions rely on the batch.
What Changed
Batch QA Lanesection to.agents/workflows/pr-processing.mddefining when QA is required, when it can be recorded asnot required, how QA can run concurrently, and how release-blocking versus follow-up findings are handled.QA Evidencehandoff block with claim/heartbeat state, checked scope,Tested at, automated/manual checks, findings, QA required/rationale, QA lane status, release-blocking status, and process-gap disposition..agents/skills/plan-pr-batch/SKILL.md,.agents/skills/pr-batch/SKILL.md,.agents/skills/post-merge-audit/SKILL.md,.agents/workflows/post-merge-audit.md, and.agents/workflows/pr-processing.md.Validation
git fetch --prune origin main-> success; branch is current withorigin/mainand GitHub merge state isCLEAN./Users/justin/.codex/worktrees/a423/react_on_rails.AGENTS.md,.agents/skills/pr-batch/SKILL.md, and.agents/workflows/pr-processing.mdexist.codex-91b3-pr-4145-takeover.pr-security-preflight --repo shakacode/react_on_rails 4145reportedSECURITY_PREFLIGHT_BLOCKEDbecausetimelineItemscoverage was truncated (fetched 100 of 233). Maintainer acknowledged that pagination risk and authorized takeover for this PR.e48a4aa360d85bfce634c562d5ec798ff2faec36.script/ci-changes-detector origin/main-> documentation-only changes; recommended CI jobs: none.ruby .agents/skills/plan-pr-batch/scripts/check_goal_prompt_size.rb-> pass (goal_prompt_template_chars=3673,oversized_candidate_chars=17281,split_fallback_goal_prompt_chars=3721).git diff --check origin/main...HEAD && git diff --check-> pass.pnpm start format.listDifferent-> pass.bin/check-links-> pass (3022 Total,2116 OK,0 Errors,906 Excluded).9 Total,9 OK,0 Errors).pr-ci-readiness->READYfor PR Docs: add coordinated batch QA lane #4145 ate48a4aa360d85bfce634c562d5ec798ff2faec36.claude-reviewsuccess for current head; CodeRabbit success/approved evidence present.script/pr-merge-ledger 4145 --strict --pretty --changelog-classification not_user_visible --finding-dispositions /tmp/pr4145-dispositions.json->complete_allowed: true, no violations, no unknown fields. Artifact:/tmp/pr4145-merge-ledger.json.Review / Churn Notes
[auto-deferred]rationale to avoid restarting the review loop.Process Gap Disposition
CI / Label Decision
Labels: none. This is a docs-only internal workflow update;
script/ci-changes-detector origin/mainrecommends no CI jobs.Merge Authority
merge_authority: auto_merge_when_gates_pass. Maintainer granted merge authority in the active batch session after authorizing #4145 takeover.
Merge criteria satisfied before merge:
origin/mainand GitHub merge state isCLEAN.READY; configured review-agent checks have no current-head blocker.script/pr-merge-ledgerpasses withcomplete_allowed: trueandchangelog_classification: not_user_visible.Note
Low Risk
Documentation-only changes to internal agent workflows with no runtime, CI, or application code paths affected.
Overview
Introduces a first-class Batch QA Lane so coordinators cannot treat QA as informal side work when batches affect release, CI/tooling, generated output, workflows, or broad runtime behavior.
The canonical definition lives in
.agents/workflows/pr-processing.md: when QA is required vsnot requiredwith rationale, how aqalane is claimed and heartbeated, allowedUNKNOWNprivate-state fallback evidence, and a mandatory QA Evidence handoff block (Tested at, scope, lane status, release-blocking status).Planning and execution skills (
plan-pr-batch,pr-batch) now require declaring the Batch QA Lane in batch plans and goal prompts and block calling a QA-required batch ready without current evidence.Post-merge audit paths collect QA lanes after scope resolution, verify QA evidence freshness and scope, classify coverage (
satisfied,blocked,waived, etc.), and surface QA gaps as readiness blockers in audit output and issue planning.Reviewed by Cursor Bugbot for commit 9e630f6. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by CodeRabbit