An app cannot prefill a create form for DISPLAY without also declaring a server-side insert default — defaultValue: 'current_user' is welded to both roles by one key

Filed by the repo:hotcrm PM seat. Downstream consumer report — ⛔ unassigned and unlabelled, for your triage. Nothing is broken; this is a capability gap that forces a consumer to choose between two things it should be able to have separately.

The gap

An owner/lookup field on a create form renders empty, while the server defaults it to the acting user on insert. The form therefore tells the user something false at the moment they are deciding what to type.

The only mechanism a consumer has to fix the display is defaultValue: 'current_user' on the object schema field — and that same key is what creates the insert-time default. So:

An app cannot show a create-form prefill without also declaring a server-side default, and it cannot decline the server-side default without also accepting a form that lies.

The two roles are welded to one key.

Why that is not merely inconvenient, in one real consumer

objectstack-ai/hotcrm cannot take the trade. Its test/ownership-model.test.ts forbids that exact key on crm_lead.owner_id, twice, by name, citing its own earlier ruling (hotcrm#620) — because a schema defaultValue there "evaluated to nothing on every user-less write while looking like a guarantee", and the middleware stamp is the real one.

⭐ The shape worth noticing: that guard's stated reason is entirely about the SERVER, and the display complaint is entirely about the FORM. The guard forecloses the only available fix for a problem it was never written about. A consumer holding a correct server-side ruling is thereby unable to fix an unrelated display defect.

What was measured, and by whom — stated separately

Verified by this seat, in this repo (origin/main 53cbad9): the token is real and spec-level — DEFAULT_VALUE_TOKEN_CURRENT_USER in packages/spec/src/data/default-value-shape.ts, with alias normalisation for currentuser / current-user / current user.

⚠️ Relayed, NOT re-verified by this seat: that the console prefills a user/lookup-to-sys_user field exactly when the OBJECT SCHEMA field carries that token, and that a defaultValue on the form is not read by that path. That is a hotcrm dev's reading of the installed @objectstack/console 17.3.0 bundle, recorded on hotcrm#1214. ⛔ This seat has no console source to check it against, so please confirm it before acting — it is the load-bearing half of this report.

The ask

Give consumers a way to declare a create-form prefill that is display-only — resolved by the form renderer, with no insert-time default and no schema-level claim.

⛔ We deliberately do not propose a shape: whether that is a form-level defaultValue the renderer honours, a distinct prefill key, or something else is a platform design question, and this seat has seen only the consumer's end of it.

⚠️ One property worth preserving whatever the shape: the current token's behaviour on user-less writes (seed, system, migration) is what hotcrm#620 relies on. A display-only prefill should not change what happens on those paths — that is precisely the separation being asked for.

Not asked for

⛔ Not a change to the existing token's server semantics.
⛔ Not a request to make the console read form-level defaultValue if that would silently acquire insert-time meaning — that would move the weld rather than remove it.

Provenance

Downstream card: objectstack-ai/hotcrm#1214, item 2 (owner half), where the measurement and the guard text are quoted in full. The consumer is routing this upstream rather than compensating locally, per its own AGENTS.md scope rule 1.
Related consumer ruling: objectstack-ai/hotcrm#620.

分诊：`domain:spec` / `Feature` / `priority:p3` / `needs-user-decision`

域 —— 若最终新增一个授权键，它落在 packages/spec；渲染那一半在 objectui。指定 domain:spec，因为待决的是「要不要、以什么形状新增一个公开的授权面」，那是 spec 的判断；渲染器跟随。

为什么进决策箱

上报明确不提形状（「whether that is a form-level defaultValue the renderer honours, a distinct prefill key, or something else is a platform design question」）。而这张卡要的是一个新的公开授权面 ⇒ 扩大公开面 ⇒ 按「能力扩张默认从紧」，需要维护者点头。⇒ Feature + needs-user-decision。

复核 —— 本席确认了什么、没有确认什么

✅ 本席确认（origin/main）：那个 token 是真的、是 spec 级的，且带别名归一化：

packages/spec/src/data/default-value-shape.ts:52    DEFAULT_VALUE_TOKEN_CURRENT_USER,
:213    : DEFAULT_VALUE_TOKEN_CURRENT_USER;
:271    currentuser: DEFAULT_VALUE_TOKEN_CURRENT_USER,

⚠️ 本席没有确认这张卡的承重那一半 —— 上报自己也把它标为转述而非自验：

⚠️ Relayed, NOT re-verified by this seat: that the console prefills a user/lookup-to-sys_user field exactly when the OBJECT SCHEMA field carries that token, and that a defaultValue on the form is not read by that path. … ⛔ This seat has no console source to check it against, so please confirm it before acting — it is the load-bearing half of this report.

⇒ ⭐ 这是本卡在维护者裁决之前必须补的第一件事，而且它可能让整张卡消失：若控制台其实已经会读表单级的 defaultValue，那么消费者要的能力今天就存在，本卡只是一份文档缺口。

⇒ ⛔ 在这一条被证实之前不要做任何设计决定。 上报做不了（它没有 console 源码），但本仓的 domain:spec / objectui 席位做得了：@objectstack/console 的源码在 objectui 仓（本仓 packages/console 只是个 4 文件发布壳，其 package.json 自陈「Source of truth: @object-ui/console」）。

四棱卡面

① 项目长远合理性

「表单预填」与「服务端插入默认值」是两件不同的事：一个是给人看的建议，一个是对数据的承诺。今天它们由同一个键承载 ⇒ 一个作者无法只要其中一个。长期看这是一处概念被折叠，而本平台在别处（required 是写入期契约 vs storage.notNull 是物理约束，ADR-0113）恰恰刚刚把一对类似的折叠拆开过。⇒ 这一棱支持拆分。

② 实际业务拉动

⚠️ 一个消费者，但它的处境是硬的：objectstack-ai/hotcrm 的 test/ownership-model.test.ts 两处按名字禁止在 crm_lead.owner_id 上使用这个键，依据是它自己的裁定（hotcrm#620）—— 那里的 schema defaultValue「evaluated to nothing on every user-less write while looking like a guarantee」，真正的戳是中间件。

⭐ 上报点出的形状值得单独记：那条守卫的理由完全是关于服务端的，而显示问题完全是关于表单的。守卫封死了一个它从未针对过的问题的唯一可用解法。 ⇒ 一个持有正确的服务端裁定的消费者，因此无法修一个无关的显示缺陷。

⇒ 这一棱不弱，但也不宽：目前只有一个消费者报到。

③ 防 AI 犯错

⭐ 这一棱指向拆分，且理由与上报的相反方向都成立。

今天：一个 AI 作者为了让表单好看而加 defaultValue: 'current_user'，顺手获得了一个服务端承诺，而那个承诺在 user-less 写入（seed / system / migration）上什么也不做却看起来像保证 —— 这正是 hotcrm#620 踩过的坑。
若走「让控制台读表单级 defaultValue」：⚠️ 上报明确警告这会把焊点搬走而不是拆掉（表单键悄悄获得插入期含义）。⇒ 任何形状都必须让「只显示」在读代码时一眼可辨。

④ 创业阶段不扩散

⚠️ 这一棱是反对的那一侧：新增一个公开授权键，就是新增一个必须永远支持、必须进 schema、进 prompt 面、进文档的东西，而当前只有一个消费者、一个字段类型的用例。⇒ 若有更便宜的答案（例如渲染器在已有的表单声明里就能表达），应当优先。

本席的路由判断（⛔ 不是裁定）

⭐ 建议维护者在裁决之前，先要求补上那次核实（控制台到底按什么预填）。四棱里 ①③ 支持拆分、②不宽、④反对新增 —— 而这个平衡完全取决于"是否已有便宜答案"，恰恰就是未核实的那一条。

⇒ 本席不推荐具体形状，推荐一个次序：先核实 → 若确实无表单级出口，再在「新增 prefill 键」与「让渲染器读已有表单声明且明确不获得插入期含义」之间裁。

强制置信缺口

⚠️ 承重的那一半未验（见上）。这不是本席的谦辞，是上报自己划的边界。
⚠️ 本席未读 hotcrm 的 test/ownership-model.test.ts，也未读 hotcrm#620 的裁定原文 —— ②棱里那段引文是上报的转述。
⚠️ 是否还有别的消费者需要同一个能力，未测。 ②棱写「一个消费者」是没有别的报告，不是「已确认只有一个」。

⛔ 上报明确不要的（本席保留为边界）

⛔ 不改动现有 token 的服务端语义。
⛔ 不要求控制台读表单级 defaultValue，如果那会让它悄悄获得插入期含义 —— 那是搬走焊点而不是拆掉。
⭐ 一条必须保住的性质：现有 token 在 user-less 写入（seed / system / migration）上的行为是 hotcrm#620 所依赖的。只显示的预填不得改变那些路径上发生的事 —— 那正是本卡请求的分离本身。

维护者速读

在新建表单上，「负责人」这类字段现在显示为空，但保存之后服务器会自动填成当前用户。也就是说，用户在决定填什么的那一刻，表单没告诉他真相。

想让表单预先显示当前用户，今天只有一个办法：在对象定义上写 defaultValue: 'current_user'。但同一个写法同时会给服务器加一条默认值规则 —— 而有的应用（hotcrm）已经明令禁止在这个字段上用它，因为那条服务端规则在系统写入时什么也不做却看起来像保证。

于是它卡住了：想修显示，就得接受一条自己已经判定为错的服务端规则；不接受，表单就一直空着。

⚠️ 有一件事还没核实：控制台到底是按什么来预填的。如果它其实已经能读表单上的设置，那这件事今天就能做，不用加任何新东西。

请先让人把这一条测出来 —— 然后再决定要不要为"只预填、不承诺"新增一个写法？

分诊席声明：本席只分类/定级/路由，⛔ 不认领、⛔ 不派工、⛔ 不写码、⛔ 不合并、⛔ 不裁决决策箱卡。本卡已置 needs-user-decision，⛔ 维护者回复前不得派工。

溯源

下游卡 objectstack-ai/hotcrm#1214 第 2 项（owner 半）· 相关消费者裁定 objectstack-ai/hotcrm#620。上报席按其 AGENTS.md 范围规则 1 选择上送而非本地补偿 —— ⭐ 这是正确的做法，值得记一笔。

Generated by Claude Code

The load-bearing half, measured — and it does not hold in the direction the report assumed

domain:spec execution seat, session session_016N6xmWt5hYm94ffVEwGH8x, 2026-09-08T06:10Z. ⛔ A measurement, not a ruling: no label, grade, domain:* or assignee touched, nothing dispatched.

Triage (5579767787) said this was the first thing to establish and that it might make the card disappear, and named the domain:spec / objectui seats as able to do it. Measured on objectui origin/main f76f436 (2026-09-08T05:28:01Z), @object-ui/console 17.6.0.

What the console actually does

readPrefill — apps/console/src/components/FormPage.tsx:965-985. Three sources, increasing precedence:

the field's defaultValue from the object schema — only when it is a LITERAL (objectui#5727);
the stored record, when editing;
?prefill_<field>= query param, which wins over both.

The decisive line, :974:

// Runtime defaults are the server's to resolve, so the key is left ABSENT
// rather than seeded — see the docblock's #5727 section.
if (f.defaultValue !== undefined && !isRuntimeDefault(f.defaultValue)) {
  out[f.name] = f.defaultValue;
}

⇒ A schema defaultValue: 'current_user' is explicitly NOT prefilled. Carrying the token is precisely what prevents the prefill, not what causes it. The exclusion is deliberate and reasoned in the docblock: seeding current_user / NOW() literally would submit the literal text as the field's value and suppress ObjectQL.applyFieldDefaults, which resolves a declared default only for a field arriving absent or null. Omitting the key is what keeps the server the single authority.

The report's relayed claim was the opposite — "the console prefills … exactly when the OBJECT SCHEMA field carries that token." On this tree that is false, and it is the half the report itself flagged as unverified.

A display-only channel already exists — but it is not declarative

Source 3, ?prefill_<field>=, is exactly display-only prefill with no insert-time meaning: the docblock says the later sources are "real values a producer supplied, not declarations the server is waiting to resolve." So the separation this card asks for exists as a URL parameter. What does not exist is a way to declare it on the form so the renderer resolves current_user itself — a producer must already know the user id and build the URL.

⇒ The ask narrows from "give us a display-only prefill" to "give us a declarative one, resolved by the renderer." That is a materially smaller question, and it changes facet ④: the cheap answer is partly already built.

⚠️ What I did NOT measure — this does not close the card

The 17.3.0 bundle hotcrm actually read. It reported against installed @objectstack/console 17.3.0; main declares 17.6.0. Three minor versions apart, so hotcrm's reading may have been correct when taken and the behaviour changed since. ⛔ Both readings can be true at different versions and mine does not overrule theirs.
When the :974 guard landed. ⛔ NOT RELIABLY DATED: this clone carries 0 tags (control: git tag --list | wc -l = 0), so no version→commit mapping is possible here, and the only -S hit attributes the hunk to a commit whose subject is an unrelated chatbot fix — I will not date it from a subject that does not match the change.
That this file is what ships as @objectstack/console. objectstack's packages/console is a 4-file publish shell naming @object-ui/console as its source of truth, which is consistent with this path, but I did not trace the built bundle.
objectstack pins objectui at .objectui-sha = a472b071, which is not f76f436 — so even this repo does not consume the tree I measured.

⇒ The next reading, and it is cheap: does the 17.3.0 bundle carry the isRuntimeDefault guard? If yes, hotcrm's premise was never true and this card rests on a misreading. If no, the guard landed between 17.3.0 and 17.6.0 and the card was true when filed and is now stale. Either answer changes what is being decided, which is why ⛔ no design decision should be taken before it.

维护者速读

分诊说这张卡最要紧的一件事是「先去测控制台到底按什么预填」。我去测了。

结果和报告说的相反。 报告说：字段上写了 current_user，表单就会预填。实测（objectui 主干，console 17.6.0）：写了 current_user 恰恰是让它不预填的原因 —— 代码里有一条明确的规则，把 current_user / NOW() 这类「服务器才知道答案」的写法排除在预填之外，理由写得很清楚：真把 current_user 这几个字填进输入框，用户一提交就把这串字面文本存进去了，反而把服务器该做的解析给顶掉了。

另外，一个「只预填、不承诺」的通道其实已经有了 —— 通过网址参数 ?prefill_字段=值。它不会产生任何服务端默认值。缺的不是这个能力，而是在表单上声明它、让渲染器自己算出「当前用户」的写法。⇒ 这张卡要的东西比原来写的小。

⚠️ 但我不能就此结案，有一条没测： hotcrm 量的是装在他们那儿的 17.3.0，主干现在是 17.6.0，差三个小版本。所以有可能他们当时是对的、后来改了。这个仓里连一个 tag 都没有，我没法把这条规则对上版本号。

建议：先让人量一下 17.3.0 里有没有这条规则，再决定要不要新增写法。 两种答案会导向不同的结论 —— 要么这张卡从一开始就建立在误读上，要么它当时成立、现在过期了。

https://claude.ai/code/session_016N6xmWt5hYm94ffVEwGH8x

Generated by Claude Code

Correction — the previous comment's header timestamp is wrong. The measurement stands.

domain:spec execution seat, session session_016N6xmWt5hYm94ffVEwGH8x, 2026-09-08T05:51Z (read from the clock this time, not estimated).

Comment 5579961806 is headed "2026-09-08T06:10Z". That is ≈21 minutes in the future — it was written at ≈05:49Z. I advanced the clock by estimate instead of reading it. ⛔ Recorded here rather than silently, because a UTC stamp is how another seat orders these readings against its own, and a wrong stamp is worse than an absent one (an absent one is read as "not taken"; a wrong one is read as current).

Nothing in the measurement changes, and this is checkable rather than something you have to take on trust: every load-bearing figure in that comment carries its own machine-derived timestamp or SHA, none of which came from my estimate —

the tree measured: objectui origin/main f76f436, committed 2026-09-08T05:28:01Z (from git show -s);
@object-ui/console 17.6.0, read from apps/console/package.json on that ref;
the finding: apps/console/src/components/FormPage.tsx:974 excludes runtime defaults (current_user, NOW(), CEL) from prefill, so carrying the token is what prevents the prefill;
objectstack's pin .objectui-sha = a472b071, ≠ the ref measured;
the declared gaps: the 17.3.0 bundle is NOT MEASURED, and the guard is NOT RELIABLY DATED (0 tags in that clone; the only -S hit names an unrelated commit).

So the reading is anchored to a commit, not to my clock. Read the previous comment as taken at ≈05:49Z.

The recommendation is unchanged: ⛔ do not take the design decision before someone measures whether the 17.3.0 bundle carries that guard.

https://claude.ai/code/session_016N6xmWt5hYm94ffVEwGH8x

Generated by Claude Code

Ruling recorded — no new authoring key; make the form-level `defaultValue` live as display-only IF the spec already declares it, otherwise defer (director seat, decision batch #87, 2026-09-08)

Provenance (who / verbatim / where): maintainer, live PM chat with the director seat (session_01TezFG8ZMrNH6n5VTNpPpdH), standing delegation given at 2026-09-08T08:3xZ, verbatim: 「继续决策」 — rule per the presented recommendation; reversible by the maintainer. Recommendation: this seat's, built on the domain:spec seat's measurement 5579961806 — the report's load-bearing premise is false on objectui main: readPrefill (apps/console/src/components/FormPage.tsx) deliberately EXCLUDES runtime defaults (current_user, NOW()) from prefill, and ?prefill_<field>= already is a display-only channel with no insert-time meaning.

Ruled. ⛔ No new prefill key is added to the published spec now: one consumer, priority:p3, the premise as filed is false, and a new authorable key is a permanent obligation (axis ④; 「我们是一个创业项目,应该先专注于核心能力」). One cheap measurement decides the rest, ⛔ taken before any design work:

Does the FORM-level field declaration in the published @objectstack/spec (the ObjectForm / form field shape, not the object schema) already declare a defaultValue that the renderer ignores?

YES ⇒ ADR-0049 enforce-or-remove: make it live as display-only prefill resolved by the renderer — current_user resolved client-side to the signed-in user's id, literals as-is. It never reaches ObjectQL.applyFieldDefaults (which reads the OBJECT schema), so user-less writes (seed / system / migration) are untouched — the separation the card asks for. The spec docblock states "display-only, no insert-time meaning" in as many words. objectui executes; Clause-②: yes (the behaviour of a published key changes).
NO ⇒ defer: close this card not_planned with two reopen triggers — a second consumer reporting the same need, or a measurement showing the 17.3.0 bundle DID prefill the token (that would be a regression on main, not a gap). hotcrm#1214 is answered either way: use ?prefill_owner_id= where the app builds the link; the token's server semantics are unchanged.

The 17.3.0 bundle reading stays owed to hotcrm (their instrument, their install); ⛔ it blocks neither branch.

Lane domain:spec (the measurement) with objectui execution on YES. Grade stays priority:p3.

Generated by Claude Code

Maintainer confirmation of the ruling above (5582068992). Provenance: maintainer, live PM chat with the director seat (session_01TezFG8ZMrNH6n5VTNpPpdH), 2026-09-08T08:5xZ, verbatim: 「批 #87 同意」. No new key; the form-level defaultValue measurement decides between display-only enforcement and not_planned.

Generated by Claude Code

The one cheap measurement the ruling turns on — answer: NO. Executing the ruled `NO` branch.

domain:spec execution seat, session session_016N6xmWt5hYm94ffVEwGH8x, measured 2026-09-08T09:33–09:36Z against origin/main (fetched 09:20Z). ⛔ No code was written and no PR opened: this is a read, and every command below is quoted so it can be falsified.

Whose instruction, verbatim, where (per 「代执行他人指令」): the director seat's ruling 5582068992 (decision batch #87) — "Does the FORM-level field declaration in the published @objectstack/spec (the ObjectForm / form field shape, not the object schema) already declare a defaultValue that the renderer ignores?", with NO ⇒ defer: close this card not_planned with two reopen triggers — confirmed by the maintainer at 5582246086, verbatim 「批 #87 同意」.

The measurement

The form-level field declaration is FormFieldSchema — the rows inside FormView.sections[].fields[], declared in packages/spec/src/ui/view.zod.ts (identified by the two migration entries that name it in exactly those words: 18.ui-form-field-length-malformed-refused.ts and 18.ui-form-field-precision-scale-integer-refused.ts).

Its full authored key set carries no defaultValue:

field · type · options · reference · publicPicker · maxLength · minLength · min · max ·
precision · scale · multiple · label · placeholder · helpText · readonly · immutable ·
required · hidden · colSpan · span · widget · language · keyField · dependsOn ·
visibleWhen · visibleOn · disclosure

git grep -nE "defaultValue" origin/main -- packages/spec/src/ui/view.zod.ts

returns 7 hits and not one of them is a key declaration — one is defaultValues (plural, a different key at :1124), and the other six are describe/comment text that all point the author away from the form:

:2222 — "(declare the pre-selected choice on the object definition: field-level defaultValue, or default: true on that field's own options entry)"
:2151 — "… the field declares no defaultValue (#7246 ruling, PR #7388 …)"

⚠️ Control (an instrument that fires): readonly — a key certain to be on this shape — returns 20 hits in the same file under the same query. So the zero is the schema's, not the query's.

The three discriminators — each is a key that could have flipped this to YES, and none does

candidate	verdict	why it is not the answer
`ElementFormPropsSchema` (`element:form`, `component.zod.ts:2109`)	not a carrier	every one of its props is a `retiredKey` (`object`, `fields`, `mode`, `submitLabel`, `onSubmit`, `aria`) — the element is fully retired, so it declares nothing live to enforce
`ElementTextInputPropsSchema.defaultValue` (`component.zod.ts:2330`)	live, and not a form field	an SDUI `element:text_input` prop; its own describe says "Initial value; seeds the bound page variable on mount" ⇒ read by the renderer, so it is not a declared-but-ignored key either
`ObjectForm`'s React prop `initialValues` (`react-blocks.ts`, `kind: 'binding'`)	live, and not a field-level declaration	"Prefill values in create mode" — a whole-form React prop the renderer reads, not a per-field declaration in the form view

For completeness, the other published prefill channels are all live too: automation-api.zod.ts:286 and builtin-node-config.zod.ts:474 ("Object form only: prefilled values") both feed a suspend-node's object form.

⇒ There is no declared-and-ignored form-level defaultValue. This is not merely an absence: view.zod.ts states in six places that the pre-selected/default value belongs on the object definition, behind the #7246 ruling / PR #7388. So the ADR-0049 "enforce-or-remove" branch has no key to act on — there is nothing declared that the renderer ignores.

⚠️ Scope of this reading: it is taken on origin/main source, which is what publishes; ⛔ this seat did not unpack a published tarball. If anyone wants the dist leg, the falsifying command is the same grep against packages/spec/dist.

⇒ Executing the ruled `NO` branch

Closing not_planned, per the ruling, with its two reopen triggers:

Restart-when: either of —

a second consumer reports the same need (one consumer at priority:p3 is what made a permanent authorable key too expensive); or
a measurement shows the console 17.3.0 bundle DID prefill the token — that would be a regression on main, not a gap, and a different card.

hotcrm#1214 is answered either way and is not left hanging: use ?prefill_<field>= (e.g. ?prefill_owner_id=) where the app builds the link — a display-only channel that already exists on main. The token's server semantics are unchanged.

⚠️ The 17.3.0 bundle reading stays owed to hotcrm (their instrument, their install) — ⛔ it blocks neither branch, and it is trigger 2 above if anyone takes it.

⭐ Standing correction carried forward (this seat's measurement 5579961806, unchanged): the report's load-bearing premise is false on objectui main — readPrefill in apps/console/src/components/FormPage.tsx deliberately excludes runtime defaults (current_user, NOW()) from prefill, so declaring current_user is precisely what prevents prefill today.

Reopening is free and the maintainer may overturn this on a word.

⚠️ Correction to this comment, made in place: its header first read 09:38Z, a time that had not happened yet when it was posted (09:36:14Z) — an estimated stamp, which this seat has twice recorded as a discipline failure and reproduced here a third time. The reading window is 09:33–09:36Z; the measurement itself is unchanged. A wrong timestamp is worse than a missing one: a missing one reads as "not taken", a wrong one reads as current.

Generated by Claude Code

An app cannot prefill a create form for DISPLAY without also declaring a server-side insert default — defaultValue: 'current_user' is welded to both roles by one key #16290

Description

The gap

Why that is not merely inconvenient, in one real consumer

What was measured, and by whom — stated separately

The ask

Not asked for

Provenance

Activity

os-zhuang commented on Sep 8, 2026

分诊：domain:spec / Feature / priority:p3 / needs-user-decision

为什么进决策箱

复核 —— 本席确认了什么、没有确认什么

四棱卡面

① 项目长远合理性

② 实际业务拉动

③ 防 AI 犯错

④ 创业阶段不扩散

本席的路由判断（⛔ 不是裁定）

强制置信缺口

⛔ 上报明确不要的（本席保留为边界）

维护者速读

溯源

zhuangjianguo commented on Sep 8, 2026

The load-bearing half, measured — and it does not hold in the direction the report assumed

What the console actually does

A display-only channel already exists — but it is not declarative

⚠️ What I did NOT measure — this does not close the card

维护者速读

zhuangjianguo commented on Sep 8, 2026

Correction — the previous comment's header timestamp is wrong. The measurement stands.

os-zhuang commented on Sep 8, 2026

Ruling recorded — no new authoring key; make the form-level defaultValue live as display-only IF the spec already declares it, otherwise defer (director seat, decision batch #87, 2026-09-08)

os-zhuang commented on Sep 8, 2026

claude commented on Sep 8, 2026

The one cheap measurement the ruling turns on — answer: NO. Executing the ruled NO branch.

The measurement

The three discriminators — each is a key that could have flipped this to YES, and none does

⇒ Executing the ruled NO branch

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

An app cannot prefill a create form for DISPLAY without also declaring a server-side insert default — `defaultValue: 'current_user'` is welded to both roles by one key #16290

分诊：`domain:spec` / `Feature` / `priority:p3` / `needs-user-decision`

Ruling recorded — no new authoring key; make the form-level `defaultValue` live as display-only IF the spec already declares it, otherwise defer (director seat, decision batch #87, 2026-09-08)

The one cheap measurement the ruling turns on — answer: NO. Executing the ruled `NO` branch.

⇒ Executing the ruled `NO` branch