From 66f12e4d3062c18cc9edfb3347e3d0215a2a1bd7 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 18 Sep 2026 05:02:32 +0000 Subject: [PATCH] docs(changeset): drop the migration framing from the EvalContext.api removal note `.changeset/18318-evalcontext-no-query-api.md` holds `not-required (runtime-interface-only packages/formula/src/types.ts#EvalContext)`, whose four predicates were verified positively. The disposition also inherits the `no-migration-prescription` refusal, and after the RETIREMENT arm landed in `check-adr-0087-registration.mjs` the body's own lead line reads as a framed migration prescription -- so the two contradict each other and the gate refuses the claim the moment a diff makes it judge this changeset. The refusal is correct on its own terms: the line carried the repo's FROM -> TO pair notation with an instruction in TO position. There is no TO. This rewrites the lead as the imperative it always was, keeping every word of the instruction and dropping the pair notation and the `Migration` label that the disposition at the foot of the same file denies. Nothing else in the changeset moves: the bump, the BREAKING banner, the disposition comment and its four predicates are byte-identical. Claude-Session: https://claude.ai/code/session_01JbZnqu8bt6YqfJsr9vaFb3 Co-authored-by: Claude --- .changeset/18318-evalcontext-no-query-api.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.changeset/18318-evalcontext-no-query-api.md b/.changeset/18318-evalcontext-no-query-api.md index bdd8e3e77a4..ff6962523e2 100644 --- a/.changeset/18318-evalcontext-no-query-api.md +++ b/.changeset/18318-evalcontext-no-query-api.md @@ -8,7 +8,7 @@ The member's docblock said it was "implemented opportunistically by call sites that have a query engine", and no call site ever could: `ctx.api` was read **zero** times in this package — control in the same sweep, `ctx.user`, three reads in `stdlib.ts` — so the three functions reached no evaluation scope however completely a caller populated the member. An author who wrote a predicate to the declaration got `runtime: found no matching overload for 'dyn.lookup(string, dyn)'` instead, and because an unevaluable predicate refuses the write it guards, a validation rule authored that way locked **every** write on its object. The harm came from the declaration existing, not from the implementation missing, so it is removed rather than implemented — with the reason written at the deletion site, and with no shim, alias or reserved spelling left behind. -**Migration — `api: { … }` → delete the property.** There is no replacement key and nothing to re-point: every implementation ever passed there was discarded before evaluation, so removing the property changes no result your predicates produce. TypeScript is where you will hear about it: an `EvalContext` literal carrying `api` now fails to compile, which is the whole of the break. Reading a related record's field from inside a predicate remains unexpressible in any spelling — that capability is tracked as its own card, relationship traversal (`record.crm_account.type`), and deliberately not as `os.lookup` queries; no schedule is implied by this removal. +**Your fix — delete the `api: { … }` property.** There is no replacement key and nothing to re-point: every implementation ever passed there was discarded before evaluation, so removing the property changes no result your predicates produce. TypeScript is where you will hear about it: an `EvalContext` literal carrying `api` now fails to compile, which is the whole of the break. Reading a related record's field from inside a predicate remains unexpressible in any spelling — that capability is tracked as its own card, relationship traversal (`record.crm_account.type`), and deliberately not as `os.lookup` queries; no schedule is implied by this removal.