Skip to content

Enroll native-resolve coverage for fold handler binders - #13585

Closed
gunbai-bot[bot] wants to merge 5 commits into
mainfrom
session/fierce-fox-380
Closed

gunbai-bot[bot] wants to merge 5 commits into
mainfrom
session/fierce-fox-380

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Oct 8, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Re-derived RFM fold_cons_handler_binder_unbound_on_the_native_resolver: on current main the native ingest resolver already binds a fold handler as an ordinary Arrow (fold_recurrence_encoding step + resolve_arrow_node LexicalFrame). Historical RED remains the 2026-10-02 vfb_specimen native-lane prepare refusal at candidate.path.
  • Enrolled the discriminating inhabitance on that route (native_test_context_from_ingest / native_census_module_resolution): a minimal fold(..., fn(acc, candidate) { candidate.path }) module resolves; the same lambda as a call argument still resolves; an undeclared name in a fold handler is the sole resolve_reason_unbound_symbol at its atom.
  • Flipped the callable-binder slice row to assert the production encoding (Loop positional is the step Arrow). Deleted a stale resolve comment that still claimed the step Arrow was never constructed. RFM rung recorded as mechanically preventable.

Test plan

  • gunbc run --entry src/v2/test/claim/resolve/fold_handler_binder_resolve_test.dag --function a_fold_handler_item_binder_resolves --claim-run → PASS
  • same entry a_non_fold_lambda_argument_still_resolves → PASS
  • same entry an_undeclared_name_in_a_fold_handler_is_the_sole_refusal_at_its_atom → PASS
  • cbs_the_fold_encoding_step_admits_handler_binders_holds → PASS
  • Bounded --entry only (subject is three ingest strings). Do not merge.

Made with Cursor

Brian Searls and others added 3 commits October 8, 2026 11:54
The native ingest route already binds a fold step as an ordinary Arrow; lock that with a dotted-path specimen, lambda control, and undeclared-name red, and record the RFM at mechanically preventable.

Co-authored-by: Cursor <cursoragent@cursor.com>
…ng Arrow frame.

Bisect the RFM to resolve_projection_base treating only ParameterFrame as a projection base; reconcile #13423's native-CLI fold refusals with unbound kernel names on an incomplete copy. Unroll the witness walk so the claim module is not itself a fold handler.

Co-authored-by: Cursor <cursoragent@cursor.com>
Three test fns each calling fhb_outcomes re-ran the same prepare fold; the floor discovers one test that asserts the three conjuncts from a single ingest.

Co-authored-by: Cursor <cursoragent@cursor.com>
@gunbai-bot

gunbai-bot Bot commented Oct 8, 2026

Copy link
Copy Markdown
Contributor Author

review 77993: collapsed the three test fns that each called fhb_outcomes() into fold_handler_binders_resolve_on_native_ingest (one ingest, three conjuncts). The named helpers remain for a local --function.

— sent from fierce-fox-380

@gunbai-bot

gunbai-bot Bot commented Oct 8, 2026

Copy link
Copy Markdown
Contributor Author

review 78002: same cost tell as 77993. Head 1d37d396f1 already pays native_test_context_from_ingest once in fold_handler_binders_resolve_on_native_ingest; the three named helpers are ordinary fns for a local --function, not enrolled test fns.

— sent from fierce-fox-380

A single new witness paid the whole ingest (~1.1M eval steps) against the
enrolment margin; three planned claims over the same nullary producer let the
floor net the fill.

Co-authored-by: Cursor <cursoragent@cursor.com>

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

REQUEST_CHANGES at exact head ecf7d49db3994d1696e6213f88798e56d20829d6. One P2 in the committed historical/bisect account. Keep the current route controls and their enrollment; I found no reason to undo that useful coverage.

P2 — the claimed ParameterFrame-only/Absent parent is contradicted by the pinned parent source

The RFM says resolve_projection_base minted bases only for ParameterFrame, that LexicalFrame answered Absent, and that #13028 (9446711d34) closed this resolve refusal. I fetched the commit's actual parent, f7303bb0781046fa17c272040c15de87ad42a92d, and the resolver at that parent.

The parent has BOTH:

  1. a ParameterFrame arm calling resolve_frame_bound_reference; and
  2. BoundInFrame { canonical: canonical, kind: _ } => optional_present(value: Accepted { value: canonical_atom(...), diagnostics: None }).

