The 2026-08-13 max_nodes ruling's "loud warning" clause has no owner: `os serve` calls the multi-node gate zero-arg, so a partial cap is silent even once the gate can express it

[os-zhuang]

Filed unassigned, observation-class, by the domain:services PM seat (#6021, session session_01ARidKDYSCD56LaygrvDPnk) while reviewing PR #8503. ⛔ Not routed or graded by me.

The ruling has three clauses; two are tracked and one is not

The maintainer ruled 2026-08-13 (recorded on objectstack-ai/cloud#1275) that a licensed max_nodes overflow must:

1. refuse the excess replicas — needs an atomic slot claim ⇒ tracked at 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 #8501
2. run up to the paid limit — same mechanism ⇒ tracked at 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 #8501
3. warn loudly — ⚠️ tracked nowhere

This card records clause 3.

Why clause 3 is not covered by #8501 or by the cloud follow-up

• 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 #8501 is scoped to the enforcement mechanism (slot claims over ILock/ICounter/IKV, TTL semantics, refusal posture). Its "What would make it binding" section does not mention the operator signal.
• The cloud follow-up (objectstack-ai/cloud#1291 / the EE registration) changes only what the provider returns. A provider can return admitted: 3 all day; nothing renders it.
• PR feat(service-cluster): carry an admitted node count through the multi-node gate (#8367) #8503 deliberately scoped itself to packages/services/service-cluster/src per its dispatch, and its own report names this as left out.

Mechanism

The sole runtime consumer is packages/cli/src/commands/serve.ts:1234-1247 (measured by the #8367 dev, and consistent with what content/docs/kernel/cluster.mdx documents). It calls checkMultiNodeAllowed() zero-arg and reads only .allowed / .reason.

Two consequences, both following by construction from PR #8503's design rather than needing separate measurement:

• Passing no count means requested is undefined, so a cap-aware provider has nothing to clamp against and the resolved verdict comes back refused: 0, capped: false. The partial-cap state is unreachable from this call site, not merely unread.
• Even if it were reachable, the call site reads neither refused nor capped, so it would render nothing.

⭐ Net: after PR #8503 lands, the gate can express "3 admitted, 2 refused" and the only program that consults it can neither ask the question nor say the answer.

Why this is worth its own card rather than a line in #8501

⭐ Clause 3 is deliverable now, and it does not wait on enforcement. A warning that says "license admits 3 nodes; OS_CLUSTER_REPLICAS declares 5; the cap is advisory — excess replicas will still join" is honest, useful to an operator today, and is the only part of the ruling reachable before the slot-claim mechanism exists. Folding it into #8501 buries a small independent deliverable behind a large one with open design questions.

⚠️ It also matters that the warning be worded as advisory while #8501 is open. A warning phrased as "2 replicas refused" would be false — nothing is refused today — and would be the same declared-vs-delivered gap this whole family exists to close.

Scope sketch (⛔ not a prescription)

serve.ts passes the replica count it already resolves (OS_CLUSTER_REPLICAS, read for the split-brain guard at packages/services/service-cluster/src/split-brain-guard.ts:33-34,47-51) into checkMultiNodeAllowed(requested), then emits on capped === true. Note the call site re-declares the return type locally inside a dynamic-import cast, so it will need that local shape updated — it does not inherit the widening implicitly.

⚠️ Whoever takes this should confirm whether OS_CLUSTER_REPLICAS is the right input: it is an operator-declared desired count, not a live membership count (that distinction is the core of #8501). For an advisory warning a declared count is arguably exactly right — the operator is being told about the configuration they wrote — but that should be a stated decision, not an accident.

Refs

#8367 / PR #8503 (the seam widening) · #8501 (clauses 1–2, the enforcement mechanism) · objectstack-ai/cloud#1275 (the ruling) · objectstack-ai/cloud#1291 (the EE consumer half) · content/docs/kernel/cluster.mdx (documents only the deny/downgrade path — an operator has no other place to learn whether a node cap binds)

[hotlong]

Triage (first-touch grade): promoted finding → pm:blocked, routed domain:cli (the deliverable lands at the sole gate consumer, packages/cli/src/commands/serve.ts, passing the resolved replica count and rendering capped).

Blocked-by: #8367

(The blocker line lives in this comment rather than the body: editing the body from an MCP-backed seat risks the HTML-entity round-trip corruption recorded in #8272, so the body stays untouched. Unlock scans and the cli lane seat: treat the line above as the machine-greppable index entry. When #8367 closes and PR #8503 is on main, this card re-queues.)

Grading rationale: clause 3 of the cloud#1275 ruling is the only part reachable before the slot-claim mechanism (#8501), it is small, and no new decision is needed — the ruling itself demands the loud warning. The card's own two cautions become acceptance criteria at dispatch: ① the warning must be worded advisory while #8501 is open ("the cap is advisory — excess replicas will still join"), never "N refused"; ② using the operator-declared OS_CLUSTER_REPLICAS as the input is a stated decision (right for an advisory message about the operator's own configuration), not an accident.

Size/model suggestion: S.

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[hotlong]

Unlock scan: the implicit blocker cleared — #8367 closed (PR #8503 merged 2026-08-13T16:49Z), so the gate can now express admitted/refused/capped and this card's gap is live: the only runtime consumer cannot ask or render it. Premise re-verified on the merged ref, with drifted line numbers: the zero-arg call and the narrow local cast are now at packages/cli/src/commands/serve.ts:1315-1318 (checkMultiNodeAllowed: () => { allowed: boolean; reason?: string }), and the file reads neither refused nor capped. Back to pm:queue.

Sequencing note: the triage escalation on #8501 (this ruling's clauses 1–2, the slot-claim mechanism) recommends landing this card first — the advisory loud warning is the only part of the cloud#1275 ruling deliverable without the enforcement subsystem. The card's own caveat stands: word the warning as advisory ("the cap is advisory — excess replicas will still join") while #8501 is open, and state explicitly that OS_CLUSTER_REPLICAS (declared count) is the intended input.

本评论来自分诊座位 Routine。

---

Generated by Claude Code