ADR-0010 View demand cap and cross-scope arbitration

#Context

The per-Scope cap has been enforced since Phase 0 and it is not enough. The spike's own gameability probe P3 splits two level-4 demands into sibling Scopes; both Scopes pass individually, and only a View-level check catches the pair — the finding is recorded as "ADR-010 is load-bearing". Ten Scopes each locally correct still produce a screen of ten demands, which is precisely the screen ADR-0001 says the system exists to prevent.

Two things were undecided. The number — how many concurrent demands a View admits — and what happens to the second one. The engine has been running on a provisional VIEW_DEMAND_CAP = 1 in packages/budget/src/config.js, marked pending, with no ratified home and no stated arbitration rule; the playbook's own §10 row points at this ADR for it. Phase 3 cannot close a composition-contract phase on a cap that is a spike constant, and the pairing matrix cannot generate a View-level row from a number nothing has ratified.

#Decision

A View owns a demand cap, default 1, declared as a token like the Scope emission ceilings. It lives in the serialization constants, not in the engine that happens to read it, and it is one number the whole system agrees on rather than a per-consumer default.

Arbitration, for live interfaces: demands are granted in arrival order. A Scope requesting Demanded while the View is at cap is held at Directed and promoted when a slot frees. A demand is deferred, never silently dropped, and never fought over — the order is decided by when the request arrived, not by who is asking.

Static analysis and fixtures: a scene declaring more concurrent Demanded elements than the View cap is a build failure, naming every offending Scope, the View, and the rule. There is no runtime arbitration in a static scene to defer anything, so the scene is wrong at the point it was written.

Zero demands remains valid. The cap is a ceiling, not a quota: a View carrying no demand at all passes, and nothing in this decision gives a screen a reason to manufacture one.

#Rejected options

A cap of 2, or a configurable-high default. Merit: fewer held demands on dense supervision screens, where two genuinely urgent things can arrive close together and deferral is felt as latency. Lost because two simultaneous demands is the exact condition the thesis calls a failure of the interface to answer *what needs me now* — a default that permits it makes the central claim optional, and a claim that is optional at the default is not a claim.

Per-scope enforcement only, no view tier. Merit: simpler, and already built and green in CI. Lost because ten Scopes each locally correct still produce a screen of ten demands. Only a View owner can make the global guarantee, which is ADR-0001's own argument moved one tier up — the same reason a Scope owns a budget rather than each Emitter policing itself.

Failing both demands at runtime. Merit: symmetrical, and it needs no ordering logic at all. Lost because it punishes the person at the worst possible moment: the interface goes silent exactly when two things need them. Deferral degrades to a correct screen; mutual failure degrades to a broken one.

Priority classes deciding who wins. Merit: expressive, and it lets a team say that one demand genuinely outranks another. Lost because it reintroduces the bidding war the budget exists to end, and because every team inflates its own class within a release cycle — the mechanism is stable in a design document and unstable in a product.

#Consequences

The cap moves from packages/budget/src/config.js into the core serialization constants beside DEMAND_LEVEL, and the engine imports it. The provisional site is removed rather than shadowed: one definition, one number, and a workspace grep that finds exactly one.

Salience — view in the §10 enforcement table now has a defined rule behind it rather than a pending pointer, and the engine's failure text stops saying "pending". The pairing matrix gains a view-salience dimension keyed on the ratified cap — two sibling Scopes each carrying a Demanded element are forbidden while the cap is 1, and the verdict is computed from the constant, so a future ADR that raises the cap moves the cell rather than requiring the table be rewritten.

What this makes harder: the arrival-order arbitration is stated here and implemented nowhere, because there is no runtime yet. It is a Phase 4 obligation on the first component that can escalate, and stating it now is what stops that component inventing its own rule. The static half is enforceable today and is what CI gates on.

ADR-0005 is untouched: the level-3 plurality question is still open, and a View cap on level 4 does not answer it.