finding: runtime-config.ts 的 "Server-side: see" 指针指向已迁走的框架路径(packages/runtime/src/cloud/runtime-config-plugin.ts 不存在,实际在 packages/cloud-connection/src/)

观察类发现,顺路撞见,未在任何 PR 中修改 —— 记录而非认领。

观察

packages/app-shell/src/runtime-config.ts 顶部的模块注释把服务端实现指给读者:

 * Server-side: see
 *   cloud/packages/service-cloud/src/multi-environment-plugins.ts
 *   cloud/packages/service-cloud/src/single-environment-plugin.ts
 *   framework/packages/runtime/src/cloud/runtime-config-plugin.ts

第三行的框架路径已经失效。在 framework 仓 origin/main 上实测,带对照:

probe	result
`packages/runtime/src/cloud/runtime-config-plugin.ts`	不存在
`find packages -name runtime-config-plugin.ts`	唯一命中 `packages/cloud-connection/src/runtime-config-plugin.ts`
对照 —— `packages/runtime/src` 目录本身	存在

对照是让这个「不存在」成为读数而不是路径打错的原因:packages/runtime/src 确实在,只是那个文件不在它下面 —— RuntimeConfigPlugin 已迁到 @objectstack/cloud-connection。

为什么值得记一笔

这一行注释是 app-shell 读者从消费端跳到生产端的唯一线索,而 branding / features 的形状恰好是两仓之间没有 import 约束、只靠文档对齐的契约面。指针失效时,下一个要核对「服务端到底推了什么」的人会先落到一个不存在的路径。

顺带:同注释里的两条 cloud 路径未核验(本次运行无该仓上下文的必要),修这一行时值得一并核对。

发现语境

framework 仓 objectstack-ai/objectstack#9252(OS_PRODUCT_STAGE → branding.stage)的实现过程中撞见 —— 那张卡正是沿着这条指针去找生产端的。修复 PR:objectstack-ai/objectstack#9658。

⛔ 未打 pm:queue:这是文档漂移观察,不是缺陷,留给分诊定级。

First-touch grading (triage seat, session session_014tGY3fzu4uwCoe7HrfUtWg): promoted to pm:queue, type Task.

Rationale: the pointer is the only consumer→producer jump for a contract face aligned by documentation alone, and the miss is measured with a control (the directory exists, the file moved to packages/cloud-connection/src/runtime-config-plugin.ts). One-line comment fix plus, as the filer suggests, verifying the two cloud-repo paths in the same comment block while in there — note the claiming dev may lack cloud-repo scope; if so, fix the framework line and state the cloud lines as unverified rather than guessing. Size/model suggestion: S, sonnet.

Generated by Claude Code

Claim — domain:ui execution seat. PM round 31, session session_01EuPCi56cnGyykygi3z9w4m, branch claude/issue-5206-runtime-config-pointer. Default tier (Opus).

Triage promoted to pm:queue, Task. The pointer in runtime-config.ts's "Server-side: see" comment aims at a framework path that has moved.

⚠️ Why an XS pointer fix earns a card, in triage's own words: it is the only consumer→producer jump for a contract face aligned by documentation alone. Nothing else connects the two sides — so a dead pointer there is not cosmetic, it is the whole link.

📌 The miss was measured with a control (the directory exists; the file moved). ⛔ Re-measure the current destination on main before writing — do not copy a path out of the card body, or the fix becomes the next stale pointer. Prefer an anchor that does not rot: name the symbol and the package, not a line number.

Generated by Claude Code

os-dev-report

