@marcomigozzi/trailhead 0.12.1 → 0.14.0

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.
Files changed (66) hide show
  1. package/README.it.md +38 -13
  2. package/README.md +48 -13
  3. package/bin/lib/codex-projection.js +18 -11
  4. package/bin/lib/codex-projection.test.js +39 -11
  5. package/bin/lib/install-verify.js +10 -5
  6. package/bin/lib/install-verify.test.js +51 -0
  7. package/bin/trailhead.js +37 -25
  8. package/bin/trailhead.test.js +162 -5
  9. package/package.json +4 -1
  10. package/plugins/trailhead/.claude-plugin/plugin.json +3 -2
  11. package/plugins/trailhead/commands/panel.md +10 -0
  12. package/plugins/trailhead/hooks/hooks.json +3 -18
  13. package/plugins/trailhead/hooks/lib/body-sources.js +795 -0
  14. package/plugins/trailhead/hooks/lib/gh-subcommand.js +92 -10
  15. package/plugins/trailhead/hooks/lib/gh-subcommand.test.js +55 -0
  16. package/plugins/trailhead/hooks/lib/mockup-link.js +21 -5
  17. package/plugins/trailhead/hooks/lib/shell-scan.js +496 -64
  18. package/plugins/trailhead/hooks/lib/shell-scan.test.js +420 -0
  19. package/plugins/trailhead/hooks/lib/unmodelled.js +345 -0
  20. package/plugins/trailhead/hooks/lib/unmodelled.test.js +173 -0
  21. package/plugins/trailhead/hooks/lib/work-state.test.js +252 -0
  22. package/plugins/trailhead/hooks/mod/README.md +187 -0
  23. package/plugins/trailhead/hooks/mod/map-pane-view.ts +453 -0
  24. package/plugins/trailhead/hooks/mod/map-pane.tsx +663 -0
  25. package/plugins/trailhead/hooks/mod/register.tsx +280 -0
  26. package/plugins/trailhead/hooks/mod/work-state-prompt.ts +69 -0
  27. package/plugins/trailhead/hooks/mod/work-state-view.ts +93 -0
  28. package/plugins/trailhead/hooks/trailhead-bash-guards.js +140 -0
  29. package/plugins/trailhead/hooks/trailhead-bash-guards.test.js +233 -0
  30. package/plugins/trailhead/hooks/trailhead-body-guard.js +145 -61
  31. package/plugins/trailhead/hooks/trailhead-body-guard.test.js +224 -3
  32. package/plugins/trailhead/hooks/trailhead-commit-guard.js +41 -14
  33. package/plugins/trailhead/hooks/trailhead-commit-guard.test.js +2 -1
  34. package/plugins/trailhead/hooks/trailhead-install-guard.js +22 -12
  35. package/plugins/trailhead/hooks/trailhead-install-guard.test.js +2 -1
  36. package/plugins/trailhead/hooks/trailhead-mockup-link-guard.js +48 -11
  37. package/plugins/trailhead/hooks/trailhead-mockup-link-guard.test.js +79 -7
  38. package/plugins/trailhead/hooks/trailhead-mockup-link-stop.test.js +1 -1
  39. package/plugins/trailhead/hooks/trailhead-search-guard.js +19 -9
  40. package/plugins/trailhead/hooks/trailhead-search-guard.test.js +2 -1
  41. package/plugins/trailhead/hooks/trailhead-secret-guard.js +541 -57
  42. package/plugins/trailhead/hooks/trailhead-secret-guard.test.js +1000 -4
  43. package/plugins/trailhead/hooks/trailhead-secret-read-guard.js +171 -6
  44. package/plugins/trailhead/hooks/trailhead-secret-read-guard.test.js +170 -0
  45. package/plugins/trailhead/skills/_shared/choices.md +3 -1
  46. package/plugins/trailhead/skills/_shared/configuration-reference.md +5 -4
  47. package/plugins/trailhead/skills/_shared/configuration.md +1 -1
  48. package/plugins/trailhead/skills/_shared/multi-map.md +1 -1
  49. package/plugins/trailhead/skills/_shared/session-handoff.md +1 -1
  50. package/plugins/trailhead/skills/_shared/teamwork.md +4 -2
  51. package/plugins/trailhead/skills/_shared/techniques/acceptance-testing.md +1 -1
  52. package/plugins/trailhead/skills/_shared/techniques/prototype.md +15 -16
  53. package/plugins/trailhead/skills/_shared/techniques.md +1 -1
  54. package/plugins/trailhead/skills/trailhead/SKILL.md +2 -2
  55. package/plugins/trailhead/skills/trailhead-work/SKILL.md +3 -2
  56. package/plugins/trailhead/skills/trailhead-work/references/auto.md +2 -0
  57. package/plugins/trailhead/skills/trailhead-work/references/ticket-engines.md +3 -1
  58. package/plugins/trailhead/templates/trailhead-work-state.js +199 -0
  59. package/plugins/trailhead/tests/map-pane-ui.test.ts +1374 -0
  60. package/plugins/trailhead/tests/map-pane-view.test.ts +565 -0
  61. package/plugins/trailhead/tests/mod.test.ts +14 -0
  62. package/plugins/trailhead/tests/work-state-prompt-hook.test.ts +207 -0
  63. package/plugins/trailhead/tests/work-state-prompt.test.ts +109 -0
  64. package/plugins/trailhead/tests/work-state-ui.test.ts +365 -0
  65. package/plugins/trailhead/tests/work-state-view.test.ts +86 -0
  66. package/plugins/trailhead/types/index.d.ts +69 -0
@@ -44,6 +44,32 @@
44
44
  // are shared with trailhead-search-guard.js via lib/shell-scan.js, so the two
45
45
  // guards can never drift into two divergent tokenizers again.
46
46
  //
47
+ // #214 fix: a secret read inside a command substitution was missed when the
48
+ // substitution sat in double quotes (`echo "$(cat .env)"`, `x="$(cat .env)"`,
49
+ // `echo "$(true; cat .env)"`): the quoted token hid it, and the splitter cut
50
+ // inside the `$(..)`. Each outermost `$(..)` / `<(..)` / `>(..)` body (from
51
+ // substitutionBodies in lib/shell-scan.js) is now also scanned as a command,
52
+ // off a depth- and size-capped work-list.
53
+ //
54
+ // #216 fix: the same miss for backtick substitutions (`echo "`cat .env`"`,
55
+ // `x="`cat .env`"`, `echo "${x:-`cat .env`}"`). scanLine now tracks a backtick
56
+ // span and substitutionBodies returns its body (unescaped as the shell would
57
+ // run it) alongside the `$(..)` ones, so the work-list scans it too.
58
+ //
59
+ // #218 fix: the same miss for a substitution in the body of an UNQUOTED heredoc
60
+ // (`cat <<EOF` with `$(cat .env)` or a backtick inside): the shell runs it, but
61
+ // heredoc bodies are data to the splitter and were never lexed. Each unquoted
62
+ // body is now lexed as the shell reads one (heredocSubstitutionBodies: quotes
63
+ // are literal there) and its outermost substitution bodies join the work-list.
64
+ // A quoted delimiter (`<<'EOF'`) and an escaped `\$(..)` stay literal.
65
+ //
66
+ // #223 fix: a heredoc body fed to a shell interpreter on stdin (`bash <<'EOF'`,
67
+ // `sh <<EOF`, `cat <<EOF | bash`) is a script the shell runs, whatever the
68
+ // delimiter quoting, but bodies were only ever data. Each statement is now paired
69
+ // with its own bodies by position (as trailhead-secret-guard.js does); when a
70
+ // statement of its pipeline invokes a shell from a closed set, those bodies join
71
+ // the work-list as commands. No wrappers (sudo, exec, nohup): out of scope.
72
+ //
47
73
  // #180 fix: `docker`/`podman` `--env-file .env` (or `--env-file=.env`) was a
48
74
  // false positive: the container RUNTIME reads that file, not the agent. Only
49
75
  // that flag's value is exempted, and only for docker/podman verbs; see
@@ -60,6 +86,14 @@
60
86
  // a link prepared under a non-secret name onto `.env`
61
87
  // (`ln -s .env.example l && mv l .env`).
62
88
  //
89
+ // #227: a construct the guard cannot interpret with certainty (eval, source / `.`, a
90
+ // bash 5.3 `${ cmd; }`, printf -v, a function definition, an alias, a quoted gh api body
91
+ // key, a backslash-newline inside a word) is not emulated. As a FINAL gate, after the
92
+ // precise scan, one that sits next to a secret-looking piece (`.env`, `.e""nv`, ...)
93
+ // denies with SECRET_READ_UNMODELLED_CONSTRUCT and asks for the simple form; with no
94
+ // such piece (`. venv/bin/activate && make`) it passes. The closed list is
95
+ // lib/unmodelled.js.
96
+ //
63
97
  // Deliberately best-effort on the Bash leg, like the sibling guards: not a
64
98
  // full shell parser. It does not care about `cd` shape at all (that is
65
99
  // trailhead-search-guard.js's job) — it only asks "does any token here
