@deeeed/metamask-harness 0.47.0 → 0.47.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +21 -0
- package/adapters/mobile/bridge-runtime/lib/bridge-errors.cjs +15 -0
- package/dist/commands/tutorial.js +4 -4
- package/dist/mm-harness-cli.js +3 -3
- package/library/actions/mobile/perps/perps.mjs +41 -12
- package/library/actions/mobile/perps/set_market_favorite.mjs +0 -11
- package/library/actions/mobile/platform/bridge.mjs +6 -1
- package/library/actions/mobile/ui/native-navigation.mjs +9 -2
- package/library/actions/mobile/ui/navigate.mjs +13 -4
- package/library/manifests/mobile.action-manifest.json +1 -2
- package/package.json +2 -2
- package/site/assets/help-recipes.json +6 -1
- package/site/architecture.html +0 -497
- package/site/assets/help-recipes.mjs +0 -25
- package/site/assets/metamask-fox.svg +0 -24
- package/site/assets/progress.mjs +0 -325
- package/site/assets/style.css +0 -1066
- package/site/cheatsheet.html +0 -307
- package/site/ecosystem.html +0 -162
- package/site/how-it-works.html +0 -697
- package/site/index.html +0 -236
- package/site/perps-advanced-orders-qa.html +0 -96
- package/site/perps.html +0 -265
- package/site/recipes.html +0 -430
- package/site/reviewers.html +0 -375
- package/site/tutorials/index.html +0 -181
- package/site/tutorials/v1.html +0 -216
- package/site/tutorials/v2.html +0 -207
- package/site/tutorials/v3.html +0 -258
- package/site/tutorials/v4.html +0 -196
- package/site/tutorials/v5.html +0 -164
- package/site/tutorials/v6.html +0 -166
- package/site/tutorials/v7.html +0 -185
package/site/index.html
DELETED
|
@@ -1,236 +0,0 @@
|
|
|
1
|
-
<!DOCTYPE html>
|
|
2
|
-
<html lang="en">
|
|
3
|
-
<head>
|
|
4
|
-
<meta charset="utf-8">
|
|
5
|
-
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
6
|
-
<title>The trust layer for MetaMask agentic development</title>
|
|
7
|
-
<meta name="description" content="Skills encode MetaMask engineering workflows. Recipes prove the work against real builds, preserve the evidence, and remain as regression checks.">
|
|
8
|
-
<link rel="icon" href="assets/metamask-fox.svg" type="image/svg+xml">
|
|
9
|
-
<link rel="stylesheet" href="assets/style.css?v=4">
|
|
10
|
-
</head>
|
|
11
|
-
<body>
|
|
12
|
-
<a class="skip" href="#prompt">Skip to the prompt</a>
|
|
13
|
-
|
|
14
|
-
<main class="lobby">
|
|
15
|
-
<div class="lobby-inner">
|
|
16
|
-
<img class="lobby-mark" src="assets/metamask-fox.svg" alt="" width="52" height="52">
|
|
17
|
-
<span class="eyebrow">Built for MetaMask engineering workflows</span>
|
|
18
|
-
|
|
19
|
-
<h1>The trust layer for agentic development.</h1>
|
|
20
|
-
<p class="lobby-lede">
|
|
21
|
-
Skills encode MetaMask's engineering workflows. Recipes prove the work against real builds,
|
|
22
|
-
preserve the evidence, and remain as regression checks.
|
|
23
|
-
</p>
|
|
24
|
-
<p class="lobby-sub">
|
|
25
|
-
Set up once, then work a real ticket.
|
|
26
|
-
</p>
|
|
27
|
-
|
|
28
|
-
<section class="qs">
|
|
29
|
-
|
|
30
|
-
<div class="qs-step">
|
|
31
|
-
<h2 class="qs-title"><span class="qs-num" aria-hidden="true">1</span>Set up</h2>
|
|
32
|
-
<p class="qs-why">
|
|
33
|
-
One time per machine. Paste this into your agent inside a MetaMask checkout.
|
|
34
|
-
</p>
|
|
35
|
-
|
|
36
|
-
<div class="cmd cmd-hero" id="prompt"><pre><code>Task: set me up for recipe-backed work on MetaMask. Follow these steps in order.
|
|
37
|
-
When a command fails, its message names the exact next command — run that
|
|
38
|
-
instead of improvising.
|
|
39
|
-
|
|
40
|
-
1. Install the harness: `npm i -g @deeeed/metamask-harness@latest`, then
|
|
41
|
-
`mm-harness --version` to confirm it resolved.
|
|
42
|
-
2. Checkout: if I started you inside a MetaMask product checkout
|
|
43
|
-
(metamask-extension, metamask-mobile, or core), use it. If not, run
|
|
44
|
-
`mm-harness setup-base --dry-run` to show me the layout it would create,
|
|
45
|
-
and ask me before running it for real. Everything below runs from inside
|
|
46
|
-
the checkout.
|
|
47
|
-
3. Run `mm-harness doctor` and fix every finding by following its own
|
|
48
|
-
instructions until doctor passes. `mm-harness doctor --fix` repairs
|
|
49
|
-
harness-owned runtime state; it will not invent credentials or pick a
|
|
50
|
-
wallet fixture for me.
|
|
51
|
-
4. Run `mm-harness fixtures`. If no fixture exists, run
|
|
52
|
-
`mm-harness fixtures init --dev`; this creates a disposable public test
|
|
53
|
-
wallet that must never receive real funds.
|
|
54
|
-
5. Launch and wait for readiness:
|
|
55
|
-
- Extension: `mm-harness launch --verify`.
|
|
56
|
-
- Android: `mm-harness launch android --verify`; if more than one device is
|
|
57
|
-
listed, choose one serial and repeat it with `--device <serial>`.
|
|
58
|
-
- iOS: run `xcrun simctl list devices available`, choose ONE available iPhone
|
|
59
|
-
UUID (ask me if the choice is ambiguous), and use that literal UUID in all
|
|
60
|
-
three commands below — never substitute the simulator name:
|
|
61
|
-
`mm-harness provision runway ios --device '<UUID>' --force`
|
|
62
|
-
`xcrun simctl get_app_container '<UUID>' io.metamask.MetaMask app`
|
|
63
|
-
`mm-harness launch ios --device '<UUID>' --verify`
|
|
64
|
-
- Core: `mm-harness verify`; it has no app to launch.
|
|
65
|
-
`--preflight-mode` is an internal adapter flag, not a public launch flag.
|
|
66
|
-
6. On Extension run `mm-harness fixtures set`. On Mobile include the same
|
|
67
|
-
`--device <UUID-or-serial>` used for launch. Wait for it to succeed.
|
|
68
|
-
7. Install the skills — they are how the work actually gets driven. First
|
|
69
|
-
inspect `METAMASK_SKILLS_DIR` and `CONSENSYS_SKILLS_DIR`, then check the
|
|
70
|
-
expected local layout below. Reuse every valid existing clone. For each
|
|
71
|
-
missing source, show me the proposed path and ask before cloning:
|
|
72
|
-
`git clone https://github.com/MetaMask/skills.git ~/dev/metamask/skills`
|
|
73
|
-
`git clone git@github.com:Consensys/skills.git ~/dev/Consensys/skills`
|
|
74
|
-
The internal overlay needs access to the Consensys org. Export the paths in
|
|
75
|
-
the current shell for setup:
|
|
76
|
-
`export METAMASK_SKILLS_DIR=~/dev/metamask/skills`
|
|
77
|
-
`export CONSENSYS_SKILLS_DIR=~/dev/Consensys/skills`
|
|
78
|
-
Never edit `.zshrc`, `.bashrc`, or another shell startup file unless I
|
|
79
|
-
explicitly consent; ask separately if I want these exports persisted.
|
|
80
|
-
If that clone fails, tell me — I may not have access, and the next step
|
|
81
|
-
depends on it. Then, from inside the checkout:
|
|
82
|
-
`yarn metamask-skills list --maturity experimental` everything installable
|
|
83
|
-
`yarn skills` installs the stable set
|
|
84
|
-
`yarn skills` runs `metamask-skills sync` and is already wired in
|
|
85
|
-
metamask-extension, metamask-mobile, and core. Use `--maturity experimental`
|
|
86
|
-
when listing: the default only prints stable skills, so the recipe skills
|
|
87
|
-
below do not appear without it.
|
|
88
|
-
8. Add the skills that drive recipe-backed work:
|
|
89
|
-
`yarn skills --include agentic/recipe-harness,agentic/recipe-cook,agentic/recipe-quality,agentic/recipe-performance,agentic/recipe-pr-qa-review,agentic/recipe-evidence --save`
|
|
90
|
-
They install as `mms-recipe-harness`, `mms-recipe-cook`, `mms-recipe-quality`,
|
|
91
|
-
`mms-recipe-performance`, `mms-recipe-pr-qa-review`, and
|
|
92
|
-
`mms-recipe-evidence`. They come from the `Consensys/skills` clone in
|
|
93
|
-
step 7 and are marked experimental, which is why the explicit `--include`
|
|
94
|
-
is required. If `yarn metamask-skills describe agentic/recipe-cook` cannot
|
|
95
|
-
find it, check `CONSENSYS_SKILLS_DIR` points at that clone, then stop and
|
|
96
|
-
tell me. Do not substitute a different skill.
|
|
97
|
-
9. Run `mm-harness actions`. That list is the ONLY set of capabilities you may
|
|
98
|
-
use, now and in every later session — never invent an action or a flag. Then
|
|
99
|
-
stop and tell me setup is done.
|
|
100
|
-
|
|
101
|
-
Not optional, from here on: evidence comes only from executed actions — never
|
|
102
|
-
fabricate a result or edit state to manufacture one. If the harness reports a
|
|
103
|
-
capability as unsupported, stop and tell me rather than working around it. If a
|
|
104
|
-
step fails twice after following its error's instructions, stop and show me the
|
|
105
|
-
exact error.</code></pre></div>
|
|
106
|
-
</div>
|
|
107
|
-
|
|
108
|
-
<div class="qs-step">
|
|
109
|
-
<h2 class="qs-title"><span class="qs-num" aria-hidden="true">2</span>Do real work</h2>
|
|
110
|
-
<p class="qs-why">
|
|
111
|
-
Pick what you are doing. Each one runs the skill that owns that flow, and leaves a
|
|
112
|
-
rerunnable recipe behind as the proof.
|
|
113
|
-
</p>
|
|
114
|
-
|
|
115
|
-
<div class="tabs">
|
|
116
|
-
<div class="tablist" role="tablist" aria-label="Choose what to do" hidden>
|
|
117
|
-
<button type="button" role="tab" id="tab-fix" class="tab" aria-controls="panel-fix" aria-selected="true" tabindex="0">Fix a bug</button>
|
|
118
|
-
<button type="button" role="tab" id="tab-build" class="tab" aria-controls="panel-build" aria-selected="false" tabindex="-1">Build a feature</button>
|
|
119
|
-
<button type="button" role="tab" id="tab-review" class="tab" aria-controls="panel-review" aria-selected="false" tabindex="-1">QA + Review PR</button>
|
|
120
|
-
<button type="button" role="tab" id="tab-performance" class="tab" aria-controls="panel-performance" aria-selected="false" tabindex="-1">Performance</button>
|
|
121
|
-
<button type="button" role="tab" id="tab-evidence" class="tab" aria-controls="panel-evidence" aria-selected="false" tabindex="-1">Pretty PR</button>
|
|
122
|
-
</div>
|
|
123
|
-
|
|
124
|
-
<div class="qs-panel" role="tabpanel" id="panel-review" aria-labelledby="tab-review" tabindex="0">
|
|
125
|
-
<p class="qs-panel-why">
|
|
126
|
-
<code>mms-recipe-pr-qa-review</code> runs full read-only QA and code-risk review. It
|
|
127
|
-
freezes the acceptance criteria before it touches the runtime, validates each one on a real build, and returns a report.
|
|
128
|
-
It never edits product code and never posts to GitHub. The PR must be in the same
|
|
129
|
-
product as your checkout.
|
|
130
|
-
</p>
|
|
131
|
-
<div class="cmd"><pre><code>/mms-recipe-pr-qa-review https://github.com/MetaMask/metamask-mobile/pull/<number>
|
|
132
|
-
|
|
133
|
-
Extract the acceptance criteria from the PR yourself and freeze them before any
|
|
134
|
-
runtime work. Validate each one against the running build, then give me the
|
|
135
|
-
per-AC verdict table, the overall verdict, and the artifact paths. Do not post
|
|
136
|
-
anything on the PR.</code></pre></div>
|
|
137
|
-
</div>
|
|
138
|
-
|
|
139
|
-
<div class="qs-panel" role="tabpanel" id="panel-fix" aria-labelledby="tab-fix" tabindex="0">
|
|
140
|
-
<p class="qs-panel-why">
|
|
141
|
-
<code>mms-recipe-cook</code>, classified as <code>fix-bug</code>. It lists the
|
|
142
|
-
compatible checklist templates and stops for your pick, then works on a local task
|
|
143
|
-
branch. No product edits until the bug is proven to reproduce.
|
|
144
|
-
</p>
|
|
145
|
-
<div class="cmd"><pre><code>/mms-recipe-cook
|
|
146
|
-
|
|
147
|
-
Fix this in the checkout I started you in — treat it as fix-bug:
|
|
148
|
-
<paste the ticket, or the broken behaviour and how to reproduce it>
|
|
149
|
-
|
|
150
|
-
Reproduce it on the real build first and keep that failing run as the baseline.
|
|
151
|
-
Then fix it and re-run the same recipe until it passes. Show me the recipe
|
|
152
|
-
status, the per-node results, and the artifact paths.</code></pre></div>
|
|
153
|
-
</div>
|
|
154
|
-
|
|
155
|
-
<div class="qs-panel" role="tabpanel" id="panel-build" aria-labelledby="tab-build" tabindex="0">
|
|
156
|
-
<p class="qs-panel-why">
|
|
157
|
-
<code>mms-recipe-cook</code>, classified as <code>dev</code>. Same flow: it lists the
|
|
158
|
-
compatible templates, stops for your pick, and keeps the diff uncommitted until you
|
|
159
|
-
ask it to package the PR.
|
|
160
|
-
</p>
|
|
161
|
-
<div class="cmd"><pre><code>/mms-recipe-cook
|
|
162
|
-
|
|
163
|
-
Build this in the checkout I started you in — treat it as dev:
|
|
164
|
-
<paste the ticket, or the change you want>
|
|
165
|
-
|
|
166
|
-
Plan the proof before you edit anything, implement it, then prove it with a
|
|
167
|
-
recipe that drives the real build. Show me the recipe status, the per-node
|
|
168
|
-
results, and the artifact paths.</code></pre></div>
|
|
169
|
-
</div>
|
|
170
|
-
|
|
171
|
-
<div class="qs-panel" role="tabpanel" id="panel-performance" aria-labelledby="tab-performance" tabindex="0">
|
|
172
|
-
<p class="qs-panel-why">
|
|
173
|
-
<code>mms-recipe-performance</code> measures one real MetaMask flow with
|
|
174
|
-
evidence tied to the recipe run. It freezes the user journey and measurement boundaries,
|
|
175
|
-
keeps setup outside the measured window, and requires approval before any fix.
|
|
176
|
-
</p>
|
|
177
|
-
<div class="cmd"><pre><code>/mms-recipe-performance
|
|
178
|
-
|
|
179
|
-
Measure this MetaMask flow:
|
|
180
|
-
<describe the exact user journey and suspected performance problem>
|
|
181
|
-
|
|
182
|
-
Propose the measured start and end, client, lifecycle state, environment,
|
|
183
|
-
evidence sources, and failure threshold. Wait for my approval before measuring.
|
|
184
|
-
Run one real-app baseline and return the recipe, trace, measurements, verdict,
|
|
185
|
-
and artifact paths. Do not edit product code unless I approve a proven fix.
|
|
186
|
-
If I approve one, rerun the identical recipe after the change.</code></pre></div>
|
|
187
|
-
</div>
|
|
188
|
-
|
|
189
|
-
<div class="qs-panel" role="tabpanel" id="panel-evidence" aria-labelledby="tab-evidence" tabindex="0">
|
|
190
|
-
<p class="qs-panel-why">
|
|
191
|
-
<code>mms-recipe-evidence</code> — the PR evidence skill. It first checks that every
|
|
192
|
-
claim has strong reviewable evidence, then turns the completed Recipe Cook task into
|
|
193
|
-
a clear, template-preserving PR description. Packaging is local; uploads and PR writes
|
|
194
|
-
require your separate approval.
|
|
195
|
-
</p>
|
|
196
|
-
<div class="cmd"><pre><code>From the MetaMask checkout, install the PR evidence skill if it is missing:
|
|
197
|
-
yarn skills --maturity experimental --include agentic/recipe-evidence --save
|
|
198
|
-
|
|
199
|
-
Then run:
|
|
200
|
-
/mms-recipe-evidence
|
|
201
|
-
|
|
202
|
-
Use the completed Recipe Cook task in this checkout. Before packaging, verify
|
|
203
|
-
that every PR claim maps to executed recipe evidence. Inspect each selected
|
|
204
|
-
screenshot or video and keep only the strongest reviewer-useful artifacts. If
|
|
205
|
-
the proof is weak, missing, stale, or does not show the claimed result, stop and
|
|
206
|
-
tell me what recipe or evidence must be rerun instead of polishing the PR.
|
|
207
|
-
|
|
208
|
-
Once the evidence is good, preserve the repository PR template and build the
|
|
209
|
-
cleanest reviewer-facing package. Show me pr-package/pr-desc.md, the selected
|
|
210
|
-
screenshots or videos, proved claims, and honest gaps before doing anything
|
|
211
|
-
external.
|
|
212
|
-
|
|
213
|
-
Do not upload screenshots or create/update the PR until I approve that outward
|
|
214
|
-
step. Warn me that uploaded screenshots go to a public evidence repository and
|
|
215
|
-
may show wallet state. Never invent evidence or turn an incomplete run into a
|
|
216
|
-
pass.</code></pre></div>
|
|
217
|
-
</div>
|
|
218
|
-
|
|
219
|
-
</div>
|
|
220
|
-
</div>
|
|
221
|
-
|
|
222
|
-
</section>
|
|
223
|
-
|
|
224
|
-
<div class="lobby-cta">
|
|
225
|
-
<a class="btn btn-primary" href="how-it-works.html">How it works →</a>
|
|
226
|
-
</div>
|
|
227
|
-
|
|
228
|
-
<p class="lobby-fine">
|
|
229
|
-
A proposal for how agents can code at MetaMask — offered for teams to try.
|
|
230
|
-
</p>
|
|
231
|
-
</div>
|
|
232
|
-
</main>
|
|
233
|
-
|
|
234
|
-
<script type="module" src="assets/progress.mjs?v=4"></script>
|
|
235
|
-
</body>
|
|
236
|
-
</html>
|
|
@@ -1,96 +0,0 @@
|
|
|
1
|
-
<!DOCTYPE html>
|
|
2
|
-
<html lang="en">
|
|
3
|
-
<head>
|
|
4
|
-
<meta charset="utf-8">
|
|
5
|
-
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
6
|
-
<title>Mobile Pro advanced orders — QA walkthrough</title>
|
|
7
|
-
<meta name="description" content="Offline QA walkthrough and reusable mm-harness commands for Mobile Pro TWAP, Chase, and Scale orders.">
|
|
8
|
-
<link rel="icon" href="assets/metamask-fox.svg" type="image/svg+xml">
|
|
9
|
-
<link rel="stylesheet" href="assets/style.css?v=4">
|
|
10
|
-
</head>
|
|
11
|
-
<body>
|
|
12
|
-
<a class="skip" href="#checks">Skip to checks</a>
|
|
13
|
-
<header class="topbar">
|
|
14
|
-
<div class="wrap topbar-inner">
|
|
15
|
-
<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>
|
|
16
|
-
<nav class="nav" aria-label="Main">
|
|
17
|
-
<a class="nav-cta" href="index.html#prompt">Quick start</a>
|
|
18
|
-
<a href="how-it-works.html">How it works</a>
|
|
19
|
-
<a href="perps.html" aria-current="page">Team / Perps</a>
|
|
20
|
-
<a href="cheatsheet.html">Cheatsheet</a>
|
|
21
|
-
<a href="architecture.html">Architecture</a>
|
|
22
|
-
<a href="tutorials/index.html">Tutorials</a>
|
|
23
|
-
</nav>
|
|
24
|
-
</div>
|
|
25
|
-
</header>
|
|
26
|
-
<main>
|
|
27
|
-
<section class="wrap hero" style="padding-bottom:1rem">
|
|
28
|
-
<span class="eyebrow">Mobile Pro QA</span>
|
|
29
|
-
<h1>Advanced orders must remain observable</h1>
|
|
30
|
-
<p class="lede">Place TWAP, Chase, and Scale through visible Pro controls, then prove the resulting work remains available where a trader expects to monitor it.</p>
|
|
31
|
-
<div class="hero-meta"><span>Hyperliquid testnet</span><span>visible UI only</span><span>parameterized recipes</span></div>
|
|
32
|
-
</section>
|
|
33
|
-
|
|
34
|
-
<section class="wrap" id="checks">
|
|
35
|
-
<div class="note blue">
|
|
36
|
-
<span class="note-title">Safety boundary</span>
|
|
37
|
-
<p>Use a prepared fixture wallet with the three Mobile flags enabled. Omit <code>account</code> to keep the account already selected in MetaMask. Provider, network, and market use the recipe defaults; every recipe defaults to testnet. Mainnet requires an explicit user request; never infer it from context. Assertions preserve orders on either network, and placement preserves existing mainnet trading state. Do not use React state overrides, coordinate gestures, reloads, or background transitions to repair a failed proof.</p>
|
|
38
|
-
</div>
|
|
39
|
-
|
|
40
|
-
<h2>Preflight</h2>
|
|
41
|
-
<ol>
|
|
42
|
-
<li>Launch and verify the prepared Mobile slot with <code>mm-harness launch ios --verify --adapter mobile --target <mobile-checkout></code>.</li>
|
|
43
|
-
<li>Confirm the recipes appear in <code>mm-harness run --list --adapter mobile</code>.</li>
|
|
44
|
-
<li>Choose a funded testnet account and market, and pass explicit parameters when its safe ladder prices differ from the BTC defaults.</li>
|
|
45
|
-
<li>Let cleanup finish after every lane. Preserve the first failure and its trace.</li>
|
|
46
|
-
</ol>
|
|
47
|
-
|
|
48
|
-
<h2>TWAP: place, then monitor</h2>
|
|
49
|
-
<div class="cmd"><pre><code>mm-harness run perps.twap-place account=dev1 provider=hyperliquid network=testnet market=BTC side=long notional=110 randomize=false --adapter mobile
|
|
50
|
-
mm-harness run perps.twap-assert-active account=dev1 provider=hyperliquid network=testnet market=BTC --adapter mobile</code></pre></div>
|
|
51
|
-
<ol>
|
|
52
|
-
<li>The Advanced picker visibly offers TWAP.</li>
|
|
53
|
-
<li>The five-minute schedule is accepted and the form resets.</li>
|
|
54
|
-
<li>The TWAP tab opens on Active and shows a card for the selected market.</li>
|
|
55
|
-
</ol>
|
|
56
|
-
<p>A placement toast without an active card is a product failure: the schedule has vanished from the trader's monitoring surface. Mobile supports a 24-hour venue maximum; do not claim a seven-day duration, trigger price, or max price.</p>
|
|
57
|
-
|
|
58
|
-
<h2>Chase: survive a foreground dwell</h2>
|
|
59
|
-
<div class="cmd"><pre><code>mm-harness run perps.chase-place account=dev1 provider=hyperliquid network=testnet market=BTC side=long notional=100 max_distance=5000 --adapter mobile
|
|
60
|
-
mm-harness run perps.chase-assert-running account=dev1 provider=hyperliquid network=testnet market=BTC dwell_ms=12000 --adapter mobile
|
|
61
|
-
mm-harness run perps.chase-terminate account=dev1 provider=hyperliquid network=testnet market=BTC --adapter mobile</code></pre></div>
|
|
62
|
-
<ol>
|
|
63
|
-
<li>The Advanced picker visibly offers Chase and the form shows its foreground disclosure.</li>
|
|
64
|
-
<li>After placement, the Chase tab shows the market as Running.</li>
|
|
65
|
-
<li>The app remains foregrounded for the full dwell. The same row must still be visible afterward.</li>
|
|
66
|
-
<li>Terminate the session and confirm it leaves the active list.</li>
|
|
67
|
-
</ol>
|
|
68
|
-
<p>If the row disappears during the dwell, classify whether the trace shows product state loss, selector drift, harness transport failure, or a venue rejection. Do not claim force-kill conversion; Mobile's supported boundary is graceful foreground/background lifecycle handling.</p>
|
|
69
|
-
|
|
70
|
-
<h2>Scale: expose every child order</h2>
|
|
71
|
-
<div class="cmd"><pre><code>mm-harness run perps.scale-place account=dev1 provider=hyperliquid network=testnet market=BTC side=long notional=100 orders=3 skew=1 start_price=70000 end_price=75000 --adapter mobile
|
|
72
|
-
mm-harness run perps.scale-assert-orders account=dev1 provider=hyperliquid network=testnet market=BTC orders=3 --adapter mobile</code></pre></div>
|
|
73
|
-
<ol>
|
|
74
|
-
<li>The Advanced picker visibly offers Scale.</li>
|
|
75
|
-
<li>Start, end, order count, skew, and notional produce a visible preview before submission.</li>
|
|
76
|
-
<li>The standard Orders tab reports the requested count and shows the child entries as Limit orders.</li>
|
|
77
|
-
</ol>
|
|
78
|
-
<p>Partial venue acceptance is a failed full-ladder proof. This walkthrough does not claim group cancellation.</p>
|
|
79
|
-
|
|
80
|
-
<h2>Classify and report</h2>
|
|
81
|
-
<div class="table-scroll">
|
|
82
|
-
<table>
|
|
83
|
-
<thead><tr><th>Class</th><th>Evidence</th><th>Action</th></tr></thead>
|
|
84
|
-
<tbody>
|
|
85
|
-
<tr><td>Product defect</td><td>Bridge remains live; product selector/state disappears or venue-backed UI contradicts acceptance.</td><td>Record the first failing node, trace, screenshot, market, side, and elapsed time.</td></tr>
|
|
86
|
-
<tr><td>Recipe drift</td><td>Current product source or live tree establishes an intentional selector/flow change.</td><td>Repair the smallest node and rerun every caller.</td></tr>
|
|
87
|
-
<tr><td>Harness defect</td><td>A declared action violates its schema or reports a false verdict independent of product behavior.</td><td>Fix the harness and retain before/after proof.</td></tr>
|
|
88
|
-
<tr><td>Environment or venue</td><td>Fixture, funding, connectivity, capability, or exchange rejection prevents the product claim.</td><td>Fail closed and report the precise prerequisite; do not manufacture state.</td></tr>
|
|
89
|
-
</tbody>
|
|
90
|
-
</table>
|
|
91
|
-
</div>
|
|
92
|
-
</section>
|
|
93
|
-
</main>
|
|
94
|
-
<script type="module" src="assets/progress.mjs?v=4"></script>
|
|
95
|
-
</body>
|
|
96
|
-
</html>
|
package/site/perps.html
DELETED
|
@@ -1,265 +0,0 @@
|
|
|
1
|
-
<!DOCTYPE html>
|
|
2
|
-
<html lang="en">
|
|
3
|
-
<head>
|
|
4
|
-
<meta charset="utf-8">
|
|
5
|
-
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
6
|
-
<title>Team / Perps — customize the harness for your team</title>
|
|
7
|
-
<meta name="description" content="Every team points the harness at its own recipe library. The MetaMask Perps library is the worked example: recipes, actions, checklist templates, and the team's own knowledge.">
|
|
8
|
-
<link rel="icon" href="assets/metamask-fox.svg" type="image/svg+xml">
|
|
9
|
-
<link rel="stylesheet" href="assets/style.css?v=4">
|
|
10
|
-
</head>
|
|
11
|
-
<body>
|
|
12
|
-
<a class="skip" href="#setup">Skip to setup</a>
|
|
13
|
-
|
|
14
|
-
<header class="topbar">
|
|
15
|
-
<div class="wrap topbar-inner">
|
|
16
|
-
<a class="brand" href="index.html">
|
|
17
|
-
<img class="brand-mark" src="assets/metamask-fox.svg" alt="" width="22" height="22">
|
|
18
|
-
<span class="brand-name">recipes</span>
|
|
19
|
-
</a>
|
|
20
|
-
<nav class="nav" aria-label="Main">
|
|
21
|
-
<a class="nav-cta" href="index.html#prompt">Quick start</a>
|
|
22
|
-
<a href="how-it-works.html">How it works</a>
|
|
23
|
-
<a href="perps.html" aria-current="page">Team / Perps</a>
|
|
24
|
-
<a href="cheatsheet.html">Cheatsheet</a>
|
|
25
|
-
<a href="architecture.html">Architecture</a>
|
|
26
|
-
<a href="tutorials/index.html">Tutorials</a>
|
|
27
|
-
</nav>
|
|
28
|
-
</div>
|
|
29
|
-
</header>
|
|
30
|
-
|
|
31
|
-
<main>
|
|
32
|
-
<section class="wrap hero" style="padding-bottom:1rem">
|
|
33
|
-
<span class="eyebrow">Customization</span>
|
|
34
|
-
<h1>Make it your team's harness</h1>
|
|
35
|
-
<p class="lede">
|
|
36
|
-
The harness ships an execution standard and a deliberately small bundled library. Everything that
|
|
37
|
-
is specific to what <em>you</em> work on — the journeys, the assertions, the checklists, the review
|
|
38
|
-
knowledge — lives in a library you own and point the harness at. MetaMask Perps is the worked
|
|
39
|
-
example on this page.
|
|
40
|
-
</p>
|
|
41
|
-
<div class="hero-meta">
|
|
42
|
-
<span>per team</span>
|
|
43
|
-
<span>per engineer</span>
|
|
44
|
-
<span>one env var</span>
|
|
45
|
-
</div>
|
|
46
|
-
</section>
|
|
47
|
-
|
|
48
|
-
<section class="wrap" aria-labelledby="advanced-orders-qa">
|
|
49
|
-
<div class="note blue">
|
|
50
|
-
<span class="note-title" id="advanced-orders-qa">Mobile Pro advanced-order QA</span>
|
|
51
|
-
<p>
|
|
52
|
-
Validate TWAP monitoring, foreground Chase persistence, and Scale child orders with the
|
|
53
|
-
parameterized Mobile recipe family.
|
|
54
|
-
<a href="perps-advanced-orders-qa.html">Open the offline walkthrough</a>.
|
|
55
|
-
</p>
|
|
56
|
-
</div>
|
|
57
|
-
</section>
|
|
58
|
-
|
|
59
|
-
<section class="wrap">
|
|
60
|
-
<div class="doctrine">
|
|
61
|
-
<p>
|
|
62
|
-
<span class="k">The harness supplies the execution standard; your library supplies the domain.</span>
|
|
63
|
-
A team shares one library. An engineer can add their own on top. Neither requires a change to
|
|
64
|
-
the harness.
|
|
65
|
-
</p>
|
|
66
|
-
</div>
|
|
67
|
-
|
|
68
|
-
<h2>What lives where</h2>
|
|
69
|
-
<div class="table-scroll">
|
|
70
|
-
<table>
|
|
71
|
-
<thead><tr><th>Layer</th><th>Owns</th><th>Does not own</th></tr></thead>
|
|
72
|
-
<tbody>
|
|
73
|
-
<tr>
|
|
74
|
-
<td><code>mm-harness</code></td>
|
|
75
|
-
<td>Launch, typed actions, graph execution, screenshots, video, traces, and artifact contracts.</td>
|
|
76
|
-
<td>Anything specific to one team's domain.</td>
|
|
77
|
-
</tr>
|
|
78
|
-
<tr>
|
|
79
|
-
<td>Your library</td>
|
|
80
|
-
<td>Reusable setup, journeys, assertions, cleanup, platform variants, and checklist templates.</td>
|
|
81
|
-
<td>Wallet credentials, generated evidence, or product source.</td>
|
|
82
|
-
</tr>
|
|
83
|
-
<tr>
|
|
84
|
-
<td>Product checkout</td>
|
|
85
|
-
<td>The real Extension, Mobile, or Core code and runtime being proved.</td>
|
|
86
|
-
<td>A substitute test implementation.</td>
|
|
87
|
-
</tr>
|
|
88
|
-
</tbody>
|
|
89
|
-
</table>
|
|
90
|
-
</div>
|
|
91
|
-
</section>
|
|
92
|
-
|
|
93
|
-
<section class="wrap">
|
|
94
|
-
<h2 id="setup">Point the harness at a library</h2>
|
|
95
|
-
<p>
|
|
96
|
-
One environment variable does it. The Perps library is private, so start by asking its owners for
|
|
97
|
-
access — a clone failure means your GitHub account does not have it yet.
|
|
98
|
-
</p>
|
|
99
|
-
|
|
100
|
-
<div class="cmd"><pre><code><span class="p">$ </span>git clone git@github.com:MetaMask/experimental-metamask-recipe-perps.git \
|
|
101
|
-
"$HOME/shared-library/metamask-recipe-perps"
|
|
102
|
-
<span class="p">$ </span>export RECIPE_LIBRARY_PATH="perps=$HOME/shared-library/metamask-recipe-perps"
|
|
103
|
-
<span class="p">$ </span>mm-harness run --list</code></pre></div>
|
|
104
|
-
|
|
105
|
-
<p>
|
|
106
|
-
<code>name=path</code> gives the source its alias; without one the directory name is used. Separate
|
|
107
|
-
several libraries with <code>:</code> — order is precedence, first wins:
|
|
108
|
-
</p>
|
|
109
|
-
|
|
110
|
-
<div class="cmd"><pre><code><span class="p">$ </span>export RECIPE_LIBRARY_PATH="mine=$HOME/my-recipes:perps=$HOME/shared-library/metamask-recipe-perps"</code></pre></div>
|
|
111
|
-
|
|
112
|
-
<p>
|
|
113
|
-
Use <code>--library name=/path</code> for a single command instead — useful when a tool shell loses
|
|
114
|
-
an exported variable. Resolution follows your library order, then the bundled MetaMask library.
|
|
115
|
-
</p>
|
|
116
|
-
|
|
117
|
-
<div class="note blue">
|
|
118
|
-
<span class="note-title">Your own library, with no configuration</span>
|
|
119
|
-
<p>
|
|
120
|
-
A directory at <code>~/.farmslot/recipe-library</code> is picked up automatically as
|
|
121
|
-
<code>personal</code> when you set no library at all. It is a fallback, not an addition: as soon
|
|
122
|
-
as <code>RECIPE_LIBRARY_PATH</code> or <code>--library</code> is set, only those sources are used.
|
|
123
|
-
List it explicitly to keep both.
|
|
124
|
-
</p>
|
|
125
|
-
</div>
|
|
126
|
-
|
|
127
|
-
<div class="note blue">
|
|
128
|
-
<span class="note-title">Discovery is adapter-aware</span>
|
|
129
|
-
<p>
|
|
130
|
-
The list shows only recipes runnable in the current product checkout. A recipe marked
|
|
131
|
-
<code>[perps]</code> came from that library; <code>[metamask]</code> means it ships with the
|
|
132
|
-
harness. Read the selected platform variant with <code>--describe</code> before running it.
|
|
133
|
-
</p>
|
|
134
|
-
</div>
|
|
135
|
-
</section>
|
|
136
|
-
|
|
137
|
-
<section class="wrap">
|
|
138
|
-
<h2>What a team library actually holds</h2>
|
|
139
|
-
<p>
|
|
140
|
-
Every path below is real, from the Perps library. Copy the shape, not the contents — it is the
|
|
141
|
-
reference structure for a MetaMask team building its own.
|
|
142
|
-
</p>
|
|
143
|
-
|
|
144
|
-
<div class="cmd"><pre><code>manifests/extension.action-manifest.json types the actions you add
|
|
145
|
-
actions/extension/perps/ domain actions the product needs
|
|
146
|
-
recipes/mobile/perps/ per-adapter journeys
|
|
147
|
-
recipes/extension/perps/
|
|
148
|
-
recipes/core/perps/
|
|
149
|
-
checklists/dev/ your own Recipe Cook checklist templates
|
|
150
|
-
checklists/fix-bug/
|
|
151
|
-
docs/ the knowledge: authoring rules,
|
|
152
|
-
performance evidence, analytics</code></pre></div>
|
|
153
|
-
|
|
154
|
-
<p>
|
|
155
|
-
The <code>docs/</code> and <code>checklists/</code> directories are the part teams underestimate.
|
|
156
|
-
They are how a team's hard-won conventions — how performance evidence is gathered here, which
|
|
157
|
-
analytics events matter, what a finished task looks like — stop living in one engineer's head.
|
|
158
|
-
</p>
|
|
159
|
-
|
|
160
|
-
<div class="note">
|
|
161
|
-
<span class="note-title">Review knowledge lives with the skills</span>
|
|
162
|
-
<p>
|
|
163
|
-
One team surface sits outside the recipe library: the static antipattern packs the PR QA review
|
|
164
|
-
reads, which ship with the skills as
|
|
165
|
-
<code>references/antipatterns/<repo>/<pack>.md</code>. Today there is a
|
|
166
|
-
<code>perps</code> pack for Mobile, Extension, and Core, and a Mobile-only
|
|
167
|
-
<code>unit-vs-cv</code> pack. A pack is advisory: it never changes an acceptance-criterion
|
|
168
|
-
verdict.
|
|
169
|
-
</p>
|
|
170
|
-
</div>
|
|
171
|
-
</section>
|
|
172
|
-
|
|
173
|
-
<section class="wrap">
|
|
174
|
-
<h2>Your first live proof</h2>
|
|
175
|
-
<p>
|
|
176
|
-
Complete <a href="how-it-works.html#steps">the walkthrough</a> first so the app, device, and wallet fixture are
|
|
177
|
-
ready. With <code>RECIPE_LIBRARY_PATH</code> exported, the library's recipes are just names.
|
|
178
|
-
</p>
|
|
179
|
-
|
|
180
|
-
<h3>Extension or Mobile</h3>
|
|
181
|
-
<div class="cmd"><pre><code><span class="p">$ </span>mm-harness run perps.open-market --describe
|
|
182
|
-
<span class="p">$ </span>mm-harness run perps.open-market network=testnet market=BTC --plan
|
|
183
|
-
<span class="p">$ </span>mm-harness run perps.open-market network=testnet market=BTC \
|
|
184
|
-
--record-video=full-run --artifacts-dir ./perps-open-market-evidence</code></pre></div>
|
|
185
|
-
|
|
186
|
-
<h3>Core</h3>
|
|
187
|
-
<div class="cmd"><pre><code><span class="p">$ </span>mm-harness run perps.snapshot-market --describe
|
|
188
|
-
<span class="p">$ </span>mm-harness run perps.snapshot-market network=testnet market=BTC \
|
|
189
|
-
--artifacts-dir ./perps-market-evidence</code></pre></div>
|
|
190
|
-
|
|
191
|
-
<p>
|
|
192
|
-
A passing run writes <code>summary.json</code>, per-node results in <code>trace.json</code>, and an
|
|
193
|
-
artifact manifest beside screenshots or video. Visual review surfaces can render those same
|
|
194
|
-
recipe-derived artifacts without changing the proof graph.
|
|
195
|
-
</p>
|
|
196
|
-
</section>
|
|
197
|
-
|
|
198
|
-
<section class="wrap">
|
|
199
|
-
<h2>What the Perps team put in theirs</h2>
|
|
200
|
-
<p>
|
|
201
|
-
A sample of the library's recipes, as an idea of the granularity that works: small, parameterized,
|
|
202
|
-
composed rather than duplicated.
|
|
203
|
-
</p>
|
|
204
|
-
<div class="table-scroll">
|
|
205
|
-
<table>
|
|
206
|
-
<thead><tr><th>Claim</th><th>Recipe</th><th>Platforms</th></tr></thead>
|
|
207
|
-
<tbody>
|
|
208
|
-
<tr><td>Reach a live market detail screen</td><td><code>perps.open-market</code></td><td>Mobile, Extension</td></tr>
|
|
209
|
-
<tr><td>Read positions and orders</td><td><code>perps.snapshot-market</code></td><td>Mobile, Extension, Core</td></tr>
|
|
210
|
-
<tr><td>Place, assert, and clean up an order</td><td><code>perps.prove-order</code></td><td>Mobile, Extension, Core</td></tr>
|
|
211
|
-
<tr><td>Manage or close a position</td><td><code>perps.manage-position</code></td><td>Mobile, Extension, Core</td></tr>
|
|
212
|
-
<tr><td>Prove real MetaMetrics emissions</td><td><code>perps.analytics-lifecycle</code></td><td>Mobile, Extension</td></tr>
|
|
213
|
-
<tr><td>Measure the open-market journey</td><td><code>perps.performance-open-market</code></td><td>Mobile, Extension</td></tr>
|
|
214
|
-
<tr><td>Exercise edit-order contracts</td><td><code>perps.prove-edit-order</code></td><td>Core</td></tr>
|
|
215
|
-
</tbody>
|
|
216
|
-
</table>
|
|
217
|
-
</div>
|
|
218
|
-
|
|
219
|
-
<div class="note">
|
|
220
|
-
<span class="note-title">Mutation boundary</span>
|
|
221
|
-
<p>
|
|
222
|
-
Always run <code>--describe</code> and <code>--plan</code> before a state-changing recipe. The
|
|
223
|
-
library defaults to testnet and cleans up testnet state. Never turn an onboarding proof into a
|
|
224
|
-
mainnet mutation; mainnet operations require the recipe's explicit real-funds confirmation.
|
|
225
|
-
</p>
|
|
226
|
-
</div>
|
|
227
|
-
</section>
|
|
228
|
-
|
|
229
|
-
<section class="wrap">
|
|
230
|
-
<h2>Starting your team's library</h2>
|
|
231
|
-
<ol>
|
|
232
|
-
<li>Create a repository with the directory shape above. It holds no accounts, fixtures, credentials, or generated evidence.</li>
|
|
233
|
-
<li>Parameterize stable choices such as market, side, order type, and network.</li>
|
|
234
|
-
<li>Compose existing setup, assertion, and cleanup recipes before adding a new top-level recipe.</li>
|
|
235
|
-
<li>Add a platform variant only when the products genuinely differ.</li>
|
|
236
|
-
<li>
|
|
237
|
-
If a locator or screen assertion fails, classify it first. Intentional product change may mean
|
|
238
|
-
small recipe drift; otherwise preserve the failure and fix the product, runtime, or harness layer
|
|
239
|
-
that owns it.
|
|
240
|
-
</li>
|
|
241
|
-
<li>Re-run every caller after a shared node changes and attach the fresh evidence.</li>
|
|
242
|
-
</ol>
|
|
243
|
-
|
|
244
|
-
<p>
|
|
245
|
-
Keep it small. Compose or repair the closest recipe before creating another one — a library that
|
|
246
|
-
grows a scenario per ticket stops being maintainable faster than the product does.
|
|
247
|
-
</p>
|
|
248
|
-
|
|
249
|
-
<div class="btn-row">
|
|
250
|
-
<a class="btn btn-primary" href="tutorials/v3.html">Install skills and the library →</a>
|
|
251
|
-
<a class="btn btn-ghost" href="ecosystem.html">Where this sits in the stack</a>
|
|
252
|
-
<a class="btn btn-ghost" href="recipes.html">How recipes prove claims</a>
|
|
253
|
-
</div>
|
|
254
|
-
</section>
|
|
255
|
-
</main>
|
|
256
|
-
|
|
257
|
-
<footer class="footer">
|
|
258
|
-
<div class="wrap">
|
|
259
|
-
<p>Internal getting-started guide for proving MetaMask changes with recipes. Not official MetaMask product documentation.</p>
|
|
260
|
-
<p>Written against the shared MetaMask Perps recipe library. Sample output moves between releases; trust your terminal over this page.</p>
|
|
261
|
-
</div>
|
|
262
|
-
</footer>
|
|
263
|
-
<script type="module" src="assets/progress.mjs?v=4"></script>
|
|
264
|
-
</body>
|
|
265
|
-
</html>
|