map-memories v0.49.19: malformed finalize output followed by MC-D11 aborts run after partial progress #771

Short description

On stock v0.49.19, map-memories made useful progress with NVIDIA Nemotron Lightning but then emitted a <branch> root instead of <mappings> near its investigation budget. Validation announced a fallback, but that was immediately followed by DreamTokenBudgetExceeded / MC-D11. The task failed rather than completing the backlog. Please investigate finalize-format reliability and the interaction between finalization and validation fallback; this report does not request weaker validation or higher safety caps.

Environment

• Stock @cortexkit/opencode-magic-context@0.49.19, confirmed by live stack package paths.
• OpenCode 1.19.4, macOS arm64.
• Model: nvidia/nvidia/nemotron-3.5-lightning-30b-a3b.
• User changed the mapper model only; no local plugin patches, timeout increases, token-budget increases, or runtime-storage edits were made.

Observed run, 2026-10-23 UTC

10:19:18.566 mapper child started
10:20:58.160 dreamer token budget: finalize fired {"budget":2500000,"spent":2035462,"finalizeFired":true,"refusedCalls":0,"hardStopped":false}
10:21:22.445 map-memories batch: steps=29 committed=5 steps_per_memory=5.80 elapsed_ms=123947
10:21:22.561 next mapper child started
10:23:01.386 dreamer token budget: finalize fired {"budget":2500000,"spent":2055519,"finalizeFired":true,"refusedCalls":0,"hardStopped":false}
10:23:19.655 [dreamer:map-memories] primary (nvidia/nvidia/nemotron-3.5-lightning-30b-a3b) failed validation/prompt: root <branch> unrecognized; expected <mappings> with <memory> entries; trying 1 fallback(s)
10:23:19.656 map-memories batch failed: DreamTokenBudgetExceeded message="Dreamer child [redacted] spent 2166112 prompt tokens (token_budget)"
10:23:19.663 map-memories: accepted partial manifest after token budget: 0/5
10:23:19.663 map-memories batch: steps=25 committed=0 steps_per_memory=n/a elapsed_ms=117162
10:23:19.667 task map-memories failed code=MC-D11 (transient=false): DreamTokenBudgetExceeded

The first batch committed five decisions; the second committed none. Existing decisions were preserved. The log's 2,166,112 spent value is reported as observed, without asserting it exceeded the configured 2,500,000 hard cap: finalization had already fired, and the exact budget-state/fallback interaction needs investigation.

Context and comparison

An earlier stock run with Super as primary showed the new 90-second no-output fallback working correctly: Lightning completed two five-item fallback batches. Later Super batches produced 8 and 9 steps respectively but each timed out after 240000ms with no commits, ending with 29 pending. That motivated the task-specific switch to Lightning. The two models have not been compared on an identical controlled sample; these observations do not prove a universal model-speed or capability difference.

Expected behavior / investigation request

• The budget-finalization turn should produce the task's required <mappings> contract, or fail with an actionable explanation without implying that a fallback can run when the child can no longer accept it.
• Retain strict host-side path/manifest validation, token and timeout limits, and preservation of already committed decisions.
• Determine whether recoverable partial decisions or a bounded format-repair mechanism can avoid losing all progress in an interrupted batch, without treating malformed output as valid or silently classifying memories as independent.
• Please distinguish expected budget exhaustion from a finalization/fallback integration defect; the supplied evidence establishes the failure sequence, not its final code-level cause.

Verification route

Latest manual verification used:

npm run opencode -- run --agent power --command ctx-dream map-memories

The CLI returned exit 0 with no task-result text, while the plugin log recorded the MC-D11 failure above. CLI process success was therefore not used as task-success evidence. This result-reporting limitation may be separate from the mapping failure.

Diagnostics

Only sanitized task timing/model/count/error lines are included. No memory bodies, source contents, credentials, complete configuration, or runtime database dumps are attached. No local fork is active. This differs from #356's old shrinking-time-slice problem and #323's older manifest-validation defects.