Complexity gating (i): completeness-gated import-closure parallel-representation prevention wall

[gunbai-bot]

What

The first real enforced wall from the complexity-gating lane. A change-time / §2–§4 structural (parallel-representation) wall: a module's declared consumed-input closure must equal its derived import closure (import_closure_live over witness_layer_roots).

It folds the whole declared_consumed_input_closures registry, so any future declared closure is auto-covered by the same gate — closing the "only the one conformance closure is hand-witnessed" gap. Forward-looking ask-once-compile-forever prevention, not instance-count-bound.

Why (mandate context)

Deliverable-1 audit found: complexity detection is real, enforcement is zero (always_required_lenses = [fact_density, unit_modeling]; every cost/complexity lens is WitnessOnly-on-fixtures). Root cause: runtime-quadratic walls are blocked because v2 doesn't lower real fn bodies to inspectable Loop nodes (body_lowering unwired) — dispatched separately as a compiler milestone. The decidable structural class is real today; this is the first wall from it. The registry is 1 clean entry (0 drift), so it lands clean with no self-poison — modest-but-real prevention.

Green-by-execution (v1 floor engine = authority)

claim_batch over the new witness — 3 PASS:

• all_declared_import_closures_have_no_drift — registry clean (0 drift)
• completeness_fold_reds_on_a_drifted_closure — red control fires on a drifted closure
• fold_auto_covers_a_newly_added_closure — completeness: injected drift into the registry-fold is auto-caught (no new hand-witness)

Existing conformance witness regression (import_closure_live_test) still PASS with the additive entry_path field.

Mechanism & honest enforcement-maturity caveat

• Realized as a floor witness (fail-closed: a red witness fails the floor). A corpus-level registry-fold check does not fit always_required_lenses (a per-compiled-node CompileLens); the floor witness is the correct fail-closed realization.
• main CI currently cancels at the 30-min compile-clean timeout before batch-2 witnesses run, so this wall — like every batch-2 witness — enforces on the local/scheduled floor run, not yet on main CI. Full CI enforcement follows the compile-clean-serial lane. (Stated in the witness doc too.)

Files

• dag/tools/rust_stage0_gates.dag — +entry_path on ConsumedInputClosure (additive)
• src/v2/test/claim/intent_linearity/lens_unit/import_closure_completeness_test.dag — new completeness-gated floor witness

🤖 Generated with Claude Code

[gunbai-bot]

CI ci failure here is the systemic compile-clean-gate 30-min timeout, not a defect in this PR — no fix to push.

Evidence:

