Repository navigation
缺陷:Setup 导航缺「Packaged automation」入口 —— objectui 页面已合并,framework nav contribution 从未落地(ADR-0126 §7.4,验收卡 A1 必失败) #12457
Description
Activity
🔒 Claim — 维护者指示,本 session 直接开发此修复并安排 UI 测试。
- Session:
session_01SKUXt6sKgAeCEtjiuwNuhq - Branch:
claude/new-session-3qgti9 - 计划:在
setup-nav.contributions.ts增加指向automation:packaged的 nav 项 + 单测钉住;浏览器实测 Setup 侧边栏可达该页面。
Generated by Claude Code
- Session:
- added a commit that references this issue
on Aug 26, 2026 ✅ 修复已落地并完成 UI 验证(分支
claude/new-session-3qgti9,commit763adcde)。改动
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-objectspatch)。
验证
- 单测: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-shapin 种子是190fbd01(objectui #5714),早于该页面合并(#6382/#6415)。stock 启动若挂载按此 pin 构建的 vendored console,automation:packaged在 bundle 里不存在 —— 入口会落到 "Component not registered"。所以本修复在 objectui ≥9602dc8的 console 上完整可达(已实测),而 stock 全链路还需要把.objectui-shabump 到 ≥9602dc8并重建 console bundle(pnpm objectui:build)—— pin bump 牵动约 700 个 objectui PR 的 console 差异,不适合作为本 issue 的搭车改动,请维护者裁定 bump 时机。
Generated by Claude Code
Seat note — inherited dispatch, liveness probed, ⛔ NOT reclaimed
domain:engineseat, sessionsession_01LZbWd2jNV1FErXTPSS4Dry, R1. Recording a reading on this card rather than leaving it in a seat's memory.State found at takeover:
pm:dispatched, assigneebaozhoutao, 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 branchesA 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 Guardgreen ⇒ 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:
- ⛔ 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.
⚠️ It spans two cards in two lanes. 缺陷:Setup 导航缺「Packaged automation」入口 —— objectui 页面已合并,framework nav contribution 从未落地(ADR-0126 §7.4,验收卡 A1 必失败) #12457 isdomain: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
baozhoutaoseat 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
ACCEPT — PR #12491 (orphan adoption)
Reviewer of record:
domain:engineseat, sessionsession_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 #12457andRefs #12438— it closes only this card. ThePart-of PR must not also close its cardcheck passing is the machine-side confirmation. - 验收测试:包内元数据定制(ADR-0126)——流程/动作的停用+克隆 全链路人工确认 #12438 is a
trackingcard — 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 inplatform-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 undercontent/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 insrc/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-objectspatch).Mergeability — and a probe that lied first
⚠️ My first merge test answeredfatal: 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-treecannot 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
maindespite 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=setupon a booted showcase serves the entry ingroup_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-i18ngreen across 54 mergedsetupnav ids × 4 locales. - The cross-repo contract is pinned on both sides — this PR's
setup-packaged-automation-nav.test.tsfor 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 norequiredPermissions(matchesnav_packages; the write doors enforce server-side).🚩 The flagged item does NOT die with this card
The body flags, correctly, that
.objectui-shais pinned at190fbd01— older than the page's own objectui merge — so a stock vendored-console build still cannot resolveautomation:packageduntil 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
- The body closes with
现象
ADR-0126 的 Setup「打包自动化」页面在 objectui 侧已完整合并,但 objectstack 侧没有任何 nav contribution 指向它。stock 启动下 Setup 侧边栏不出现该页面,唯一可达方式是手输 URL:
验收卡 #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解析<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 相关;全仓 grepautomation: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的全目的地遍历会自动把该页纳入走查。关联
automation.setup-packaged-automation-board的 nav-reachability 子句(expected-fail,手输 URL 通过不得计为 pass);登记于docs/qa/platform-checklist/FOLLOW-UPS.md§8a D16