@@ -194,6 +194,13 @@ The planner reviews the plan against the user intent, repository evidence,
 instructions, specifications, and observable validation. A failed review returns
 a focused prompt that the implementor can apply directly.
 
+A pull-request review needs the pull request's complete current state, and the
+planner cannot fetch it: the supervised exercise denies agent network access. So
+the review prompt renders every category the handle resolves — existing reviews,
+comments, and check results — rather than a subset, and names the revision under
+review: the diff at the head identity against the base. A verdict describes that
+head alone, and a moved head requires a fresh review.
+
 Factual disagreement calls for more evidence. When evidence leaves more than one
 viable choice, the agents present the options, consequences, and recommendations
 to the user. Convergence means that the final plan reflects a shared
@@ -244,9 +251,10 @@ A stage that only produces material for the next prompt is a text component:
 `InstructionFiles` and `Discovery` render their result and a caller's `as` binds
 that text. A stage that resolves a user decision inside itself declares
 `returns` instead. `Planning` and `Implementation` each run a review loop that
-asks the user a question, so each returns its prose, its parsed verdict, the
-complete `UserDecision` it resolved, and the derived `authorized` and `terminal`
-its caller gates on. `<UserCheckpoint>` does the same for a single decision.
+asks the user a question, so each returns its prose, its parsed verdict's fields,
+and the complete `UserDecision` it resolved — the sources its caller gates on,
+and nothing derived from them. `<UserCheckpoint>` does the same for a single
+decision.
 
 The rule is about where authority lives. A controller that resolves a decision
 and returns only a rendering of it has discarded the thing its caller needs: the
@@ -256,15 +264,27 @@ boundary as data or it does not cross at all.
 
 ### A stage fails rather than returning a half-record
 
-A stage's `<Output>` region runs under the `output` error mode; everything
-outside it is documentation and runs under `throw`. An undecided error at either
-position fails the run rather than producing a result a caller would bind. The
-two modes differ in what a printing boundary may do about it: a `<PrintErrors>`
-region can print an `output` decision instead of failing, and `throw` is the one
-mode it cannot replace — a printed error in documentation is one nobody can
-read. Neither rescues a stage here, because every stage's parsing sits in
-documentation. That is what makes each stage's final `<Parse>` a gate: malformed
-agent output cannot reach control flow or a deterministic effect.
+The two component kinds fail differently, and neither can hand a caller a
+half-record.
+
+A **text component** is split by its `<Output>` boundary: the region inside runs
+under the `output` error mode, everything outside is documentation and runs
+under `throw`. `InstructionFiles` and `Discovery` are the two here, and each
+puts its work in documentation, so an undecided error ends the run rather than
+printing into a region nobody reads.
+
+A **value component** declares `returns`, so it renders nothing and cannot
+contain `<Output>` at all — that would be a structural error. Its entire body
+runs fail-fast, and a failure binds nothing: there is no partially validated
+return for a caller to gate on. `Planning`, `Implementation`, and
+`UserCheckpoint` are value components.
+
+The two error modes differ in what a printing boundary may do about a failure: a
+`<PrintErrors>` region can print an `output` decision instead of failing, and
+`throw` is the one mode it cannot replace — a printed error in documentation is
+one nobody can read. Neither rescues a stage here. That is what makes each
+stage's final `<Parse>` a gate: malformed agent output cannot reach control flow
+or a deterministic effect.
 
 A failing region keeps only what it had already rendered. That partial text
 reaches the output stream; nothing after the failure does. Continuing after a
@@ -305,7 +325,8 @@ Two are not implemented:
   establish is itself shipped and already inherited by files, globs, processes,
   and agents.
 - `<PullRequest>` creates or resolves the pull request for a branch and returns
