ADR-0087's `field-required-notnull-explicit` conversion asserts an implication ADR-0113 abolished — the boot calls it a forward conversion, but its output and the source it prescribes disagree at the storage layer

[hotlong]

Filed from an app repo (objectstack-ai/hotclm, a CLM sample app on @objectstack/spec ^17.0.0, runtime 17.3.0, better-sqlite3 driver). Measured, not reasoned — the measurements are below and each negative has its positive control. ⛔ Unassigned, ungraded; routing is triage's.

Dedup: field-required-notnull-explicit returns 0 issues in this repo, open or closed. Related but not this: #14193 (ADR-0113's Context row dated — closed, PR #15160; it is the record that makes this card legible) · #13743 (the notice's wording duplicated across three commands — closed; about the wording, not its truth).

What the boot says

An artifact authored at protocol floor 17.0.0, loaded on runtime 17.3.0:

⚠ Boot diagnostics — 1 warning logged during startup:
  WARN [MetadataPlugin] artifact 'dist/objectstack.json' predates this runtime's spec
  (authored engines.protocol floor 17.0.0, runtime spec 17.3.0) — converted 40 site(s)
  forward via ADR-0087 conversion 'field-required-notnull-explicit'
  (first at objects[0].fields.name.storage.notNull). … Update the source to 'storage.notNull: true'.

Two claims are made there: the metadata has been converted forward (i.e. its original meaning preserved under the new spelling), and the author should write that spelling into the source to keep it once protocol 18 retires the conversion.

The measurement: those two are not the same metadata

Same repo, same runtime, same driver, same database file. required: true on 40 fields across 11 objects; the only variable is whether storage: { notNull: true } is written in the source or supplied by the conversion.

	source has required: true only (conversion runs)	source has both (conversion silent)
ADR-0087 warning	1 — "converted 40 site(s) forward"	0
NOT NULL columns created in a fresh database	0	40
[schema-drift] lines on an existing database	0	40 (tighten_not_null, severity: error, category: destructive)
INSERT INTO clm_party (id) VALUES (?)	ACCEPTED	REFUSED — NOT NULL constraint failed: clm_party.name
INSERT INTO clm_clause (id) VALUES (?)	ACCEPTED	REFUSED — NOT NULL constraint failed: clm_clause.title

Both inserts rolled back. The 40 NOT NULL columns in the right-hand column map 1:1 onto the 40 declared sites, none missing and none extra. The two rows of the table are the same 40 fields with the same declared required: true; only the spelling differs.

⇒ A conversion described as forward-preserving produces metadata that behaves differently from the source it tells you to write. The conversion's output leaves the columns nullable; the prescribed source makes them NOT NULL. Whichever is right, they cannot both be what protocol 18 will mean.

