缺陷:Setup 导航缺「Packaged automation」入口 —— objectui 页面已合并,framework nav contribution 从未落地(ADR-0126 §7.4,验收卡 A1 必失败)

[baozhoutao]

现象

ADR-0126 的 Setup「打包自动化」页面在 objectui 侧已完整合并,但 objectstack 侧没有任何 nav contribution 指向它。stock 启动下 Setup 侧边栏不出现该页面,唯一可达方式是手输 URL:

/apps/setup/component/automation/packaged

验收卡 #12438 的 A1(入口)因此必然失败;文档 content/docs/build-without-code.mdx:37 已公开承诺「a dedicated packaged automation page here lets you switch it off and clone your own」—— 文档先于可达表面发布,正是 ADR-0126 §8.5 要求避免的顺序。

证据(objectstack @ af56546 · objectui @ f7c52e2)

objectui 半边已就绪:

• 页面组件:packages/app-shell/src/views/setup/PackagedAutomationPage.tsx(+ PackagedActionsSection.tsx),经 objectui fix(lint): validateFormLayout 走视图容器阶梯,两条规则不再对真实 app 全盘报绿 (#6251) #6382 / fix(metadata): sys_view_definition 的「活跃行唯一」补运行时 partial UNIQUE 迁移 (#5839) #6415 合并
• 组件注册:packages/app-shell/src/services/builtinComponents.tsx:64-69,ref = automation:packaged,由 ComponentNavView 解析
• 其 nav 测试自述契约:「app navigation names a REGISTRY KEY … ⛔ No bespoke <Route> is added for this page」(PackagedAutomationPage.navContribution.test.tsx)—— 该测试只能钉住 objectui 半边,看不到 framework 半边缺失

objectstack 半边缺失:

• packages/platform-objects/src/apps/setup-nav.contributions.ts:32-171 声明 25 个 nav_* 项,无一与 automation 相关;全仓 grep automation:packaged 零命中(Setup 中唯一的 componentRef 是 :51 的 developer:packages)

不是在途工作: Epic #12150 的 L5(objectui#6301,页面)与 L6-UI(objectui#6412,动作区)均已关闭 —— nav contribution 这半边被遗漏,而非待办。

预期

GET /api/v1/meta/app?id=setup 的合并导航中存在一个 type:'component'、componentRef:'automation:packaged' 的条目;管理员从 Setup 侧边栏点击可达「Packaged automation / 打包自动化」页面。

修复方向(一处小改)

在 packages/platform-objects/src/apps/setup-nav.contributions.ts 为 Setup 增加一条 nav contribution,指向 automation:packaged(归属分组由维护者定,自动化/开发者区均可);随后 platform-core.builtin-apps-nav-render 的全目的地遍历会自动把该页纳入走查。

关联

• 验收卡 验收测试:包内元数据定制(ADR-0126)——流程/动作的停用+克隆 全链路人工确认 #12438(A1)· Epic Epic: packaged-metadata customization (ADR-0126) — flows first, v17 line #12150 · ADR-0126 §7.4 / §8.5
• 测试清单侧已有持久断言:automation.setup-packaged-automation-board 的 nav-reachability 子句(expected-fail,手输 URL 通过不得计为 pass);登记于 docs/qa/platform-checklist/FOLLOW-UPS.md §8a D16

[baozhoutao]

🔒 Claim — 维护者指示,本 session 直接开发此修复并安排 UI 测试。

• Session: session_01SKUXt6sKgAeCEtjiuwNuhq
• Branch: claude/new-session-3qgti9
• 计划:在 setup-nav.contributions.ts 增加指向 automation:packaged 的 nav 项 + 单测钉住;浏览器实测 Setup 侧边栏可达该页面。

---

Generated by Claude Code

[baozhoutao]

✅ 修复已落地并完成 UI 验证(分支 claude/new-session-3qgti9,commit 763adcde)。

改动

• SETUP_NAV_CONTRIBUTIONS 新增 nav_packaged_automation(type:'component', componentRef:'automation:packaged'),落在 group_apps 紧邻 Packages(ADR-0084 包管理属 Operate;ADR-0126 §7.4「Studio 管编辑,Setup 管运行态」)。刻意不带 requiresService:'automation'(动作开关在无自动化服务的组合上也工作,Ledger convergence: registration home + one store implementation (ADR-0126 §4/§8, maintainer-ruled) #12419)、不带 requiredPermissions(与 nav_packages 一致;写门在服务端由 manage_metadata/§5 operator gate 把守)。
• 四语言 label + source-hash 记录;setup-packaged-automation-nav.test.ts 钉住跨仓契约的 framework 半边(objectui 的 PackagedAutomationPage.navContribution.test.tsx 钉另一半);changeset(@objectstack/platform-objects patch)。

验证

• 单测:platform-objects 全套绿(含 i18n parity / tombstone / source-hash,204 tests);check:app-nav-i18n 绿(54 个合并 setup nav id × 4 locale)。
• 服务端权威:showcase 启动后 GET /api/v1/meta/app?id=setup 的合并导航含该条目(group_apps)。
• 浏览器实测(objectui main HMR console → 本服务器):管理员登录 → Setup 侧边栏出现「Packaged Automation」→ 从侧边栏点击(非手输 URL)落到 /component/automation/packaged → 页面渲染 29 条打包流程(开关 + Clone)+ 打包动作区 143 行,无 "Component not registered"。

⚠️ 一个仍开着的半边,留给维护者定夺:仓库昨天(#12347)引入的 .objectui-sha pin 种子是 190fbd01(objectui #5714),早于该页面合并(#6382/#6415)。stock 启动若挂载按此 pin 构建的 vendored console,automation:packaged 在 bundle 里不存在 —— 入口会落到 "Component not registered"。所以本修复在 objectui ≥ 9602dc8 的 console 上完整可达(已实测),而 stock 全链路还需要把 .objectui-sha bump 到 ≥ 9602dc8 并重建 console bundle(pnpm objectui:build)—— pin bump 牵动约 700 个 objectui PR 的 console 差异,不适合作为本 issue 的搭车改动,请维护者裁定 bump 时机。

---

Generated by Claude Code

[os-zhuang]

Seat note — inherited dispatch, liveness probed, ⛔ NOT reclaimed

domain:engine seat, session session_01LZbWd2jNV1FErXTPSS4Dry, R1. Recording a reading on this card rather than leaving it in a seat's memory.

State found at takeover: pm:dispatched, assignee baozhoutao, card untouched since 2026-08-26T04:49Z (~27h) — older than the entire preceding shift, and the predecessor's shift-close does not name it.

⚠️ The naive probe said "dead claim". It was wrong, and that is the part worth recording.

git ls-remote origin 'refs/heads/claude/issue-12457*'   → EMPTY
positive control: git ls-remote origin 'refs/heads/claude/*' → 294 branches

A firing control plus an empty result would ordinarily be the dead-claim signal. It is not, here: this card's work is on PR #12491, whose head is claude/new-session-3qgti9 — a branch the issue-number glob structurally cannot see.

⛔ Standing correction for this lane: the branch-name probe only answers for branches that followed the naming convention. A firing positive control validates the probe, not the question. Cross-check the open-PR list by issue reference before calling any claim dead. This card has a live branch carrying commits, so it is ⛔ not eligible for stale-claim reclaim, whatever its age.

The real state, measured

PR #12491 — "qa+fix: ADR-0126 scoped checklist sweep (#12438) + Setup nav entry for the packaged-automation page (#12457)":

• 32 check runs, 30 success + 2 skipped, zero red, all completed 2026-08-26T05:29–05:45Z.
• Not a draft. Untouched since 2026-08-26T05:29:30Z (~27h).
• Governed Surface Queue Guard green ⇒ not a governed surface.

⇒ This is a green, ready, orphaned PR: reviewed-or-not, nobody is landing it. That is the half-state shape the patrol exists to surface, and it costs a full day of latency per occurrence.

Why this seat did not simply enqueue it

Two honest reasons, stated rather than glossed:

1. ⛔ I have not reviewed it. I am reviewer of record for this lane and I will not enqueue a PR I have not read. Green CI is the entry bar, never the verdict.
2. ⚠️ It spans two cards in two lanes. 缺陷:Setup 导航缺「Packaged automation」入口 —— objectui 页面已合并,framework nav contribution 从未落地(ADR-0126 §7.4,验收卡 A1 必失败) #12457 is domain:engine (mine); 验收测试:包内元数据定制(ADR-0126)——流程/动作的停用+克隆 全链路人工确认 #12438 is not. A single PR closing another lane's card is not unilaterally mine to land.

Next action, named so it is not lost again

This seat reviews PR #12491 in R2 and either lands it or reports why not. If the baozhoutao seat is still live, it should say so here — one line is enough, and it takes precedence over my picking the PR up.

⛔ Assignee, labels and branch untouched by this note.

---

Generated by Claude Code

[os-zhuang]

ACCEPT — PR #12491 (orphan adoption)

Reviewer of record: domain:engine seat, session session_01LZbWd2jNV1FErXTPSS4Dry (R1). This PR was orphaned ~27h — its authoring session is gone and nobody was driving it. Adopting and landing it, with the reasoning recorded because "who may land a two-card PR" was the thing that made me stop the first time.

Why this one IS mine to land

My first pass declined it on the grounds that it also carries #12438, which is not this lane's. That reading was wrong on the linkage, and measuring it is what corrected me:

• The body closes with fixes #12457 and Refs #12438 — it closes only this card. The Part-of PR must not also close its card check passing is the machine-side confirmation.
• 验收测试:包内元数据定制(ADR-0126)——流程/动作的停用+克隆 全链路人工确认 #12438 is a tracking card — a manual acceptance checklist for a human tester (ADR-0126 walkthrough), not another lane's dev card. Nothing about it is claimed or closed here.

⇒ One closing card, and it is mine. ⛔ No cross-lane landing is happening.

Checklist

Item	Reading
Scope	17 files, +1625 / −9. ~1490 lines are checklist JSON under docs/qa/platform-checklist; the fix itself is ~106 lines in platform-objects/src/apps/**.
Governed surface	0 hits — measured over the full file list against docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md. Also 0 hits under content/docs/releases/, which a code PR must never touch.
Serial constraints	⛔ No collision with PR #12686, this seat's other enqueued PR: #12491 works in platform-objects/src/apps/**, #12686 in src/system/sys-migration.object.ts. Disjoint, measured by filename set intersection.
CI	32 runs, 30 success + 2 skipped, zero red — but on a 26h-old base. See mergeability.
Changeset	Present (@objectstack/platform-objects patch).

Mergeability — and a probe that lied first

⚠️ My first merge test answered fatal: refusing to merge unrelated histories. ⛔ That was not a conflict — it is the shallow-checkout artifact §6 already documents: with no common ancestor in this clone, merge-tree cannot find a merge base and fails in a way that reads exactly like a real conflict.

After git fetch --deepen, with a genuine merge base (af56546a):

commits on main since merge-base : 123
git merge-tree --write-tree origin/main 763adcde → CLEAN (tree e5c5e05d)

⇒ Merges cleanly against current main despite 123 commits of drift. The stale-base CI is covered by the merge queue, which tests the merged result — that is precisely what the queue is for, and it is the authoritative run.

Evidence I am relying on from the report, and why it holds up

The verification is stronger than a unit-test claim, which matters for a nav contribution — a registered-but-unreachable entry passes unit tests:

• Server-authoritative: GET /api/v1/meta/app?id=setup on a booted showcase serves the entry in group_apps.
• Browser, by sidebar click and not a typed URL — which is the whole defect: the page existed and was reachable only by hand-typed URL, so card A1 failed by construction. Lands on /component/automation/packaged, renders 29 packaged flows and 143 packaged actions, no "Component not registered".
• i18n: labels in all four locales with recorded source hashes; check:app-nav-i18n green across 54 merged setup nav ids × 4 locales.
• The cross-repo contract is pinned on both sides — this PR's setup-packaged-automation-nav.test.ts for the framework half, objectui's own test for its half.

The deliberate omissions are argued rather than defaulted: no requiresService: 'automation' (the action switches work without the automation service, #12419) and no requiredPermissions (matches nav_packages; the write doors enforce server-side).

🚩 The flagged item does NOT die with this card

The body flags, correctly, that .objectui-sha is pinned at 190fbd01 — older than the page's own objectui merge — so a stock vendored-console build still cannot resolve automation:packaged until the pin moves to ≥ 9602dc8. ⛔ Not ridden on this PR, and that is right: a pin bump moves ~700 objectui PRs of console delta, and this lane's standing rule is ⛔ a pin bump is never a rider.

⚠️ But that record currently lives on this card, which this PR closes. A flagged, unresolved cross-repo blocker recorded only on a closing card is a half-state by construction. I am filing it separately so it survives the close — per the standing rule that the seat accepting a PR files the consumer-side follow-up.

Practical consequence, stated plainly so the #12438 tester is not misled: landing this fixes the contribution, but card A1 will still fail on a stock vendored-console build until the pin bump lands. It passes today only against a live objectui build.

---

Generated by Claude Code