admission: END is accepted as an edge source and START as a target, so a graph that cannot be built is admitted

[Shashankss1205]

What happens

_check_endpoints accepts START and END in either role:

for role, endpoint in (("source", edge.source), ("target", edge.target)):
 if endpoint in _SENTINELS or endpoint in names or endpoint in self.known_nodes:
 continue

But the sentinels are directional — START is the graph's entry and END its exit — so a proposal carrying END -> x or x -> START is admitted and then dies in Materializer:

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

Reproduce:

from grapharc.planner import (
 AdmissionChecker, CostEstimate, EdgePolicy, EdgeRule, Materializer,
 NodeRegistry, NodeSpec, ProposedEdge, ProposedNode, Subgraph,
)
from grapharc.runtime.graph import START, END
from grapharc.runtime.state import GraphARCState

class S(GraphARCState):
 note: str = ""

reg = NodeRegistry([NodeSpec(name="work", description="w",
 worst_case=CostEstimate(iterations=1),
 factory=lambda build: (lambda state: {"note": "ran"}))])
ck = AdmissionChecker(registry=reg, edge_policy=EdgePolicy(rules=(EdgeRule(action="allow"),)))
mz = Materializer(registry=reg, state_schema=S, writes={"work": {"note"}})

sub = Subgraph(
 nodes=(ProposedNode(name="work", kind="work"),),
 edges=(ProposedEdge(source=START, target="work"),
 ProposedEdge(source=END, target="work")),
)
r = ck.check(sub)
print(r.admitted) # True
mz.materialize(r, sub) # MaterializationError: END cannot be a start node

Why it matters

Not because the run proceeds — it does not — but because the failure is charged to the wrong allowance and reaches the planner in the wrong shape.

GovernedLoop counts a MaterializationError as an execution failure:

except MaterializationError as exc:
 return _Execution(state=state, materialization_error=f"could not be built: {exc}")

which lands in failed_in_a_row against max_consecutive_execution_failures (2) rather than rejected_in_a_row against max_consecutive_rejections (3). So a planner gets fewer retries for a mistake admission is supposed to catch than for one it does catch, and two of these in a row end the run with LoopStop.EXECUTION_FAILED — a stop reason that says the graph ran and failed, when nothing ran at all.

The second half is the shape. A rejection is meant to be data: AdmissionResult.feedback() hands the planner a per-check list of codes and remedies, and the loop never retries an identical proposal. What the planner gets here instead is prose assembled from an exception:

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.

There is no reason code, no remedy, and nothing on the admission trace event's failed-check list — because admission did not fail. The gate said yes to a graph that cannot exist.

The prompt already tells models the right rule (proposal.py: "__start__ and __end__ are the graph's own entry and exit. Never use..."). The gate is what does not enforce it, and the gate is the part that is supposed to hold when the model does not.

Where in the code

• grapharc/planner/admission.py — _check_endpoints, the loop over ("source", ...), ("target", ...)
• grapharc/planner/proposal.py — _SENTINELS, and the prompt text that already states the rule
• grapharc/planner/loop.py — except MaterializationError, and the two separate max_consecutive_* counters

What to change

Reject END as a source and START as a target under Check.REGISTRY, with a reason code and a remedy in the same shape every other rejection uses. Both endpoints of an edge should still be reported rather than only the first, matching the existing posture.

Deliberately not in scope: whether a MaterializationError should count against the rejection allowance in general. That is a separate question about the loop, and closing this one removes the only known way to reach it from a well-formed proposal.

Acceptance criteria

• A proposal with END -> x or x -> START is refused by admission with a reason code and a remedy, and appears on the admission trace event's failed-check list
• Nothing is materialised and no factory is called
• The normal START -> ... -> END shape still admits
• uv run pytest green, uv run ruff check . clean