… the spec's declaration forms, ListViewSchema stops promising phantom defaults (objectstack#4074) (#3020)

Three public types said something different from what the platform accepts,
found by making packages/types' tests compile (#3009) and resolving the
declared p1-spec-alignment.test.ts debt site-by-site.

ActionParam is now the AUTHORING shape, aligned with the spec's input:
name/label/type optional, field/objectOverride added. The spec's primary
declaration form — a bare field reference inheriting label/type/validation/
options from an object field — was unrepresentable while all three were
required. The RESOLVED shape the dialog consumes (after app-shell's
resolveActionParams() inlines the reference) remains core's ActionParamDef,
all three required: authoring and resolved are different types on purpose.
label is the spec's I18nLabel by import — which the new compile-time guard
promptly revealed to be aliased to plain string in the current spec, so no
behavioural widening today; importing the alias means objectui tracks any
future widening automatically.

ListViewInferred is z.input, not z.infer. The spec sub-schemas flowing into
the list-view surface (userActions, tabs→ViewTab, sharing) carry .default()s,
so the inferred output type made userActions.refresh or a tab's pinned/visible
REQUIRED — but nothing on the render path runs .parse(): normalizeListViewSchema
deliberately applies no defaults ("an absent flag stays absent", its own suite).
The output type rejected valid authored metadata while promising renderers
defaults that never arrive; input matches both author and runtime.

FormField.dependsOn is DependsOnInput. The runtime reader
(resolveCascadingOptions) has always accepted a bare name, a list of names, or
{field, param} entries; the public property said string, so array-authored
metadata type-errored while working and the form renderer read the key through
(f as any).dependsOn to get past its own type. The shape now lives in
@object-ui/types next to FormField; core imports and re-exports it; the two
as-any reads in components are typed.

The p1-spec-alignment.test.ts exclusion is gone — its 14 errors resolved:
the "sharing in ObjectUI format" and legacy-ARIA fixtures are re-seated as
normalizer-input dialects (folded by normalizeListViewSchema; asserted
branch-by-branch in core's normalize-list-view.test.ts, the seam where the
fold runs), and the one fixture no surface ever admitted (an ObjectQL triplet
as a spec ViewTab.filter) is corrected to the rule-object form. Every test
file in @object-ui/types is compiled, no exclusions.

Discrimination-checked: reverting ListViewInferred to z.infer, dependsOn to
string, or ActionParam.name to required each fails compile in the now-compiled
tests (TS2739 / TS2322 / TS2741); restored, all projects clean.


Claude-Session: https://claude.ai/code/session_014DBMo8gnFduzgpuSHd5Eje

Co-authored-by: Claude <noreply@anthropic.com>

…engine stops disagreeing with the server (#3103) (#3107)

Five rule types in `data-protocol.ts` were hand-written interfaces labelled
`(ObjectStack Spec v2.0.1)` while the installed spec was 17.0.0-rc.0. Nothing
bound them to the spec, so fifteen majors of drift accumulated with `tsc` silent
and the comment still vouching for it — the planted-premise failure class
objectstack#4115 was filed for.

They are now `z.input` derivations of the spec's schemas. `z.input`, not
`z.infer`: objectui consumes AUTHORED metadata off `/meta`, before the spec's
defaults and ExpressionInput canonicalization run, so `condition` really is
`string | {dialect, source}` and `active`/`events`/`priority` really can be
absent.

What the copies had drifted into, and what each cost the user — the engine is a
client PRE-CHECK of rules `objectql/src/validation/rule-validator.ts` enforces,
so every one of these is a disagreement with the authority:

  - Predicate POLARITY was inverted. The server violates a rule when the
    predicate is TRUE; the engine violated it when FALSE. Every spec-authored
    `script`/`cross_field` rule got the opposite verdict.
  - `conditional` read `condition` + `rules[]` where the spec says `when` +
    `then`/`otherwise` → silent no-op, and `otherwise` never ran at all.
  - `format` read `pattern` where the spec says `regex` → `undefined.test()`
    threw into a catch that reported a VIOLATION, blocking writes the server
    accepts.
  - Envelope-valued conditions hit `expression.trim()`, threw, and read as
    "passes" → silent no-op.
  - An absent `active` disabled the rule; an absent `events` threw. Both arrive
    absent because the spec defaults them at parse time.
  - `initialStates` (objectstack#3165) and `priority` were missing entirely;
    `events: 'delete'` was still advertised after objectstack#3184 retired it.

`unique`/`async`/`range` have no spec counterpart — the spec removed the first
two deliberately (uniqueness → a unique index, since SELECT-then-INSERT is racy;
async → the form layer) — and are now @deprecated, with a test proving the
spec's union rejects them, so the comment is load-bearing rather than decorative.

Gates, each mutation-tested: the compile-time pins in
`validation-rule-spec-parity.test.ts` (live because tsconfig.test.json compiles
it, #3009) go TS1360 when a derivation is reverted, and the engine suite goes red
for polarity, envelope coercion, `otherwise`, `initialStates` and the spec
defaults. `ConditionalValidation.then/otherwise` carry one pinned divergence —
the spec's published types erase them to `unknown` (objectstack#4171) — with an
inverted pin that fails the day upstream fixes it.

Canonicity now rides on the import and the gate, not the comment: `grep
"Spec v2.0.1" packages/types/src/data-protocol.ts` is empty, and objectstack#4115's
ledger drops 120 -> 115.

Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>