Continue IR work

[rogeralsing]

Context

Recent IR-only refactor work removed the remaining AST-eval seams from ExecutionPlanRunner and prebuilt class callable plan seeds in ClassDefinitionProgramCache, but one callable-side seam is still open. Class-created sync methods/constructors closed over a dynamic scope (with in the closure chain) can still be unsafe because cached successful IR seeds assume slot/flat-slot resolution that may bypass runtime with lookup semantics.

This issue is the next contained follow-up from #364 comment 4188869884: finish the remaining class-created sync callable dynamic-scope seam without reintroducing silent AST fallback.

Success Criteria

• Add a failing regression test first that covers a class-created sync callable defined inside a with-captured closure and demonstrates the current unsafe or AST-dependent path.
• Class-created sync methods/constructors with cached successful plan seeds no longer bypass with resolution through slot/flat-slot assumptions.
• Runtime uses one explicit safe behavior for this seam: either a dynamic-scope-safe IR execution mode for these callables, or a truthful IR-plan rejection path that does not silently fall back to AST execution.
• Existing AST-free assertion coverage for non-dynamic IR-owned class callable paths remains green.
• Build and focused regression packs for class/runtime/IR execution pass after the change.

Rules

• Add RED coverage before implementation.
• Scope this issue to the remaining class-created sync callable dynamic-scope seam from Epic: Design: IR-only execution  #364; do not bundle IL backend or broader epic work.
• Do not add silent fallback paths.
• Preserve JavaScript with / dynamic name-resolution semantics exactly; cached slot layouts must not bypass dynamic bindings.
• Keep cache construction, callable materialization, and runtime execution concerns separated.

NFRs

• No new runtime AST re-entry on IR-owned non-dynamic paths.
• Execution-plan diagnostics must stay truthful about cached seed success/failure versus runtime execution path.
• Avoid measurable allocation regression on the existing profiling loop for this refactor area.

Quality Gates

• Tests pass
• No regressions

---

Faktoria Attribution: agent=intake | trigger=new issue intake

[rogeralsing]

Intake: Approved (p2, size:L)

Approved because the linked #364 comment narrows this to one actionable IR concern: class-created sync callables with cached plan seeds still have a remaining dynamic-scope (with-captured closure) seam. Code search shows the affected runtime/cache paths are real, prior bytecode migration issues are already closed, and no open issue covers this exact remaining seam. The current body is too vague on its own, so it should enter the pipeline with a rewritten, testable scope.

---

Faktoria Attribution: agent=intake | trigger=issue approved

[rogeralsing]

Investigation

Blast Radius

• src/Asynkron.JsEngine/Execution/ClassDefinitionProgramCache.cs prebuilds LoweredClassCallable plan seeds without any closure-chain context, so class-created sync callables can be cached as IR-successful even when later invoked from a with-captured closure.
• src/Asynkron.JsEngine/Ast/TypedAstEvaluator.SyncFunctionInvoker.cs is the runtime decision point. It sets _allowIdentifierCache = AllowsIdentifierCaching(_function) && !closure.HasWithObjectInChain(), uses the cached class seed only when that flag stays true, and otherwise drops to the dynamic-scope AST executor for sync methods/constructors.
• src/Asynkron.JsEngine/Ast/TypedAstEvaluator.ExecutionPlanRunner.Core.cs mirrors the same closure-chain guard for IR runner construction, so any dynamic-scope-safe IR option will have to line up with this entry behavior.
• src/Asynkron.JsEngine/JsEnvironment.cs owns HasWithObjectInChain(), which is the current runtime signal that with lookup semantics must stay live.
• src/Asynkron.JsEngine/Execution/ExecutionPlanBuilder.cs and src/Asynkron.JsEngine/Execution/ExecutionPlanBuildResult.cs own what counts as truthful plan-seed success/failure if we decide these seeded plans must be rejected for closure-dynamic sync callables.
• Tests likely affected: tests/Asynkron.JsEngine.Tests/ExpressionProgramLoweringTests.cs, tests/Asynkron.JsEngine.Tests/AstFreeExecutionAssertionTests.cs, plus one class-facing regression file such as tests/Asynkron.JsEngine.Tests/ClassStatementTests.cs or tests/Asynkron.JsEngine.Tests/ClassElementEvalTests.cs.

