WfP ecosystem support roadmap: Wave Whale Vex and native debugging

This is an index issue, not a work item: read the 'Good first issues' section and the 'Implementation dependencies' list to see where to enter. To contribute here, pick a bounded child issue such as #58 (Whale textual IR highlighting) or #94 (documenting the three debugging workflows) rather than editing the roadmap itself. Baselines, audit boundaries and label semantics are all defined in the body; #8 holds the existing runtime/Cargo entry points.

Purpose

Track the audited Wave, Whale and Vex integration work for Wave for Platform. This is an index of focused contributor tasks, not one implementation PR. Existing runtime/product cleanup and Rust/Cargo foundations remain in #8.

The user has requested issue registration first; implementation will proceed separately. The audit read pinned source/configuration and existing upstream issues. It did not execute a compiler, debugger, test suite or IDE.

Audit date: 2026-09-23. Baselines: Wave 509a1e46; Whale e3a12d08; Vex 71f29daa; WfP 2804fc02.

Boundaries established by the audit

• Wave currently emits LLVM IR; its reserved --whale backend is not implemented. Wave .ast Debug text is not Whale frontend JSON.
• Whale IR lowering is feature-gated. Reliable navigation/CFG needs stable identities and parsing/inspection contracts.
• Whale assembly currently supports AMD64 ELF objects. The object command wraps raw bytes; it is not an object inspector.
• Whale link is a stub at the audited baseline, so exit zero must not be interpreted as a produced executable.
• Vex uses WSON manifests/locks. Metadata/build-event protocols are upstream work, and plain vex tree can resolve/fetch/change lock state.
• Debugging the Rust compiler process, inspecting compiler dumps and debugging a generated Wave program are separate workflows.

Keep Open as the project entry point. Do not restore New Project, remove unrelated development tools, or run builds automatically on project open.

Contributor guidance

Start with a bounded unassigned issue and coordinate before substantial implementation. Each issue owns a specific scope and includes acceptance criteria and prerequisites. Existing Cargo/Rust issues #30–35 and LSP issues #25–29 remain authoritative for those foundations.

The blocked-upstream label means a real compiler/protocol prerequisite exists. Its issue body identifies the boundary. An upstream reference without that label can be coordination or background rather than a blocker. Good-first labels are limited to genuinely small entry points; complex debugger and parser work is not labeled easy.

Shared toolchain and command infrastructure

• #50 — Select project toolchain profiles for wavec Whale and Vex
• #51 — Discover compiler capabilities without assuming every tool supports the same commands
• #52 — Share bounded cancellable process execution across ecosystem tool adapters

Wave builds, diagnostics and artifacts

• #53 — Add direct wavec check build and run configurations
• #54 — Display wavec dry-run plans and target configuration from compiler JSON
• #55 — Map Wave JSON diagnostics to source locations and related errors
• #56 — Track compiler artifacts with input tool and target provenance
• #57 — Add basic LLVM IR editing support distinct from Whale IR

Whale IR inspection

• #58 — Recognize and highlight Whale textual IR files
• #59 — Run Whale frontend JSON lowering as an explicit compiler experiment
• #60 — Navigate Whale IR value and block identities from a stable inspection contract — blocked upstream
• #61 — Visualize Whale control-flow graphs using stable block identities — blocked upstream
• #62 — Compare Whale IR snapshots before and after explicit optimization passes — blocked upstream
• #63 — Link Wave source locations to Whale lowering and IR diagnostics — blocked upstream

Assembly and encoding

• #64 — Select assembly dialect and ISA without conflating syntax coloring with assembler support
• #65 — Assemble explicit AMD64 fixtures with Whale and register ELF outputs
• #66 — Navigate Whale assembly labels sections and declaration references
• #67 — Inspect Whale assembler token AST and byte dumps without treating debug text as a protocol
• #71 — Map assembly source instructions to emitted bytes and relocations — blocked upstream

Objects and disassembly

• #68 — Add a bounded read-only ELF64 header and section inspector
• #69 — Inspect ELF symbols and navigate to their defining sections
• #70 — Inspect ELF relocation records and their symbol and byte targets
• #72 — Compare compiler object artifacts by sections symbols relocations and bytes
• #73 — Add explicit object disassembly with address symbol and byte navigation

Linker scripts and link results

• #74 — Add a bounded linker-script structure view for MEMORY SECTIONS and ENTRY
• #75 — Navigate linker-script INCLUDE paths using explicit search roots
• #76 — Inspect linker map files with section layout and memory-size summaries
• #77 — Integrate Whale linking only after executable and diagnostic contracts are implemented — blocked upstream

Vex packages and dependencies

• #78 — Add WSON language support for vex.ws and vex.lock
• #79 — Validate and complete Vex manifest and lockfile fields separately
• #80 — Recognize existing Vex package roots and canonical source entries
• #81 — Add manifest-scoped Vex build check and run configurations
• #82 — Display the Vex dependency graph from versioned metadata and local lock state — blocked upstream
• #83 — Run explicit Vex fetch and targeted update actions with lockfile change summaries
• #84 — Share Vex dependency source roots with Wave LSP import resolution — blocked upstream
• #85 — Consume Vex structured build messages and artifact events — blocked upstream

Native and Wave source debugging

• #86 — Add a bounded native Debug Adapter Protocol client for WfP
• #87 — Configure debugging of the Rust wavec Whale and Vex binaries
• #88 — Connect native breakpoints stepping stacks and variables to XDebugger
• #89 — Expose supported native disassembly registers and memory in debug sessions
• #90 — Support Wave source debugging after compiler debug metadata is available — blocked upstream
• #94 — Document the three distinct compiler-development debugging workflows

Compiler regression workflows

• #91 — Run selected Wave compiler regression cases through the existing test runner
• #92 — Display Wave JSON regression reports with failure navigation
• #93 — Compare two Wave compiler builds on an explicitly selected regression fixture

Implementation dependencies

• #51 depends on #50.
• #52 depends on #50.
• #53 depends on #50, #51, #52.
• #54 depends on #53.
• #55 depends on #53.
• #56 depends on #50, #52.
• #59 depends on #51, #52, #56.
• #60 depends on #58.
• #61 depends on #60.
• #62 depends on #60, #56.
• #63 depends on #60, #55.
• #65 depends on #64, #51, #52, #56.
• #66 depends on #64.
• #67 depends on #65.
• #69 depends on #68.
• #70 depends on #68, #69.
• #71 depends on #65, #70.
• #72 depends on #56, #70.
• #73 depends on #69, #52, #50.
• #75 depends on #74, #54.
• #76 depends on #54, #56, #69.
• #77 depends on #51, #52, #56, #70.
• #79 depends on #78.
• #80 depends on #78.
• #81 depends on #50, #52, #80.
• #82 depends on #80, #79.
• #83 depends on #81, #79.
• #84 depends on #82.
• #85 depends on #81, #55, #56.
• #86 depends on #50, #52.
• #87 depends on #86.
• #88 depends on #86, #87.
• #89 depends on #88.
• #90 depends on #88, #56, #53.
• #91 depends on #50, #52, #51.
• #92 depends on #91.
• #93 depends on #50, #52, #56, #92.

Suggested order

1. Tool profiles and command lifecycle, then explicit wavec/Vex actions and diagnostics.
2. Rust compiler-process debugging, Vex editing/project discovery, and selected regression runs.
3. Text artifact comparison, assembly execution, ELF inspection, and linker-script/map views.
4. Stable upstream contracts unlock IR graphs/pass comparison, Vex metadata/events, real Whale linking, and generated Wave source debugging.

Good first issues

#58, #94. Existing entry points remain indexed in #8.

Accounting

45 focused new work issues plus this index; 10 are labeled blocked upstream and 2 are good first issues. No product code changes, compilation, IDE launches, or debugger sessions were performed as part of this issue-registration batch.