UTTORI ASM · IN DEVELOPMENT

Runtime capture in VS Code

Use runtime capture in vs code in the Uttori ASM VS Code extension.

Use Source Project → Capture to record a runtime window, finalize it and optionally import its evidence into the selected matching source project.

asm.debug.traceDetail selects full execution details (default) or explicit PC-only recording. Full capture rejects runtimes without instruction-detail support. Check the active workspace's launch.json runtime paths and restart debugging with a rich-trace build. Capture notifications show the selected mode and report dropped events, including when stopping to analyze. Both modes still use bounded buffers: a longer recording can lose events and does not guarantee more unique code coverage. New trace producer identities include the executable SHA-256 so supplemental runtime builds can be distinguished. Captured RAM instructions open from Sources using their saved bytes. See configuration, workflow, and remaining trace limits.

The sidebar includes Project, Outline, Source Project, Sources and Analysis Coverage. The Source Project view separates building current edits from updating source with new evidence. Start Capture, Stop Capture and Stop Capture and Import Evidence retain visible recording/finalization state, including recordings started from the command palette. The view title also has Record/Stop actions during a matching ares session.

Start while paused, choose the output and Continue (F5). Stop finalizes and offers import; Stop and Import also imports into the selected matching project. Imported evidence does not automatically merge new source. Analyze, prepare, preview, checkpoint, apply and finish when you want to incorporate it. See source projects.

Capture storage controls

asm.analysis.cacheMaxMiB defaults to 256 for disposable SQL projections. asm.analysis.storageMaxMiB defaults to 0 (no database publication ceiling). Explicit editor settings override the persisted project policy. Unset settings preserve policy choices made through the CLI.

Use uttori-asm project-storage <analysis-directory> to inspect capture receipts and storage usage, apply limits, and recycle caches/WAL. Imports read the source capture without copying it into the project. Keep the original recording when you need its full ordered history. Reopen clients after replacing a project database.

Native ares file capture

With the separately installed ares-capture-file-desktop-runtime candidate, set asm.debug.captureSink to native-file and select any lossless asm.debug.traceMode. Start recording while paused, then continue or step. Ares writes bounded binary ACT2 batches directly to the selected local file. Stop Recording waits for durable finalization. The existing import and storage budgets still apply. Stream remains the default sink. See native file capture for setup, scope, measured throughput, recovery and platform limitations.

The ares-realtime-desktop-runtime follow-up adds faster native checksums and live bus analysis. With native-file and a lossless bus mode selected, enable asm.debug.liveBusAnalysis to choose a matching project and see provisional counts/backlog in the status bar. The isolated worker publishes only after complete archive validation. asm.debug.liveBusMaxLagMiB defaults to 256. Exceeding it stops analysis while recording continues. Click the status bar or run Assembly: Stop Live Bus Analysis to stop analysis independently. Dense PPU analysis can still fall behind even when recording exceeds realtime. See the native capture workflow.

Capture context is enabled by default (asm.debug.captureContext). Use Add Capture Milestone to label a paused screenshot, Replay Capture Inputs to reproduce the captured action, or Restore Capture Pre-action State to try a different action from the same state. These require a matching local ares runtime and ROM. See the capture bundle reference for file contracts, visual timing, replay validation, and graphics scope limits.