• The ci job was canceled at 30m19s ("The operation was canceled" = the CI policy: 30-minute job timeout (workflow-layer policy over the modeled GitHub default) #6154 30-min job timeout) while still in batch-1 host-effects (the compile-clean gate ran ~29 min, 02:34→03:03). It never reached batch-2, where this PR's witness (import_closure_completeness_test) runs — so the failure cannot be caused by the new witness.
• rust_tests passed (3m14s) — the entry_path field addition + new .dag witness don't break the build.
• This is identical to Task E (1/2): model_anemia lens as a live consumer, over a shared scalar_leaf_grounding core #6183's ci (canceled at 30m20s in batch-1). The timeout is hit regardless of PR content because the compile-clean gate is the ~27–29 min floor dominator — exactly the CI-maturity caveat stated in this PR's description and in import_closure_completeness_test.dag:11.

This wall is verified green-by-execution on the v1 floor engine (claim_batch): all 3 witnesses PASS (clean / red-control / completeness) + the conformance regression. Its floor enforcement is real; full main-CI enforcement is gated on the compile-clean-serial lane fixing the timeout (a whole-batch-2 integrity gap, not this PR).

Review criteria are met (2 distinct approvals, no REQUEST_CHANGES, mergeable=CLEAN); the only open item is this systemic-infra CI timeout.

— sent from silent-ferret-137

[gunbai-bot]

State-clarity note (no action needed): the two latest approvals (reviews 34944/34945) ran against SHA 105a18c982, which transiently included two audit-table rows in structural_quadratic_wall_coverage_audit.dag. Those rows were a stray edit the auto-committer captured mid-work without the paired plan-doc regen (that regen routes to BuildBuddy-remote and can't see a working-tree edit), which would have drifted the .dag from its generated .md. I reverted them at 69bdfb26e0 to keep .dag↔.md consistent. Current HEAD 76484f74bc is therefore a strictly smaller, cleaner 2-file diff — the entry_path field on ConsumedInputClosure + the completeness-gated import-closure witness — with no audit-file change at all. The wall the reviews approved is unchanged; the removed rows were benign (they documented existing termination debt). The audit-row update now folds into the body-lowering Stage-1 PR, where the plan-doc regen runs locally and the row's final content is determined by that consolidation. — sent from silent-ferret-137

[gunbai-bot]

CI-failing investigation for run 28639436786 @ 76484f7 — this is the known systemic compile-clean timeout, NOT a defect in this PR, so there is no fix to push:

• ci job: FAIL at 30m20s = the workflow's 30-minute job timeout (CI policy: 30-minute job timeout (workflow-layer policy over the modeled GitHub default) #6154) killing the batch-1 dsl_compile_clean_gate before batch-2 witnesses (where this PR's witness runs) ever execute. Identical duration/signature to Task E (1/2): model_anemia lens as a live consumer, over a shared scalar_leaf_grounding core #6183 (30m20s) and this PR's earlier run (30m19s) — a fleet-wide floor-timeout, not width- or diff-specific.
• rust_tests: PASS (2m16s).

This PR's net diff is 2 files / 47 insertions (an additive entry_path field on ConsumedInputClosure + one completeness-gated witness test) — additive and structurally incapable of causing a batch-1 compile-clean timeout. The batch-1 compile-clean gate is the ~30-min serial dominator being addressed by the compile-clean-serial lane; until that lands, every PR's ci job cancels here and no batch-2 .dag witness is confirmable via main CI (this is the honest enforcement-maturity caveat already documented on the wall's witness).

Merge state is otherwise clean: 2 distinct dashboard approvals (claude, cursor, both on this HEAD), 0 REQUEST_CHANGES, mergeable=CLEAN. The only red is the systemic timeout, ignored per policy. — sent from silent-ferret-137

[gunbai-bot]

CI-failing at 3629894: same known systemic compile-clean timeout, nothing to fix. This SHA is purely an auto-merge of origin/main into the branch (to stay current, incl. #6190) — the PR's net diff vs main is UNCHANGED: 2 files / 47 insertions (the entry_path field + the completeness witness). Failure signature is identical to every prior run: ci FAIL at 30m20s = the 30-min job timeout (#6154) killing batch-1 compile-clean before batch-2 witnesses run; rust_tests PASS (45s). An additive 2-file diff cannot cause a batch-1 timeout, and merging main in didn't change the diff. Merge state remains clean: 2 distinct approvals (claude, cursor), 0 REQUEST_CHANGES, mergeable=CLEAN; the only red is the systemic timeout, ignored per policy. — sent from silent-ferret-137

[gunbai-bot]

CI re-run pushed (4a70a29). The prior red (run 28681037454) was the pre-#6155 batch-2 exit-137 OOM, not a defect in this PR: the floor claim_executor was Killed → exit 137 after running 77 min (so the 90-min timeout raise was in effect — a real OOM, not a timeout-cancel). That run's branch merge-base was #6188, predating #6155 (the compositional build_type_env OOM fix, merged 20:40).

Fix: merged current origin/main (including #6155) into this branch — clean merge, the import-closure prevention wall delta is unchanged (2 files, +47). CI is re-running with the memory fix. The wall itself (0-instance prevention) was never implicated.

— sent from silent-ferret-137

[gunbai-bot]

Re-run result (28683946983 with #6155): CANCELLED at the 90-min job timeout, not a defect in this PR. "The operation was canceled" on both jobs at 90m21s — no exit-137/OOM this time. So #6155 fixed the earlier OOM (the prior run was SIGKILL'd at 77 min); the floor now runs the full 90 min without dying but takes >90 min to complete, hitting the job timeout. That's a systemic floor-speed issue (ci_floor_plan throughput), not this wall — the import-closure prevention wall is unchanged and green locally.

Not pushing further changes here: integrating more main won't fix a systemic floor timeout. #6192 stays review-complete + mergeable; the CI red is the floor's global speed budget, tracked separately.

— sent from silent-ferret-137

[gunbai-bot]

CI red here is the #6155 whole-tree compile-time regression, not a defect in this PR — no code fix in #6192 applies.

Both failing checks are timeouts, not errors:

• ci — CANCELLED @ ~1h30m (no error/panic/assertion/OOM in the failed-step log)
• rust_tests — CANCELLED @ ~1h30m

This PR's diff is 2 files / 47 lines (an import-closure-completeness lens + one gate-wiring line) — it cannot cause a compile or test timeout, and it was review-complete (2 approvals) on its pre-#6155 base. The red was introduced by merging current origin/main (commit 36e026a) which carries #6155.

#6155's resolver rewrite regressed the whole-tree compile_to_resolved (typecheck) phase so it no longer completes within the CI window. This was independently diagnosed on #6209: the --target dag compile-clean gate is killed during compile_to_resolved on both a local run (crawls ~1 MiB/s) and a contention-immune remote BuildBuddy action (context deadline exceeded after resolving 859 sources) — so it is genuine wall-time, not memory/contention, and it blocks ci + rust_tests for all PRs on a post-#6155 base until the compile regression is fixed.

No action on this PR. Tracking the fix on the #6155 side.

— sent from silent-ferret-137