blueprint §10 still rejects connection cycles, contradicting §4.2, and names a code absent from the registry

[justinmerrell]

Summary

Blueprint §10 (Security considerations) still says a connection cycle is
rejected, contradicting §4.2, which says a cycle MAY exist and MUST NOT be
rejected. It names ERR_CONNECTION_CYCLE, a code that appears nowhere in §7's
diagnostics registry.

Per the README, "A disagreement between two normative artifacts is a defect
here that blocks a release, not a choice for an implementation" — so this looks
like text left behind by the acyclicity reversal rather than an intended rule.

The contradiction

specifications/blueprint/v1/spec.md §4.2 (line ~322):

The connection graph MAY contain a cycle. Two nodes MAY each consume an
output of the other, and an implementation MUST NOT reject a composition for
that reason alone.

specifications/blueprint/v1/spec.md §10, "Graph traversal" (line 750–755):

Graph traversal. §4.2 makes the component graph a directed
graph an implementation walks. A cycle is rejected with ERR_CONNECTION_CYCLE,
and an implementation MUST detect cycles rather than relying on a recursion
limit to stop it — a stack overflow is a crash, not a diagnostic.

The phantom code

Neither cycle code exists in the blueprint §7 registry:

$ awk '/^## <a id="diagnostics"/,/^## <a id="conformance"/' \
    specifications/blueprint/v1/spec.md | grep -c ERR_CONNECTION_CYCLE
0
$ awk '/^## <a id="diagnostics"/,/^## <a id="conformance"/' \
    specifications/blueprint/v1/spec.md | grep -c ERR_DEPENDENCY_CYCLE
0

ERR_CONNECTION_CYCLE occurs exactly once in the whole repository — line 751.

What the corpus says

The conformance corpus sides with §4.2, so §10 is the outlier:

• blueprint/v1/semantic/002-connection-cycle — "expected": "pass",
  "A cyclic connection graph validates: mutual service discovery is
  expressible."
• blueprint/v1/semantic/011-three-node-cycle — "expected": "pass",
  "A cycle longer than two nodes validates, and no traversal order is imposed
  on it."

Suggested fix

Delete the "A cycle is rejected with ERR_CONNECTION_CYCLE" clause. The rest of
the paragraph is still worth keeping and is independently true: an
implementation that walks the graph must terminate on a cyclic one by
detecting the cycle rather than relying on a recursion limit, and the parser's
COMP-YAML-011 nesting bound does not help because the cycle is in the graph the
document describes rather than in the document's own structure. That reads as a
requirement on the traversal, not as a rejection rule.

Happy to send the one-line PR if useful.

Context

Found while bringing musher-dev/platform onto the post-#42 pin. The platform
had implemented the acyclicity rule (its own ADR 0125) and is now removing it to
follow §4.2; §10 was the one place that still read as support for keeping it.