Thus a successfully found LexicalFrame did not return Absent there. #13028 replaces that accepted canonical-atom base with ResolvedAtom from the shared frame-reference producer, including lexical entries. Its own comment describes the downstream ReceiverTypeUnderived/inference consequence of the old bare atom. That is a real repair, but it is not the historical resolve-level mechanism the new RFM states.

A reported current-head mutant restricting projection-base production to ParameterFrame is useful fault injection. It is not, by itself, a historical revert of the parent above, because that parent also accepted non-parameter frames through its canonical-atom arm. The row itself admits that the old tree was not successfully replayed with today's seed. Do not label that combination an executed bisect proving that #13028 closed the October 2 NativeTestStagePrepare refusal.

Correct the durable account to what is established: the historical refusal was observed; current minimal fold/lambda native-resolve subjects pass; the current control detects the reported ParameterFrame-restriction mutant; #13028 changed projection representation and lexical evidence, while the exact attribution of the historical prepare refusal is unestablished unless separately demonstrated. No old-corpus replay or broad bisect is required merely to land the corrected account.

The same correction applies to NOT THIS CLASS AT ... #13423: that receipt reports the named missing declarations (concat, map_get, Map) AND separately reports fold-projection refusals on small probes. Those are not established to be the same diagnostics. A copied import-only set is insufficient evidence of a canonical production closure, but #13028's date and today's tiny passing fixture do not prove that every earlier fold-projection refusal was caused by the incomplete copy. Restrict the reattribution to the named missing-declaration observations; leave the probe-specific causal claim unestablished rather than replacing one unsupported attribution with another.

Also distinguish historical 'rung found' from current rung: the October 2 receipt was loud mitigation, not a retrospectively discovered rung 2. The new tested phase boundary can now be described separately.

Current controls and rung scope

The three new tests really call native_test_context_from_ingest -> native_census_module_resolution; a refused context, missing module, file refusal or unexpected outcome returns false. The undeclared-name control requires resolve_reason_unbound_symbol, the exact fhb_undeclared_item atom, and no remaining diagnostic chains. It is not an any-error acceptance. The fold and ordinary-lambda positives require NativeCensusModuleResolved through that producer. This is resolve-phase coverage, not successful infer/eval or proof that all three historical vfb_specimen identities now pass the emitted native driver's prepare.

The callable-binder slice supplies a Loop whose positional step is an Arrow and asserts both expected handler binders; it is a boundary test, with the ingest tests providing the real-route pairing. Its Absent arm is false. The outdated resolve comment is deleted without changing production resolver logic in this PR.

Current rung 2 is defensible only at that declared ingest/resolve subject, supported by the positive/refusal controls and the reported executed fault-injection RED. The fault-injection transcript and patch were not independently retrieved or rerun by me. Do not inflate it into a historical bisect or a whole-native-driver repair certificate. The ceiling must remain a future construction guarantee; the all-frame match already present is not by itself proof that returning Absent for a bound frame has become unwritable.

Execution verified at this head

Workflow 37786982162 is successful: five jobs passed and rust-unit-tests was skipped. I downloaded artifact 11558438223 (required-floor-claim-cost), verified ZIP SHA256 e37d009ffff1e9ebb41b88fdb2749e6552ad6f413eb7ae20bb91690006dda363, and read its receipt. All four affected controls executed with verdict reached and passed:

  • a_fold_handler_item_binder_resolves
  • a_non_fold_lambda_argument_still_resolves
  • an_undeclared_name_in_a_fold_handler_is_the_sole_refusal_at_its_atom
  • cbs_the_fold_encoding_step_admits_handler_binders_holds

The three ingest claims share their nullary production fill; their small net claim costs are not evidence that ingest was bypassed. I did not locally run gunbc, a historical seed, or the reported one-arm mutant. No new lane, full historic replay, or production resolver rewrite requested. Nothing merged or enqueued.

…tigation.

Separate the 2026-10-02 prepare refusal, today's ingest subjects, current-head
fault injection, and what #13028 actually changed. Narrow the #13423
re-attribution to concat, map_get, and Map.

Co-authored-by: Cursor <cursoragent@cursor.com>
@gunbai-bot

gunbai-bot Bot commented Oct 8, 2026

Copy link
Copy Markdown
Contributor Author

review 78094: APPROVE on the accounting rewrite; the truncated 'fault injection is described as a reg…' sentence is already the committed (c) receipt at ebb86170db (regression discriminator, not a historical revert). Nothing further to change.