Dependencies

• No open PRs are currently touching this area: gh pr list --state open --json number,title,headRefName,url returned [].
• Related tracking only: Epic: Design: IR-only execution  #364 is the umbrella epic and its latest comments already narrow the next seam to closure-dynamic class-created sync callables.
• No separate open issue matching this exact seam showed up in gh issue list searches beyond Continue IR work #723 and Epic: Design: IR-only execution  #364.
• ADR note: python3 faktoria/adr.py context could not run because this repo currently has no faktoria/adr.py, and there are still no files under docs/adrs/.

Approach

Add a RED regression first for a class-created sync method or constructor defined inside a closure whose environment chain includes with, and make it prove the current mismatch between cached successful class-callable seeds and the runtime dynamic-scope path. Then fix the seam in the callable/runtime boundary, not by adding fallback: either introduce a closure-dynamic-safe IR mode that avoids slot/flat-slot assumptions, or make runtime reject those cached successful seeds truthfully when HasWithObjectInChain() is true so the execution path and diagnostics stay honest.

Risks

• Using the cached successful seed as-is can bypass with name resolution through stamped slot/flat-slot assumptions and return the wrong binding.
• Pushing closure-sensitive policy into ClassDefinitionProgramCache would mix cache construction with invocation environment concerns; that boundary should stay in invoker/runtime code unless a separate dynamic-safe seed shape is introduced.
• A partial fix could keep PlanSeed.Succeeded == true while runtime always refuses to use it, which would leave diagnostics misleading.
• Constructors and methods both use SyncFunctionInvoker, so coverage should hit both shapes if their initialization paths differ.

Acceptance Criteria (Refined)

• Add a failing regression test first for a class-created sync callable inside a with-captured closure; include constructor coverage too if it takes a different path than methods.
• Cached successful class-callable seeds are not used when the closure chain contains with unless the runtime path preserves JavaScript with lookup semantics exactly.
• Runtime uses one explicit, truthful behavior for this seam: dynamic-scope-safe IR execution, or explicit IR-plan rejection. No silent AST fallback for IR-owned class-created sync callables.
• Existing AST-free class/runtime coverage stays green, especially ExpressionProgramLoweringTests, AstFreeExecutionAssertionTests, and the focused class packs.
• Build plus focused class/runtime/IR regression packs pass after the change.

Proof

• gh issue view 364 --comments
• gh pr list --state open --json number,title,headRefName,url
• gh issue list --state open --json number,title,labels,url
• rg -n "HasWithObjectInChain|_allowIdentifierCache|FunctionExecutionPlanSeed|LoweredClassCallable|PlanSeed" src/Asynkron.JsEngine tests/Asynkron.JsEngine.Tests
• rg -n "AssertNoAstEvaluation_Enabled_ClassMethodDebuggerStatement_ThrowsPlanFailureInsteadOfAstFallback|AssertNoAstEvaluation_Enabled_ThrowsOnWithStatementExecution" tests/Asynkron.JsEngine.Tests/AstFreeExecutionAssertionTests.cs

[rogeralsing]

Build update for #723

What I changed

• Added RED coverage for class-created sync methods and constructors defined inside a with-captured closure.
• Added a debug assertion regression proving the old path re-entered AST for this seam.
• Switched class callable materialization to turn cached successful sync plan seeds into an explicit runtime rejection when the closure chain contains with, instead of silently dropping into AST execution.

Proof

