task-pipeline-skill 1.96.0 → 1.97.1

package/CHANGELOG.md

@@ -1,3 +1,40 @@
+## v1.97.1 — 2026-10-17
+
+The same source as v1.97.0, plus its release declaration. The v1.97.0 tag failed its own release run
+([38976060549](https://github.com/ssheleg/task-pipeline/actions/runs/38976060549)): `retro.md` named no
+release after its newest stamp, so the validator on the tag's tree refused and `publish` was skipped. Tags
+are immutable here, so v1.97.0 stays as a failed tag and this patch carries the declaration (the v1.94.0 →
+v1.94.1 precedent). No doctrine change.
+
+## v1.97.0 — 2026-10-16
+
+Source candidate; not published.
+
+Guards: 447 → **448**; property checks 15 → **15**.
+
+The look now runs on WebKit first. Every browser example in the bundle opened the
+tool's default engine, a Chromium-family browser, and `chrome-devtools` drives Chrome
+only — so the look the pipeline taught was a Chromium look reported as *tested in a
+browser*, and a layout that breaks only in Safari passed it. `references/browser.md`
+opens with *Engine order — WebKit (Safari) first*: Safari through `safaridriver` for a
+real browser, Playwright's `webkit` for automation (`playwright-cli open --browser
+webkit`, the MCP's `--browser webkit`, read from each tool's `--help`), Safari Web
+Inspector for debugging, and `open -a Safari` instead of the system default browser.
+Chromium is a stated exception — Lighthouse, a CDP trace, a heap snapshot, a
+Chrome-only API — named with its reason, on a temporary profile the run closes; a
+surface checked only in Chromium is reported as exactly that. The recipe, the
+sign-in example and the library example (`const { webkit } = require('playwright')`)
+now open WebKit.
+
+`references/companion-skills.md` makes `playwright` on WebKit the default look and
+`chrome-devtools` the stated Chromium exception, in the matrix, the preflight lines
+and the one rule for both channels; stages 5, 6 and 8, `tdd.md`, the README, the
+Cursor rule, the skill card and the contact-sheet template say the same. `DEC-0007`
+records the order: the engine is ranked, the tools' quality still is not, so
+`DEC-0004` keeps its other two parts. The new guard holds the section above the model
+and the recipe's `--browser webkit`; its negative self-test strips the flag and
+requires the validator to refuse.
+
 ## v1.96.0 — 2026-10-15
 
 Source candidate; not published.

package/README.md

@@ -280,14 +280,17 @@ and neither can a **browser test suite**, which asserts what someone wrote down
 counted as coverage rather than as the look. Absent, the run says *"verified by reading
 the diff"* — a weaker claim, recorded as one.
 
-There are **two channels and either is enough**, ranked by nothing: `playwright`
-(`npm install -D @playwright/cli@latest`, or
-`claude mcp add playwright npx @playwright/mcp@latest`) needs no plugin and is already
-there on a project that runs Playwright, and its CLI half puts no tool schema in the
-context window; `chrome-devtools`
-(`/plugin install chrome-devtools-mcp@claude-plugins-official`) is the one that reaches
-past the page to Lighthouse and heap snapshots, and analyses a performance trace rather
-than only recording one. Neither is a gate,
+There are **two channels and either is enough**, and the **engine** is ranked:
+**WebKit (Safari) first, Chromium a stated exception**. `playwright`
+(`npm install -D @playwright/cli@latest` then `playwright-cli open --browser webkit`, or
+`claude mcp add playwright -- npx @playwright/mcp@latest --browser webkit`) is the default
+look: it reaches WebKit, needs no plugin, is already there on a project that runs
+Playwright, and its CLI half puts no tool schema in the context window; on macOS Safari
+itself is driven through `safaridriver`. `chrome-devtools`
+(`/plugin install chrome-devtools-mcp@claude-plugins-official`) drives Chrome only and is
+reached for when the question needs Chrome — Lighthouse, heap snapshots, a performance
+trace analysed rather than only recorded — said with the reason; a look taken only there
+is reported as *checked in Chromium*. Neither is a gate,
 and a CLI, a library or a backend service is never offered either.
 
 **The wiki is [obsidian-wiki](https://github.com/ar9av/obsidian-wiki)** (Karpathy's

package/SKILL-CARD.md

@@ -12,9 +12,9 @@ harmless.
 |---|---|
 | **Purpose** | Runs a substantial task through ten gated delivery stages — intake grill, docs study, brainstorm, spec, plan, subagent build, tests, lint/deploy, post-deploy, docs+registers, acceptance — refusing to advance until each gate passes |
 | **Owner** | ssheleg ([github.com/ssheleg/task-pipeline](https://github.com/ssheleg/task-pipeline)) |
-| **Version** | 1.96.0 |
+| **Version** | 1.97.1 |
 | **Surface** | Claude Code (filesystem skill + plugin) and the vercel `skills` CLI. **Not** uploaded to the Skills API; custom Skills do not sync across surfaces |
-| **Dependencies** | None required. Optional: `context7` (MCP), `figma` (MCP), super-ux, agent-sync, graphify, obsidian-wiki, and **one of two browser channels** — `playwright` (CLI or MCP) or `chrome-devtools` (MCP); either satisfies the browser step and neither is required. Every stage's doctrine ships in-repo; user-facing stage 3 requires a valid scenario artifact; super-ux is preferred, with equivalent-provider and inline-fallback paths under the provider contract |
+| **Dependencies** | None required. Optional: `context7` (MCP), `figma` (MCP), super-ux, agent-sync, graphify, obsidian-wiki, and **one of two browser channels** — `playwright` (CLI or MCP) or `chrome-devtools` (MCP); either satisfies the browser step and neither is required. The engine is WebKit (Safari) first; `chrome-devtools` is Chrome-only, a stated exception. Every stage's doctrine ships in-repo; user-facing stage 3 requires a valid scenario artifact; super-ux is preferred, with equivalent-provider and inline-fallback paths under the provider contract |
 | **Evaluation status** | Suite authored, 5 categories. One recorded run, **self-observed by the author**; **zero blind runs on zero of three models** — the split, and the numbers, live in [`evals/RESULTS.md`](evals/RESULTS.md) and are computed by `evals/run.py` |
 
 ## Risk-tier disclosure

package/cursor/rules/task-pipeline.mdc

@@ -272,13 +272,17 @@ not authorize an outward, irreversible action — stage 7 stops and asks.
    look. With a browser channel connected: load the surface, snapshot it, read the
    console and the network log, and quote what you read. Fix what the look finds
    before calling the stage green. Without one, say "verified by reading the diff" and
-   treat that as the weaker claim it is. Two channels, either is enough, ranked by
-   nothing: `npm install -D @playwright/cli@latest` (or
-   `claude mcp add playwright npx @playwright/mcp@latest`) needs no plugin, and its CLI
-   half puts no tool schema in the context window;
-   `/plugin install chrome-devtools-mcp@claude-plugins-official` is the one that
-   reaches Lighthouse and heap snapshots, and analyses a trace rather than only
-   recording one. Never a gate. A CLI, a
+   treat that as the weaker claim it is. Two channels, either is enough, on WebKit
+   (Safari) first with Chromium a stated exception: `npm install -D @playwright/cli@latest`
+   then `playwright-cli open --browser webkit <url>` (or
+   `claude mcp add playwright -- npx @playwright/mcp@latest --browser webkit`) is the
+   default look, needs no plugin, and its CLI half puts no tool schema in the context
+   window; on macOS, Safari itself through `safaridriver`, and `open -a Safari <url>`
+   rather than the system default browser for a person.
+   `/plugin install chrome-devtools-mcp@claude-plugins-official` drives Chrome only and
+   is reached for when the question needs Chrome — Lighthouse, heap snapshots, a trace
+   analysed rather than only recorded — said with the reason; a look taken only there
+   is reported as "checked in Chromium", never "tested in a browser". Never a gate. A CLI, a
    library or a backend service is never offered either.
 7. **Lint + deploy** (manual) — lint clean AND suite green before deploy; deploy is
    outward → explicit user go, or the specific standing authorization recorded in

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "task-pipeline-skill",
-  "version": "1.96.0",
+  "version": "1.97.1",
   "description": "Full-cycle delivery pipeline for coding agents: a mandatory built-in intake grill, then 10 gated stages (docs, brainstorm+decompose, spec, plan, build, tests, lint/deploy, post-deploy, docs/wiki, acceptance). Every stage's doctrine ships inside the skill — no companion plugin required. This package is the installer CLI.",
   "bin": {
     "task-pipeline": "bin/task-pipeline.js"

package/plugins/task-pipeline/.claude-plugin/plugin.json

@@ -3,7 +3,7 @@
   "name": "task-pipeline",
   "displayName": "Task Pipeline",
   "description": "Runs a substantial task through a mandatory built-in intake grill, then 10 gated stages (docs, brainstorm+decompose, spec, plan, subagent build, tests, lint/deploy, post-deploy, docs/wiki, acceptance). Every stage's doctrine is built into the skill — no companion plugin required — with typed auto/judgment/manual gates, a frozen requirement spine that closes with evidence, a work board and a verification ledger that outlive a run, an exposure line naming what shipped unconfirmed, a progress rail computed from the project's own config, a loop guard whose review ceiling measures rather than stops, and stage-3 tracks for what a product does, how it sounds and how it looks. Two modes need no task: `checkup` (what is unverified) and `setup` (audit existing docs); a third, `waves`, takes the whole board and closes it in waves that each finish in one pass. Retro insights can publish upstream as issues, opt-in and redacted.",
-  "version": "1.96.0",
+  "version": "1.97.1",
   "author": {
     "name": "ssheleg",
     "url": "https://x.com/sshlg93"

package/plugins/task-pipeline/skills/task-pipeline/references/browser.md

@@ -12,7 +12,9 @@ which is how a run says *I checked the browser* and means *I ran the unit tests*
 > **Every command and flag below was read from the tool's own `--help`**, not from a
 > vendor page. Where the two disagreed, `--help` won and the page was wrong — see
 > *Rationalizations*. Re-derive before quoting:
-> `npx @playwright/cli@latest --help` and `npx @playwright/mcp@latest --help`.
+> `npx @playwright/cli@latest --help` and `npx @playwright/mcp@latest --help`. The
+> `--browser webkit` flag on both was last read from `@playwright/cli` 0.1.22 (`open
+> --help`) and `@playwright/mcp` 0.0.83 on 2026-10-16.
 >
 > **Use the scoped name with `npx`.** `npx playwright-cli --help` fails outside a project
 > that has already installed it (`could not determine executable to run`), and the bare
@@ -23,6 +25,7 @@ which is how a run says *I checked the browser* and means *I ran the unit tests*
 
 ## Contents
 
+- Engine order — WebKit (Safari) first
 - The one model: a tree, and a ref
 - The look, as commands you can run
 - Sessions, and why an agent needs them
@@ -35,6 +38,35 @@ which is how a run says *I checked the browser* and means *I ran the unit tests*
 - What the channel can reach — the part a recommendation owes you
 - Rationalizations
 
+## Engine order — WebKit (Safari) first
+
+**Check a rendered surface in WebKit first** (`DEC-0007`). The channel is how a look
+arrives; the engine is what renders it, and the two are separate choices:
+
+| Need | WebKit route — the default |
+|---|---|
+| A real browser | Safari itself, through `safaridriver` (WebDriver; enable it once with `sudo safaridriver --enable`) |
+| Automation, the look | Playwright's `webkit`: `playwright-cli open --browser webkit <url>`, the MCP started with `--browser webkit`, a `webkit` project in `playwright.config.*`. Install the engine with `playwright-cli install-browser webkit` or `npx playwright install webkit` |
+| Debugging | Safari Web Inspector |
+| A page for a person, on macOS | `open -a Safari <url>` — never bare `open <url>`, which hands the page to the system default browser, and the default may be another browser |
+| An automation library (browser-use and the like) | its WebKit or Safari backend, where it has one |
+
+Name the engine every time. Without `--browser`, the CLI falls back to a Chromium-family
+browser (read from its own bundle, 0.1.22, not from `--help`) — so a recipe that leaves
+the flag off has chosen Chromium without saying so. Playwright's `webkit` is the engine,
+not Safari itself: a question about Safari's own behaviour goes to `safaridriver`.
+
+**Chromium is a stated fallback, never the default.** Use it only when the task needs
+Chrome itself — a Chrome-only API, Lighthouse, a CDP performance trace, a heap snapshot,
+the `chrome-devtools` MCP — and say which and why in the verdict. Prefer the Chrome Dev
+build for that. When you launch your own Chrome or Chromium for a UI run, give it a
+temporary profile (never the user's), record what you started, and close every process
+you started before you finish ([`residue.md`](residue.md)).
+
+**A surface checked only in Chromium is reported as exactly that** — *"checked in
+Chromium (`chrome-devtools`, for `lighthouse_audit`)"*, never *"tested in a browser"*.
+The engine is part of the claim, the same way the command is.
+
 ## The one model: a tree, and a ref
 
 **Both channels drive the page through its accessibility tree, not its pixels.** You ask
@@ -68,14 +100,15 @@ The pipeline asks for the same four things every time: **open it, snapshot it, r
 console, read the network.** In the CLI that is literally four commands:
 
 ```bash
-playwright-cli open http://localhost:3000/checkout
+playwright-cli open --browser webkit http://localhost:3000/checkout
 playwright-cli snapshot
 playwright-cli console warning     # min-level: only warnings and errors
 playwright-cli requests            # then: request <n> for headers, body, response
 ```
 
 The MCP is the same four moves under different names: `browser_navigate`,
-`browser_snapshot`, `browser_console_messages`, `browser_network_requests`.
+`browser_snapshot`, `browser_console_messages`, `browser_network_requests` — on WebKit
+when the server was started with `--browser webkit`.
 
 **Quote what you read, not that you looked.** *"Console clean, all requests fine"* is a
 claim. *"`console warning` → empty; `requests` → no status ≥ 400"* is the same claim with
@@ -87,8 +120,9 @@ resources by default and says so in its own footer (*"N static request(s) not sh
 appears without the flag — so *no status ≥ 400* is a safe claim and *14 requests* is not.
 
 `chrome-devtools` takes the identical four moves — `navigate_page`, `take_snapshot`,
-`list_console_messages`, `list_network_requests` — which is why the matrix ranks neither:
-the look is the same look.
+`list_console_messages`, `list_network_requests` — but only in Chrome. The moves are the
+same look; the engine is not, so for the look it is the **stated Chromium exception**,
+reached for when the question needs Chrome (*Engine order*, above).
 
 ## Sessions, and why an agent needs them
 
@@ -130,17 +164,17 @@ commonest way a run reports a green it does not have.
 |---|---|---|---|
 | **The look** | an agent driving a page: open, snapshot, console, network | that this surface renders, right now, and what the browser said while it did | the **functional look**, stage 6 — recommended, never a gate. Its **visual half** is a gate on a `flagship`, `product` or `ad` surface — *The visual half*, below |
 | **The spec suite** | `playwright test` — the **test runner** | that the assertions someone wrote still hold, on the paths someone thought to write | the **suite** half of the stage-6 gate, counted with every other test |
-| **The library** | `require('playwright')` — `chromium`/`firefox`/`webkit`, `devices`, `request`, `selectors` | whatever your own script asserts; it is an automation API, not a test framework | wherever the project already runs it |
+| **The library** | `require('playwright')` — `webkit`/`chromium`/`firefox`, `devices`, `request`, `selectors` | whatever your own script asserts; it is an automation API, not a test framework | wherever the project already runs it |
 
-The library and the runner are **separate APIs** — a script built on `chromium.launch()`
+The library and the runner are **separate APIs** — a script built on `webkit.launch()`
 has no `expect`, no fixtures, no reporter, and no retry. Choosing the library where a
 runner was wanted is how a project ends up with a bespoke half-runner nobody trusts.
 
 The minimal library shape, for reading a script that already exists:
 
 ```js
-const { chromium } = require('playwright');
-const browser = await chromium.launch();
+const { webkit } = require('playwright');
+const browser = await webkit.launch();
 const page = await browser.newPage();
 await page.goto('http://example.com');
 await browser.close();
@@ -186,7 +220,8 @@ the close-out — the same rule as every other refusal in the pipeline.
 
 1. **Deterministic.** The project linter — `python3 scripts/visual_gate.py lint <dir>`,
    which runs sheleg-design's `--lint` where it is installed and answers **NOT_RUN (exit 3)**
-   where it is not — plus axe or Lighthouse, the token check, the type checker. An S1
+   where it is not — plus axe or Lighthouse (the stated Chromium exception), the token
+   check, the type checker. An S1
    finding blocks, whatever anyone says about the picture later. **With Figma on, the
    token check includes the drift probe**: `python3 scripts/visual_gate.py tokens
    --figma <variables.json> --css <tokens.css>` compares the variable names exported
@@ -266,7 +301,7 @@ and neither needs a password in a transcript.
 
 ```bash
 mkdir -p .auth                                  # state-save does not create it
-playwright-cli open https://app.example.com/login
+playwright-cli open --browser webkit https://app.example.com/login
 #  … sign in by hand, or drive the form …
 playwright-cli state-save .auth/state.json      # cookies + localStorage
 playwright-cli state-load .auth/state.json      # every later look starts signed in
@@ -387,4 +422,6 @@ On a CI box, headed is the failure you will spend an hour on.
 | *"The tool list is in the docs."* | The page listed tools this version does not ship, and omitted that tracing, video and PDF need `--caps`. Ask the server: 24 tools default, 42 with all caps. |
 | *"It's behind a login, so the look isn't possible."* | `state-save` / `state-load`, or `--storage-state`. Auth is a solved step, not an exemption. |
 | *"No browser channel is installed, so the step doesn't apply."* | The step still applies; the claim weakens. Say *verified by reading the diff* and let the close-out record it as the weaker claim it is. |
+| *"Tested in a browser."* | Which engine? A look taken only in Chromium is reported as *checked in Chromium*, with the reason Chrome was needed. WebKit is the default (*Engine order*). |
+| *"I opened it with `open <url>`."* | That is the system default browser, which may not be Safari. `open -a Safari <url>` for a person; `--browser webkit` for automation. |
 | *"I closed the browser."* | `list` is the evidence. The command you typed is not the state you left ([`residue.md`](residue.md)). |

package/plugins/task-pipeline/skills/task-pipeline/references/companion-skills.md

@@ -27,6 +27,10 @@ one must never look alike.
 > **`DEC-0006`** scopes that to the functional look: the **visual half** is a gate on a
 > `flagship`, `product` or `ad` surface, and its absent tool reads NOT_RUN and stops to
 > ask rather than passing ([`browser.md`](browser.md) → *The visual half*).
+> **`DEC-0007`** ranks the **engine**, not the channel's quality: WebKit (Safari) first,
+> Chromium a stated exception. `playwright` reaches WebKit and `chrome-devtools` does
+> not, so `playwright` on WebKit is the default look and `chrome-devtools` is reached for
+> when the question needs Chrome ([`browser.md`](browser.md) → *Engine order*).
 
 ## Contents
 
@@ -70,8 +74,8 @@ one must never look alike.
 | **Figma** (MCP) | stage 3 UX track, when the project designs visually — super-ux mirrors each `SCR-` screen/state into a frame | Optional, **UI + Figma-on only**. Absent → super-ux degrades to text-only *by itself and never blocks*, so shipping a UI feature with no mockups becomes a silent scope call — which is why the stage-0 sweep decides it | connect the Figma MCP server (`/mcp`, or your claude.ai connectors) |
 | **[obsidian-wiki](https://github.com/ar9av/obsidian-wiki)** (`wiki-query`, `wiki-update`) | **stage 0 harvest** (query what's already known) **+ stage 9 sync** | **Recommended** — never a gate; absent → harvest runs on repo docs alone | `pip install obsidian-wiki` → `obsidian-wiki setup --vault /path/to/your/vault` |
 | **[graphify](https://github.com/Graphify-Labs/graphify)** (`/graphify`, `graphify query`, `graphify affected`, `graphify god-nodes`) | **stage 0 harvest** (reach: what calls this, what breaks if it moves) **+ stage 9 refresh + the graph↔docs divergence check** ([`knowledge-graph.md`](knowledge-graph.md)) | **Recommended** — never a gate; absent → the harvest greps instead, and the divergence axis is unavailable | `uv tool install graphifyy` → `graphify install` → `/graphify .` |
-| **playwright** (CLI — `playwright-cli open`, `snapshot`, `click`, `type`, and the two this pipeline actually asks for: `console` and `requests`; or MCP — `browser_navigate`, `browser_snapshot`, `browser_click`, `browser_console_messages`, `browser_network_requests`) | **stages 5–6 on any project with a web front end**, and **stage 8** on a deployed target — the same job as the row below: open the surface, snapshot it, read the console and the network log. Its own difference is **the channel a look arrives on**: the CLI is a shell command, so it does not put a tool schema in the context window the way an MCP channel does — that is upstream's own comparison and it is *CLI against MCP*, which makes it a claim about this row's own two halves before it is a claim about the row below. Both channels default to an **accessibility-tree snapshot rather than pixels**, so the ordinary look costs a page of text and no vision model; `screenshot` exists in both and costs one when you ask for it | **Recommended** — never a gate; absent → say the surface was verified **by reading the diff** and treat that as the weaker claim it is | CLI: `npm install -D @playwright/cli@latest` → `npx playwright-cli --help` (or `npm i -g` for the global binary; `playwright-cli install --skills` adds its agent skills, `--global` to the home directory). MCP: `claude mcp add playwright npx @playwright/mcp@latest` |
-| **chrome-devtools** (MCP — `list_pages`, `navigate_page`, `take_snapshot`, `take_screenshot`, `evaluate_script`, `list_console_messages`, `list_network_requests`, `lighthouse_audit`, `performance_start_trace`, `take_heapsnapshot`) | **stages 5–6 on any project with a web front end** — verify the **rendered** surface rather than the diff: computed layout, console errors, failed requests. **Stage 8** on a deployed web target: load the page and read what the browser did, not what the deploy said. Its own difference is **reach past the page**: a Lighthouse category (`lighthouse_audit`, which `seo-aeo-audit` builds on) and a heap snapshot have no equivalent in the row above. A performance trace has one — `playwright-cli tracing-start` records one — but only this row's arrives with `performance_analyze_insight` over it | **Recommended** — never a gate; absent → say the surface was verified **by reading the diff** and treat that as the weaker claim it is | `/plugin install chrome-devtools-mcp@claude-plugins-official` (or connect the MCP server directly) |
+| **playwright** (CLI — `playwright-cli open`, `snapshot`, `click`, `type`, and the two this pipeline actually asks for: `console` and `requests`; or MCP — `browser_navigate`, `browser_snapshot`, `browser_click`, `browser_console_messages`, `browser_network_requests`) | **The default route — WebKit first** (`DEC-0007`): `playwright-cli open --browser webkit`, or the MCP started with `--browser webkit`; on macOS, Safari itself through `safaridriver` and Safari Web Inspector to debug ([`browser.md`](browser.md) → *Engine order*). **Stages 5–6 on any project with a web front end**, and **stage 8** on a deployed target — the same job as the row below: open the surface, snapshot it, read the console and the network log. Its own difference is **the channel a look arrives on**: the CLI is a shell command, so it does not put a tool schema in the context window the way an MCP channel does — that is upstream's own comparison and it is *CLI against MCP*, which makes it a claim about this row's own two halves before it is a claim about the row below. Both channels default to an **accessibility-tree snapshot rather than pixels**, so the ordinary look costs a page of text and no vision model; `screenshot` exists in both and costs one when you ask for it | **Recommended** — never a gate; absent → say the surface was verified **by reading the diff** and treat that as the weaker claim it is | CLI: `npm install -D @playwright/cli@latest` → `npx playwright-cli --help` (or `npm i -g` for the global binary; `playwright-cli install --skills` adds its agent skills, `--global` to the home directory), then `playwright-cli install-browser webkit`. MCP: `claude mcp add playwright -- npx @playwright/mcp@latest --browser webkit` |
+| **chrome-devtools** (MCP — `list_pages`, `navigate_page`, `take_snapshot`, `take_screenshot`, `evaluate_script`, `list_console_messages`, `list_network_requests`, `lighthouse_audit`, `performance_start_trace`, `take_heapsnapshot`) | **The stated Chromium exception** — it drives Chrome only, so it is reached for when the question needs Chrome, said with the reason, and a look taken only here is reported as *checked in Chromium*. **Stages 5–6 on any project with a web front end** — verify the **rendered** surface rather than the diff: computed layout, console errors, failed requests. **Stage 8** on a deployed web target: load the page and read what the browser did, not what the deploy said. Its own difference is **reach past the page**: a Lighthouse category (`lighthouse_audit`, which `seo-aeo-audit` builds on) and a heap snapshot have no equivalent in the row above. A performance trace has one — `playwright-cli tracing-start` records one — but only this row's arrives with `performance_analyze_insight` over it | **Recommended** — never a gate; absent → say the surface was verified **by reading the diff** and treat that as the weaker claim it is | `/plugin install chrome-devtools-mcp@claude-plugins-official` (or connect the MCP server directly) |
 | **[agent-sync](https://github.com/ssheleg/agent-sync)** (`/agent-sync`, **≥ 1.3.0** — `finish` did not exist before it, so an older install turns the stage-10 close-out into a command that is not there) | **guarded registers** — a lease before writing one, `reserve` before minting an id, `reconcile`/`record` for intent vs as-built, and `finish` for the stage-10 multi-repository close-out ([`documentation.md`](documentation.md)) | **Recommended** — never a gate. Absent → the run is **`ungated`** and must say so out loud; the discipline still applies, only the arbitration is missing | `npx sshlg-skills install` |
 | **sheleg-dev** (`stripe-billing`, `crypto-payments`, `error-tracking`, `ad-tracking`, `google-signin`, `google-auth`, `frontend-performance`) | **stage 5 when the task wires money, tracking, sign-in or page speed** — the seams a generated integration gets wrong in ways no screen shows: the webhook is the payment, a thank-you-page event cannot know the charge cleared, a duplicated `event_id` counts revenue twice | **Recommended** — never a gate; absent → the integration ships on the host's own doctrine and the close-out names the seam nobody checked | `/plugin marketplace add ssheleg/sheleg-dev` → `/plugin install sheleg-dev@sheleg-dev` |
 | **agent-stack** (`agent-orchestrator`, `agent-evals`, `agent-interop`, `agent-harness`) | **stage 5 when the thing being BUILT is an agent system** — the orchestrator's loop, evals that say whether it got better, the protocols it speaks (MCP/A2A), the wallet under LLM resale. Not for coordinating the agents editing this repository (that is agent-sync, above) | **Recommended** — never a gate; absent → the agent layer ships unevaluated and the close-out says so | `/plugin marketplace add ssheleg/agent-stack` → `/plugin install agent-stack@agent-stack` |
@@ -94,11 +98,11 @@ required; an absent one is a check recorded as NOT_RUN with its reason.
 | `review-animations`, `improve-animations` | reviews motion against its intent: timing, easing, interruption, reduced-motion fallback | stage 6, on a surface with motion; findings as triples |
 | `mobile-native` | the mobile-web surface: viewport, safe areas, touch targets, keyboard-up states | stages 5–6, mobile-web frames of the matrix |
 | `animate-expo` | React Native and Expo motion, built and reviewed on the platform's own primitives | stage 5, an RN or Expo surface |
-| `webapp-testing`, `chrome-devtools` (`take_screenshot`, `lighthouse_audit`) | the frames of the matrix at each viewport and theme, and a Lighthouse pass as the deterministic floor | stage 6, the capture and the floor; stage 8 on a deployed target |
+| `playwright-cli open --browser webkit` + `screenshot`, `webapp-testing`; `chrome-devtools` (`lighthouse_audit`, the stated Chromium exception) | the frames of the matrix at each viewport and theme, captured in WebKit first, and a Lighthouse pass as the deterministic floor | stage 6, the capture and the floor; stage 8 on a deployed target |
 | `accessibility-review`, `a11y-debugging` | accessibility review of the rendered surface and debugging what it finds | stage 6, beside axe or Lighthouse |
 | XCUITest `performAccessibilityAudit` | the iOS platform's own accessibility audit, run in UI tests | stage 6, a native iOS surface |
 | Compose `enableAccessibilityChecks` | Android's accessibility checks in Compose UI tests | stage 6, a native Android surface |
-| Playwright `toHaveScreenshot` | screenshot regression against the approved baseline, per state and theme | stage 6 (regression), and the nightly or release baseline after |
+| Playwright `toHaveScreenshot` | screenshot regression against the approved baseline, per state and theme — the `webkit` project first | stage 6 (regression), and the nightly or release baseline after |
 | axe-core | the deterministic accessibility floor of a web surface | stage 6, first in the cheap-first order |
 | `figma-code-connect` (Figma's public plugin skill) | maps a design-system component in the file to its code component, so `get_design_context` hands the agent the real import instead of approximated markup | stage 5, **offered** for a core component the file draws and nothing maps — publishes to the file, so it needs a go ([`build.md`](build.md) → *Code Connect, kept*) |
 
@@ -164,11 +168,12 @@ Pipeline companions (stage doctrine is built in — nothing to install for it):
                          (running without it — no reach queries, no graph↔docs
                           divergence check)
   ✗ playwright         — recommended when this project has a web front end.
-                         One of TWO channels that do the same look; either is
-                         enough, and a project that already runs Playwright has
-                         this one for free:
+                         The default look: it reaches WebKit (Safari's engine),
+                         which is checked first; a project that already runs
+                         Playwright has this one for free:
                            npm install -D @playwright/cli@latest   (then npx playwright-cli)
-                           claude mcp add playwright npx @playwright/mcp@latest
+                           playwright-cli install-browser webkit
+                           claude mcp add playwright -- npx @playwright/mcp@latest --browser webkit
                          (running without it — see the line below; without BOTH,
                           the surface is verified by reading the diff)
   ✗ sheleg-dev         — this task wires money, tracking, sign-in or page speed;
@@ -191,9 +196,9 @@ Pipeline companions (stage doctrine is built in — nothing to install for it):
   ✗ chrome-devtools    — recommended when this project has a web front end:
                          stages 5-6 check the RENDERED surface instead of the
                          diff, stage 8 reads what the browser did after a deploy.
-                         The other channel; it alone reaches lighthouse_audit
-                         and heap snapshots, and analyses a trace rather than
-                         only recording one:
+                         The stated Chromium exception: Chrome only, and it
+                         alone reaches lighthouse_audit and heap snapshots, and
+                         analyses a trace rather than only recording one:
                            /plugin install chrome-devtools-mcp@claude-plugins-official
                          (running without it — the surface is verified by reading
                           the diff, and the close-out says so in those words)
@@ -226,7 +231,8 @@ Rules:
   `wiki-query`/`wiki-update`. Present → say `✓ ready` and use it in the harvest.
   Absent → print the two install lines **once** and continue; never ask twice in a
   run and never block a stage on it ([`knowledge-sources.md`](knowledge-sources.md)).
-- **The browser channels — `playwright` and `chrome-devtools`, one rule for both.**
+- **The browser channels — `playwright` and `chrome-devtools`, one rule for both, WebKit
+  first.**
   Flag them only when the project **has a web front end** — an `index.html`, a
   `package.json` naming a browser framework, a `docs/ux/screens.md`, or a deploy target
   that serves pages. **A CLI, a library or a backend service does not flag either** —
@@ -237,18 +243,20 @@ Rules:
   `mcp__chrome-devtools__list_pages` (either one under whatever prefix the host uses).
   Present → `✓ ready`. Absent → print its install lines **once** and continue; neither
   is a gate.
-- **They are two channels for one look, and the run needs one of them, not both.**
-  Both open the page, snapshot it and read the console and the network log, so **stop
-  at the first one that answers** — running the same look twice is a cost with no
-  second fact. Where neither is present, say the surface was verified **by reading the
-  diff**; where both are, the tie-breakers are stated rather than left to taste:
-  **`playwright` when the project already runs it**, or when context budget is tight —
-  its own upstream sells the CLI on not loading large tool schemas and verbose
-  accessibility trees into the model context. **`chrome-devtools` when the question is
-  past the page** — a Lighthouse category or a heap snapshot, neither of which the
-  Playwright channel has, or a performance trace you want *analysed* rather than only
-  recorded. Neither is *the better
-  browser*, and a run that ranks them has invented a fact this matrix does not carry.
+- **They are two channels for one look, and the run needs one of them, not both —
+  on WebKit first** (`DEC-0007`, [`browser.md`](browser.md) → *Engine order*). Both open
+  the page, snapshot it and read the console and the network log, so the look is taken
+  once: **`playwright` with `--browser webkit`** (on macOS, Safari itself through
+  `safaridriver` is the same engine) — running the same look twice is a cost with no
+  second fact. **`chrome-devtools` is the stated Chromium exception**: it drives Chrome
+  only, so it is reached for when the question needs Chrome — a Lighthouse category or a
+  heap snapshot, neither of which the Playwright channel has, a performance trace you
+  want *analysed* rather than only recorded, or a Chrome-only API — and the verdict says
+  which and why. Where only `chrome-devtools` is present, the look is reported as
+  *checked in Chromium*, never as *tested in a browser*; where neither is, say the
+  surface was verified **by reading the diff**. The rank is of the **engine**, not of the
+  tools' quality: neither channel is *the better browser*, and a run that claims one is
+  has invented a fact this matrix does not carry.
 - **graphify**: detect via `graphify-out/graph.json` (built → `✓ ready`, query it in
   the harvest) or a resolving `graphify` binary with no `graphify-out/` (installed,
   not built → offer the one-line `/graphify .`). Absent → print the install lines

package/plugins/task-pipeline/skills/task-pipeline/references/stage-05-dev.md

@@ -19,8 +19,8 @@ The full gate and freedom level remain in [stages.md](stages.md).
   contradiction that exists only between two of them.
 - **Web front end? The task's own surface is checked in a browser, not in the diff.**
   Where a browser channel is connected — `playwright` **or** `chrome-devtools`, either
-  one, whichever answers first (**how**: [`browser.md`](browser.md); which:
-  [`companion-skills.md`](companion-skills.md)): after a
+  one, on WebKit first with Chromium a stated exception (**how**, and the engine order:
+  [`browser.md`](browser.md); which: [`companion-skills.md`](companion-skills.md)): after a
   task that changes a rendered surface, load it, take a snapshot and read the
   console and the network log **before the task is marked DONE** — a component can be
   correct and land under a fixed header, and a review of the diff cannot see that.

package/plugins/task-pipeline/skills/task-pipeline/references/stage-08-post-deploy.md

@@ -13,8 +13,9 @@ The full gate and freedom level remain in [stages.md](stages.md).
 - **A deployed web target is opened, not curled.** A `200` proves the server
   answered; it says nothing about whether the page rendered, whether a bundle 404'd,
   or whether the console filled with errors on load — all three ship green past a
-  health check. Where a browser channel is connected — `playwright` **or**
-  `chrome-devtools`, either one ([`browser.md`](browser.md)) — load the deployed URL and read
+  health check. Where a browser channel is connected — `playwright` on WebKit first
+  **or** `chrome-devtools` as the stated Chromium exception, and a Chromium-only look
+  is reported as such; either one ([`browser.md`](browser.md)) — load the deployed URL and read
   the console and the network log; quote what you read, not that you looked
   ([`companion-skills.md`](companion-skills.md)). Absent → say the check was an HTTP
   response only, which is the honest name for it.

package/plugins/task-pipeline/skills/task-pipeline/references/stages.md

@@ -254,8 +254,9 @@ never that the work was skipped quietly.
   page rendered — a component can be correct and land under a fixed header, a request
   can 404 while every unit test mocks it, and a console error costs nothing at test
   time. Where a browser channel is connected — `playwright` **or** `chrome-devtools`,
-  either one ([`browser.md`](browser.md) is the four commands this sentence means;
-  [`companion-skills.md`](companion-skills.md) is which channel):
+  either one, on WebKit first with Chromium a stated exception
+  ([`browser.md`](browser.md) is the four commands this sentence means and the engine
+  order; [`companion-skills.md`](companion-skills.md) is which channel):
   load the surface, take a snapshot, and read **the console and the network log**
   before calling it green. Absent, say the surface was verified **by reading the
   diff** — that is a weaker claim and the close-out records it as one, rather than

package/plugins/task-pipeline/skills/task-pipeline/references/tdd.md

@@ -102,8 +102,9 @@ database created ten seconds ago" are different claims, and only the second one
   code does what its assertions say; it cannot see a component that renders correctly
   and lands under a fixed header, a request that 404s while every unit test mocks it,
   or a console error that costs nothing at test time. Where a browser channel is
-  connected — `playwright` **or** `chrome-devtools`, either one
-  ([`companion-skills.md`](companion-skills.md)) — open the surface and read
+  connected — `playwright` **or** `chrome-devtools`, either one, on WebKit first with
+  Chromium a stated exception ([`companion-skills.md`](companion-skills.md);
+  [`browser.md`](browser.md) → *Engine order*) — open the surface and read
   the console and the network log before calling it done — and **quote what you read**,
   not that you looked. Absent, the honest sentence is *"verified by reading the diff"*,
   which is a weaker claim and is recorded as one. Same family as a test that passes

package/plugins/task-pipeline/skills/task-pipeline/templates/browser-claims.json

@@ -75,7 +75,7 @@
     "route": "/",
     "motion": "reduced",
     "captured_at": "2026-10-07T00:00:00Z",
-    "source": "the capability that took it, e.g. chrome-devtools take_screenshot"
+    "source": "the capability and engine that took it, e.g. playwright-cli screenshot (webkit)"
    },
    "figma_frame": "https://www.figma.com/design/<fileKey>/<file>?node-id=<frame>",
    "baseline": null,
@@ -120,7 +120,7 @@
     "route": "/",
     "motion": "reduced",
     "captured_at": "2026-10-07T00:00:00Z",
-    "source": "the capability that took it, e.g. chrome-devtools take_screenshot"
+    "source": "the capability and engine that took it, e.g. playwright-cli screenshot (webkit)"
    },
    "figma_frame": "https://www.figma.com/design/<fileKey>/<file>?node-id=<frame>",
    "baseline": null,
@@ -165,7 +165,7 @@
     "route": "/",
     "motion": "reduced",
     "captured_at": "2026-10-07T00:00:00Z",
-    "source": "the capability that took it, e.g. chrome-devtools take_screenshot"
+    "source": "the capability and engine that took it, e.g. playwright-cli screenshot (webkit)"
    },
    "figma_frame": "https://www.figma.com/design/<fileKey>/<file>?node-id=<frame>",
    "baseline": null,
@@ -210,7 +210,7 @@
     "route": "/",
     "motion": "reduced",
     "captured_at": "2026-10-07T00:00:00Z",
-    "source": "the capability that took it, e.g. chrome-devtools take_screenshot"
+    "source": "the capability and engine that took it, e.g. playwright-cli screenshot (webkit)"
    },
    "figma_frame": null,
    "baseline": null,
@@ -251,7 +251,7 @@
     "route": "/",
     "motion": "reduced",
     "captured_at": "2026-10-07T00:00:00Z",
-    "source": "the capability that took it, e.g. chrome-devtools take_screenshot"
+    "source": "the capability and engine that took it, e.g. playwright-cli screenshot (webkit)"
    },
    "figma_frame": null,
    "baseline": null,