@selesai/code 0.13.11 → 0.13.13

package/dist/skills/unlazy/references/method.md

@@ -1,49 +0,0 @@
-# The Depth Tree
-
-Use the tree to expose natural work boundaries and integration points. Do not treat depth as an arithmetic promise about effort or tokens.
-
-The original v1 method claimed that each binary split multiplied effort. A small maintainer-run comparison later suggested that agents treated depth as a thoroughness cue rather than following that arithmetic. The repository does not contain the raw artifacts needed to reproduce those historical figures, so treat them as design history, not benchmark evidence. See [../research/validation-protocol.md](../research/validation-protocol.md).
-
-## Rules
-
-1. **Make layer 1 the requested task.** Split only at real domain, component, or verification boundaries. Binary splits are optional.
-2. **Make each leaf one coherent deliverable.** Give it exact ownership, dependencies, and acceptance gates. Merge tiny adjacent leaves; split a leaf that hides several independent outcomes.
-3. **Fix contracts before fan-out.** Reread the original request and current amendments. Inventory every independently omittable required outcome and acceptance-changing constraint in `PLAN.md`, then record interfaces, formats, shared assumptions, error conventions, naming, and ownership before a leaf starts.
-4. **Give branches integration gates.** Verify child ledgers again, then test interfaces, end-to-end behavior, and regressions across the joined work.
-5. **Use gates and passes as the effort control.** Finish implementation, expert reread, defect hunt, and low-cost polish. Stop only when every required gate has current evidence and another improvement pass finds nothing.
-
-## Choose depth
-
-- Use a shallow tree or solo ledger for a feature, contained bug hunt, or document.
-- Use an orchestrated tree when several coherent deliverables benefit from fresh contexts or independent ownership.
-- Use a deeper tree only when its additional branches correspond to real integration boundaries. Do not add empty hierarchy to satisfy a number.
-- Honor an explicit `tree N` request while keeping leaves meaningful. If the requested depth would create filler leaves, state the mismatch and use the closest honest decomposition.
-
-When no depth is requested, choose the smallest tree that exposes every independent deliverable and integration point.
-
-## Contract checklist
-
-Before dispatch, make these decisions explicit:
-
-- stable contract item ids mapped to an owner and observing gate or manual review
-- exact files or relative globs each leaf owns
-- interfaces and schemas shared between leaves
-- dependency ids and readiness states
-- toolchain, shell, and working-directory requirements
-- error and compatibility conventions
-- which branch gates prove integration
-- who performs high-risk manual review
-
-Optional ideas are not requirements. Paraphrase only acceptance-relevant facts; never copy credentials, private request text, or unrelated context into repository state. Increment the contract revision when the user changes scope, reconcile every affected mapping before new dispatch, and use `REMOVED_BY_USER` only with explicit user authority.
-
-Do not let two concurrent leaves own the same path. If shared work cannot be separated, make it an earlier dependency or a dedicated integration leaf.
-
-## Completion hierarchy
-
-| Layer | Proof |
-|---|---|
-| Leaf | Current runnable evidence plus reviewed manual evidence |
-| Branch | Reverified children plus cross-child integration checks |
-| Root | Current request reread, every contract row reconciled, every branch integrated, regressions checked, final claims remeasured |
-
-Local completion does not imply integration. Verify from leaves upward and report only after the root ledger and current contract inventory are satisfied. A missing owner or observation, stale reference, abandonment, deferment, or owner decision is a visible handoff, not completion.

package/dist/skills/unlazy/references/orchestration.md

