@deeeed/metamask-harness 0.46.0 → 0.47.0

package/site/architecture.html

@@ -144,7 +144,7 @@
 <section class="wrap">
   <h2 id="spec">The spec underneath</h2>
   <p>
-    <code>mm-harness</code> implements <strong>farmslot</strong>, a versioned specification for agentic
+    <code>mm-harness</code> implements <strong><a href="https://farmslot.io">Farmslot</a></strong>, a versioned specification for agentic
     proof work. The CLI is one implementation of it, not the thing itself.
   </p>
 
@@ -190,7 +190,7 @@
     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):
+  <div class="out">managed trust boundary (not needed for normal runs; <a href="https://farmslot.io">Farmslot</a> 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>
@@ -198,7 +198,7 @@
   <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
+      The <a href="https://farmslot.io">Farmslot</a> 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.

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/assets/help-recipes.mjs

@@ -0,0 +1,25 @@
+const root = document.querySelector('[data-help-recipes]');
+
+if (root) {
+  const response = await fetch(new URL('help-recipes.json', import.meta.url));
+  if (!response.ok) throw new Error(`Recipe help failed to load: ${response.status}`);
+  const topic = await response.json();
+  const code = document.createElement('code');
+  const lines = [
+    'Task: use the installed mm-harness for recipe-backed work. Follow these steps in order.',
+    topic.summary,
+    topic.capabilities,
+    topic.scopeNotice,
+  ];
+  for (const [index, section] of topic.sections.entries()) {
+    lines.push('', `${index + 1}. ${section.title}`, `   ${section.instruction}`);
+    for (const detail of section.details) lines.push(`   - ${detail}`);
+    for (const command of section.commands) lines.push(`   ${command}`);
+  }
+  lines.push('', `Safety: ${topic.safety}`);
+  code.textContent = lines.join('\n');
+  const pre = document.createElement('pre');
+  pre.append(code);
+  root.replaceChildren(pre);
+  document.dispatchEvent(new CustomEvent('mm-harness-content-rendered'));
+}

package/site/assets/progress.mjs

@@ -315,6 +315,8 @@
     initLayers();
   }
 
+  document.addEventListener('mm-harness-content-rendered', initCopy);
+
   if (document.readyState === 'loading') {
     document.addEventListener('DOMContentLoaded', init);
   } else {

package/site/ecosystem.html

@@ -75,7 +75,7 @@
     <div class="map-row">
       <article class="node">
         <span class="node-tag">Spec &amp; engine</span>
-        <h2 class="node-name">farmslot packages</h2>
+        <h2 class="node-name"><a href="https://farmslot.io">Farmslot</a> packages</h2>
         <p class="node-what">
           The recipe protocol and the execution engine, as pinned by mm-harness.
           <code>recipe-harness</code> depends on <code>protocol</code>.
@@ -138,7 +138,7 @@
   <div class="note">
     <span class="note-title">Standing disclosure</span>
     <p>
-      The farmslot <strong>control plane</strong> is experimental and sole-maintained. What is adopted
+      The <a href="https://farmslot.io">Farmslot</a> <strong>control plane</strong> is experimental and sole-maintained. What is adopted
       here is the spec and the engine — the npm packages above — not the control plane. Weigh that
       before depending on anything beyond them.
     </p>

package/site/how-it-works.html

@@ -194,6 +194,11 @@
       <div class="cmd"><pre><code><span class="p">$ </span>npm i -g @deeeed/metamask-harness@latest
 <span class="p">$ </span>mm-harness --version</code></pre></div>
 
+      <div class="note plain">
+        <span class="note-title">Why @deeeed?</span>
+        <p>Arthur publishes the pre-1.0 builds from his personal npm scope while MetaMask teams validate the workflows. Version 1.0 will move to a MetaMask-owned npm package.</p>
+      </div>
+
       <div class="out-label">Expected</div>
       <div class="out">0.34.x  <span class="dim">— any 0.34 or newer</span></div>
 

package/site/index.html

@@ -3,8 +3,8 @@
 <head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
-<title>Recipes — build with proof, not hope</title>
-<meta name="description" content="A skill drives the change. The recipe proves it on a real MetaMask build as it is written, self-checked in the same context and kept as a regression guard.">
+<title>The trust layer for MetaMask agentic development</title>
+<meta name="description" content="Skills encode MetaMask engineering workflows. Recipes prove the work against real builds, preserve the evidence, and remain as regression checks.">
 <link rel="icon" href="assets/metamask-fox.svg" type="image/svg+xml">
 <link rel="stylesheet" href="assets/style.css?v=4">
 </head>
@@ -14,12 +14,12 @@
 <main class="lobby">
   <div class="lobby-inner">
     <img class="lobby-mark" src="assets/metamask-fox.svg" alt="" width="52" height="52">
-    <span class="eyebrow">Proven as it's built</span>
+    <span class="eyebrow">Built for MetaMask engineering workflows</span>
 
-    <h1>Build agentically, with confidence.</h1>
+    <h1>The trust layer for agentic development.</h1>
     <p class="lobby-lede">
-      A skill drives the change. The recipe proves it on a real MetaMask build as it is written —
-      self-checked in the same context, then kept as a regression guard.
+      Skills encode MetaMask's engineering workflows. Recipes prove the work against real builds,
+      preserve the evidence, and remain as regression checks.
     </p>
     <p class="lobby-sub">
       Set up once, then work a real ticket.
@@ -86,9 +86,10 @@ instead of improvising.
    when listing: the default only prints stable skills, so the recipe skills
    below do not appear without it.
 8. Add the skills that drive recipe-backed work:
-     `yarn skills --include agentic/recipe-cook,agentic/recipe-quality,agentic/recipe-pr-qa-review --save`
-   They install as `mms-recipe-cook`, `mms-recipe-quality`, and
-   `mms-recipe-pr-qa-review`. They come from the `Consensys/skills` clone in
+     `yarn skills --include agentic/recipe-harness,agentic/recipe-cook,agentic/recipe-quality,agentic/recipe-performance,agentic/recipe-pr-qa-review,agentic/recipe-evidence --save`
+   They install as `mms-recipe-harness`, `mms-recipe-cook`, `mms-recipe-quality`,
+   `mms-recipe-performance`, `mms-recipe-pr-qa-review`, and
+   `mms-recipe-evidence`. They come from the `Consensys/skills` clone in
    step 7 and are marked experimental, which is why the explicit `--include`
    is required. If `yarn metamask-skills describe agentic/recipe-cook` cannot
    find it, check `CONSENSYS_SKILLS_DIR` points at that clone, then stop and
@@ -113,15 +114,17 @@ exact error.</code></pre></div>
 
         <div class="tabs">
           <div class="tablist" role="tablist" aria-label="Choose what to do" hidden>
-            <button type="button" role="tab" id="tab-review" class="tab" aria-controls="panel-review" aria-selected="true" tabindex="0">Review a PR</button>
-            <button type="button" role="tab" id="tab-fix" class="tab" aria-controls="panel-fix" aria-selected="false" tabindex="-1">Fix a bug</button>
+            <button type="button" role="tab" id="tab-fix" class="tab" aria-controls="panel-fix" aria-selected="true" tabindex="0">Fix a bug</button>
             <button type="button" role="tab" id="tab-build" class="tab" aria-controls="panel-build" aria-selected="false" tabindex="-1">Build a feature</button>
+            <button type="button" role="tab" id="tab-review" class="tab" aria-controls="panel-review" aria-selected="false" tabindex="-1">QA + Review PR</button>
+            <button type="button" role="tab" id="tab-performance" class="tab" aria-controls="panel-performance" aria-selected="false" tabindex="-1">Performance</button>
+            <button type="button" role="tab" id="tab-evidence" class="tab" aria-controls="panel-evidence" aria-selected="false" tabindex="-1">Pretty PR</button>
           </div>
 
           <div class="qs-panel" role="tabpanel" id="panel-review" aria-labelledby="tab-review" tabindex="0">
             <p class="qs-panel-why">
-              <code>mms-recipe-pr-qa-review</code> — read-only. It freezes the acceptance criteria
-              before it touches the runtime, validates each one on a real build, and returns a report.
+              <code>mms-recipe-pr-qa-review</code> runs full read-only QA and code-risk review. It
+              freezes the acceptance criteria before it touches the runtime, validates each one on a real build, and returns a report.
               It never edits product code and never posts to GitHub. The PR must be in the same
               product as your checkout.
             </p>
@@ -164,6 +167,55 @@ Plan the proof before you edit anything, implement it, then prove it with a
 recipe that drives the real build. Show me the recipe status, the per-node
 results, and the artifact paths.</code></pre></div>
           </div>
+
+          <div class="qs-panel" role="tabpanel" id="panel-performance" aria-labelledby="tab-performance" tabindex="0">
+            <p class="qs-panel-why">
+              <code>mms-recipe-performance</code> measures one real MetaMask flow with
+              evidence tied to the recipe run. It freezes the user journey and measurement boundaries,
+              keeps setup outside the measured window, and requires approval before any fix.
+            </p>
+            <div class="cmd"><pre><code>/mms-recipe-performance
+
+Measure this MetaMask flow:
+&lt;describe the exact user journey and suspected performance problem&gt;
+
+Propose the measured start and end, client, lifecycle state, environment,
+evidence sources, and failure threshold. Wait for my approval before measuring.
+Run one real-app baseline and return the recipe, trace, measurements, verdict,
+and artifact paths. Do not edit product code unless I approve a proven fix.
+If I approve one, rerun the identical recipe after the change.</code></pre></div>
+          </div>
+
+          <div class="qs-panel" role="tabpanel" id="panel-evidence" aria-labelledby="tab-evidence" tabindex="0">
+            <p class="qs-panel-why">
+              <code>mms-recipe-evidence</code> — the PR evidence skill. It first checks that every
+              claim has strong reviewable evidence, then turns the completed Recipe Cook task into
+              a clear, template-preserving PR description. Packaging is local; uploads and PR writes
+              require your separate approval.
+            </p>
+            <div class="cmd"><pre><code>From the MetaMask checkout, install the PR evidence skill if it is missing:
+  yarn skills --maturity experimental --include agentic/recipe-evidence --save
+
+Then run:
+  /mms-recipe-evidence
+
+Use the completed Recipe Cook task in this checkout. Before packaging, verify
+that every PR claim maps to executed recipe evidence. Inspect each selected
+screenshot or video and keep only the strongest reviewer-useful artifacts. If
+the proof is weak, missing, stale, or does not show the claimed result, stop and
+tell me what recipe or evidence must be rerun instead of polishing the PR.
+
+Once the evidence is good, preserve the repository PR template and build the
+cleanest reviewer-facing package. Show me pr-package/pr-desc.md, the selected
+screenshots or videos, proved claims, and honest gaps before doing anything
+external.
+
+Do not upload screenshots or create/update the PR until I approve that outward
+step. Warn me that uploaded screenshots go to a public evidence repository and
+may show wallet state. Never invent evidence or turn an incomplete run into a
+pass.</code></pre></div>
+          </div>
+
         </div>
       </div>
 

package/site/recipes.html

@@ -38,6 +38,12 @@
   </p>
 </section>
 
+<section class="wrap" id="agent-method">
+  <div class="cmd cmd-hero" data-help-recipes>
+    <pre><code>Loading version-matched recipe help…</code></pre>
+  </div>
+</section>
+
 <section class="wrap">
   <div class="doctrine">
     <p>
@@ -418,6 +424,7 @@
   </div>
 </footer>
 
+<script type="module" src="assets/help-recipes.mjs?v=1"></script>
 <script type="module" src="assets/progress.mjs?v=4"></script>
 </body>
 </html>

package/site/tutorials/v1.html

@@ -105,6 +105,10 @@
       <div class="cmd"><pre><code><span class="p">$ </span>npm i -g @deeeed/metamask-harness@latest
 <span class="p">$ </span>mm-harness --version</code></pre></div>
       <div class="out">0.34.x  <span class="dim">— any 0.34 or newer</span></div>
+      <div class="note plain">
+        <span class="note-title">Why @deeeed?</span>
+        <p>Arthur publishes the pre-1.0 builds from his personal npm scope while MetaMask teams validate the workflows. Version 1.0 will move to a MetaMask-owned npm package.</p>
+      </div>
     </li>
 
     <li class="step" data-step="doctor">