@@ -76,7 +110,12 @@
76
110
  const {
77
111
  basename,
78
112
  stripQuotes,
79
- splitStatements,
113
+ splitStatementsWithSeparators,
114
+ countHeredocs,
115
+ skipEnvPrefix,
116
+ substitutionBodies,
117
+ heredocBodies,
118
+ heredocSubstitutionBodies,
80
119
  tokenize,
81
120
  SEARCH_VERB_CONFIG,
82
121
  scanArgsSkippingPattern,
@@ -391,6 +430,47 @@ function scanStatementForSecretPath(stmt) {
391
430
  return scanTokensForSecretPath(tokens, exempt, nameOnlyTokenIndices(bin, tokens));
392
431
  }
393
432
 
433
+ // #214: substitution bodies are scanned off an explicit work-list (no
434
+ // recursion, so no stack overflow) under a cap on nesting depth and on the
435
+ // total bytes of bodies scanned. Past the cap the remaining text is checked
436
+ // crudely instead (see crudeSecretToken): the guard fails toward blocking.
437
+ const MAX_SUB_DEPTH = 32;
438
+ const MAX_SUB_BYTES = 64 * 1024;
439
+ const CRUDE_SPLIT_RE = /[\s"'`()$;|&<>{}=]+/;
440
+
441
+ // Fallback when the cap is hit: split the unscanned text on whitespace, quotes,
442
+ // parens and operators, and return the first piece that is a secret path.
443
+ function crudeSecretToken(text) {
444
+ for (const piece of text.split(CRUDE_SPLIT_RE)) {
445
+ if (piece && isSecretPathArg(piece)) return piece;
446
+ }
447
+ return null;
448
+ }
449
+
450
+ // #223: shells that read a script from stdin (closed set, no wrappers).
451
+ const STDIN_SCRIPT_INTERPRETERS = new Set(['bash', 'sh', 'zsh', 'dash', 'ksh']);
452
+ // Reserved words that may precede the command word (no grouping, no wrappers).
453
+ const LEADING_KEYWORDS = new Set(['then', 'do', 'else', 'time', '!']);
454
+ // `env` options whose value is the next token (separate form, no `=`).
455
+ const ENV_VALUE_OPTIONS = new Set(['-u', '-C', '--unset', '--chdir']);
456
+
457
+ // True when the statement runs one of those shells: after leading NAME=value
458
+ // assignments, an optional `env` (with its NAME=value and -option words), the
459
+ // command word's basename is in the set. Flags after it do not matter.
460
+ function invokesInterpreter(stmt) {
461
+ const tokens = tokenize(stmt);
462
+ let i = 0;
463
+ while (i < tokens.length && LEADING_KEYWORDS.has(tokens[i])) i++;
464
+ i += skipEnvPrefix(tokens.slice(i));
465
+ if (i < tokens.length && basename(stripQuotes(tokens[i])) === 'env') {
466
+ i++;
467
+ while (i < tokens.length && (/^[A-Za-z_][A-Za-z0-9_]*=/.test(tokens[i]) || tokens[i].startsWith('-'))) {
468
+ i += ENV_VALUE_OPTIONS.has(tokens[i]) ? 2 : 1;
469
+ }
470
+ }
471
+ return i < tokens.length && STDIN_SCRIPT_INTERPRETERS.has(basename(stripQuotes(tokens[i])));
472
+ }
473
+
394
474
  // Walk the command's top-level statements (quote-aware; `|`, `;`, `&&`,
395
475
  // `||`, and newlines all split, even with no surrounding whitespace, e.g.
396
476
  // `cat .env|grep KEY`) looking for a secret path used as a plain positional,
@@ -398,10 +478,80 @@ function scanStatementForSecretPath(stmt) {
398
478
  // (quotes/punctuation not necessarily stripped) or null. Best-effort: not a
399
479
  // full shell parser.
400
480
  function scanBashForSecretPath(cmd) {
401
- const statements = splitStatements(cmd);
402
- for (const stmt of statements) {
403
- const hit = scanStatementForSecretPath(stmt);
404
- if (hit) return hit;
481
+ const work = [{ text: String(cmd), depth: 0 }];
482
+ let bytes = 0;
483
+ for (let w = 0; w < work.length; w++) {
484
+ const { text, depth } = work[w];
485
+ if (depth > 0) bytes += text.length;
486
+ if (depth > MAX_SUB_DEPTH || bytes > MAX_SUB_BYTES) {
487
+ const hit = crudeSecretToken(text);
488
+ if (hit) return hit;
489
+ continue;
490
+ }
491
+ const bodies = heredocBodies(text);
492
+ const entries = splitStatementsWithSeparators(text);
493
+ let next = 0;
494
+ const pushed = new Set(); // bodies already scanned whole as commands
495
+ let pipe = []; // consecutive statements joined by `|`
496
+ const flush = () => {
497
+ if (pipe.some((p) => invokesInterpreter(p.text))) {
498
+ for (const doc of pipe.flatMap((p) => p.docs)) {
499
+ work.push({ text: doc.body, depth: depth + 1 });
500
+ pushed.add(doc);
501
+ }
502
+ }
503
+ pipe = [];
504
+ };
505
+ for (const entry of entries) {
506
+ const hit = scanStatementForSecretPath(entry.text);
507
+ if (hit) return hit;
508
+ const docs = bodies.slice(next, next + countHeredocs(entry));
509
+ next += docs.length;
510
+ pipe.push({ text: entry.text, docs });
511
+ if (entry.sep !== '|') flush();
512
+ }
513
+ flush();
514
+ // #214: a statement cut inside `"$(..)"` loses the closing context, and a
515
+ // double-quoted token hides its body from the per-token walk; scan each
516
+ // outermost substitution body as a command of its own (nested ones next).
517
+ for (const body of substitutionBodies(text)) work.push({ text: body, depth: depth + 1 });
518
+ // #218: an unquoted heredoc body is data to the splitter, but the shell runs
519
+ // the substitutions in it; a quoted delimiter makes the body literal.
520
+ // (#223: a body already pushed whole as a command needs no second push.)
521
+ for (const doc of bodies) {
522
+ if (doc.quoted || pushed.has(doc)) continue;
523
+ for (const body of heredocSubstitutionBodies(doc.body)) work.push({ text: body, depth: depth + 1 });
524
+ }
525
+ }
526
+ return null;
527
+ }
528
+
529
+ // --- unmodelled constructs (#227) ----------------------------------------------
530
+
531
+ // Does a text hold a secret-looking piece once live backslash-newlines are joined and
532
+ // quote characters dropped (`.e""nv` is `.env` to the shell)? Crude by design: the
533
+ // precise scan above is exact and runs first, this only has to catch what it cannot see.
534
+ function crudeSecretPiece(text) {
535
+ return crudeSecretToken(String(text).replace(/\\\n/g, '').replace(/["'`]/g, ''));
536
+ }
537
+
538
+ // A construct the guard cannot interpret (eval, source / `.`, a bash 5.3 `${ cmd; }`,
539
+ // printf -v, a function definition, an alias, a quoted gh api body key, a backslash-newline
540
+ // inside a word) next to a secret-looking piece: { hit, piece } or null. The piece only has
541
+ // to sit in the construct's own statement or in the code it hides, which is not proof of a
542
+ // read (`printf -v x %s .env` blocks too): the uncertain shape is blocked and the simple
543
+ // form asked for, not emulated.
544
+ function unmodelledSecretPiece(cmd) {
545
+ let lib; // loaded lazily: a missing or broken lib only switches this gate off
546
+ try {
547
+ lib = require('./lib/unmodelled.js');
548
+ } catch {
549
+ return null;
550
+ }
551
+ for (const hit of lib.findUnmodelled(cmd)) {
552
+ if (hit.id === 'api-field') continue; // a body-write concern (body-guard), not a read
553
+ const piece = crudeSecretPiece(hit.stmt) || crudeSecretPiece(hit.payload);
554
+ if (piece) return { hit, piece };
405
555
  }
406
556
  return null;
407
557
  }
@@ -420,12 +570,27 @@ function detectSecretRead(toolName, toolInput) {
420
570
  if (toolName === 'Bash') {
421
571
  const cmd = input.command || '';
422
572
  const hit = scanBashForSecretPath(cmd);
423
- return hit ? { path: hit } : null;
573
+ if (hit) return { path: hit };
574
+ const um = unmodelledSecretPiece(cmd); // a final gate: the precise scan keeps priority
575
+ return um ? { path: um.piece, unmodelled: um.hit } : null;
424
576
  }
425
577
  return null;
426
578
  }
427
579
 
580
+ function blockUnmodelled(hit) {
581
+ let redact; // the secret-guard's redactor; without it the message omits the sample
582
+ try {
583
+ ({ redact } = require('./trailhead-secret-guard.js'));
584
+ } catch {
585
+ redact = undefined;
586
+ }
587
+ const reason = require('./lib/unmodelled.js').unmodelledReason('secret-read guard', 'that it does not read a secret file (.env / .env.* / .secrets)', hit.unmodelled, redact);
588
+ process.stdout.write(JSON.stringify({ decision: 'block', code: 'SECRET_READ_UNMODELLED_CONSTRUCT', reason }));
589
+ process.exit(2);
590
+ }
591
+
428
592
  function block(hit) {
593
+ if (hit.unmodelled) blockUnmodelled(hit);
429
594
  const reason =
430
595
  `trailhead secret-read guard: blocked a read of secret file \`${hit.path}\` ` +
431
596
  '(.env / .env.* / .secrets). This replaces the Read() deny permission rules ' +
@@ -34,6 +34,18 @@ ok('Bash grep -n KEY .env.production is denied', !!detectSecretRead('Bash', { co
34
34
  ok('Bash cat app/.env.local is denied', !!detectSecretRead('Bash', { command: 'cat app/.env.local' }));
35
35
  ok('Bash cat --file=.env is denied', !!detectSecretRead('Bash', { command: 'cat --file=.env' }));
36
36
 
37
+ // --- line continuation splits a secret path (#222) ---
38
+ ok('Bash cat \\<nl>.env is denied', !!detectSecretRead('Bash', { command: 'cat \\\n.env' }));
39
+ ok('Bash echo $(cat \\<nl>.env) is denied', !!detectSecretRead('Bash', { command: 'echo $(cat \\\n.env)' }));
40
+ ok('Bash cat .e\\<nl>nv is denied', !!detectSecretRead('Bash', { command: 'cat .e\\\nnv' }));
41
+ ok('Bash cat .e\\\\<nl>nv (escaped backslash) is allowed', !detectSecretRead('Bash', { command: 'cat .e\\\\\nnv' }));
42
+ ok('Bash continuation inside single quotes stays literal', !detectSecretRead('Bash', { command: "echo 'x\\\n.env'" }));
43
+ ok('Bash consecutive continuations cat \\<nl>\\<nl>.env are denied', !!detectSecretRead('Bash', { command: 'cat \\\n\\\n.env' }));
44
+ ok('Bash separator on the continuation line is denied', !!detectSecretRead('Bash', { command: 'echo a \\\n; cat .env' }));
45
+ ok('Bash continuation inside a backtick span is denied', !!detectSecretRead('Bash', { command: 'echo `cat \\\n.env`' }));
46
+ ok('Bash continuation inside "$(..)" is denied', !!detectSecretRead('Bash', { command: 'echo "$(cat .e\\\nnv)"' }));
47
+ ok('Bash trailing backslash on the last line is allowed', !detectSecretRead('Bash', { command: 'echo done \\' }));
48
+
37
49
  // --- ALLOW cases (no false positives) ---
38
50
  ok('Read src/app.ts is allowed', !detectSecretRead('Read', { file_path: 'src/app.ts' }));
39
51
  ok('Bash grep -n x pubspec.yaml is allowed', !detectSecretRead('Bash', { command: 'grep -n x pubspec.yaml' }));
@@ -46,6 +58,8 @@ ok('Read .environment (near-miss) is allowed', !detectSecretRead('Read', { file_
46
58
  // --- #135 follow-up: Finding 1 - glued shell metacharacters must not bypass detection ---
47
59
  ok('Bash cat .env|grep KEY is denied (glued pipe)', !!detectSecretRead('Bash', { command: 'cat .env|grep KEY' }));
48
60
  ok('Bash cat .env;echo done is denied (glued semicolon)', !!detectSecretRead('Bash', { command: 'cat .env;echo done' }));
61
+ ok('Bash cat .env after an arithmetic << on the previous line is denied (#212)',
62
+ !!detectSecretRead('Bash', { command: 'echo $((1<<3))\ncat .env' }));
49
63
  ok('Bash cat .env&&echo done is denied (glued &&)', !!detectSecretRead('Bash', { command: 'cat .env&&echo done' }));
50
64
  ok('Bash bash -c "cat .env" is denied (quoted sub-command)', !!detectSecretRead('Bash', { command: 'bash -c "cat .env"' }));
51
65
  ok('Bash eval "cat .env" is denied (quoted sub-command)', !!detectSecretRead('Bash', { command: 'eval "cat .env"' }));
@@ -180,13 +194,169 @@ denyCmd('cp .env.example .env -f');
180
194
  denyCmd('cp .env.example .env && cat .env');
181
195
  denyCmd('git check-ignore .env; cat .env');
182
196
 
197
+ // #214: a secret read inside a command substitution, even double-quoted
198
+ const hit214 = (c) => { const r = detectSecretRead('Bash', { command: c }); return !!r && r.path === '.env'; };
199
+ for (const c of ['echo "$(true; cat .env)"', 'echo "$(cat .env)"', 'x="$(cat .env)"', 'diff <(cat .env) x',
200
+ 'echo "$(echo "$(cat .env)")"', 'echo "$(\ncat .env\n)"']) {
201
+ ok(`Bash \`${c}\` is denied with path .env (#214)`, hit214(c));
202
+ }
203
+ allowCmd("echo '$(cat .env)'");
204
+ allowCmd('echo "$(echo hi)"');
205
+ allowCmd('echo "$((1+2))"');
206
+ allowCmd('git commit -m "document .env usage"');
207
+
208
+ // #214 review: heredoc inside a substitution, substitution inside arithmetic
209
+ for (const c of ['echo "$(cat <<E\nfoo\nE\n; cat .env)"', 'echo $(cat <<E\nfoo\nE\n; cat .env)',
210
+ 'echo "$(( $(cat .env) ))"', 'echo $(( $(cat .env) ))', 'echo "$[ $(cat .env) ]"']) {
211
+ ok(`Bash \`${c}\` is denied with path .env (#214 review)`, hit214(c));
212
+ }
213
+ allowCmd('echo "$((1+2))"');
214
+ allowCmd('echo $((a+(b)))');
215
+ allowCmd('echo "$(( $(echo 1) + 1 ))"');
216
+
217
+ // #216: a secret read inside a backtick substitution, even double-quoted
218
+ for (const c of ['echo "`cat .env`"', 'x="`cat .env`"', 'echo "${x:-`cat .env`}"', 'echo `cat .env`',
219
+ 'echo "$(echo `cat .env`)"', 'echo `echo $(cat .env)`', 'echo `echo \\`cat .env\\``']) {
220
+ ok(`Bash \`${c}\` is denied with path .env (#216)`, hit214(c));
221
+ }
222
+ for (const c of ['echo "`echo \'"\'`"; cat .env', 'echo `true\ncat .env\n`',
223
+ 'echo `echo \\`echo \\\\\\`cat .env\\\\\\`\\``']) {
224
+ ok(`Bash \`${c}\` is denied with path .env (#216 review)`, hit214(c));
225
+ }
226
+ { // \" inside a double-quoted backtick body: bash reads the quoted .env (the path keeps its quotes)
227
+ const r = detectSecretRead('Bash', { command: 'echo "`cat \\".env\\"`"' });
228
+ ok('Bash `echo "`cat \\".env\\"`"` is denied (#216 review)', !!r && /\.env/.test(r.path));
229
+ }
230
+ allowCmd('echo "run `ls` then `pwd`"');
231
+ allowCmd("echo '`cat .env`'");
232
+ allowCmd('echo "\\`cat .env\\`"');
233
+
234
+ // #218: a secret read inside the body of an UNQUOTED heredoc (the shell runs $(..) and backticks there)
235
+ for (const c of ['cat <<EOF\n$(cat .env)\nEOF', 'cat <<EOF\n`cat .env`\nEOF', 'cat <<-EOF\n\t$(cat .env)\n\tEOF',
236
+ "cat <<EOF\nit's $(cat .env)\nEOF", 'cat <<EOF\nsay "hi $(cat .env)\nEOF', 'cat <<EOF\n${x:-$(cat .env)}\nEOF',
237
+ 'cat <<EOF\nfirst line\nthen text $(cat .env) more\nEOF', 'x=$(cat <<EOF\n$(cat .env)\nEOF\n)',
238
+ 'cat <<A\n$(cat <<B\n)\nB\ncat .env)\nA', 'cat <<EOF\n$\\\n(cat .env)\nEOF', 'cat <<EOF\n$(cat .e\\\nnv)\nEOF',
239
+ 'cat <<EOF\n$(cat \\\n.env)\nEOF', "cat <<A <<'B'\n$(cat .env)\nA\nx\nB"]) {
240
+ ok(`Bash \`${c}\` is denied with path .env (#218)`, hit214(c));
241
+ }
242
+ for (const c of ["cat <<'EOF'\n$(cat .env)\nEOF", 'cat <<"EOF"\n$(cat .env)\nEOF', "cat <<'EOF'\n`cat .env`\nEOF",
243
+ 'cat <<EOF\n$$(cat .env)\nEOF', "cat <<A <<'B'\nx\nA\n$(cat .env)\nB",
244
+ 'cat <<EOF\n\\$(cat .env)\nEOF', 'cat <<EOF\n\\`cat .env\\`\nEOF', 'cat <<EOF\ncat .env\nEOF']) {
245
+ allowCmd(c);
246
+ }
247
+
248
+ // #223: a heredoc body fed to a shell interpreter on stdin is a script, whatever the delimiter quoting
249
+ for (const c of ["bash <<'EOF'\ncat .env\nEOF", 'sh <<EOF\ncat .env\nEOF', 'bash <<EOF\ncat .env\nEOF',
250
+ 'cat <<EOF | bash\ncat .env\nEOF', 'zsh -s <<EOF\ncat .env\nEOF', 'VAR=1 bash <<EOF\ncat .env\nEOF',
251
+ 'env FOO=1 bash <<EOF\ncat .env\nEOF', '/bin/bash <<EOF\ncat .env\nEOF', 'dash <<EOF\ncat .env\nEOF',
252
+ 'env -i FOO=1 ksh <<EOF\ncat .env\nEOF', "cat <<'EOF' | sh\ncat .env\nEOF", 'bash -x <<EOF\necho $(cat .env)\nEOF',
253
+ 'echo hi; bash <<EOF\ncat .env\nEOF']) {
254
+ ok(`Bash \`${c}\` is denied with path .env (#223)`, hit214(c));
255
+ }
256
+ // #223 review: env option values, leading shell keywords, heredoc pairing
257
+ for (const c of ['env -u FOO bash <<EOF\ncat .env\nEOF', 'env -C /tmp bash <<EOF\ncat .env\nEOF',
258
+ 'env --unset FOO sh <<EOF\ncat .env\nEOF', 'env --chdir /tmp bash <<EOF\ncat .env\nEOF',
259
+ 'env -S bash <<EOF\ncat .env\nEOF', 'if true; then bash <<EOF\ncat .env\nEOF', 'time bash <<EOF\ncat .env\nEOF',
260
+ 'while x; do bash <<EOF\ncat .env\nEOF', '! bash <<EOF\ncat .env\nEOF', 'true; then time bash <<EOF\ncat .env\nEOF',
261
+ 'cat <<EOF |& bash\ncat .env\nEOF', 'bash <<EOF &\ncat .env\nEOF', 'cat <<A; bash <<B\necho hi\nA\ncat .env\nB']) {
262
+ ok(`Bash \`${c}\` is denied with path .env (#223 review)`, hit214(c));
263
+ }
264
+ allowCmd('cat <<A; bash <<B\ncat .env\nA\necho hi\nB');
265
+
266
+ for (const c of ["cat <<'EOF'\ncat .env\nEOF", 'cat <<EOF\ncat .env\nEOF', "tee f <<'EOF'\ncat .env\nEOF",
267
+ 'cat <<EOF; bash x.sh\ncat .env\nEOF', "bash <<'EOF'\necho hi\nEOF", 'cat <<EOF | bash\necho hi\nEOF']) {
268
+ allowCmd(c);
269
+ }
270
+
271
+ // #214: deep nesting is bounded (explicit work-list, capped), never a stack overflow
272
+ {
273
+ const nest = (n, inner) => 'echo ' + '"$('.repeat(n) + inner + ')"'.repeat(n);
274
+ for (const n of [40, 2000, 6000]) {
275
+ const t0 = Date.now();
276
+ const r = detectSecretRead('Bash', { command: nest(n, 'cat .env') });
277
+ const ms = Date.now() - t0;
278
+ ok(`nesting n=${n} with a secret is denied with path .env`, !!r && r.path === '.env');
279
+ ok(`nesting n=${n} with a secret completes under 1s (${ms}ms)`, ms < 1000);
280
+ }
281
+ const t1 = Date.now();
282
+ const clean = detectSecretRead('Bash', { command: nest(6000, 'cat README.md') });
283
+ const ms1 = Date.now() - t1;
284
+ ok('deep nesting with no secret is allowed', clean === null);
285
+ ok(`deep nesting with no secret completes under 1s (${ms1}ms)`, ms1 < 1000);
286
+ }
287
+
183
288
  const a6 = runHook('Bash', { command: 'git check-ignore -v .env' });
184
289
  ok('hook allows Bash(git check-ignore -v .env) end-to-end (exit 0, no output)', a6.code === 0 && a6.out.trim() === '');
185
290
  const a7 = runHook('Bash', { command: 'cp .env.example .env' });
186
291
  ok('hook allows Bash(cp .env.example .env) end-to-end (exit 0, no output)', a7.code === 0 && a7.out.trim() === '');
187
292
 
293
+ // --- #227: constructs the guard cannot interpret, near a secret-looking piece ---
294
+ {
295
+ const CODE = 'SECRET_READ_UNMODELLED_CONSTRUCT';
296
+ const code = (command) => { const r = runHook('Bash', { command }); return r.code === 2 ? JSON.parse(r.out).code : null; };
297
+ for (const c of [
298
+ 'eval cat .e""nv',
299
+ 'eval "cat .e\'\'nv"',
300
+ 'echo ${ cat .e""nv; }',
301
+ 'echo ${| cat .e""nv; }',
302
+ 'source .e""nv',
303
+ '. .e""nv && make',
304
+ 'printf -v x %s .e""nv',
305
+ "alias c='cat .e\"\"nv'",
306
+ "alias c='cat .env'; c",
307
+ 'f() { cat .e""nv; }; f',
308
+ 'echo "${ cat .e""nv; }"',
309
+ 'x=$(source .e""nv)',
310
+ ]) {
311
+ const hit = detectSecretRead('Bash', { command: c });
312
+ ok(`denies an unmodelled construct near a secret piece: ${c}`, !!hit && !!hit.unmodelled);
313
+ ok(`... with the unmodelled code (exit 2): ${c}`, code(c) === CODE);
314
+ }
315
+ ok('a quoted api body key mentioning .env in prose is not a read', detectSecretRead('Bash', { command: "gh api -X PATCH repos/a/b/issues/1 -f 'body'='document the .env file'" }) === null);
316
+ ok('... and the hook allows it', runHook('Bash', { command: "gh api -X PATCH repos/a/b/issues/1 -f 'body'='document the .env file'" }).code === 0);
317
+ // The precise scan keeps priority and its code.
318
+ ok('a precise read keeps SECRET_READ_BLOCKED', code('eval cat .env') === 'SECRET_READ_BLOCKED');
319
+ ok('a precise read inside a function body keeps SECRET_READ_BLOCKED', code('f() { cat .env; }; f') === 'SECRET_READ_BLOCKED');
320
+ ok('detectSecretRead keeps { path } for a precise read', (() => { const h = detectSecretRead('Bash', { command: 'cat .env' }); return h && h.path === '.env' && !h.unmodelled; })());
321
+ // Plain controls pass: the construct has no secret-looking piece near it.
322
+ for (const c of [
323
+ '. venv/bin/activate && make',
324
+ 'source ~/.venv/bin/activate && pytest',
325
+ "alias ll='ls -l'",
326
+ 'alias g=gh; g issue list',
327
+ 'eval "$(ssh-agent)"',
328
+ 'printf -v x %s y; echo $x',
329
+ 'f() { ls; }; f',
330
+ 'echo ${ date; }',
331
+ 'echo "alias .environment"',
332
+ 'cat .e\\\n nv.md',
333
+ ]) ok(`allows a construct with no secret piece: ${c}`, detectSecretRead('Bash', { command: c }) === null && runHook('Bash', { command: c }).code === 0);
334
+ const r = runHook('Bash', { command: 'echo ${ cat .e""nv; }' });
335
+ const reason = JSON.parse(r.out).reason;
336
+ ok('the message names the guard and asks for the simple form', /^trailhead secret-read guard: /.test(reason) && /Rewrite it in a simple form/.test(reason));
337
+ const T = 'ghp_' + 'a1B2c3D4e5F6g7H8i9J0k1L2m3N4o5P6q7R8'.slice(0, 36);
338
+ const leak = JSON.parse(runHook('Bash', { command: `echo \${ cat .e""nv; echo ${T}; }` }).out).reason;
339
+ ok('the message never echoes a token', !leak.includes(T) && !leak.includes('ghp_'));
340
+ }
341
+
188
342
  // --- crash safety ---
189
343
  const crash1 = runHook('Read', undefined);
190
344
  ok('missing tool_input never crashes (exit 0)', crash1.code === 0);
191
345
 
346
+ // --- #227: a missing unmodelled lib degrades to the previous behaviour ---
347
+ {
348
+ const fs = require('fs');
349
+ const os = require('os');
350
+ const dir = fs.mkdtempSync(path.join(os.tmpdir(), 'srg-nolib-'));
351
+ fs.mkdirSync(path.join(dir, 'lib'));
352
+ for (const f of fs.readdirSync(path.join(__dirname, 'lib'))) {
353
+ if (/\.(js|json)$/.test(f) && !f.endsWith('.test.js') && f !== 'unmodelled.js') fs.copyFileSync(path.join(__dirname, 'lib', f), path.join(dir, 'lib', f));
354
+ }
355
+ fs.copyFileSync(path.join(__dirname, 'trailhead-secret-read-guard.js'), path.join(dir, 'trailhead-secret-read-guard.js'));
356
+ const bare = require(path.join(dir, 'trailhead-secret-read-guard.js'));
357
+ ok('without the unmodelled lib the guard still loads and denies a precise read', !!bare.detectSecretRead('Bash', { command: 'cat .env' }));
358
+ ok('without the unmodelled lib the unmodelled gate is off', bare.detectSecretRead('Bash', { command: 'source .e""nv' }) === null);
359
+ fs.rmSync(dir, { recursive: true });
360
+ }
361
+
192
362
  console.log(`✓ secret-read-guard: ${passed} assertions passed`);
@@ -4,6 +4,8 @@ When trailhead must put a **forced choice** to the human (any `AskUserQuestion`-
4
4
 
5
5
  **Host constraint.** These options exist only inside questions **trailhead itself authors**. The host `AskUserQuestion` tool is not ours to change; we add the options as extra choices in the prompts we build.
6
6
 
7
+ **Which format.** Count the **real options** (the delegate/defer affordances never count). A forced choice with **up to 4 real options** is always put as an `AskUserQuestion` menu, never as a prose list: the menu rules below apply (dedup, cap, links in the prose). A forced choice with **more than 4 real options** cannot fit the menu, so put it as a **lettered list** in prose, one option per line (**(a)**, **(b)**, ...), with any applicable affordance appended as its own letter, then wait for the user's pick (a letter or the option's text). The lettered `(a)/(b)/(c)` options written in these instructions name the options to offer, not the format: render them per this rule. Conversational call-sites (grilling) stay in prose. On Codex, which has no `AskUserQuestion`, the plain-text numbered list of its adapter replaces the menu.
8
+
7
9
  ## The one-line test: whose choice is it?
8
10
 
9
11
  Before offering the delegate option, ask: **is the answer itself a project decision (a `decision`-ticket's answer, or a change to the map's destination or scope), as opposed to a process choice that merely gets folded into some ticket's ordinary resolution summary?**
@@ -54,7 +56,7 @@ This is the operational recipe every applicable call-site follows. It is **manda
54
56
 
55
57
  Worked examples: 2 real options + delegate + defer = 4 -> all in the menu; 3 real options + delegate + defer = 5 -> the menu carries the 3 real options and delegate/defer are offered in the prose line right after it; 2 real options + delegate (defer not applicable) = 3 -> in the menu.
56
58
 
57
- **Menu call-sites (an `AskUserQuestion` trailhead authors): links live in the prose.** A picker renders its question and options as plain text, so nothing in it is clickable. When a question is about something the user has to open first (a mockup to approve or pick from, a published page, a PR, a ticket comment), write its clickable link(s) in the reply text **immediately before** the menu, in that same message, never only earlier in the conversation, never as a name in place of the URL, and never inside the picker. If there is no link to show yet, do not ask. For mockups the full rule is "Surface the mockup" in `techniques/prototype.md`, enforced by the mockup-link hooks (Claude Code and Codex).
59
+ **Menu call-sites (an `AskUserQuestion` trailhead authors): links live in the prose.** A picker renders its question and options as plain text, so nothing in it is clickable. When a question is about something the user has to open first (a mockup to approve or pick from, a published page, a PR, a ticket comment), write its clickable link(s) in the reply text **immediately before** the menu, in that same message, never only earlier in the conversation, never as a name in place of the URL, and never inside the picker. If there is no link to show yet, do not ask. For mockups the full rule is "Surface the mockup" in `techniques/prototype.md`, enforced by the mockup-link hooks (Claude Code and Codex); the Claude Code guard also accepts a link carried by the approval question itself, but the prose stays the preferred form.
58
60
 
59
61
  **Prose / conversational call-sites (grilling, or any choice put in words rather than a menu).** There is no cap: **state the applicable affordance(s) in words** in the same message that puts the choice (for example append "Oppure: scegli tu, propongo io / scelgo dopo se dipende da un prerequisito."). Grilling stays human-decides, so delegate is not offered there; **defer is offered in prose when the decision is genuinely blocked on a prerequisite.**
60
62
 
@@ -7,8 +7,9 @@ Effective config = built-in defaults ← global `~/.claude/trailhead/config.json
7
7
  | `models.{plan,execute,research,review,debug,verify,codebase-map}` | a model id (**Balanced-profile default**) | model for that activity; an unset key resolves to its default **Balanced** tier, see note |
8
8
  | `models.codex.{plan,execute,research,review,debug,verify,codebase-map}` | an OpenAI model id (**inherit session**) | per-activity subagent model on **Codex** (OpenAI ids), the honoured namespace there; independent of `models.*` (Claude ids); projected into `~/.codex/agents/trailhead-*.toml` and dispatched by `agent_type`. See note |
9
9
  | `ticket.language` | an ISO 639-1 code (**`en`**) | the language trailhead **writes** its GitHub prose in (ticket titles/bodies, engine comments, map body & commit descriptions), see note. Independent of the language the agent converses in |
10
- | `design` | **`disk`** \| `claude.ai/design` \| `stitch` | mode for UI mockups (**Prototype**). `disk` = throwaway local HTML (any host); `claude.ai/design` = create/edit the mockup on claude.ai/design via Anthropic's **official Claude Design MCP** (`claude mcp add --scope user --transport http claude-design https://api.anthropic.com/v1/design/mcp`, auth `/design-login`), **Claude only**; `stitch` = create/edit the mockup via the **Google Stitch MCP** (`claude mcp add --scope user --transport http stitch https://stitch.googleapis.com/mcp`), the **cross-host** hosted option (Claude Code **and** Codex). A hosted mode's projectId is created/reused at execution and cached in `design.project`; which surface it uses is `design.surface`. If the configured mode's MCP isn't connected, Prototype offers a one-time install before falling back (see Prototype). **On Codex** `claude.ai/design` isn't available, so Prototype **offers to switch to `stitch`** (cross-host) before degrading to `disk`; `stitch` and `disk` run on Codex unchanged |
11
- | `design.surface` | **`canvas`** \| `design-system` | under a hosted `design` mode (`claude.ai/design` or `stitch`), which surface the mockup lives on. `canvas` = a single surface of screens to react to (under `claude.ai/design`: a `/design` **Artifact** or a hand-made web-app project, **not** MCP-created; under `stitch`: a Stitch project), editable visually and exportable as a live prototype. `design-system` = push components into a shared design-system project (a `PROJECT_TYPE_DESIGN_SYSTEM` synced via DesignSync `/design-sync`, or a Stitch design system), for a shared component library. **Back-compat:** unset, a cached `design.project` infers `design-system` (that's what the key meant before this key existed); with no cached project, `canvas`. See Prototype |
10
+ | `design` | **`disk`** \| `artifacts` \| `stitch` | mode for UI mockups (**Prototype**). `disk` = throwaway local HTML (any host); `artifacts` = build the mockup as a **Design canvas Artifact** on claude.ai through Claude Code's built-in `Artifact` tool (no MCP, no login step), **Claude Code signed in with a claude.ai account only**; `stitch` = create/edit the mockup via the **Google Stitch MCP** (`claude mcp add --scope user --transport http stitch https://stitch.googleapis.com/mcp`), the **cross-host** hosted option (Claude Code **and** Codex). A hosted mode's canvas/project is created or reused at execution and cached in `design.project`. **Legacy:** `claude.ai/design` (the standalone Claude Design site, closing 2026-12-14) is read as `artifacts`, with a one-time notice and an offer to rewrite the key. Where the `Artifact` tool is missing (Codex, API-key sessions) Prototype **offers to switch to `stitch`** before degrading to `disk`; `stitch` and `disk` run on Codex unchanged |
11
+ | `design.surface` | **`canvas`** \| `design-system` | **`stitch` only**: which surface the mockup lives on. `canvas` = a Stitch project of screens to react to; `design-system` = push components into a shared Stitch design system. Ignored under `artifacts` (always a Design canvas; a design system is installed on it via `design.system`, never written to) and under `disk`. See Prototype |
12
+ | `design.system` | Design System Artifact URL (**unset**) | **`artifacts` only**: the design system installed on the mockup canvas (its tokens and, when it ships them, its components). Unset at the first screen: the account's default design system if one is marked, else trailhead lists them and asks (or none), then caches the pick here |
12
13
  | `design.approval` | **`explicit`** \| `auto` | must a mockup be explicitly approved before the build proceeds to UI code? |
13
14
  | `tdd` | **`seams`** \| `on` \| `off` | how the `build` engine tests |
14
15
  | `acceptance.browser` | **`auto`** \| `on` \| `off` | how **Acceptance testing** runs |
@@ -62,7 +63,7 @@ If a value is unset, it resolves to its **Balanced**-profile default for that ac
62
63
 
63
64
  **acceptance.browser.** The drive-mode ask (AI-driven vs human-driven, see the Acceptance testing technique) **always comes first, before any step runs**: no value of this key pre-answers it. This key only governs whether and how an AI-driven step uses the browser once that ask is answered AI-driven: `auto` (default) = browser-drive when `testing.webapp` + `testing.url` are set, or (when `testing.webapp` is set but `testing.url` is unset) first try to auto-detect the target URL (running dev server, package scripts, dev-server/framework config, project config) and propose it, driving against the accepted URL; when no URL can be determined, fall back per the Acceptance testing technique (ask the human for the URL, or the guided UAT for that step); `on` = always attempt browser-driving, auto-detecting the URL the same way when `testing.url` is unset; `off` = never drive a browser. **`off` disables *browser-driving*, not acceptance, and not AI-driven checking**: AI-driven still runs its non-browser checks via commands / the test suite for whatever steps allow it; only a step that genuinely needs the human (or the whole UAT, under human-driven) gets the guided UAT walkthrough. The Verify step honours this.
64
65
 
65
- **design.surface.** Under `design: claude.ai/design`, which Claude Design surface the mockup lives on. `canvas` (default) = a one-off screen to react to, edited visually and exportable as a live prototype; under `claude.ai/design` it is **not** MCP-driven (no MCP creates a regular canvas project): it's the built-in `/design` skill published as an **Artifact**, or a claude.ai/design project made by hand in the web app whose `/p/<id>` URL you paste. `design-system` = a `PROJECT_TYPE_DESIGN_SYSTEM` project driven by DesignSync (the `/design-sync` slice of the official Claude Design MCP), for a shared component library kept in sync. Unset, it infers from `design.project`: a cached project (which, before this key, was always a design system) means `design-system`; no cached project means `canvas`. The Prototype technique honours this; when the **`design-system`** surface's MCP isn't connected it **offers a one-time install** (`claude mcp add ... claude-design`, then `/design-login`) before falling to disk (the `canvas` surface needs no MCP, so no install offer). Under `design: stitch` the same key applies: `canvas` = a Stitch project with generated screens, `design-system` = a Stitch design system; the install offer and disk fallback work the same way (no intra-provider chain, the Stitch MCP either connects or falls to disk). Ignored under `design: disk`.
66
+ **design.surface / design.system.** Under `design: stitch`, `design.surface` picks the surface: `canvas` (default) = a Stitch project with generated screens, `design-system` = a Stitch design system; the install offer and disk fallback are in Prototype (the Stitch MCP either connects or falls to disk). Under `design: artifacts` there is one surface, a **Design canvas Artifact** (`design.project` = its URL), and `design.surface` is ignored; `design.system` names the **Design System Artifact** installed on that canvas, a read-only reference: screens are never pushed into it. **Back-compat:** a `design.project` left from the standalone claude.ai/design (a bare project id or a `claude.ai/design/p/<id>` URL) is not reusable; Prototype says so once and attaches a new canvas. Ignored under `design: disk`.
66
67
 
67
68
  **design.approval.** `explicit` (default) = a UI mockup must be **explicitly approved by the user** before the `build` engine writes any real UI code; surface the mockup and wait for a clear go-ahead. `auto` = surface the mockup and proceed without blocking on a confirmation (the user can still object). The Prototype technique honours this.
68
69
 
@@ -104,7 +105,7 @@ Example `config.json` (same shape for the project `.trailhead/config.json` and t
104
105
  - **The per-key questions (Manual path only): always two separate questions, one for `plan` and one for `execute`; never merge them into a single model pick.** Ask each as its own `AskUserQuestion` menu (current value pre-selected), and offer the **same versioned lineup** to both. Each option is a **full model id with its version**; never a bare family alias (`opus`/`sonnet`/`haiku`), which can't say *which* live version. Build the list from the models actually reachable **at setup time** (verify, don't trust this file verbatim), offering **at least the two most recent versions per family**, e.g. `claude-fable-5`, `claude-opus-5-5` / `claude-opus-5`, `claude-sonnet-5-5` / `claude-sonnet-5`, `claude-haiku-5-5` / `claude-haiku-4-5`, plus **inherit session** (the no-override option, the session model). If that lineup exceeds the menu's option cap, drill **family → version** or include a free-id "Other" so every recent version stays reachable. The rarer `research`/`review`/`debug`/`verify`/`codebase-map` sit behind an "Advanced" option, each its own separate choice, same versioned rule.
105
106
  - **Anti-pattern, never do this (in the Manual path):** a single screen whose options are *combined* plan+execute presets, e.g. `🧠 Plan 4.8 / Exec Sonnet 5`, `🚀 Tutto Opus 5`, `Plan Opus 5 / Exec Sonnet 5`. That bundles the two decisions into one pick. Forbidden. In Manual, Plan is asked, answered, and only then is Execute asked, as a second menu: two questions, two answers, always. (A **named tier profile** applied whole is **not** this anti-pattern: it is a coherent per-key tier assignment chosen deliberately, not an ad-hoc plan+execute combo, which is why picking a profile is terminal.)
106
107
  - **On Codex (host-detected), the Manual path asks `models.codex.*` instead of the Claude lineup.** Same discipline: `plan` and `execute` as two separate `AskUserQuestion` menus, never merged; the rarer `research`/`review`/`debug`/`verify`/`codebase-map` behind Advanced, each its own choice. Offer OpenAI model ids verified reachable at setup time (do not trust this list verbatim): `gpt-5.6-sol` (flagship) / `gpt-5.6-terra` (balanced) / `gpt-5.6-luna` (fast), plus **inherit session** (default). Avoid the retiring `gpt-5.4` / `gpt-5.4-mini` and the deprecated `gpt-5.3-codex`. Write the answers to `models.codex.*`; the Claude `models.*` lineup is not asked on Codex (those ids cannot run there). After writing, tell the user to **re-run the installer** (the same `--host=codex` install command) so the pins are re-projected into `~/.codex/agents/trailhead-*.toml`: the menu updates `.trailhead/config.json`, the installer is what regenerates the TOMLs and enables `features.multi_agent_v2`.
107
- 5. **🎨 Design**: 💾 Local disk · 🖼️ claude.ai/design (Anthropic's official Claude Design MCP, Claude only) · 🧵 Stitch (Google Stitch MCP, cross-host: Claude Code + Codex). *Mode only, don't ask for a URL here; the concrete project is created or reused at execution time and its projectId cached in `design.project` (see Prototype).* If claude.ai/design or Stitch is picked, ask the **🖼️ Design surface**: 🖌️ Canvas (a single project of screens to react to; default; **who makes it:** on claude.ai/design you do, the `/design` Artifact or a hand-made web-app project, not MCP-driven; on Stitch the MCP generates the screens) · 🧩 Design system (push components into a shared design-system project, for a shared library; **the MCP creates and syncs it**) → `design.surface`. Then **✅ Mockup approval**: 🖐️ Explicit (wait for a go-ahead before UI code) · ⏩ Auto (proceed without blocking).
108
+ 5. **🎨 Design**: 💾 Local disk · 🖼️ Artifacts (a Design canvas on claude.ai, built with Claude Code's `Artifact` tool; Claude Code only) · 🧵 Stitch (Google Stitch MCP, cross-host: Claude Code + Codex). *Mode only, don't ask for a URL here; the canvas/project is created or reused at execution time and cached in `design.project` (see Prototype).* If Stitch is picked, ask the **🖼️ Design surface**: 🖌️ Canvas (a Stitch project of screens to react to; default) · 🧩 Design system (push components into a shared Stitch design system) → `design.surface`. If Artifacts is picked, optionally ask the **🧩 Design system** to install on the canvas (list the account's Design System Artifacts, or "decide at the first screen") → `design.system`. Then **✅ Mockup approval**: 🖐️ Explicit (wait for a go-ahead before UI code) · ⏩ Auto (proceed without blocking).
108
109
  6. **🧪 TDD**: 🎯 Seams only · ✅ On (all definable behaviour) · ⛔ Off.
109
110
  7. **⚖️ Effort**: how hard the `build`/`bug` engine works each change (`effort`). 🛠️ **Standard** (default; every step runs) · 🍃 **Lean** (size-triage small changes and offer to skip heavy steps, on an explicit yes only: the plan pass, TDD, cross-AI review, the full code review, the goal-backward verify; correctness checks always stay). Governs `build`/`bug` only: `quick` always size-triages regardless.
110
111
  8. **🖥️ Acceptance testing**: 🤖 Auto · ▶️ Always browser · 🚫 No browser (acceptance still runs, starting with the drive-mode ask; only browser-driving is off, see `acceptance.browser` above). If browser is enabled, ask **🔗 base URL** and confirm it's a web app.
@@ -5,4 +5,4 @@ Three layers, **nearest wins**, key by key; a key unset at one layer inherits th
5
5
  - **Global**: `~/.claude/trailhead/config.json` (honour `$CLAUDE_CONFIG_DIR`): your standing defaults across every project.
6
6
  - **Defaults**: the built-in values documented in `configuration-reference.md`.
7
7
 
8
- Load the effective config at the start of a work session, **from the map's project root** (`.trailhead/config.json` at the superproject repo root) plus the global file, **before** any isolation workspace is set up. **Config is a property of the project/map, not the working directory**: an `isolation: worktree`/`clone` workspace **inherits** the config loaded here and must **never re-resolve it from the isolated copy's own root**. A per-ticket clone is always a clone of the **superproject** (never of a submodule alone), so its `.trailhead/config.json` is present when the project commits one and absent when it doesn't; either way re-resolving there is wrong, because the workspace must reuse the config already resolved from the original checkout, not load it afresh (an absent file would silently fall back to defaults, which is exactly how a `design: claude.ai/design` project ends up wrongly using `disk` in a clone). Config **writes** too (e.g. caching `design.project`) target the project's `.trailhead/config.json` in the original checkout, never the clone. **The main session orchestrates and holds the HITL moments** (the `build`/`bug` Discuss's "stop and ask", Verify's acceptance/UAT); **every model key runs as a subagent** (`plan`, `execute` (an *executor subagent* implementing with atomic commits on `models.execute`), `research`, `review`, `debug`, `verify`, `codebase-map`) so the whole per-activity model split applies in one session whatever model it runs on. Run Execute inline only when `models.execute` is unset or equals the session model. **On a subagent-less host** (`subagentToolkit == none`) there is nothing to fan out into: every activity runs inline. **Separately, on a host that can't honour the model keys** (`honorsModelKeys == false`, e.g. Codex, whose subagents run on its own OpenAI models) every `models.*` key collapses to the single session model even though the activities still fan out; when any `models.*` is set there the engine surfaces a **one-time** session-start notice that the split is not taking effect (the keys stay in `.trailhead/config.json` for when the project next runs on Claude Code). On Codex the per-activity split is available through a parallel `models.codex.*` namespace (OpenAI model ids), the honoured namespace there (projected into per-technique `~/.codex/agents/*.toml` and dispatched at runtime by `agent_type`), while `models.*` (Claude ids) still collapse to the single session model; the collapse notice points at `models.codex.*` and goes silent once it is set. A host without a hook bus (`hookBus == none`) also runs a lightweight inline update check at session start (no SessionStart hook, no statusline). After an update changes the tier defaults, a pinned-model review offer surfaces too, once per session and until the user answers it (see `../_shared/load-first.md` for the check/ack sequence and `configuration-reference.md`'s Pinned model review). See `configuration-reference.md`. The **keys, their values, the model/tdd/acceptance semantics, and the guided menu setup live in `configuration-reference.md`**: read it when running `/trailhead:config` or when you need a key's exact meaning. `/trailhead:config` with no args runs the guided setup; `config get` prints the merged config; `config set <key> <value>` writes one key.
8
+ Load the effective config at the start of a work session, **from the map's project root** (`.trailhead/config.json` at the superproject repo root) plus the global file, **before** any isolation workspace is set up. **Config is a property of the project/map, not the working directory**: an `isolation: worktree`/`clone` workspace **inherits** the config loaded here and must **never re-resolve it from the isolated copy's own root**. A per-ticket clone is always a clone of the **superproject** (never of a submodule alone), so its `.trailhead/config.json` is present when the project commits one and absent when it doesn't; either way re-resolving there is wrong, because the workspace must reuse the config already resolved from the original checkout, not load it afresh (an absent file would silently fall back to defaults, which is exactly how a `design: artifacts` project ends up wrongly using `disk` in a clone). Config **writes** too (e.g. caching `design.project`) target the project's `.trailhead/config.json` in the original checkout, never the clone. **The main session orchestrates and holds the HITL moments** (the `build`/`bug` Discuss's "stop and ask", Verify's acceptance/UAT); **every model key runs as a subagent** (`plan`, `execute` (an *executor subagent* implementing with atomic commits on `models.execute`), `research`, `review`, `debug`, `verify`, `codebase-map`) so the whole per-activity model split applies in one session whatever model it runs on. Run Execute inline only when `models.execute` is unset or equals the session model. **On a subagent-less host** (`subagentToolkit == none`) there is nothing to fan out into: every activity runs inline. **Separately, on a host that can't honour the model keys** (`honorsModelKeys == false`, e.g. Codex, whose subagents run on its own OpenAI models) every `models.*` key collapses to the single session model even though the activities still fan out; when any `models.*` is set there the engine surfaces a **one-time** session-start notice that the split is not taking effect (the keys stay in `.trailhead/config.json` for when the project next runs on Claude Code). On Codex the per-activity split is available through a parallel `models.codex.*` namespace (OpenAI model ids), the honoured namespace there (projected into per-technique `~/.codex/agents/*.toml` and dispatched at runtime by `agent_type`), while `models.*` (Claude ids) still collapse to the single session model; the collapse notice points at `models.codex.*` and goes silent once it is set. A host without a hook bus (`hookBus == none`) also runs a lightweight inline update check at session start (no SessionStart hook, no statusline). After an update changes the tier defaults, a pinned-model review offer surfaces too, once per session and until the user answers it (see `../_shared/load-first.md` for the check/ack sequence and `configuration-reference.md`'s Pinned model review). See `configuration-reference.md`. The **keys, their values, the model/tdd/acceptance semantics, and the guided menu setup live in `configuration-reference.md`**: read it when running `/trailhead:config` or when you need a key's exact meaning. `/trailhead:config` with no args runs the guided setup; `config get` prints the merged config; `config set <key> <value>` writes one key.
@@ -13,7 +13,7 @@ gh issue list --label "trailhead:ticket" --label "trailhead:map-<n>" --state ope
13
13
  --search "no:assignee -label:trailhead:blocked -label:trailhead:unverified"
14
14
  ```
15
15
 
16
- **Active map.** Which map a session works is the **active map**: a `.trailhead/active-map` marker at the working root (one line `#<n>`, **gitignored**, per-session local state like `session-ticket`, never committed). `/trailhead:work` and `/trailhead:map` default to it; naming a map/ticket explicitly always overrides. Each checkout/clone (so each teammate) has its own.
16
+ **Active map.** Which map a session works is the **active map**: a `.trailhead/active-map` marker at the working root (one line `#<n>`, **gitignored**, per-session local state like `session-ticket`, never committed). `/trailhead:work` and `/trailhead:map` default to it; naming a map/ticket explicitly always overrides. A named ticket that carries a `trailhead:map-<n>` label makes that map the active map (write `.trailhead/active-map`); a whiteboard ticket leaves the active map alone. Each checkout/clone (so each teammate) has its own.
17
17
 
18
18
  **Park & switch** = **pause** the in-flight ticket (`/trailhead:pause`, a `PAUSED` checkpoint), then point the active map at the other's number. Nothing else to save: every map lives on the Issues, durable. Resume later with `/trailhead:resume`, or just `/trailhead:work` once that map is active again.
19
19
 
@@ -1,6 +1,6 @@
1
1
  ## Session handoff
2
2
 
3
- Resolving a ticket **ends the session**: one ticket per session is a hard rule (see [Principles](principles.md)). So every resolution closes the same way. Render every command in this ritual in this host's command forms (the **Host command forms** rule in `load-first.md`). After the resolution comment + `gh issue close` + the `Decisions so far` update, **remove the session-ticket marker** (`.trailhead/session-ticket` at the working root, if you wrote one, see Mode 2), then **always** sign off with, in order:
3
+ Resolving a ticket **ends the session**: one ticket per session is a hard rule (see [Principles](principles.md)). So every resolution closes the same way. Render every command in this ritual in this host's command forms (the **Host command forms** rule in `load-first.md`). After the resolution comment + `gh issue close` + the `Decisions so far` update, **remove the session-ticket marker** (`.trailhead/session-ticket` at the working root, if you wrote one, see Mode 2) and **clear the work state** (`node <templates>/trailhead-work-state.js clear --repo <working-root>`, see **Work state file** in `teamwork.md`), then **always** sign off with, in order:
4
4
 
5
5
  1. **A short recap of what was done** (2 to 4 lines) for the resolved ticket: the change in plain language, the files or areas touched (when applicable), and the outcome (verified / released / next step). Keep it **result-oriented**: say what changed and what it means, never trailhead's internal machinery (no mode or step names, no engine-role or technique names). It **augments** the ritual (it does not replace anything below): the recap sits above the one-line confirmation and gives the user a quick account of the ticket without reconstructing it from the commits or the issue timeline. It rides with a **resolution** only; a decision-ticket resolution may touch no files, hence "when applicable", and a capture or research batch (which never reach this ritual) carry no recap. It also carries forward any **pending follow-up** the Pending follow-up guard below identified, so a follow-up surfaced while working never has to be reconstructed from scrollback.
6
6
  2. **A one-line confirmation** the ticket is resolved, by name and number, both visible (e.g. *Add login rate limit* (#45), never the name alone nor a bare `#number`).
@@ -49,8 +49,8 @@ With the default `auto` this choice is made for you at each ticket's work-start;
49
49
 
50
50
  ## Pausing & resuming
51
51
  Switching away from a ticket mid-work (to clear a blocker, chase an urgent bug, or just stop) must not lose the thread.
52
- - **Pause** (`/trailhead:pause [note]`): first commit any work-in-progress (atomic) so nothing is stranded, then post a **`PAUSED`** checkpoint comment: what's done, the exact next step, and any local state (branch, **worktree path under `isolation: worktree`**, how to run it). Keep the claim if you'll return soon; **release it** (unassign) if it's open-ended, so someone else can resume; the checkpoint is what makes that safe. If you release, also remove the `.trailhead/session-ticket` marker (SKILL.md Mode 2); if you keep the claim, leave it. **If the paused ticket is a `trailhead:whiteboard` quick that has deferred its dashboard refresh to a handoff it is not reaching this session** (born by `quick`, resolution refresh not yet done), refresh the dashboard now (full regeneration from the live tracker) so the unfinished quick shows on the pinned index: the read-only renders never rewrite the dashboard body, so pause is what surfaces it.
53
- - **Resume** (`/trailhead:resume [ticket]`): read the ticket's latest `PAUSED` checkpoint (and the `DISCUSS`/`PLAN` comments above it), then pick up at the recorded next step. Anyone may resume a *released* ticket; a still-claimed one, only its owner. **Re-write the `.trailhead/session-ticket` marker** at the working root (SKILL.md Mode 2 step 2) so the resumed session shows in tooling like the statusline (a released pause removed it); under `isolation: worktree`/`clone`, also re-enter the ticket's recorded workspace.
52
+ - **Pause** (`/trailhead:pause [note]`): first commit any work-in-progress (atomic) so nothing is stranded, then post a **`PAUSED`** checkpoint comment: what's done, the exact next step, and any local state (branch, **worktree path under `isolation: worktree`**, how to run it). Keep the claim if you'll return soon; **release it** (unassign) if it's open-ended, so someone else can resume; the checkpoint is what makes that safe. If you release, also remove the `.trailhead/session-ticket` marker (SKILL.md Mode 2); if you keep the claim, leave it. Either way, set the work state `--step paused` and keep the file. **If the paused ticket is a `trailhead:whiteboard` quick that has deferred its dashboard refresh to a handoff it is not reaching this session** (born by `quick`, resolution refresh not yet done), refresh the dashboard now (full regeneration from the live tracker) so the unfinished quick shows on the pinned index: the read-only renders never rewrite the dashboard body, so pause is what surfaces it.
53
+ - **Resume** (`/trailhead:resume [ticket]`): read the ticket's latest `PAUSED` checkpoint (and the `DISCUSS`/`PLAN` comments above it), then pick up at the recorded next step. Anyone may resume a *released* ticket; a still-claimed one, only its owner. **Re-write the `.trailhead/session-ticket` marker** at the working root (SKILL.md Mode 2 step 2) so the resumed session shows in tooling like the statusline (a released pause removed it), and set the work state to the recorded next step, in the full work-start form (`--map`, `--ticket`, `--title`, `--step <next step>`) so the file is re-created when absent; under `isolation: worktree`/`clone`, also re-enter the ticket's recorded workspace.
54
54
  - One ticket per session still holds: pausing A to work B ideally means B in a fresh session. If you must switch within one session, checkpoint A first; never leave it half-done and unrecorded.
55
55
 
56
56
  ## Parking & switching between maps
@@ -97,3 +97,5 @@ The map issue's **body** is a shared mutable document: two sessions appending to
97
97
  **Keeping the guard current (migration).** The guard filters at **job level** (`jobs.guard.if`: a `trailhead:` label, a sender other than the repo owner, not in `TRAILHEAD_LABEL_ALLOWLIST`), because a skipped job is not billed while a job that starts and returns early from its script costs at least one Actions minute; the in-script permission check stays the real defence. Guards installed before 0.12.1 lack that `if:` and start a runner on **every** label event, which with trailhead labelling all the time runs into thousands of billed runs a month. So whenever the guard is present (every chart/adopt, and after `/trailhead:update`), run `node <templates>/trailhead-label-guard-sync.js --repo <working-root>` (same `<templates>` lookup as the commit-msg sync script below). It prints one JSON status line: `current` (nothing to do), `outdated` (offer the upgrade and always explain why in the question, in plain words: today every label added to an issue starts a run billed at least one minute even when it does nothing, trailhead labels constantly so that adds up to thousands of billed runs a month and can exhaust the Actions minutes, and the updated guard skips irrelevant events before a runner starts with the same protection), `custom` (has the job-level filter but differs from the template: leave it, mention it only if asked), `foreign` (not a trailhead workflow: never touched), `absent` (install as above). On go-ahead for `outdated`, re-run it with `--apply` (it rewrites the file from the template in the working tree only, never a foreign or customised guard), then commit it (`fix: skip trailhead label guard job for irrelevant label events`) and push, with the same `workflow`-scope caveat. The SessionStart hook (or, on a host with no hook bus, the load-first check) also runs it with `--notice` at every session start and surfaces the same upgrade offer until the user answers it; `--ack` records the answer in the gitignored `.trailhead/label-guard-ack` (the guard's hash), so a declined offer comes back only if the file changes. If the script is missing (an outdated install), fall back to reading the file and checking `jobs.guard` for an `if:` containing `startsWith(github.event.label.name, 'trailhead:')`.
98
98
 
99
99
  **The commit-msg git hook (host-independent commit guard).** On every host trailhead ALSO installs a git **`commit-msg`** hook as a host-independent backstop (defence in depth alongside the host's own `PreToolUse` guard on Claude Code and Codex alike), enforcing the two rules (a Conventional Commits subject of at most 72 chars; never a `Co-Authored-By` trailer) plus, while a `.trailhead/session-ticket` marker is present at the worktree root, a `Refs: #<n>` trailer matching its number, on every `git commit`, whatever host drives it (decision #16). **Every chart or adopt, and at every `work`/`quick` ticket start, run the sync script**: `node <templates>/trailhead-commit-msg-sync.js --repo <working-root>`, where `<templates>` is the first of `${CLAUDE_PLUGIN_ROOT}/templates/`, `~/.claude/trailhead/templates/`, `~/.codex/skills/trailhead/templates/` that contains `trailhead-commit-msg-sync.js`: try all three in order, skipping the first when `CLAUDE_PLUGIN_ROOT` is unset or empty (it is often absent from the Bash environment), and never stop at the first miss. It prints one JSON status line and handles every case itself: absent -> installs it; an older trailhead hook (recognised by its own header line, not by trusting the filename) -> upgraded in place; already current -> left alone; a foreign (non-trailhead) hook -> never touched, only reported (offer to chain it); under a repo's `core.hooksPath`, an existing trailhead hook there is still upgraded in place, but nothing is newly added to that directory. Unlike the label guard, `.git/hooks/` is not version-controlled, so this is a per-clone local install with nothing to commit. **If the sync script is missing (none of the three dirs has it: an outdated install) or node errors, never claim git enforces nothing before looking**: resolve the effective hooks dir with `git -C <working-root> rev-parse --git-path hooks` (resolve a relative output against the working root; it honours `core.hooksPath` and the git common dir shared by linked worktrees), read `<hooks dir>/commit-msg`, and classify it by its header line (a trailhead hook has `// trailhead commit-msg hook (git).` among its first 5 lines, trimmed; never trust the filename alone; a symlinked `commit-msg` counts as foreign, as the script treats it). Report one result-oriented line: (a) trailhead hook present and executable (`test -x`): git does enforce trailhead's rules here, but its freshness could not be checked or upgraded, so suggest updating the trailhead install; a trailhead hook that is NOT executable: git skips it, so it does not enforce trailhead's rules here (suggest updating the install so the sync script can fix the mode); (b) a foreign hook (or a symlink): left untouched, git does not enforce trailhead's rules here; (c) no hook: git does not enforce trailhead's rules here (suggest updating the install so the sync script can install it). Never blocks the work.
100
+
101
+ **Work state file (the ticket in play, for tooling).** Alongside the session-ticket marker, trailhead keeps a gitignored `.trailhead/work-state.json` at the working root recording the one ticket in play: `{map, ticket, title, step, auto, autoDone, session, updatedAt}` (`autoDone` is the number of tickets resolved so far in an autonomous run, `0` otherwise). It is independent of `session-ticket` and of the commit-msg hook, and written the same way on Claude Code and Codex by the template helper `trailhead-work-state.js`, found with the same three-dir `<templates>` lookup as the commit-msg sync above (the first of `${CLAUDE_PLUGIN_ROOT}/templates/`, `~/.claude/trailhead/templates/`, `~/.codex/skills/trailhead/templates/` that contains it). Forms: `node <templates>/trailhead-work-state.js set --repo <working-root> --map <n|none> --ticket <n> --title "<title>" --step discuss` at work-start (`--map none` for a whiteboard ticket), `node <templates>/trailhead-work-state.js set --repo <working-root> --step <step>` at each step change (`discuss`, `plan`, `execute`, `verify`, `resolve`, `paused`; it merges onto the file, and a different `--ticket` starts it fresh; it needs a ticket on file, so where the file may be absent, as at resume or a pause in a fresh workspace, pass the full work-start form with that step), and `node <templates>/trailhead-work-state.js clear --repo <working-root>` at Resolve. During an autonomous run every `set` adds `--auto true --auto-done <n>`, `n` being the tickets resolved so far in this run. The step-to-state mapping per ticket type lives in `trailhead-work/references/ticket-engines.md`. A missing helper or a non-zero exit is silent and never blocks the work (no user-facing line).
@@ -17,7 +17,7 @@ Automated tests prove the code does what the *code* intended; acceptance testing
17
17
  - **When the human can only run it later** (on-device, hardware you don't have right now), record the full numbered checklist in the `VERIFY` comment as the durable artifact and mark UAT **explicitly pending**, but the walkthrough stays conversational **when they come to run it**: never shrink it to a vague one-liner ("just check it on the device"), and never let "automated passed" quietly stand in for it. Deferring *where/when* the human runs it is fine; replacing the live step-by-step with a self-serve checklist is not.
18
18
  - **Pending UAT must stay tracked: a closed ticket is not tracking.** Don't resolve/close a user-facing ticket on unconfirmed acceptance and leave the checklist as a comment on the closed issue, where nobody will look. The default is to **keep the ticket open** until the human confirms the UAT passes (closing on green you didn't see is a premature close). **When UAT hasn't been run at Resolve, pose the choice to the human and wait for an explicit answer, never decide it for them:** (a) **run the UAT now**, in this session, with no ticket (opens with the drive-mode ask above, then the guided conversational walkthrough or AI-driven checks, resolving only on a confirmed pass; a failing step becomes a fix or a `bug` follow-up and an incomplete/blocked step is marked pending and tracked, per the failing-step and partial-run rules above, never a silent close), or (b) **open a UAT ticket** to run it later. **Never open a UAT ticket without asking, and never let silence or an ambiguous reply default to either path.** Only when the human picks (b) do you **open a follow-up ticket before that close** that carries the pending UAT and links back to the parent with a `UAT of: <parent name>(link)` pointer in the body. Route it the way `../choices.md` routes a deferred choice: a **`trailhead:seed`** (kept blocked) when the run is gated on a future external trigger not yet true (hardware you don't have, a device out of reach), or a follow-up **`task`** on the frontier when it's just scheduled or batched work you could pick up any time. Either way the follow-up **carries the full numbered checklist and, when it comes to resolution, opens with the drive-mode ask above before running the guided conversational walkthrough**, never a self-serve check-off. **Never close a user-facing ticket on a chosen-deferred UAT with nothing opened**: the parent may close as agreed, but the owed UAT stays visible on the tracker as its own ticket, linked to the parent, until it is actually performed. The pending check must be visible on the tracker, not buried.
19
19
 
20
- **Mockup-fidelity check (when the ticket had an approved mockup).** If the change was preceded by an approved mockup (the **Prototype** technique produced one and it was approved and recorded at Execute), acceptance testing MUST check the built screen **against that approved mockup**, not merely against "what the user wanted" in the abstract. Pull the mockup's current state to compare against (re-fetch it in `claude.ai/design` / `stitch` mode via the technique's re-fetch rule, or open the linked `disk` mockup); never compare from memory. Walk it **element by element and state by state**, layout, spacing, sizing, colour, typography, copy, and every state it shows (empty, loading, error, hover, active, disabled, and the like), enumerating from the approved mockup itself (the spec) and cross-checking the executor's recorded Execute-step fidelity list and any element it flagged infeasible, and confirm each is reproduced. Record the per-element and per-state result in the `VERIFY` comment. Any **unforced** deviation is an acceptance finding, never waved through as "close enough"; a genuinely infeasible part must already have been raised with the user at Execute (per the Prototype technique), not surface here as a silent drift.
20
+ **Mockup-fidelity check (when the ticket had an approved mockup).** If the change was preceded by an approved mockup (the **Prototype** technique produced one and it was approved and recorded at Execute), acceptance testing MUST check the built screen **against that approved mockup**, not merely against "what the user wanted" in the abstract. Pull the mockup's current state to compare against (re-fetch it in `artifacts` / `stitch` mode via the technique's re-fetch rule, or open the linked `disk` mockup); never compare from memory. Walk it **element by element and state by state**, layout, spacing, sizing, colour, typography, copy, and every state it shows (empty, loading, error, hover, active, disabled, and the like), enumerating from the approved mockup itself (the spec) and cross-checking the executor's recorded Execute-step fidelity list and any element it flagged infeasible, and confirm each is reproduced. Record the per-element and per-state result in the `VERIFY` comment. Any **unforced** deviation is an acceptance finding, never waved through as "close enough"; a genuinely infeasible part must already have been raised with the user at Execute (per the Prototype technique), not surface here as a silent drift.
21
21
 
22
22
  Acceptance failures are findings like any other: a `bug` follow-up or a fix on this ticket before it resolves.
23
23