@@ -8,13 +8,23 @@
 // The COMPILE-TIME half — a declared `configSchema` / `hotReloadable` no
 // longer type-checks against the published `PluginMetadata` — lives in
 // `packages/rest/src/plugin-metadata-retired-fields.pin.test.ts`, deliberately
-// NOT here: `@objectstack/core` has no `typecheck` script (type-check DEBT
-// ledger entry), so a `@ts-expect-error` in this package is a phantom pin no
-// tsc program a `typecheck` script runs would ever evaluate —
-// `check:type-check-coverage` refuses exactly that. The rest package's
-// `tsconfig.test.json` program is compiled by its `typecheck` script and reads
-// core's BUILT `.d.ts`, so the pin over there guards the published contract
+// NOT here. The rest package's `tsconfig.test.json` program is compiled by its
+// `typecheck` script and resolves `@objectstack/core` to core's BUILT
+// `dist/index.d.ts`, so the pin over there guards the published contract
 // itself.
+//
+// ⚠️ This used to read as though the split were forced — that
+// `@objectstack/core` "has no `typecheck` script (type-check DEBT ledger
+// entry)", making a `@ts-expect-error` here a phantom pin
+// `check:type-check-coverage` refuses. False on this tree in BOTH halves:
+// #14613 split a `tsconfig.test.json` out of the build config,
+// `package.json`'s `typecheck` NAMES it (via `check:test-typecheck
+// --project`), and this package holds no DEBT entry. A directive here WOULD be
+// evaluated — against `./plugin-loader.ts`, this package's own SOURCE, which
+// `tsc --listFiles` puts in that program alongside ZERO files under
+// `packages/core/dist/`. The published `.d.ts` is what these pins are about
+// and only the rest program reads it, which is a reason that outlives any
+// package's script list.
 
 import { describe, it, expect } from 'vitest';
 import * as securityBarrel from './security/index.js';
 
@@ -4,15 +4,29 @@
 // `PluginMetadata` surface of `@objectstack/core` (#11982 `configSchema`,
 // #12587 `hotReloadable`), recorded in ADR-0025 §3.7.
 //
-// Why the pins live in THIS package: `@objectstack/core` has no `typecheck`
-// script (it is a type-check DEBT ledger entry), so a `@ts-expect-error` there
-// is a phantom pin — no tsc program a `typecheck` script runs ever evaluates
-// it, and `check:type-check-coverage` refuses it. This package's
-// `tsconfig.test.json` program IS run by its `typecheck` script
-// (`check:test-typecheck`, EXACT per-file ratchet: an unlisted file must stay
-// at zero errors), and it resolves `@objectstack/core` to the BUILT
-// `dist/index.d.ts` — so these directives pin the contract consumers actually
-// see. This package is also the retirement's worked replacement: the REST
+// Why the pins live in THIS package: this package's `tsconfig.test.json`
+// program IS run by its `typecheck` script (`check:test-typecheck`, EXACT
+// per-file ratchet: an unlisted file must stay at zero errors), and it
+// resolves `@objectstack/core` to the BUILT `dist/index.d.ts` — so these
+// directives pin the contract consumers actually see.
+//
+// ⚠️ NOT because core cannot compile a pin — this header used to say
+// `@objectstack/core` "has no `typecheck` script (it is a type-check DEBT
+// ledger entry)", and that is false on this tree in BOTH halves. #14613 split
+// a `tsconfig.test.json` out of core's build config and core's `typecheck`
+// NAMES it (via `check:test-typecheck --project`), so a `@ts-expect-error`
+// over there is compiled rather than the phantom pin
+// `check:type-check-coverage` refuses; and core holds no DEBT entry. What
+// core's program cannot do is read core's own PUBLISHED surface: it compiles
+// `src`, so a pin there would read `plugin-loader.ts` — the declaration —
+// not the `.d.ts` the build emits from it. Measured with `tsc --listFiles` on
+// both programs: this one contains `packages/core/dist/index.d.ts` and ZERO
+// files under `packages/core/src/`, while core's own test program contains
+// `packages/core/src/plugin-loader.ts` and ZERO under `packages/core/dist/`.
+// That reason is durable where the script-list one was not. Same placement as
+// `plugin-type-closed-set.pin.test.ts`.
+//
+// This package is also the retirement's worked replacement: the REST
 // server parses its own config at its own seam (#11637,
 // `rest-config-parse-not-cast.test.ts`) precisely because the kernel-side
 // validator could never run.
 
