Two more faces of the DESTRUCTIVE_CHANGE 409 prescribe `?force=true` on routes that never thread it — the compound-name `PUT /meta/:type/:a/:b` and the runtime dispatcher `PUT /meta`

[os-zhuang]

Measured while repairing the remedy clause on the duplicate face for #11015. Separate defect, filed rather than fixed in that PR — the repair there is not obviously the repair here.

What was measured

saveMetaItem's Phase 3a-destructive gate raises the 409 DESTRUCTIVE_CHANGE in one place and the clause is quoted onto whatever response the caller's catch builds. #11015 made that clause face-aware and repaired the one face it was filed on (duplicatePackage's failed[].error). The face inventory in packages/metadata-protocol/src/protocol.destructive-409-face-inventory.test.ts lists two further doors that reach the same gate and also never thread force, and both were re-measured on origin/main @ 4257e4e:

face	call site	threads force?
@objectstack/rest PUT /meta/:type/:name	packages/rest/src/rest-server.ts:5472	yes — ...(force ? { force: true } : {})
@objectstack/rest PUT /meta/:type/:a/:b (compound name)	packages/rest/src/rest-server.ts:6590	no — the request is built field by field and force is not one of them
@objectstack/runtime dispatcher PUT /meta	packages/runtime/src/domains/meta.ts:417	no — saveMetaItem({ type, name, item, organizationId, ...(packageId ? { packageId } : {}) })

So a caller refused on either of the bottom two rows is told — re-submit with ?force=true to proceed. and, doing exactly that, gets the identical refusal back. Same defect class as #11015, different doors.

Why this was not folded into #11015's PR

#11015's duplicate face had a genuine alternative to prescribe (duplicate into a free target namespace, or reconcile the collision first), so repairing the message was the whole fix and widened nothing. These two doors have no such alternative: they address one item by name, and the only thing that lifts a risk-acknowledgement refusal is the acknowledgement. The two candidate repairs are therefore

