fix(seller): state accepting=n while no harness is serving

[orveth]

What this fixes

The agents list on the heartbeat is already wired to the live roster — #300 did that. publish_heartbeat passes LiveRoster::advertised(), which filters on live serving state and excludes both Dropped and Incapable. A dropped harness already stops advertising.

The flag beside it was not. accepting came from the in-flight slot alone:

HeartbeatDraft::v1(!job_in_flight, u32::from(job_in_flight), rate_sats)

So a seat that had dropped every harness published accepting=y, queue_depth=0, and no mobee_agent tag — byte-identical to a healthy seller that simply never named a harness (a_seller_stating_no_harness_emits_a_byte_identical_heartbeat pins that identity deliberately). Both signals a buyer can filter on read open and unconstrained.

Reachable in one step: on a non-acp build the first offer marks each harness Incapable(AcpFeature), so a one-harness seat is fully dark after a single job.

The design call on emptiness

Routed through accepting, not through the agents tag. An absent tag already means UNSTATED — that absence is load-bearing and agent_tag omits rather than emits empty on purpose. There is no spare state there to mean "none" without a protocol change every reader has to learn. accepting has no unstated value, so the truth fits a field that already exists.

Rejected: stop heartbeating when dark. The #150 relay-stall watchdog uses the own-heartbeat round-trip as its liveness probe (filter is kind+author+d, run.rs:572-574). A dark seat would look relay-stalled and churn reconnects, and would vanish from discovery exactly when an operator needs to see it is up-but-dark. Worse on every axis.

Why serving is not !names.is_empty()

The roster advertises names; the unlabelled --agent-argv hatch has none. AgentRegistry::advertised already documents it: "an empty list means 'this seller states no harness', never 'it has none'." So a seat serving only the hatch advertises nothing while being perfectly able to work, and reading darkness off that list would take it off the market for lacking a label. The signal comes from the roster's own dispatch predicate.

LiveRoster::advertisement returns both halves under one lock, because both are published in the same event. Read separately, a fault landing in between could emit accepting=y beside an empty advertisement — the exact incoherence a live roster exists to make unrepresentable.

Blast radius — measured, and deliberately narrow

Nothing in this tree reads accepting (every other hit of the word is English prose). This is honesty on the wire for external readers — the market site, buyer filters. It does not change our own dispatch, which already declines correctly via serves(). I am not claiming otherwise.

Side effect worth having: accepting=n, queue_depth=0 is now the distinct signature of up-but-dark versus n, 1 = busy — two states the pair could not express before.

Red legs

① Revert the conjunction to !job_in_flight ⇒ accepting_requires_a_free_slot_and_something_serving fails on the idle+dark row, left: ("y", "0") / right: ("n", "0"). One test red, 198 green.

② Derive serving from !ad.names.is_empty() ⇒ the_advertisement_separates_having_no_name_from_having_nothing_to_serve fails ("yet the seat is serving, and must advertise as accepting"). One test red, 198 green. ⚠ Note which test did not redden: a_fully_dropped_named_roster_reports_dark_alongside_an_empty_advertisement stayed green, because for a named roster the simplification gives the right answer. The hatch case is the only positive control for that mistake — that is why it exists as its own test.

Counts — both sides, same tree, same command

• cargo test -p mobee-core --locked (CI job 1): 196 → 199 = +3, 0 failed
• cargo test -p mobee-core --features wallet --locked: 661 → 664 = +3, 0 failed, 3 ignored

Same +3 in both aggregations. ⚠ seller_node is #[cfg(feature = "wallet")] and default = [], so the default job never compiles the call site — the wallet run is what proves run.rs builds. The three new tests are in ungated modules (heartbeat, seller_roster), so they are in both denominators. Keyed on the mobee_core unittests line by name, never the trailing ok. 0 passed integration bins.

Not in scope, flagged for slots=2

job_in_flight is health().jobs > 0, so with slots=2 the heartbeat flips to accepting=n on the first job while the node happily claims a second — an existing wire lie that understates capacity. It wants its own reasoning in the slots=2 PR, not smuggled in here.

Refs #254

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
mobee	Ready	Preview	Jul 30, 2026 1:59pm