Admission refuses a sentinel pointing the wrong way

[Shashankss1205]

Closes #108.

The gap

_check_endpoints tested endpoint in _SENTINELS without looking at which side of the edge it was on. START is the graph's entry and END its exit, so:

END -> work    admitted=True  ->  MaterializationError: ValueError: END cannot be a start node
work -> START  admitted=True  ->  MaterializationError: ValueError: START cannot be an end node

Why it mattered

The run doesn't proceed either way. What was wrong is where the failure was charged and what the planner was told.

GovernedLoop treats a MaterializationError as an execution failure — max_consecutive_execution_failures (2) — rather than a rejection — max_consecutive_rejections (3). A planner got fewer retries for a mistake admission is supposed to catch than for one it does catch, and two in a row ended the run as LoopStop.EXECUTION_FAILED: a stop reason claiming the graph ran and failed, when nothing ran.

And a rejection is meant to be data. feedback() hands the planner codes and remedies. What it got instead:

The subgraph you proposed did not run: could not be built: proposal 0fcdafa536eb
was admitted but could not be assembled into a graph: ValueError: END cannot be
a start node. Propose something that addresses that.

No code, no remedy, and nothing on the admission trace event's failed-check list — because admission hadn't failed. The prompt in proposal.py already tells models the rule; the gate is what didn't hold when a model ignored it.

After

END -> work    admitted=False
    sentinel_wrong_direction: '__end__' is the graph's exit, so it cannot be an edge's source
    remedy: use '__end__' as the edge's target, or '__start__' here
work -> START  admitted=False
    sentinel_wrong_direction: '__start__' is the graph's entry, so it cannot be an edge's target
    remedy: use '__start__' as the edge's source, or '__end__' here
(control) ok   admitted=True   -> invoke -> {'note': 'ran'}

Both endpoints are still reported rather than only the first, matching every other check's posture.

Verification

• Three new tests in tests/test_admission.py. Two go red without the fix; the third is the guard that the normal START -> … -> END shape still admits, which must stay green either way.
• The refusal test asserts failed_checks() == (Check.REGISTRY,) and relies on the fact that every registered kind's factory in that file is _explode — anything that built the graph anyway would raise rather than fail quietly.
• uv run pytest green · uv run ruff check . clean.

The deep-dive selected-count moved 2,145 → 2,148 for the three new tests, which tests/test_deep_dive.py caught on the first full run.

Out of scope

Whether a MaterializationError should count against the rejection allowance in general — that is a separate question about the loop. Closing this removes the only known way to reach it from a well-formed proposal.

🤖 Generated with Claude Code