@@ -153,11 +153,27 @@ describe('QuickJSScriptRunner — L2 hook script', () => {
   // without also installing it.
 
   it('the VM ctx.crypto exposes exactly randomUUID, under ANY grant (#4391)', async () => {
-    // The EXECUTABLE pin, and the load-bearing one. `@objectstack/runtime` has
-    // no `typecheck` script (it sits in the DEBT table of
-    // scripts/check-type-check-coverage.mjs), so a type-level assertion here
-    // would never be compiled — a dead pin reads as assurance and gives none.
-    // This enumerates what `installCtx` actually put on the seam instead.
+    // The EXECUTABLE pin, and the load-bearing one. It enumerates what
+    // `installCtx` actually put on the seam, and it has to: the defect was a
+    // member DECLARED on the host seam and never installed, so a type-level
+    // assertion reads the declaration — the very artefact that lied — and
+    // would have passed green on the broken tree. Only running the sandbox
+    // observes what the VM really got. That reason outlives any package's
+    // script list.
+    //
+    // ⚠️ This used to justify itself the other way round — that
+    // `@objectstack/runtime` "has no `typecheck` script (it sits in the DEBT
+    // table of scripts/check-type-check-coverage.mjs)", so a type-level
+    // assertion here "would never be compiled". False on this tree in BOTH
+    // halves: the package declares `typecheck`
+    // (`tsc --noEmit && pnpm check:test-typecheck`) and holds no DEBT entry,
+    // and #14504's `tsconfig.test.json` — which that script NAMES via
+    // `check:test-typecheck --project` — puts THIS file in its program
+    // (measured with `tsc --listFiles`). The build config still excludes
+    // `**/*.test.ts`, which is where the old sentence came from; it stopped
+    // being the whole story when the test layer got its own program. A
+    // directive here would be LIVE, so the pin below is executable by
+    // ARGUMENT, not for want of a compiler.
     //
     // It is deliberately exhaustive rather than `hash`-specific: the defect was
     // a member advertised ahead of its implementation, so ANY new member must
 
@@ -247,9 +247,23 @@ describe('[#14328] the ARRAY-form divergence is PRESERVED, not unified away', ()
         // reports it verbatim and binds nothing).
         // Typed as the real `FlowTrigger`, NOT `… as never`: the cast erases the
         // contextual type for `start`, which leaves `binding` implicitly `any`
-        // (TS7006). This package has no `typecheck` script, so its `tsc --noEmit`
-        // runs only in the type-check DEBT lane — which compiles `src/**`, tests
-        // included, and is a shrink-only ratchet. Same shape as `engine.test.ts`.
+        // (TS7006) — and here that error is reported on arrival. This package's
+        // `tsconfig.json` carries NO test exclusion (its `include` is `["src"]`),
+        // so the `tsc --noEmit` its `typecheck` script runs already compiles this
+        // file, and #15048's `tsconfig.test.json` — NAMED by the same script via
+        // `check:test-typecheck --project` — compiles it too. There is no
+        // `test-typecheck-debt.json` beside that config, and the ABSENCE is the
+        // zero: any error in any file here is red immediately, with no entry to
+        // be added to. Same shape as `engine.test.ts`.
+        //
+        // ⚠️ This used to say the package "has no `typecheck` script, so its
+        // `tsc --noEmit` runs only in the type-check DEBT lane", a shrink-only
+        // ratchet. False on this tree in BOTH halves: the package declares
+        // `typecheck` (`tsc --noEmit && pnpm check:test-typecheck`) and holds no
+        // entry in `scripts/check-type-check-coverage.mjs`'s `DEBT`. The floor
+        // under this file is stricter than that sentence claimed, not laxer —
+        // and the reason above is a property of the two configs, which outlives
+        // any package's script list.
         const started: FlowTriggerBinding[] = [];
         const trigger: FlowTrigger = {
             type: 'record_change',