Skip to content

[PM seat] repo:objectui — 🔴 vacant · last shift: consolidated seat session_018rzQyhLGC5iVs11V3TzRs5 closed 2026-09-09T06:3xZ (brief on thread) · prev: os-sales session_014zHsbJoTkTZeJQ5DLbRXrE 收班 R26 #6025

Description

@claude

本贴是 repo:objectui 座位的唯一权威登记。 索引 = label:pm:seat,总入口 #4604。正文为权威;晚于正文最后编辑时间的评论是现状。

🔴 收班 · session session_014zHsbJoTkTZeJQ5DLbRXrE · domain:ui 车道 · round 26

维护者 2026-08-21 指示:「如果 api 有问题,可以当前任务处理完合并了就下班」。在飞已清零(5 张全部完成实现),四张 PR 已全部处置——三张已合并,p0 的那张见下。收班后未再派发。

⚠️ 本班期间账号发生切换:前半程为 qq9340100 / claude[bot],后半程重新授权为 os-sales。这带来两个后果,下一班必须知道。


✅ 交接第一条(已解决,原文作废)

收班后维护者重新授权,MCP 恢复,四张 PR 已全部处置。 原记载的「本席无法把 draft 转 ready」在 MCP 恢复后不再成立。留此条只为记录三条路的实测结论,下一班遇到同样症状可直接用:

  • REST PATCH /pulls/{n}draft:false 返回 200 但 draft 仍为 true(REST 永远改不了 draft,已二次证实);
  • GraphQL 在本会话只放行固定的 review 操作,markPullRequestReadyForReview / enablePullRequestAutoMerge 均被拒;
  • MCP 是唯一可行路径,它一断,入队能力就整个消失。⬛ 下次遇到先修 MCP,别在 REST/GraphQL 上耗。

结果:#5555#5424)、#5556#5533)、#5558#5034)均 22/22 全绿并已合并

✅ 交接第一条之二:PR #5546 不可达,已用第二分支绕开并落地

**结局:main = 0935a43be,p0 已落地。**⚠️ **合并动作由维护者亲手完成,不是本席。**本席的入队调用因 GraphQL 配额耗尽(used 10001/5000, remaining 0)失败;随后看到一条 actor 为 os-salesenqueued 事件,因两者此刻是同一账号,本席一度误记为自己那次失败调用生效了——维护者当面更正。同账号下 actor 字段分不出人与 agent,判据只能是会话自己的调用是否返回成功。

落地后在树上带控制探针复核:.env.production 不再有 live DSN 行(控制探针:该文件仍有 13 个 VITE_ 键,故仪器是活的、缺失是真的);sentry.ts:114=== 'true' 即 opt-in;:99 / :105 的 fail-closed 判决均带 sendDefaultPii: falseresolveSentryGate 导出于 :91

原委记录如下。

#5546#5522,p0/security)曾达 22/22 全绿,随后对维护者与本席均返回 404head 过滤查询在任何 state 下都返回空,而 GitHub 仍拒绝为该分支新建 PR(a pull request already exists)。即:记录存在,但无法到达,因而无法评审、无法入队、无法合并。

⚠️ 该 p0 修复当时并未落地 —— 实测 mainapps/console/.env.production 仍提交着 live DSN 与 VITE_SENTRY_SEND_DEFAULT_PII=true。若当时只凭 #5546 的“全绿”就当它已交付,这条 p0 会静默地留在产品里。

处置:把同一个已验证提交 f751c0288 推到第二分支 claude/issue-5522-sentry-telemetry-reopen,开出 PR #5559(非 draft)。未重建、未 rebase、未重验——是同一个对象。若 #5546 将来可达,两者是同一棵树,关掉冗余的那个即可。

⛔ 交接第二条:一段 issue 编号对本会话不可见

账号切到 os-sales 后,#5533、#5545–#5552 这一段读取一律 404,而其两侧(#5544#5553+)正常。已重试确认非瞬时。后果:

我没有对这个现象下诊断——只报读数。


✅ 本轮落地 20(全部在树上复核过)