The GitHub REQUEST_CHANGES on ecf7d49db3 is the same P2: current row at ebb86170db separates (a) the 2026-10-02 prepare observation with unestablished cause, (b) today's ingest subjects, (c) current-head ParameterFrame-only injection, (d) #13028 as resolve_frame_bound_reference + ResolvedAtom.lexical. #13423 re-attribution is only concat / map_get / Map; fold-projection probes are not withdrawn. Rung found stays mitigatable; ingest/resolve is mechanically preventable.

— sent from fierce-fox-380

@briansrls briansrls left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

APPROVE at exact head ebb86170dbf1517d72bf39a01850d035bfc14fe6, re-reviewing REQUEST_CHANGES 5459510139. The accounting P2 is resolved. No new blocking finding.

Historical attribution and rung scope

The committed RFM now separates four different kinds of evidence rather than combining them into an alleged historical bisect:

  • The 2026-10-02 emitted-native prepare refusal and interpreted-floor success remain recorded. Its exact cause is explicitly UNESTABLISHED; the row no longer claims the parent returned Absent for a found LexicalFrame.
  • Today's three minimal ingest subjects have their own resolve-phase results.
  • The reported ParameterFrame-only injection is expressly a current-head fault injection, not a historical revert or a successful reading of the old tree.
  • #13028 is credited with routing frame-bound projection bases through resolve_frame_bound_reference and carrying ResolvedAtom.lexical. The parent's already-accepted canonical-atom base is acknowledged. That matches the distinction identified in my preceding review and does not claim #13028 proved the historical prepare refusal fixed.

The #13423 reattribution is limited to the named concat/map_get/Map missing-declaration observations. Its separately reported fold-projection refusals are retained rather than explained away by the copied-closure account. I do not read retaining that historical attribution as newly proving its cause; no historical replay or class-wide discharge is credited.

Historical rung found is now mitigatable. Current mechanically preventable standing is explicitly at native_test_context_from_ingest -> native_census_module_resolution, with the retained boundary controls and reported executed fault injection. It is not a certificate for infer/eval or for all three historical vfb_specimen identities passing the emitted driver's prepare. The ceiling remains a future construction guarantee: the row explicitly states that the bad source remains writable, and passing inhabitance alone does not raise the rung.

Delta checked

The compare from previously reviewed ecf7d49db3994d1696e6213f88798e56d20829d6 contains exactly one commit and two files: eight receipt-string replacements in the RFM and a comment-only correction in fold_handler_binder_resolve_test.dag. No production code, test body, assertion, evidence identity or enrollment changes. The evidence list still names all four previously reviewed controls. No new lane or repeated historical experiment is needed for this correction.

Exact-head execution

Workflow 37810712732 succeeded: seed, generated, floor, emit-build and witnesses passed; rust-unit-tests was skipped. The generated job passed all-target lint and the one-emission mirror check.

I downloaded the exact-head required-floor-claim-cost artifact 11568366507, verified ZIP SHA256 101d7f17c8ad9239ec98babd853e672da14d81077708ba8f25f85e6f75d19962, and parsed its TSV. All four affected claims are pass with reached verdicts and observed costs:

  • a_fold_handler_item_binder_resolves
  • a_non_fold_lambda_argument_still_resolves
  • an_undeclared_name_in_a_fold_handler_is_the_sole_refusal_at_its_atom
  • cbs_the_fold_encoding_step_admits_handler_binders_holds

That independently verifies current passing execution. The ParameterFrame-only injection remains author-run evidence; I did not retrieve its raw patch/transcript or replay it. I did not run a local compiler or historical seed. Local execution was limited to artifact hashing and parsing.

No further committed change requested. This approves the corrected account and retained current-boundary coverage, not a newly established historical root cause. Land only through the normal required composed-revision checks; no merge or enqueue performed.

@gunbai-bot
gunbai-bot Bot added this pull request to the merge queue Oct 8, 2026
@gunbai-bot
gunbai-bot Bot removed this pull request from the merge queue due to a manual request Oct 9, 2026
@gunbai-bot

gunbai-bot Bot commented Oct 10, 2026

Copy link
Copy Markdown
Contributor Author

Superseded by #13641 (v1 closeout): this head is an ancestor of integration/v1-closeout.

@gunbai-bot gunbai-bot Bot closed this Oct 10, 2026
@gunbai-bot gunbai-bot Bot mentioned this pull request Oct 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant