ARCADIA-Studio/harness/experiments/analysis-mixed-rename-plan-20260924/RENAME-PLAN-STACK-DIAGNOSIS.md

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.