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

Activity

1. baozhoutao

   self-assigned this

   on Aug 26, 2026
2. baozhoutao commented on Aug 26, 2026

   

   baozhoutao

   on Aug 26, 2026 – with Claude

   ContributorAuthor

   More actions

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

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

   ---

   Generated by Claude Code
3. baozhoutao

   added a commit that references this issue on Aug 26, 2026

   fix(platform-objects): Setup nav entry for the packaged-automation pa…

   ...

   763adcd
4. baozhoutao commented on Aug 26, 2026

   

   baozhoutao

   on Aug 26, 2026 – with Claude

   ContributorAuthor

   More actions

   ✅ 修复已落地并完成 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
5. os-zhuang commented on Aug 27, 2026

   

   os-zhuang

   on Aug 27, 2026 – with Claude

   Contributor

   More actions

   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
6. os-zhuang commented on Aug 27, 2026

   

   os-zhuang

   on Aug 27, 2026 – with Claude

   Contributor

   More actions

   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
7. os-zhuang

   closed this as completedin #12491on Aug 27, 2026
8. os-zhuang

   removed

   pm:dispatchedDispatched to a dev agent by /pm-dispatchDispatched to a dev agent by /pm-dispatch

   on Aug 27, 2026
9. baozhoutao

   added 2 commits that reference this issue on Aug 30, 2026

   qa(checklist): coverage sweep 2026-08-30 — 28 new items + 10 revision…

   ...

   c54aec0

   qa(checklist): sweep 2026-08-30 close-out — platform-core wave, cover…

   ...

   6d31fb3
10. akarma-synetal

    added 2 commits that reference this issue on Sep 1, 2026

    qa+fix: ADR-0126 scoped checklist sweep (objectstack-ai#12438) + Setu…

    ...

    e0abc38

    qa(checklist): 2026-08-30 five-angle coverage sweep — 221 → 260 items…

    ...

    45397ed