-  its identity and state (#295).
+  a structured handle: number, URL, head and base identities, state, reviews,
+  comments, and checks (#295).
 
 Each environmental operation declares its inputs and preconditions, reconciles
 existing state, returns a structured handle, and records its observed effects. A
 
@@ -220,14 +220,38 @@ remote effects.
         #{pullRequest.number} ({pullRequest.state}) {pullRequest.url}
         head {pullRequest.headSha} onto base {pullRequest.baseSha}
 
+        Reviews:
+
+        <Each in={pullRequest.reviews} let="review">
+        - {review.author} ({review.state}) on {review.headSha}: {review.body}
+        </Each>
+
+        Comments:
+
+        <Each in={pullRequest.comments} let="comment">
+        - {comment.author} on {comment.path}: {comment.body}
+        </Each>
+
+        Checks:
+
+        <Each in={pullRequest.checks} let="check">
+        - {check.name}: {check.status} / {check.conclusion} — {check.url}
+        </Each>
+
         Result contract:
 
         {pullRequestVerdictSchema}
 
-        Review the pull request against the authorized plan and instruction
-        content above. Classify every finding and include a focused revision
-        prompt when the review fails. Return only JSON matching the supplied
-        result contract.
+        Review the diff at {pullRequest.headSha} against {pullRequest.baseSha},
+        together with the authorized plan and instruction content above. The
+        reviews, comments, and checks listed here are the complete current
+        state; you have no network access, so do not attempt to fetch more.
+
+        A verdict is about one head. If the head moves, this verdict no longer
+        describes the pull request and a fresh review is required.
+
+        Classify every finding and include a focused revision prompt when the
+        review fails. Return only JSON matching the supplied result contract.
       </Prompt>
 
       <Loop max={2}>
@@ -278,6 +302,24 @@ remote effects.
     #{pullRequest.number} ({pullRequest.state}) {pullRequest.url}
     head {pullRequest.headSha} onto base {pullRequest.baseSha}
 
+    ### Reviews
+
+    <Each in={pullRequest.reviews} let="review">
+    - {review.author} ({review.state}) on {review.headSha}
+    </Each>
+
+    ### Comments
+
+    <Each in={pullRequest.comments} let="comment">
+    - {comment.author} on {comment.path}: {comment.body}
+    </Each>
+
+    ### Checks
+
+    <Each in={pullRequest.checks} let="check">
+    - {check.name}: {check.status} / {check.conclusion}
+    </Each>
+
     ## Planner review
 
     Passed: {verdict.passed}
@@ -351,19 +393,41 @@ and nothing derived from them. The caller reads
 `decision.proceed && verdictPassed` directly, so there is no second copy of that
 answer to disagree with the first.
 
-The pull-request handle is **not** returned. `<PullRequest>` (#295) resolves a
-structured handle carrying the number, URL, head and base identities, state,
-reviews, comments, and checks, and `start.md` consumes none of it — the artifact
-ledger (#291) records the effect and its handle independently. The `report`
-above renders the specific fields a reader needs. A return field typed `string`
-would be worse than useless here: a conforming `<PullRequest>` would perform its
-durable effects and only then fail this component's return validation. If a
-later caller genuinely needs the handle, it is added with #295's object schema,
-never a placeholder.
-
-The agent, parsing, and control-flow syntax runs today. A value component's body
-runs fail-fast, so the final `<Parse>` in each repair loop ends the stage rather
-than passing malformed data to a durable effect.
+## The reviewer sees the complete pull request
+
+`<PullRequest>` (#295) resolves a structured handle carrying the number, URL,
+head and base identities, state, reviews, comments, and checks. This stage
+consumes all of it, because the planner cannot recover any of it itself: agent
+network access is denied for the supervised exercise, so whatever the prompt does
+not render is invisible to the review. Every category is rendered explicitly —
+each collection iterated with `<Each>`, never stringified as an object — into
+both the planner prompt and the checkpoint material the user reads. A review that
+cannot see a failing check or an existing objection is not adversarial, it is
+uninformed.
+
+The prompt names the revision under review: the planner reviews the diff at
+`headSha` against `baseSha`, and a verdict describes that head only. A moved head
+invalidates it and a fresh review is required — the same rule #295 states for a
+stored verdict.
+
+The **member field names** used above — a review's `author`, `state`, `headSha`
+and `body`, a comment's `author`, `path` and `body`, a check's `name`, `status`,
+`conclusion` and `url` — are #295's to settle. This document depends on that
+schema rather than defining a competing one; what is settled here is that the
+planner receives the complete snapshot, not what each member is called.
+
+The handle stays internal: it is not part of this component's declared return,
+because `start.md` gates on the verdict and decision rather than on pull-request
+state, and the artifact ledger (#291) records the effect and its handle
+independently. A return field typed `string` would be worse than useless — a
+conforming `<PullRequest>` would perform its durable effects and only then fail
+this component's return validation. If a later caller genuinely needs the handle,
+it is declared with #295's object schema, never a placeholder.
+
+The agent, parsing, and control-flow syntax runs today. This component declares
+`returns`, so it contains no `<Output>` and its whole body runs fail-fast: the
+final `<Parse>` in each repair loop ends the stage rather than passing malformed
+data to a durable effect, and a failure binds nothing at all.
 
 The user's decision outranks the verdict here too. `reviewCheckpoint.proceed` is
 read before `verdict.passed`, so a declined pull-request review leaves the loop
 
@@ -254,12 +254,14 @@ presenting it as reviewed — a rejection is neither a revision request nor an
 acceptance. `<Break />` works from that nested position, so the two conditions
 compose without a flag binding between them.
 
-A value component's body runs fail-fast, which is what makes the bounded repair
-turns a real gate: `<SafeParse>` absorbs a malformed verdict so the document can
-show the correction prompt, and the final `<Parse>` ends the stage if the
-candidate is still invalid. `throwOnError` on each `<Prompt>` is required for the
-same reason — a failed prompt without it records its failure and returns its
-text, raising nothing.
+This component declares `returns`, so it contains no `<Output>` and there is no
+documentation split: the whole body runs fail-fast and binds nothing if it
+fails. That is what makes the bounded repair turns a real gate — `<SafeParse>`
+absorbs a malformed verdict so the document can show the correction prompt, and
+the final `<Parse>` ends the stage if the candidate is still invalid, rather than
+returning something half-formed for a caller to branch on. `throwOnError` on each
+`<Prompt>` is required for the same reason: a failed prompt without it records
+its failure and returns its text, raising nothing.
 
 **Outstanding gap: the terminal policy for exhaustion.** Reaching `max`
 completes the loop normally — exhaustion is not a failure and produces no
 
@@ -218,11 +218,6 @@ from continuing after the bounded repair loop with malformed output. The schema
 is ordinary captured document content rather than a registry entry or
 `<Prompt schema>` prop.
 
-A value component's body is not documentation in the ordinary sense — a value
-root and a value component both run fail-fast, so the assessment, the repair
-loop, and the elicitation all end the stage rather than binding something a
-caller would mistake for a decision.
-
 `<Agent name={agent}>` reads the bare binding because that is the expression-
 prop spelling current main supports, while `{props.purpose}` in the prompt body
 is text interpolation; #305 unifies the two.
 
@@ -86,12 +86,13 @@ else renders nothing — not an error, a value with no destination.
 ### What a failing stage returns
 
 Nothing partial. A text component's `<Output>` region runs under the `output`
-error mode and everything outside it under `throw`; a value component's whole
-body runs fail-fast. Either way an undecided error fails the run rather than
-producing a result the caller would bind, and a value component that fails binds
-nothing at all — there is no half-validated return. A failing `<Output>` region
-keeps only the text it had already rendered, and that text reaches the output
-stream; nothing after the failure does. A failed run is still a complete
+error mode and everything outside it under `throw`. A value component has no such
+split — it renders nothing, so `<Output>` inside one is a structural error — and
+its whole body runs fail-fast. Either way an undecided error fails the run rather
+than producing a result the caller would bind, and a value component that fails
+binds nothing at all: there is no half-validated return. A failing `<Output>`
+region keeps only the text it had already rendered, and that text reaches the
+output stream; nothing after the failure does. A failed run is still a complete
 record — replay restores its output and its failure without re-executing
 anything.
 
 
@@ -67,12 +67,15 @@ structure and read where an error is raised:
 A failing region keeps what it had already rendered: that text reaches the
 output stream, and nothing after the failure does.
 
-A component body is split by its `<Output>` boundary: the region inside runs
-under `output`, everything outside is documentation and runs under `throw`.
-Every stage in this workflow puts its prompts, parsing, and control flow outside
-`<Output>`, so a stage returns a complete validated result or it fails — it
-never returns a half-record. `<Retry>` and `<Result as>` would let a document
-handle a failure instead of ending on it; both are defined and unbuilt.
+A **text component**'s body is split by its `<Output>` boundary: the region
+inside runs under `output`, everything outside is documentation and runs under
+`throw`. A **value component** declares `returns` and renders nothing, so it
+cannot contain `<Output>` — that is a structural error — and its entire body
+runs fail-fast, binding nothing when it fails.
+
+Either way a component returns a complete validated result or it fails; neither
+kind can hand a caller a half-record. `<Retry>` and `<Result as>` would let a
+document handle a failure instead of ending on it; both are defined and unbuilt.
 
 **Missing: printing an `output` decision.** The `output` row above is the
 settled contract, and the engine does not meet it yet — an outer
 
@@ -257,24 +257,30 @@ use the bare spelling in expression props, and #305 migrates them.
 
 ## Error modes in a stage
 
-Every stage component is split by its `<Output>` boundary, and the two halves
-fail differently:
+How a component fails depends on which kind it is.
+
+A **text component** — `InstructionFiles` and `Discovery` — is split by its
+`<Output>` boundary:
 
 - Everything **outside** `<Output>` is documentation and runs under the `throw`
   error mode. The first error stops the body and fails the run, and no
-  `<PrintErrors>` region can print it instead — which is what makes each
-  stage's final `<Parse>` a real gate rather than a formality.
+  `<PrintErrors>` region can print it instead.
 - The **`<Output>` region** runs under the `output` error mode: an undecided
   error there fails the run too, though a `<PrintErrors>` region may print it
   instead. Either way the region keeps what it had already rendered — that
   partial text reaches the output stream, and nothing after the failure does.
   Printing an `output` decision is the contract; the engine does not do it yet
   (#327).
 
-So a stage either returns a complete, schema-validated result or it fails. It
-never returns a half-record. The `throwOnError` on each `<Prompt>` is
-load-bearing for the same reason: a failed prompt without it records its
-failure and returns its text, raising nothing for the error mode to decide.
+A **value component** — `UserCheckpoint`, `Planning`, `Implementation` — has no
+such split. Declaring `returns` means it renders nothing, so `<Output>` inside
+one is a structural error; its whole body runs fail-fast and a failure binds
+nothing at all. There is no partially validated return for a caller to gate on.
+
+Either way a stage returns a complete, schema-validated result or it fails, and
+never a half-record. The `throwOnError` on each `<Prompt>` is load-bearing for
+the same reason: a failed prompt without it records its failure and returns its
+text, raising nothing for the error mode to decide.
 
 ## What runs today
 
@@ -327,11 +333,13 @@ with nothing derived from them. The three checkpoints bind decisions. This
 document renders the human-readable reports from those returned fields rather
 than receiving them pre-rendered.
 
-Neither stage returns the pull-request handle. `<PullRequest>` (#295) resolves a
-structured handle with the number, URL, head and base identities, state, reviews,
-comments, and checks; nothing here consumes it, and the artifact ledger (#291)
-records it independently. `Implementation` renders the fields a reader needs into
-its `report`.
+Neither stage returns the pull-request handle, but `Implementation` consumes it
+in full. `<PullRequest>` (#295) resolves the number, URL, head and base
+identities, state, reviews, comments, and checks; the planner has no network
+access, so `Implementation` renders every category explicitly into the review
+prompt and into the checkpoint material, and the artifact ledger (#291) records
+the effect independently. What `start.md` gates on is the verdict and the
+decision, so the handle itself never crosses the stage boundary.
 
 ## Details