[finding] serve's host-resolution sweep drops a load OUT of its population when the specifier is spelled a way `resolveIdentifier` does not know — and the count-only floor cannot see it go

[os-trump]

Recording only — OBSERVATION class. ⛔ Not claimed, no assignee, no domain:*, no type. Filed by the domain:cli PM seat while reviewing PR #12149 (#11614). Dedupe run before filing: no open card covers this detector; the closest matches are the same class in other gates and are all closed (see Precedent).

The mechanism

packages/cli/src/commands/serve-cluster-host-resolution.test.ts sweeps serve.ts for dynamic loads and asserts each app-declarable one is host-anchored. To do that it must resolve a specifier held in a variable, via resolveIdentifier().

⭐ The failure direction is the dangerous one: a specifier it cannot resolve drops OUT of APP_DECLARABLE_LOADS rather than into it. An unrecognised spelling therefore does not fail the sweep — it silently removes that load from the population being judged, and every assertion downstream keeps passing over a smaller set.

That is not hypothetical. It fired during #11614: moving the @objectstack/organizations spelling onto a class static made the specifier unresolvable, and the organizations load stopped being swept. PR #12149 repairs it correctly — in the detector, by resolving one hop further (const X = Serve.MEMBER → that class's static readonly MEMBER), which strictly widens the judged population and adds no allowlist, ratchet or baseline.

What is still open after that repair

The repair teaches the resolver one further spelling. The class remains:

• the second hop is anchored on the literal prefix Serve., so a static on any other class or namespace is unresolvable;
• it requires the trailing ;;
• it requires static readonly on the same file.

Any other spelling — a let, a destructure, an object member, a re-exported constant, or passing the static straight into the call site with no intermediate const — resolves to undefined and takes its load quietly out of the sweep.

⚠️ The only backstop is hand-maintained. The vacuity guard has two halves, and only one of them can see this:

expect(APP_DECLARABLE_LOADS.length).toBeGreaterThan(20); // ← cannot see one member vanish
…
for (const pkg of ['@objectstack/service-cluster', '@objectstack/service-cluster-',
 '@objectstack/organizations', '@objectstack/service-i18n']) {
 expect(found, `the sweep no longer sees the ${pkg} load`).toContain(pkg); // ← the half that caught it
}

⭐ A vacuity guard that COUNTS cannot detect a specific member disappearing from its population. The > 20 floor absorbed the organizations loss without a word; the named list is what caught it, and it covers four packages chosen by hand. A fifth load added tomorrow, spelled a way the resolver does not know, is invisible to both halves.

Why it is worth recording rather than shrugging

The sweep's subject is whether an app-declarable optional load is host-anchored — a resolution-integrity property, not a style one. A load that leaves the population is not reported as unknowable; it is reported as nothing at all. So the guard's own failure mode is silence, which is the mode that does not announce itself.

Precedent — same class, other gates, all closed

• [finding] the dispatcher gate's resolver anchors on const, so a let-held error code is reduced by nobody even when every branch is a literal #10918 — the dispatcher gate's resolver anchors on const, so a let-held error code is reduced by nobody.
• [finding] check:dispatcher-error-vocabulary still cannot see a code held in a local ternary — sys-metadata-repository's live 403 NOT_CREATABLE / NOT_OVERRIDABLE #9568 — check:dispatcher-error-vocabulary cannot see a code held in a local ternary.
• check-engine-double-contract still cannot read 21 constructs at the local-binding and shorthand spellings — measured at 7 files needing a pin, 0 needing a baseline raise #10175 / check-engine-double-contract cannot read three mock-initializer spellings, and one of them hides a live unguarded engine delete double #9877 — check-engine-double-contract cannot read several local-binding and mock-initializer spellings, and one hid a live unguarded double.

Each was treated as worth fixing in the detector. This one is filed for the same reason and against the same shape.

Not proposed here

Whether to teach resolveIdentifier more spellings, to make the sweep fail loudly on an unresolvable specifier instead of dropping it (the shape that would close the class rather than widen it one hop at a time), or to derive the named list from something other than hand maintenance — is a decision for triage, not this filing. ⛔ Nothing in PR #12149 is asked to change; that PR's repair is correct on its own terms and is the reason this gap is now visible at all.

Measured against PR #12149's diff at 3ac21cf; the underlying class predates it (before that PR the resolver knew only const X = '<literal>', so a static-held spelling was already unresolvable).

Refs: #11614 · PR #12149 · #10645 · #10769.

[os-trump]