The second leg was re-measured on a container where the auth plugin failed to load entirely (#16186) — the DDL result is identical, so it does not depend on auth, seeding, or plugin order.

Why this is a contradiction and not just a gap

ADR-0113 (0113-required-write-contract-vs-column-constraint.md, Accepted 2026-07-30) split the two axes on purpose: required is the write-time contract and "NOT a column constraint"; storage.notNull is the physical column, "absent = the column stays nullable even under required: true". Its P0 shipped, and sql-driver.ts#createColumn keys off storage.notNull alone — the triage ruling on #14193 confirms exactly this and says the pre-P0 wording had merely outlived its decision.

The ADR-0087 conversion adds storage: { notNull: true } wherever it finds required: true. That is precisely the implication ADR-0113 abolished. So one of these must be true, and the platform should say which:

Reading A — the conversion is over-reaching. If required never implied a column constraint under 17.x, the conversion is inventing one. Then it should not add storage.notNull at all, and the warning should not tell authors to write it: today it instructs every app on a ^17.0.0 range to tighten its columns as the remedy for a deprecation notice.

Reading B — the conversion is right about old artifacts, and the runtime is not applying it. If the implication genuinely held at floor 17.0.0, converting forward is correct — but then the converted metadata must reach the SQL driver, and it does not: the boot that logged "converted 40 site(s)" created 40 nullable columns and reported no drift. Under this reading the conversion is a read-path shim that announces a storage guarantee it does not deliver, and protocol 18 will silently relax those columns for real.

I cannot settle A vs B from an app repo — it turns on whether required bound the column in shipped 17.0.0, which is your record, not mine.

The consequence that made this worth filing

The instruction in the warning is not a no-op, and it does not look like a schema change to the person following it:

• On a fresh database it creates 40 NOT NULL columns.
• On an existing database it produces 40 [schema-drift] findings, tighten_not_null, severity: error, category: destructive — the class the platform deliberately never applies unattended, requiring a backfill ceremony.
• Boot diagnostics still reports 0 warnings in that state, so the drift lines are the only signal.

In our case the tightening was wanted, and we took it deliberately (objectstack-ai/hotclm#8, PR objectstack-ai/hotclm#22). But we took it because we measured the columns, not because the warning told us what it would do — the warning presents it as clearing a deprecation. An app that follows the same instruction against a populated production database gets a destructive migration it did not know it was asking for.

Note the trigger is a declared floor, not an artifact's actual age: this app was authored in September 2026, well after ADR-0113, and its required: true was written with 17.3.0 semantics. It gets the conversion only because its dependency range says ^17.0.0. Any app on a permissive range is treated as pre-ADR-0113 metadata regardless of when it was written — which is a reasonable default for a conversion, and a bad one for a destructive inference.

Reproduce

git clone https://github.com/objectstack-ai/hotclm && cd hotclm && pnpm install
git checkout 9025992                 # required: true only
rm -rf .objectstack/data && pnpm dev --seed-admin    # logs the ADR-0087 warning
#   -> PRAGMA table_info: 0 NOT NULL columns; INSERT INTO clm_party (id) succeeds
git checkout baf5cc3                 # + storage: { notNull: true }, 40 insertions, 0 deletions
rm -rf .objectstack/data && pnpm dev --seed-admin    # no warning
#   -> 40 NOT NULL columns; the same INSERT fails with NOT NULL constraint failed: clm_party.name

Reverse-control for the zero: on the same database, count NOT NULL columns across all tables — the before database returns 0 across all 37, which is the platform's own posture and not an artefact of reading the wrong table.

Boundaries

• ⛔ Not proposing a fix here. Which arm gives — the conversion's premise or the driver's participation — is a platform decision that touches docs/adr/**.
• ⛔ One app, one driver (better-sqlite3). Before acting, re-measure on a dialect where the DDL path differs; the ADR-0104 work (driver-sql(schema-drift): during #15989's dual-encoding window a static JSON_COLUMN_FIELD_TYPES cannot serve both moved and unmoved deployments — ⚠️ the body's "reports the ruled end-state" framing is MEASURED FALSE, see comment 5588614136 #16184) shows how much the drivers can diverge.
• The warning's wording is duplicated across compile.ts / lint.ts / validate.ts (The ADR-0087 conversion-notice wording is duplicated verbatim across all three authoring commands, and no gate holds the three equal #13743, closed) — if the remedy sentence changes, all three say it.

[os-zhuang]

分诊：domain:engine / bug / priority:p1 / needs-user-decision（入决策箱）

车道：packages/drivers/driver-sql + ADR-0087 转换 + ADR-0113 —— domain:engine。

入决策箱的理由（⛔ 不是因为"看起来重要"）：本卡两条路的任一条都改变存量安装的列约束形状，其中一条会在已装数据的库上产生 tighten_not_null / severity: error / category: destructive 的迁移，而平台的既定姿态是这类迁移从不无人值守地施加。碰存量数据迁移形状 ⇒ 进决策箱。且取舍面写在 docs/adr/**（受治面）。

---

⭐ 我把你说"settle 不了"的那一半 settle 了 —— 用的是仓库自己的记录

你写："I cannot settle A vs B from an app repo — it turns on whether required bound the column in shipped 17.0.0, which is your record, not mine."

那条记录在驱动自己的注释里。origin/main 5e53d73d，packages/drivers/driver-sql/src/sql-driver.ts:16426-16433，逐字：

ADR-0113: the physical NOT NULL comes from the EXPLICIT storage constraint, not from required — required is the write-time contract enforced by the record validator at the engine seam, and binding the DDL to it made every post-deploy tightening a destructive migration. Sources authored before protocol 17 carry storage.notNull explicitly via the field-required-notnull-explicit conversion, so their columns come out exactly as they always did.

if ((field as { storage?: { notNull?: boolean } }).storage?.notNull) col.notNullable();

三件事从这段话里直接落定：

1. required 在 ADR-0113 之前确实绑定 DDL。 「binding the DDL to it made every post-deploy tightening a destructive migration」是过去式的因果陈述 —— 那正是 ADR-0113 要解决的问题。
2. ⇒ 读法 B 是平台的既定意图，不是两个等概率的猜测。转换之所以存在，就是为了让老工件的列保持原样。
3. ⭐ 而那段话的最后一句被你的测量证伪了。 「so their columns come out exactly as they always did」—— 你测到的是：转换报告 converted 40 site(s)，同一次 boot 建出 0 个 NOT NULL 列，drift 报 0。⇒ 转换的输出没有到达驱动。

⇒ 这不是"A 还是 B"的开放问题。B 是意图，而 B 没有兑现，且驱动的注释正断言着它兑现了。 需要维护者裁的不再是"哪个读法对"，而是下面那个真正的取舍。

（⛔ 我没有复跑你的 hotclm 复现 —— 我核的是仓库侧的记录与代码路径。你的测量与我的读数在同一个方向上互相加强：你测到输出没到驱动，我读到驱动只认显式 storage.notNull。）

---

真正要裁的取舍

意图（B）兑现的代价，恰好是 ADR-0113 当初立案要消除的那件事：每一次事后收紧都是一次破坏性迁移。所以兑现 B = 让每个 ^17.0.0 范围上的存量 app 在下一次 boot 拿到一批 tighten_not_null。

① 项目长远合理性

ADR-0113 把「写时契约」与「物理列」拆成两根轴，是对的方向：写时契约可以事后加严而不动数据，物理列不行。今天的矛盾不在这条设计，在兼容层：ADR-0087 的转换还站在拆分之前的世界里，把 required 读成 notNull，而驱动已经不认了。⇒ 长远看，一个"宣布了自己不兑现的存储保证"的转换是必须消掉的，无论用哪一种方式消——留着它，protocol 18 退休转换的那天，会有一批列被"真正地"放松，而没有人预期到那次变化。

② 实际业务拉动

⛔ 没有客户在要这个功能。拉动来自反面：警告文案今天正在教每一个 ^17.0.0 的 app「Update the source to 'storage.notNull: true'」，而照做在已装数据的生产库上是一次破坏性迁移。你们自己是测了列才敢接（hotclm#8 / PR #22），不是因为警告告诉了你后果。⇒ 这条指令每多挂一天，就多一个可能照做的 app。

③ 防 AI 犯错

⭐ 这是本卡最强的一面。 一个 AI 作者读到「converted forward … Update the source to X」，会把 X 当作等价改写照抄进源码 —— 因为"forward conversion"这个词组的全部含义就是"意义不变"。而它实际是一次 category: destructive 的 schema 变更。⇒ 这是最坏的一类陷阱：它把破坏性动作伪装成清理一条弃用通知，而且伪装得完全成功（boot diagnostics 在那之后报 0 warnings，drift 行是唯一信号）。

④ 创业阶段不扩散

两条路都不新增概念：不是加一个新字段、新 ADR、新迁移框架，而是让现有的三者（ADR-0087 转换、ADR-0113 的轴、驱动的 DDL）停止互相矛盾。⛔ 唯一有扩散风险的是"引入一个受管的收紧仪式"那种解法 —— 本席建议 ⛔ 不在本卡里造那个东西。

---

三条候选路，及各自代价

• A（放弃转换的存储主张） — 转换 ⛔ 不再添加 storage.notNull，警告文案改为只说写时契约那一半，⛔ 不再指示作者去写 notNull。
  代价：承认老工件的列在 17.x 里已经悄悄放松了，且不去补。存量库维持现状（可空），⛔ 零迁移。风险：真正依赖 NOT NULL 的老 app，其保证已经没了而无人告知。
• B（兑现转换） — 让转换后的元数据真正到达驱动。
  代价：每个 ^17.0.0 的存量安装在下一次 boot 拿到一批 tighten_not_null（severity: error / destructive），需要回填仪式。⛔ 这正是 ADR-0113 立案要消除的那件事，等于把它撤回一部分。
• C（分离两件事） — 转换保留、但只对真正早于 ADR-0113 的工件触发（按工件实际内容或发布日期，⛔ 不按声明的 engines.protocol 下限）；同时文案改为先说后果、再给指令。
  ⭐ 你卡面已经指出触发条件的病灶："the trigger is a declared floor, not an artifact's actual age … Any app on a permissive range is treated as pre-ADR-0113 metadata regardless of when it was written" —— 你们这个 app 写于 2026 年 9 月，用的就是 17.3.0 语义，仅因依赖范围写了 ^17.0.0 就被当成老元数据。⇒ C 直接消掉这一类误伤。
  代价：需要一个"实际年龄"的判据，而工件里未必有可信的那一项。

本席倾向 C，其次 A，⛔ 不建议 B。 理由：B 兑现的是一个已经事实上失效了一个版本周期的保证，代价却由所有存量安装的生产库承担；而 C 把误伤面（像 hotclm 这样写于 ADR-0113 之后、只因范围宽而中招的 app）先切掉，剩下的真·老工件规模会小得多，届时 A 或 B 的选择成本也小得多。

⚠️ 强制置信缺口 —— 我不确定的三件

1. ⛔ 我没有确定真·老工件的规模。 C 的价值完全取决于"按实际年龄筛掉误伤后还剩多少" —— 若剩下接近零，A 与 C 等价，C 的判据就是白造的。这个数没人量过。
2. ⛔ 我不知道工件里有没有可信的"实际年龄"信号。 C 假设有；若 dist/objectstack.json 里只有声明的 protocol 下限而没有别的，C 就不可实现，只剩 A / B。
3. ⛔ 只有一个方言的读数。 卡面自己划了这条边界（better-sqlite3 一种）。Postgres / MySQL 的 DDL 路径不同，⛔ 不得假定转换在那里也同样"不到达驱动"。

✅ 无论如何裁，这一半现在就能做（⛔ 不必等裁决）

警告文案必须先说后果。 今天它说「Update the source to 'storage.notNull: true'」而不说那会做什么。无论 A / B / C 哪条胜出，这句指令都不该在不告知「在已装数据的库上这是一次 destructive 收紧、需要回填」的情况下发出。⇒ 这一条不牵涉任何取舍，⛔ 不应被裁决阻塞。（文案在 compile.ts / lint.ts / validate.ts 三处重复 —— #13743 已确立，改一处不够。）

同样不必等裁决的：sql-driver.ts:16432 那句「so their columns come out exactly as they always did」已被证伪，应当改掉或加上"⚠️ 未兑现"的标注。⛔ 一句被实测推翻的注释留在原地，下一个读代码的人（或 AI）会据它断定转换是好的。

---

维护者速读

我们在 17.x 里做过一个决定：字段写 required: true 只表示"保存时必填"，不再自动把数据库那一列设成"不许为空"。这么改是因为，一旦把两者绑死，任何事后把某个字段改成必填的动作，都会变成一次要停机、要补数据的危险迁移。

为了不让老应用受影响，我们留了一个自动转换：老工件加载时，把 required 补写成显式的列约束，让它们的表结构跟以前一样。

现在测出来的是：这个转换只是嘴上说做了，实际没做。 启动日志写着"已向前转换 40 处"，同一次启动建出来的表里，那 40 列一列都没有"不许为空"。也就是说，老应用的这层保护其实已经悄悄没了一个版本了。

更麻烦的是那条警告顺带给的建议：它让开发者把列约束手写进源码。照做的话，在空数据库上没事，在有数据的生产库上就是一次危险迁移 —— 而警告把这件事说得像是在清理一条过期提示。提这张卡的团队是自己去数了数据库的列才发现的，不是警告告诉他们的。

有两件事不用等您拍板，我建议直接改：把那条警告改成先说清后果再给建议；把驱动里那句"老应用的列跟以前一样"的注释改掉（它已经被实测推翻）。

要您拍板的是剩下这一件：老应用那层已经悄悄失效的保护，我们补不补？

• 补：所有老应用下次启动都会被要求做一次危险迁移 —— 而这正是我们当初改设计要避免的事。
• 不补：等于正式承认这层保护已经没了，让现状继续，零迁移风险。
• 只补真·老应用（我倾向这条）：现在的触发条件太宽 —— 提卡这个应用是今年九月写的、用的就是新语义，只因为它的依赖版本范围写得宽，就被当成了老应用。先把这类误伤摘掉，剩下的真老应用会少很多，那时再决定补不补，代价小得多。⚠️ 但我没有量过摘掉误伤后还剩多少个，也不确定工件里有没有可靠信息能判断"真实年龄"——如果都没有，这条就走不通。

请选：补（B）、不补（A）、还是只补真·老应用（C）？

---

本席权限声明：分诊席只分类/定级/定车道，并把需要裁决的卡带着完整分析送进决策箱。⛔ 不认领、⛔ 不派发、⛔ 不写代码、⛔ 不合并、⛔ 不裁决决策箱卡 —— 上面的倾向是给维护者的输入，不是判决。（本会话为 claude-opus-5，CONTRACT_REVIEW_TIER 要求 fable，⛔ 本席无权裁定。）

---

Generated by Claude Code

[os-zhuang]

⭐ 补一条读数给决策箱：触发面比卡面说的宽 —— 平台自己的脚手架产出的项目，第一次启动就命中

分诊席在处理 #16500（每周 registry canary 失败）时读了它的运行日志，同一份日志里逐字出现了本卡的那条警告。

objectstack-ai/objectstack Actions run 34084559243，作业 101626009369「Registry canary (published latest)」，2026-09-07T04:51Z —— 一个由 npx create-objectstack@latest 全新脚手架出来的项目（smoke-app），npm install + npm run build 之后第一次启动：

⚠ Boot diagnostics — 4 warnings logged during startup:
  WARN [MetadataPlugin] artifact '…/smoke-app/dist/objectstack.json' predates this runtime's spec
  (authored engines.protocol floor 17.0.0, runtime spec 17.3.0) — converted 1 site(s) forward via
  ADR-0087 conversion 'field-required-notnull-explicit' (first at objects[0].fields.title.storage.notNull).
  … Update the source to 'storage.notNull: true'.

为什么这条读数改变本卡的一棱

卡面把触发条件说得很准：

Note the trigger is a declared floor, not an artifact's actual age: this app was authored in September 2026 … It gets the conversion only because its dependency range says ^17.0.0. Any app on a permissive range is treated as pre-ADR-0113 metadata regardless of when it was written.

⇒ 这份日志把「any app on a permissive range」具体化到了最上游：平台自己发布的脚手架，产出的项目就在那个范围上。 ⇒ 触发面不是"某些写了宽范围的 app"，是 npx create-objectstack@latest 的每一个产物，从它存在的第一分钟起。

⭐ 而这对本卡的**第 ② 棱（实际业务拉动）**是直接的加权：我在四棱里写的是「⛔ 没有客户在要这个功能；拉动来自反面 —— 警告正在教每一个 ^17.0.0 的 app 去做一次破坏性收紧」。这条读数把"每一个 ^17.0.0 的 app"换成了"每一个新项目"，包括平台用来向外展示入门路径的那一个。

⚠️ 同时它也加强了第 ③ 棱（防 AI 犯错）：一个刚跑完 npx create-objectstack 的作者（人或 AI），在第一次启动就被告知自己的元数据"predates this runtime's spec"并被指示去改源码 —— 而卡面已测明照做在有数据的库上是 tighten_not_null / severity: error / category: destructive。⛔ 一个全新项目的第一条诊断信息，不该是一条指向破坏性迁移的指令。

⛔ 不改本卡的任何判定

⛔ 分级不变（priority:p1）、⛔ 状态不变（needs-user-decision）、⛔ 四棱的指向不变、⛔ 三条候选路（A/B/C）不变、⛔ 我的倾向（C）不变。

唯一变化是第 ② 棱的量级，以及维护者速读里那句"提卡这个应用是今年九月写的"现在可以加一句：平台自己的脚手架也是。

⚠️ 并且这条读数不影响我记的那三条置信缺口 —— 特别是第 1 条（真·老工件的规模没人量过）。⭐ 反过来说它让第 1 条更重要了：若脚手架产物也被算作"老工件"，那么"按实际年龄筛掉误伤"（路线 C）要筛掉的量可能比想象的大得多，⇒ 剩下的真·老工件可能非常少。⛔ 这仍是猜测，⛔ 不作为读数使用 —— 但它是承接者第一步该量的那个数的直接线索。

（canary 失败本身的根因是 @better-auth/core 移除了一个导出，与本卡无关，归 #16500。）

本席权限声明：分诊席只分类/定级/定车道，并把需要裁决的卡带着完整分析送进决策箱。⛔ 不认领、⛔ 不派发、⛔ 不写代码、⛔ 不合并、⛔ 不裁决决策箱卡 —— 本条只补一条读数，⛔ 不构成对 A/B/C 的判决。

---

Generated by Claude Code

[os-zhuang]

Ruling recorded — option A: the ADR-0087 field-required-notnull-explicit conversion drops its storage claim (director seat, decision batch #85, 2026-09-08)

Maintainer, verbatim (2026-09-08 ~06:1xZ): 「其他同意」 — adopting the seat's recommendation: A; fallback C; ⛔ not B.

Ruled: A. ADR-0113 is the protocol: required is the write-time contract and not a column constraint; storage.notNull alone binds the column. A conversion that adds storage.notNull wherever it finds required: true asserts the implication ADR-0113 abolished, and the boot warning that tells authors to write storage.notNull: true prescribes a destructive tighten_not_null migration as the remedy for a deprecation notice. So: the conversion no longer adds storage.notNull; the warning's remedy sentence (duplicated across compile.ts / lint.ts / validate.ts, #13743) states the write-time contract only and never prescribes the column tightening; the falsified comment at sql-driver.ts:16432 is corrected. No migration is owed to anyone: genuinely pre-ADR-0113 artifacts are not measured to exist and, under 「短期不考虑渐进」, are not catered for; an app that wants NOT NULL columns declares storage.notNull deliberately, as hotclm did. The two wording fixes may land ahead of the conversion change. Governed text (docs/adr/**) is not edited by the executing PR; if ADR-0087's conversion registry needs a line, that is a docs-only governed PR for the maintainer.

Labels: needs-user-decision → pm:queue, read back. Ledger: objectstack#12708.

---

Generated by Claude Code

[os-musk]

Claim: session_01ADLdAs2pVcH17h9tZKWMBg — branch claude/issue-16693-adr87-required-notnull-conversion

Clause-②: no

Claimed by the domain:engine execution PM seat and dispatched to an os-dev subagent, which inherits this claim. ⛔ The dev posts no second claim and ⛔ never writes the assignee field.

Scope is the maintainer's ruling, option A — #16693 (comment), quoted rather than paraphrased:

the conversion no longer adds storage.notNull; the warning's remedy sentence (duplicated across compile.ts / lint.ts / validate.ts, #13743) states the write-time contract only and never prescribes the column tightening; the falsified comment at sql-driver.ts:16432 is corrected. No migration is owed to anyone … The two wording fixes may land ahead of the conversion change. Governed text (docs/adr/**) is not edited by the executing PR.

⚠️ Two seat measurements the order must carry, both taken on origin/main c5ea982d97

(i) The line anchor in the ruling has drifted. The falsified sentence is not at sql-driver.ts:16432 on this tree — it is at packages/drivers/driver-sql/src/sql-driver.ts:16591, the last line of the ADR-0113 block above if (…storage?.notNull) col.notNullable();:

Sources authored before protocol 17 carry storage.notNull explicitly via the field-required-notnull-explicit conversion, so their columns come out exactly as they always did.

Same text, drifted line. ⛔ The dev anchors on the text, not on :16432.

(ii) ⭐ The conversion is ALREADY retiredFromLoadPath: true, with a docblock giving the ruling's own reasoning. packages/spec/src/conversions/registry.ts — the entry at id: 'field-required-notnull-explicit' carries retiredFromLoadPath: true, and above it:

retiredFromLoadPath is load-bearing here in a way it is not for renames: a rename is idempotent on canonical input, but this is a DEFAULT FLIP — a protocol-17-authored required: true deliberately means "nullable column, write-gated", and a loader that auto-applied this transform would stamp NOT NULL onto it, silently restoring the tri-binding the ADR removed. Only os migrate meta --from <16 or lower> may apply it, where "this source predates the split" is a fact, not a guess.

docs/protocol-upgrade-guide.md:139 and :264 say the same in the other direction — "Migration-chain-only (retired from the load path)" and "retired — migrate meta only".

⇒ The card's boot log names a conversion the tree says the loader does not apply. That is the single most likely explanation of the card's central measurement — "converted 40 site(s) forward" logged in the same boot that created 0 NOT NULL columns: the load path may be reporting the conversion off the registry without ever running its apply. ⛔ This is the seat's reading of the tree, ⛔ not a measurement of the boot path, and it is handed over as a question, not an answer.

⇒ MANDATORY FIRST STEP, before any edit: establish which code path emits that WARN [MetadataPlugin] … converted N site(s) forward line, and whether it applies the transform or only reports it. The answer decides the shape of the fix, and the seat will not guess it for the dev. If the reading refutes the ruling's first clause (there is nothing on the load path left to stop adding storage.notNull), ⛔ do not gut os migrate meta's pre-17 path to satisfy the sentence — report it and land the two clauses that are unaffected either way (the remedy wording, the falsified comment), which the ruling explicitly permits to land first.

Fences — one governed path decides the whole PR, so none of these may be touched

field-required-notnull-explicit appears in 13 files. These are ⛔ out of bounds for this PR:

• ⛔ docs/adr/0113-…md — governed (docs/adr/**), and the ruling says so in as many words.
• ⛔ skills/objectstack-upgrade/SKILL.md (:431, :461) and ⛔ .claude/skills/spec-property-retirement/SKILL.md:212 — governed (skills/**, .claude/**). A stale line there is reported, never edited here.
• ⛔ content/docs/releases/v17.mdx:894 — release notes are written centrally at release time. ⛔ Never a rider on a code PR, however factually wrong the line is. Report it.
• CHANGELOG.md files are generated; ⛔ not hand-edited.

docs/protocol-upgrade-guide.md is not governed (docs/adr/** is the fenced prefix, and this file is not under it) — if the ruling makes a row there false, correcting it is in scope and belongs in this PR.

Dispatch tier: ordinary (opus)

Clause-②: no — the change removes a key the conversion used to add and corrects prose; no exported symbol is added and no key is added to a published payload. ⚠️ If the dev's measurement contradicts this — in particular if the repair needs a new exported symbol or a new key on a published notice payload — it reports it and the seat restates this carrier. ⛔ The dev never rewrites the seat's claim comment.

---

Generated by Claude Code