• dotnet test tests/Asynkron.JsEngine.Tests --filter "FullyQualifiedName~ClassMethodCreatedInsideWithCapturedClosure_RejectsCachedIrSeed|FullyQualifiedName~ClassConstructorCreatedInsideWithCapturedClosure_RejectsCachedIrSeed|FullyQualifiedName~AssertNoAstEvaluation_Enabled_ClassMethodWithCapturedDynamicScope_ThrowsPlanFailureInsteadOfAstFallback" ✅
• dotnet test tests/Asynkron.JsEngine.Tests --filter "FullyQualifiedName~ExpressionProgramLoweringTests|FullyQualifiedName~AstFreeExecutionAssertionTests|FullyQualifiedName~ClassStatementTests" ✅ (220 passed)
• rg -n "EvaluateExpression\\(|ProfileEvaluateExpression\\(" src/Asynkron.JsEngine/Ast/TypedAstEvaluator.ExecutionPlanRunner* ✅ (no matches)

Blocked proof outside this issue’s blast radius

• dotnet test tests/Asynkron.JsEngine.Tests ❌ with existing unrelated failures in async/module coverage:
  • AsyncLoopTests.ForLoop_WithAwaitAndContinue_Works
  • AsyncLoopTests.DoWhileLoop_WithAwaitAndBreak_Works
  • AsyncAwaitTests.AsyncFunction_WithAwaitInExpression
  • AsyncModuleTryAwaitTests.TryCatch_CanEvaluateClassComputedNamesFromAwait
• dotnet build ❌ because tests/Asynkron.JsEngine.Tests.Test262/Generated/Tests262Harness.Test262Test.generated.cs currently fails with CS1503 (cannot convert from '(JsEngine Engine, Test262AgentRuntime AgentRuntime)' to 'JsEngine').

Commit pushed

• 35f59b22 on issue-723

[rogeralsing]

Build verification refresh for #723

What I verified

• Re-ran the focused regression pack for the new with-captured class callable seam and the AST-free/class/runtime proof pack.
• Re-ran the full Asynkron.JsEngine.Tests suite.
• Re-ran dotnet build for the repo.

Proof

• dotnet test tests/Asynkron.JsEngine.Tests --filter "FullyQualifiedName~ClassMethodCreatedInsideWithCapturedClosure_RejectsCachedIrSeed|FullyQualifiedName~ClassConstructorCreatedInsideWithCapturedClosure_RejectsCachedIrSeed|FullyQualifiedName~AssertNoAstEvaluation_Enabled_ClassMethodWithCapturedDynamicScope_ThrowsPlanFailureInsteadOfAstFallback|FullyQualifiedName~ExpressionProgramLoweringTests|FullyQualifiedName~AstFreeExecutionAssertionTests|FullyQualifiedName~ClassStatementTests" ✅ (220 passed)
• rg -n "EvaluateExpression\\(|ProfileEvaluateExpression\\(" src/Asynkron.JsEngine/Ast/TypedAstEvaluator.ExecutionPlanRunner* ✅ (no matches)
• dotnet test tests/Asynkron.JsEngine.Tests ❌ existing unrelated failures remain:
  • AsyncAwaitTests.AsyncFunction_WithAwaitInExpression
  • AsyncLoopTests.ForLoop_WithAwaitAndContinue_Works
  • AsyncLoopTests.DoWhileLoop_WithAwaitAndBreak_Works
  • AsyncModuleTryAwaitTests.TryCatch_CanEvaluateClassComputedNamesFromAwait
• dotnet build ❌ existing unrelated Test262 compile break remains:
  • tests/Asynkron.JsEngine.Tests.Test262/Generated/Tests262Harness.Test262Test.generated.cs(79,25): error CS1503 cannot convert from '(JsEngine Engine, Test262AgentRuntime AgentRuntime)' to 'JsEngine'

Status

• Issue-specific code remains on issue-723 and PR fix: reject with-scoped class IR seeds #726 is open.
• Build-stage verification is still blocked by repo-level failures outside this issue's documented blast radius, so I did not move this forward as complete.