@deeeed/metamask-harness 0.46.0 → 0.47.1

package/scripts/site-contrast.mjs

@@ -393,13 +393,17 @@ async function checkBehavior(browserEndpoint, port, pages) {
       ['yarn skills', copied.setup],
       ['/mms-recipe-pr-qa-review', copied.work.join('\n')],
       ['/mms-recipe-cook', copied.work.join('\n')],
+      ['/mms-recipe-performance', copied.work.join('\n')],
+      ['/mms-recipe-evidence', copied.work.join('\n')],
+      ['agentic/recipe-performance', copied.setup],
+      ['agentic/recipe-evidence', copied.setup],
     ];
     const missing = expected.filter(([line, text]) => !text?.includes(line)).map(([line]) => line);
     if (missing.length) {
       throw new Error(`copy prompt omitted ${missing.map((m) => `"${m}"`).join(', ')}`);
     }
-    if (copied.work.length < 3) {
-      throw new Error(`expected three work prompts, copied ${copied.work.length}`);
+    if (copied.work.length < 5) {
+      throw new Error(`expected five work prompts, copied ${copied.work.length}`);
     }
 
     // The landing page is the lobby: one prompt, one way onward, nothing else.

package/site/assets/help-recipes.json

@@ -0,0 +1,113 @@
+{
+  "schemaVersion": 1,
+  "topic": "recipes",
+  "title": "Recipe-backed work",
+  "summary": "Build an executable proof from the closest installed recipe, adapt it to the exact product version, and leave evidence another agent can replay.",
+  "capabilities": "Recipe uses: functional QA, visual checks, analytics and log assertions, and performance measurements during development, PR review, or release testing.",
+  "scopeNotice": "Current coverage: mm-harness is heavily optimized for Perps. Other teams can use it by adding composable recipes for their key journeys; contact Arthur for help.",
+  "recipeProtocolVersion": "1",
+  "sections": [
+    {
+      "id": "target",
+      "title": "Freeze the proof target",
+      "instruction": "Work inside one isolated MetaMask checkout. Name the exact product version and acceptance criteria, repair harness-owned state, then verify or launch that checkout.",
+      "details": [
+        "The tested build and current criteria are authoritative. A prior recipe pass is not current proof.",
+        "Choose state, visual, log, or mixed evidence for each criterion before authoring the graph."
+      ],
+      "commands": [
+        "mm-harness doctor --fix",
+        "mm-harness status --json"
+      ]
+    },
+    {
+      "id": "discover",
+      "title": "Discover the strongest starting point",
+      "instruction": "Search the installed recipe and action catalogs, inspect exact schemas, and select the closest recipe before writing anything new.",
+      "details": [
+        "A bundled recipe, including a Core recipe, is strong composable vocabulary, not authority for every future product version.",
+        "Prefer an existing recipe, then existing actions, then read-only CDP or controller inspection. Add shared vocabulary only after repeated need is proven."
+      ],
+      "commands": [
+        "mm-harness actions --json",
+        "mm-harness actions --action app.status --json",
+        "mm-harness run --list --json",
+        "mm-harness run runner.smoke --describe --json"
+      ]
+    },
+    {
+      "id": "parameters",
+      "title": "Design a parameterized contract",
+      "instruction": "Declare genuine caller choices once in paramsSchema and keep invariants required by the postcondition inside the recipe.",
+      "details": [
+        "Parameterize reusable differences such as market, account, provider, network, amount, side, or lifecycle mode.",
+        "Do not parameterize away safety, assertions, cleanup, or the meaning of success. Never depend on hidden wallet, account, provider, network, page, port, or device state."
+      ],
+      "commands": []
+    },
+    {
+      "id": "compose",
+      "title": "Compose a readable graph",
+      "instruction": "Use static call references for unchanged sub-journeys. Keep preparation, action, assertion, evidence, and guaranteed teardown visible as separate nodes with human-facing intent.",
+      "details": [
+        "Use idempotent ensure actions for required start state and independently assert their postconditions.",
+        "Actions translate stable UI, CDP, or controller operations. Recipes compose them. Product code owns business rules."
+      ],
+      "commands": []
+    },
+    {
+      "id": "author",
+      "title": "Build and prove one node at a time",
+      "instruction": "Probe each unfamiliar action with call or a tiny action-to-end recipe. Use read-only CDP inspection only when declared actions cannot reveal the needed authoring detail, then consolidate the final proof from manifest-declared actions.",
+      "details": [
+        "Plan after every structural change and preserve the first failing trace.",
+        "A CDP observation can help find the current route or selector; it is not final evidence unless the recipe records an allowed action and assertion for that signal."
+      ],
+      "commands": [
+        "mm-harness call app.status --json",
+        "mm-harness run ./proof.recipe.json --plan --json"
+      ]
+    },
+    {
+      "id": "branch",
+      "title": "Branch without hiding decisions",
+      "instruction": "Use switch for declared parameter choices. For runtime conditions, call an action that returns a finite declared case, then route every case to explicit assertions and a terminal result.",
+      "details": [
+        "Never template a call ref. Pass only declared child parameters and keep child output scoped to the call node.",
+        "Every success path must prove its postcondition. workflow.teardown must remain reachable after main success or failure."
+      ],
+      "commands": []
+    },
+    {
+      "id": "quality",
+      "title": "Run the whole proof and judge its quality",
+      "instruction": "Run the complete graph once into an explicit artifact directory, then apply the built-in quality bar before assigning coverage or a verdict.",
+      "details": [
+        "Coverage: every criterion needs an executable path and assertion; manual, untestable, and environment-dependent gaps stay explicit.",
+        "Graph: no unconditional pass, generic intent, hidden start state, or opaque node that collapses preparation, action, assertion, evidence, and teardown.",
+        "Evidence: inspect the recipe resolution, summary, trace, manifest, logs, and actual visual evidence. A filename or passing node is not visual proof.",
+        "Flake risk: wait on observable state instead of sleeping, keep device and runtime identity explicit, and never overwrite a prior run's artifacts.",
+        "Mutation: require an independent state assertion, identity-bound receipt, and guaranteed cleanup."
+      ],
+      "commands": [
+        "mm-harness run ./proof.recipe.json --artifacts-dir temp/recipe-proof --json",
+        "mm-harness last --json",
+        "mm-harness recipe-quality build --input recipe-quality-input.json --output recipe-quality.json --json"
+      ]
+    },
+    {
+      "id": "drift",
+      "title": "Repair drift and promote reusable learning",
+      "instruction": "When a shared recipe fails, reproduce once and classify product regression, recipe drift, fixture/runtime drift, harness defect, or live dependency before changing anything.",
+      "details": [
+        "The graph and evidence contract can be deterministic while the product, provider, account, or network outcome is not. Honest external rejection remains a valid result, not a reason to seek a green retry.",
+        "For product-version drift, preserve the failed trace, copy the composed recipe into the task, keep working nodes, and repair the smallest owning node against the tested build.",
+        "Prove the changed node in isolation, re-plan, then rerun the full task-local recipe and affected callers. Never weaken an assertion or change product code merely to turn stale proof green.",
+        "Record the source recipe digest, tested product identity, repair, and fresh evidence. If the defect belongs to reusable harness code or bundled vocabulary, prepare a focused experimental-metamask-harness issue and open it when authorized.",
+        "Promote a repair only after it works on the tested version and current main, or declare and enforce its compatibility boundary."
+      ],
+      "commands": []
+    }
+  ],
+  "safety": "Recipe parameters never bypass mutation consent or live-funds gates. Preserve valid live financial rejections exactly; never tune or retry merely to obtain a pass, and always run guaranteed cleanup."
+}

package/site/architecture.html

@@ -1,497 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-<head>
-<meta charset="utf-8">
-<meta name="viewport" content="width=device-width, initial-scale=1">
-<title>Architecture — how the pieces fit</title>
-<meta name="description" content="Skills, mm-harness, team recipe libraries, product repos: what lives where, the three workflows, and the mistakes newcomers make.">
-<link rel="icon" href="assets/metamask-fox.svg" type="image/svg+xml">
-<link rel="stylesheet" href="assets/style.css?v=4">
-</head>
-<body data-progress-page="architecture">
-<a class="skip" href="#stack">Skip to the stack map</a>
-
-<header class="topbar">
-  <div class="wrap topbar-inner">
-    <a class="brand" href="index.html">
-      <img class="brand-mark" src="assets/metamask-fox.svg" alt="" width="22" height="22">
-      <span class="brand-name">recipes</span>
-    </a>
-    <nav class="nav" aria-label="Main">
-      <a class="nav-cta" href="index.html#prompt">Quick start</a>
-      <a href="how-it-works.html">How it works</a>
-      <a href="perps.html">Team / Perps</a>
-      <a href="cheatsheet.html">Cheatsheet</a>
-      <a href="architecture.html" aria-current="page">Architecture</a>
-      <a href="tutorials/index.html">Tutorials</a>
-    </nav>
-  </div>
-</header>
-
-<main>
-<section class="wrap hero" style="padding-bottom:1rem">
-  <span class="eyebrow">The stack behind a recipe</span>
-  <h1>How the pieces fit together</h1>
-  <p class="lede">
-    The recipe is the unit of trust; the rest of the stack runs it. Four moving parts, two of which
-    people routinely confuse. What each layer is, where it lives, which workflow you are in, and the
-    mistakes that cost newcomers their first afternoon.
-  </p>
-</section>
-
-<section class="wrap">
-  <h2 id="model">The one-paragraph model</h2>
-  <div class="doctrine">
-    <p>
-      <span class="k">A recipe proves a task with actions.</span> Recipes are JSON graphs of typed
-      actions; <code>mm-harness</code> executes them against a real app and produces an evidence bundle
-      a reviewer can trust. <strong>Skills</strong> teach an agent a workflow — author a recipe, review
-      a PR, validate a release — and are the layer you work through; they call the harness, which runs
-      the recipe. <strong>Recipe libraries</strong> hold each team's recipes and domain actions.
-      Compose in that order, against the product repo under test.
-    </p>
-  </div>
-</section>
-
-<section class="wrap">
-  <h2 id="stack">The layers</h2>
-  <p>Click a layer to see what it is responsible for and when you touch it.</p>
-
-  <div class="stack">
-    <button type="button" class="layer" aria-expanded="false" aria-controls="l-skills">
-      <span class="layer-n">1</span>
-      <span class="layer-name">Skills</span>
-      <span class="layer-sub">the workflow an agent follows</span>
-    </button>
-    <div class="layer-detail" id="l-skills" hidden>
-      <p>
-        A packaged workflow — author a recipe from a criterion, review a pull request, validate a
-        release — turning "figure it out" into a procedure with gates you can steer.
-      </p>
-      <p>
-        Skills come from the public <code>MetaMask/skills</code> repo plus the internal
-        <code>Consensys/skills</code> overlay, which needs access to that org; private skills override
-        public ones on a name collision. Clone each, point <code>METAMASK_SKILLS_DIR</code> and
-        <code>CONSENSYS_SKILLS_DIR</code> at them, then install per checkout with
-        <code>yarn skills</code>. <strong>You do not need skills to run a recipe</strong>, only to have
-        an agent follow a proven workflow instead of improvising one.
-        <a href="tutorials/v3.html">V3 walks the install.</a>
-      </p>
-    </div>
-
-    <div class="arrow" aria-hidden="true">↓</div>
-
-    <button type="button" class="layer" aria-expanded="false" aria-controls="l-harness">
-      <span class="layer-n">2</span>
-      <span class="layer-name">mm-harness</span>
-      <span class="layer-sub">execution and evidence</span>
-    </button>
-    <div class="layer-detail" id="l-harness" hidden>
-      <p>
-        The CLI: launches the app, exposes the action vocabulary, executes recipe graphs against a real
-        build, writes the evidence. The only layer everyone needs, and the only one installed globally:
-      </p>
-      <div class="cmd"><pre><code><span class="p">$ </span>npm i -g @deeeed/metamask-harness@latest</code></pre></div>
-      <p style="margin-bottom:0">
-        It owns MetaMask runtime control and the domain capabilities; the generic graph engine and the
-        evidence schemas underneath it are separate packages it depends on.
-      </p>
-    </div>
-
-    <div class="arrow" aria-hidden="true">↓</div>
-
-    <button type="button" class="layer" aria-expanded="false" aria-controls="l-libs">
-      <span class="layer-n">3</span>
-      <span class="layer-name">Team recipe libraries</span>
-      <span class="layer-sub">your team's recipes and domain actions</span>
-    </button>
-    <div class="layer-detail" id="l-libs" hidden>
-      <p>
-        A team-owned repo of reusable recipes plus the domain actions they need. The harness ships a
-        bundled library so a fresh install can prove something immediately; your team's library is where
-        the recipes that matter to your work live.
-      </p>
-      <p>Libraries must be declared, or the harness only sees the bundled set:</p>
-      <div class="cmd"><pre><code><span class="p">$ </span>export RECIPE_LIBRARY_PATH="perps=$HOME/dev/my-recipe-library"
-<span class="p">$ </span>mm-harness run &lt;recipe&gt; --library perps=$HOME/dev/my-recipe-library</code></pre></div>
-      <p style="margin-bottom:0">
-        Each library carries its own setup notes — read those before running anything domain-specific.
-      </p>
-    </div>
-
-    <div class="arrow" aria-hidden="true">↓</div>
-
-    <button type="button" class="layer" aria-expanded="false" aria-controls="l-product">
-      <span class="layer-n">4</span>
-      <span class="layer-name">Product repos</span>
-      <span class="layer-sub">the thing under test</span>
-    </button>
-    <div class="layer-detail" id="l-product" hidden>
-      <p>
-        <code>metamask-extension</code>, <code>metamask-mobile</code>, and <code>core</code>. Recipes
-        execute against a real build, never a mock. Run <code>mm-harness</code> from inside the checkout
-        and it detects the product, ports, and runtime paths.
-      </p>
-      <p style="margin-bottom:0">
-        They differ, and the harness says so rather than pretending otherwise: Core is headless with
-        nothing to launch and no UI actions; Extension and iOS can record full-run video; Android
-        replay video is not implemented yet, so use screenshot evidence there.
-      </p>
-    </div>
-  </div>
-</section>
-
-<section class="wrap">
-  <h2 id="spec">The spec underneath</h2>
-  <p>
-    <code>mm-harness</code> implements <strong>farmslot</strong>, a versioned specification for agentic
-    proof work. The CLI is one implementation of it, not the thing itself.
-  </p>
-
-  <div class="stack">
-    <div class="layer layer-static">
-      <span class="layer-n">1</span>
-      <span class="layer-name">The specification</span>
-      <span class="layer-sub">recipes, action manifests, observations and traces, evidence, handoff</span>
-    </div>
-    <div class="arrow" aria-hidden="true">↓</div>
-    <div class="layer layer-static">
-      <span class="layer-n">2</span>
-      <span class="layer-name">mm-harness implements it</span>
-      <span class="layer-sub">for MetaMask products</span>
-    </div>
-    <div class="arrow" aria-hidden="true">↓</div>
-    <div class="layer layer-static">
-      <span class="layer-n">3</span>
-      <span class="layer-name">Skills drive it</span>
-      <span class="layer-sub">the workflows an agent follows</span>
-    </div>
-  </div>
-
-  <p>Schemas are published and versioned. Every recipe carries the URL it validates against:</p>
-  <div class="out">"$schema": <a href="https://farmslot.io/schemas/recipe-v1.schema.json">"https://farmslot.io/schemas/recipe-v1.schema.json"</a></div>
-  <p>
-    Action manifests carry <code>action-manifest-v1</code>; evidence records its own
-    <code>schemaVersion</code> and <code>runner_protocol_version</code>. Versioning is what keeps a
-    bundle readable by tooling written after it was produced.
-  </p>
-
-  <h3>Why the spec is the scaling mechanism</h3>
-  <p>
-    The recipe you run from the CLI is the same artifact a control plane dispatches to a worker,
-    monitors, and gates — dispatch, worker, self-review, human gate, publication, each step speaking
-    these contracts. Evidence returns in the same shape either way, so a fleet result is reviewable by
-    whoever wrote the recipe. Parity is structural: one spec, both sides.
-  </p>
-  <p>
-    That is what makes the trust layer scale. A proof written once becomes a permanent guard: it is
-    replayed by whoever changes that code next, it stays readable as evidence no matter who or what ran
-    it, and the bug it was written for cannot quietly return. Review does not get weaker as volume
-    grows.
-  </p>
-  <p>The seam shows in the CLI's own help — the flags a control plane supplies:</p>
-  <div class="out">managed trust boundary (not needed for normal runs; Farmslot supplies it):
-  --source-trust, --source-kind, --source-name, --source-digest,
-  <span class="hint">--approve-plan</span> (binds approval to the exact reviewed plan)</div>
-  <p>Approve a plan and only that plan runs — which is what keeps the gate a gate.</p>
-
-  <div class="note">
-    <span class="note-title">What you actually need</span>
-    <p>
-      The farmslot control plane is <strong>experimental and sole-maintained</strong>. Nothing this site
-      teaches requires it — the harness, recipes, and skills are complete on their own, and the CLI says
-      as much: those flags are "not needed for normal runs". The specification is what you adopt; the
-      control plane is one consumer of it.
-    </p>
-  </div>
-</section>
-
-<section class="wrap">
-  <h2 id="loop">The improvement loop</h2>
-  <p>
-    A recipe guards the regression it was written for. This is how a team catches the ones nobody has
-    written down yet — each run leaving the next one better informed.
-  </p>
-
-  <div class="doctrine">
-    <p>
-      <span class="k">Learnings are written, not collected.</span> The checklist an agent follows carries
-      a step instructing it to write what it learned as human-readable markdown, bundled beside the
-      execution plan and the evidence. A run ends with prose — what was hard, what surprised it, what
-      the next run should know — sitting next to the proof. A deliverable, not telemetry: nobody mines
-      traces for insight; the agent is asked and answers.
-    </p>
-  </div>
-
-  <h3>The chain</h3>
-  <div class="stack">
-    <div class="layer layer-static">
-      <span class="layer-n">1</span>
-      <span class="layer-name">A checklist step asks for learnings</span>
-      <span class="layer-sub">part of the execution plan</span>
-    </div>
-    <div class="arrow" aria-hidden="true">↓</div>
-    <div class="layer layer-static">
-      <span class="layer-n">2</span>
-      <span class="layer-name">The run writes learnings.md beside its evidence</span>
-      <span class="layer-sub">prose, in the run artifacts</span>
-    </div>
-    <div class="arrow" aria-hidden="true">↓</div>
-    <div class="layer layer-static">
-      <span class="layer-n">3</span>
-      <span class="layer-name">Curation promotes the durable ones</span>
-      <span class="layer-sub">a human decides what generalises</span>
-    </div>
-    <div class="arrow" aria-hidden="true">↓</div>
-    <div class="layer layer-static">
-      <span class="layer-n">4</span>
-      <span class="layer-name">They become team knowledge</span>
-      <span class="layer-sub">in the library, beside the recipes</span>
-    </div>
-    <div class="arrow" aria-hidden="true">↓</div>
-    <div class="layer layer-static">
-      <span class="layer-n">5</span>
-      <span class="layer-name">The next run loads it before acting</span>
-      <span class="layer-sub">discovery, not recall</span>
-    </div>
-  </div>
-
-  <p>
-    Step 3 is a person on purpose: a run produces plenty of true-but-local detail, and promoting all of
-    it buries what matters — the same judgement as deciding what belongs in a code comment.
-  </p>
-
-  <div class="note blue">
-    <span class="note-title">Where learnings collect</span>
-    <p>
-      Scrubbed packages from approved runs land in
-      <code>MetaMask/experimental-distributed-learnings</code>, a private append-only inbox — the same
-      repository as <code>experimental-agentic-learnings</code>, which was its earlier name and still
-      redirects. Capture records the observation, review later decides whether it warrants a proposal,
-      and proposals go to whichever repo owns the affected layer. Sharing is opt-in: without a local
-      <code>learning.config.json</code> a run stages locally and publishes nothing. Packages are
-      date-partitioned and the indexes are scaffolded, but only one day of runs has landed so far —
-      collection is beginning, so treat it as the destination rather than a corpus to read today.
-    </p>
-  </div>
-
-  <h3>What works today</h3>
-
-  <div class="table-scroll">
-    <table>
-      <thead><tr><th>Mechanism</th><th>Its part in the loop</th></tr></thead>
-      <tbody>
-        <tr>
-          <td>The evidence bundle</td>
-          <td>Produces the raw material. <code>diagnostics.json</code> in particular is where side findings land — application warnings and errors captured during the run, kept out of the verdict precisely so they survive as observations rather than being flattened into pass or fail.</td>
-        </tr>
-        <tr>
-          <td>Team recipe libraries</td>
-          <td>The place shared understanding accumulates. A recipe that encodes "get to a clean market first" <em>is</em> a piece of team knowledge, already reusable by everyone who declares the library.</td>
-        </tr>
-        <tr>
-          <td><code>mm-harness recipe-quality</code></td>
-          <td>Turns a review's verdicts into a quality artifact, so an assessment of a proof is itself a durable record rather than a comment that scrolls away.</td>
-        </tr>
-        <tr>
-          <td><code>mm-harness execution-template</code></td>
-          <td>Discovers, validates, and materialises shared agent checklists — a curated procedure written once and picked up by everyone, which is the loop working at the level of process.</td>
-        </tr>
-        <tr>
-          <td>Skills</td>
-          <td>The same idea for workflows. A skill is a procedure someone got right, packaged so nobody has to rediscover it.</td>
-        </tr>
-      </tbody>
-    </table>
-  </div>
-
-  <h3>Where this is heading</h3>
-  <p>
-    The gap is the middle of the loop: recipes and actions have a home in a team library; the sharper
-    things a run teaches you do not yet. Worth capturing:
-  </p>
-
-  <ul>
-    <li><strong>Gotchas</strong> — the non-obvious precondition that cost someone an afternoon, written down once.</li>
-    <li><strong>Screen maps</strong> — how a surface is actually reached and identified in the current build, so the next author is not re-deriving it.</li>
-    <li><strong>Flakes</strong> — the step known to be intermittent, with what is known about when and why, so an author can distinguish a real failure from a familiar one.</li>
-  </ul>
-
-  <p>
-    The intended shape is the one proven everywhere else here: <strong>discovery rather than
-    recall</strong>. Just as you ask the checkout what actions exist, you would ask what is already
-    known about a surface before authoring against it — a <code>knowledge</code> surface alongside
-    <code>actions</code> and <code>run --list</code>, resolving the way libraries already do, layered
-    most-specific-wins: yours, your team's, the workflow's, then defaults shipping with the harness
-    release so tool facts cannot drift out of date in a document nobody re-reads.
-  </p>
-
-  <p>
-    Entries stay small and curated: a short index of what exists and when to load it, topic files under
-    a size cap, each entry carrying a stable id and the same symptom → cause → what to do shape the
-    error messages use. Promotion happens through an ordinary reviewed pull request, so a human is in
-    the loop by construction.
-  </p>
-
-  <div class="note">
-    <span class="note-title">Being straight about status</span>
-    <p style="margin-bottom:0">
-      <strong>Not shipping yet.</strong> There is no <code>knowledge</code> command today, which is why
-      you will not find one in a copyable block on this page. Meanwhile the useful part is unblocked:
-      keep what your runs teach you in the library repo beside the recipes. Tooling makes it
-      discoverable later; writing it down is what makes it exist.
-    </p>
-  </div>
-
-  <div class="doctrine">
-    <p>
-      <span class="k">The skills teach the workflow; the knowledge teaches the product.</span> Runs
-      produce learnings, curation promotes them, discovery serves them to every run after.
-    </p>
-  </div>
-</section>
-
-<section class="wrap">
-  <h2 id="libraries">Where everything lives</h2>
-  <div class="table-scroll">
-    <table>
-      <thead><tr><th>What</th><th>Is</th><th>You need it when</th></tr></thead>
-      <tbody>
-        <tr>
-          <td><code>@deeeed/metamask-harness</code><br><span style="color:var(--text-faint);font-size:.85rem">the <code>mm-harness</code> CLI, on npm</span></td>
-          <td>The execution engine and evidence producer: <code>doctor</code>, <code>launch</code>, <code>actions</code>, <code>call</code>, <code>run</code>, <code>last</code>.</td>
-          <td><strong>Always.</strong> Install and update with <code>npm i -g @deeeed/metamask-harness@latest</code>.</td>
-        </tr>
-        <tr>
-          <td><code>Consensys/skills</code><br><span style="color:var(--text-faint);font-size:.85rem">internal repo</span></td>
-          <td>Agentic skills — recipe authoring, PR QA review, release validation. Installed into a checkout via that repo's tooling.</td>
-          <td>When you want an agent to follow a proven workflow instead of improvising one.</td>
-        </tr>
-        <tr>
-          <td>Team recipe libraries<br><span style="color:var(--text-faint);font-size:.85rem">e.g. the perps and money-movement libraries</span></td>
-          <td>Team-owned recipes, domain actions, and domain knowledge. Declared with <code>RECIPE_LIBRARY_PATH</code> or <code>--library</code>.</td>
-          <td>When running or authoring anything domain-specific. <a href="tutorials/v3.html#steps">V3 walks the setup</a> with the perps library as the worked example.</td>
-        </tr>
-        <tr>
-          <td>Product repos<br><span style="color:var(--text-faint);font-size:.85rem">extension · mobile · core</span></td>
-          <td>The thing under test. The harness runs against a real checkout and a real build.</td>
-          <td><strong>Always</strong> — there is nothing to prove without one.</td>
-        </tr>
-      </tbody>
-    </table>
-  </div>
-</section>
-
-<section class="wrap">
-  <h2 id="workflows">The three workflows — pick one, do not blend them</h2>
-  <p>Most confusion here is someone doing two at once. They need different setup and fail differently.</p>
-
-  <div class="grid grid-3">
-    <div class="card">
-      <h3>1 · Run an existing recipe</h3>
-      <p style="color:var(--text-dim);font-size:.92rem">No skills needed. This is the majority of daily use.</p>
-      <div class="cmd"><pre><code><span class="p">$ </span>mm-harness update
-<span class="p">$ </span>cd &lt;product checkout&gt;
-<span class="p">$ </span>export RECIPE_LIBRARY_PATH=&lt;name=path&gt;
-<span class="p">$ </span>mm-harness doctor
-<span class="p">$ </span>mm-harness launch
-<span class="p">$ </span>mm-harness run &lt;recipe&gt; \
-    --artifacts-dir ./out</code></pre></div>
-      <p style="margin-bottom:0;font-size:.92rem">Evidence lands in the artifacts dir. That is the whole workflow.</p>
-    </div>
-
-    <div class="card">
-      <h3>2 · Author a recipe</h3>
-      <p style="color:var(--text-dim);font-size:.92rem">For a specific acceptance criterion. Skills earn their keep here.</p>
-      <p style="font-size:.92rem">
-        Install the recipe-authoring skill. It discovers the vocabulary with
-        <code>mm-harness actions</code> — <strong>the discovered list is law, action names are never
-        invented</strong> — composes the graph, validates it with <code>run --plan</code>, then runs it
-        for real.
-      </p>
-      <p style="margin-bottom:0;font-size:.92rem">
-        Expect one honest failure-and-fix loop. That is the error messages doing their job.
-      </p>
-    </div>
-
-    <div class="card">
-      <h3>3 · Review a PR / validate a release</h3>
-      <p style="color:var(--text-dim);font-size:.92rem">Requires the QA skills.</p>
-      <p style="font-size:.92rem">
-        Give the skill one PR URL. It extracts the acceptance criteria verbatim — missing ones become a
-        hygiene finding, never an invented criterion — waits for you to confirm or edit the table, runs
-        the proof on a real device, and produces a per-criterion verdict with evidence paths.
-      </p>
-      <p style="margin-bottom:0;font-size:.92rem">
-        A criterion the surface genuinely cannot prove is reported as needing a human, not quietly
-        passed.
-      </p>
-    </div>
-  </div>
-
-  <div class="note blue">
-    <span class="note-title">Why "do not blend them" is a real instruction</span>
-    <p>
-      Running a recipe needs no skills; reviewing a PR does. Install everything and ask an agent to
-      "just handle it" and you get an agent choosing between procedures with no basis to pick. Name the
-      workflow you are in.
-    </p>
-  </div>
-</section>
-
-<section class="wrap">
-  <h2 id="mistakes">The five mistakes every newcomer makes</h2>
-
-  <ol style="padding-left:1.2rem">
-    <li style="margin-bottom:1rem">
-      <strong>Asking the agent to figure it all out from one sentence.</strong> The skills <em>are</em>
-      the figured-out part. Name the workflow you want; do not make the agent guess which of the three
-      you are in.
-    </li>
-    <li style="margin-bottom:1rem">
-      <strong>A stale harness.</strong> This one costs the most afternoons. The CLI ships often and
-      recipes assume current behaviour. Run <code>mm-harness update</code> before you debug anything
-      that "used to work".
-    </li>
-    <li style="margin-bottom:1rem">
-      <strong>Not declaring the library.</strong> Without <code>RECIPE_LIBRARY_PATH</code> (or
-      <code>--library</code>) the harness only sees bundled recipes — so your team's recipe appears not
-      to exist, and the error is telling the literal truth.
-    </li>
-    <li style="margin-bottom:1rem">
-      <strong>Skipping <code>doctor</code>.</strong> It tells you exactly what is missing and the exact
-      command that fixes it. Every error in this stack carries a <code>Next:</code> action. Read them —
-      that is the whole design.
-    </li>
-    <li>
-      <strong>Blending the workflows.</strong> See above. Mixing "run a recipe" with "review a PR"
-      confuses the agent and produces work you then have to check by hand.
-    </li>
-  </ol>
-
-  <hr class="sep">
-  <h2>Which repo is which</h2>
-  <p>
-    The layers above are the design. The <a href="ecosystem.html">Ecosystem map</a> is the concrete
-    version: the six repositories and packages behind a run, each with its URL, and which way the
-    dependencies point.
-  </p>
-
-  <div class="btn-row">
-    <a class="btn btn-primary" href="ecosystem.html">See the repo map →</a>
-    <a class="btn btn-ghost" href="how-it-works.html#steps">Do the walkthrough</a>
-    <a class="btn btn-ghost" href="reviewers.html">Read an evidence bundle</a>
-  </div>
-</section>
-</main>
-
-<footer class="footer">
-  <div class="wrap">
-    <p>Internal getting-started guide for proving MetaMask changes with recipes. Not official MetaMask product documentation.</p>
-    <p>Sample output moves between releases; trust your terminal over this page.</p>
-  </div>
-</footer>
-
-<script type="module" src="assets/progress.mjs?v=4"></script>
-</body>
-</html>