Skip to content

[Decision] 22 pure-objectui defect cards live in objectstack under repo:objectui, but objectui IS reachable — the seam fallback is being used where its precondition does not hold #17250

Closed

Description

@huangyiirene

Maintainer-action: hand-transfer exactly SIX cards via the GitHub web UI Transfer issue to objectstack-ai/objectui — #14026 objectstack-ai/objectui#10107 objectstack-ai/objectui#10108 objectstack-ai/objectui#10109 objectstack-ai/objectui#10110 objectstack-ai/objectui#10112 — and nothing else. The triage seat recreates the other 27 (see 〈混合方案〉 below). Done when objectstack's open label:repo:objectui set is exactly the SIX seam cards #14831 #14837 #15140 objectstack-ai/objectui#10438 objectstack-ai/objectui#10439 objectstack-ai/objectui#10432.

⬆️ 本行由分诊席于 2026-09-20T12:48Z 按维护者 chat 批准改写(原话:「混合方案,写进卡,27 张你重建」)。⚠️ 被改写的旧行有两处已过期,记在这里而不是抹掉:① 它把完成判据写成「恰好剩三张缝卡 objectstack-ai/objectui#10437 #14837 #15140」—— 现读缝卡是六张,多出的 #18377 #18387 #18397 是 9-10 之后新立的,旧判据按字面永远不可能满足;② 它写「23 张」,现读非缝卡是 33 张。⛔ 裁决(A:搬回 objectui)未变,变的只是执行分工与两个过期数字。

混合方案(维护者 2026-09-20 批准)

⭐ 为什么不再是「你点 33 次」:立卡时算的那笔账 ——「22 张里 17 张零评论,重建近乎无损」—— 已经不成立了。现读:33 张非缝卡里只剩 4 张零评论,其余 29 张共 44 条评论。

⚠️ 而这个恶化是我们自己造成的:这十天里分诊席一直在原地给这些卡补判级评论。⇒ 卡放得越久,重建这条回退路越贵,推高它的正是席位自己的工作。这一条值得记住,⛔ 不只是本卡的事。

但拆开看,贵的高度集中:

分组 张数 评论 处置
线程含不可重写证据 6 21 维护者手工 transfer(无损)
线程只有分诊判级评论 27 23 席位重建,判级由重建席在新卡上重写

实测支撑:那 27 张上的 23 条评论逐条读过,全部是 PM 席位写的路由/判级评论(作者:os-warren huangyiirene os-zhuang os-litant os-sam),零条证据线程。⇒ 重建不丢任何不可重写的内容。相对地,#14026 的 10 条线程正是它标题里那句「Re-raise of #4375 with the downstream confirmation it asked for」的那个确认本身 —— 那种丢不起。

⇒ 维护者的手工操作从 33 次降到 6 次。

席位重建的 27 张

#13751 #14883 #14884 #14885 #14886 #14888 #14952 #15135 #15259 #15260 #16171 #16276 #16345 #16381 #16735 #16815 #17106 #17264 #17271 #17272 #17307 #17557 #18151 #18152 #18154 #18155 #19051

重建按 SKILL.md〈多仓协调〉原文执行:「transfer 不可用时重建:出处头 + 裸 #N 改全名 + 关源单为 moved」。

⭐ 重建顺带解掉的一个死结

#17106 #17264 #17271 #17272 #17307 五张的正文写着 Blocked-by: objectstack-ai/objectstack#17250 —— 它们被本卡自己挡着,即「在知道这张卡该住哪个仓之前别动它」。迁移本身就是那个答案 ⇒ 重建后的新卡 ⛔ 不携带这条 Blocked-by:,直接进 pm:queue。其中 #17264 是 p1。

⚠️ 这五张若走维护者手工 transfer,那条 Blocked-by: 会原样跟过去并继续挡着,要再点五次才能清。⇒ 这也是把它们放进重建组而非手工组的实质理由,⛔ 不只是评论数。

Filed by the triage seat (session_013hshVTmHY5F7rhpNtYHa3m, R+165) while healing the bare-card backlog. Ten of these cards were given a state label in that sweep; this card is the systemic question underneath them, ⛔ raised once rather than answered 22 times card-by-card.

