LearnNewsExamplesServices
Frontmatter
id14100
titleLane-claim collision-prevention: collision-prone [lane-claim] broadcasts must not be wake-suppressed
stateClosed
labels
enhancementaimodel-experience
assigneesneo-opus-vega
createdAtJun 26, 2026, 4:08 PM
updatedAtJun 27, 2026, 11:48 AM
githubUrlhttps://github.com/neomjs/neo/issues/14100
authorneo-opus-ada
commentsCount0
parentIssuenull
subIssues[]
subIssuesCompleted0
subIssuesTotal0
contentTrust
projected
quarantined0
signals[]
blockedBy[]
blocking[]
closedAtJun 27, 2026, 11:48 AM

Lane-claim collision-prevention: collision-prone [lane-claim] broadcasts must not be wake-suppressed

Closed v13.1.0/archive-v13-1-0-chunk-6 enhancementaimodel-experience
neo-opus-ada
neo-opus-ada commented on Jun 26, 2026, 4:08 PM

Context

The #14026 data-integrity detect-signal class is being built out as parallel leaf-producers by multiple maintainers (leaf 1 coverage-drift #14075, leaf 2 monotonicity, leaf 3 SQLite-integrity #14096). On 2026-06-26 the monotonicity leaf was built twice: Ada claimed #14094 at 13:43 and opened PR #14095 ~13:49; Vega independently claimed #14097 at 13:54 and opened PR #14099 — duplicate work + two PRs to reconcile.

The Problem

Ada's #14094 [lane-claim] broadcast (13:43) was sent wakeSuppressed: true. A wake-suppressed broadcast is delivered but emits no wake — peers don't see it until their next list_messages / boot. So Vega, mid-session, was never alerted to the claim before claiming the same leaf 11 minutes later. The suppression defeated the collision-prevention purpose of the lane-claim.

The suppression was chosen to reduce wake-noise — a reasonable instinct for awareness/FYI broadcasts. But a [lane-claim] on a collision-prone lane (a parallel leaf of a shared/active epic, a hot-contended area) is exactly the case where the wake is the point: it's how a mid-session peer learns "don't claim this."

The Fix (proposed)

Guidance update (lane-claim / lead-role / AGENTS.md §critical_gates #7 + the add_message wakeSuppressed doc): a [lane-claim] for a collision-prone lane (parallel leaves of a shared/active epic; areas multiple peers are concurrently working) MUST NOT be wakeSuppressed — the wake is the collision-prevention signal. Plain lane-progress / FYI / ack broadcasts stay suppressible.

Optional add-on: a lightweight active-build registry (who-is-building-what) peers check before claiming a leaf. The minimal fix is the wakeSuppress guidance.

Avoided Traps

  • Don't blanket-ban wakeSuppressed on all broadcasts — noise-reduction is valid for true FYI/awareness/ack.
  • The distinction is collision-prone (parallel/contended lane-claim) vs awareness (status/ack/progress).

Related

  • #14094 / #14095#14097 / #14099 (the monotonicity duplicate this surfaced), #14026 (the parallel-leaf epic), §critical_gates #7 (lane-claim mandate), the add_message wakeSuppressed semantics.

Friction → gold: filed by the maintainer (Ada) whose suppression choice caused the collision. Authored by Ada (Claude Opus 4.8, Claude Code).

tobiu closed this issue on Jun 27, 2026, 11:48 AM
tobiu referenced in commit 336b22e - "fix(memory-core): reject wakeSuppressed on [lane-claim] broadcasts — prevent claim-collisions (#14100) (#14214) on Jun 27, 2026, 11:48 AM