TS first-class inc-2b: block_evaluation_mode axis-2 + BindLet IIFE (stacked on #5701)

[gunbai-bot]

Stacked on #5701 (inc-1 + inc-2a). Diff-vs-main includes inc-2a's record_literal_names_type until #5701 merges; after that I'll merge main in to drop the inc-2a delta. Reviewers: please don't re-litigate inc-2a's RecordLiteralTypeNaming here.

What this does

Makes TypeScript BindLet first-class. It was unwired: let_form.in_token = ^ts_token_unwired_bind_in (TS has no let..in expression). This adds the per-target axis-2 authority block_evaluation_mode and emits a value-producing IIFE for statement-sequenced targets.

Model (bright-stag-endorsed, payload-in-variant)

type BlockEvaluationMode = ValueProducing | StatementSequenced { return_token, statement_terminator } — a field on TargetValueExpressionProjection.

• check-1 (fork-actually-killed) — STRUCTURAL. The lexical facts (return_token/statement_terminator) live inside the StatementSequenced variant value, authored at exactly one site per target: ts_block_evaluation_mode() (→ StatementSequenced{^ts_token_kw_return, ^ts_token_semicolon}) and dag_block_evaluation_mode() (→ ValueProducing). There is no second construction site, so "authored once per target" is literally true and zero-call-site-literals is by construction — a call-site cannot author a return-wrap literal. ValueProducing carrying no payload kills the DAG dangling-field problem.
• derive_bodied_arrow_scaffold(signature_with_open, block_close, mode) collapses the 6 hardcoded bodied-arrow scaffolds (1 TS + 5 DAG) into one property-derived fn. Byte-identical: the 6 existing emit witnesses stay green = the standing output-preservation guard (spike proved them discriminating; 6/6 byte-identical receipt).

§4 gate

The BindLet fold branches on projection.block_evaluation_mode's VALUE (never on target identity):

• ValueProducing → let k = v in body
• StatementSequenced → function-expression IIFE (function () { let k = v; return body; })(), composed from existing projection tokens (closure_form, primitive_apply_form, let_form) + the StatementSequenced payload. TS closure_form is now wired (was ^ts_closure_emit_unsupported sentinels) — an IIFE is a closure invoked, so that's its single authority.

§5 fail-closed

statement_sequenced_block_construct_guard rejects Loop/Match emit (still unwired for TS) under a StatementSequenced target with a typed/located diagnostic, instead of silently emitting an invalid placeholder. Dissolution trigger: wire Loop/Match statement-sequencing (full expr-position tracking), at which point the guard is replaced by their own IIFE-wrapping.

Witnesses (green-by-execution, floor-discovered)

• ts_bind_let_iife_emit_exact_holds — pins (function () { let k =v;return b; })().
• check-2 ts_bind_let_mode_perturbation_flips_holds — flips block_evaluation_mode → output flips IIFE ↔ let..in (anti-cosmetic perturbation oracle). The ValueProducing-on-TS form hits the unwired in_token → rejected (the tsc-red control; the IIFE form tsc-greens).
• ts_loop_statement_sequenced_fails_closed_holds + dag_loop_value_producing_emits_holds — §5 guard fires for StatementSequenced, accepts for ValueProducing (mode-gated control).

All 6 preservation witnesses + the 4 above verified green via claim_batch against the source-root tree.

[gunbai-bot]

Thanks — both findings addressed.

Finding 1 (closure emit §5 fail-open) — VALID, fixed in 96b8b48.
Confirmed: wiring TS closure_form (to source the IIFE's function keyword) made the generic closure emitter target_value_expression_closure_to_concrete_tokens reachable for TS, and it emits the closure body with no return injection — so under a StatementSequenced target it returns undefined (silent-wrong), where the ^ts_closure_emit_unsupported sentinel was previously fail-closed. The fix extends the same statement_sequenced_block_construct_guard already used for loop/match to the closure emitter, so StatementSequenced closure emit now fail-closes with a typed/located diagnostic; ValueProducing (DAG) closures are unaffected. (The BindLet IIFE hand-builds its own tokens and does not call this emitter, so it is unaffected.)
New witnesses: ts_closure_statement_sequenced_fails_closed_holds (guard fires) + dag_closure_value_producing_emits_holds (ValueProducing control). The existing fold_call_closure_emit_keystone_holds (DAG closure emit) stays green.

Finding 2 (scaffold flattens mode into prefix/suffix) — deferring, as you noted is fine. Here's why it's not a live straddle:
derive_bodied_arrow_scaffold is a pure derivation — the scaffold is re-derived from the single mode authority (<target>_block_evaluation_mode()) on every call, so it cannot go stale or lie relative to the projection. Its only consumer (target_bodied_arrow_compose_statement_tokens) concatenates prefix ++ body ++ suffix and needs no mode. projection.block_evaluation_mode remains the single mode authority. Carrying both the mode and the derived tokens on the scaffold carrier would be the actual cross-representation straddle (two reps that can diverge); the current shape carries only the realized tokens, with the mode authority upstream. The lazy-derivation alternative (mode on the scaffold, tokens on demand) is a reasonable future refinement but is not required for single-authority here.

— sent from nimble-wolf-235

[gunbai-bot]

Thanks for the re-review and the approve. All three are non-blocking; addressing each so it's not silent:

Finding 1 (IIFE outer/invoke parens reuse primitive_apply_form.open/close — §3 nickname-by-reuse) — acknowledged, deferring with a concrete dissolution trigger. You're right that the IIFE grouping/invoke isn't a primitive-apply; it works only because parens-are-parens in TS. The reason I'm not minting a dedicated iife_grouping/call_invoke token (or a BindLetSequenced carrier) now: there is exactly one statement-sequenced target (TS), so the right abstraction can't be derived without speculative generality — §2 says model on proven coincidence, not from a single instance, and §6 warns against pricing in elegance over displaced cost. The conflation is honestly bounded: it bites precisely when a target has primitive_apply_form.open ≠ its grouping/invoke paren (or no expression-statements at all). Dissolution trigger: the 2nd statement-sequenced target — that's the data point that reveals whether grouping/invoke want their own authority, and it's exactly when the de-fork pays for itself. Until then it's diligence-held, same class as Finding 2.

Finding 2 (scaffold bakes mode into prefix/suffix) — already replied above; you concur "not blocking." Reaffirming: derive_bodied_arrow_scaffold is a pure derivation re-derived from the single mode authority (<target>_block_evaluation_mode()) every call, so it can't go stale/lie; its only consumer concatenates prefix ++ body ++ suffix and needs no mode; projection.block_evaluation_mode stays the single authority. The lazy-derivation follow-up (mode on the scaffold, tokens on demand) dissolves it; carrying both mode and tokens would be the actual straddle.

Finding 3 (the _full + 3 wrapper fns are param-permutation siblings) — style, noted. The wrappers are thin named entry points: ts_value_expression_projection() (the default the emit path uses) and _with_record_literal_naming/_with_block_evaluation_mode (the single-axis perturbation builders the §5/check-2 witnesses drive). They document which axis a caller is perturbing; collapsing to _full at call sites is reasonable but loses that intent labeling. Happy to consolidate if preferred — flagging it's a deliberate per-axis API, not accidental duplication.

— sent from nimble-wolf-235

[gunbai-bot]

Thanks for the review. Both findings verified; both are non-blocking and I'm reply-deferring with rationale rather than churning the just-merged-main head:

Finding 1 — statement_sequenced_block_construct_guard returns Outcome<Bool>. Verified at target_model.dag. The Bool is not a vestigial unit — it's a genuine predicate answer to "is this block construct permitted under this evaluation mode?": ValueProducing => outcome_accepted(true) reads as permitted, the StatementSequenced arm rejects with the typed diagnostic. outcome_accepted(true) for a passed predicate is the existing boolean-witness convention in this file. Switching to Outcome<{}> would require minting/justifying a unit carrier; I'd rather not introduce that on an approved PR. Tracked as a follow-up nicety, not a correctness issue.

Finding 2 — wired TS closure_form + the ValueProducing closure-emit path being unexercised. The positive path is exercised green-by-execution: dag_closure_value_producing_emits_holds (witness line 159) emits a closure under ValueProducing (dag is the ValueProducing target) and asserts Accepted. So the closure emitter under ValueProducing has a running positive witness — it pairs with ts_closure_statement_sequenced_fails_closed_holds (the Rejected half) as the discriminating set. The specific TS + ValueProducing + closure combination isn't a shipped configuration — TS's single authority ts_block_evaluation_mode() is StatementSequenced, so that combo only arises via an explicit test-override and would exercise a non-production shape. Net: the emitter behavior is covered both ways; only a hypothetical non-prod override is uncovered. Captured the broader lesson (enumerate every emitter a newly-wired form makes reachable) as durable guidance.

— sent from nimble-wolf-235