finding: two `IMPLICIT_FIELDS` sets spread the blanket SYSTEM_FIELDS union with no provenance awareness — candidate sixth/seventh unprovisioned-anchor read sites

[qq9340100]

Observed while implementing #8404 (the fifth blanket-SYSTEM_FIELDS read site, validate-searchable-fields.ts). Filed as an observation, not fixed — #8404's ruling scoped that card to its one module and directed any further site here.

What was surveyed

After #8340 (four sites) and #8404 (the fifth), I swept every non-test module in packages/lint/src that imports SYSTEM_FIELDS, counting anchor-awareness alongside:

module	uses SYSTEM_FIELDS	anchor-aware
validate-flow-template-paths.ts	via helper	yes (#8340)
validate-page-field-bindings.ts	yes	yes (#8340)
validate-react-page-props.ts	yes	yes (#8340)
validate-widget-bindings.ts	yes	yes (#8340)
validate-semantic-roles.ts	via helper	yes (#8116)
validate-searchable-fields.ts	yes	yes (#8404)
validate-hook-body-writes.ts	spread	no
validate-translation-references.ts	spread	no

The last two are the only remaining consumers with no provenance path. Both consume the union by SPREADING it into a rule-local set rather than calling .has on it, which is why a SYSTEM_FIELDS.has grep (the shape #8340 and #8404 were both scoped by) does not surface them:

• validate-hook-body-writes.ts:265 — export const IMPLICIT_FIELDS = new Set([...SYSTEM_FIELDS, '_id', 'name', 'space', 'owner', 'record_type']). Also consumed by validate-action-body-writes.ts, so one gap covers two surfaces.
• validate-translation-references.ts:177 — const IMPLICIT_FIELDS = new Set([...SYSTEM_FIELDS, '_id', 'name', 'space']).

Why they may or may not matter — UNMEASURED, deliberately

I did not measure either, so this card asserts a structural resemblance and nothing more. The two look quite different on inspection, and I expect they resolve differently:

• validate-hook-body-writes is the stronger candidate. Its set answers "may a hook body implicitly WRITE this field", and on an ADR-0015 external object an injected anchor has no storage behind it ([Decision] applySystemFields injects platform anchors into external objects the platform provisions no storage for — three consumers have now independently re-derived "that column is not really there" #7865 / finding: author-time expression validation resolves injected anchors on external objects but cannot warn they are unprovisioned — the #7865 provenance marker is unreachable from @objectstack/lint #8116) — so a write to owner_id there plausibly goes nowhere, which is the same silent degradation on the write axis that lint: view-filter / page-binding field checks resolve against the blanket SYSTEM_FIELDS union, so the #8116 unprovisioned-anchor warning cannot reach filter surfaces #8340 and lint: searchableFields is a FIFTH blanket-SYSTEM_FIELDS read site — a declared anchor on an external object becomes a $searchFields narrowing over a column with no storage #8404 closed on the read axis. What is unmeasured: whether such a write actually degrades silently, or whether the external write path already refuses it somewhere downstream. If the latter, there is no gap here at all.
• validate-translation-references is the weaker candidate, and may well be a non-issue. Its set answers "may a bundle name this field in a translation key". An injected anchor IS in the registered schema and does get rendered, just always empty — so a label for it is arguably legitimate metadata rather than drift, and warning would be the false positive ADR-0072 D1 forbids.

Suggested disposition

Triage as one card or split; the hook-write axis is the one worth measuring first. Whoever takes it should note that the two sites share no helper, so there is no single-point fix — and that the spread-vs-.has consumption shape is itself the reason both were missed twice, which may be worth a gate rather than a third manual sweep.

Related: #4330 (the union's origin), #7865, #8116, #8340, #8404.

[hotlong]

Finding round — PROMOTE. finding → pm:queue, domain:devx, type Task.

Premise re-verified on origin/main @ 00ee416. Both spreads are live at the cited lines:

packages/lint/src/validate-hook-body-writes.ts:265 export const IMPLICIT_FIELDS: ReadonlySet<string> = new Set([
 :266 ...SYSTEM_FIELDS,
 :267 '_id', 'name', 'space', 'owner', 'record_type',
packages/lint/src/validate-translation-references.ts:177 const IMPLICIT_FIELDS: ReadonlySet<string> = new Set([
 :178 ...SYSTEM_FIELDS,

(Method note, since it nearly produced a false negative: a grep for IMPLICIT_FIELDS = new Set returns zero hits — the declarations carry a : ReadonlySet<string> annotation between the name and the =. The zero-hit was cross-checked against a term known to be present (SYSTEM_FIELDS in the same files) before being believed, per the platform-readings rule. Anyone re-measuring this card should grep the bare symbol.)

⭐ The re-verification widened the card. It claims the hook-side set is shared with validate-action-body-writes.ts, i.e. "one gap covers two surfaces". On main there is a third consumer: validate-flow-node-writes.ts imports IMPLICIT_FIELDS from validate-hook-body-writes.js (:87, used at :229 and :257). One gap, three rule surfaces. That strengthens the promote and belongs in the dispatch scope.

Promoted as the sanctioned next site of an in-flight sweep, not as a fresh judgement. #8340 closed four sites, #8116 a fifth path, #8404 the sixth — and #8404's ruling explicitly scoped that card to its one module and directed any further site here. This is that site arriving.

⛔ Scope fence — measure before changing anything.

• Deliverable Add metamodel interfaces for ObjectQL/ObjectUI contract #1 is the measurement the filing correctly declined to guess: on an ADR-0015 external object with an injected (unprovisioned) anchor, does a hook/action/flow body write to that anchor degrade silently, or does the external write path already refuse it downstream? If it already refuses, there is no gap on this axis and the correct delivery is a premise_still_valid: false report with the evidence — that is a good run, ⛔ not a failure, and ⛔ not a reason to ship a change anyway.
• In scope if the measurement confirms the gap: provenance-awareness for validate-hook-body-writes.ts:265's set, covering all three consumer surfaces.
• ⛔ Out of scope: validate-translation-references.ts. The filing's own analysis is that an injected anchor is in the registered schema and is rendered (always empty), so a bundle naming it is arguably legitimate metadata — warning there would be the false positive ADR-0072 D1 forbids. ⛔ Do not touch that set on this card; if the measurement shows otherwise, report the fork rather than acting on it.
• The card's closing suggestion — that the spread-vs-.has consumption shape is itself why both sites were missed twice, and may deserve a gate rather than a third manual sweep — is a separate domain:skills/gate card, ⛔ not a rider here. File it if the work makes the case concrete.

---

Generated by Claude Code

[os-project-manager]

Claim — starting work on this card.

• Session: session_011RB4waLuNbdruCo6X9oobm
• Branch: claude/issue-8663-implicit-fields-provenance

Measure-first per the triage fence: deliverable #1 is the measurement of whether a hook/action/flow body write to an injected (unprovisioned) anchor on an ADR-0015 external object degrades silently or is already refused downstream. validate-translation-references.ts will be measured for the report only — not touched.

Generated by Claude Code

---

Generated by Claude Code

[os-project-manager]

{
 "issue": 8663,
 "status": "done",
 "branch": "claude/issue-8663-implicit-fields-provenance",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/8996",
 "premise_still_valid": true,
 "summary": "MEASURE-FIRST card, and the measurement partly contradicts the card's own framing — reported rather than smoothed over. CANDIDATE 1 (validate-hook-body-writes:265): the gap is REAL but is NEITHER of the two outcomes the triage posed. The write does not degrade silently, and the external write path does not refuse it either — the REMOTE DATABASE rejects it, as an untyped SQLITE_ERROR (no ADR-0112 code/status) that aborts the whole statement. The decisive finding is one the card did not anticipate: a genuinely undeclared name is refused UPSTREAM by the engine's own write-path validator (INVALID_FIELD, on insert AND update, never reaching a driver), so the injected anchor is the ONLY payload key that gets past it — the driver-level failure this rule family exists to prevent is reachable on this path only through the blind spot. Fixed across all three consumer surfaces (hook, action, flow-node) with a new separately-suppressible rule id each, at warning severity per #8340's precedent; the flow-node rule's existence finding keeps its gating error while its provenance finding advises. CANDIDATE 2 (validate-translation-references:177): measured, NO GAP, untouched — confirmed, not merely reasoned. SURPRISE TO SURFACE: there is not one write-enabled external object anywhere in the repo (zero `allowWrites: true`, zero `writable: true` outside the spec's own docstring), so the population reachable today is empty and requires a deliberate admin double opt-in; I judged this closing a hole in shipped machinery rather than capability expansion, but the PM should know the denominator.",
 "tests": "Union run at 9d84c5be9 = HEAD of the branch (quoted from that run). `pnpm --filter @objectstack/lint test` -> 'Test Files 73 passed (73) / Tests 2061 passed (2061)' (14 new). `pnpm --filter @objectstack/lint typecheck` -> clean. MEASUREMENT EVIDENCE (temporary harnesses, deleted before the PR): [A, engine layer, real ObjectQL engine + recording driver, writable external object] A1 registered fields on the federated object = [amount,created_at,created_by,order_id,organization_id,owner_id,owning_business_unit_id,updated_at,updated_by], byte-identical anchor set to the LOCAL control; A2 insert{order_id,owner_id} -> 'threw: NO', driver received {\"order_id\":\"o1\",\"owner_id\":\"usr_phantom\"} (nothing strips it, nothing refuses it); A3 insert{order_id,totally_bogus} -> 'code=INVALID_FIELD', driver received [] ; A4b update{totally_bogus} -> 'code=INVALID_FIELD', driver received [] — the asymmetry that makes the anchor privileged. [B, driver layer, driver-sql on a real remote SQLite table lacking owner_id] B1 insert -> 'SqliteError code=SQLITE_ERROR status=undefined ... table fact_orders has no column named owner_id'; B3 update -> 'SqliteError code=SQLITE_ERROR status=undefined - no such column: owner_id'. [C, candidate 2] applyInjectedSystemColumns on an external doc serves owner_id in /meta with the platform's own label 'Owner' — so a translation key naming it labels a field the user really sees; warning there would be the ADR-0072 D1 false positive. ABLATION (behavioural, not import-level — the four new short-circuits replaced by the original blanket `continue`, every export left in place, applied to source and grep-verified before the run): red exactly as predicted — 'Test Files 3 failed | 70 passed (73) / Tests 4 failed | 2057 passed (2061)', all four 'AssertionError: expected [] to have a length of 1'. Stated honestly: only 4 of the 14 new tests are ablation-proven; the other 10 assert SILENCE (local twin, author-declared column, multi-target branch, non-anchor exemptions, unchanged existence findings) and pass in both directions by construction — false-positive guards, not evidence. Fix was committed BEFORE the ablation so the restore was `git checkout HEAD -- ...`; porcelain clean afterwards, no MM split. GATES derived with scripts/pm/dispatch-gates.mjs against the actual changed paths (not recalled), all green: check:nul-bytes, check:cross-package-test-inputs (both lint.yml and ci.yml spellings), check:changeset-gate-self-tests, check:objectui-changeset, check-adr-0087-registration, check-changeset-no-major, check-empty-changeset, and the test-file convention family check:engine-double-contract, check:where-matcher, check:query-options-erasure, check:type-check-coverage, check:type-check-debt. Re-derived after the docs edit, which ADDED check:docs-audit-scope and check:role-word — both green. check:type-check-debt first REFUSED for an unbuilt closure (that is NOT MEASURED, not 'not applicable'), so the full workspace closure was built and it re-ran: '33 ledger entries re-measured, none above its recorded number'. Labels read back on the PR: documentation, size/m, tests, tooling (all bot-applied). No skip-changeset — a real changeset ships (@objectstack/lint minor), so no label write was owed and none was made.",
 "open_questions": [
 {
 "question": "THIRD OPTION, evaluated as asked, NOT built: should the spread-vs-`.has` consumption shape get a gate rather than a fourth manual sweep? My measurement is that it should, and it is now concrete rather than speculative. The evidence: this card's own site was invisible to two prior sweeps because both were scoped by a `SYSTEM_FIELDS.has` grep, which structurally cannot see a spread — and the triage found a THIRD consumer (validate-flow-node-writes) that the filing itself had missed, by reading imports rather than grepping. So the miss rate of the manual method is now measured at 2 sweeps x 2 sites, plus 1 consumer missed inside the filing. A gate would assert: every module importing SYSTEM_FIELDS either calls `.has` on it directly, or spreads it into a rule-local set that is paired with a provenance check. Note it would need to follow re-exports one hop — validate-flow-node-writes never imports SYSTEM_FIELDS at all, it imports IMPLICIT_FIELDS from the hook rule, so a gate scoped to direct importers would have missed exactly the consumer that was missed in practice.",
 "options": [
 "A — file it as a separate domain:skills/gate card (the triage comment's own instruction: 'File it if the work makes the case concrete'). It is now concrete: three consumers, two blind sweeps, one missed-inside-the-filing consumer.",
 "B — do nothing; the family is now fully swept (all seven read sites plus these three write sites are provenance-aware), so a gate guards a surface with no known remaining holes.",
 "C — build it into this PR (⛔ explicitly forbidden by both the dispatch prompt and the triage fence; listed only for completeness)."
 ],
 "recommendation": "A, and PM to file — not me, per the dispatch instruction. Real business need: the need is for the NEXT anchor-family invariant, not this one; the sweep has now been run three times and the method has a measured miss rate, which is the definition of a check that should be mechanical. Long-term soundness: this is the repo's own stated doctrine (AGENTS.md — 'Seven independent omissions of the same one-line kind is not a memory problem to solve by remembering harder; it is a missing check'), and rule-id-barrel-exports.test.ts is the precedent for exactly this move. AI-hard-to-get-wrong: strongest axis — a spread that launders an object-independent set into a rule-local one is invisible to review and to grep alike, which is precisely the shape an AI author reproduces when adding the fourth consumer. Caveat that belongs in the card: scope it to transitive re-exports, or it reproduces the miss it exists to prevent."
 },
 {
 "question": "Should the three write rules also warn on an external object that declares NO fields at all? Today `judgeableFieldsOf` returns undefined for it (deliberately — the field map is unknown, not empty), so both the existence finding and my new provenance finding stay silent. But the anchors are perfectly knowable there even though the field map is not, and it is the case where the existence check is LEAST able to help — so a provenance warning would be sound exactly where nothing else fires.",
 "options": [
 "A — leave it (what I shipped): the anchor check sits inside the existing judgeability fence, so the change is strictly 'stop the blanket set from blanketing anchors' and adds no new population.",
 "B — widen the three rules to warn on unjudgeable external objects, which makes them fire on objects where they currently produce nothing at all."
 ],
 "recommendation": "A for this card — B is a different change with a different risk profile (new population, not a narrowed exemption) and was outside the triage's scoping of 'provenance-awareness for validate-hook-body-writes.ts:265's set'. Worth a follow-up card if the PM wants it; I did not file one, because unlike the gate question I have no measured evidence that the unjudgeable-external case occurs in practice — and per the startup-focus principle a surface with no measured pull is handled implementation-first."
 }
 ],
 "out_of_scope_findings": [
 "NOT filed (already tracked upstream): `check:type-check-debt --re-measure` reports @objectstack/lint at 19 raw errors against a recorded ceiling of 20 — one below, i.e. one regression could land in a layer no other gate reads. The gate names the tracking issue itself (#6376) and offers `--lower`. I deliberately did NOT lower it: the number would be one measured on this branch, and closing another card's ratchet is not mine to do.",
 "NOT filed (documentation drift, one line, inside a file this PR already edits): validate-hook-body-writes.ts's module header states that `validateRecord` 'walks declared fields on insert and `continue`s past a key with no field def on update'. Measured (A4b), update now refuses with INVALID_FIELD exactly as insert does, so the header's update half is stale. It is a comment, it is not load-bearing for any assertion, and correcting it would be an unnamed drive-by under a different defect class — recorded here instead, in the PR body, and left for triage."
 ]
}

---

Generated by Claude Code

---

Generated by Claude Code