diff --git a/docs/known-gaps.md b/docs/known-gaps.md
index 1b1fbacb8..e097dc815 100644
--- a/docs/known-gaps.md
+++ b/docs/known-gaps.md
@@ -30,7 +30,7 @@
 | Severity | Open |
 |---|---|
 <!-- @generated:gap-counts START (do not edit — `bun scripts/state.ts --write`) -->
-| HIGH | 76 |
+| HIGH | 77 |
 | MED | 204 |
 | LOW | 87 |
 | Nominal (spec-ahead-of-impl) | 7 |
@@ -53,6 +53,11 @@
 
 <!-- ⛑ S395-bryan filing batch 2 — THREE entries from the #818 if-chain server-boundary arc. Two are PRE-EXISTING and were verified as such two-sided before filing (neither is introduced by #818); the third is a tooling-baseline debt whose measurement is RELAYED and labelled so, because `tsc` is not installed in this checkout and the types gate correctly refuses to pass without running. -->
 
+<!-- ⛑ S395-bryan filing batch 3 — ONE entry, surfaced while reading §32 IN FULL to answer bryan's `~` question. It is the reason a live contradiction between two normative sections survived unnoticed, and it is filed BEFORE the fix arc for the contradiction lands, so the two are not conflated. -->
+
+### g-tilde-lin-enforcement-does-not-fire-on-spec-own-examples — §32's `~` exactly-once (`lin`) enforcement produces **ZERO diagnostics on SPEC's own worked examples**. **PA-MEASURED ON MERGED MAIN — six probes, all exit 0, all zero `E-TILDE`:** §32.5's verbatim `${ process(~) }` (spec'd `E-TILDE-001`) · `~` read with no initialization at all · a double-initialization with no consumption between (spec'd `E-TILDE-002` per §32.3) · an initialization never consumed before scope exit (also spec'd `E-TILDE-002`) · a double-init inside a function body · §17.6.6's partial-`if` example (`if (cond) { lift a }` then `const dbl = ~ * 2`, which §17.6.6 says the compiler **SHALL** emit `E-TILDE-001` for). ⛑ **NOT from absence, which is why this is filed as a defect rather than as spec-ahead:** `TildeTracker` (`type-system.ts:18380`), `MustUseTracker`, `checkLinear` and BOTH codes exist with real user-facing messages, and `checkLinear` is invoked **unconditionally** at file level (`:24470`, gated only on `allLinNodes.length > 0`). The pass runs and does not fire on the documented shapes. ⛑ **CAUSE NOT TRACED — stated as an observation, not a diagnosis.** `hasNonLiftTildeConsumer` gates only loop-body elision (`:18956`) and one site at `:19549`, not the pass as a whole, so the obvious gate is NOT the explanation; whether `~` reaches the tracker as a `tilde-ref` node in these shapes was not established. **A fix must start by tracing that, not by assuming the pass is unimplemented.** ⛑ **WHY IT MATTERS BEYOND THE MISSING DIAGNOSTICS:** this silence is what let §17.6.2 and §32.2 contradict each other unnoticed — §17.6.2 says a bare call in an if-as-expression arm is a side effect, §32.2 says an unassigned expression statement SHALL initialize `~`, and with §32.3 that shape should have been a hard `E-TILDE-002` for as long as both sentences have coexisted. Nobody saw it because nothing enforced it. **This is the S322 re-examination test in its purest form:** a normative SHALL delivered by a tracker pass that scans for states — RETROFIT, not by construction — and the predicted hole duly appeared. Composes with **dpa-040** (should an arm body be a `~` boundary?), whose phase 1 is required to re-verify this by execution before reasoning from it. — `NEW S395-bryan (surfaced while reading §32 in full for the `~` ruling; six probes PA-executed on merged main)`; **HIGH**; open
+<!-- @gap id=g-tilde-lin-enforcement-does-not-fire-on-spec-own-examples sev=HIGH status=open locus=compiler/src/type-system.ts:18380(TildeTracker)+:18479(checkLinear)+:24470(the unconditional file-level invocation) — the pass EXISTS and RUNS; the reason it does not fire on SPEC's documented shapes was NOT traced prov=empirical:PA-six-probes-on-merged-main-including-SPEC-32.5-and-17.6.6-verbatim-examples-all-exit-0-zero-E-TILDE -->
+
 ### g-same-named-branch-declarations-bind-to-the-last-definition — two sibling `if=`/`else` branches declaring the SAME function name emit BOTH definitions but bind **every** call site to the LAST one, with zero diagnostics. Surfaced by the S239 pass on #818 and **PA-verified PRE-EXISTING, not introduced**: on merged main two *lone* `if=` divs each declaring `dup()` already emit `_scrml_dup_7` + `_scrml_dup_8` and route the calls to the last definition (measured 1 call to the first, 5 to the second). #818 brings the collapsed-chain shape to PARITY with that lone-`if=` oracle, which is its stated goal — so the chain now inherits the oracle's own defect rather than introducing one. ⛑ **The direction of the change at this shape is loud→silent**, and that is why it is filed rather than shrugged at: on base the chain produced a `ReferenceError` (nothing was defined at all); it now returns the WRONG branch's value silently. In the `server fn` / plain `function` mix the `if`-arm's call binds to the else-arm's CLIENT function while the emitted route goes unreferenced — a live POST endpoint with no caller. **No server body leaked in any duplicate-name shape tested** (`SERVER-SECRET` never reached `client.js`), so this is a correctness defect, not a confidentiality one. The real question underneath is whether a branch body is its own DECLARATION SCOPE — the same scoping question `g-if-chain-all-arms-run-at-module-init` asks about `${}` bodies, and it should be ruled once for both rather than twice. — `NEW S395-bryan (S239 finding on #818; PA-verified pre-existing on the lone-if= oracle)`; **MED**; open
 <!-- @gap id=g-same-named-branch-declarations-bind-to-the-last-definition sev=MED status=open locus=compiler/src/codegen/collect.ts(collectFunctions registers by NAME with no per-branch scope, so the last registration wins; the same shape pre-exists for sibling lone-if= blocks, which is the oracle it was brought to parity with) prov=empirical:PA-two-sided-execution-two-lone-if-divs-on-merged-main-already-bind-all-calls-to-the-last-definition -->
 
