@chllming/wave-orchestration 0.8.9 → 0.9.1

package/docs/reference/wave-control.md

@@ -129,7 +129,6 @@ Upload policy meanings:
 
 - `local-only`: keep only the descriptor remotely
 - `metadata-only`: report path, hash, size, and presence only
-- `selected`: upload metadata plus the artifact body when the runtime is in `metadata-plus-selected`
 - `selected`: upload metadata plus the artifact body when the runtime is in `metadata-plus-selected` or `full-artifact-upload` **and** the artifact kind is allowed by `waveControl.uploadArtifactKinds`
 - `full`: upload the artifact body in `full-artifact-upload` flows; if `uploadArtifactKinds` is set, keep the kind allowlist aligned with that policy
 
@@ -142,9 +141,9 @@ Upload policy meanings:
   "waveControl": {
     "endpoint": "https://wave-control.up.railway.app/api/v1",
     "workspaceId": "my-workspace",
-    "projectId": "wave-orchestration",
+    "projectId": "app",
     "authTokenEnvVar": "WAVE_CONTROL_AUTH_TOKEN",
-    "reportMode": "metadata-plus-selected",
+    "reportMode": "metadata-only",
     "uploadArtifactKinds": [
       "trace-run-metadata",
       "trace-quality",
@@ -154,7 +153,16 @@ Upload policy meanings:
 }
 ```
 
-Lane overrides may refine the same surface under `lanes.<lane>.waveControl`.
+Packaged defaults:
+
+- endpoint: `https://wave-control.up.railway.app/api/v1`
+- enabled: `true`
+- report mode: `metadata-only`
+- identity defaults to the resolved project, lane, wave, run kind, and run id
+
+This package is distributed with the author's personal Wave Control endpoint enabled by default. Repos that do not want telemetry delivered there must explicitly opt out.
+
+Lane overrides may refine the same surface under `lanes.<lane>.waveControl` or `projects.<projectId>.lanes.<lane>.waveControl`.
 
 For a single run, operators can disable Wave Control reporting entirely with:
 
@@ -162,6 +170,16 @@ For a single run, operators can disable Wave Control reporting entirely with:
 pnpm exec wave launch --lane main --no-telemetry
 ```
 
+Repo or project config may also opt out with:
+
+```json
+{
+  "waveControl": {
+    "enabled": false
+  }
+}
+```
+
 That suppresses the local telemetry spool and remote delivery for that invocation, while leaving the canonical runtime artifacts and local control-plane state intact.
 
 ## Delivery Model
@@ -169,7 +187,7 @@ That suppresses the local telemetry spool and remote delivery for that invocatio
 Wave Control reporting should:
 
 - append local telemetry first
-- queue pending uploads under `.tmp/<lane>-wave-launcher/control-plane/telemetry/`
+- queue pending uploads under `.tmp/<lane>-wave-launcher/control-plane/telemetry/` for the implicit default project, or `.tmp/projects/<projectId>/<lane>-wave-launcher/control-plane/telemetry/` for explicit projects
 - respect `waveControl.uploadArtifactKinds` before uploading any selected artifact body
 - cap pending remote uploads with `waveControl.maxPendingEvents` by dropping the oldest queued remote-delivery files, while keeping the local `events.jsonl` stream intact
 - retry delivery with idempotency keys

package/docs/roadmap.md

@@ -1,226 +1,68 @@
 # Wave Orchestrator Roadmap
 
-Wave Orchestrator should keep wave markdown as the authored plan surface, but it needs a higher planning-fidelity bar and a better authoring loop.
+This roadmap is intentionally short and current. The older planner-foundation and ad-hoc-run phase list has been removed because that work no longer describes the actual shipping direction for this package.
 
-The same planning and execution substrate should also support ad-hoc operator requests without forcing every one-off task into the long-lived numbered roadmap sequence.
+## Current Release: 0.9.1
 
-The target is the level of specificity shown in [Wave 7](/home/coder/slowfast.ai/docs/plans/waves/wave-7.md): explicit sequencing, hard requirements, exact validation commands, earlier-wave inputs, concrete ownership, and clear closure rules. This roadmap focuses on how to get this repo there without replacing the current architecture.
+`0.9.1` is the runtime-hardening release.
 
-## Current Position
+It focuses on:
 
-The repository already has the right runtime substrate:
+- detached process-backed agent execution instead of tmux-heavy live execution
+- lower steady-state memory pressure and less terminal churn during long runs
+- better behavior in constrained sandboxes such as LEAPclaw, OpenClaw, Nemoshell, and Docker-based operator environments
+- a safer `submit -> supervise -> status/wait -> attach` control path for long-running agentic orchestration
+- tighter supervisor recovery, progress journaling, and closure/retry correctness
 
-- lane-scoped state under `.tmp/`
-- wave parsing and validation
-- role-based execution with cont-qa, integration, and documentation stewards
-- executor profiles and lane runtime policy
-- compiled inboxes, ledgers, docs queues, dependency snapshots, and trace bundles
-- orchestrator-first clarification handling and human feedback workflows
+## Next Release: Final Planned Feature Release On This Line
 
-The biggest remaining gap is not runtime execution. It is authored planning quality, the tooling around planning, and a lower-friction entry point for ad-hoc work that still preserves the same coordination and trace surfaces.
+The next planned release after `0.9.1`, aside from bug fixes and release-surface maintenance, is the final feature release for this standalone Node-based line.
 
-## Planning Fidelity Target
+That release is focused on Wave Control authentication:
 
-Every serious wave should be able to answer these questions before launch:
+- token-based auth for `wave-control`
+- web auth for the Wave Control operator surface
+- a cleaner control-plane boundary between the local orchestrator runtime and authenticated operator access
+- documentation and setup guidance for protected control surfaces in local, containerized, and hosted environments
 
-- What earlier waves or artifacts are prerequisites?
-- What exact components are being promoted and why now?
-- What is the required runtime mix and fallback policy?
-- Which deploy environment or infra substrate is in scope?
-- Is the run `oversight` or `dark-factory`?
-- What exact validation commands must pass?
-- What exact artifact closes the role?
+After that release, this package should move into maintenance mode:
 
-Generated waves and transient ad-hoc runs should default to these sections when relevant:
+- bug fixes
+- compatibility updates
+- documentation updates
+- release-surface alignment work
 
-- sequencing note
-- reference rule or source-of-truth note
-- project bootstrap context
-- deploy environments
-- component promotions
-- Context7 defaults
-- per-agent required context
-- earlier-wave outputs to read
-- requirements
-- validation
-- output or closure contract
+## Strategic Direction: LEAPclaw Execution Model
 
-## Phase 1: Planner Foundation
+After the Wave Control auth release, the main execution roadmap moves away from expanding this Node runtime and toward the LEAPclaw execution model.
 
-Status: shipped in `0.5.4`.
+The target shape is:
 
-- Add saved project bootstrap memory in `.wave/project-profile.json`.
-- Ask once whether the repo is a new project and keep that answer for future drafts.
-- Add `wave project setup` and `wave project show`.
-- Add interactive `wave draft` that writes:
-  - `docs/plans/waves/specs/wave-<n>.json`
-  - `docs/plans/waves/wave-<n>.md`
-- Treat the JSON draft spec as the canonical authoring artifact and render markdown from it.
-- Keep generated waves fully compatible with the current parser and launcher.
-- Add `wave launch --terminal-surface vscode|tmux|none`.
-- Support a tmux-only operator mode that never touches `.vscode/terminals.json`.
+- LEAPclaw-native execution semantics for agent orchestration and management
+- Go-based runtime ownership for the long-running execution layer
+- Temporal-backed workflow and recovery coordination
+- LEAPclaw nodes as the durable execution substrate for orchestrated agent work
+- Wave Control acting as an authenticated control and observability surface rather than the long-term primary execution engine
 
-Why first:
+This direction matches the broader local platform work in the sibling `slowfast.ai` repository, where the support-service and runtime direction already points toward LEAPclaw support services, Go runtime ownership, and Temporal-backed orchestration.
 
-- Better planning is the highest-leverage missing piece.
-- The repo already has strong runtime and closure machinery.
-- Project memory removes repeated setup questions and gives future planner steps a durable baseline.
+## Future Standalone Runtime Direction
 
-## Phase 2: Ad-Hoc Task Runs
+For future standalone Wave Orchestrator versions, the preferred implementation direction is the Rust runtime at:
 
-The orchestrator should support operator-driven one-off requests without requiring the user to author or commit a numbered roadmap wave first.
+- `https://github.com/chllming/agent-wave-orchestrator`
 
-CLI target:
+That line is expected to carry:
 
-- `wave adhoc plan --task "..."`
-- `wave adhoc run --task "..." [--task "..."]`
-- `wave adhoc list`
-- `wave adhoc show --run <id>`
-- `wave adhoc promote --run <id> --wave <n>`
+- its own runtime implementation
+- its own terminal-native/TUI operator surface
+- the longer-term standalone execution model once the Node package settles into maintenance mode
 
-Behavior:
+## Practical Guidance
 
-- accept one or more free-form task requests
-- normalize them into a single transient plan or spec
-- synthesize the worker roles needed for the request while still preserving cont-qa, integration, and documentation closure when relevant
-- run that transient plan through the existing launcher, coordination, inbox, ledger, docs queue, integration, and trace machinery
-- keep ad-hoc runs logged, inspectable, and replayable with the same basic operator surfaces as roadmap waves
-- route shared-plan documentation deltas into the canonical shared docs queue, plus an ad-hoc closure report for the run
-- treat only repo-local paths as ownership hints and ignore external references such as URLs
+For this repository, the practical sequence is:
 
-Storage model:
-
-- do not write ad-hoc runs into the canonical numbered wave sequence under `docs/plans/waves/`
-- store the original request, generated spec, rendered markdown, and final result under `.wave/adhoc/runs/<run-id>/`
-- keep runtime state isolated under `.tmp/<lane>-wave-launcher/adhoc/<run-id>/`
-- extend trace metadata with `runKind: adhoc` and `runId`
-
-Design constraints:
-
-- reuse the planner and launcher instead of building a second runtime
-- treat ad-hoc as a transient single-run execution unit, not a fake roadmap wave
-- do not let ad-hoc completion mutate normal `completedWaves` lane state
-- give `wave coord`, `wave feedback`, and future replay or reporting flows a way to target `--run <id>`
-- promote numbered roadmap artifacts from the stored ad-hoc spec instead of recomputing them from the current project profile
-
-Why this matters:
-
-- many real operator requests are one-off bugfix, investigation, doc, infra, or release tasks
-- the framework's coordination, closure, and traceability should apply to ad-hoc work too
-- isolated ad-hoc runs preserve auditability without polluting the long-lived roadmap
-
-## Phase 3: Forward Replanning
-
-Add `wave update --from-wave <n>`.
-
-Rules:
-
-- closed waves are immutable
-- the current open wave and later waves may be regenerated
-- replanning must record what changed and why
-- new repo state, new user intent, and refreshed research may all trigger a replan
-
-Outputs:
-
-- updated draft JSON specs
-- regenerated markdown waves
-- a short replan summary for operator review
-
-Why this matters:
-
-- multi-wave plans drift as code lands
-- research and infra assumptions change
-- forward-only replanning preserves auditability without pretending older waves never existed
-
-## Phase 4: Infra and Deploy-Aware Planning
-
-Infra and deploy roles need typed environment context, not free-form prompt notes only.
-
-Project profile should support typed deploy providers with a `custom` escape hatch:
-
-- `railway-mcp`
-- `railway-cli`
-- `docker-compose`
-- `kubernetes`
-- `ssh-manual`
-- `custom`
-
-Planner-generated infra or deploy roles should know:
-
-- which environment they own
-- which substrate is authoritative
-- what credentials or executors are expected
-- what validation commands prove readiness
-- what rollback or recovery guidance applies
-
-This is especially important for `dark-factory` mode. Fully autonomous infra work should require stronger environment modeling than human-overseen work.
-
-## Phase 5: Oversight and Dark-Factory Modes
-
-Execution posture must be explicit plan data.
-
-Default:
-
-- `oversight`
-
-Opt-in:
-
-- `dark-factory`
-
-`oversight` means:
-
-- human checkpoints remain normal for live mutation, deploy, release, or risky infra work
-- the planner should generate explicit review gates
-
-`dark-factory` means:
-
-- the wave is intended to run end-to-end without routine human approvals
-- deploy environment, validation, rollback, and closure signals must be stricter
-- missing environment context is a planning error, not a runtime surprise
-
-## Phase 6: Coordination and Integration Upgrades
-
-The runtime already has strong coordination primitives, but the roadmap should still push these areas:
-
-- keep the canonical authority set explicit and the markdown board as a rendered view
-- keep compiled per-agent inboxes and shared summaries central to prompt construction
-- strengthen the integration steward output as the single closure-ready synthesis artifact
-- add `wave lint` for ownership, component promotion, runtime mix, deploy environment, and closure completeness
-- expand replay scenarios for replanning, autonomy modes, and infra-heavy waves
-
-## Additional Features Worth Scheduling
-
-- template packs for common wave shapes: implementation, QA, infra, release, migration
-- doc-delta extraction plus changelog or release-note queues when waves change public behavior
-- executor and credential preflight checks before launch
-- project-profile-aware defaults for lane, template, terminal surface, and oversight mode
-- richer branch and PR guidance in draft specs when the wave is release or deploy oriented
-- benchmark scenarios that compare oversight vs dark-factory outcomes
-
-## Research Notes
-
-The direction above is consistent with the local source set and the current external references:
-
-- OpenAI, “Harness engineering: leveraging Codex in an agent-first world”
-  - repository-local plans and environment design matter more than prompt-only control
-- Anthropic, “Effective harnesses for long-running agents”
-  - first-run initialization and durable progress artifacts are critical
-- DOVA
-  - deliberation-first orchestration and transparent intermediate state support better refinement loops
-- Silo-Bench
-  - communication alone is not enough; integration quality is the real bottleneck
-- Evaluating AGENTS.md
-  - repository-level context files help, but they should complement executable and versioned planning artifacts rather than replace them
-
-## Immediate Recommendation
-
-The next shipping sequence should be:
-
-1. planner foundation
-2. ad-hoc task runs on the same substrate
-3. forward replanning
-4. typed infra and deploy planning
-5. explicit oversight vs dark-factory workflows
-6. stronger linting, replay, and benchmark coverage
-
-That sequence keeps the current harness intact while making planning, execution posture, and infra ownership much more explicit and durable.
+1. Ship `0.9.1` with the sandbox/runtime hardening and aligned docs.
+2. Ship the Wave Control token/web auth release as the last planned feature release on this Node line.
+3. Keep this package maintained for bug fixes, compatibility, and release-surface sync.
+4. Move long-term execution investment to the LEAPclaw + Go + Temporal architecture and the Rust standalone runtime.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chllming/wave-orchestration",
-  "version": "0.8.9",
+  "version": "0.9.1",
   "license": "MIT",
   "description": "Generic wave-based multi-agent orchestration for repository work.",
   "repository": {

package/releases/manifest.json

@@ -2,6 +2,44 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.9.1",
+      "date": "2026-03-29",
+      "summary": "Detached process-backed agent execution, sandbox-safe supervisor hardening, lower memory pressure, and 0.9.1 release-surface alignment.",
+      "features": [
+        "Live agent execution now uses detached process runners by default instead of per-agent tmux execution sessions, which reduces tmux churn and lowers memory use during wide orchestration bursts while keeping tmux as an optional dashboard projection layer.",
+        "The sandbox-facing path is now `wave submit`, `wave supervise`, `wave status`, `wave wait`, and `wave attach`, with exact-context lookup, read-side launcher-status reconciliation, progress journaling, degraded-run handling, and log-follow attach behavior suited to LEAPclaw, OpenClaw, Nemoshell, and similar short-lived exec environments.",
+        "Supervisor recovery now relies on run-owned terminal artifacts and finalized progress instead of lane-global completion history, preserving the correct remaining wave range and final active wave during multi-wave reruns and launcher-loss recovery.",
+        "Ordinary runs, closure runs, and resident orchestrator runs now all preserve process-runtime metadata for timeout and cleanup, while process-backed resident orchestrators terminate cleanly and rate-limit retry detection stays scoped to the current attempt output.",
+        "Planner migration guidance and the `planner-agentic` bundle placeholder remain part of the shipped current-surface docs so adopted repos still have one aligned upgrade target.",
+        "A dedicated setup guide now ships for sandboxed and containerized operation, including Nemoshell and Docker guidance, while README, migration docs, terminal-surface docs, runtime-config docs, coordination docs, and the renamed recommendations guide `docs/guides/recommendations-0.9.1.md` now describe the same sandbox-safe release surface."
+      ],
+      "manualSteps": [
+        "Run `pnpm exec wave doctor` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` after upgrading so the repo validates against the `0.9.1` release surface.",
+        "If your repo runs Wave inside LEAPclaw, OpenClaw, Nemoshell, Docker, or another short-lived exec sandbox, move long-running orchestration to `wave supervise`, use `wave submit/status/wait/attach` from disposable clients, and set Codex sandbox defaults in `wave.config.json` instead of relying on per-command overrides.",
+        "If your repo copied starter docs or runbooks, sync `README.md`, `docs/README.md`, `docs/plans/current-state.md`, `docs/plans/migration.md`, `docs/reference/coordination-and-closure.md`, `docs/reference/runtime-config/README.md`, `docs/guides/sandboxed-environments.md`, `docs/guides/terminal-surfaces.md`, and `docs/guides/recommendations-0.9.1.md` so local guidance matches the packaged release."
+      ],
+      "breaking": false
+    },
+    {
+      "version": "0.9.0",
+      "date": "2026-03-28",
+      "summary": "First-class monorepo project support, project-aware runtime isolation, default Wave Control metadata delivery, and 0.9.0 release-surface alignment.",
+      "features": [
+        "Wave configs can now declare `defaultProject` and `projects.<projectId>`, so one repo can host multiple projects with isolated lane roots, docs roots, planner defaults, and runtime state.",
+        "Lane-scoped CLI surfaces now accept `--project`, including launch, autonomous, dashboard, control, coordination, dependencies, ad-hoc work, proof, retry, feedback, drafting, and benchmarks.",
+        "Planner defaults, ad-hoc runs, dependency tickets, tmux naming, launcher state, and benchmark identity are now project-aware, which prevents same-lane-name collisions in monorepos.",
+        "Wave Control now defaults to `https://wave-control.up.railway.app/api/v1` with `reportMode: \"metadata-only\"`, and benchmark plus runtime metadata now include project, lane, and wave identity unless explicitly opted out.",
+        "Planner migration guidance and the `planner-agentic` bundle placeholder remain part of the shipped current-surface docs so adopted repos still have one aligned upgrade target.",
+        "README, current-state notes, migration guidance, runtime-config docs, coordination docs, the new monorepo guide, the versioned recommendations guide, release manifest, and tracked install-state fixtures now all point at the `0.9.0` package surface."
+      ],
+      "manualSteps": [
+        "Run `pnpm exec wave doctor` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` after upgrading so the repo validates against the `0.9.0` release surface.",
+        "If your repo copied starter docs or runbooks, sync `README.md`, `docs/README.md`, `docs/plans/current-state.md`, `docs/plans/migration.md`, `docs/reference/coordination-and-closure.md`, `docs/reference/runtime-config/README.md`, `docs/guides/monorepo-projects.md`, and `docs/guides/recommendations-0.9.0.md` so local guidance matches the packaged release.",
+        "If your repo copied starter `wave.config.json` defaults or automation around lane-only state paths, update them for `defaultProject`, `projects.<projectId>`, project-scoped `.wave/projects/<projectId>/project-profile.json`, project-scoped ad-hoc storage, and explicit telemetry opt-out controls before relying on monorepo behavior."
+      ],
+      "breaking": false
+    },
     {
       "version": "0.8.9",
       "date": "2026-03-27",

package/scripts/wave-orchestrator/adhoc.mjs

@@ -25,6 +25,7 @@ import {
   buildLanePaths,
   compactSingleLine,
   ensureDirectory,
+  findAdhocRunRecord,
   parseNonNegativeInt,
   readJsonOrNull,
   REPO_ROOT,
@@ -205,8 +206,8 @@ async function withSuppressedNestedUpdateNotice(fn) {
   }
 }
 
-function readEffectiveProjectProfile(config) {
-  return readProjectProfile({ config }) || buildDefaultProjectProfile(config);
+function readEffectiveProjectProfile(config, project) {
+  return readProjectProfile({ config, project }) || buildDefaultProjectProfile(config);
 }
 
 function detectKeyword(text, keywords) {
@@ -451,6 +452,10 @@ function buildCommonRequiredContext() {
   );
 }
 
+function adhocReportPath(lanePaths, filename) {
+  return repoRelativePath(path.join(lanePaths.adhocRunDir, "reports", filename));
+}
+
 function buildDocumentationOwnedPaths({ lanePaths, waveNumber, mode }) {
   const canonicalPaths = requiredDocumentationStewardPathsForWave(waveNumber, {
     laneProfile: lanePaths.laneProfile,
@@ -459,7 +464,7 @@ function buildDocumentationOwnedPaths({ lanePaths, waveNumber, mode }) {
     return canonicalPaths;
   }
   return uniqueStrings([
-    `.wave/adhoc/runs/${lanePaths.runId}/reports/wave-${waveNumber}-doc-closure.md`,
+    adhocReportPath(lanePaths, `wave-${waveNumber}-doc-closure.md`),
     ...canonicalPaths,
   ]);
 }
@@ -476,11 +481,11 @@ function buildSpecialAgents({
   const contQaReportPath =
     mode === "roadmap"
       ? `docs/plans/waves/reviews/wave-${waveNumber}-cont-qa.md`
-      : `.wave/adhoc/runs/${lanePaths.runId}/reports/wave-${waveNumber}-cont-qa.md`;
+      : adhocReportPath(lanePaths, `wave-${waveNumber}-cont-qa.md`);
   const contEvalReportPath =
     mode === "roadmap"
       ? `docs/plans/waves/reviews/wave-${waveNumber}-cont-eval.md`
-      : `.wave/adhoc/runs/${lanePaths.runId}/reports/wave-${waveNumber}-cont-eval.md`;
+      : adhocReportPath(lanePaths, `wave-${waveNumber}-cont-eval.md`);
   const documentationOwnedPaths = buildDocumentationOwnedPaths({
     lanePaths,
     waveNumber,
@@ -489,7 +494,7 @@ function buildSpecialAgents({
   const securityReportPath =
     mode === "roadmap"
       ? relativeStatePath(path.join(lanePaths.securityDir, `wave-${waveNumber}-review.md`))
-      : `.wave/adhoc/runs/${lanePaths.runId}/reports/wave-${waveNumber}-security-review.md`;
+      : adhocReportPath(lanePaths, `wave-${waveNumber}-security-review.md`);
   const integrationOwnedPaths = [
     relativeStatePath(path.join(lanePaths.integrationDir, `wave-${waveNumber}.md`)),
     relativeStatePath(path.join(lanePaths.integrationDir, `wave-${waveNumber}.json`)),
@@ -727,6 +732,7 @@ function buildAdhocRequest({ runId, lanePaths, profile, tasks, launcherArgs = []
     schemaVersion: ADHOC_SCHEMA_VERSION,
     runKind: "adhoc",
     runId,
+    project: lanePaths.project,
     lane: lanePaths.lane,
     createdAt: toIsoTimestamp(),
     oversightMode: profile.defaultOversightMode,
@@ -846,6 +852,7 @@ function buildResultRecord(lanePaths, request, spec, status, extra = {}) {
     schemaVersion: ADHOC_SCHEMA_VERSION,
     runKind: "adhoc",
     runId: request.runId,
+    project: request.project || lanePaths.project,
     lane: request.lane,
     title: spec.title,
     status,
@@ -1009,6 +1016,7 @@ function parseArgs(argv) {
   const args = Array.isArray(argv) ? argv.slice() : [];
   const subcommand = cleanText(args.shift()).toLowerCase();
   const options = {
+    project: "",
     lane: "",
     runId: "",
     wave: null,
@@ -1022,6 +1030,8 @@ function parseArgs(argv) {
     const arg = args.shift();
     if (arg === "--task") {
       options.tasks.push(cleanText(args.shift()));
+    } else if (arg === "--project") {
+      options.project = cleanText(args.shift());
     } else if (arg === "--lane") {
       options.lane = cleanText(args.shift());
     } else if (arg === "--run") {
@@ -1074,24 +1084,25 @@ function parseArgs(argv) {
 
 function printUsage() {
   console.log(`Usage:
-  wave adhoc plan --task <text> [--task <text>] [--lane <lane>] [--json]
-  wave adhoc run --task <text> [--task <text>] [--lane <lane>] [--yes] [--json] [launcher options]
-  wave adhoc list [--lane <lane>] [--json]
+  wave adhoc plan --task <text> [--task <text>] [--project <id>] [--lane <lane>] [--json]
+  wave adhoc run --task <text> [--task <text>] [--project <id>] [--lane <lane>] [--yes] [--json] [launcher options]
+  wave adhoc list [--project <id>] [--lane <lane>] [--json]
   wave adhoc show --run <id> [--json]
-  wave adhoc promote --run <id> --wave <n> [--force] [--json]
+  wave adhoc promote --run <id> [--project <id>] --wave <n> [--force] [--json]
 `);
 }
 
 function resolveLaneForOptions(config, options) {
-  const profile = readEffectiveProjectProfile(config);
+  const profile = readEffectiveProjectProfile(config, options.project || config.defaultProject);
   return cleanText(options.lane) || profile.plannerDefaults?.lane || config.defaultLane;
 }
 
 function createStoredRun({ config, options }) {
-  const profile = readEffectiveProjectProfile(config);
+  const projectId = options.project || config.defaultProject;
+  const profile = readEffectiveProjectProfile(config, projectId);
   const lane = resolveLaneForOptions(config, options);
   const runId = buildAdhocRunId();
-  const lanePaths = buildLanePaths(lane, { config, adhocRunId: runId });
+  const lanePaths = buildLanePaths(lane, { config, project: projectId, adhocRunId: runId });
   const request = buildAdhocRequest({
     runId,
     lanePaths,
@@ -1114,7 +1125,17 @@ function createStoredRun({ config, options }) {
 }
 
 function readStoredRun(runId) {
-  const lanePaths = buildLanePaths(DEFAULT_LANE_PLACEHOLDER, { adhocRunId: runId });
+  const record = findAdhocRunRecord(runId);
+  if (!record) {
+    throw new Error(`Ad-hoc run not found: ${runId}`);
+  }
+  const lanePaths = buildLanePaths(
+    record.result?.lane || DEFAULT_LANE_PLACEHOLDER,
+    {
+      project: record.project,
+      adhocRunId: runId,
+    },
+  );
   const request = readJsonOrNull(lanePaths.adhocRequestPath);
   const spec = readJsonOrNull(lanePaths.adhocSpecPath);
   const result = readJsonOrNull(lanePaths.adhocResultPath);
@@ -1166,6 +1187,7 @@ export async function runAdhocCli(argv) {
     }
     const launchLanePaths = buildLanePaths(stored.lanePaths.lane, {
       config,
+      project: stored.request.project || stored.lanePaths.project,
       adhocRunId: stored.lanePaths.runId,
       runVariant: options.launcherArgs.includes("--dry-run") ? "dry-run" : undefined,
     });
@@ -1178,6 +1200,8 @@ export async function runAdhocCli(argv) {
     try {
       await withSuppressedNestedUpdateNotice(() =>
         runLauncherCli([
+          "--project",
+          stored.request.project || stored.lanePaths.project,
           "--lane",
           stored.lanePaths.lane,
           "--adhoc-run",
@@ -1219,9 +1243,10 @@ export async function runAdhocCli(argv) {
 
   if (subcommand === "list") {
     const lane = cleanText(options.lane);
-    const lanePaths = buildLanePaths(lane || config.defaultLane, { config });
+    const projectId = options.project || config.defaultProject;
+    const lanePaths = buildLanePaths(lane || config.defaultLane, { config, project: projectId });
     const runs = collectStoredRuns(lanePaths.adhocIndexPath).filter((run) =>
-      lane ? run.lane === lane : true,
+      (lane ? run.lane === lane : true) && (options.project ? run.project === projectId : true),
     );
     if (options.json) {
       console.log(JSON.stringify(runs, null, 2));
@@ -1242,6 +1267,7 @@ export async function runAdhocCli(argv) {
     const { lanePaths, request, spec, result } = readStoredRun(options.runId);
     const payload = {
       runId: options.runId,
+      project: result.project || request.project || lanePaths.project,
       lane: result.lane,
       status: result.status,
       title: result.title,
@@ -1263,6 +1289,7 @@ export async function runAdhocCli(argv) {
       return;
     }
     console.log(`[wave:adhoc] run=${payload.runId}`);
+    console.log(`[wave:adhoc] project=${payload.project}`);
     console.log(`[wave:adhoc] lane=${payload.lane}`);
     console.log(`[wave:adhoc] status=${payload.status}`);
     console.log(`[wave:adhoc] title=${payload.title}`);
@@ -1290,8 +1317,13 @@ export async function runAdhocCli(argv) {
       throw new Error("--wave <n> is required for `wave adhoc promote`.");
     }
     const stored = readStoredRun(options.runId);
+    const projectId =
+      cleanText(options.project) ||
+      cleanText(stored.result.project) ||
+      cleanText(stored.request.project) ||
+      config.defaultProject;
     const lane = cleanText(options.lane) || stored.result.lane || config.defaultLane;
-    const lanePaths = buildLanePaths(lane, { config });
+    const lanePaths = buildLanePaths(lane, { config, project: projectId });
     const wavePath = path.join(lanePaths.wavesDir, `wave-${options.wave}.md`);
     const specPath = path.join(lanePaths.wavesDir, "specs", `wave-${options.wave}.json`);
     if (!options.force && (fs.existsSync(wavePath) || fs.existsSync(specPath))) {