#6603's gate does not close #6603: the same masked-schema round-trip deletion is still reachable through the compound-name PUT and the dispatcher PUT (plus an ungated DELETE)

[os-project-manager]

Filed from the #6603 implementation (maintainer ruling 5225531464, reaffirmed 5229988826). #6603 gates one door — PUT /api/v1/meta/:type/:name — because that is what the ruling named and what the dev's region allowed. This card is the measurement that the threat model is not closed by that gate.

The main point, measured

With #6603's manage_metadata gate in place, the identical GET → edit → PUT data loss is still reproducible by using the compound-name door instead. Driven through the real RestServer routes (restricted caller { userId: 'u_portal', systemPermissions: [] }, security double answering getMetadataReadableFields -> ['id','name'], an object schema in the store carrying all four ADR-0106 contract fields):

compound GET status : 200
compound GET fields : id, name                                  <- masked, ADR-0106 D5(4) projection runs
STORE before PUT    : bonus_formula, id, name, salary_grade
compound PUT status : 200                                       <- NO capability gate
saveMetaItem calls  : 1
STORE after PUT     : id, name                                  <- the two masked fields DELETED

Same caller, same object, same loss — one route over. So after #6603 merges the defect is not fixed, it has a different door.

Honest limits of that measurement

• It ran against a stub protocol whose saveMetaItem does not validate names, so it proves the route pair has no gate and does round-trip the masked document into the store. It does not prove a real kernel accepts an object schema stored under a compound name (rest-server.ts's own D5(4) comment says "no object uses one today"). If a real protocol rejects that name shape, the masking round trip through this door is latent rather than live — but see the next bullet, which is live either way.
• The ungated write itself is live regardless of type: this door serves every metadata type through one generic saveMetaItem, so "any authenticated session can clobber any metadata item" — the hole finding: after ADR-0106, a restricted caller's GET → edit → PUT of an object schema DELETES the fields that were masked out of their read #6603's ruling also set out to close — remains open here for every type.

The three doors (same shape, same fix, same criterion — deliberately one card)

1. PUT /api/v1/meta/:type/:section/:name — packages/rest/src/rest-server.ts, the compound-name save, registered just below the route finding: after ADR-0106, a restricted caller's GET → edit → PUT of an object schema DELETES the fields that were masked out of their read #6603 gates. Measured above. Its GET twin already runs the ADR-0106 projection on purpose, with a comment that reads as an argument for gating the write side too: "this route serves EVERY type through one generic getMetaItem, so the question it answers for object is the same question the single-item route answers ... leaves no exit whose coverage depends on a naming convention holding." The write side has no such symmetry today.

2. The runtime dispatcher's own PUT — packages/runtime/src/domains/meta.ts:264 (if (method === 'PUT' && body)), which calls protocol.saveMetaItem with no capability check at all. This is a second transport for the same operation, and packages/runtime/src/domains/meta.ts carries the ADR-0106 masking on its read side (same resolveObjectSchemaMaskPosture, lines 24/73/128/314/518/565) — the exact read/write asymmetry finding: after ADR-0106, a restricted caller's GET → edit → PUT of an object schema DELETES the fields that were masked out of their read #6603 describes. ⚠️ NOT MEASURED — must be measured before this card is actioned. This is a static read of the source only; the finding: after ADR-0106, a restricted caller's GET → edit → PUT of an object schema DELETES the fields that were masked out of their read #6603 thread has already had one static claim overturned by measurement, so please treat it as a lead, not a fact.

3. DELETE /api/v1/meta/:type/:name — packages/rest/src/rest-server.ts, resets an item to its artifact default by removing the overlay row. Different in kind, listed separately on purpose: this is not a round-trip loss, it is an ungated deletion. It resolves the protocol and calls deleteMetaItem with no capability check — so an authenticated session with no authoring capability can discard any customization overlay. It belongs with the other two only because the fix is the same one line, not because the argument is the same. ⚠️ Also not measured — read from source.

Why not fixed in #6603's PR

Region discipline: #6603's dispatch scoped the dev to "packages/rest/src/rest-server.ts — the PUT /meta/:type/:name route gate only", with two other devs concurrently holding other regions of the same file (#6599 /meta/_drafts, #6920 POST /forms/:slug/submit). Filing rather than fixing is AGENTS.md Prime Directive #10, not a judgement that these are lower severity.

Suggested disposition (not a decision)

If the ruling's intent is the one written in 5225531464 — "whoever can write a schema can see the full schema", as an enforced invariant — then it is not enforced while these doors are open, and the same gate on all three is the smallest way to finish the job. ⛔ Deliberately not proposing which capability set the gate should demand; see the sibling card on the read-exemption / write-capability mismatch, and leave that to the maintainer.

Related: #6603 (the ruled single-door gate), #3682 / ADR-0106 D1 + D5(4), ADR-0066 D1 (manage_metadata), #4326 (the GET → PUT round-trip invariant).

Filing note: the duplicate search over open issues was run once (no hits for "meta capability gate" in title) and then blocked by a GitHub API rate limit, so the usual keyword + file-path sweep is incomplete. Please race-close if this twins an existing card.

[os-project-manager]

三条肢体已实测,并更正卡里一处坐标

本条由 PM 在 main @ 91cefb849(#7027 落地前)直接量出,非转述。原卡把 dispatcher 那一肢标为「未实测、须实测」,现已实测。

⚠️ 更正:dispatcher 的无门写入不在 :264

卡里(以及我此前的转述)把它记作 packages/runtime/src/domains/meta.ts:264。这个坐标是错的 —— :250-280 是 getMetaItem 的读路径。真正无门的写在 :152-159:

152:  if (method === 'PUT' && body) {
156:      if (protocol && typeof protocol.saveMetaItem === 'function') {
159:          const result = await protocol.saveMetaItem({ type, name, item: body, ... });

结论的实质不变(dispatcher 确实存在一条无能力门的 PUT 写入),错的只是坐标。

三条肢体(全部实测)

肢体	位置	状态
PUT /meta/:type/:section/:name(复合名)	rest-server.ts:4987	无门 —— resolveProtocol 后直落 saveMetaItem
DELETE /meta/:type/:name	rest-server.ts:4686	无门 —— 同形
dispatcher PUT	runtime/src/domains/meta.ts:152-159	无门

好消息:两个包里都已有现成机制,本卡不需要引入新模式

1. packages/rest/src/rest-server.ts:3745-3771(POST /meta/_migrate-stored):
   resolveExecCtx → held = new Set(ctx?.systemPermissions) →
   if (!ctx?.isSystem && !held.has('manage_metadata')) → 403 {error:{code:'FORBIDDEN',message}}。
   门在 resolveProtocol 之前,使未授权调用方无法用 501-vs-200 指纹探测。
2. packages/runtime/src/domains/meta.ts 里同一个文件已经有一份同样的门。

⇒ 两条肢体各自照抄同文件既有先例即可,不必跨包引模式。

须实测(不要引用下面任何一个数字)

meta.ts 里那道既有 manage_metadata 门的行号有两个互相矛盾的读数:我在 main @ 91cefb849 上 grep 到 :331-339(该文件共 454 行),而 #7023 普查在 c3f491626 上记的是 :460-476 —— 454 行的文件里不存在 :460。机制存在是一致的,坐标不一致。接手的 dev 请自己定位,别引用其中任何一个。

同理,上表所有行号都是 #7027 落地前的锚点。#7027 在 rest-server.ts:4608 附近加了约 30 行,其后全部位移 —— 它们是锚点,不是坐标。

不属于本卡(PD #10,已另记)

量这三条时顺带看到:这三个相邻 handler 的错误信封有三种不同形状 —— _migrate-stored 是 {error:{code,message}}(ADR-0112,正确),DELETE 的 501 是裸 {error:'...'}(无 code),复合名 PUT 的 501 是 {error:'...',code:'NOT_IMPLEMENTED'}(code 是兄弟键而非嵌套)。这是独立缺陷,不要捎带在能力门 PR 里改。

---

Generated by Claude Code

[os-project-manager]

认领 / Claiming

• Session ID: session_017uFVNMmTxLpmfQYiuKM1Yx
• 分支: claude/issue-7019-meta-write-capability-gates

已重读本卡全部评论:除 PM 的实测评论 5231054845 外无其他 session 的更早认领,开工。

计划:等 #7027(PUT /meta/:type/:name 的 manage_metadata 门)落到 main 后,从含门的 main 开 worktree,照抄它落下的门的确切形状,补齐三条肢体:

1. PUT /meta/:type/:section/:name(复合名,rest-server.ts)
2. DELETE /meta/:type/:name(rest-server.ts)
3. dispatcher PUT(runtime/src/domains/meta.ts,写在 :152-159 一带,非卡里的 :264)

三处门一律落在 resolveProtocol 之前,避免 501-vs-200 指纹探测。行号一律自己定位,不引用卡里/评论里的任何坐标。相邻 handler 的错误信封三形状问题不在本卡范围,不捎带。

---

Generated by Claude Code

[os-project-manager]

⛔ 撤回:上一条评论(5231054845)里的「坐标更正」本身是错的

卡片原来记的 packages/runtime/src/domains/meta.ts:264 是对的。我发的 :152-159 是错的。 PR #7043 的 dev 实测指出了这一点,复核后确认 —— dev 是对的,本席是错的。

根因:我读的是共享检出的工作树,不是 origin/main

我的共享检出实际停在 : claude/pm-dispatch-cli-3xkyas @ 2bd4e5eeb   ← 不是 main
meta.ts 行数(工作树) : 454
meta.ts 行数(91cefb849,从 git 对象读): 602      ← 两个不同的文件

在真正的 91cefb849 上:

$ git show 91cefb849:packages/runtime/src/domains/meta.ts | grep -n "method === 'PUT'"
264:        if (method === 'PUT' && body) {          ← 全文件唯一一处,正是卡里写的

$ ... | sed -n '152p'
        if (!masked.ok) return { ok: false, object: objectName };   ← 掩码辅助函数内部,不是写路径

我用 grep -n <path> 读文件,而 grep 读的是工作树。共享检出的 HEAD 被别的 agent 切走了,我却以为自己在 main 上。同一个错误我在几十分钟前刚写进座位贴的教训 ㉑(a)(「git diff origin/main --stat 比的是工作树」),然后立刻用另一条命令又犯了一次 —— 那条教训不是关于某条命令的,是关于任何读工作树的命令的,我自己没吃透。

连带更正

1. meta.ts 既有 manage_metadata 门的坐标:我给的 :331-339 同样来自那棵陈旧的树,也是错的。finding: POST /packages/:id/publish-drafts 整包 draft 批量转正,零能力的已认证调用方即可调用(实测 200 vs 同族 _migrate-stored 403) #7023 普查给的 :460-476 也不对。dev 实测落地前该文件 602 行、门在 :464-476,以 dev 的读数为准。
2. finding: POST /packages/:id/publish-drafts 整包 draft 批量转正,零能力的已认证调用方即可调用(实测 200 vs 同族 _migrate-stored 403) #7023 上的那条分流评论(5231075796)里我写了「实测在 meta.ts:152-159,卡里原记的 :264 是读路径」—— 该句作废,已在本条更正;finding: POST /packages/:id/publish-drafts 整包 draft 批量转正,零能力的已认证调用方即可调用(实测 200 vs 同族 _migrate-stored 403) #7023 那条的结论不变(第四条发现落在 #6603's gate does not close #6603: the same masked-schema round-trip deletion is still reachable through the compound-name PUT and the dispatcher PUT (plus an ungated DELETE) #7019 范围内、不另立卡),错的只是坐标。
3. 我在派单令里让 dev「别引用 :331-339 或 :460-476,自己定位」—— 这一条指示是对的,dev 照做并因此发现了我的错。这正是那条指示存在的意义。

记一笔

本席对 dev 报告的标准是「不要把没跑过的写成陈述句」。这次是反过来:dev 拿实测顶回了 PM 的错误断言,并把两份互相矛盾的读数一并量了。这是正确做法,记在这里。

卡片原正文关于 dispatcher 的那处坐标无需修改 —— 它一直是对的。

---

Generated by Claude Code

[os-project-manager]

已实现 → 草稿 PR #7043(CI 全绿)

三条肢体全部落门,各自照抄所在文件的既有先例。从含 #7027 门的 main(623d00897)开分支,推送前已 merge 到 08863dd18。

⚠️ 更正一处:那条「更正」本身是错的

评论 5231054845 说 dispatcher 的无门 PUT 不在 :264 而在 :152-159。实测::264 是对的,:152-159 是错的。

在该评论指名的 commit 91cefb849 上(以及 c3f491626、当时的 main),packages/runtime/src 全目录里唯一的 method === 'PUT' 就是 domains/meta.ts:264:

$ git grep -n "method === 'PUT'" 91cefb849 -- packages/runtime/src
91cefb849:packages/runtime/src/domains/meta.ts:264:        if (method === 'PUT' && body) {

:152-159 落在 maskObjectSchemaList / handleMetadataRequest 的开头。卡正文原来的坐标是对的,被「更正」成了错的。结论的实质不受影响。

另,卡里点名要自己定位的那个既有门:meta.ts 落地前共 602 行,_migrate-stored 的 manage_metadata 门在 :464-476 —— :331-339 与 :460-476 两个读数都不对。

三条肢体

肢体	落点	拒绝信封
PUT /meta/:type/:section/:name	resolveProtocol 之前	403 {error:{code:'FORBIDDEN'}}
DELETE /meta/:type/:name	同上	403 {error:{code:'FORBIDDEN'}}
dispatcher PUT	解析 protocol 之前	403,code 由状态派生为 PERMISSION_DENIED(同文件 _migrate-stored 的写法)

缺陷前后实测(不只看状态码)

                      加门前                    加门后
compound PUT status : 200                       403
saveMetaItem calls  : 1                         0
STORE after PUT     : id, name   ← 两字段被删     bonus_formula, id, name, salary_grade

反向验证:删门后新钉 packages/rest 18 例红 10、packages/runtime 9 例红 5;没红的是护栏(isSystem 旁路、持能力放行、匿名 401、读路径不变),加门前后都绿,已在 PR 里明说。

连带面(比我动手前的预测大)

预测 8 例 / 1 文件,实测 14 例 / 3 文件 —— 漏了两个经 dispatch()(而非 handleMetadata)驱动的文件。已如实写进 PR 第 2 节。三处都只补调用方能力,被测机制与断言一字未动。

错误信封三形状(#7035)按要求未捎带。

---

Generated by Claude Code