User report of this issue
Rebaseline the Finite Bytecode Retirement Inventory
Context: #3377 asks to complete the entire new bytecode execution layer and retire the IR execution layer. The maintained source of truth is docs/plans/bytecode-burndown-checklist.md, with route/status context in docs/bytecode-progress.md and drift inventories in docs/unified-bytecode-expansion-contract.md. Keep each child bounded to one source-owned lane, and do not claim final retirement until manifest/source-absence gates prove it.
Close Remaining Admission Gaps
Context: These children should admit one semantic family at a time by updating the production eligibility gate, compiler lowering, VM/runtime semantics, route-hit tests, no-route neighbor tests, and checklist/proof manifest rows together.
Retire Fallback Tiers in Bounded Steps
Context: Accepted production unified bytecode must remain all-or-nothing. Do not move semantics into runner-time fallback. Delete or hard-quarantine fallback entry points only after the corresponding non-dynamic admission surface is proven.
Final Gates and Documentation
Context: Final completion is not a route-width claim; it requires machine-checkable absence of the old execution layers for non-dynamic code.
Investigation
Delivery strictness: full - This task edits machine-checked bytecode governance surfaces and may drive child planning for runtime route/fallback retirement; the work depends on source-presence/source-absence gates, cross-module VM/compiler/runner behavior, and proof-manifest consistency.
Blast Radius
- docs/plans/bytecode-burndown-checklist.md - maintained finite checklist, current open-row inventory, row counts, and source-owned lane boundaries.
- docs/plans/bytecode-proof-manifest.json - executable proof index for admitted, open, hard-quarantined, and retired bytecode rows.
- docs/bytecode-progress.md - human-readable current route/status map and final-proof evidence summary.
- docs/unified-bytecode-expansion-contract.md - drift inventory for decline codes, proof commands, and expansion-contract rows.
- tests/Asynkron.JsEngine.Tests/BytecodeProofManifestTests.cs - manifest/checklist consistency, source-presence/source-absence, and classified fallback gates.
- tests/Asynkron.JsEngine.Tests/ExpressionProgramCoverageMapTests.cs - expansion-contract and expression coverage drift gate.
- tests/Asynkron.JsEngine.Tests/UnifiedBytecodeProductionEligibilityTests.cs - route/no-route proof for production eligibility boundaries.
- tests/Asynkron.JsEngine.Tests/UnifiedBytecodeProductionInvocationTests.cs - production invocation, classified fallback, and source gate coverage.
- src/Asynkron.JsEngine/Execution/UnifiedBytecode/UnifiedBytecodeCompiler.cs - A51 compiler diagnostic owners and emitted opcode coverage.
- src/Asynkron.JsEngine/Execution/UnifiedBytecode/UnifiedBytecodeProductionEligibility.cs - A1/A2/A51/B24h/B36/E5 eligibility and decline classification.
- src/Asynkron.JsEngine/Execution/UnifiedBytecode/UnifiedBytecodeVirtualMachine.cs - VM ownership for admitted rows and fallback-free execution constraints.
- src/Asynkron.JsEngine/Ast/TypedAstEvaluator.UnifiedBytecodeResumableActivation.cs - A2 resumable direct-eval and dynamic activation residue boundary.
- src/Asynkron.JsEngine/Ast/TypedAstEvaluator.IrSyncGeneratorInvoker.cs - E5d sync-generator creation-time IR route-selection anchor.
- src/Asynkron.JsEngine/Ast/TypedAstEvaluator.AsyncFunctionInvoker.cs - E5d async-function declined-body runner residue anchor.
- src/Asynkron.JsEngine/Ast/Legacy/StatementNodeExtensions.cs - E5c classified script and terminal dynamic script fallback anchors.
- src/Asynkron.JsEngine/Ast/ClassDefinitionExtensions.cs - B24h/B36 static-block production route and classified static-block residue.
Dependencies
User Stories
Story 1: As a bytecode runtime maintainer, I want the finite retirement inventory rebaselined against current source and proof gates, so that future runtime work starts from real open blockers instead of stale checklist text.
Story 2: As a Faktorial build agent, I want the remaining open rows converted into owned child slices with exact source files, proof anchors, and dynamic-residue boundaries, so that implementation work can be scheduled without parking ordinary fallback work in A1/A2 or terminal residue.
Story 3: As a reviewer, I want every retirement claim backed by manifest and source-absence evidence, so that final IR/expression fallback retirement is machine-checkable rather than narrative-only.
Approach
- Start the build stage by capturing a pre-edit baseline: current HEAD
85de9bb6cd6ba1cece67906f71c93bf374a24942, checklist totals 137 / 161, A+B+C+D 127 / 146, Phase E 5 / 10, manifest item count 32, non-done manifest items A1 A2 A51b A51a2 A51c A51j A51h A51h1 A51h2 A51k A51f3 A51f5 B24h B36 E5b E5c E5d E5e, and the focused runner/E4 source scans before edits.
- Treat
docs/plans/bytecode-burndown-checklist.md as the human source of truth, docs/plans/bytecode-proof-manifest.json plus BytecodeProofManifestTests as the executable source of truth, and docs/unified-bytecode-expansion-contract.md as the decline-template drift inventory.
- Reconcile the four named docs against current source. Update docs only where stale; if a manifest row moves, update
BytecodeProofManifestTests in the same change so the row is executable.
- Convert every remaining open checklist lane into independently shippable child slices. Preserve these current groups: A1/A2 dynamic activation residue, A51 compiler leaves including A51g/A51i lanes that currently lack manifest closure rows, B24h class-expression/static-block environment bridge, B36 resumable declaration/class-definition residue, and E5b-E5e runner-retirement/exclusion rows.
- Do not reopen E4 unless current production source contradicts the manifest. Current evidence shows the E4 dynamic executor and old standalone/lowered expression bridges are absence-ratcheted and production-source scans return no matches; runner-internal expression execution belongs to E5.
- Keep runtime changes blocked behind child conversion unless the build finds a tiny proof-manifest/doc drift that is required to make the child plan accurate.
Risks
- A documentation-only rebaseline can still break the build because
BytecodeProofManifestTests parses and enforces checklist/manifest/source-gate consistency.
- Flattening A1/A2, D1-D4, B24h/B36, E4, or E5 rows would hide the owner that future runtime work must actually retire.
- Broad source searches can overcount test/docs references; production-source absence must be scoped to the source paths used by the manifest tests.
- Route-hit/profile numbers in the docs are dated evidence. Build must capture current numbers before claiming a new final-proof baseline.
- If build discovers the durable proof declaration is wrong, repair the durable task/proof contract first; do not weaken a proof to pass an unrelated edit.
Additional quality gates
- Baseline evidence gate - Before editing files, record current HEAD, checklist totals, manifest non-done ids, runner AST-seam scan result, E4 tombstone scan result, and source owner scan notes in
## Build Update or the build handoff.
- Source-of-truth gate - Source Context and Faktorial API output remain authoritative for issue state; use source/docs only to verify current repo drift, not external GitHub reads.
- No parking gate - A1/A2 and terminal D/E residue must not absorb ordinary A51, B24h, B36, E4, or E5 work.
- Manifest closure gate - No row may move to done unless the manifest proof row proves admission, hard quarantine, fallback retirement, or source absence as applicable; non-done rows must retain at least one open or hard-quarantined proof.
- E4/E5 separation gate - E4 deleted bridge names remain source-absence ratchets; runner-internal expression execution and remaining
ExecutionPlanRunner construction stay in E5.
- Change-risk routing - requested behavior: finite bytecode retirement rebaseline plus child conversion; risk lane: full; lane evidence: proof manifest, source-presence/source-absence tests, current source scans, route-hit probes, and allocation profile; required proof or human judgment: build must run the proof obligations and preserve owner classification; buyer consequence if missing: unsupported JavaScript can be falsely marked bytecode-owned or required fallback can be hidden; stop/downgrade trigger: if current source contradicts the manifest or proof declaration, stop runtime work and repair the durable proof contract before implementation.
Proof obligations
- proof-manifest | required | runner: repo-command | command: rtk dotnet test tests/Asynkron.JsEngine.Tests --filter "FullyQualifiedName~BytecodeProofManifestTests" | terminal: passes
- expansion-contract | required | runner: repo-command | command: rtk dotnet test tests/Asynkron.JsEngine.Tests --filter "FullyQualifiedName~ExpressionProgramCoverageMapTests" | terminal: passes
- production-eligibility | required | runner: repo-command | command: rtk dotnet test tests/Asynkron.JsEngine.Tests --filter "FullyQualifiedName~UnifiedBytecodeProductionEligibilityTests" | terminal: passes
- production-invocation | required | runner: repo-command | command: rtk dotnet test tests/Asynkron.JsEngine.Tests --filter "FullyQualifiedName~UnifiedBytecodeProductionInvocationTests" | terminal: passes
- prototype-vm | required | runner: repo-command | command: rtk dotnet test tests/Asynkron.JsEngine.Tests --filter "FullyQualifiedName~UnifiedBytecodePrototypeTests" | terminal: passes
- runner-ast-seam-scan | required | runner: repo-command | command: rtk bash -lc '! rg "EvaluateLegacyAstExpression\(|EvaluateLegacyAstExpressionSlow\(|ProfileEvaluateExpression\(" src/Asynkron.JsEngine/Ast/TypedAstEvaluator.ExecutionPlanRunner*' | terminal: passes
- e4-tombstone-scan | required | runner: repo-command | command: rtk bash -lc '! rg -n "EvaluateStandaloneExpressionProgram|EvaluateLoweredExpressionProgram|EvaluateDynamicExpressionProgram|UnifiedBytecodeExpressionProgramExecutor\.ExecuteDynamic|ExecutionPlanRunner\.ApplyStandaloneBindingTargetProgram|ProfileEvaluateExpressionProgramLoop|ProfileEvaluateLoweredExpressionProgramLoop" src/Asynkron.JsEngine tools/ProfileRunner -g "*.cs"' | terminal: passes
- route-hit-probes | required | runner: repo-command | command: rtk bash -lc './tools/profile forloop --route-hits && ./tools/profile propertyaccess --route-hits && ./tools/profile functioncalls-lite --route-hits && ./tools/profile activation-noargs-lite --route-hits && ./tools/profile forofiteration --route-hits' | terminal: passes
- allocation-stability | required | runner: repo-command | command: rtk ./tools/profile forloop --memory | terminal: passes
Recommended Labels
- bytecode
- unified-bytecode
- ir
- runtime
- compiler
- documentation
- planning
- size:XL
- priority: high
Acceptance Criteria (Refined)
AC-1: The build update captures the pre-edit baseline with current HEAD, checklist totals, manifest non-done ids, runner AST-seam scan result, E4 tombstone scan result, and source owner scan notes.
AC-2: docs/plans/bytecode-burndown-checklist.md, docs/plans/bytecode-proof-manifest.json, docs/bytecode-progress.md, and docs/unified-bytecode-expansion-contract.md agree on current open rows, counts, owner files, proof anchors, and dynamic-residue boundaries.
AC-3: Remaining open rows are converted into owned child slices with exact source files, proof anchors, and explicit boundaries for A1/A2, A51 compiler leaves, B24h, B36, E5b, E5c, E5d, and E5e; A51g/A51i lanes must not be dropped just because they lack manifest closure rows today.
AC-4: E4 stays closed as source-absence/tombstone inventory unless current production source contains a live E4 bridge; any such contradiction repairs the manifest/checklist before runtime work proceeds.
AC-5: No child slice or doc wording treats terminal dynamic residue as a parking bucket for ordinary compiler, class-definition, expression-program, or runner-retirement work.
AC-6: BytecodeProofManifestTests continues to prove checklist/manifest status consistency, non-vacuous source discovery, exact source-presence/source-absence rows, and classified E5 fallback ownership.
AC-7: docs/unified-bytecode-expansion-contract.md keeps current decline-template inventories aligned with compiler and eligibility source; stale examples are removed or reclassified with proof.
AC-8: The proof obligations above pass before review or verification is requested; any failed proof is reported with the exact command, failure, and next repair owner.
AC-9: Final build notes record both pre-edit baseline and post-change final signal for the selected stable evidence metric, even if the build turns out to be evidence-only.
AC-10: The build handoff records created child task ids, their lineage back to gh3377, and any rows intentionally left as terminal residue or human-governed future work.
User report of this issue
Rebaseline the Finite Bytecode Retirement Inventory
Context: #3377 asks to complete the entire new bytecode execution layer and retire the IR execution layer. The maintained source of truth is
docs/plans/bytecode-burndown-checklist.md, with route/status context indocs/bytecode-progress.mdand drift inventories indocs/unified-bytecode-expansion-contract.md. Keep each child bounded to one source-owned lane, and do not claim final retirement until manifest/source-absence gates prove it.Close Remaining Admission Gaps
Context: These children should admit one semantic family at a time by updating the production eligibility gate, compiler lowering, VM/runtime semantics, route-hit tests, no-route neighbor tests, and checklist/proof manifest rows together.
UnsupportedPlanShapebuckets only when selector, compiler, VM, and proof coverage are all present.Retire Fallback Tiers in Bounded Steps
Context: Accepted production unified bytecode must remain all-or-nothing. Do not move semantics into runner-time fallback. Delete or hard-quarantine fallback entry points only after the corresponding non-dynamic admission surface is proven.
ExpressionProgramexecution surfaces that are not terminal dynamic residue, replacing them with standalone unified bytecode or deleting dead bridges.ExecutionPlanRunnerfallback entry points after all non-dynamic declines are gone or explicitly quarantined as dynamic residue.with, eval-injected bindings, andFunction(...)produced bodies as the only documented terminal interpreter residue.Final Gates and Documentation
Context: Final completion is not a route-width claim; it requires machine-checkable absence of the old execution layers for non-dynamic code.
ExecutionPlanRunnerentry points cannot silently return.docs/bytecode-progress.md,docs/plans/bytecode-burndown-checklist.md,docs/plans/bytecode-proof-manifest.json, anddocs/unified-bytecode-expansion-contract.mdto state the final retired-state evidence.Investigation
Delivery strictness: full - This task edits machine-checked bytecode governance surfaces and may drive child planning for runtime route/fallback retirement; the work depends on source-presence/source-absence gates, cross-module VM/compiler/runner behavior, and proof-manifest consistency.
Blast Radius
Dependencies
User Stories
Story 1: As a bytecode runtime maintainer, I want the finite retirement inventory rebaselined against current source and proof gates, so that future runtime work starts from real open blockers instead of stale checklist text.
Story 2: As a Faktorial build agent, I want the remaining open rows converted into owned child slices with exact source files, proof anchors, and dynamic-residue boundaries, so that implementation work can be scheduled without parking ordinary fallback work in A1/A2 or terminal residue.
Story 3: As a reviewer, I want every retirement claim backed by manifest and source-absence evidence, so that final IR/expression fallback retirement is machine-checkable rather than narrative-only.
Approach
85de9bb6cd6ba1cece67906f71c93bf374a24942, checklist totals137 / 161, A+B+C+D127 / 146, Phase E5 / 10, manifest item count32, non-done manifest itemsA1 A2 A51b A51a2 A51c A51j A51h A51h1 A51h2 A51k A51f3 A51f5 B24h B36 E5b E5c E5d E5e, and the focused runner/E4 source scans before edits.docs/plans/bytecode-burndown-checklist.mdas the human source of truth,docs/plans/bytecode-proof-manifest.jsonplusBytecodeProofManifestTestsas the executable source of truth, anddocs/unified-bytecode-expansion-contract.mdas the decline-template drift inventory.BytecodeProofManifestTestsin the same change so the row is executable.Risks
BytecodeProofManifestTestsparses and enforces checklist/manifest/source-gate consistency.Additional quality gates
## Build Updateor the build handoff.ExecutionPlanRunnerconstruction stay in E5.Proof obligations
Recommended Labels
Acceptance Criteria (Refined)
AC-1: The build update captures the pre-edit baseline with current HEAD, checklist totals, manifest non-done ids, runner AST-seam scan result, E4 tombstone scan result, and source owner scan notes.
AC-2:
docs/plans/bytecode-burndown-checklist.md,docs/plans/bytecode-proof-manifest.json,docs/bytecode-progress.md, anddocs/unified-bytecode-expansion-contract.mdagree on current open rows, counts, owner files, proof anchors, and dynamic-residue boundaries.AC-3: Remaining open rows are converted into owned child slices with exact source files, proof anchors, and explicit boundaries for A1/A2, A51 compiler leaves, B24h, B36, E5b, E5c, E5d, and E5e; A51g/A51i lanes must not be dropped just because they lack manifest closure rows today.
AC-4: E4 stays closed as source-absence/tombstone inventory unless current production source contains a live E4 bridge; any such contradiction repairs the manifest/checklist before runtime work proceeds.
AC-5: No child slice or doc wording treats terminal dynamic residue as a parking bucket for ordinary compiler, class-definition, expression-program, or runner-retirement work.
AC-6:
BytecodeProofManifestTestscontinues to prove checklist/manifest status consistency, non-vacuous source discovery, exact source-presence/source-absence rows, and classified E5 fallback ownership.AC-7:
docs/unified-bytecode-expansion-contract.mdkeeps current decline-template inventories aligned with compiler and eligibility source; stale examples are removed or reclassified with proof.AC-8: The proof obligations above pass before review or verification is requested; any failed proof is reported with the exact command, failure, and next repair owner.
AC-9: Final build notes record both pre-edit baseline and post-change final signal for the selected stable evidence metric, even if the build turns out to be evidence-only.
AC-10: The build handoff records created child task ids, their lineage back to gh3377, and any rows intentionally left as terminal residue or human-governed future work.