diff --git a/handOffs/delta-log.md b/handOffs/delta-log.md
index c1e375757..7efc0bd74 100644
--- a/handOffs/delta-log.md
+++ b/handOffs/delta-log.md
@@ -3262,3 +3262,8 @@ flagged `(deputy)`, observation-only, recording an agent that landed while the P
 [2035] find · **(S396-peter) E-ROUTE-004 HAS AN UNTYPED-PARAM HOLE — dog-fooded flogenceP, root-caused end-to-end, filed + routed.** flogenceP compiles clean on HEAD (21 files, 94 routes, 1 WS channel, validate-emit) + boots clean (server + MCP 11 tools); all 92 server-fns swept, every 500 triaged to app-level (empty-args / schema-init-order — e.g. `edit_mode` created by digest-tool not app's ensureSchema, init-order-dependent = flogenceP app bug), ZERO codegen-signature errors. The ONE scrml find: `checkRouteWireSerializability` (`type-system.ts:4734`) `continue`s on un-annotated params ("un-annotated param defaults asIs → allow"), so a server-boundary fn with an untyped-but-CALLED function param escapes E-ROUTE-004 and is routed as a **silent dead-500 endpoint**. Manifested on `runGatedAgentic` (untyped `run`, POST→500 `run is not a function`); import-only by intent so blast-radius LOW + pre-existing. **Two-sided minimal repro, runtime-confirmed:** `function f(cb){?{}…return cb(rows)}` (untyped) → exit 0 + dead route → POST 500; `function f(cb: () -> number)` (typed) → E-ROUTE-004 fires. Filed `g-route-004-untyped-fn-param-escapes-serializability-gate` (MED, open) + routed to bryan (the `continue` is deliberate — asIs hatch — so the fix is a normative fork: usage-based signal / require annotation / warn). ⚑ I STOPPED SHORT before routing (invoked "bryan's lane" to avoid reading his files) — Peter pushed, and READING for diagnosis ≠ EDITING; then I root-caused to the exact line. [[be-the-authority-root-cause-dont-hand-wave]].
 
 [2036] state · **(S396-peter) WRAP.** Dog-food + adopter-ops session; NO compiler `src` touched (no FACTS/state code regen owed; maps unchanged). Landed: aM pin bumped + `g-route-004` filed (`state.ts` regen MED 203→204) + routed to bryan. Also flipped `~/.claude/settings.json` `blockReadsOutsideWorkingDirectories`→false (Peter's ask; needs restart/`/add-dir`); BLOCKED by the auto-mode classifier from self-editing permission config (dir-adds are Peter's own `/add-dir`). Continuity rides a light PR off `8f3c5b74`: this delta-log [2033]-[2036] + changelog S396 + the S396 hand-off PICKUP (bryan's S393/S395 owed-queue reconciled — S395 closures removed, the "inverted ruling" + value-form-null struck as resolved, the #818 security gap struck as closed). Pre-existing agent worktrees retained (not this session's). Gaps HIGH 76 · MED 204 · LOW 87.
+[2037] state · **(S395-bryan) THE `~` RULING — limb (a), and it exposed that SPEC answers the question TWICE.** bryan: *"lets look at ~"* then *"your rec"*. **RATIFIED: §17.6.2 governs an if-as-expression arm body** — a bare expression statement inside an arm is a SIDE EFFECT; it does not initialize `~`, does not rebind the tilde context, does not touch the arm's result; only `lift` or the §17.6.10 sugar designates it. Per S276/S130 the terse ratification adopted the FULL text — *"(a) now, with (c) named as the question behind it"* — so **limb (c) is banked, not closed** (dpa-040). The reading found **§17.6.2 and §32.2 in direct conflict**: §32.2's *"an expression statement whose value is not bound SHALL initialize `~`"* plus §32.3's exactly-once rule makes `{ note("a") lift "pos" }` an `E-TILDE-002`, while §17.6.2 calls the same statement a side effect. **The compiler implements NEITHER** — it mints a fresh tilde and rebinds the context, so the `lift` writes the wrong var and the binding is silently null. Arc dispatched: codegen fix + the SPEC reconciliation it owes (§32.2 arm-body carve-out + reciprocal cross-ref + Rule 4b provenance), same arc, with a warning that #802's reconciliation surface turned out to be 3× what its ruling named.
+
+[2038] find · ⚑ **(S395-bryan) §32's `~` ENFORCEMENT DOES NOT FIRE — AND THAT SILENCE IS WHY THE CONTRADICTION SURVIVED.** Six probes on merged main, all exit 0 with ZERO `E-TILDE`: SPEC §32.5's own verbatim `${ process(~) }`, `~` read with no init, double-init without consumption, init-never-consumed-at-scope-exit, double-init in a function body, and §17.6.6's partial-`if` example that SPEC says the compiler **SHALL** diagnose. NOT from absence — `TildeTracker`, `checkLinear` and both codes exist with real messages and `checkLinear` runs unconditionally at file level (`:24470`). **Cause NOT traced and the entry says so**; `hasNonLiftTildeConsumer` gates only loop-body elision, so the obvious explanation is ruled out but no replacement is offered. Filed HIGH as `g-tilde-lin-enforcement-does-not-fire-on-spec-own-examples`. **The S322 test in its purest form:** a normative SHALL delivered by a state-scanning tracker — retrofit, not by construction — and the predicted hole appeared.
+
+[2039] friction · ⚑ **(S395-bryan) I BANKED dpa-040 IN A FORM THE PROBE COULD NOT READ, AND CAUGHT IT ONLY BY RUNNING THE PROBE.** Wrote the full `## [dpa-040]` section into `dpa-queue.md` — the right FILE, per the S319 drain-path rule — and `dpa-debt.ts` still reported **39 items / 2 UNRUN**. The probe reads the **status TABLE**, not the per-item sections; `scripts/dpa-debt.ts`'s own header says reading the per-item `status:` lines instead *"would reproduce the exact obligation/probe mismatch this file exists to close."* Adding the table row moved it to **40 / 3 UNRUN**. **The S319 rule "bank in the queue FILE" is necessary and NOT sufficient — the row is the banking act, the section is documentation.** Same base §10 class as everything else this session, self-inflicted, and caught only because the probe was run rather than assumed. [[feedback_the_probe_answered_a_different_question]]
diff --git a/handOffs/dpa-queue.md b/handOffs/dpa-queue.md
index 6c5d9ac31..71c06e9b5 100644
--- a/handOffs/dpa-queue.md
+++ b/handOffs/dpa-queue.md
@@ -58,6 +58,7 @@ Item format + drain protocol: `scrml-support/dpa-scrml.md` + the design DD
 | dpa-035 | **COMPLETE (ADVISORY) dPA 2026-08-19 — awaiting PA/bryan ratification.** ★★ **THE QUESTION IS ASKED AGAINST THE WRONG LEDGER — the "16 KB budget" is the assembled SPA *RUNTIME* gzip budget** (`g-spa-runtime-gzip-budget-knife-edge`, 16,257/16,384 B, **127 B margin**, open HIGH with a live hold-vs-raise fork, asserted at `v0-3-x-spa-tree-shake-phase-b.test.js:145`) — **NOT an app-payload budget.** Above-the-fold partitions APP markup; the app budget is a separate SOFT `W-CG-CHUNK-LARGE` at 100,000 B sitting at **2.4% utilisation**. Fold-preferencing therefore **cannot relieve the budget that motivated the question**, and the mechanism to realise it is paid for OUT of the constrained ledger. ★★ **The bank's load-bearing claim is CONFIRMED by execution** (a 4-arm `<engine initial=.Idle>` ships all 3 non-initial arm bodies into the initial client chunk) — **but the half the bank did not state is decisive: arms are DEFINED, not MOUNTED** (absent from HTML; no DOM, listeners or subscriptions). ⚑ **I CORRECTED MY OWN CEILING 19x MID-DELIBERATION** — trivial arms gave 37 B gz, heavy dissimilar arms (form/table/error-panel) give **2,659 B raw / 689 B gz = 28.4% of the app chunk but 2.40% of payload**; three poles had already reasoned from 37 B and **all three were re-polled against it and all three moved**. ★★ **THE ARITHMETIC THAT DECIDES IT (source-verified):** there is **no component-tiering machinery to extend** (`reachability-solver.ts:434-454` — component/cell/vendor tier sets are `new Set()`, literally empty; the tier axis carries server-fn ids ONLY, so this builds the FIRST component tier) · deferring arms **inverts a normative SHALL** (worst-case union, *"under-inclusion is the disallowed failure mode"*, `SPEC.md:22980`) → a §40.9 amendment, **120-220h** · and **no executing loader exists** (`_scrml_fetch_chunk` returns chunk TEXT, never evaluates) so one costs **400-900 B gzip of RUNTIME to save 689 B of APP** — *spend the ledger with 127 B of margin to relieve the one that is 97.6% unused.* ★ **§65 critical-CSS claim REFUTED by execution** — `#{}` emits verbatim into one global `@layer global`; a class used **nowhere at all** still ships (no dead-rule elimination, no per-arm partition). ★ **HTML byte pool = ZERO** (heavy vs empty arm HTML both 603 B, no `<template>`) — closes the cost-pole's own named unverified gap, against the proposal. ★ **`--minify` is a shipped CLI flag documented as a NO-OP** (`cli.js:73`) applying to 100% of emitted surface vs the fold's 8.4%. **VERDICT 6 DO-NOT-BUILD / 1 DEFER-WITH-RETRIGGER / 0 BUILD** — the corrected measurement flipped the Qwik pole to BUILD-NARROWED, the source facts **re-flipped it back to DO-NOT-BUILD on its own arithmetic** (*"qwikloader amortizes ~1 KB across hundreds of QRLs; an arm-loader amortizes 400-900 B across ~4 arms — same mechanism, wrong denominator"*). **Reco: sequence (1) land `--minify` for real, (2) runtime tree-shaking (the ledger actually failing), (3) fix `I-SSR-EACH-CLIENT-RENDERED` (the REAL above-the-fold defect — the LCP element painting client-only), (4) dead-rule elimination in `#{}`; revisit the partition only when the runtime fork resolves by RAISING and a loader exists for another reason.** ⚑ **OQ-1 BLOCKING: resolve the 16 KB hold-vs-raise fork — every option is downstream of it.** ★★ **PANEL GAP CLOSED — dPA 2026-08-19 (second boot), addendum §10.** The critical-rendering-path voice (forged in the first drain; `Agent type not found` then, LIVE at this boot — a clean second confirmation of the next-boot rule) was polled and **CONFIRMS: tally now 7 DO-NOT-BUILD / 1 DEFER / 0 BUILD** — on STRONGER grounds than cost. ★ **The sign is wrong, not just the size:** deferral **REGRESSES INP on the state switch**, which in an `<engine>`/`<match>` app IS the primary interaction (good INP → 100-500 ms on mobile) — every other pole argued the prize was too small; this one argues it is NEGATIVE. ★ **Re-denominated in ms the prize vanishes:** never-called arms are pre-parsed only ≈ **0.4-1.3 ms = 2-5% of ONE frame, first visit only, <1% of runtime main-thread cost** — **the panel OVERSTATED the residual by staying in bytes.** ★★ **The reframe:** bryan's statically-known-initial-state idea is worth **~100x more aimed at FIRST PAINT than at chunk size**, and §5's blockers do NOT bind it (no under-inclusion, no loader, no runtime bytes vs the 127 B margin) — **VERIFIED: a `fixed inset-0 z-40` backdrop swallows EVERY CLICK from first paint until hydration** (`app.scrml:2870`, `<overlay> = ""` at `:117`, fold happens only in `app.client.js` — the LAST of 8 parser-blocking scripts). ⚑ **The pole's stated mechanism was REFUTED and the finding ENLARGED:** its "the compiler folds initial hidden state, inconsistently" rests on an **AUTHOR-written** `hidden` (`:2854`; the sibling binding at `:2845` has none) — there is **no folding machinery**, so not an inconsistency but a **missing capability every adopter hits**, silent on failure. **6 defects verified + ROUTED** (4 scrml-compiler/emit, 2 flogence-app), incl. compiler-emitted **`.defer` on a `createElement` script = a no-op** (chunk may execute BEFORE the runtime — a race, not a smell) and **2 serialized RTTs** before the chunk is even requested. ⚑ **THE SOLE UNTAKEN MEASUREMENT THAT WOULD INVERT EVERY ARITHMETIC HERE: can a non-initial arm SOLELY root a VENDOR UNIT?** (prize would be **40-150 KB gz, not 689 B**; `prefetchTier1.vendorUnitNames` already exists as an empty set). One fixture settles it. ⚑ **Ledger note for OQ-1:** §1 budgets the runtime at 16,257 B while §2.2 ships **26,258 B gz** and the flogence cockpit ships that plus 7 more scripts — **rule OQ-1 on the SHIPPED number, not the budgeted one.** Every repo claim the pole made was independently re-verified by the dPA before recording; two needed correction. ADVISORY — nothing ratified. → `scrml-support/docs/deep-dives/above-the-fold-preferencing-dpa-035-2026-08-19.md` | S352 bryan bank → RUN 2026-08-19 → **RATIFIED S352 2026-08-19 (bryan)** — *"Ratify as advised"*: **DO-NOT-BUILD** the fold partition (6/1/0), take the replacement sequence — (1) land `--minify` for real (a shipped CLI flag documented as a no-op; 100% of emitted surface vs the fold's 8.4%) · (2) runtime tree-shaking (the ledger actually failing) · (3) fix `I-SSR-EACH-CLIENT-RENDERED` (the REAL above-the-fold defect — the LCP element painting client-only) · (4) dead-rule elimination in `#{}`. **Decisive fact PA-verified:** `_scrml_fetch_chunk` returns `r.text()` and never evaluates — no executing loader, so the scheme costs 400-900 B of RUNTIME to save 689 B of APP, which loses on its own arithmetic and would now break the S352 ratchet. **TWO CORRECTIONS against the DD, recorded so the cost is not mis-cited:** the §40.9 amendment leg (120-220h) applies ONLY to runtime-driven engines — for a compile-time-known `initial=` the SPEC already says a `<match>` MAY be classified IN or OUT, so no amendment; and the "127 B margin" framing was the stale S282 figure. Neither rescues the proposal. **Its OQ-1 (the 16 KB hold-vs-raise fork) was dissolved earlier the same session.** ⚑ Panel gap carried forward: the critical-rendering-path voice could not be polled (`Agent type not found`) — live next dPA boot. See user-voice S352. |
 | dpa-036 | **COMPLETE (ADVISORY) dPA 2026-08-22 — awaiting PA/bryan ratification.** ★★ **VERDICT — THE ITEM'S TWO RANKINGS ARE INVERTED, by its OWN cited authority.** `[1678]` ratifies a surface/internals split: *"'one chance to get it right' binds the AUTHORING SURFACE — NOT the compiler internals."* An inference algorithm is internals → **(a)→(b) is REVERSIBLE, not one-way.** What IS one-way is what `asIs` MEANS at an annotated position. **So the "sub-question inside (b)" IS the fork, and the a/b choice is subordinate scheduling.** ★★ **THE `asIs` ANSWER — 5 of 5 poles, independently, from opposed priors:** `asIs` means *the developer signed for it*; it must NEVER mean *the compiler did not look*. **Inference failure must be structurally incapable of producing `asIs`** — it yields a loud, countable `unknown^gap(k)`. Not fail-closed; **fail-LOUD** (fail-closed IS refusal-based → bills the adopter → `[1678]` rules it out, so the PA's (c) exclusion is CORRECTLY grounded). Notable: the **simplicity pole's yield condition is verbatim the type-systems pole's structural fix** — the two expected to disagree agree on mechanism and differ only on sequencing. ★★ **[EXEC] NEW, NOT IN THE BANK — the decay is not a risk, it is the CURRENT STATE:** `fieldTypeAssignable:850-862` returns true if **EITHER** side is `asIs`/`unknown` → `any`-shaped, not `unknown`-shaped; (b) built on it would **BEGIN** at (a). ⚑ **WORSE:** `fieldTypeEquals:869-877` ends `return true` for predicated/map/state/etc → reuse fails open across **~10 of 18 kinds**, not just the top. ★ **BUT THE FIX IS CHEAPER THAN THE BANK ASSUMED:** `AsIsType:340` + `UnknownType:364` are **ALREADY distinct union members** (`:489-490`) — the relation discards the distinction in TWO LINES; and `AsIsType.constraint` is an **escape-hatch-on-the-escape-hatch** (§14.10 R28-8 recovers the type the resolver just discarded) = the codebase ALREADY felt this and patched around it locally. `ResolvedType` is **NOT** SQL-shaped (18-member general lattice; SQL rides on name STRINGS `:743`/`:754`; `fnSignatures:8330-8479` already stores params+returns as `ResolvedType`) → **reuse the MODEL, replace the RELATION** (~150-250 LOC, **ONE** call site, provably preserves §14.8.8, 20-35h). ★ **PRECEDENT: scrml ALREADY RAN THIS REPAIR ONCE** — `E-TYPE-UNKNOWN-NAME`/`checkUnknownTypeNames` (`type-system.ts:5151+`, S176) converted a silent `asIs` fall-through into a position-aware hard error at the SAME seam. ★ **SCOPE IS SMALLER THAN FEARED:** the argument-position silence is **literally one line** (`:15063` `if (paramType.kind !== "enum" && paramType.kind !== "union") continue;`); cell 1-2h; return 3-5h; staged warn→error is **~0-4h** (`TSError:708-718` already takes `severity`). ★ **[EXEC] §7.5 IS NOT A FOUR-POSITION RULE — E-TYPE-031 backs NINE normative SHALL sites** (`:6132 :6149 :9600 :9721 :10071 :10254 :10258 :11679 :11697`), and **§34's registry (`:19235`) books it as PROP-only (§15.3/§15.10)** — the code's own registry contradicts its primary clause. → the SPEC has a defect here **regardless of which algorithm ships**. ★ **COSTS:** (a) ~52-110h · **(b) 205-390h** · (c) = (b) **+10-20h — a default FLIP, not a build**. Corpus repair **40-90h is IDENTICAL under all three** (60-75% of first-wave breaks are inference incompleteness, per TS/Sorbet/mypy rollouts) → (a)'s real saving is compiler time only. ⚑ **DOMINANT RISK: the builtin-method return-type catalog** (+40-80h, no scaffolding, implicated by the measured `n.toUpperCase()` repro) — out-of-scope means member-call→top, i.e. the exact absorption this DD exists to prevent. ⚑ **WORST CORNER: (b) with the relation EXTENDED — (b)'s cost, (a)'s outcome.** ★ **FREE OPTION (take it):** build the un-inferable default as a **single switch** — ~0h designed in, expensive retrofitted; keeps (c) available without adopting it. ★ **THE DUMB-TYPE-SYSTEM ATTRIBUTION IS MOOT:** the panel endorses a **4-element lattice** (`never <: {number,string,boolean,nominal} <: unknown`) — a *dumb* system is compatible with everything recommended; an **ABSENT** one wearing its clothes is not. ★ **5 CALLS FOR BRYAN (§7 of the artifact), ranked:** (1) ⚑ the ONE-WAY one — adopt the authored/gave-up `asIs` split? [panel 5/5 yes]; (2) sequencing widened-(a) vs straight-(b) [genuinely open; narrows sharply once (1) lands]; (3) builtin-method catalog in scope? [±40-80h; do not let it default]; (4) amend §7.5 to its provable domain? [independent of the fork]; (5) warn→error default-on at v1? ★ **METHOD GAP, DISCLOSED:** the gradual-typing `any`-poison voice was MISSING from the roster; `gradual-typing-boundary-expert` was **forged this session → live NEXT boot** (harness constraint re-confirmed empirically: a fresh agent is not dispatchable in the session that authored it). Its substance was carried as [EXEC] facts + the type-systems pole's Siek&Taha consistency-vs-subtyping diagnosis; **the migration-LADDER half (Sorbet sigils / `noImplicitAny` staircase) went unargued** — if call (2) or (5) is live at ruling time, re-boot + poll it (one question, not a re-run). **Artifact:** `scrml-support/docs/deep-dives/type-system-assignability-dpa-036-2026-08-22.md` (642 lines, pushed `0ed03b7`). **Insight CANDIDATE staged, NOT landed.** ⟨ORIGINAL BANK FRAMING FOLLOWS⟩ Banked S354-bryan 2026-08-22. **THE §7.5 ASSIGNABILITY QUESTION: scrml has type ANNOTATIONS but no type SYSTEM for expressions.** ★★ **[EXEC] THE FINDING, PA-compiled at HEAD — §7.5 (`SPEC.md:6149`) says *"the compiler SHALL emit E-TYPE-031 if a non-assignable type is assigned"*, and THREE OF FOUR POSITIONS ARE SILENT:** `let x: number = "hello"` → **fires** · `<n>: number = "hello"` → **compiles clean** · `double("str")` where `a: number` → **compiles clean** · `-> number { return "not a number" }` → **compiles clean**. Only the cell hole is filed (`g-no-reactive-cell-assignment-type-check`, HIGH). **The argument and return holes have NO gap entry and NO §34 error code** — they were unknown until this census. ★★ **AND OPERAND TYPING DOES NOT EXIST AT ALL:** `let s: string = "x"; return s * 2` → clean · `return "x" * 2` (a string LITERAL times a number) → clean · `let n: number = 5; return n.toUpperCase()` → clean. `type-system.ts` has no binary-operand check; its only arithmetic-aware code is a heuristic that DETECTS arithmetic to classify an expression and never validates operands. ⚑ **THE OPERATOR HIT THIS INDEPENDENTLY WHILE WRITING REAL SCRML, within the hour of the census probe finding it** — `fn do_thing(a: number, b: string) { return a * b }` + `do_thing(2,3)`: compiles green, no LSP diagnostic (the LSP surfaces compiler diagnostics and the compiler produced none), and the emitted output ERASES the annotations entirely (`do_thing_1(a, b)`). `fn` is correct spelling (§33/§48 canonical pure form) — this is not an authoring error. ★ **THE SUBSTRATE, so scope is not guessed:** the ONE working position is ~20 lines at `type-system.ts:10098-10118`, handles exactly three annotations (`number`/`string`/`boolean`), only when the initialiser is a LITERAL, and infers via JS `typeof` on the literal's value. **Its own comment says *"More elaborate type inference can come later."*** A `ResolvedType` model (~25 kinds) AND an assignability relation (`fieldTypeAssignable`, `type-system.ts:850`) both EXIST — but scoped to **SQL/struct FIELD types** (§14.8 generated table types). **The type REPRESENTATION exists; expression INFERENCE does not.** Nothing can answer *what is the type of `a * b`*, *of `do_thing(2,3)`*, or *of this identifier here*. ★ **[EXEC] BLAST RADIUS, of 2,014 corpus `.scrml`:** typed parameters **240** · return annotations **103** · typed cells **211**. ~A quarter of the repo's own corpus enters a check it has never been subject to. Adopter code is unmeasured and, per the operator's React framing, growing daily. ★★ **THE FORK — not *whether* (the operator has ruled cost-in-development acceptable) but WHAT GETS BUILT, and it is one-way because it defines what a scrml type MEANS:** **(a) literal-and-annotation propagation** — extend the existing shape, check the four positions, stay silent where uncertain. Cheap, fail-open by construction, catches the operator's repro. ⚑ **But it is the same RETROFIT shape that produced this** — a checker that gives up quietly has a meaningless zero-bug-family, which the retrofit census PROVED with §32 `~` (zero gaps, fail-closed SHALL, **rule does not fire**: `return step2(~)` uninitialised compiles clean and emits `null /* ~ orphaned */`). **(b) a real expression type-inference pass** — bidirectional checking over the AST, proper lattice, `asIs` as honest top. Answers all four positions PLUS operands, and the LSP gets real types for the first time. Large; will surface holes everywhere it touches, which is the point. **(c) (b) + fail-closed on un-inferable** — maximum soundness, maximum ADOPTER cost, and therefore the wrong side of the S354 cost boundary ([1678]). **PA RECOMMENDATION: (b).** ⚑ **THE QUESTION THE DD MUST SETTLE INSIDE (b), because it decides whether (b) decays into (a):** *what does `asIs` mean at a parameter boundary?* It is the honest escape today — but if it silently absorbs every un-inferable expression, (b) degrades to (a) over time and **nobody notices, because the bug family stays empty.** ★ **DO NOT RE-DERIVE:** the four positions and the operand holes are `[EXEC]`-measured above; the substrate inventory is read, not assumed; blast radius is counted. ⚑ **ATTRIBUTION CHECKED, NOT ACCEPTED — the operator suggested *"I insisted on a dumb type system"* is the cause. The record does not support it as a ruling:** zero user-voice hits for a dumb/simple-type-system ruling, zero design-insights; and the SPEC's surfacing stances point the OTHER way — §18704 makes attribute type checking *"always strict regardless"* because *"wrong attribute types produce incorrect generated code"*, and two design-insights treat the type system as load-bearing (*"must be encoded at the declaration site … as a type-system-visible distinction"*). **A grep miss is not proof it was never said.** But the sharper point: **a DUMB type system and an ABSENT one are different.** Dumb-but-honest = *"I check literals against primitive annotations; everything else is `asIs`"* — roughly what the code comment claims. What §7.5 has is annotations **parsed, stored, and never consulted**, while the SPEC promises all four positions. **That is a contract-vs-implementation gap, not a design-ambition error** — choosing simplicity is legitimate; §7.5 promising completeness is not a consequence of it. §18704's own rationale (*wrong types produce incorrect generated code*) is precisely the argument for checking parameters: `a * b` on a string produces incorrect generated code. ★ **RANKED #1 by the S354 retrofit census** on *(bug density × surface-change-required)*: no syntax change, but **the cost grows with every line of scrml written before it is switched on** — every program relying on an unchecked argument breaks the day it starts working. This is the purest instance of the operator's one-chance constraint. | **RATIFIED S365 2026-08-23 (bryan)** — *"ratify 1, take 3 and 4, hold 5"*. **Call 1 (the `asIs` split) RATIFIED, one-way, authoring surface** — `asIs` means the developer signed for it, never *the compiler did not look*; inference failure is structurally incapable of producing it and yields a counted, loud gap that still PASSES. Mechanism ratified with it: `Result<ResolvedType, InferenceGap>` where constructing a gap REQUIRES naming the AST node kind, plus an exhaustive switch with a `never` fallthrough. **Call 3 (builtin-method catalog) TAKEN — stays IN scope.** **Call 4 (amend §7.5 to its provable domain) TAKEN.** **Call 5 (warning->error default-on at v1) HELD — not decided.** Established as a CONFORMANCE defect against S174 (`SPEC.md:19236` already said *"a deliberate, named untyped escape hatch"*), not a new one-way door. Build: rung 0 on `feat/s365-asis-split-rung0`, DO-NOT-LAND on SPEC text only, fix round dispatched. Full ruling: `user-voice-scrml.md` S365; delta-log [1692]-[1693], [1702]. |
 | dpa-037 | **COMPLETE (ADVISORY) dPA 2026-08-31 — awaiting bryan's ruling on FOUR calls (§7).** Call 1 BLOCKING: is NaN a defined value (#2, ~20-45h) or outside the value domain (#3, 240-490h)? ⚑ Call 2 is NEW and not in the item: ship the `==` fix as the operator alone or as the comparison FAMILY — the DD recommends the family, and recommends doing NOTHING over half a fix. ⚑ Call 3 CONTRADICTS the recorded lean (`1/0` is the least NaN-like of the four; the `-0` argument is inverted). Call 4: split `toNumber` out and take it now (0 call sites). 6-pole panel incl. a domain expert forged mid-run + polled ADVERSARIALLY, which conceded the conclusion while striking two premises. NOT RATIFIED — RUN-not-RATIFY. **THE NON-FINITE FLOAT CLASS — NaN and Infinity have no normative home, and `==` is not reflexive because of it.** ⚑ **NOTHING HERE IS RATIFIED.** bryan supplied a WORKING TAKE and then said so explicitly: *"ok hold on I am not ratifying NaN! TBC"*. His lean, recorded as a lean: *"NaN and Infinity are NOT absence values"* / *"what we have here 1/0 ***IS*** not a number"* / *"and then Inf well..."*. **Every limb stays live, including `not`-absorbs-NaN.** PA-MEASURED BY EXECUTION at `952cecc6`, do not re-derive. | banked |
+| dpa-040 | **BANKED — UNRUN** S395. Should an if-as-expression ARM BODY be a `~` context boundary in its own right (§32.4, beside `${}` contexts and function bodies)? ⛑ **Banked BY the S395 ruling, not after it** — bryan answered *"your rec"* to *"(a) now, with (c) named as the question behind it"*, so per S276/S130 the ratification adopted BOTH halves and (c) is explicitly NOT closed. Limb (a) settles the §17.6.2-vs-§32.2 conflict by CARVE-OUT; (c) would remove the conflict's possibility BY CONSTRUCTION — squarely the S322 retrofit-vs-by-construction test applied to `~`. ⛑ **Urgency evidence:** §32's enforcement DOES NOT FIRE — six probes incl. SPEC §32.5's own verbatim `${ process(~) }` and §17.6.6's partial-`if` example produce ZERO `E-TILDE` diagnostics on merged main, though `TildeTracker`/`checkLinear` exist and `checkLinear` is invoked unconditionally at `type-system.ts:24470`. Cause NOT traced; phase 1 MUST re-verify by execution before reasoning from it. Boundary SET is the question — `~`-as-`lin` (§32.3) is NOT on the table. Adding a boundary is the LIMIT direction (row 1) but is `semantics-changed` and owes a MEASURED migration. Corpus-zero is blast radius ONLY, never demand evidence (S346). | the S395 `~` ruling (user-voice S395) |
 
 **⚠ DRAIN-PATH RULE (S319).** The dPA drains **THIS file**. A deliberation banked anywhere else does not exist to it. Witnessed S316→S319: seven conclusions were rung-assigned into `scrml-support/docs/deep-dives/S316-DELIBERATION-QUEUE.md` and the hand-off recorded *"the dPA is RUNNING on Q1/Q2/Q3"* — it was not and never had been; the dPA drained the dpa-018 Pole-D conditional (which IS in this file) instead, and the three deliberations sat unrun across two sessions while every build that depended on them stayed held. **Same shape as the review-floor and `gh issue list` misses: an obligation named in one place, a probe reading another.** Bank deliberations HERE; a separate rung-assignment doc is a companion, never the carrier.
 
@@ -2442,3 +2443,38 @@ The adopter says *"We surveyed the source before asking"* and states 1-3 as fact
 - Do not accept "we'd vendor a PDF lib via the `.js` sidecar" (Q4) as settling Q4. That is what they will do ANYWAY; the question is whether scrml wants a story.
 - Do not answer Q5 by restating the stance. They are asking for confirmation it is LONG-TERM, which is a commitment, not a description.
 - Do not let Q1 be answered as "use `handle()`" without answering Q2, because Q2 is the reason `handle()` is unsatisfying.
+
+---
+
+## [dpa-040] deep-dive — should an if-as-expression ARM BODY be a `~` context boundary in its own right?
+
+`status: BANKED — UNRUN` · **origin:** the S395 `~` ruling; banked BY that ruling, not after it · banked S395-bryan 2026-09-02
+
+⚑ **This is limb (c) of a three-limb fork bryan ruled on 2026-09-02, and it was banked BY the ruling itself.** He answered *"your rec"* to *"(a) now, with (c) named as the question behind it"* — so per the S276/S130 durable the ratification adopted **both halves**: limb (a) governs today, and **(c) is explicitly NOT closed.** Do not treat the S395 landing as having settled this.
+
+### The question
+
+§32.4 makes `~` non-crossing at exactly two boundaries: a `${}` logic context, and a function body. **Should an if-as-expression arm body be a third?**
+
+Under (c) there is nothing to arbitrate between §17.6.2 and §32.2: a bare call inside an arm fills the *arm's own* `~` slot, `lift` designates the *arm's* result through a different mechanism, and the two sections cannot contradict each other **by construction** rather than by carve-out.
+
+### Why it was not just ruled at S395
+
+The ruling took (a) — §17.6.2 governs, a bare call in an arm is a side effect — because it is specific-over-general, fixes the root, and restores a shape SPEC ships a worked example for. **But (a) is a CARVE-OUT: it settles the conflict by amending §32.2 to exempt arm bodies.** (c) would remove the conflict's possibility instead. That difference is the whole question, and it is squarely the S322 re-examination test — *retrofit vs by construction* — applied to `~`.
+
+### ⚑ THE EVIDENCE THAT MAKES THIS URGENT — the enforcement does not fire
+
+**Six probes on merged main, including SPEC §32.5's own verbatim `${ process(~) }` and §17.6.6's partial-`if` example, produce ZERO `E-TILDE` diagnostics.** Not from absence: `TildeTracker`, `checkLinear`, and both `E-TILDE-001`/`E-TILDE-002` exist in `type-system.ts` with real messages, and `checkLinear` is invoked unconditionally at file level (`:24470`). It runs; it does not fire on the documented shapes. **Cause NOT traced** — filed as `g-tilde-lin-enforcement-does-not-fire-on-spec-own-examples`.
+
+**That silence is why a live contradiction between two normative sections survived unnoticed.** A DD on (c) that does not account for it is reasoning about a rule nothing enforces.
+
+### Load-bearing constraints (do not let the DD drift past these)
+
+- **`~` is a `lin` variable (§32.3) and that is not on the table.** The question is its BOUNDARY SET, not its exactly-once semantics.
+- **Direction matters:** adding a boundary NARROWS `~`'s reach — the LIMIT direction, fork-rule row 1, which favours it. But it is also `semantics-changed` for any existing program that relied on `~` crossing an arm boundary, so it owes a MEASURED migration, not an assumed-zero one.
+- **The S395 blast-radius measurement is a floor, not an answer:** the bare-expr-in-arm shape is **corpus-zero** (of 5 bound-position if-as-expression sites, the only one with an intermediate statement uses a `let`-decl, which does not rebind). Per bryan's own S346 ruling, corpus-zero is **blast radius ONLY, never demand evidence** — and this corpus is 100% LLM-authored, so it carries almost no ergonomic signal. Do not close (c) on corpus silence.
+- **Phase 1 MUST re-verify the E-TILDE non-firing by execution** before reasoning from it. It is PA-measured but the cause is untraced, and a DD that inherits an untraced claim is the laundering shape.
+
+### What a verdict has to deliver
+
+Either (i) a boundary rule for §32.4 with its migration measured and its interaction with the S395 §32.2 carve-out stated — does the carve-out get REVERTED, or does it become redundant? — or (ii) a recorded reason the two-boundary set is right and arm bodies are correctly ordinary, in which case the S395 carve-out is the permanent answer and should be marked as such rather than left looking provisional.