#617 M4: the LIST_TAKE_AFTER_FLATMAP note — the plan's Core shape would have shipped a detector that never fires by sunholo-voight-kampff · Pull Request #681 · sunholo-data/ailang

sunholo-voight-kampff · 2026-08-12T16:58:45Z

Closes the final milestone of #617 (m-take-flatmap-peak-memory), the sprint plan's declared CUT LINE. Closes AC-6. V1 mission iteration 186.

What landed

A non-blocking check-time diagnostic LIST_TAKE_AFTER_FLATMAP that fires on take(n, flatMap(f, xs)) and points at the fused takeFlatMap(n, f, xs) M2 exported:

New internal/pipeline/warn_take_after_flatmap.go — TakeAfterFlatMapWarning (Code()/Position()/String(), var _ elaborate.Warning assertion) + DetectTakeAfterFlatMap, modelled on strict_fallbacks.go.
Wired into both pipeline_module.go (inside the sorted-modID loop, deterministic order) and pipeline_single.go (a consistency no-op there — imports are not resolved to VarGlobal), matching how the two existing detectors are wired.
Four warning-based fixtures as a new test func writing real files to t.TempDir(), not a footgunFixtures row — plan decision D-4, because footgun_fixtures_test.go:212 fatals on err == nil, which is exactly what a non-blocking warning returns. The design doc's AC-6 text describes the impossible mechanism; the plan wins.
footguns.md row flipped to shipped-this-sprint; changelog's stale "remains inventoried" sentence replaced.

The finding: the plan would have shipped a detector that never fires

The executor self-reported a deviation, and it is #617's own failure mode one layer up. The plan prescribes matching App(take, [n, App(flatMap, [f, xs])]). Elaboration in fact always emits ANF: let tmp = flatMap(f, xs) in take(n, tmp).

Adjudicated by measurement in both arms rather than from the executor's report:

Arm	Mutation	Landed	Builds	Result
A — plan's shape only	neuter the ANF arm	sha `21a22852`→`7b042ce3`	`go build` rc=0	RED: `.../direct_trap`: `expected LIST_TAKE_AFTER_FLATMAP warning, got warnings: []`
B — as shipped	none	—	—	rc=0

So a literal implementation would have produced a green suite pinning nothing, inside the very sprint fixing a shipped-but-unreachable defect.

The converse is recorded rather than assumed: neutering the nested-App arm alone leaves ./internal/diag and ./internal/pipeline fully green, so that branch is unexercised defensive code — named in a comment at the site instead of letting arm-count arithmetic imply coverage.

Reachability — the check that matters most for #617

Verified through the real CLI, not just the test harness: ailang check on a trap file prints the note with its full fix text, rc=0, ✓ No errors found! still shown (genuinely non-blocking). Negative control: the fused file is silent (0 hits).

Verification

Four executor fixture mutation drills (trap / fused / take∘map / sortBy), each landed + building + naming a failing subtest, all restored byte-identical from cp backups. Its first sortBy mutant stayed green — internal std/list.sortBy calls resolve locally, not as VarGlobal — and was replaced with an effective one. Refusal-branch audit on the M4 diff: 0 new branches.

All gates re-run by the controller outside the codex sandbox (executor gate results are never banked): go build, go test ./internal/diag ./internal/pipeline, go vet, gofmt -l, check-file-sizes, check-boundaries, check-changelog — all rc=0.

Evaluator (sonnet, distinct provider from the codex executor): PASS 98/100 round 1, zero blocking. It independently reproduced the both-arm drill, verified CLI reachability, and wrote 8 adversarial fixtures of its own (module-alias and symbol-alias imports, local shadowing, reused intermediates, lambda-nested traps, intervening calls) — all behaved correctly.

Its one non-blocking finding was reproduced first-party before being acted on: nested composition reports only the outermost trap (take(2, flatMap(g, take(3, flatMap(h, xs)))) → 1 of 2), because ANF wraps the inner trap in an extra Let the detector does not unwrap. Filed as #680 with a suggested fix and recorded in the #617 footguns row rather than left implicit.

Co-Authored-By: codex <gpt-5.6-sol>

🤖 Generated with Claude Code