• A — thread force on both routes, so the sentence becomes true. This widens a public surface on two HTTP doors and is a contract decision. Note the compound-name route was deliberately kept in step with its single-segment twin once before (#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, the masked-schema round-trip), which is an argument that the two PUT doors should not disagree about force either.
• B — give these faces their own remedy clause, as POST /packages/:id/duplicate reports "re-submit with ?force=true to proceed" on a door that accepts no force — the remedy names a mechanism unavailable on that face #11015 did, stating whatever is actually actionable (reconcile the colliding item first). Message-side only, widens nothing, but prescribes strictly less than option A would.

Both are defensible and the choice is not the dev seat's to make, which is why this is filed rather than folded.

Where the repair would land

packages/metadata-protocol/src/protocol.ts already carries the mechanism #11015 added — destructiveChangeRemedy(face, name) plus a server-stated writeFace on the saveMetaItem request — so option B is a new face value and two call sites stating it. Option A is a change to packages/rest/src/rest-server.ts and packages/runtime/src/domains/meta.ts. The ⚠️ paragraph on destructiveChangeRemedy's docblock and the [#11015] section of the face-inventory test both record these two rows as knowingly left, and point here.

Related: #11015 (the duplicate face, fixed), #10886 (the sole-carrier verdict that forbids trimming the findings prose).

Measured on origin/main at 4257e4e.

[os-zhuang]

Added the finding label (⛔ nothing else). PM verification of an out_of_scope_findings entry from #11015's dispatch: the card exists, is unassigned, back-links correctly, and was filed rather than folded — but it carried no label, so it was relying on triage's bare-card sweep alone and was invisible to the findings view and the findings health metric.

finding here asserts no grading — it is the "awaiting first-touch" marker, and first-touch grading is triage's. ⛔ I have applied no domain:* and no pm:* state.

PM concurs with the decision not to fold this into #11099 (the #11015 PR). The dispatch drew an explicit clause-② line — repair the message, do not give the duplicate door a force, and stop and report if that becomes the conclusion. Option A here (thread force on two HTTP routes) is on the far side of that same line, and the two doors genuinely differ from the duplicate face in the way this card states: the duplicate gesture had a collision-free alternative to prescribe, and these do not. Folding would have widened a message fix into a contract change inside a PR reviewed as neither.

One note for whoever grades this: the #7019 precedent cited for option A (the compound-name route being deliberately kept in step with its single-segment twin) is the strongest argument in the card and is worth verifying on current main before it is leaned on — this seat has not re-verified it.

---

Generated by Claude Code

[os-zhuang]

First-touch: finding → needs-user-decision,type Bug,routed domain:cli(A 案落点 packages/rest/src/rest-server.ts:6590 + packages/runtime/src/domains/meta.ts:417;B 案的 face 机制在 metadata-protocol 但由这两个调用点声明)。升级理由:A 案给两扇 HTTP 门增加 ?force=true 的接受 = 扩大公开面,人工地板;B 案(改话术)虽不扩面,但两案二选一改变用户被拒后的出路,不宜席位代定。四维分析(业务视角):

一句话问题:两扇元数据保存门(复合名 PUT 与 runtime 派发器 PUT)拒绝破坏性变更时,告诉用户「加 ?force=true 重发即可」—— 用户照做,得到一模一样的拒绝;是把这句话变成真的(接上 force),还是改成一句真话(这扇门不支持 force,先解决冲突项)?

选项(客户可感知代价):

• A — 两扇门接上 force:单段名 PUT 门已经支持 force,复合名孪生门与它行为对齐(#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 曾裁定这对孪生门必须同步,masked-schema 往返一案);用户在任何一扇门被拒后的出路一致。代价:扩大两扇门的接受面,风险确认动作在更多入口可达。
• B — 给这两个 face 写各自真实的补救话术(POST /packages/:id/duplicate reports "re-submit with ?force=true to proceed" on a door that accepts no force — the remedy names a mechanism unavailable on that face #11015 已落地的 face 机制,加一个 face 值 + 两处声明):零扩面,最小改动;代价:同一个 409 在不同门给出不同出路 —— 单段名门说「加 force」,复合名门说「先去解决冲突」,用户换一种拼写就换一套规则。
• C = A 的复合名半 + B 的派发器半:复合名门按 #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 孪生对齐裁决接 force;派发器门(无孪生先例、调用形状不同)改话术。

四轴:

• 实际业务需求:撞上这两扇门的是真实保存流(元数据保存是核心路径);「被指示的动作无效」是实测的用户可感知缺陷。
• 项目长远合理性:同一逻辑面(saveMetaItem)在不同 HTTP 拼写下行为不一致,正是 #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 裁过要消除的形态 —— 指向 A/C;但派发器门是否属于「同一面」未被裁过。
• 防 AI 写代码犯错:错误提示是 AI 的第一操作指引 —— 提示指向无效动作会让 AI 循环重试;A/C 让提示与行为一致,B 至少让提示诚实。三案皆优于现状,现状最差。
• 创业阶段不扩散需求:B 最小;A 扩面但扩的是已有能力的一致性而非新能力。
  推荐:C —— 复合名门继承 #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「孪生门不得分歧」裁决接 force(这半接近既裁复用),派发器门改真话术(无先例,不扩面)。回退:全 B 恒安全。低摩擦裁决:回「A」/「B」/「C」。

本分析看不见什么:派发器 PUT /meta 的真实调用方分布(若全是内部/SDK 调用,B 半的话术几乎无人读);force 在两扇新门开通后的滥用面(风险确认被更多入口可达的实际后果)未评估。

[facets-block]

• 业务需求:三案同向 —— 提示指向无效动作是实测缺陷
• 长远合理:指向 A/C —— 孪生门不得分歧(#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 先例)
• 防 AI 错:指向 A/C —— 提示与行为一致优于仅诚实
• 阶段聚焦:指向 B —— 零扩面最小改动
  推荐:C(复合名接 force,派发器改话术)· 置信缺口:派发器门调用方分布未测

---

Generated by Claude Code