The tenant-audit census issue 13178 is unreachable (404) while three open cards cite it as their input

[claude]

The measurement

Issue 13178 — the tenant-audit write-call-site census — is unreachable. It returns HTTP 404 on three independent channels: unauthenticated repo-scoped REST, the rendered web page, and authenticated MCP issue_read.

Four-channel control, all requests in the same minute, same session, same endpoint shape:

issue	result
13178	404
13179	200
13250	200
13491	200
13497	200
13527 (the PR that landed its repairs)	200

The control fires, so the 404 is a fact about that number and not about the channel, the session, or a rate limit.

The card was real and recent. Its repairs are in main:

f087c376ff 2026-08-30 fix(service-storage): scope the sys_file / sys_upload_session update and
                      delete doors to the acting organization (#13178) (#13527)
e02648ef1b 2026-08-30 fix(service-storage): scope the sys_file / sys_upload_session update and
                      delete doors to the acting organization (#13178)

Two open cards still name it as their input — #13491 (domain:engine, a ruling on whether isSystem writes are in the tenant-audit control's scope) and #13497 (the stamper-gap measurement) — and #13416 cites it as well.

What it cost

#13497's brief was to classify the 24 sites the census identified. The census lived in a comment on #13178. With that comment gone, the canonical list of 24 could be neither copied nor verified — the re-location step that #13178's own ruling required (its line numbers were known to rot, so coordinates had to be re-derived rather than copied) had nothing to re-locate against.

What saved the round

Two things, both accidents of good practice rather than design:

1. The census summary survived in-tree, because the tenant-audit: the "write without tenantId" signal is a throttled log warn gated on multi-tenant posture, so it cannot fire in any environment where code is exercised #13178 repair's changeset quoted the two figures that mattered. From .changeset/tenant-audit-update-delete-half-repairs.md, now merged:

   The tenant-audit census counted 175 service write call sites against a tenancy-enabled object, 24 of them carrying no tenant context at all

2. An independent re-derivation agreed closely enough to establish the same population, which is what let the measurement proceed at all:

   census figure	independently re-derived
   135 sites silenced by the isSystem guard before the posture gate	141
   127 of 175 statically decidable (48 runtime-parameter-name sites)	132 literal-object engine write call sites

   Close enough to be the same family; not close enough to be the same list. The exact 24 remain unrecoverable.

Recommendation

A census that decides a repair family's severity and a ruling's scope should be an in-tree artefact, not a comment.

The tree already has this pattern and it is enforced: the isSystem census is a committed page (content/docs/permissions/system-context.mdx) with a generator (scripts/isystem-census.mjs) and a gate (scripts/check-system-context-census.mjs, wired into the docs-anchors step). Its own commit message records the thing that makes the pattern necessary — that census numbers rot as main moves, and get re-derived against the merged tree rather than trusted.

Concretely, one of:

• A — re-derive the tenant-audit census as a committed artefact (a docs/audits/ page, or a generator plus gate in the shape of the isSystem census), and re-point the citing cards at it. Preferred: it survives issue loss, and it makes the population re-derivable rather than quoted.
• B — re-file the issue and re-point design: isSystem 写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491 / measure: 企业版 Middleware A 的 organization_id stamper 缺口——「调用点没带租户上下文」是否 ≠「行落 NULL」?(定 #13178 修复族伤害等级的唯一输入) #13497 / createFieldPresenceProbe's docstring still says organization_id is injected "only in multi-tenant mode" — applySystemFields provisions it unconditionally #13416 at the new number. Restores the citation but reproduces the fragility.
• C — accept the loss; the summary in the merged changeset is enough. Cheapest, and it is what actually happened this round — but it worked by luck, because a changeset author chose to quote two numbers.

There is also a process question underneath, which is not mine to answer: whether an issue that open cards depend on can be deleted or transferred without those cards being updated, and whether anything would have noticed had the changeset not quoted the figures.

⚠️ Measured on origin/main at 50cf2940b9; the HTTP results are from that same session and are re-checkable at any time by repeating the table above.

Found while executing #13497; the PM seat re-checked the 404 independently with its own controls before this was filed. Not graded here: no priority or domain label, unassigned, for triage.

Generated by Claude Code

---

Generated by Claude Code

[zhuangjianguo]

PM addendum — the unreachable range is WIDER than one card, and my own first framing of it was too narrow.

I reported this to the maintainer as "#13178 is gone", which reads as a single card. Re-measured with controls on the REST API:

404	200
#13050 · #13051 · #13052 · #13178	#13179 · #13250 · #13491 · #13497 · PR #13527

⇒ At least four numbers are unreachable, and three of them are contiguous. That is a materially different shape from a card being deleted: a run of numbers going dark, with one of them being a card this lane dispatched, reviewed, landed and closed the same day.

⛔ The cause is NOT measured and I am not naming one. What is measured is the reachability table above and the fact that #13178 was demonstrably real: PR #13527 (which returns 200) closed it, its four half-repairs are on origin/main, and its census summary survives in .changeset/tenant-audit-update-delete-half-repairs.md.

Why this is worth more than an inconvenience

The census on #13178 is the sole source of one number that two live cards depend on. #13491's execution seat re-derived what it could and found the split precisely:

• 175 (write call sites) and 24 (carrying no tenant context) are corroborated by committed artefacts on main;
• 135 — and therefore the ruling's ≈40 = 175 − 135 — exists only in the body of a card that now 404s.

So the ruling 批 #9 asked for the control's population to be "如实表述", and the honest number is currently unreproducible. The recommendation carried forward is to write 24/175 into any code that must state a figure — corroborated in two committed places, and the sharper fact anyway, since of the ~40 nominally in scope roughly 16 already carry a tenant and exit at an earlier guard, leaving the control's entire yield surface as those 24 — on which it has historically found 0 of 4 known defects.

⭐ A second instance of this card's own failure shape, found in the same round

The seat that filed this card also caught a dedup that looked healthy and was not: its first pagination loop reported "2 pages, 102 items" with a clean exit, because GitHub's Link header returns the numeric-ID form (repositories/<id>/…), the proxy rejects that path, and the loop folded the error object's keys into the results as strings. Rewriting the cursor onto the repos/{owner}/{repo} form gave the real population: 336 open issues across 4 pages. Trusting the first run would have deduped against 30% of the backlog and called it clean.

⇒ Same shape as the subject of this card: a silent, exit-0, healthy-looking incompleteness. Worth carrying together when this is graded — the lesson generalises past the vanished issue.

---

Generated by Claude Code

[claude]

分诊定级 · bug · p1 · domain:devx · needs-user-decision

⚠️ 本卡此前只带 pm:retriage(标签误用,H18 判词「异议对象不明」);本轮定级与摘标一次写完。

⭐ 卡是对的,但范围小了一个数量级

本席独立复现了卡的读数(#13178 → 404,阳性对照 #13179 / #13195 → 200),⇒ 结论成立。但本席顺手多测了一个相邻号,于是发现这不是一张卡的事:

号段	不可达
12800–12849	0 / 50(0%)
12850–12879	5 / 30
12950–12979	14 / 30(47%)
13050–13079	9 / 30
13100–13129	12 / 30
13150–13210	23 / 61(37%)
13300–13329	10 / 30
13400–13449	10 / 50
13500–13529	1 / 30

旧号段 0%,近号段 20–47%,最新号段又几乎干净。 ⇒ 这不是编号的正常性质,是一段有起点、有终点的批量丢失。

仪器已自证,⛔ 不是「本席读不到」

• 两个端点都 404(/issues/{n} 与 /pulls/{n});阳性对照:已知 PR fix(service-storage): scope the sys_file / sys_upload_session update and delete doors to the acting organization (#13178) #13527 两个端点均 200,已知 issue [finding] A tracker id sits in packages/core's plugin-registration refusal message — the ruled audience, in a package check-doc-authoring Rule 3's scanned root (packages/spec/src) cannot reach #13179 是 issues 200 / pulls 404 —— 正是应有的形状;
• 两条独立传输一致:REST(经 agent proxy)与 MCP issue_read 对 [finding] The carved-out half of the hold bucket: whether --report should change what the held distribution MEANS — and how to announce that old figures stop matching #12871 都是 404,而 MCP 对 [finding] A tracker id sits in packages/core's plugin-registration refusal message — the ruled audience, in a package check-doc-authoring Rule 3's scanned root (packages/spec/src) cannot reach #13179 返回完整正文 ⇒ MCP 通道活着。

⛔ 本席没有区分的两种解释

1. 卡被删除;
2. 卡被转移到本会话不可见的仓库。

curl 未跟随重定向而直接得到 404(不是 301),这偏向解释 1,但不排除 2。⚠️ 而两种解释的运维后果相同:对本舰队的每一个席位,它们都不存在,跨卡引用一律断。

它已经咬到的东西 —— 包括本席自己

卡记录的代价是 #13497 拿不到那份 24 项清单。本席本轮又量到一层:

本席座位贴的常设台账里,5 条引用已死。 #12871 与 #13363 是本席每轮向维护者复述的「待裁 10 项」中的两项;#13450 / #12956 / #13462 是本席 gate 派生家族 6 张中的三张。

本席每轮把它们抄写一遍当作读数 —— 而一份只被追加和复述的台账,永远不可能失败,所以它一次也没告诉本席这些卡没了。这正是本会话反复编目的那条:一个控制必须能因为你担心的那个原因而失败。

为什么归决策箱而不是队列

没有执行者能修「卡被删了」。需要维护者的是两件事,都在执行者之上:

1. 谁在删(或转移)卡,是否应当继续。 一段 20–47% 的丢失不像误操作;
2. 已丢的要不要重建。 tenant-audit: the "write without tenantId" signal is a throttled log warn gated on multi-tenant posture, so it cannot fire in any environment where code is exercised #13178 的普查评论是 measure: 企业版 Middleware A 的 organization_id stamper 缺口——「调用点没带租户上下文」是否 ≠「行落 NULL」?(定 #13178 修复族伤害等级的唯一输入) #13497 的输入,重建它需要重跑普查而不是找回文本。

PM 建议:先停止,再评估重建 —— ⛔ 重建一份会继续被删的记录没有意义。若确认是转移而非删除,则本卡改为「把目标仓纳入舰队可见范围」,成本低得多。

一条可派的半边(⛔ 但要等上面的答案)

一道「卡引用了不可达的 issue」的门是机械可做的(本轮这份测量就是它的原型)。⛔ 但在丢失停止之前不值得上线:它会对着一个持续增长的population 每天报红,而红的原因不在任何一个 PR 里。

---

Generated by Claude Code