A captain decision raised outside a gate has no presentation contract, so the first officer relays a halted worker's options

[iamcxa]

The asymmetry

At a gate the first officer cannot avoid judging. present-gate carries a
Recommend {approve | reject} line, the shared core calls that verdict
"irreducible judgment," and a blank there is visible.

Every other way a captain decision reaches the captain has no template. The
shared core lists an explicit blocker (a «halt.rebase-conflict», an unmet clarification) and a captain decision the contract requires among the
conditions that may halt the turn, and says nothing about how to present one.

So the cheapest path is to relay.

What it looks like

A worker halted on a declared size threshold and offered three options: raise
the numbers, extract a new internal package, or cut the slice in half. The FO
passed all three to the captain. The captain got a menu, and the technical
judgment they had delegated came back to them.

Prompted to look again, the FO found the answer that was not on the list: one
whole deliverable — a shell entry point, its skill doc, its tests, and four
registration points — existed so an installed-plugin user could reach the
command, and no such user existed yet. Removing it deleted real work, not a
label. Nothing on the relayed list would have found that.

A menu is worse than a wrong recommendation, because a worker's options
carry its role's blind spot. A worker told to build a thing cannot propose
building less — that option does not exist inside its remit. Relaying its list
relays the blind spot, with the FO's authority on it.

This reproduces, and it is the missing template

Same fixture, same prompt, same binary, same base revision — the only variable
is whether a decision-request template exists.

Without one, the FO relays:

Captain decision: "Publish a document and hand out its link" — implementation.

Recommend option 3: cut slice 1 in half and defer the expiry read.

Decision: Approve option 3?

No derivation, no account of what the worker could not propose, and the
recommendation is one of the worker's own three.

With one, on the same input:

Recommend authorizing a Go-only first slice: serve today's checkout user
through the Go subcommand and defer the unused installed-plugin shell,
skill, test, and registration surfaces.

Outside the worker's remit: reduce today's requirement to the Go subcommand;
an implementation worker assigned plugin reachability could not remove that
requirement itself.

It also declined to certify what it could not check: "The fixture contains no
implementation diff, so its line counts cannot be independently verified
here."

Proposed direction

A ## Decision Request section in present-gate, for a captain decision raised
outside a gate. It records nothing — gate record stays the sole recorder and
the entity's stage does not move. The shared core's halt clause routes to it.

Three fields carry the mechanism, chosen because a relay cannot fill them:

Field	Why a relay cannot fill it
Recommend {single option, as the action it authorizes}	A list is not a recommendation
Derived from: {evidence the FO read for itself}	A worker's summary does not qualify — it is an input at the level of a test result
Outside the worker's remit: {the option its role structurally could not propose, or none and why}	Only answerable from above the worker's seat

The third field carries the two questions that reach it: what is the limit that
stopped it protecting, and who is the remaining work for today. Plus the tell
— when every option on the table moves the budget and none moves the
requirement, the list was written from inside the requirement.

Why a template rather than a rule

A prose rule saying "form your own view" has nothing checking it. The gate
discipline works because of a blank that is visible when unfilled. This copies
that mechanism rather than the sentiment.

Open questions for direction

1. Home. present-gate becomes "captain-facing presentation" rather than
   gate-only, or a separate skill? The former avoids a new file and a new
   registration; the latter keeps present-gate honest to its name.
2. Field count. Three fields carry the mechanism. A draft adds Raised by,
   Alternatives, and Decision for context and captain authority — six total,
   reducible to five by folding Raised by into the header. Which floor is
   right?
3. Coverage. A live test in the shape of gate_content_live_test.sh covers
   this (it is what produced the two transcripts above), and like its neighbour
   it needs a live model and is not wired into CI. Is operator-run the intended
   resting place for this class of check?

A reference implementation with that live test exists as a draft PR, offered as
something concrete to argue against rather than as a proposal to merge.

[clkao]

The gap is real, but the contract belongs before presentation. It defines when a gate or decision package is ready, not what the FO must derive.

A ready package needs an actionable decision, evidence, consequences, and one attributable advisory recommendation. Attribution must name the role and backing model when relevant.

The composition can vary:

• An Ensign supplies the complete package.
• The FO adds advice to Ensign evidence.
• A Science Officer supplies advice when the FO is dispatch-only.

The FO can then check readiness and present the package without claiming authorship.

gate prepare already preserves Git provenance for the Artifact and References. It does not preserve contribution authorship, role, or model provenance.

Therefore, Outside the worker’s remit is a useful reasoning prompt, not a universal field. I recommend revising #751 around attributable composition and readiness, with one live dispatch-only proof instead of the large prose grader.