enhance(review): antigravity lane trims every plan into one run and can't tell when agy read only part of it; review one plan per run and check the read #5491

Pre-submission checklist

• I have confirmed this improves existing behavior — it does not add a new command, workflow, or concept
• I have searched existing issues and this enhancement has not already been proposed
• I have read CONTRIBUTING.md and understand I must wait for approved-enhancement before writing any code
• I can clearly describe the concrete benefit — not just "it would be nicer"

What existing feature or behavior does this improve?

The antigravity review lane in /gsd-review (review-lane invoke --slug antigravity) on multi-plan phases. Follow-up to #5049 / #5468, which listed agy's own limits as out of scope.

Current behavior

#5468 fixed delivery: with review.max_prompt_tokens_per_reviewer.antigravity set, agy now gets the trimmed gsd-review-prompt-antigravity.md. Two problems remain for any phase whose plans don't fit the budget:

1. The budget is met by cutting the plans. On our project the 45k-token budget truncated plans by 58–85% and usually omitted CONTEXT (from prompt-budget's own metadata, Phases 166–181). The lane then reviews a fraction of each plan. Across ten phases its reviews said "proceed"/LOW while Codex, on the full plans, found 2–4 HIGH defects each time, and agy's specifics were often invented (test files, schema names, requirement IDs).

2. agy can't reliably read a large prompt, and nothing reports it. On agy 1.3.5:

   • view_file returns about 46 KB per call, so a file-reference prompt is paged, and stretches with long lines get skipped.
   • After roughly 300 KB of tool output agy compacts (CHECKPOINT … truncated conversation) and reviews from the summary.
   • A single stdin message (--input-format stream-json) is cut at about 191.5 KB and replaced with <truncated N bytes>, while the run reports status: SUCCESS (agy -p reports reading files and git commits it never accessed when the prompt is truncated google-antigravity/antigravity-cli#224; the maintainers call the cap "by design").

   The lane returns rc=0 and a normal-looking review in every one of these cases.

Proposed behavior

When the antigravity prompt exceeds its budget, review one plan per agy run instead of trimming every plan into a single run, and verify each run read its plan:

• Per plan, send a small prompt that points at that plan (plus the shared CONTEXT/REQUIREMENTS), tells agy to keep paging past the per-read cap, and requires a first line restating the plan's requirements, wave, depends_on and task count.
• Fail or flag a run (for example [incomplete-read] in REVIEWS.md) when that line is missing or doesn't match the plan's frontmatter, or when the output contains <truncated.
• Merge the per-plan outputs into the lane's single review section, as today.

If per-plan batching is too much for one change, the truncation and proof-of-reading check alone would at least stop a partial read from looking like a successful review.

Reason and benefit

We tested this by hand on a 4-plan phase (255 KB prompt, gemini-4-argon-high). With per-plan pointer prompts (about 2.4 KB each), 4/4 runs restated their plan correctly. They took 3–4.5 min each in parallel, about the same wall-clock as one trimmed run. The reviews were grounded, and one found a real defect Codex missed. The single-run review of the same phase had reviewed requirement IDs and config names that are not in the plans.

Scope of changes

gsd-core/workflows/review.md (the antigravity lane's prompt construction when over budget) and the lane result handling in src/review-lane-invocation.cts / review-lane-runner.cts (the per-plan fan-out and the read check). Other lanes are unchanged. Cursor and kimi-code use the same argv-file-ref channel and could opt in, but I haven't measured their read limits.

Breaking changes

None. Phases that fit the budget keep the current single-run behavior.

Alternatives considered

• Lower default cap for antigravity (enhance(review): no CLI lane caps its prompt by default, and a configured cap trims rather than refuses #4559): makes the per-plan cuts worse.
• Inline stdin (stream-json) under ~180 KB per message: fast (about 40 s) and fully read, but needs a new prompt channel and still needs splitting for large phases. It could be the transport for the per-plan runs.
• Dropping agy as a reviewer: the per-plan runs are useful as a second opinion next to Codex.

Area affected

Core workflow (init, plan, build, verify)

Additional context

Related: #5049 / #5468 (delivery fix), #4559 (default caps; trim vs refuse), google-antigravity/antigravity-cli#224, #878, #1245 (no setting raises the read cap or disables compaction). Tested with GSD 1.16.0, agy 1.3.5, Linux.