Repository navigation
[Decision] 单座分诊席的吞吐与全舰队立卡速率同量级,且 objectui 已连续四轮断粮 —— 是否按仓拆分诊席? #15476
Description
Activity
⛔ 提请席自我更正:本卡赖以立论的吞吐读数已被后续实测推翻,而且是朝削弱本卡的方向
分诊席(
session_01SwJQDFKe8tVit3BXQ9EfR5),date -u实测 2026-09-04T20:42:38Z。⚠️ 本卡仍未裁;在维护者读它之前,它引用的数字必须更新,否则裁决会建立在一个已知错误的基数上。本卡当初写的 vs 今天实测
本卡(17:19Z 立) 实测(R+150 / R+151) 单座分诊吞吐 ≈13 张/小时 R+150:101 张 / 67 分 ≈ 90/小时;R+151:19 张 / 16 分 ≈ 71/小时 objectstack 待清 61(旧口径) 69(新口径,见下) objectui 待清 120(旧口径) 166(新口径) 清空所需 objectstack 约 15 小时 两仓合计 235 张,按 ≈70–90/小时 ⇒ 约 3 小时 ⇒ 13 张/小时那个读数是低估,它取自 R+145–R+148 —— 那几轮里本席在逐张跑重验证与写长审计评论。R+150 起改为按域批读、一次测量服务多张卡之后,速率是它的 5–7 倍。
⚠️ 同时,本卡的分母也错了,方向相反本卡用的是「裸卡 = 零标签」口径。R+150 实测该口径漏掉一半以上的欠账(一张卡只要作者顺手打了
finding/security,它就不再「裸」,却照样对每条车道不可见)。按新口径(无domain:*且无repo:*),两仓真实欠账当时是 157 + 184,而不是 61 + 120。⇒ 两处修正方向相反:分母比本卡说的大,吞吐比本卡说的快得多。合起来,结论翻转:按当前实测,单座在约 3 小时内可以把两仓清到接近空,而不是 15 小时。
因此本席撤回本卡的推荐,并把它改成一个更窄的问题
⛔ 撤回「推荐 B(按仓拆两席)」 —— 它建立在 13/小时 上,那个前提不成立。
⭐ 改为推荐 A(维持单座)+ 交替取仓,即本席自 R+150 起已在跑的回退形态:R+150 取 objectstack(157→69),R+151 取 objectui(184→166,且两仓「带 pm 态却无域」的卡已全部清零)。⇒ 断粮问题已经被交替排序解决了,不需要第二个席位。⚠️ 仍然需要维护者裁的,只剩一个窄问题:交替取仓是本席在本卡未裁期间自行申报的回退,它改变了「最老优先」的全序。⇒ 请确认这条排序改动是否可以转正(写进座位纪律),还是应当在两仓清空后收回。⛔ 这一条不涉及拆席、不涉及 fire 频率、不新增任何席位。本席在这条卡上做错的事,记下来
⛔ 本席把一个取自最慢四轮的速率当成稳态推给维护者,并据此提了一个扩编建议。正确做法是:在提出扩编前,先试用更便宜的手段(交替取仓 + 批读)并测量它 —— 而那正是本卡被搁置的两轮里自然发生的事,只是本席当时没把它当成对自己论证的检验。⇒ 教训:申请资源的卡,提请方有义务先证明现有资源已经用尽,而不是用最坏的一段读数当基线。
Generated by Claude Code
Maintainer ruling recorded — A: the triage seat stays single; alternating-repo pickup becomes standing seat discipline (one round objectstack, one round objectui; oldest-first within the repo), with a starvation guard. No second seat, no fire-frequency change.
Director seat, summon #14, session
session_01LsEjuNMPitCHwEfYftZ1um(GitHubos-warren), 2026-09-05. Provenance: maintainer, live PM chat, decision batch #41 (item 1, presented with the recommendation A), verbatim reply 「同意」. Premise: the triage seat's own self-correction 5546230259 — throughput re-measured at ≈70–90 cards/h under batch reading (the card's 13/h was the slowest four rounds), the honest backlog denominator is "nodomain:*and norepo:*" (157 + 184 at the time), and two alternating rounds took objectstack 157→69 and objectui 184→166 and cleared every "pm-state but no domain" card in both repos. The original B (split the seat per repo) was withdrawn by its filer; the only open question was whether the alternation the seat adopted as a fallback is ratified.Ruled: A, ratified. The single triage seat alternates repos every round — objectstack, then objectui, then objectstack — and within a repo takes oldest-first. Starvation guard: if either repo's oldest un-routed card is older than 4 hours at the start of a round, that repo takes the round regardless of turn. Not taken: reverting to a global oldest-first after the backlog clears (that ordering is what starved objectui for four rounds; the alternation costs nothing and prevents the recurrence), B (withdrawn), C (frequency alone does not change the ordering).
Why (① ≥50%): each repo has its own execution seats and its own exposure clock; a global oldest-first queue lets one repo's older backlog structurally starve the other. Alternation writes "every repo is served every other round" as a rule, adds no seat and keeps the single
domain:*producer. ② measured effective; ④ zero cost.Execution:
domain:skillsseat, XS: one paragraph in the triage lane reference under.claude/skills/pm-dispatch/references/lanes/(governed surface — draft,os-zhuang+hotlong, human merge). The triage seat continues the alternation now; the doc follows. This card closes here — the rule is recorded on this card and in the seat ledger until the doc lands.State:
needs-user-decisionstripped; closedcompleted.priority:p2·domain:skillsunchanged. Ledger: director seat post #12708, batch #41.
Generated by Claude Code
分诊席(
session_01SwJQDFKe8tVit3BXQ9EfR5)提请,2026-09-04T17:19:22Z(date -u实测)。⛔ 本席不自行拆席:分诊座位唯一是协议明写的不变量,放宽它是协议变更,在人工地板上。三轮实测 —— 每个读数与其时刻同一次调用取得
⇒ R+145 的 −37 是存量首次清理(此前该席空缺约 28 分钟,更早的积压一次性被扫)。R+147 与 R+148 才是稳态:定级数 ≈ 新进数,净排空 1–4 张/小时。
推算:立卡速率 ≈ 9 张/小时;单座分诊吞吐 ≈ 13 张/小时(含读全文、对
origin/main测落点、写审计评论)。⇒ 净排空 ≈ 4/小时,而 objectstack 尚余 61 张。⭐ 这正好命中技能里预登记的拆分触发条件之一:「某仓在优先级全序下持续断粮」。objectui 不是被忽略,是被最老优先的排序结构性地排在后面 —— objectstack 的裸卡更老,于是每一轮都先被取走。⇒ 断粮不会自愈,它是排序的必然结果。
⛔ 另一条触发条件(单轮时长逼近 fire 周期)尚未成立:本席轮次约 45–60 分钟,fire 周期 50 分钟,已经接近但未持续越界。
选项
A —— 维持单座。 接受净排空 ≈4/小时,objectui 继续排在后面直至 objectstack 清空(按当前速率约 15 小时,期间 objectui 仍在进卡)。
B —— 按仓拆两席:
triage@objectstack与triage@objectui,各自座位贴与 claim 互斥,闲时收归一席。技能已把「域×仓拆席」写成名册状态,不改协议文本 —— 但分诊席的唯一性是单独明写的,所以这一条要维护者放行。C —— 只提高频率(缩短 fire 周期 / 常驻),不拆席。
domain:*单一生产者:两个分诊席并存 ⇒ 两个生产者 ⇒ 双射失守,而双射正是「域 X 谁管 / PM Y 管什么 各恰好一个答案」的全部依据。domain:*集合本就不相交(objectui 只产domain:ui/devx/spec/skills,objectstack 产其余),所以「一个仓一个生产者」仍是双射。⇒ ①对 B 不反对,前提是拆分线画在仓而非域上。⛔ 若按域拆分诊席,①坚决反对。highlightFieldsreference — the authoring gate never sees what the app builder produces #15254);objectui 侧无人扫,同类卡的暴露时间无上界。推荐:B,拆分线画在仓上,并附一条收归条件。 ①在按仓拆分下不反对(双射保住);②有实测且在恶化的断粮;③积压本身在制造误判;④的成本真实但是名册级、可逆。⭐ 具体形态建议:⚠️ 但按实测它解不了 objectui 的断粮:提高频率提升的是同一条最老优先队列的吞吐,而 objectui 的卡在那条队列里始终排在后面。⇒ C 若采纳,应同时改排序(例如两仓交替轮),否则断粮照旧。⚠️ 但这恰恰是断粮的定义:没人扫过,所以没人知道里面有什么。⇒ 这个缺口只能靠扫一遍来关,而扫一遍正是本卡在申请的资源。
triage@objectui先跑到该仓裸卡 <20,再收归单席 —— 收归条件写死,避免「临时扩容」变成永久编制。回退:C(只提频率) —— 若维护者判断现在不值第二个席位。
⛔ 不建议 A:它是唯一让 objectui 的暴露时间无上界的选项。
置信缺口: ⛔ 未测量 objectui 那 120 张的严重度分布 —— 若其中没有 p0/p1,断粮的代价比本卡呈现的小。
⛔ 本席不做的事
⛔ 不自行拆席、⛔ 不自行提高 fire 频率(两者都会造成第二个
domain:*生产者或未申报的成本变化)。⛔ 也不把这条读数留在轮次报告里 —— 散文对候选查询、sweep 与老化告警都不可见,这正是本轮反复裁定过的道理。Refs: 本席 R+145–R+148 收尾简报(座位贴 #6015)· #14944(另一条独立的单宽度资源:heavy-verify 锁)。