@@ -1,98 +0,0 @@
-# Orchestrated mode
-
-Use orchestrated mode when one context cannot hold the task and its verification at full attention. Keep the driver responsible for planning, dispatch, independent verification, integration, and the root report.
-
-## Declare states and paths
-
-Use these leaf states only:
-
-- `WAITING`: one or more ids in `Needs` are not yet `VERIFIED`
-- `READY`: dependencies are verified and ownership is available
-- `IN-FLIGHT`: dispatched and not yet independently verified
-- `VERIFIED`: parent re-verification passed and manual gates were reviewed
-- `ABANDONED`: at least one required gate has a recorded handoff; never treat this as full completion
-
-Use `OPEN`, `VERIFIED`, or `ABANDONED` for branches. Store leaf ledgers as `gates/leaf-<id>.md` and integration ledgers as `gates/node-<id>.md`. Do not label a branch path as `leaf-*`.
-
-## Driver loop
-
-1. **Plan before fan-out.** Reread the original request and current amendments. Create `.unlazy/<scope>/PLAN.md`, `.unlazy/<scope>/GATES.md`, and one ledger per leaf and branch from the templates. Inventory every independently omittable outcome and acceptance-changing constraint with a stable id, owner, observing gate or manual review, disposition, and revision. Fix interfaces, naming, toolchain, dependencies, and exact ownership before dispatch.
-2. **Inspect and approve checks.** Run `gate-check --status` on every inherited ledger. Review each `CHECK:`, `EXPECT:`, and `CWD:`, including called scripts. Determine the shell and inherited `PATH`; a new oracle with no exact approval prints its resolved values during a normal run without executing. Use `--approve` only after inspection, and do not treat normal mode as a dry run once approval exists.
-3. **Claim every concurrent leaf.** Run:
-
-   ```text
-   node <skill-dir>/scripts/gate-check.mjs --scope <scope> --leaf leaf-1.2.1 --claim
-   ```
-
-   A refused claim means the split is not safe for concurrent dispatch. Change the plan or run the work sequentially; never bypass the refusal.
-4. **Launch each ready wave.** Give each leaf only the shared contract, its exact ownership and dependencies, its own ledger, and the four-pass completion rule. Open a dispatch wave for the independent `READY` leaves, call the host's native nonblocking launch once per leaf, record every host handle, and seal the wave before the first wait or result read. Follow [dispatch.md](dispatch.md); do not leak unrelated leaf histories.
-5. **Verify each return independently.** Record the native return in its wave, then re-run the returned leaf's runnable gates, including already checked gates:
-
-   ```text
-   node <skill-dir>/scripts/gate-check.mjs --root . --cwd . --reverify .unlazy/<scope>/gates/leaf-1.2.1.md
-   ```
-
-   `--status` alone is not re-verification. If an approved oracle changed, inspect it and approve the new oracle before continuing. Review manual gates directly and try to refute at least one passed gate.
-6. **Append status and roll forward.** Record the result without rewriting history:
-
-   ```text
-   node <skill-dir>/scripts/gate-check.mjs --scope <scope> --log "leaf-1.2.1 verified"
-   ```
-
-   Mark the leaf `VERIFIED`, promote newly unblocked leaves from `WAITING` to `READY`, and dispatch them without waiting for unrelated in-flight leaves.
-7. **Integrate bottom-up.** Work each `node-*.md` ledger only after all named children return. Reverify the children, then run interface, end-to-end, and regression checks.
-8. **Reconcile, release, and report.** Reread the current request and review every current contract row. Missing/stale ownership or observation, abandonment, deferment, and owner decisions are non-completion. Release all scope leases after final verification. Report only when both the inventory and root ledger are met, then remeasure every reported count.
-
-## Check concurrency
-
-Gate checks run sequentially by default (`--jobs 1`). This is the easiest transcript to debug and is the compatibility behavior.
-
-Use `--jobs <N>` only when runnable gates are independent and parallel execution reduces wall-clock time:
-
-```text
-node <skill-dir>/scripts/gate-check.mjs --root . --cwd . --reverify --jobs 4 .unlazy/<scope>/gates/leaf-1.1.1.md .unlazy/<scope>/gates/leaf-1.1.2.md
-```
-
-The limit is rolling: start another check when one finishes instead of waiting for a fixed batch. Output and file updates remain deterministic in ledger order. `--jobs` controls command execution, not subagent dispatch and not dependency readiness. Use [dispatch waves](dispatch.md) for native agent concurrency.
-
-## Rolling dispatch
-
-Treat dispatch as a loop:
-
-```text
-while an unverified leaf remains:
-  collect the independent READY leaves up to the host concurrency limit
-  open a dispatch wave for that exact set
-  launch every native agent and record every returned host handle
-  seal the wave before the first wait
-  wait for the next leaf to return
-  record that return in its dispatch wave
-  reverify that leaf and review its manual evidence
-  append status and update its declared state
-  promote each WAITING leaf whose Needs are all VERIFIED
-```
-
-Do not invent a dependency during dispatch. Add it to `PLAN.md`, correct the affected states, and record the change. A user amendment increments the contract revision and must be reconciled before more completion credit. Prefer independent leaves, but do not force independence where an interface must be established first.
-
-## Verification hierarchy
-
-1. **Leaf self-check:** catches ordinary incompleteness but remains self-certification.
-2. **Parent `--reverify`:** executes each runnable oracle again instead of trusting old or manually written evidence.
-3. **Branch integration:** catches locally correct children that do not compose.
-
-The parent must use the same required toolchain and declared shell. If the environment differs, record and resolve the mismatch instead of accepting old evidence.
-
-## Manual gates
-
-Automation cannot prove every user-facing or judgment-heavy outcome. For each manual gate:
-
-- cite the exact artifact, location, measurement, or reviewer decision
-- review consequences, not only visual polish
-- obtain independent review for high-risk outcomes when feasible
-- keep the gate unmet if evidence is ambiguous
-
-Do not call a leaf `VERIFIED` merely because every runnable gate passed.
-
-## When not to orchestrate
-
-Stay solo when one focused context can implement and verify the task without hiding independent deliverables. Orchestration has planning and integration overhead; use it for attention isolation, not ceremony.

package/dist/skills/unlazy/references/parallel.md

@@ -1,111 +0,0 @@
-# Parallel pipelines and leaves
-
-Scopes and ownership leases coordinate cooperating unlazy processes. They prevent accidental cross-certification and refuse declared ownership overlap. They do not sandbox shell commands, enforce operating-system permissions, or stop a process that ignores the protocol from writing any file.
-
-## Layout
-
-```text
-.unlazy/
-  <scope>/
-    PLAN.md
-    GATES.md
-    gates/
-      leaf-*.md
-      node-*.md
-    status.log
-    dispatch.json
-  locks/
-```
-
-Keep `.unlazy/` untracked. The legacy single-pipeline layout, `GATES.md` plus `gates/*.md` at the project root, remains available for solo work.
-
-## Scope resolution
-
-A scoped checker invocation selects one pipeline in this order:
-
-1. `--scope <id>`
-2. `UNLAZY_SCOPE`
-3. the only scope present
-4. the legacy layout when no scoped pipeline exists
-
-When several scopes exist and none resolves, the checker refuses instead of running every ledger. Scope resolution is the only selector; there is no hook binding.
-
-Use scope ids that match `[A-Za-z0-9][A-Za-z0-9._-]{0,63}` and are not `.` or `..`. Do not use separators, traversal, or absolute paths.
-
-## What a scope isolates
-
-A scope limits unlazy's own:
-
-- default gate discovery
-- status log target
-- lease owner label
-
-A scope does not limit a `CHECK:` process. Checks inherit ambient operating-system access and can read or write outside the scope. Use separate worktrees or stronger process isolation when commands themselves must be isolated.
-
-## Ownership declarations
-
-Declare repository-relative paths before the first gate:
-
-```markdown
-OWNS: src/api/**, tests/api/**
-```
-
-Reject absolute paths and any path containing a `..` traversal segment. Every leaf dispatched concurrently must declare all paths it may modify and claim them before work:
-
-```text
-node <skill-dir>/scripts/gate-check.mjs --scope api --leaf leaf-1.2.1 --claim
-```
-
-Claiming checks all existing leases and writes the new lease while holding one global lease lock. Two simultaneous conflicting claims cannot both succeed. A claim is all-or-nothing.
-
-A scope/leaf label is itself exclusive while its lease exists. Repeating the same claim is refused; release that exact leaf before claiming it again. This prevents two workers dispatched with the same logical identity from both believing they own one lease.
-
-Lock directories contain JSON owner metadata. Unlazy deliberately does not auto-break an apparently stale lock, because deleting a live owner's path can let two successors enter at once. If a process dies while holding a lock, first verify that its recorded process is no longer running and that no unlazy operation could still own the lock, then remove only that specific abandoned lock manually. Never clear the whole lock directory while work is active. Approval-record locks use the same recovery rule.
-
-Overlap detection is deliberately conservative. It may reject two globs that a full intersection engine could prove disjoint, especially globs with mid-segment wildcards. It must not clear an uncertain pair as safe. Treat over-conflict as a prompt to use simpler disjoint paths or sequential dispatch.
-
-Examples:
-
-| First declaration | Second declaration | Result |
-|---|---|---|
-| `src/api/**` | `src/web/**` | disjoint |
-| `src/shared/**` | `src/shared/util.mjs` | conflict |
-| `src/a*.mjs` | `src/ab*.mjs` | conflict because intersection is possible |
-| `**` | `docs/**` | conflict |
-
-Leases cover only declared paths and only participants that honor them. They are coordination records, not write isolation.
-
-Release a leaf or whole scope after parent verification:
-
-```text
-node <skill-dir>/scripts/gate-check.mjs --scope api --release --leaf leaf-1.2.1
-node <skill-dir>/scripts/gate-check.mjs --scope api --release
-```
-
-An unknown `--leaf` is an error. The checker never silently falls back to the first ledger.
-
-## Concurrent ledger updates
-
-The checker serializes each gate-file update and commits it atomically. Before applying a completed check, it re-reads the ledger and confirms that the gate id and oracle fields still match what ran. If the command, expectation, working directory, or other bound oracle field changed in flight, the stale result is discarded.
-
-Preserve the ledger's original LF or CRLF style. Insert a missing evidence line without changing unrelated content. Keep result output deterministic in gate order even when `--jobs <N>` executes checks concurrently.
-
-The status log is append-only:
-
-```text
-node <skill-dir>/scripts/gate-check.mjs --scope api --log "leaf-1.2.1 verified"
-```
-
-Append-only logging reduces lost updates; it does not replace the live state fields in `PLAN.md`.
-
-## Per-session scope state
-
-Dispatch state and status logs are per-scope. Do not treat a session or run id as a secret or identity proof.
-
-## Choose the right isolation level
-
-- Use one working tree and several scopes for read-heavy work or leaves with simple disjoint ownership.
-- Use one worktree per pipeline when worktree-local output or generated files would collide. Configure separate cache directories when cache writes can conflict; worktrees do not isolate external caches or services.
-- Use operating-system or container isolation for untrusted commands. Unlazy approval and leases are not a sandbox.
-
-Parallelism changes wall-clock time, not the evidence standard. Parent re-verification and branch integration remain required.

