test(dashboard): accept the team plan confirmation path in a browser

[huangruiteng]

Why

#4547 shipped the team plan confirmation card and #4548 shipped the rebuilt bundle, but the only verification was a unit smoke (transport + presentation reducer). The residual gap recorded in that PR was explicit: no browser-level acceptance for the click path. An owner-confirmable preview that never gets confirmed end-to-end is exactly the failure mode this lane has been fixing, so this closes the gap with the harness that already exists.

What

A new team-plan scenario in the personal workspace browser acceptance (examples/personal-workspace-browser/team-plan.mjs), registered in the existing scenario catalog:

1. a validated multi-lane preview becomes a proposal row that names the team.plan kind;
2. opening the card shows the Goal, the objective, a ready lane's Agent + first bounded Todo + priority + action kind + acceptance signal, the declared staffing gap with its reason and the work it did not staff, the quota envelope and the stop condition;
3. the card never claims a lane already exists before confirmation;
4. confirming sends exactly one apply for the confirmed proposal, performs exactly one durable write, and the drawer then reports the applied state;
5. no client-side exception is raised, and no LoopX API call fails during the confirm flow.

The only fixture-controlled parts are the service boundary (initialActionProposals); nothing computes the plan under test.

One deliberate decision, stated in the scenario: a development-server resource status (e.g. the dev server refusing a font path) is not treated as a client failure — it is a harness path question, not product behavior — so the error assertion distinguishes a client-side exception from a resource-load console message, and the API assertion only covers /api/ responses.

Validation

• LOOPX_PERSONAL_WORKSPACE_SCENARIO=team-plan node examples/personal-workspace-browser-smoke.mjs — ok, scenarios=team-plan.
• Full acceptance run with the scenario registered — ok, scenarios=navigation-sorting,chat-recovery,typed-actions,team-plan,execution-chip, so the new scenario is additive and the existing four still pass.
• loopx canary premerge --from-git-diff — passed (diff hygiene, catalog canaries including the semantic-vocabulary and frontstage smokes, public/private boundary scan; one advisory: the known baseline maintainability ratchet).

Residual Gaps

• The scenario asserts the client's apply request and the applied state it renders; it does not run the real LoopX apply for team.plan (that path is covered by the Python tests for the Chat action and the governed transition owner).
• Screenshots (team-plan-preview.png, team-plan-applied.png) are written to the browser smoke output directory for inspection; they are not committed.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Reviewed exact head: d9e760224c2f7e9903f13dedd539c59e208fb1c5

English verdict: APPROVE

动机

#4547 出货了团队预览的确认卡片，#4548 重建了被打包的 chat bundle，但当时的验证只到单元层（传输 schema + 呈现 reducer），并在 PR 里明确留下了残余缺口：没有浏览器级的点击链路验收。"业主可确认但从未真正端到端确认过"正是本 lane 一直在修的那类失败，所以这一刀用仓库既有的浏览器验收框架把它补上。

改动思路

• 复用既有框架而不是新造：在既有 scenario catalog 里新增一个 team-plan 场景，服务边界只由既有 fixture 的 initialActionProposals 控制，被测逻辑不被 fixture 计算。
• 断言"业主真正关心的事实"：能看到什么、能确认什么、确认后发生了几次写入。
• 对无关噪声做出明确且可解释的取舍：dev server 的资源 403（本 worktree 因 node_modules 符号链接导致）不算客户端故障，断言区分"客户端异常"与"资源加载 console 信息"，API 断言只覆盖 /api/。

具体改动

• examples/personal-workspace-browser/team-plan.mjs（新，+189）：team-plan 场景。
• examples/personal-workspace-browser-smoke.mjs（+2/-1）：导入并注册该场景。

场景断言：提案行点名 team.plan；卡片显示 Goal/目标/就绪 lane 的 Agent + 首个有界 Todo + priority + action_kind + 验收信号/缺口 lane 的"未配齐 + reason + 未配出的工作"/quota 包络/停止条件；确认前绝不出现"已创建/已组建"；确认只发一次 apply、只发生一次 durable write，并在抽屉里显示已应用状态；无客户端异常、确认流程内无 /api/ 失败。

对主干的风险

1. 只新增验收，不改产品：本 PR 不含源码行为变化，只有测试场景与注册项；失败时会在 CI/本地立即暴露，不会静默。
2. 既有场景未被影响：全量运行 navigation-sorting,chat-recovery,typed-actions,team-plan,execution-chip 全部通过。
3. 断言边界被明确记录：把 dev server 资源状态排除在客户端故障之外，并在 PR/代码注释里写明理由，避免把"环境问题"伪装成"产品通过"或反之；/api/ 覆盖确保确认流程本身没有任何失败请求。
4. 未做：场景验证的是客户端的 apply 请求与它渲染的已应用状态，不运行真实 LoopX 的 team.plan apply（那条路径由 Chat action 与 governed transition owner 的 Python 测试覆盖）；PR body 已点名。

我的整体评价

正向且 proportional：约 190 行、单一目的，把上一刀自己记录的残余缺口补成可重复执行的验收，并且用既有 harness 而不是新框架。

验证：单场景与全量场景均通过；canary premerge 通过（唯一 advisory 为已知基线 maintainability ratchet）。

作为作者自有 PR，GitHub 不允许正式 self-approve，故以本 COMMENTED review 作为放行结论。