`FieldSchema.defaultValue` has the same `z.unknown()` acceptance hole as the action param one, but it is NARROWER — a literal must first be told apart from the runtime-token / CEL vocabulary before it can be checked

[os-zhuang]

Found while implementing #6970 (PR #7126), which closed the same hole one layer up on ActionParamSchema.defaultValue. Filed unassigned per Prime Directive #10. Deliberately not fixed in that PR — it is not the same bug, and unlike #6970 it is not decision-free.

Measured

FieldSchema.defaultValue is z.unknown().optional() (packages/spec/src/data/field.zod.ts:513). Probed against FieldSchema.safeParse on origin/main (2026-08-09):

DEFAULT_VALUE_TOKENS = ["NOW()","current_user"]

FIELD number field + literal "abc" -> ACCEPT
FIELD datetime field + wall clock -> ACCEPT
FIELD select field + non-member -> ACCEPT
FIELD number field + current_user TOKEN -> ACCEPT
FIELD datetime field + NOW() TOKEN -> ACCEPT
FIELD date field + CEL envelope -> ACCEPT

The first three are the residual hole: a literal that can never satisfy the field's own valueSchemaFor contract is accepted silently at authoring.

Why the #6970 fix does NOT transfer

An action param's defaultValue is a pure LITERAL — objectui's ActionParamDialog seeds dialog state with it verbatim and serializeParamValues resolves nothing — so valueSchemaFor is the whole contract, and #6970 could run the default through it unchanged.

A FIELD's defaultValue is polymorphic by design, three legal shapes, documented in packages/spec/src/data/default-value-tokens.ts:

1. a literal ('open', 0, false)
2. a runtime TOKEN — DEFAULT_VALUE_TOKENS: NOW(), current_user
3. an Expression envelope — { dialect: 'cel', source: 'today()' } (ROADMAP §M9.9b)

Running valueSchemaFor naively over this key would reject shipped, correct metadata. Measured instances:

• examples/app-showcase/src/data/objects/field-zoo.object.ts:120 — Field.user({ defaultValue: 'current_user' })
• cloud packages/service-ai/src/objects/*.object.ts — many datetime fields with defaultValue: 'NOW()' (ai-conversation, ai-trace, ai-message, ai-eval-run, ai-eval-case)

datetime + 'NOW()' is legitimate and would fail InstantValueSchema.

What has to be decided before anything is enforced

Any fix must first subtract the token/expression vocabulary, and that subtraction is a real design question rather than a mechanical tightening:

• Is the token set gated per type? Is NOW() legal on a number? Is current_user legal on anything but a user / lookup('sys_user')? Today nothing says.
• The DDL split already documented in default-value-tokens.ts (NOW() becomes a physical column DEFAULT, current_user deliberately does not) suggests the answer is per-token AND per-type, not one flat allow-list.
• A CEL envelope's RESULT type is not knowable at parse time at all, so that shape can only ever be accepted structurally.

That is why this is filed rather than folded into #6970: that card's triage explicitly ruled it "decision-free 的契约收紧 …… 不是新设计", and this one is not.

Why it still matters

Same argument the parent card makes about AI-authored metadata: a wrong literal here is accepted at authoring and only surfaces as bad data (a number column seeded with 'abc') or a runtime failure far from the cause. No shipped metadata in objectstack or cloud currently carries such a literal — the hole is real but has no known live instance, which is why it is being recorded rather than escalated.

Related

• An action param's defaultValue is typed z.unknown(), so a default that can never satisfy the param's own value contract is accepted at authoring time and only 400s at submit #6970 / PR fix(spec): validate action param defaultValue against the param's own value contract (#6970) #7126 — the action-param half, fixed
• ADR-0104 D1 (valueSchemaFor), ADR-0049 enforce-or-remove, ADR-0078

[os-zhuang]

Triage: finding + domain:spec.

• Classification: observation-class. The acceptance hole is real and measured (probe table in the body), but the filer's own reachability audit found no live instance — no shipped metadata in objectstack or cloud carries a literal that would fail its field's value contract; the legitimate carriers are all token/CEL shapes. Nothing a user hits today ⇒ held as finding, per the filer's explicit "recorded rather than escalated". At promotion this card converts to a design decision (per-type/per-token token gating) before any enforcement — the findings-triage round should route it to the maintainer's inbox at that point, not now (the decision is not yet pending; parking it in needs-user-decision today would be the rest: filterAppForUser treats app hidden flag as builder-only access gate — built-in account app returns 404 for all normal users #4829 failure shape in reverse).
• Routing anchor (read, not inferred): packages/spec/src/data/field.zod.ts on origin/main @ 445a0c2 — defaultValue: z.unknown().optional().describe('Default value'), confirmed by direct read; packages/spec/src/data/default-value-tokens.ts exists and documents the token vocabulary. Any fix changes what FieldSchema accepts/rejects ⇒ acceptance-surface change ⇒ domain:spec per the standing spec-split rule (never spec-surface).
• Dedup: repo-scoped open search on defaultValue returns Create dialog ignores a field's defaultValue — a required select with a default renders empty and forces a manual choice #5150 (objectui Create-dialog rendering of defaults — different layer) and objectui: dashboard KPI cards drop the translated widget title/description — the self-contained metric path bypasses tWidgetTitle, and the plugin's private resolveLabel never calls t() #5428 (unrelated i18n). The action-param sibling An action param's defaultValue is typed z.unknown(), so a default that can never satisfy the param's own value contract is accepted at authoring time and only 400s at submit #6970 is closed via PR fix(spec): validate action param defaultValue against the param's own value contract (#6970) #7126. Clean.
• Stale-premise check: verified at origin/main @ 445a0c2 as above; fix(spec): validate action param defaultValue against the param's own value contract (#6970) #7126's merge did not touch FieldSchema.defaultValue.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

CLAIM — measurement dossier only, NO code, NO acceptance change. Spec-lane PM seat (#6017), session session_01PiRUoQkTSBBmpyXBY3cVn2. Dispatching a cloud dev session under the maintainer's acceleration instruction (2026-08-10, verbatim: 「可以用云卡片加速派发 spec 人物」).

Scope discipline: triage above ruled that promotion converts this card into a maintainer design decision (per-type/per-token gating) before any enforcement. This dispatch does not jump that decision — it prepares it. Deliverable is a decision dossier posted as a comment on this card:

1. Full-corpus measurement (objectstack + cloud): every defaultValue occurrence, classified literal / token / CEL-envelope, cross-tabulated token × field-type;
2. The DDL-split constraints from default-value-tokens.ts (NOW() → physical column DEFAULT, current_user deliberately not) spelled out as design inputs;
3. A proposed per-token × per-type gating table (e.g. NOW() ⇒ datetime/date only; current_user ⇒ user-shaped fields only — proposal, not ruling) plus the enforcement mechanics that would mirror fix(spec): validate action param defaultValue against the param's own value contract (#6970) #7126 (valueSchemaFor(…, 'stored') on the literal branch, structural acceptance on the CEL branch);
4. Migration surface if the proposal were adopted: exactly which shipped metadata (if any) would start refusing.

The maintainer then rules accept/amend/reject from the decision inbox; implementation would be a separate card after that ruling. No branch, no PR, no schema edit in this dispatch.

---

Generated by Claude Code

[os-zhuang]

Decision dossier — FieldSchema.defaultValue per-token × per-type gating

Measurement only. No code, no branch, no PR, no schema edit, no changeset. This comment prepares the maintainer's design decision that triage said promotion requires; it does not make it. §3 is a PROPOSAL, explicitly not a ruling.

Measured at objectstack main @ 55da611 (2026-08-10T02:14Z) and cloud main @ 485cbd3. Both repos read-only; git status clean in both at the end of the run. Probes ran against the schema source (packages/spec/src/...) via tsx.

---

0. The acceptance table still holds

Re-probed FieldSchema.safeParse on current main. The issue body's table reproduces exactly, and the hole is wider than the six rows recorded there:

DEFAULT_VALUE_TOKENS = ["NOW()","current_user"]

 number field + literal "abc" -> ACCEPT ← the residual hole
 datetime field + wall clock -> ACCEPT ← "
 select field + non-member -> ACCEPT ← "
 number field + current_user TOKEN -> ACCEPT
 datetime field + NOW() TOKEN -> ACCEPT
 date field + CEL envelope -> ACCEPT
 boolean field + literal 42 -> ACCEPT ← not in the card
 user field + current_user TOKEN -> ACCEPT ← "
 text field + NOW() TOKEN -> ACCEPT ← "
 number field + arbitrary object -> ACCEPT ← "
 number field + function -> ACCEPT ← "

z.unknown() (packages/spec/src/data/field.zod.ts:513) accepts a function, so the key is not even bounded to JSON-serializable metadata.

---

1. Full-corpus census

1a. Method

Two independent passes, because the first disagreed with the second and the second won:

• Static regex pass — flagged 6 candidate defects. Every one was the detector's error: 5 from a 14-line backward type search binding defaultValue to the wrong Field.* builder, and 1 (sys-webhook.object.ts method: 'post' against options GET|POST|…) from not knowing that Field.select(['GET','POST',…]) lowercases option values (field.zod.ts:1011-1044, toSnakeCase). Zero survived. Discarded in favour of the pass below.
• Authoritative pass (used below) — await import() of every object module, reading the normalized field defs the builders actually produce, then valueSchemaFor({type, multiple, options}, 'stored').safeParse(defaultValue) on each literal. cloud object modules resolve @objectstack/spec through a throwaway node_modules symlink (gitignored, nothing committed). 371 rows, 0 failed imports — full coverage, no sampling. There are no .object.yml / .object.json definitions in either repo, so nothing escapes the TS pass.

1b. Population A — shipped object metadata (the population a gate would govern)

371 field-level defaultValue declarations across 113 files in both repos.

class	objectstack	cloud	total
literal	159	80	239
runtime token NOW()	84	47	131
runtime token current_user	1	0	1
CEL envelope	0	0	0
other / none-of-the-three	0	0	0

By package — objectstack: platform-objects 124, plugin-security 26, app-showcase 20, service-messaging 16, plugin-sharing 14, metadata-core 11, rest ≤8. cloud: service-tenant 102, service-ai 14, ee-*-showcase apps 9, security-enterprise 2.

1c. Token × field type (the cross-tab the decision needs)

token	field type	count	where
NOW()	datetime	131	objectstack 84 · cloud 47
NOW()	date	0	—
NOW()	time	0	—
NOW()	anything else	0	—
current_user	user	1	examples/app-showcase/src/data/objects/field-zoo.object.ts:120 (f_owner)
current_user	lookup('sys_user')	0	—
current_user	anything else	0	—

The NOW() population is overwhelmingly audit stamps: created_at ×80, updated_at ×44 — 124 of 131. The remaining 7 are domain timestamps (timestamp, last_seen, run_at, proposed_at, published_at, installed_at, …), all datetime. This matches default-value-tokens.ts:99 ("the ~100 defaultValue: 'NOW()' declarations in the platform objects").

Both tokens today appear on exactly one type each. The vocabulary is in practice already per-type; nothing declares it.

1d. Literal × field type, with the valueSchemaFor verdict

field type	n	valueSchemaFor(…, 'stored')
select (string)	86	86 PASS
boolean (boolean)	71	71 PASS
number (number)	57	57 PASS
text (string)	17	17 PASS
percent (number)	5	5 PASS
toggle / currency / progress	3	3 PASS
total	239	239 PASS · 0 FAIL

Zero live defects in shipped object metadata, both repos. The card's own audit is confirmed by measurement, not by inspection.

1e. Other corpora

• Docs code samples (content/docs): 40 occurrences in 13 files. Of these, 11 are not FieldSchema surfaces at all — flow screen fields (automation/flows.mdx ×6), page variables (ui/pages.mdx ×3), dashboard filters (ui/dashboards.mdx ×1), and FieldMapping.defaultValue (references/shared/mapping.mdx:32) — and 3 are prose mentions, not samples (field-types.mdx:312, schema-design.mdx:240, types.mdx:426). That leaves 26 real field samples, of which two are live defects — §1f.
• Tests / fixtures: 141 occurrences. Of the 72 with a statically resolvable type, 62 pass and 10 would refuse — none of them a field: 9 are the An action param's defaultValue is typed z.unknown(), so a default that can never satisfy the param's own value contract is accepted at authoring time and only 400s at submit #6970 action-param test's own deliberate negative cases (packages/spec/src/ui/action-param-default-value.test.ts) and 1 is a flow-variable test. 0 field-level test fixtures at risk.
• Source / tooling: no consumer constructs a field defaultValue from untrusted input.

1f. Live defects worth naming individually

Both are documented samples in hand-written docs. Neither is any of the three legal shapes, and both are wrong today, independent of whether the proposal is adopted:

1. content/docs/protocol/objectql/schema.mdx:399 — due_datetime: {type: datetime, defaultValue: "daysFromNow(7)" # 7 days from now (CEL)}. The comment says CEL, but this is a bare CEL source string, not the {dialect, source} envelope. Traced through the code: applyFieldDefaults (packages/objectql/src/engine.ts:2412) recognises an envelope only by dv.dialect && typeof dv.source === 'string'; a bare string is not one, is not a token, so it falls to the literal branch at engine.ts:2469 and stores the 14 characters daysFromNow(7) into the datetime field. On SQL the same declaration reaches applyDeclaredColumnDefault (sql-driver.ts:8934-8944), fails all three guards, and is emitted as col.defaultTo('daysFromNow(7)') — a physical column DEFAULT of that string. Probe: valueSchemaFor({type:'datetime'},'stored').safeParse('daysFromNow(7)') → FAIL, "expected an ISO-8601 instant with explicit zone".
2. content/docs/protocol/objectql/schema.mdx:385 — revenue: {type: currency, defaultValue: { value: 0, currency: 'USD' }}. currency is in NUMERIC_VALUE_TYPES, so the stored contract is z.number().finite(). Probe → FAIL, "expected number, received object". The engine stores the object verbatim; the SQL DDL drops it silently (typeof dv === 'object' guard at sql-driver.ts:8942), so the two layers disagree about what the column defaults to.

Neither is shipped metadata, so neither escalates this card off finding — but both are docs bugs a reader will copy, and both are exactly the shape the proposal would catch. Fixing them is docs-only work and does not need this decision.

---

2. Design inputs, read from the code (file:line)

2a. The DDL split is a contract, and it is per-token

packages/spec/src/data/default-value-tokens.ts:32-44 states it as a table, not a comment:

Token	Resolved by	Physical column DEFAULT
NOW()	the database (CURRENT_TIMESTAMP and friends)	yes — the driver's native now-expression
current_user	the engine, from the request's ExecutionContext	none

default-value-tokens.ts:39-44 gives the reason current_user has no DB counterpart: SQL's CURRENT_USER is the connection role, not a sys_user.id, and the engine deliberately leaves the field unset when there is no authenticated user rather than stamp a bogus owner — a column DEFAULT would override precisely that decision (#4560).

2b. Who resolves which token, on which type, today

site	file:line	behaviour
absence test	packages/objectql/src/engine.ts:2410	f.defaultValue == null ⇒ skip. '' is a real default for a field (unlike an action param, where isActionParamValuePresent at packages/spec/src/ui/action-params.zod.ts:129-131 treats blank as absent). Any field-side presence predicate must match the engine, not the action-param one.
CEL envelope	engine.ts:2412-2427	recognised structurally (dv.dialect && typeof dv.source === 'string'), evaluated by ExpressionEngine; failure is a logger.warn, not a throw
current_user	engine.ts:2428-2442	exact match, engine-resolved from execCtx.userId; left unset when unauthenticated
NOW()	engine.ts:2443-2470 → resolveNowDefault engine.ts:2342-2353	case-insensitive, whitespace-tolerant. Resolves per declared type: date ⇒ YYYY-MM-DD, time ⇒ HH:MM:SS[.fff] (zero-ms trimmed), everything else ⇒ full ISO instant
literal	engine.ts:2469	stored verbatim — the branch both §1f defects fall into
SQL DDL	packages/drivers/driver-sql/src/sql-driver.ts:8934-8944	NOW() ⇒ nowColumnDefault(type); any other runtime token ⇒ emit nothing; object ⇒ emit nothing; else literal verbatim
SQL now-expression	sql-driver.ts:8709-8752	dialect-specific per type for time and date (MySQL rejects bare CURRENT_TIMESTAMP on DATE/TIME; Postgres resolves in the server's zone), knex.fn.now() / canonical ISO otherwise
MySQL TIME widening	sql-driver.ts:5876	restates the NOW() default when MODIFY would drop it
schema-drift	packages/drivers/driver-sql/src/schema-drift.ts:440	isAppResolvedDefaultToken ⇒ a physical DEFAULT carrying the token's own spelling is reported as default_mismatch and dropped (#4560)
mongodb / memory drivers	—	no defaultValue consumer at all. The engine is their only resolver.

Consequence for the decision: NOW() is already honored end-to-end on datetime, date, and time — in the engine (resolveNowDefault) and in the DDL (nowColumnDefault), on every dialect. It is not datetime-only. The docs say so explicitly at content/docs/protocol/objectql/types.mdx:426-431: "for date, datetime, and time alike". That the census finds 0 date/time uses is an artifact of what has been authored, not of what is supported.

2c. valueSchemaFor alone cannot subtract the tokens

Probed valueSchemaFor({type}, 'stored') against the two token spellings:

'NOW()' datetime:X date:X time:X number:X text:ok boolean:X user:ok lookup:ok select:ok json:ok
'current_user' datetime:X date:X time:X number:X text:ok boolean:X user:ok lookup:ok select:ok json:ok

Two things fall out, and both are decision-relevant:

• On reference-shaped and string types the token is indistinguishable from a plain value — current_user on a user field passes only by accident, as a would-be record id, not because anything recognised it as a token. A gate that ran valueSchemaFor first and called that "fine" would be right for the wrong reason, and would break the moment ReferenceIdValueSchema tightens its id charset (field-value.zod.ts:336-363 says that widening/tightening is deliberately left open).
• On text, 'NOW()' passes valueSchemaFor as an ordinary string — but the engine matches the token before the literal branch (engine.ts:2443), so resolveNowDefault falls to its default arm and stores an ISO instant into the text field. An author cannot store the literal string NOW() in a text field at all. That is a real asymmetry the gating table has to take a position on (§3, open question Q2).

So the token/expression subtraction must happen first, structurally, and the literal branch must run only on what is left. That is precisely why the #6970 mechanics do not transfer unchanged.

2d. The mechanics #7126 established, and the one obstacle it did not face

packages/spec/src/ui/action.zod.ts:404-460 (commit 445a0c2): a .superRefine appended to ActionParamSchema, before the existing .transform, which (i) skips when the value is absent, (ii) skips when type is unresolvable, (iii) runs valueSchemaFor(def, 'stored'), (iv) on failure raises code:'custom', path:['defaultValue'], with a message naming the param, its type, the offending literal verbatim, the underlying contract message, and the fix. Pinned by packages/spec/src/ui/action-param-default-value.test.ts asserting issue path + code + message content, never a bare success === false.

The obstacle that is new here: field-value.zod.ts:36-37 imports FieldType and AddressSchema from field.zod.ts. A field.zod.ts → field-value.zod.ts import closes an ESM cycle that the action-param fix did not have (action.zod.ts lives in ui/, and field-value.zod reaches only shared/ + data/ — the diff comment at action.zod.ts:6-11 says exactly this, and it does not hold in the other direction). Both sides are lazySchema-wrapped, so it may well be benign at module-eval time, but this is an implementation risk to be discharged with a real build, not assumed. Cheapest escape if it bites: move the shared shapes into a third module, or have the refinement resolve valueSchemaFor through a lazy indirection.

---

3. PROPOSED gating table — PROPOSAL, NOT A RULING

Derived from §1 + §2. The maintainer accepts / amends / rejects; nothing below is implemented.

3a. Shape discrimination, in this order

#	shape	recognised by	check
1	absent	dv == null (matching engine.ts:2410 — '' is present for a field)	skip
2	CEL / Expression envelope	structurally: dv.dialect && typeof dv.source === 'string' (same predicate as engine.ts:2412)	structural acceptance only. The result type is unknowable at parse time; a wrong result type is an ADR-0032 runtime concern, not this gate's
3	runtime token	isNowDefaultToken / isCurrentUserDefaultToken	per-token × per-type table, §3b
4	literal	everything else	valueSchemaFor({type, multiple, options}, 'stored') — the #6970 mechanics one layer down

3b. The per-token × per-type table

token	proposed legal types	rationale (measured, §2b)	shipped uses that would refuse
NOW()	datetime, date, time	resolveNowDefault (engine.ts:2342-2353) and nowColumnDefault (sql-driver.ts:8709-8752) both branch on exactly these three; types.mdx:426-431 documents these three	0 (all 131 are datetime)
current_user	user, and lookup whose reference is sys_user	engine.ts:2428 writes String(execCtx.userId), a sys_user.id; #4560 is the record of what happens when that id lands anywhere else	0 (the single use is user)

multiple: true — a token on a multi-value field is not covered by either resolver (engine.ts:2428 and :2470 both assign a scalar). Proposed: refuse, or defer to Q3.

3c. Enforcement mechanics sketch

Extend the existing superRefine on FieldSchema at packages/spec/src/data/field.zod.ts:896 (which already carries the ADR-0113 storage.notNull × requiredWhen rejection) rather than adding a second one — one refinement block, two rules. Skip when field.type is absent or is an explicitly-open contract (json, code, formula, autonumber — valueSchemaFor returns z.unknown() for those, so the literal branch is already a no-op; the token branch would still apply).

Error naming, following the ADR-0033 design centre (the long-term author of metadata is an AI; the human confirms) and the self-prescribing style already in this file at field.zod.ts:263-268 (UniqueScopeSchema) and in action.zod.ts:451-460: code:'custom', path:['defaultValue'], and a message that carries the field name, its type, the offending value verbatim, why it cannot hold, and the legal alternatives — e.g. for the token branch, "current_user is a runtime token the engine resolves to a sys_user.id (engine.ts applyFieldDefaults); a number field cannot hold one. Use it on a user field or a lookup('sys_user'), or write a literal number." Pin with a table-driven test asserting issue path + code + message content, mirroring action-param-default-value.test.ts.

3d. Open sub-questions the maintainer must still answer

• Q1 — is NOW() on date/time in or out? Both resolvers support it and the docs promise it, but nothing ships it. Proposal says in (refusing it would contradict types.mdx:426). Ruling needed because it is the difference between "codify what the code does" and "narrow to what is used".
• Q2 — NOW() on text (and other string types). Today the engine intercepts it and stores an ISO instant, so the literal 'NOW()' is unstorable in a text field. Refuse it (author probably meant a temporal field), or keep silently intercepting? Either is defensible; the status quo is the one nobody chose.
• Q3 — tokens on multiple: true. Neither resolver produces an array. Refuse, or resolve-then-wrap?
• Q4 — current_user on lookup: does the gate read reference === 'sys_user', or accept any lookup? Reading reference is stricter and matches data: the SQL driver emits the current_user framework token as a literal column DEFAULT, so the database itself writes a non-id into a lookup('sys_user') #4560's failure mode; accepting any lookup is cheaper and cannot false-refuse a federated user table.
• Q5 — near-miss token spellings. default-value-tokens.ts:106-116 deliberately refuses to widen current_user ({current_user}, currentUser) because widening would make a genuinely-intended literal unstorable, and delegates the catch to lint. Should this gate suggest the correct spelling in its message (the CONTEXT_TOKEN_SUGGESTIONS pattern at context-tokens.zod.ts) without accepting it? Cheap, and squarely in the ADR-0033 AI-author frame.
• Q6 — the field-value.zod ↔ field.zod cycle (§2d). An implementation constraint, but it may force a module split, which is a shape decision rather than a mechanical one.

---

4. Migration surface if the proposal were adopted

corpus	occurrences	would start refusing
shipped object metadata — objectstack	244	0
shipped object metadata — cloud	127	0
field-level test fixtures (both repos)	72 resolvable	0
hand-written docs code samples (content/docs)	40 (26 are field samples)	2

Shipped metadata that would start refusing: 0 — verified by executing the proposal's own three branches over all 371 declarations, not by inspection. The card's audit is confirmed.

The only refusals anywhere are the two documented samples in §1f (schema.mdx:399, schema.mdx:385), and both are already wrong today — the gate would be catching real defects, not imposing a migration. A docs-only fix for those two is independent of this decision and does not need the maintainer's ruling.

Non-refusal costs that an implementation card would still carry: the generated export/skill baseline regeneration #7126 needed (api-surface / export-origins read the built dist, so regenerate after pnpm --filter @objectstack/spec build, or unrelated entries silently drop), and whatever the §2d cycle forces.

---

Reproduction

Read-only; nothing written to either repo (git status clean in both). cloud cloned shallow at 485cbd3; its @objectstack/spec resolved through a gitignored node_modules symlink so its object modules could be imported. Census = await import() over every *.object.ts / */objects/*.ts in both repos (371 rows, 0 failed imports), classified by the spec's own isNowDefaultToken / isCurrentUserDefaultToken predicates, literals probed through valueSchemaFor(def,'stored').

---

Generated by Claude Code

[os-zhuang]

OS-DEV-REPORT

{
 "issue": 7127,
 "outcome": "dossier_posted",
 "dossier_comment_url": "https://github.com/objectstack-ai/objectstack/issues/7127#issuecomment-5235337746",
 "census_totals": {
 "method": "await import() of every object module in both repos; normalized field defs; literals probed through valueSchemaFor(def,'stored')",
 "shipped_object_metadata_declarations": 371,
 "files": 113,
 "failed_imports": 0,
 "by_repo": { "objectstack": 244, "cloud": 127 },
 "by_class": {
 "literal": 239,
 "token_NOW()": 131,
 "token_current_user": 1,
 "cel_envelope": 0,
 "other_unknown": 0
 },
 "token_x_type": {
 "NOW() x datetime": 131,
 "NOW() x date": 0,
 "NOW() x time": 0,
 "current_user x user": 1,
 "current_user x lookup(sys_user)": 0
 },
 "literal_verdicts": { "PASS": 239, "FAIL": 0 },
 "other_corpora": {
 "content_docs_occurrences": 40,
 "content_docs_real_field_samples": 26,
 "test_fixture_occurrences": 141,
 "test_fixture_field_level_at_risk": 0
 }
 },
 "live_defects_found": {
 "in_shipped_object_metadata": 0,
 "in_hand_written_docs": 2,
 "detail": [
 "content/docs/protocol/objectql/schema.mdx:399 — datetime + bare CEL source string \"daysFromNow(7)\" (not the {dialect,source} envelope): engine.ts:2469 stores the literal string; sql-driver.ts:8943 emits it as a physical column DEFAULT",
 "content/docs/protocol/objectql/schema.mdx:385 — currency + object literal { value: 0, currency: 'USD' }: stored contract is z.number().finite(); engine stores the object, SQL DDL silently drops it (sql-driver.ts:8942)"
 ],
 "note": "Both are docs-only. Neither escalates this card off `finding`. A docs-only fix is independent of the pending design ruling and needs no maintainer input."
 },
 "cloud_repo_reachable": true,
 "cloud_ref": "485cbd3dac9ea26afabdaeb7c12b941fce8a39b5",
 "objectstack_ref": "55da611",
 "migration_surface_if_proposal_adopted": {
 "shipped_metadata_that_would_refuse": 0,
 "docs_samples_that_would_refuse": 2,
 "test_fixtures_that_would_refuse": 0
 },
 "notes": [
 "SCOPE HELD: no code, no branch, no PR, no schema edit, no changeset. git status clean in BOTH repos at end of run.",
 "Card's own audit CONFIRMED by execution, not inspection: 0 shipped literals fail their field's valueSchemaFor('stored') contract.",
 "NEW design input the card did not have: NOW() is already honored end-to-end on datetime, date AND time — engine resolveNowDefault (engine.ts:2342-2353) and sql nowColumnDefault (sql-driver.ts:8709-8752) both branch on those three, and content/docs/protocol/objectql/types.mdx:426-431 documents all three. A datetime/date-only gate would contradict shipped behaviour and shipped docs.",
 "NEW design input: valueSchemaFor CANNOT subtract the tokens on its own — 'current_user' passes on user/lookup only by accident (as a would-be record id), and 'NOW()' passes on text as a plain string while the engine intercepts it and stores an ISO instant instead. The token subtraction must be structural and must run FIRST.",
 "IMPLEMENTATION RISK flagged for whoever picks up the follow-on card: field-value.zod.ts:36-37 imports from field.zod.ts, so a field.zod -> field-value.zod import closes an ESM cycle that PR #7126 explicitly did not face (action.zod.ts lives in ui/). Both sides are lazySchema-wrapped so it may be benign, but it must be discharged with a real build, not assumed.",
 "6 open sub-questions (Q1-Q6) are listed in the dossier §3d — Q1 (NOW() on date/time) and Q4 (current_user on lookup: read `reference` or accept any lookup) are the two that change the shape of the table, not just its wording.",
 "Detector honesty: a first static-regex pass produced 6 candidate defects; ALL 6 were the detector's own errors (5 wrong-builder type binding, 1 from not knowing Field.select lowercases option values). That pass was discarded and is not the basis of any number above."
 ]
}

---

Generated by Claude Code

[os-zhuang]

PM handoff: dossier delivered → decision now PENDING with the maintainer. Spec-lane PM seat (#6017), session session_01PiRUoQkTSBBmpyXBY3cVn2. pm:dispatched removed; needs-user-decision applied — exactly the point triage said this card converts into a maintainer design decision.

What the dossier (comment 5235337746) established, in one paragraph: 371 shipped defaultValue declarations across both repos, censused by executing every object module — zero would refuse under the proposed gate (239 literals all pass valueSchemaFor(…, 'stored'); 131× NOW() all on datetime; 1× current_user on user). The only refusals anywhere are two hand-written docs samples that are already wrong today (content/docs/protocol/objectql/schema.mdx:399 bare CEL source string stored verbatim and emitted as a physical column DEFAULT; :385 currency object literal the engine stores and the SQL DDL silently drops) — filed separately as a docs-only finding, independent of this ruling.

The ruling asked of the maintainer: accept / amend / reject the §3 gating table — shape discrimination absent → envelope (structural) → token (per-token × per-type) → literal (valueSchemaFor 'stored'), with NOW() ⇒ datetime/date/time and current_user ⇒ user + lookup('sys_user') — plus the six sub-questions in §3d. The two that change the table's shape rather than its wording: Q1 (is NOW() on date/time in? — both resolvers and the docs already support it, nothing ships it) and Q4 (current_user on lookup: read reference === 'sys_user', or accept any lookup?). Implementation would be a separate card after the ruling, and carries the §2d ESM-cycle risk flag.

---

Generated by Claude Code