7d0143c35  #5545 (#5519)    7493bff63  #5539 (#5486)
eba3a6eaa  #5537 (#5040)    4bb940b6e  #5530 (#5498)
9e2208544  #5534 (#4082)    ca2b4096e  #5532 (#4838)
20e317cd5  #5517 (#5504)    100547e36  #5523 (#5449)
6cc62e225  #5526 (#4881)    ec9fdaaa5  #5516 (#5134)
e40b8579b  #5525 (#5438)    cef27e2b1  #5513 (#5444)
ff7543c5d  #5512 (#5020)    c86185eb5  #5505 (#5454)
8fce8a0fb  #5510 (#5067)    9b9af8dbb  #5509 (#5348)

📌 平台事实(本轮实测,⛔ 下一班不必重测)

  • 共享 verify lock 扛不住并发 5:docs: v17 docs sweep run 5 — rc.2 catch-up #4881 为一条跑 15s 的命令等 461s;17.x 立项:建设声明式 ApiEndpoint 执行器(挂载 + matchEndpoint + authRequired/cacheTtl/inputMapping/outputMapping 逐键接线) #5040 exit 99 / 9m00s 从未获得。规则:拿不到锁就如实说没跑什么、靠 CI;⛔ 绝不把没跑的套件报成通过。锁在兄弟仓 /home/user/objectstack/scripts/pm/os-verify-lock.sh(本仓无 scripts/pm/)。
  • dispatch-gates.mjs 对 objectui 不可用:按自身位置解析 repo root,从 objectui worktree 跑会分析 objectstack 树并 exit 2。gate 家族只能从本仓 .github/workflows/*.yml 手工推导。本轮五个 agent 各自独立撞上。
  • 本仓 check run 的 output 一律为空;get_job_logs 是唯一诊断仪器,pull_request_read get_status 无用。读点名 job,⛔ 永不读聚合。
  • 按 SHA 取 check-runs 比按 PR 号更耐用:/commits/{sha}/check-runs 在 PR 号 404 时仍可用——本轮就是靠它确认 fix(client): 让 client 测试层真的进 tsc,那处 @ts-expect-error 不再是幽灵检查 #5546 全绿的。
  • /search/issues 被仓库范围限制挡住,查重用 /repos/{o}/{r}/issues 列表 + 本地过滤。
  • pnpm --filter PKG test 被本仓 guard 拒绝(chore(release): exit RC pre-release mode → stable 16.0.0 #3378):从包目录跑 vitest 会静默改跑 console 的 22 个文件并报 Test Files 22 passed —— 假绿。一律用 pnpm exec vitest run PATH 从仓根跑。
  • sanitizer 会吃掉尖括号片段,写入后必须回读;本贴上一版就被吃掉一个占位符。issue_read 会剥掉同样的片段,所以它诊断不了自己造成的损伤
  • 常设条款:「一棵被验证过、但不是被推送的树,不构成证据。」
  • auto-merge / draft→ready 只能走 GraphQL,而 GraphQL 池会被打满:本班尾声实测 graphql used 10001/5000, remaining 0,约 21 分钟后重置,期间 core 仍有 14989 余量。⛔ 不要因为 core 有余量就改用 REST PUT /pulls/{n}/merge ——那会绕过合并队列,等于把刚验的绿换成没验的绿。正确做法是等配额。
  • cwd 会在 Bash 调用之间重置:不带 cd 前缀的 gitfatal: not a git repository,若命令写成 git ... || echo "没问题",失败会打印出成功的结论。本班两次险些据此报错结果,都靠控制探针拦下。⛔ 每条 git 命令都带 cd /home/user/objectui &&

⚠️ 本席本轮犯的错(下一班据此校准本贴读数)

全部已在对应卡片上公开更正。共同形状:用「看起来对的东西」代替一次读取。

  1. 17.x 立项:建设声明式 ApiEndpoint 执行器(挂载 + matchEndpoint + authRequired/cacheTtl/inputMapping/outputMapping 逐键接线) #5040 认领了却没派发 —— 标签、assignee、认领评论全是我自己写的,它们按构造必然自洽,没有一个能证明容器存在。此后改为用 ListAgents 按名核对活 agent 数。
  2. [17.0-rc2验收] REST create/update 回包的 record 缺所有 formula 字段(GET/LIST 有)—— applyFormulaPlan 只挂在 find/findOne 上,写路径回包不做公式水合 #5504 文件面报错 —— 声明 apps/console/src/**,实际在 packages/app-shell/src/console/{marketplace,home}/**
  3. fix(cli): OS_APP_NAME 压过 config.email.defaultTemplateContext.appName —— 恢复「env 逐项覆盖」契约 (#5448) #5498 两处 pin 的推断错,且朝一个会让缺陷更糟的答案施加了压力;dev 用四条证据推翻。
  4. docs(pm-dispatch): 协调模型改版 —— 分诊/执行纵向拆分 + 一人一车道双射 + 登记表正文即真相 + 座位 Routine 化 (#5472) #5522 把新增文件说成既有 pin —— 我称 sentry.test.ts:143 是既有 pin 并据此给了整套框架;git ls-tree origin/main 一条命令就能证伪(该目录当时只有四个文件)。真因与我的假设无关(本仓 Vitest 的 import.meta.env 只暴露五个键,vi.stubEnv 写的是 process.env)。
  5. fix(tooling): 发布说明页留在审计范围内,降级为只读通道 —— 报 finding,不改盘 (#4920) #5034 读错了当前生效的阻塞 —— 我把「阻塞解除」建立在卡面抬头的 validateOrgAxisRedLines 的 objects[].rowLevelSecurity 分支同样是死路径:ObjectSchema 不声明该键 #4989 上,没有回读晚于正文的评论;而本仓惯例是把 Blocked-by: 写进评论(分诊常设指令⑥明文记着,我知道仍漏了)。判据是 objectstack#9474 的 Restart-when:,至今未被求值。dev 照样推进是对的(所派范围与之正交),但该判据仍需求值。
  6. 基础设施通告未随事实更新 —— 我通告「git 也断了」,git 先恢复后我没重测,fix(tooling): 发布说明页留在审计范围内,降级为只读通道 —— 报 finding,不改盘 (#4920) #5034 的 dev 实测 push exit 0 并纠正了我。

🔴 等维护者裁决

本轮新增(⚠️ 现不可见,恢复后需处理):#5547(requiredRoles 在 ADR-0090 D3 后的语义;它同时卡着 types.tsroles?: string[] 的退休——站点 1 是其唯一活读者)、#5548(navigateOnSuccesssubmitBehavior.redirect 的前裁定祖先,还是自带方言的独立键)。

#5550(不可见):#5546 合并后,托管 SaaS/demo console 必须在 Vercel 部署环境注入 VITE_SENTRY_DSN,否则错误上报为关;VITE_SENTRY_SEND_DEFAULT_PII 已由 opt-out 改为 opt-in这一步在部署面板里,任何 agent 都做不到。

承前(上一班读数,本席未重验):skills/** 受管归属、#5442(16 个版本从未到达 npm)、#5436#4986#5468。加本席早前的 #4934#5451#5504-Ask3(FYI)。

🟡 就绪队列(已预审)

#5344(设计器改列拼写后 object-grid 不渲染)· #5492(内联 lookup 下拉显裸 ID / ISO 原文 / enum code)—— 两者的包锁均已随本轮合并释放。

📎 本轮新立(dev 与本席)

#5547 #5548 #5549 #5550 #5551 #5552 #5557,objectstack#10741 #10742。其中 #5549 值得点名:Console 的 /home 压根没挂权限 provider(MePermissionsProvider 唯一挂载点是 AppContent,只覆盖 /apps/:appName/*),于是 useCanAuthorMetadata 走无 provider 默认值——一个字面返回 true 的箭头函数#5521 若照原样派发,会做出一个不起作用的门,必须先修 #5549


Generated by Claude Code


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    pm:seatPM seat registry issue - single-writer body, index = this label

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions