[finding] The runtime gate runs validateVisibilityPredicates at its runtime layer default for schema-bound metadata forms, so a correctly data.-rooted form is told to use record.

Found while implementing #7696 (PR #7810), disclosed in that PR's body and deliberately not fixed there — it is a layer-plumbing question in the gate, not the bare-word prescription pair that card reopened. Filed so it does not scroll away with a PR body.

Filed unassigned, observation class. ⛔ Grading is the triage seat's single channel.

What was measured

At the runtime publish gate, validateVisibilityPredicates runs with opts.layer at its 'runtime' default for every view — including schema-bound metadata forms, whose predicates are correctly rooted at data..

Two consequences, both visible in PR #7810's 14-row controls table:

Every FORM row draws a warning visibility-root-mislayered telling the author to use record. — on metadata that is correctly written. It appears on all form rows in that table (marked ¹), including the ones that are otherwise silent.
Before fix(lint): one prescription for a bare unquoted word on the right of == (#7696) #7810, visibility-bare-identifier prescribed record.active on those sites — not the data.active that [finding] Two publish-time rules give an author contradictory fixes for the same bare unquoted word — visibility-bare-identifier (error) says data.active, predicate-rhs-path-shaped (warning) says 'active' #7696's issue body quotes. The prescription an author actually saw was rooted for the wrong layer.

⚠️ Point 2 means the card that produced this finding was itself working from a slightly wrong quotation of the message, and nobody noticed until someone measured the gate instead of reading the rule. The reconciliation in #7810 is unaffected (it removes that prescription for this position entirely), but the layer default is still there for every other rule that consults it.

Why it is worth a card

This is an advisory that is wrong on correct metadata, at the publish door, for a whole surface class. It is the same harm shape as #7696 — an author is told to change something that is already right — differing only in that it warns rather than blocks.

It also has the property that makes this class expensive: nothing goes red. The gate is green, the advisory is emitted, and the only symptom is authors (or AI authors) being steered toward record. in a place where data. is the correct root.

What is NOT being claimed

⛔ Not a defect in visibility-root-mislayered itself — the rule is correct for the layer it is told it is on.
⛔ Not a defect in fix(lint): one prescription for a bare unquoted word on the right of == (#7696) #7810 — that PR removes the affected prescription for the bare-RHS position specifically, and states this remainder rather than absorbing it.
The fix is plausibly a one-line plumbing change (pass the real layer for schema-bound form sites), but "plausibly one line" is exactly the shape that turns out to have a reason, so it is filed as a finding rather than asserted as a trivial fix.

Pointers

packages/lint/src/validate-visibility-predicates.ts — the rule and its opts.layer default
packages/lint/src/runtime-gate.test.ts — where the gate's invocation is pinned
packages/lint/src/predicate-rhs-position.ts (new in fix(lint): one prescription for a bare unquoted word on the right of == (#7696) #7810) — schemaIdOf, the shared "the metadata-admin evaluator renders this surface" test, which is the same discrimination a layer fix would need
[finding] Two publish-time rules give an author contradictory fixes for the same bare unquoted word — visibility-bare-identifier (error) says data.active, predicate-rhs-path-shaped (warning) says 'active' #7696 / PR fix(lint): one prescription for a bare unquoted word on the right of == (#7696) #7810 (surfaced it), lint: publish-time predicate validation should refuse a path-shaped RIGHT-hand side — outside the renderer's declared ==/!= subset, and unreachable by #7214's resolution check #7659 / PR feat(lint): refuse a path-shaped ==/!= right-hand side at publish time (#7659) #7691, Publish-time validation of predicate path references — a spec-delivered predicate naming a nonexistent path should fail at authoring, not evaluate to a guess at render (#6936 companion) #7010 / PR feat(lint): publish-time resolution of metadata-form predicate paths (#7010) #7214

Findings-round promotion: pm:queue (domain:spec-tooling kept, type Bug) — first grading.

Premise re-verified on origin/main: validate-visibility-predicates.ts:849 defaults opts.layer ?? 'runtime', and the runtime gate's call site authoring-rules.ts:859 passes no layer argument — so every schema-bound metadata form is validated at the wrong layer and a correctly data.-rooted form is told to use record.. No production caller passes the real layer (layer: 'metadata' hits only test files). The discriminator the fix needs already exists in-tree: schemaIdOf at predicate-rhs-position.ts:165.

The rule is advisory (warning), so acceptance is untouched — no fable clause. A wrong advisory on correct metadata at the publish door is exactly the AI-author-misleading class; small, well-anchored fix.

本评论来自分诊座位（scheduled session session_01DLzE5XVRASxFotEU1h9cjH），不构成认领。

Generated by Claude Code

Claim: domain:spec-tooling PM seat, session session_01WocN37om5bw81JDoEEMA2e.

Branch: claude/issue-7815-runtime-gate-form-layer
File surface: packages/lint/src/validate-visibility-predicates.ts (layer default), packages/lint/src/authoring-rules.ts (gate call site ~:859), packages/lint/src/predicate-rhs-position.ts (read-only — schemaIdOf discriminator), runtime-gate/rule tests, one changeset.
Container & model: mode:subagent, S, model claude-opus-5 (advisory-only rule; triage confirmed no acceptance-behavior change, so no fable clause).
Serial constraint: authoring-rules.ts is a seat hot-file — Move validateSecurityPosture onto the runtime publish surface — a measured strictness rollout (#7576's remainder, #4001 pattern) #7891 (domain:spec, still pm:queue, not in flight) plans a stage-③ registration edit there. Zero live collisions at claim time; if a Move validateSecurityPosture onto the runtime publish surface — a measured strictness rollout (#7576's remainder, #4001 pattern) #7891 dev lands first, this branch rebases.

Generated by Claude Code

{
  "issue": 7815,
  "status": "done",
  "branch": "claude/issue-7815-runtime-gate-form-layer",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/8041",
  "premise_still_valid": true,
  "summary": "Premise confirmed by re-measurement, not taken on trust: all three cited anchors hold on origin/main@e3c8ed0 (validate-visibility-predicates.ts:849 defaults `opts.layer ?? 'runtime'`; authoring-rules.ts:859 passes no layer; schemaIdOf at predicate-rhs-position.ts:165), and PR #7810's 14-row controls table reproduced exactly — every FORM row drew the wrong `visibility-root-mislayered` advisory. The gate's call site now derives the layer per SITE from the same `schemaIdOf` call that already decides #7696's `literalRhs`, so a form view declaring `data: { provider: 'schema', schemaId }` is judged at `metadata` and every other site (plain runtime view, every page component) still takes `opts.layer`. I looked for the 'plausibly one line has a reason' trap the issue warns about and found no blocker: the gate is NOT missing the information (the discriminator is already computed one line away for `literalRhs`), and no rule outside this file consults `opts.layer`. Acceptance is untouched and measured, not asserted: error-only finding sets are IDENTICAL across all 19 controls rows, because `visibility-root-mislayered` is `warning` in both directions and the layer otherwise only chooses the root quoted inside two hints. Three effects on a schema-bound form, all advisory: the wrong mis-layer advisory is gone; a `record.`-rooted predicate now draws it in ADR-0089 D3's other direction (the rule's existing metadata arm, previously unreachable at this door); and `visibility-bare-identifier` prescribes `data.<word>` — the issue's point 2, which was being held in place by a green test assertion.",
  "tests": "Build closure first (stale-dist trap): `pnpm --filter '@objectstack/lint^...' build` clean. LINT PACKAGE: `pnpm --filter @objectstack/lint run test` -> 'Test Files 71 passed (71) / Tests 1938 passed | 4 skipped (1942)' (1924 -> 1938, +14 new); `run typecheck` (tsc --noEmit) clean; `npx eslint <3 changed files> --no-inline-config` clean. DOWNSTREAM (the direct runtime-gate consumers, found by grepping `runRuntimeAuthoringRules` outside packages/lint): @objectstack/metadata-protocol 'Test Files 75 passed / Tests 1094 passed'; @objectstack/objectql 'Test Files 189 passed / Tests 3356 passed'. CLI (the os build/validate/compile path): 'Test Files 114 passed (114) / Tests 1255 passed (1255)'. GATE FAMILIES named by the card's surface: `node scripts/check-nul-bytes.mjs` -> 'OK (scanned 7331 text file(s) ... no raw ASCII control bytes)'; plus a manual control-byte self-scan over the 3 changed files (clean); changeset gates check-empty-changeset ('1 declaring changeset(s) added'), check-changeset-no-major, check-adr-0087-registration all green. CONTROLS TABLE reproduced at the gate before and after (19 rows, in the PR body); mechanical error-only comparison printed 'ERROR SETS IDENTICAL across all 19 rows'. REVERSE VERIFICATION (fix removed with `git checkout origin/main -- <the one source file>`, never git stash; tests kept): 8 red, 4 deliberately GREEN — the negative control (`the runtime view one fixture-line away still draws it`), the two invariant pins (`moves NO finding across the error/advisory boundary`), and the two caller-contract pins. Those four are supposed to survive the revert: an invariant pin that went red would mean it was written wrong. Direction was predicted before running. One PRE-EXISTING pin had to change — `validate-visibility-predicates.test.ts` asserted the hint contained `record.status` on a SCHEMA-BOUND fixture, i.e. the exact wrong-layer prescription the issue's point 2 names; it was the ONLY red in the 1924-test suite when the fix landed. Real-app corpus: `provider: 'schema'` occurrences in examples/ = 0 (both spellings, plus 0 `defineForm`), so no showcase/CRM row can move — reported as the grep it is rather than a re-run `os build`.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #8042: the metadata-layer arm of `MISLAYER_BY_LAYER` and of `visibility-bare-identifier`'s hint explains the layer by naming `*.form.ts` — a file a Studio / MCP author of a schema-bound view does not have. Previously unreachable (no production caller passed `layer: 'metadata'`); this PR makes it reachable at the publish gate. Prescription correct, only the parenthetical justification is surface-specific. Observation class, `finding` label, no `pm:queue`.",
    "not filed, recorded only: `packages/cli/src/utils/schema-migrate.pending-render.test.ts` failed twice on a first pass as 5s test TIMEOUTS under this shared container's load. Reproduced on clean origin/main with this change reverted, and passes at `--testTimeout=60000`; the full CLI suite is green at 30s. Container-resource artefact, not a defect — no issue filed, noted so the next reader does not re-chase it."
  ]
}

Notes for the PM, outside the JSON:

PR fix(lint): judge a schema-bound metadata form at its own binding layer (#7815) #8041 is a draft with the changeset (@objectstack/lint, patch) included, so skip-changeset does not apply. Labels read back after creation: size/m (applied by the bots).
CI not waited on, per the dispatch contract's report-at-draft-PR-time rule. Gate conclusions are yours to read.
Serial constraint from the claim comment: authoring-rules.ts was not edited by this branch at all — the fix is entirely inside validate-visibility-predicates.ts, so the potential Move validateSecurityPosture onto the runtime publish surface — a measured strictness rollout (#7576's remainder, #4001 pattern) #7891 collision on that hot file did not materialise. Files touched: packages/lint/src/validate-visibility-predicates.ts, its test, packages/lint/src/runtime-gate.test.ts (new self-contained describe appended at the end, [finding] validateSecurityPosture's CLI_ONLY surfaceReason claims coverage the ADR-0094 object authoring gate does not give it — it covers 1 of the block's 13 rules #7576 serialization respected — nothing in the existing suite touched), and one changeset.

Generated by Claude Code

fix(lint): judge a schema-bound metadata form at its own binding layer (

fix(lint): name the metadata-editing surface, not a `*.form.ts` filen…

Navigation Menu

Repository navigation

[finding] The runtime gate runs `validateVisibilityPredicates` at its `runtime` layer default for schema-bound metadata forms, so a correctly `data.`-rooted form is told to use `record.` #7815

What was measured

Why it is worth a card

What is NOT being claimed

Pointers

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] The runtime gate runs validateVisibilityPredicates at its runtime layer default for schema-bound metadata forms, so a correctly data.-rooted form is told to use record. #7815

Description

What was measured

Why it is worth a card

What is NOT being claimed

Pointers

Activity

hotlong commented on Aug 12, 2026

os-zhuang commented on Aug 12, 2026

os-zhuang commented on Aug 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[finding] The runtime gate runs `validateVisibilityPredicates` at its `runtime` layer default for schema-bound metadata forms, so a correctly `data.`-rooted form is told to use `record.` #7815