Governing text: .claude/skills/pm-dispatch/SKILL.md 〈多仓协调〉 —— 规则 1:「issue 住在修复落地的仓,分诊时按判据严格执行」;判据:「正文抽掉 objectstack 还成立 ⇒ 当场转仓(console/UI 缺陷即转 objectui)」;回退条款:「transfer 不可用时重建:出处头 + 裸 #N 改全名 + 关源单为 moved」;缝卡条款:「目标仓不可达时按缝卡规则落 objectstack 带 repo:* + 具名读者」。

Measured, 2026-09-10T01:1xZ, on open non-PR issues

repo label carried by an open objectstack issue count
repo:objectui 25
repo:hotcrm 6
repo:cloud 6

Of the 25 repo:objectui cards, 3 are titled and shaped as genuine seam cards (#14831, #14837, #15140 — coordination content naming a reader). The other 22 are pure objectui defects, aged 41h to 251h, several priority:p1/p2, with reproductions and named landing points entirely inside objectui.

⚠️ The precondition the fallback rests on does not hold for objectui

The seam rule keeps a card in objectstack when the target repo is not reachable. That is true for hotcrm and cloud — measured this session, GET /repos/objectstack-ai/hotcrm ⇒ HTTP 403 — so those 12 cards are correctly placed.

⭐ objectui is reachable. This same session enumerated all 462 open objectui issues over the ordinary read path. ⇒ the 22 pure-UI cards are not seam cards and are not covered by the unreachability fallback; by rule 1's own criterion (remove objectstack from the body and it still stands) each of them should live in objectui.

What it costs today, stated plainly

The repo:objectui seat (#6025) is currently 🔴 vacant. When it is filled, a seat scanning objectui sees 462 cards and none of these 22 — including a priority:p1 console import defect confirmed by a downstream PM as blocking a delivered feature. They are not mis-labelled; they are in a repository that seat has no reason to scan.

Options × real cost

option what happens cost that is actually felt
A. Move the 22 to objectui (recommended) each card lands in objectui; the source card closes as moved ⭐ Cost depends on a fact only you can check — see below. Via the GitHub web UI's native Transfer issue, this is near-lossless and fast. Via the fallback this seat has (recreate + close), it is 22 create/close pairs and the comment threads on ~5 of them are lost. 17 of the 22 have zero comments.
B. Amend the convention — objectstack is the single board, repo:* cards live here and the objectui seat scans both repos zero migration; the 22 stay put and the rule changes to match reality every objectui query, forever, must union two repositories. Forgetting is silent — you see fewer cards, not an error. A new seat inherits an unwritten step.
C. New ones go to objectui, these 22 stay cheapest today split-brain by filing date. ⛔ Combines B's permanent two-home cost with A's migration cost, just deferred and made arbitrary.

业务含义直译

  • A = 「把放错仓库的工单搬回它该在的仓库,一次搬完。」
  • B = 「承认我们有两个收件箱,并要求每个人每次都记得看两个。」
  • C = 「以后放对,以前放错的就不管了」—— 半年后没人说得清一张卡该去哪找。

四轴论证(从业务立场)

  • ① 项目长远合理性 —— A 恢复不变量(一张卡一个仓),是缩小特例。B 把一个临时兜底(目标仓够不着)升格成常设规则,而它的前提在这个仓上根本不成立 —— 这是契约增生的典型形状:一条为例外写的规则被当成通则用。C 明确最差。
  • ② 实际业务拉动 —— 今天就有人撞上,而且是最坏的那种撞法:22 张有复现、有落点的缺陷卡对唯一能修它们的那个席位不可见。其中 Re-raise of #4375 with the downstream confirmation it asked for: the console import wizard never sends mappingName and hardcodes writeMode:"insert", so a named mapping's upsert can never reach a user objectui#10102 是 p1,由下游 PM 实测确认正在挡一条已交付功能。⛔ 这不是预测,是板面读数。
  • ③ 防 AI 犯错 —— A 给出闭合枚举:「objectui 的活全在 objectui」,一句话能验。B 要求每个 agent 每次都记得并两个仓,而忘了不会报错 —— 只是少看见几张卡,静默漏掉,正是最难发现的失效方向。
  • ④ 创业阶段不扩散 —— A 是一次性成本、做完就结束。B 是永久义务:每一个未来的席位、每一次查询都要背这条。创业阶段不该为一次搬家买一份长期税。

推荐 + 回退 + 置信缺口

  • 推荐 A。 四轴同向。
  • 回退 B,且只有在你判断 22 次搬运的操作风险高于永久的双仓查询成本时才成立。
  • ⚠️ ⭐ 置信缺口,而且它可能直接决定 A 的成本 —— GitHub 网页版有原生的 Transfer issue,可以保留评论与作者地把卡搬到同一 org 的另一个仓。这个 MCP 工具面上没有 transfer(本席实测:GitHub MCP 工具集里只有 create / update,无 transfer),所以本席的唯一手段是有损的「重建 + 关原单」。⇒ 如果你(或任何有仓库权限的人)能用网页版的 transfer,选项 A 的代价从「22 次有损重建」降到「22 次点击、零损失」,推荐强度显著上升。⛔ 本席无法验证你的权限,所以这条只能问你。
  • 其余未测:objectui 侧是否已有这 22 张的重复卡(未逐张查重);repo:hotcrm / repo:cloud 那 12 张不在本卡范围内(它们的不可达前提成立,放置正确)。

裁后执行

  • 裁 A ⇒ 若你用网页版 transfer:搬完后本卡关 completed,无需其它动作。若要走席位的重建路径:一张 pm:queue 卡给 skills 车道,逐张重建(出处头 + 裸 #N 改全名)并把原单关为 moved,先对 objectui 逐张查重。
  • 裁 B ⇒ 一张 pm:queue 卡给 skills 车道,改 SKILL.md 〈多仓协调〉规则 1,把「双仓收件箱」写成明文,并在 references/lanes/ 的 objectui 席章程里写死「扫两个仓」。⛔ 不留口头约定。
  • 裁 C ⇒ 同 B 的文本改动,外加一条明确的截止日期语义,否则它会退化成没人记得的现状。

os-decision-facets

  • ① 项目长远合理性:A 恢复「一张卡一个仓」的不变量(缩小特例);B 把「目标仓够不着」的兜底升格为通则,而该前提在 objectui 上不成立(契约增生)。
  • ② 实际业务拉动:今天就有人撞上——22 张有复现的缺陷对唯一能修它们的席位不可见,含一张下游 PM 实测确认正在挡功能的 p1。
  • ③ 防 AI 犯错:A 给闭合枚举(「objectui 的活全在 objectui」);B 要求每次并两个仓,漏了不报错、只是少看见卡——静默漏检。
  • ④ 创业阶段不扩散:A 是一次性成本;B 是压在每个未来席位和每次查询上的永久义务。

推荐:A(搬回 objectui)。
置信缺口:本 MCP 工具面没有 transfer,所以本席只能有损重建;网页版原生 transfer 可保留评论——你若有权限,A 的代价大幅下降,而本席无法验证这一点。另:objectui 侧未逐张查重;repo:hotcrm/repo:cloud 的 12 张不在范围内(不可达前提成立,放置正确)。


Related: the ten cards given a state label in the same sweep — objectstack-ai/objectui#10102 #14883 #14884 #14885 #14886 objectstack-ai/objectui#10110 #14888 objectstack-ai/objectui#10107 #14952 objectstack-ai/objectui#10109. Correctly-placed seam cards, ⛔ out of scope here: objectstack-ai/objectui#10437 #14837 #15140 (objectui), and all 12 repo:hotcrm / repo:cloud cards.


Generated by Claude Code

Activity

  1. added
    needs-user-decisionBlocked on a maintainer decision — do not dispatch; decision cards only, never on a PR
    domain:skillsDomain lane — seat card indexed by label:pm:seat
    on Sep 10, 2026
  2. os-litant commented on Sep 10, 2026

    @os-litant
    Contributor

    裁决(一类自裁 · 总监席第 21 场 session_01QVMnxyWBx8cAQMsV6akDV9 · 2026-09-10T08:1xZ):A —— 非缝卡的 repo:objectui 卡搬回 objectui

    通道:SKILL.md〈分诊座位职责〉一类自裁门,三判据逐条:

    • ① 权威机械定向:SKILL.md〈多仓协调〉规则 1「issue 住在修复落地的仓…判据:正文抽掉 objectstack 还成立 ⇒ 当场转仓(console/UI 缺陷即转 objectui)」;缝卡/重建条款的前提是目标仓不可达,而 objectui 本场同一会话可达(list_issues 全量枚举 + REST 200);pm-dispatch: a metadata project's cards, decisions included, live in its own repo; only platform problems are filed on objectstack/objectui #17315(维护者 2026-09-10 06:54Z 合入)同向——卡住在它自己的仓。
    • ② 失败方向响亮且一次可回:搬错的卡在 objectui 席位清单里立刻可见,网页 Transfer 可原路搬回。
    • ③ 四类地板零移动:纯流程,不触安全/契约/产品能力/门禁。

    四棱(沿卡面,本席复核同意):① 恢复「一张卡一个仓」不变量;② 有复现的缺陷对唯一能修的席位不可见(含 p1 objectstack-ai/objectui#10102、#16127);③ 闭合枚举「objectui 的活全在 objectui」优于「每次记得并两个仓」(漏了不报错);④ 一次性成本优于永久义务。⛔ 不裁 B / C。

    执行读数:本容器 GraphQL POST /graphql 403(只放行 PR-review 固定操作集),REST 无 transfer 端点 ⇒ 无损搬运只能走网页版 Transfer issue;席位重建是有损回退。本场 08:08Z 现读 label:repo:objectui open 26 张 = 3 张缝卡(#14831 #14837 #15140,留 objectstack)+ 23 张非缝卡:#17307 #16815 #16735 #16381 #16345 #16276 #16171 objectstack-ai/objectui#10108 #15260 #15259 objectstack-ai/objectui#10109 #15135 #14952 objectstack-ai/objectui#10107 #14888 objectstack-ai/objectui#10110 #14886 #14885 #14884 #14883 objectstack-ai/objectui#10102 #13751 objectstack-ai/objectui#10112(比卡面 01:1xZ 的 22 多一张 #17307,新入)。搬前请以 label:repo:objectui 现读为准。

    回退一字:若您不想在网页上点 23 次,回「重建」⇒ 本席改立一张 pm:queue 卡给 skills 车道走有损重建(出处头 + 裸 #N 改全名 + 关源单 moved,先对 objectui 逐张查重),本卡随之关闭。

    状态:needs-user-decision → pm:awaiting-maintainer(同笔;正文首行加 Maintainer-action:)。


    Generated by Claude Code

  3. added
    pm:awaiting-maintainerAwaiting a manual maintainer action — ruling already given; no dispatch, no machine exit
    and removed
    needs-user-decisionBlocked on a maintainer decision — do not dispatch; decision cards only, never on a PR
    on Sep 10, 2026
  4. os-litant commented on Sep 10, 2026

    @os-litant
    Contributor

    平台读数补充 —— 席位无法用程序转移 issue,本卡「代价取决于维护者是否能用网页版 transfer」这一句现在有确定答案

    分诊席,session_017VGfRocA8VjczSe84fgjY3(os-litant),R+166,2026-09-10T13:3xZ。⛔ 只补一条实测读数,不裁定、不改本卡状态标,推荐项与四棱块一字未动。

    本卡的代价评估挂在一个当时未测的前提上。本轮因另一张卡(objectui#8680)需要跨仓落地,顺手把它测了:

    • GraphQL 通道被拒(2026-09-10T13:2xZ,POST https://api.github.com/graphql),返回原文:"This GraphQL query is not enabled for this session — only the pinned set of PR-review operations is served."
    • GitHub 的 issue transfer 只有 GraphQL transferIssue 一条路,REST 无对应端点。
    • ⇒ **本容器里的任何席位都无法程序化转移 issue。**⛔ 不是配额问题、不是权限问题,是通道本身不开。

    对本卡的意义(⛔ 不构成裁定)

    选项 A(搬回 22 张)如果被裁定采纳,执行只能落在维护者的网页版 transfer 上,席位无法代劳,也无法分担。这把 A 的代价从「谁来点」变成了明确的「22 次人工操作,全部由你点」。

    ⚠️ 同时给出已实测可用的替代执行路,供你比较代价:本轮对 objectui#8680 走了 SKILL.md 规定的重建路径(出处头 + 跨仓引用改全名 + 关源单),产出 objectstack#17417。席位可以代跑这条路,它保留证据线程与全部引用,代价是每张卡换一个新号、原线程变成只读存档。

    ⇒ 你的选择实际上是:A(你点 22 次 transfer,卡号与线程原样保留) 对 重建(席位代跑 22 次,卡号变更、原线程留存为存档)。⛔ 本席不替你在这两者间选 —— 卡号与线程连续性值不值 22 次人工操作,是你的判断。

    本条只是把一个未测前提变成读数,让原来的推荐可以在确定代价上重新评估。


    Generated by Claude Code

  5. os-litant commented on Sep 10, 2026

    @os-litant
    Contributor

    ⛔ 更正本席上一笔(评论 5619150993)—— 它是多余的,而且框错了状态

    分诊席,session_017VGfRocA8VjczSe84fgjY3(os-litant),R+166,2026-09-10T14:1xZ。

    本席上一笔犯了它自己在别处反复引用的那个错:没有先读完本卡晚于正文的评论就落笔。 三处更正:

    1. 本卡不是「待裁」,已裁。 总监席第 21 场(session_01QVMnxyWBx8cAQMsV6akDV9)于 2026-09-10T08:13Z 以一类自裁通道裁定 A(评论 5615359689),本卡随即转入 pm:awaiting-maintainer,正文已带 Maintainer-action: 行。⇒ 上一笔里「如果被裁定采纳」「⛔ 不裁定」的措辞把一张已裁的卡写成了待裁,是错的。
    2. 那条「新」读数并不新 —— 本卡已经载着它了。 裁决评论的〈执行读数〉段逐字写着:"本容器 GraphQL POST /graphql 403(只放行 PR-review 固定操作集),REST 无 transfer 端点 ⇒ 无损搬运只能走网页版 Transfer issue;席位重建是有损回退。" ⇒ 本席测到的是同一件事,五小时后重测了一遍并当成新发现呈上。重测本身无害,把它当增量呈报是错的。
    3. 数字错了:是 23,不是 22。 现读 Maintainer-action: 行:"transfer every non-seam repo:objectui card (23 at 2026-09-10T08:08Z; re-read label:repo:objectui first)"。上一笔的 22 抄自 09-10T05:35Z 的收班简报,那是裁决之前的读数。⚠️ 该行本身还要求执行前重读 label:repo:objectui,所以 23 也不该被当成执行时的定数。

    ⇒ 本卡实际需要维护者做的,一字未变

    以 Maintainer-action: 行为准,⛔ 不以本席上一笔为准:网页版 Transfer issue 搬非缝卡,完成判据是 objectstack 的 open repo:objectui 集恰好剩 objectstack-ai/objectui#10437 / #14837 / #15140 三张缝卡;回退是回覆「重建」,由总监席开 skills 车道卡走有损重建。

    ⭐ 上一笔唯一还站得住的部分,保留:本轮对 objectui#8680 实跑了一次重建路径并产出 objectstack#17417,所以那条回退路现在有了一个已执行过的先例可参照,而不只是纸面选项 —— 代价形状(新卡号、原线程转只读存档、引用改全名)是实测的。

    ⛔ 本笔不改任何标签、不动 Maintainer-action: 行、不重裁。


    Generated by Claude Code

  6. os-litant commented on Sep 10, 2026

    @os-litant
    Contributor

    ⛔ 二次更正 —— 上一笔(5619335171)自己的时刻戳是错的

    分诊席,R+166,2026-09-10T13:22Z(本次时刻与本条评论出自同一次工具调用,⛔ 不是估算)。

    上一笔是一条关于「读数要准」的更正,而它自己把时刻写成 14:1xZ;实际发出时刻是 2026-09-10T13:19Z,偏 56 分钟。同一轮里本席共有 15 处时刻戳是估算出来的、偏 15–56 分钟不等,越到后面偏得越多 —— 本席在开轮时读了一次时钟,之后一路外推,没有再读。

    ⚠️ 受影响的只有「取数时刻」,⛔ 不含任何判据。 本卡上一笔引用的三件事都是命令输出或卡面现读,逐条复核后不变:GraphQL 403 的原文、Maintainer-action: 行的 23、裁决评论 5615359689 的存在与内容。⇒ 结论一字不改,错的是时间。

    ⭐ 修法按「先删容许出错的构造」:本席自本条起,时刻戳与写评论出自同一次工具调用,⛔ 不再有「先记下一个时刻、随后凭它写」的中间态 —— 那个中间态就是出错的构造本身。全轮的逐条更正落在座位贴 #6015 的本轮收尾简报里,⛔ 不逐卡刷 15 条评论。

    ⛔ 本笔不改标签、不动 Maintainer-action: 行、不重裁。


    Generated by Claude Code

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

    domain:skillsDomain lane — seat card indexed by label:pm:seatpriority:p2Medium: important, M3

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions