dream-beta-test · git:20260621.2f9d603 · 2026-06-21 · sha256 784f836556dc9198
dream-beta-test git:20260621.2f9d603A
Immutable. This exact content is served forever at /api/v1/blob/784f836556dc9198.
--- name: dream-beta-test description: >- Beta-test the consolidate-memory "dream" / memory-consolidation skill ITSELF: run the dream beta-harness against a repo and produce a structured, version-stamped defect report (the dream dashboard + a severity-ranked findings catalog that combines a deterministic invariant oracle with adversarial judgment lenses). Use this whenever the user wants to beta-test, QA, stress-test, audit, or find bugs/inconsistencies in the dream / consolidate-memory skill, run "dream-beta-test" or "the dream beta-harness", or validate a new consolidate-memory version against a repo. IMPORTANT: this is the TESTER, not the dream — do NOT trigger it on a normal request to "dream" / "consolidate my memory" / "checkpoint" / "save what you learned" (that is the skill UNDER test; use consolidate-memory for those). Honest by construction: confirmed defects and suspected ones are kept separate. --- # Dream beta-test Beta-test the **consolidate-memory "dream" skill** in a target repo and emit one structured, version-stamped report. You are the dream skill's **consumer / beta-tester** — you run it faithfully, instrument it, and report defects. **You never patch the dream skill** (nothing under its plugin dir); this tooling ships as the `dream-beta-tester` plugin — its scripts live under `$CLAUDE_PLUGIN_ROOT/scripts/` and you run them from there. The harness has two detectors and your job is to run **both**: 1. a **deterministic invariant oracle** (already built: `beta_checks.py`, driven by `run_beta.py`) that re-tests known defect **families** every run — the trustworthy floor; 2. the **judgment lenses** (this skill's contribution) that you apply by hand to *this* run's actual artifacts to catch **novel** defects the families don't encode — the dynamic half. Two properties make this worth doing, and everything below serves them: - **Dynamic, not overfit** — adapt to whatever *this* run surfaces; never just re-run a frozen checklist. The oracle re-tests known classes; the lenses find new ones. - **Honest** — a confident-wrong defect is worse than a missed one. The harness has already retracted two of its own hand-diagnoses, so **every finding is re-verified against source before it is called confirmed**, and suspected ones are quarantined, never counted. ## Flow ### 1 · Run the deterministic engine ``` python3 "$CLAUDE_PLUGIN_ROOT/scripts/run_beta.py" --repo <TARGET_REPO> --test --json ``` `--test` (default) restores the store afterward — a pure beta-test that leaves no mutation; default repo is cwd. The runner snapshots the store, runs the oracle (which drives the dream skill's **own read-only scripts** from a clean subprocess pinned to the target repo), renders a report to `reports/<slug>__<version>__<ts>.md`, diffs the store, and restores. Note the **consolidate-memory version under test** (stamped in the report header) and the report path. Read the rendered report. ### 2 · Confirm the oracle's findings — promote or downgrade Oracle WARN/FAIL findings land in the report's **§2a-FLAGGED** (oracle-flagged, unconfirmed). For each, open the **live** skill output it refers to and either: - **promote → §2a-VERIFIED**, quoting the exact contradicting line from the real `memory_status.py` / `render_dashboard.py` output; or - **downgrade**, if you cannot reproduce it. The oracle is a hypothesis too — re-firing a defect the skill has already FIXED is itself a harness bug, and saying so is the job. ### 3 · Apply the judgment lenses — the dynamic half Read `references/lenses.md` and apply each lens to *this* run's artifacts (the rendered dream dashboard + the oracle JSON + the live store). The lenses are constant; the findings are per-run. They exist to catch what the deterministic families don't: a novel inconsistency, a dishonest claim, an incoherent recommendation, an unsafe suggestion. ### 4 · Reduce every judgment finding before cataloging it A lens finding is a **suspicion, not a defect.** Quarantine it in **§2b (judgment-flagged, UNVERIFIED)** until it reduces to one of: - (a) a **reproducible deterministic check** — you can show the exact command + its output; or - (b) a **quoted source-contradiction** — you quote the skill's own output contradicting itself or reality. Only then promote it to **§2a-VERIFIED**. Whatever you cannot reduce stays in §2b, shipped explicitly as an unverified hypothesis for human triage — **never counted as a defect.** This single discipline is the skill's whole value; it is what keeps the catalog trustworthy. ### 5 · Write the findings in + present Augment the rendered report: fill §2a-VERIFIED (confirmed, with quotes) and §2b (unverified hypotheses). A **clean run is a clean report** — empty findings is a valid, good outcome; do not invent defects to fill space. Present the report path + a tight summary: *version under test · N confirmed · N unverified · the run-delta vs the prior report for this repo*. ### 6 · (Optional) Crystallize a confirmed novel class into a family If you confirmed a **novel, general** defect class (not an existing family, not a one-off), you may add it to `$CLAUDE_PLUGIN_ROOT/scripts/beta_checks.py` as a new `(Ctx) -> [Result]` family so every future run re-tests it deterministically — the harness gets smarter each run. Tie its PASS to the FIXED behavior so a real regression flips it. This is the only code you write, and only for the harness — never the dream skill. ## Hard rules - **Never patch the consolidate-memory skill.** You are its consumer/tester; surface defects in the report and let its author patch them. Writing into its plugin dir is out of scope. - **Any-repo.** Derive the slug; run the skill's scripts from `cwd = target repo` via a clean subprocess (the contamination root cause the harness exists to catch). `run_beta.py` already does this — if you run a skill script by hand, pass the target repo **positionally**. - **Reports** live under `~/.dream-beta-test/reports/` (a stable user dir, so they survive plugin updates and the orchestrator has a fixed `latest.json` path). Never write into the skill's dir. - This skill is the **tester**. A plain "dream / consolidate / checkpoint my memory" request is the skill **under test** — use `consolidate-memory`, not this. ## Depth The authoritative design is `$CLAUDE_PLUGIN_ROOT/docs/SPEC.md` (§4 detection · §5 flow · §6 report · §7 snapshot · §8 versioning). Read it when you need the *why* behind a step.