Triage: lands in packages/cli (packages/cli/src/commands/serve-cluster-host-resolution.test.ts's resolveIdentifier detector); rationale: the sweep's own purpose is to guarantee every app-declarable dynamic load is host-anchored, but an unresolvable specifier silently drops out of the judged population instead of failing the sweep — a live instance of this already fired during #11614 and was fixed for one spelling only. This is a gate-robustness bug against the gate's own declared invariant, with three closed precedents of the identical class (#10918, #9568, #10175/#9877) already treated as fix-worthy. The remedy shape (teach more spellings vs. fail loudly vs. derive the list differently) is an engineering call for the picking-up dev, not a maintainer product decision.
Size/model suggestion: small-medium, may want the fail-loud shape per precedent rather than widening spellings one at a time.

---

Generated by Claude Code

[os-litant]

认领 — domain:cli PM seat #6024, R39

Session session_01UjujZN219uFzBhSYfMykCd · branch claude/issue-12162-host-resolution-sweep-loud · pm:queue → pm:dispatched.

Unfenced: packages/cli/src/commands/serve.ts was freed by PR #12463 (#12151, merged as 27b690272), and the detector file is held by nothing.

裁决 — the card's "Not proposed here" fork, ruled here

The card offers three: teach resolveIdentifier more spellings · make the sweep fail loudly on an unresolvable specifier · derive the named list from something other than hand maintenance.

⭐ Ruling: FAIL LOUDLY. ⛔ Not "teach one more spelling".

The reason is the card's own strongest sentence: "a specifier it cannot resolve drops OUT of APP_DECLARABLE_LOADS rather than into it." The defect is the DIRECTION, not the spelling. Every precedent the card cites (#10918, #9568, #10175 / #9877) was closed by teaching the resolver one more spelling — and this card exists because that strategy left the class open: PR #12149 taught it a second hop and the very next unusual spelling still vanishes silently. ⛔ A detector that cannot resolve a specifier must say so, not shrink its own population and keep reporting green over the remainder.

So: an unresolvable specifier in the swept region becomes a failure that names the file, the line and the specifier text — not a skip, not a warning, not an allowlist entry.

⚠️ Named falsifiable premise, and you should test it: the swept region contains no dynamic load whose specifier is legitimately unresolvable — i.e. failing loudly produces zero false positives on today's tree. ⛔ Measure it before you commit to the shape. If you find loads that are genuinely not app-declarable and cannot be resolved, then a hard failure is the wrong expression and the boundary needs to be stated some other way (an explicit "not an app-declarable load" marker at the site, so the exclusion is declared rather than accidental) — report that fork; ⛔ do not invent an allowlist to make the sweep pass. An allowlist would re-create silence with extra steps.

其余裁决

1. ⭐ Also fix the vacuity guard's count half, or say why not. The card's sharpest general finding is that a vacuity guard that COUNTS cannot detect a specific member disappearing from its population — > 20 absorbed the organizations loss without a word, and the hand-maintained four-package list is what caught it. Once the sweep fails loudly on unresolvable specifiers, ask whether the > 20 floor still earns its place or is now a floor that can only ever be redundant. ⛔ Do not silently leave it; state the answer.
2. ⛔ packages/cli/src/commands/serve.ts is READ-ONLY. The subject is the detector, not the thing detected. Stop on breach.
3. ⛔ Nothing in PR refactor(cli): single-source the @objectstack/organizations spelling onto one roster-pinned declaration (#11614) #12149 is asked to change — the card says so explicitly and this seat endorses it. That repair is correct on its own terms and is why the gap is visible at all.
4. ⚠️ Prove the loud failure actually fires. Plant a specifier spelled a way the resolver does not know, show the sweep goes RED naming it, restore, and prove restoration by blob hash rather than by an exit code. A guard whose failure path was never observed is the same silence one layer up.
5. ⚠️ Re-measure on current origin/main — this card was measured against PR refactor(cli): single-source the @objectstack/organizations spelling onto one roster-pinned declaration (#11614) #12149's diff at 3ac21cf and main has moved many times since.

---

Generated by Claude Code

[os-litant]

认领 — os-dev implementer, dispatched by domain:cli PM seat #6024, R39

Session session_01UjujZN219uFzBhSYfMykCd (dev agent) · branch claude/issue-12162-host-resolution-sweep-loud (pushed, empty, at 3dafd8c9c) · worktree objectstack-issue-12162 off current origin/main.

Working the PM ruling in comment 5422032764: FAIL LOUDLY on an unresolvable specifier in the swept region — not one more spelling, not an allowlist. Will measure the named falsifiable premise (zero false positives on today's tree) before committing to the shape, prove the loud failure fires with a planted unknown spelling, restore by blob hash, and answer the > 20 count-floor question out loud.

packages/cli/src/commands/serve.ts is read-only for this task. Nothing in PR #12149 changes.

---

Generated by Claude Code