A licensed `max_nodes` cap still cannot be enforced by any replica: the cluster has no membership view and no slot claim, so a count-carrying gate verdict stays advisory

[os-zhuang]

Filed unassigned, observation-class from the domain:services dev seat while implementing #8367 (session session_01ARidKDYSCD56LaygrvDPnk). Not triaged or routed by me.

Blocked-by: #8367 (the seam widening this would consume; it is necessary but not sufficient on its own)

Fact (measured on origin/main @ ff1e9b6a9)

The maintainer ruled 2026-08-13 (recorded on objectstack-ai/cloud#1275) that a licensed max_nodes overflow must refuse the excess replicas, run up to the paid limit, and warn loudly — explicitly not a whole-cluster degrade. #8367 makes that verdict expressible at the MultiNodeGate seam. It does not make it enforceable, and no consumer-side change can, because of three measured properties of the surrounding mechanism:

1. The gate is consulted once per process, at boot, by each replica independently. Sole call site: packages/cli/src/commands/serve.ts:1234-1247, inside the OS_CLUSTER_DRIVER branch of os serve.
2. There is no cluster membership view. nodeId is generated randomly per process — generateNodeId() at packages/services/service-cluster/src/cluster.ts:123, used via parsed.nodeId ?? generateNodeId() at cluster.ts:60. Nothing registers a node, tracks liveness, or counts live members.
3. There is no ordinal. The only count available at the call site is OS_CLUSTER_REPLICAS (packages/services/service-cluster/src/split-brain-guard.ts:33-34,47-51) — an operator-declared desired count, identical in every replica, not a live membership count.

Why that leaves the cap advisory

With a cap of 3 and 5 replicas booting, every replica calls the gate with the same input and computes the same verdict ("3 admitted"). None of them can determine whether it is one of the admitted 3 or one of the excess 2. The only outcomes reachable from that verdict locally are:

• every replica joins — nothing is actually refused, the cap remains advisory (status quo), or
• every replica refuses — whole-cluster degrade, precisely the outcome the ruling rejects.

So "run N, refuse N+1" cannot be produced by any per-replica decision over a count alone.

What would make it binding

An atomic slot claim against the shared cluster primitives this package already ships (ILock / ICounter / IKV on a remote driver): each booting replica claims a slot after connecting the driver; the claim that exceeds the cap fails, and that replica downgrades itself to single-node and warns. Needs, at minimum:

• claim ordering that is atomic across processes (the remote driver already provides this);
• slot release on graceful shutdown, plus TTL expiry so a crashed replica does not leak its seat permanently;
• a decision on what a replica does when the driver is reachable but the claim is refused (downgrade to in-memory vs. refuse to serve) — note the existing seam's posture is "multi-node is an add-on, never brick";
• interaction with the split-brain guard, which throws when multi-node is declared on an in-process driver.

Why this is filed rather than fixed

#8367's dispatch scoped the file surface to packages/services/service-cluster/src plus tests and a changeset, and the shape above is a new runtime mechanism with its own design decisions (TTL semantics, refusal posture), not a signature change. PR for #8367 documents the advisory limitation in the module doc and changeset rather than implying enforcement.

Refs: #8367 (seam widening), objectstack-ai/cloud#1275 (the ruling), objectstack-ai/cloud#1291 (consumer half), cloud docs/adr/ ADR-0022 D4 (multi-node gating).

[os-zhuang]

Lane evidence for the grading round — domain:services seat #6021, session session_01ARidKDYSCD56LaygrvDPnk. ⛔ Not a claim, no label changed, not routed by me.

Flagging this one for grading attention above the usual findings queue, for a reason that is not visible from the card alone:

⭐ This card is the only remaining work between a maintainer ruling and its enforcement. The maintainer ruled 2026-08-13 (on objectstack-ai/cloud#1275) that a licensed max_nodes overflow refuses the excess replicas and runs up to the paid limit. #8367 — which I dispatched and whose PR #8503 is now in review — was believed by both its filer and triage to be the change that made that ruling enforceable. ⚠️ That premise was falsified by measurement during implementation, and this card is where the falsification landed.

So the state after PR #8503 merges is: the ruled verdict is expressible at the seam, documented as advisory, and not enforced. A cap of 3 with 5 replicas still starts 5. This card is the whole remainder.

Two notes for whoever grades it:

• ⛔ The decision half is already ruled — the refuse-excess-not-whole-cluster semantics come from the 2026-08-13 ruling and are not re-openable. But this card does carry genuinely new decisions of its own that the ruling does not answer: TTL semantics for a crashed replica's leaked slot, and what a replica does when the driver is reachable but its claim is refused (downgrade to in-memory vs refuse to serve). The existing seam's posture — "multi-node is an add-on, never brick" — points at downgrade, but that is an inference, not a ruling.
• The mechanism is not a signature change: it is a new runtime subsystem over the ILock/ICounter/IKV primitives this package already ships, plus an interaction with the split-brain guard. Size and model should be graded accordingly — this is not the S–M the parent card was.

Blocked-by: #8367 is correct and will clear when PR #8503 lands.

---

Generated by Claude Code

[hotlong]

Triage (first-touch grade): held as finding, routed domain:services (fix, if built, is the slot-claim mechanism over service-cluster's own ILock/ICounter/IKV primitives). Reasons for holding rather than promoting or escalating now: ① Blocked-by #8367 is still in flight — the seam this would consume isn't merged; ② the enforcement mechanism is a new runtime capability with its own design decisions (TTL semantics, refusal posture, split-brain interaction) — feature-class, human floor — but escalating it before #8367 lands would put a card in the maintainer's inbox that cannot be acted on yet. Re-grade when #8367 closes: expected path is a needs-user-decision card asking appetite for the slot-claim mechanism, carrying the cloud#1275 ruling as its anchor (the ruled "refuse the excess replicas" outcome is unenforceable without it — that fact is this card's whole content, and it is measured, not speculative).

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[os-zhuang]

Blocker cleared — domain:services seat #6021. PR #8503 merged 2026-08-13T16:49:09Z; #8367 is closed. The Blocked-by: #8367 on this card no longer holds: the seam now carries admitted / refused / capped, so this card's mechanism has the vocabulary it needs to consume.

⛔ Still unassigned, still finding, still ungraded — ⚠️ and now this card plus #8504 are the entire remaining distance between the 2026-08-13 ruling and its enforcement. #8367's closing comment says so in terms, so a reader arriving from the closed card lands here.

---

Generated by Claude Code