… would have shipped a detector that never fires M4 (the sprint's declared CUT LINE) adds the non-blocking check-time note: a TakeAfterFlatMapWarning (Code/Position/String, `var _ elaborate.Warning` assertion) plus DetectTakeAfterFlatMap, wired into BOTH pipeline_module.go (inside the sorted-modID loop, deterministic order) and pipeline_single.go (a consistency no-op there — imports are not resolved to VarGlobal), matching how the two existing detectors are wired. Four warning-based fixtures land as a NEW test func writing real files to t.TempDir(), NOT a footgunFixtures row: plan decision D-4, because footgun_fixtures_test.go:212 fatals on err == nil, which is exactly what a non-blocking warning returns. THE EXECUTOR'S SELF-REPORTED DEVIATION IS THE FINDING, and it is #617's own failure mode one layer up. The plan specifies matching `App(take, [n, App(flatMap, [f, xs])])`; elaboration in fact always emits ANF, `let tmp = flatMap(f, xs) in take(n, tmp)`. Adjudicated by measurement in both arms rather than from the executor's report: neutering the ANF arm LANDS (sha 21a22852→7b042ce3), BUILDS (go build rc=0, so the red is not a compile failure) and reds TestTakeAfterFlatMapWarningFixtures/direct_trap with "expected LIST_TAKE_AFTER_FLATMAP warning, got warnings: []". So the plan as written would have shipped a detector that never fires — a green suite pinning nothing, in the very sprint fixing a shipped-but-unreachable defect. The converse arm is recorded rather than assumed: neutering the nested-App arm alone leaves ./internal/diag AND ./internal/pipeline fully green, so that branch is unexercised defensive code. Named in a comment at the site instead of letting arm-count arithmetic imply coverage. Four fixture mutation drills by the executor (trap/fused/take-map/sortBy), each landed + building + reporting a named failing subtest, all restored byte-identical from cp backups. Its first sortBy mutant stayed green — internal std/list.sortBy calls resolve locally, not as VarGlobal — and was replaced with an effective one. Refusal-branch audit on the M4 diff: 0 new branches (warn_take_after_flatmap.go 0, the 10 in the two pipeline files predate M4). Gates re-run OUTSIDE the sandbox by the controller (executor gate results are never banked): go build, go test ./internal/diag ./internal/pipeline, go vet, gofmt -l, check-file-sizes, check-boundaries, check-changelog — all rc=0. Closes AC-6. Co-Authored-By: codex <gpt-5.6-sol>

…ed/v1_1_0 Sprint-evaluator verdict on 5e4d629: AC-6 closed, all milestones (M1-M4) landed. Re-ran gates outside sandbox (build/test/vet/gofmt/file-sizes/ boundaries/changelog, all rc=0) and independently reproduced the executor's self-reported ANF-vs-nested-App finding in both arms via mutation testing. Own adversarial fixtures (aliasing, shadowing, nested composition, lambdas) found the detector solid on the primary trap shape and reachable through `ailang check`; one non-blocking false-negative noted for traps nested as an argument to an outer flatMap (not covered by the four shipped fixtures). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…luator (#680) Reproduced first-party through the real CLI before recording: a trap nested as an argument to another trap reports 1 of 2 (outer only), because ANF wraps the inner one in an extra Let that directTakeFlatMap does not unwrap. Controls in the same session: the inner expression fires when isolated, the fused file is silent. Non-blocking false negative on a teaching note; filed as #680 with a suggested fix, and named in the footguns row rather than left implicit.

…coverage gate SonarCloud red on this PR (56.1% coverage on new code, gate 80%) — negative control: Sonar is success on dev, so it is this PR's, not inherited. The uncovered lines were exactly the branch I had already MEASURED as unexercised: Position() at 0%, the nil guard, and the isTakeOfFlatMapApp arm that elaboration never produces because it always emits ANF. Rather than leave a named gap, pin it: TestDetectTakeAfterFlatMap_NestedAppArm drives DetectTakeAfterFlatMap against a hand-built Core program, which is the only way to reach that arm at all. Non-vacuity proved rather than assumed — neutering the arm with 'false &&' LANDS (sha256 differs), BUILDS (go build rc=0, so the red is not a compile failure) and reds the new test with 'expected 1 warning, got 0'; restored byte-identical from a cp backup. Also adds five Core-level negative shapes (take-of-map, flatMap from another module, a local non-global take, an ANF let bound to something else, and an ANF take reading a different binding) which pin the direct-argument scope rule, and a nil-program case. Coverage on the new file: Position 0 -> 100%, DetectTakeAfterFlatMap 85.7 -> 100%, directTakeFlatMap 84.6 -> 92.3%. The file comment is corrected in the same commit — it claimed the arm was unpinned, which this commit makes false.

sonarqubecloud · 2026-08-12T17:41:36Z

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
97.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

…ut the plan's Core shape would have shipped a detector that never fires Records for iteration 186: charter STATUS stamp (rotation invariant held at 3, line-count assertion passed, queue-row control fired), mission log entry 188, dashboard refreshed, #617 queue row IN-SPRINT -> LANDED (COMPLETE, M1-M4) with the M4 record (merge 905722f, PR #681, evaluator sonnet PASS 98/100 r1). The iteration's finding is the executor's SELF-REPORTED deviation: the sprint plan specified matching App(take, [n, App(flatMap, [f, xs])]), but elaboration always emits ANF. Adjudicated by measurement in both arms rather than from the executor's report (rule 3h(b)) — neutering the ANF arm LANDS, BUILDS and reds /direct_trap with 'got warnings: []'. The plan as written would have shipped a detector that never fires: #617's own shipped-but-unreachable failure, recreated inside the sprint fixing it, and the third form of it in this sprint's lifetime. Also records: the unexercised nested-App arm named then pinned after SonarCloud's coverage gate landed on exactly those lines; #680 filed for the nested-composition false negative the evaluator found and I reproduced first-party; and two of my own instruments failing and being caught by their paired controls. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

…ut the plan's Core shape would have shipped a detector that never fires (#682) Records for iteration 186: charter STATUS stamp (rotation invariant held at 3, line-count assertion passed, queue-row control fired), mission log entry 188, dashboard refreshed, #617 queue row IN-SPRINT -> LANDED (COMPLETE, M1-M4) with the M4 record (merge 905722f, PR #681, evaluator sonnet PASS 98/100 r1). The iteration's finding is the executor's SELF-REPORTED deviation: the sprint plan specified matching App(take, [n, App(flatMap, [f, xs])]), but elaboration always emits ANF. Adjudicated by measurement in both arms rather than from the executor's report (rule 3h(b)) — neutering the ANF arm LANDS, BUILDS and reds /direct_trap with 'got warnings: []'. The plan as written would have shipped a detector that never fires: #617's own shipped-but-unreachable failure, recreated inside the sprint fixing it, and the third form of it in this sprint's lifetime. Also records: the unexercised nested-App arm named then pinned after SonarCloud's coverage gate landed on exactly those lines; #680 filed for the nested-composition false negative the evaluator found and I reproduced first-party; and two of my own instruments failing and being caught by their paired controls. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

sunholo-voight-kampff and others added 4 commits August 12, 2026 18:45

sunholo-voight-kampff merged commit 905722f into dev Aug 12, 2026
21 checks passed

sunholo-voight-kampff deleted the sprint/iter186-617-m4 branch August 12, 2026 17:45

sunholo-voight-kampff mentioned this pull request Aug 12, 2026

docs(mission): iteration 186 — #617 M4 landed and #617 is complete, and the plan's Core shape would have shipped a detector that never fires #682

Merged

sunholo-voight-kampff mentioned this pull request Aug 12, 2026

V1 mission bookkeeping — week of 2026-08-10 #635

Open

Navigation Menu

Uh oh!

#617 M4: the LIST_TAKE_AFTER_FLATMAP note — the plan's Core shape would have shipped a detector that never fires - #681

#617 M4: the LIST_TAKE_AFTER_FLATMAP note — the plan's Core shape would have shipped a detector that never fires#681
sunholo-voight-kampff merged 4 commits into
devfrom
sprint/iter186-617-m4

sunholo-voight-kampff commented Aug 12, 2026

Uh oh!

sonarqubecloud Bot commented Aug 12, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

sunholo-voight-kampff commented Aug 12, 2026

What landed

The finding: the plan would have shipped a detector that never fires

Reachability — the check that matters most for #617

Verification

Uh oh!

sonarqubecloud Bot commented Aug 12, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant