You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Decision] is view reconciled per metadata type or per union arm? 36 keys of the #19188 census cannot be filed until this is settled #19330
view is the only union-rooted metadata type of the 17. keysOf() on a union returns the union of the arms' keys — which is the SAFE direction for formOnly (the gate says so in its own comment: an author may legally write any member's key) and the UNSAFE direction for zodOnly.
Measured in the #19188 census: view has 4 arms of 21 / 15 / 65 / 46 keys, union 85, intersection 11. Of its 56 top-level zod-only keys, 9 are on every arm, 47 are on some arms only, and 35 are exclusive to exactly one arm.
⇒ an as-is top-level zodOnly on view would demand that ONE form simultaneously offer mutually exclusive arms — columns from the list arm and sections / drawerSide / modalSize from the form arm. ⛔ No number of rows added to the one registered view form can satisfy it.
Why this is a ruling and not a fix
The registered view.form.ts authors ONE arm of four. Deciding whether reconciliation is per-type or per-arm decides what a view form IS, so it is a shape question, ⛔ not a bug. 36 of the 274 keys (buckets 5 and 6) cannot be filed as work cards until it is settled, and the census round's own recommendation is recorded below rather than adopted:
option
what it means
A
per-arm: register a form per view kind and reconcile each arm against its own form
B
per-type with an arm-aware ledger: one form, plus a ledger vocabulary that can say 「this key belongs to an arm this form does not author」
C
leave view out of the top-level direction entirely and gate only the 16 object-rooted types
The census round recommended C first, then B — C buys the other 16 types their gate immediately and makes view a single named exclusion rather than 56 unactionable red lines; B is the real answer but it is a design, not a card. ⛔ This seat adopts neither and chooses nothing.
⚠️ Read this before taking any view bucket
The liveness ledger for view is anchored to the legacy nested arm: liveness/view.json carries 7 prop rows while ViewMetadataSchema declares 85 authorable keys, and 33 of view's top-level keys resolve a verdict only through a container-child coordinate (list.allowPrinting, form.drawerWidth). The gate DECLARES this rather than hiding it — it prints 「container coverage: 114 container entries carry a blanket verdict over 604 child keys that are classified NOWHERE … recorded, not asserted」 and scripts/liveness/undrilled-containers.baseline.json is shrink-only.
Dedup words
view union arm reconciliation · per-arm form registry · keysOf union zodOnly · view form authors one arm · arm-aware ledger vocabulary
Origin: the #19188 census round, report comment 5749550902 (2026-09-20T11:37Z), base 596090efbe7. Its numbers were re-derived by the dev with the reconciliation gate's OWN helper block sliced verbatim (sha256 f6729dae2829…), ⛔ not by grepping source, with a lit control (name, offered by 17 of 17 forms) and a dark control (a fabricated key, 0) asserted inside the probe.
Filed-by: session_01LvwGppdonww4zGLWZo5rho (domain:spec execution seat 1), as the split triage asked for at 5747751499 — 「the claiming seat's first deliverable is the split, not the fix」. ⛔ Not graded and ⛔ not routed by this seat.
Ruling: batch #203 item 1 · letter A · maintainer 「203 同意」 2026-09-21T01:23Z
Director seat, summon #25 (session_012GcsUbuqFGBibkEDMRC1eE). Presented in chat with this seat's recommendation A derived from facet ① alone; the maintainer approved the batch as presented.
Ruled: view is reconciled PER ARM. Each view kind (list / form / kanban / …) gets its own registered metadata form, and reconciliation judges each arm against its own form. B (one form plus an arm-aware ledger vocabulary) and C (view as a standing named exclusion) are ⛔ not the end state; the end state is the one mainstream platforms model — a list view and a page layout are two metadata types with two editors.
Sequencing, from facets ②–④ (they move the timing, not the letter): zero customer pull today — the 36 keys in #19188's buckets 5 and 6 are census rows, not defects — so the per-arm forms are ⛔ not dispatched now. They are registered when a product card first needs a view key filed, and that card cites this ruling. Until then the reconciliation gate's top-level direction covers the 16 object-rooted types only, which is what A and C both do today; the letter fixes only what view's answer is when someone comes for it.
Execution: (1) this card closes completed — the decision is made and nothing is dispatchable (the maintainer's standing 「卡片只要 open 就要一直被扫描」 rules out a hold); (2) #19188's blocker on this card is resolved by this close — the unlock sweep returns it to the queue for the 16-type direction, with view recorded there as 「待臂表单,按 #19330 A」 and its 36 keys ⛔ not filed; (3) the 「Read this before taking any view bucket」 section on this card stays the reader for whoever registers the first arm form. needs-user-decision removed in the same stroke as the close.
Path: none | 决策:
view的对账粒度(每类型 vs 每联合臂) | 挡住 #19188 普查的 36 把钥匙与另外 16 个类型的门禁分诊重测与定级:2026-09-20T15:36Z
os-decision-facets
zodOnly方向**根本没接线**(只有嵌套列表有),这就是两个已声明键在全门禁绿的情况下缺席表单的原因 —— 本树实测 276 个 top-level zod-only 键 #19188 普查里 36 把钥匙(第 5、6 桶)立不成卡,以及另外 16 个对象根类型的对账门禁被 view 一个类型挡在门外——后者是唯一的实测拉动,前者是账面拉动。⛔ 没有客户今天因为这个看不到东西。Prior rulings read: view,reconciled,metadata,type,union,keys,census,filed,settled → 179 hits; ADR-0005 Decision §3, ADR-0037 Decision §2, ADR-0003 Decision §4, ADR-0005 Decision §7, ADR-0019 D3, ADR-0020 D2, ADR-0021 D1, ADR-0032 Decision §1; thread: none; repo: objectstack-ai/objectstack
The question
viewis the only union-rooted metadata type of the 17.keysOf()on a union returns the union of the arms' keys — which is the SAFE direction forformOnly(the gate says so in its own comment: an author may legally write any member's key) and the UNSAFE direction forzodOnly.Measured in the #19188 census: view has 4 arms of 21 / 15 / 65 / 46 keys, union 85, intersection 11. Of its 56 top-level zod-only keys, 9 are on every arm, 47 are on some arms only, and 35 are exclusive to exactly one arm.
⇒ an as-is top-level
zodOnlyon view would demand that ONE form simultaneously offer mutually exclusive arms —columnsfrom the list arm andsections/drawerSide/modalSizefrom the form arm. ⛔ No number of rows added to the one registered view form can satisfy it.Why this is a ruling and not a fix
The registered
view.form.tsauthors ONE arm of four. Deciding whether reconciliation is per-type or per-arm decides what a view form IS, so it is a shape question, ⛔ not a bug. 36 of the 274 keys (buckets 5 and 6) cannot be filed as work cards until it is settled, and the census round's own recommendation is recorded below rather than adopted:The census round recommended C first, then B — C buys the other 16 types their gate immediately and makes view a single named exclusion rather than 56 unactionable red lines; B is the real answer but it is a design, not a card. ⛔ This seat adopts neither and chooses nothing.
The liveness ledger for view is anchored to the legacy nested arm:
liveness/view.jsoncarries 7 prop rows whileViewMetadataSchemadeclares 85 authorable keys, and 33 of view's top-level keys resolve a verdict only through a container-child coordinate (list.allowPrinting,form.drawerWidth). The gate DECLARES this rather than hiding it — it prints 「container coverage: 114 container entries carry a blanket verdict over 604 child keys that are classified NOWHERE … recorded, not asserted」 andscripts/liveness/undrilled-containers.baseline.jsonis shrink-only.Dedup words
view union arm reconciliation·per-arm form registry·keysOf union zodOnly·view form authors one arm·arm-aware ledger vocabularyOrigin: the #19188 census round, report comment 5749550902 (2026-09-20T11:37Z), base
596090efbe7. Its numbers were re-derived by the dev with the reconciliation gate's OWN helper block sliced verbatim (sha256f6729dae2829…), ⛔ not by grepping source, with a lit control (name, offered by 17 of 17 forms) and a dark control (a fabricated key, 0) asserted inside the probe.Filed-by:
session_01LvwGppdonww4zGLWZo5rho(domain:specexecution seat 1), as the split triage asked for at 5747751499 — 「the claiming seat's first deliverable is the split, not the fix」. ⛔ Not graded and ⛔ not routed by this seat.Generated by Claude Code