package/dist/skills/unlazy/references/token-economy.md

@@ -1,39 +0,0 @@
-# Token economy
-
-Spend model attention on implementation and judgment. Move repeated, deterministic verification into commands and keep orchestration context narrow.
-
-## Keep enforcement cheap
-
-- **Use runnable checks.** External command execution does not itself require model inference. The agent still spends context on the command, returned output, failure interpretation, and evidence review.
-- **Cap evidence.** Store resolved environment facts plus the automatic output fingerprint, never raw successful output or a full build log.
-- **Keep enforcement cheap.** Verification is a resolved command, an exit status, and a fingerprint — not a transcript. A leaf is finished only when every gate is met and a final improvement pass finds nothing.
-- **Use sequential checks by default.** Raise `--jobs` only for independent checks when wall-clock savings justify harder failure diagnosis.
-
-## Keep contexts focused
-
-- Give a leaf the shared contract and its own ledger, not the driver's transcript or unrelated leaf outputs.
-- Keep `SKILL.md` limited to the core workflow. Load method, gate, orchestration, and parallel references only when the selected mode needs them.
-- Append events to `status.log`. Do not repeatedly regenerate a large plan when one line records the event.
-- Keep failure logs local and summarize only non-sensitive decisive facts when a manual report needs them; automatic success evidence already contains a digest and byte count.
-
-## Spend stronger reasoning on leverage points
-
-Use the strongest available review for:
-
-- contracts and architecture
-- security and compatibility boundaries
-- branch integration
-- manual high-risk gates
-- parent re-verification and final claim audit
-
-Use lower-cost execution for mechanical transformations only after the pattern and acceptance gates are fixed.
-
-## Avoid false economy
-
-Do not save time by skipping approval, negative controls, parent re-verification, or integration gates. Those checks exist because a fast false completion costs more than a direct failure.
-
-Do not orchestrate a task that one focused session can implement and verify cleanly. Conversely, do not keep an entire build in one context merely to avoid subagent overhead when independent leaves and contracts are clear.
-
-## Measurement claims
-
-Earlier unlazy documentation gave exact token and effort ratios from a six-run exploratory comparison. The raw prompts, traces, outputs, and scoring records are not present in this repository, so those numbers are not reproducible here. Do not use them as product guarantees. A protocol for a future reproducible rerun is in [../research/validation-protocol.md](../research/validation-protocol.md).

package/dist/skills/unlazy/research/validation-protocol.md

@@ -1,81 +0,0 @@
-# Validation protocol and historical limitations
-
-## Status of the historical six-run comparison
-
-The v2 design was informed by a maintainer-run exploratory comparison described in earlier README versions:
-
-- two build tasks
-- three conditions per task: no skill, tree 3, and tree 6
-- one fresh folder and session per condition
-- independent review, adversarial verification, and browser testing
-
-Earlier documentation reported output-token ratios, self-found defect counts, one live failure, and report-number errors. This repository does not contain the exact prompts, model and harness versions, transcripts, token logs, output repositories, reviewer forms, browser recordings, or calculation code for those six runs. The reported numbers therefore cannot be independently reproduced or audited from source.
-
-Treat the historical comparison as design provenance only. It is too small for broad model claims and must not be described as proof that unlazy causes a specific improvement or cost multiplier.
-
-## Minimum protocol for a reproducible rerun
-
-### 1. Pre-register the comparison
-
-Record before execution:
-
-- exact unlazy commit and condition definitions
-- task prompts and any shared input assets
-- agent product, model id, model snapshot if exposed, reasoning setting, and permissions
-- operating system, runtime versions, browser, package manager, and network policy
-- timeout, retry, and failure-handling rules
-- metrics, scoring rubric, reviewer instructions, and exclusion criteria
-- randomization order and the planned number of independent repetitions
-
-Use more than one run per task and condition. A single run in each cell cannot distinguish the condition from run-to-run variation.
-
-### 2. Isolate each run
-
-Use a fresh session and fresh working copy for every run. Give each condition the same task body, tool access, time limits, and environment except for the intervention being tested. Do not let artifacts or reviewer notes from one run become visible to another.
-
-Archive:
-
-- the exact initial prompt and every follow-up
-- full agent and tool transcript
-- starting and ending repository commits
-- dependency manifests and lockfiles
-- test, lint, build, and browser logs
-- screenshots or recordings required by the rubric
-- token and timing data as exported by the harness
-
-Redact credentials without altering outcome-relevant content. Publish checksums for every archived artifact.
-
-### 3. Define metrics operationally
-
-Avoid labels such as "effort" unless tied to a measured proxy. Define each metric so another reviewer can calculate it from the archive.
-
-Suggested measures:
-
-- requested acceptance outcomes met before the final answer
-- placeholder or deferred-work occurrences under a fixed search rule
-- test, build, console, and browser failures
-- defects found and fixed before delivery, with duplicate-defect rules
-- false completion claims in the final report
-- incorrect numeric claims, compared with a scripted measurement
-- input, cached-input, and output tokens as reported by the same harness
-- elapsed wall-clock time, including retries
-
-Keep checkpoint success distinct from end-to-end task completion.
-
-### 4. Blind and duplicate review
-
-Remove condition labels from review artifacts where possible. Use at least two independent reviewers for subjective criteria. Record disagreements and a resolution rule. Do not tell reviewers the expected direction of the result.
-
-Run objective checks from scripts pinned in the archive. For a negative assertion, include a known positive control that proves the assertion can fail.
-
-### 5. Publish calculations
-
-Provide a machine-readable row per run and a script that regenerates every table and chart. Report raw counts alongside ratios, uncertainty, exclusions, and missing data. Keep exploratory findings separate from pre-registered outcomes.
-
-### 6. Bound the conclusion
-
-Describe results for the tested models, snapshots, tasks, and environments. Do not generalize a small coding comparison to all agents or all substantial work. Record failures and null results as carefully as improvements.
-
-## Repository-level validation
-
-The current implementation has a separate deterministic test suite for parser, checker, lease, and portability behavior. Run it with the repository's documented test command. Those software tests validate implementation behavior; they do not validate broad claims about model psychology or task productivity.

package/dist/skills/unlazy/scripts/dispatch-check.mjs

@@ -1,108 +0,0 @@
-#!/usr/bin/env node
-// Records and checks the all-starts-before-wait dispatch contract. Node 16+.
-
-import { resolve } from "node:path";
-import { getDispatchWave, updateDispatch } from "./lib/dispatch.mjs";
-
-const COMMANDS = new Set(["open", "start", "seal", "return", "abandon", "status"]);
-const args = process.argv.slice(2);
-
-function usage() {
-  return [
-    "Usage:",
-    "  dispatch-check.mjs open --scope ID --wave ID --leaf ID [--leaf ID ...] [--root PATH]",
-    "  dispatch-check.mjs start --scope ID --wave ID --leaf ID --handle OPAQUE_ID [--root PATH]",
-    "  dispatch-check.mjs seal --scope ID --wave ID [--root PATH]",
-    "  dispatch-check.mjs return --scope ID --wave ID --leaf ID [--root PATH]",
-    "  dispatch-check.mjs abandon --scope ID --wave ID --reason TEXT [--root PATH]",
-    "  dispatch-check.mjs status --scope ID --wave ID [--root PATH]",
-  ].join("\n");
-}
-
-function die(message) {
-  const safe = String(message).replace(/[\u0000-\u001f\u007f]/g, " ").replace(/\s+/g, " ").trim().slice(0, 500);
-  console.error("unlazy dispatch: " + safe);
-  process.exit(2);
-}
-
-if (!args.length || args[0] === "--help" || args[0] === "-h") {
-  console.log(usage());
-  process.exit(args.length ? 0 : 2);
-}
-
-const command = args.shift();
-if (!COMMANDS.has(command)) die("unknown command " + command + "\n" + usage());
-
-const options = { root: process.cwd(), scope: null, wave: null, leaves: [], handle: null, reason: null };
-const single = new Set();
-while (args.length) {
-  const option = args.shift();
-  if (!["--root", "--scope", "--wave", "--leaf", "--handle", "--reason"].includes(option)) die("unknown option " + option);
-  if (!args.length || args[0].startsWith("--")) die(option + " requires a value");
-  const value = args.shift();
-  if (option === "--leaf") options.leaves.push(value);
-  else {
-    if (single.has(option)) die(option + " may be provided only once");
-    single.add(option);
-    options[option.slice(2)] = value;
-  }
-}
-
-if (!options.scope) die("--scope is required");
-if (!options.wave) die("--wave is required");
-options.root = resolve(options.root);
-
-if (command === "open") {
-  if (!options.leaves.length) die("open requires at least one --leaf");
-  if (options.handle !== null || options.reason !== null) die("open does not accept --handle or --reason");
-} else if (command === "start") {
-  if (options.leaves.length !== 1) die("start requires exactly one --leaf");
-  if (options.handle === null) die("start requires --handle");
-  if (options.reason !== null) die("start does not accept --reason");
-} else if (command === "return") {
-  if (options.leaves.length !== 1) die("return requires exactly one --leaf");
-  if (options.handle !== null || options.reason !== null) die("return does not accept --handle or --reason");
-} else if (command === "abandon") {
-  if (options.leaves.length || options.handle !== null) die("abandon does not accept --leaf or --handle");
-  if (options.reason === null || !options.reason.trim()) die("abandon requires --reason");
-} else if (options.leaves.length || options.handle !== null || options.reason !== null) {
-  die(command + " does not accept --leaf, --handle, or --reason");
-}
-
-const summary = (wave, id) => {
-  const started = Object.keys(wave.started).length;
-  const returned = Object.keys(wave.returned).length;
-  if (wave.state === "complete") return "COMPLETE " + id + " (" + returned + "/" + wave.leaves.length + " returned)";
-  if (wave.state === "abandoned") return "ABANDONED " + id + " (" + started + "/" + wave.leaves.length +
-    " started, " + returned + "/" + wave.leaves.length + " returned): " + wave.reason;
-  return wave.state.toUpperCase() + " " + id + " (" + started + "/" + wave.leaves.length +
-    " started, " + returned + "/" + wave.leaves.length + " returned)";
-};
-
-try {
-  if (command === "status") {
-    const wave = getDispatchWave(options.root, options.scope, options.wave);
-    console.log(summary(wave, options.wave));
-    process.exit(wave.state === "complete" ? 0 : 1);
-  }
-
-  const wave = await updateDispatch(options.root, {
-    action: command,
-    scope: options.scope,
-    wave: options.wave,
-    leaves: options.leaves,
-    leaf: options.leaves[0],
-    handle: options.handle,
-    reason: options.reason,
-  });
-  const started = Object.keys(wave.started).length;
-  const returned = Object.keys(wave.returned).length;
-  if (command === "open") console.log("OPEN " + options.wave + " (0/" + wave.leaves.length + " started, 0/" + wave.leaves.length + " returned)");
-  else if (command === "start") console.log("STARTED " + options.wave + " " + options.leaves[0] + " (" + started + "/" + wave.leaves.length + " started)");
-  else if (command === "seal") console.log("SEALED " + options.wave + " (" + started + "/" + wave.leaves.length + " started)");
-  else if (command === "abandon") console.log(summary(wave, options.wave));
-  else if (wave.state === "complete") console.log("COMPLETE " + options.wave + " (" + returned + "/" + wave.leaves.length + " returned)");
-  else console.log("RETURNED " + options.wave + " " + options.leaves[0] + " (" + returned + "/" + wave.leaves.length + " returned)");
-} catch (error) {
-  die(error.message);
-}