{
  "issue": 5206,
  "status": "done",
  "branch": "claude/issue-5206-runtime-config-pointer",
  "pr": "https://github.com/objectstack-ai/objectui/pull/5868",
  "premise_still_valid": true,
  "summary": "The card's premise held and then some: re-measuring on the producing repos' main found TWO dead pointers in that comment block, not one. The framework line was dead as filed (RuntimeConfigPlugin now lives in @objectstack/cloud-connection), and the cloud line cloud/packages/service-cloud/src/single-environment-plugin.ts is also gone — deleted with the rest of a dead forked per-environment runtime stack; the live single-environment producer is now a RuntimeConfigPlugin subclass in @objectstack/objectos-runtime. Fixing that second line is declared in the PR as a bounded in-place fix (same defect class, same comment block, same already-claimed file, mechanical, no new verification surface). Per the dispatch note no destination was copied from the card body, and the block is now anchored on exported symbol + package rather than file paths, with one clause saying why — a corrected path list would be true today and would rot on the next move, which is the exact failure this card exists to repair.",
  "tests": "Gate union re-run on final commit f696aeb6f; working tree identical to HEAD (git status --porcelain empty, git diff HEAD empty), so the typecheck/test runs describe that same tree. (1) DISCRIMINATING EVIDENCE — before/after pointer resolution through ONE pipeline (GitHub contents API at refs/heads/main), every leg with a declared expectation; script VERDICT: PASS. Before: framework packages/runtime/src/cloud/runtime-config-plugin.ts = MISS; cloud .../multi-environment-plugins.ts = HIT; cloud .../single-environment-plugin.ts = MISS. Positive controls on the same pipeline: framework packages/runtime/src = HIT, cloud packages/service-cloud/src = HIT (so the MISSes are readings, not typos). Negative control: framework packages/runtime/src/NO-SUCH-FILE.ts = MISS. After: all three symbol+package anchors HIT (pkg @objectstack/cloud-connection + sym RuntimeConfigPlugin; pkg @objectstack/objectos-runtime + sym RuntimeConfigPlugin; pkg @objectstack/service-cloud + sym createStudioRuntimeConfigPlugin), with three negative controls MISS including sym OS_CLOUD_URL, which is mentioned only in a comment in that same index — so the symbol leg cannot pass on a bare mention. Honest note on the instrument: a first, line-oriented symbol probe reported a FALSE MISS on createStudioRuntimeConfigPlugin (multi-line export block); the expectations table caught it, the probe was made multiline-aware and confirmed patched on disk (injected marker grep=1, old text grep=0), then re-run. (2) NO ABLATION — the diff is comment-only plus a changeset, so there is no behavioural leg to ablate; stating that plainly rather than staging a decorative reverse-verification. (3) pnpm exec vitest run packages/app-shell/src/runtime-config.test.ts (repo root, no bare double-dash) -> 'Test Files 1 passed (1)', 'Tests 16 passed (16)', exit 0. (4) pnpm exec vitest run packages/app-shell/ --maxWorkers=2 -> 'Test Files 506 passed (506)', 'Tests 4923 passed | 1 skipped (4924)', exit 0. (5) pnpm --filter @object-ui/app-shell type-check -> TYPECHECK_EXIT=0, zero 'error TS'; script name echoed in output ('> @object-ui/app-shell@... type-check'), so not a zero-match silent pass. First attempt was TYPECHECK_EXIT=2 with 932 errors, all the unbuilt-dependency class (TS2307/TS6305, incl. 'packages/types/dist/index.d.ts has not been built from source') — fixed by pnpm --filter '@object-ui/app-shell^...' build first, not by touching code. (6) node scripts/check-changeset-presence.mjs — run, not assumed: it FAILED first ('1 source file(s) of 1 released package(s) changed, and this change adds no changeset'), which is correct since the file is under a released package's src/; after adding an empty-frontmatter changeset it prints 'Every one of them has an EMPTY frontmatter — declared as releasing nothing, which is the explicit exemption and a complete answer to this gate.' (7) node scripts/check-changeset-no-major.mjs -> 'No changeset declares a major bump.' (8) node scripts/check-control-bytes.mjs -> 'OK (scanned 4881 tracked text file(s); skipped 85 binary)'. (9) node scripts/check-doc-links.mjs -> 'Links are valid across 13 scan roots.' (10) DECLARED LINT NARROWING (not a skip) — pnpm exec eslint packages/app-shell --format json, exit 0: population came from eslint's own config resolution (a directory was passed, eslint chose the files), count read from --format json = 941 files / 0 errors / 2606 pre-existing warnings, and eslint.config.js declares no projectService, no parserOptions and no project key (grep exits 1 on all three; control: 'rules' matches 10x), so type-aware linting is off and a comment-only edit in one file cannot move any untouched file's verdict. Every gate result above is quoted from the gate's own printed verdict line, with exit codes captured before any pipe. Heavy legs ran through scripts/pm/os-verify-lock.sh. RESOURCE NOTE for PM: the whole-package app-shell suite took 784s (13m04s) holding the shared lock — it does not fit the ~10min foreground cap and had to be polled in-turn; future seats on this package should prefer the path-filtered run.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as objectui#5869: cloud's runtime-config producer resolves a features.scim flag alongside customDomain and sso, but scim has zero occurrences across objectui packages/ and apps/ TypeScript (control: sso has 3 hits in runtime-config.ts itself) — declared-vs-consumed drift; unassigned, labels finding + domain:ui, no pm:queue, searched for duplicates first (0 hits on scim / RuntimeFeatures / runtime-config title searches)"
  ]
}

Generated by Claude Code

Navigation Menu

Repository navigation

finding: `runtime-config.ts` 的 "Server-side: see" 指针指向已迁走的框架路径(`packages/runtime/src/cloud/runtime-config-plugin.ts` 不存在,实际在 `packages/cloud-connection/src/`) #5206

观察

为什么值得记一笔

发现语境

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding: runtime-config.ts 的 "Server-side: see" 指针指向已迁走的框架路径(packages/runtime/src/cloud/runtime-config-plugin.ts 不存在,实际在 packages/cloud-connection/src/) #5206

Description

观察

为什么值得记一笔

发现语境

Activity

os-support-ai commented on Aug 18, 2026

claude commented on Aug 23, 2026

os-zhuang commented on Aug 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding: `runtime-config.ts` 的 "Server-side: see" 指针指向已迁走的框架路径(`packages/runtime/src/cloud/runtime-config-plugin.ts` 不存在,实际在 `packages/cloud-connection/src/`) #5206