# Rename planner small-stack investigation

2026-09-24, Windows gnullvm development test profile, one Cargo job. These are
observed diagnostic results; the proposed test repair still requires execution.

- Source `9388fcf2f0b82daffec93308f42949a612b07330` compiled. Its focused run
  passed four named tests, then aborted in the 128 KiB deep/wide stress test
  with `STATUS_STACK_OVERFLOW` (3221225725). It did not complete the test suite.
- The exact original artifact (42,074,624 bytes, SHA256
  `bd927d4653a8915ee72d5df22096d29edb1853c12d929e20056647b05e565956`)
  subsequently passed all other 16 rename tests. That direct run explicitly
  skipped the known aborting case and checked the artifact before/after. It
  does not establish acceptance of the complete 17-test suite.
- Diagnostic source `9e8e77e1d81c0e3116fa5777a37792a635bb4317` added flushed
  phase markers only. The deep case completed admission/indexing, original
  model cloning, successful planning and plan destruction, then desired-model
  cloning. It aborted after entering the later collision-rejection operation.
- Diagnostic source `8159a17dd7e8083ca6b572e9b63f3a300f0d67fe` additionally
  bracketed the shared rejection helper. Its final emitted marker is
  `rename rejected helper: entered; before authored`. There is no
  `after authored; before plan` marker. The overflow therefore occurred while
  rebuilding the source through that nested helper, before the colliding plan
  invocation. These markers do not identify a particular internal parser
  instruction, exact compiler frame size, or general application-stack defect.

The proposed narrow repair constructs each fresh source directly in the small
worker and invokes/matches the planner directly. It preserves the 128 KiB stack,
128-site deep and 129-site wide fixtures, full admission on that worker,
successful planning/destruction, post-equality collision refusal/destruction and
non-name refusal/destruction. It does not enlarge the stack, reduce expression
sizes, move the tested pipeline to another thread or omit failed cases.

Production rename code remained SHA256
`3ce74331c962abfbf63ca7f72b286405b1ca8b266335d77c71103c900cb6e9dd`
through all three source snapshots. Original and diagnostic logs/receipts,
committed-input manifests and exact launchers remain in
`.local/analysis-mixed-rename-plan-gates-20260924` until portable publication.

## Further observed results and scoped evaluator decision

The direct-call repair `70c20c39de4d87633a3275fda3f2bc54b20e50b7` and compact
case-loop `f1c095654a5f2a8e1592415b1392644b27169e00` both still aborted in the
same test. Neither is accepted as a repair. Read-only prologue inspection found
worker stack allocations of 10,872 and 5,976 bytes respectively; reducing that
one frame did not establish full-pipeline success. These are static observations,
not complete call-stack size measurements.

Three LLDB runs used the exact f1 artifact (42,076,160 bytes, SHA256
`b804768eccb350033fcfd01516d0c3253e43525718f42de7c75cda9a3d91c6fe`).
The first stopped on overflow without executing a backtrace command. The second
completed the exact single test successfully under the debugger; the third
overflowed and captured all threads before explicitly killing its owned debuggee.
Debugger process exit zero is not a passing test gate. The differing outcomes
show that this stack boundary is environment-sensitive; no cause for that
variation is claimed.

The third backtrace places the fault in Windows heap allocation reached through
BigInt parsing, `Exact::parse_decimal`, `Budget::exact`, `Cursor::exact_literal`,
`syntax::binding`, `declarations::parse`, `State::parse_typed`, `Parser::unit`,
`mixed::parse_with_profile`, the original admission helper, and this test's
`authored` setup. The rename planner is not on that active stack. Native system
symbol labels lack full OS debug symbols and should not be treated as precise
source attribution; the executable's Rust frames establish the setup path.

Independent evaluator review distinguishes the accepted planner-specific
requirement (small-stack comparison, success/drop and late refusal) from a
stronger full-pipeline stack claim. Prepare each fresh owner and externally
owned desired model on the normal test thread, then move the complete owner
into a scoped 128 KiB worker. That worker must invoke the planner, check exact
outcomes and destroy its plan/failure/consumed source. Desired remains an
external immutable borrow. All six deep/wide and success/collision/non-name
cases remain required, with unchanged profiles and expression counts.

This scoped evaluator remains pending runtime validation. It will not fix or
validate the previously failing combined parser/setup path on 128 KiB. Preserve
that limitation and the failed attempts; existing standalone admission/index
small-stack tests are separate evidence only.

## Final scoped result

Source `18073a6f2eabce83fc83997f094e331eec835a16` implements that scoped test.
All 17 focused tests pass, including all six 128 KiB planner cases. The full
246-name run completes with 230 passed and the same 16 inherited failures.
Existing standalone small-stack cases keep their prior outcomes. The new test
artifact is 42,081,792 bytes, SHA256
`2c8bd7b9a6adfda3f74b74bae00453b1b1348cbed47f04c8e8c1de9152899416`.
Strict core all-target Clippy passes; formatting retains the identical prior
failure bytes. These results establish the scoped planner behavior, not repair
of the separately recorded full-pipeline 128 KiB setup failure.