The `default-project` slot has 3 production readers, 0 production registrants — and 6 comments name a registrant function that exists in neither repo

[os-zhuang]

Found while sweeping the REST composition root for #4251 (B4, PR #5953). Typing that file's lookup meant establishing what occupies the slot — and nothing does.

Evidence

Three production readers, all resolving the literal 'default-project':

packages/rest/src/rest-api-plugin.ts        defaultEnvironmentIdProvider() → dp?.environmentId
packages/runtime/src/http-dispatcher.ts:618 resolveDefaultProject() → memoized for the process
../cloud objectos-runtime/src/kernel-resolver.ts:193  resolution level 6

Zero production registrants. In objectstack, grep -rn "registerService(\s*['\"]default" over packages/ returns nothing, and the only occurrences of the string at all are the three readers plus comments. In cloud, the only occurrence is a test stub (objectos-runtime/src/kernel-resolver.test.ts:143, getService: (n) => n === 'default-project' ? { environmentId: 'proj_local' } : undefined).

Six comments name the registrant, and it does not exist. createSingleEnvironmentPlugin is referenced as the thing that registers this slot in:

packages/rest/src/rest-server.ts:1796
packages/rest/src/rest-server.ts:1877
packages/rest/src/rest-api-plugin.ts:146
packages/runtime/src/http-dispatcher.ts:252
packages/runtime/src/http-dispatcher.ts:614   ([#5155])
packages/runtime/src/domain-handler-registry.ts:213

grep -rn "createSingleEnvironmentPlugin" over both repos returns only those comments — no declaration, no export, no call. Same for the cloud checkout.

Why this is observation-class and not a live outage

Every reader has a working fallback and degrades by design:

• rest-api-plugin's provider is wrapped in try/catch returning undefined; RestServer then falls through its hostname/header chain.
• http-dispatcher.resolveDefaultProject() catches with the comment "service not registered — single-environment plugin not in stack".
• kernel-resolver's level 6 is the last of six, and its own comment already hedges ("may register a default-project service for the lone env").

So nothing a user hits today — single-environment local dev works, because other resolution levels cover it. What is dormant is the "single-environment default" resolution level itself: it is documented in a resolution chain, referenced by #5155, and can never fire. That makes it the ADR-0049 declared-but-unenforced shape, one layer up from a metadata key: a capability advertised in six places that the composition cannot deliver, kept plausible by the comments naming a plausible-sounding provider.

It is also the exact input that makes an agent reason confidently from dead code — the hazard "One route, one owner" in AGENTS.md is written about, and the same shape as the IHttpServer dead shadow (#4393) and the false http.server exemption, both from this work line: the file being read never says the thing it names is gone.

Two ways to close it, opposite directions

1. The plugin should exist — createSingleEnvironmentPlugin was planned or removed, and single-environment hosts genuinely want bare /api/v1/data/... to route into the lone environment's kernel without a hostname. Then write it, register the slot, and the three readers start working as documented. Worth checking HttpDispatcher 把「本请求解析出的 kernel」存在实例字段上(this.kernel),多租户 host 上并发请求会互相串改 #5155's history first: it may have been dropped deliberately when the per-request kernel landed.
2. The slot should go — the other five resolution levels are sufficient and this level is speculative surface. Then delete the three reads and the six comments, per enforce-or-remove. Note the readers are cheap but not free: http-dispatcher memoizes the answer for the process lifetime.

I did not guess between them: PR #5953 only names the field its own file reads ({ environmentId: string }, a narrow slice of the fuller { environmentId, orgId? } that runtime declares) and changes no behaviour. Filed unassigned.

[claude]

发现分诊轮:持有(留 finding),补域 domain:cli。

• 过时前提检查:三个读者(packages/rest/src/rest-api-plugin.ts、packages/runtime/src/http-dispatcher.ts:618、cloud objectos-runtime/src/kernel-resolver.ts:193)在两仓 origin/main 上现状成立;注册方侧仅有 cloud 的测试替身(kernel-resolver.test.ts:143)。前提成立(静态证据齐,见下面的保留)。
• 为什么持有而不晋级:处置有两条相反出路 —— ①这个 slot 本就该有生产注册方(那是缺实现),②它是死槽位(那是删读者 + 订正六处注释)。选哪条取决于托管运行时是否在运行期注册,而本单证据全部来自静态 grep;registerService 的注册也可能发生在 cloud 之外的宿主装配处。在这一条测量补上之前,任何一条出路都可能是错的删除。
• 重启条件:补一次运行期测量(启一个真实 cloud 环境,在解析点打点看 slot 是否被占),或维护者直接给出该 slot 的设计意图 —— 届时晋级:占用 ⇒ 补契约与注册方文档;不占用 ⇒ 按 ADR-0049 enforce-or-remove 走退役,落点即三个读者。
• 域:domain:cli(主落点 packages/rest + packages/runtime);cloud 侧那一处随裁决走跨座位转移,⛔ 不在本单打 repo:cloud —— 一件事只留一个派发入口。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code