@asrunjs/asrun 0.2.0 → 0.5.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@asrunjs/asrun",
-  "version": "0.2.0",
+  "version": "0.5.2",
   "description": "Multi-profile end-to-end test suite: plain-language cases, AI-written Playwright specs, evidence for every run.",
   "license": "MIT",
   "author": "Zoro Chen",
@@ -55,7 +55,11 @@
     "@codemirror/lang-yaml": "^6.1.3",
     "@codemirror/language": "^6.13.1",
     "@codemirror/language-data": "^6.5.2",
+    "@codemirror/state": "^6.7.6",
     "@codemirror/view": "^6.43.15",
+    "@dnd-kit/core": "^6.3.1",
+    "@dnd-kit/sortable": "^10.0.0",
+    "@dnd-kit/utilities": "^3.2.2",
     "@hono/node-server": "^2.1.5",
     "@lezer/highlight": "^1.2.5",
     "@napi-rs/canvas": "^1.0.13",
@@ -92,6 +96,13 @@
     "spec:lint": "tsx scripts/lint-specs.ts",
     "baselines:review": "tsx scripts/review-baselines.ts",
     "pdf:render": "tsx scripts/render-pdf.ts",
+    "demo:up": "node scripts/demo.mjs up",
+    "demo:build": "node scripts/demo.mjs build",
+    "demo:seed": "node scripts/demo.mjs seed",
+    "demo:reset": "node scripts/demo.mjs reset",
+    "demo:down": "node scripts/demo.mjs down",
+    "demo:logs": "node scripts/demo.mjs logs",
+    "demo:status": "node scripts/demo.mjs status",
     "typecheck": "tsc --noEmit && tsc --noEmit -p ui/tsconfig.json",
     "ui": "tsx scripts/ui.ts",
     "ui:build": "tsx scripts/ui-build.ts",

package/templates/.claude/commands/explore-case.md

@@ -1,21 +1,22 @@
----
-description: Explore the real pages for one case (optionally attended: you do the steps that write data), before generating the spec
----
-
-Load the framework skill `{{framework}}/.claude/skills/exploring-cases/SKILL.md` and explore: $ARGUMENTS
-
-If `.claude/skills/exploring-cases.md` exists, apply it after the framework skill; on conflict it wins, except rules
-tagged `[non-negotiable]`. Project facts are in `AGENTS.md` §3.
-
-Arguments: `<case-id> <env> [--attended]`. The case id is the path below `cases/` without `.md` (it may include a
-group folder, e.g. `documents/landing-page`) and is required. `<env>` is `staging` or `production`; it is required and there
-is no default (without one, stop and say so). With `--attended` I am at the machine and the browser window is
-visible: when a step writes data or needs a choice, hand it to me as the skill describes, wait for me, and record
-what I did as a general recipe under "## Inputs". Without `--attended`, never wait for me.
-
-Follow `{{framework}}/.claude/skills/exploring-cases/references/assertion-targets.md` (list the candidates, never
-pick when in doubt, ask for the exact image/text/place/UI) and `readiness.md` (wait for the key requests and the
-content before you read anything) of the skill.
-
-This command edits `cases/<case-id>.md` only (plus screenshots under `.explore/targets/`). Do not ask me questions in
-the chat: write open questions into the case file as the skill describes, and end with the `RESULT:` line.
+---
+description: Explore the real pages for one case (optionally attended: you do the steps that write data), before generating the spec
+---
+
+Load the framework skill `{{framework}}/.claude/skills/exploring-cases/SKILL.md` and explore: $ARGUMENTS
+
+Rules combine in this order, and a later one wins where they conflict: the framework baseline
+`{{framework}}/AGENTS.md`, the framework skill, `.claude/skills/exploring-cases.md` if it exists, then the workspace
+`AGENTS.md` §2 (Project rules). F1–F6 always win. Project facts are in `AGENTS.md` §3.
+
+Arguments: `<case-id> <env> [--attended]`. The case id is the path below `cases/` without `.md` (it may include a
+group folder, e.g. `documents/landing-page`) and is required. `<env>` is `staging` or `production`; it is required and there
+is no default (without one, stop and say so). With `--attended` I am at the machine and the browser window is
+visible: when a step writes data or needs a choice, hand it to me as the skill describes, wait for me, and record
+what I did as a general recipe under the step it belongs to (`- Recipe:` lines). Without `--attended`, never wait for me.
+
+Follow `{{framework}}/.claude/skills/exploring-cases/references/assertion-targets.md` (list the candidates, never
+pick when in doubt, ask for the exact image/text/place/UI) and `readiness.md` (wait for the key requests and the
+content before you read anything) of the skill.
+
+This command edits `cases/<case-id>.md` only (plus screenshots under `.explore/targets/`). Do not ask me questions in
+the chat: write open questions into the case file as the skill describes, and end with the `RESULT:` line.

package/templates/.claude/commands/gen-spec.md

@@ -1,20 +1,21 @@
----
-description: Generate or update tests/<id>.spec.ts from cases/<id>.md (the id may be <group>/<name>)
----
-
-Load the framework skill `{{framework}}/.claude/skills/generating-specs/SKILL.md` and generate the spec for:
-$ARGUMENTS
-
-If `.claude/skills/generating-specs.md` exists, apply it after the framework skill; on conflict it wins, except rules
-tagged `[non-negotiable]`. Project facts are in `AGENTS.md` §3.
-
-Arguments: `<case-id> [<env>] [--force]`. The case file is `cases/<case-id>.md` (the id may include one group folder,
-e.g. `documents/landing-page`). `<env>` is the environment to explore in (`staging` or `production`); there is no default. If
-the spec already exists, it is left alone unless `--force` is given; with `--force` it is regenerated and overwritten.
-
-Follow the skill's procedure exactly, including its `assertion-targets.md` and `readiness.md`; run
-`pnpm spec:lint <case-id>`. Only generate the spec: do not run `pnpm asrun` (running specs is a separate
-process), and do not create baselines.
-
-Do not ask me questions: resolve ambiguity as the skill describes (explore the page, use observed values marked for
-QA, write the remaining questions into the case file), and end with the `RESULT:` line.
+---
+description: Generate or update tests/<id>.spec.ts from cases/<id>.md (the id may be <group>/<name>)
+---
+
+Load the framework skill `{{framework}}/.claude/skills/generating-specs/SKILL.md` and generate the spec for:
+$ARGUMENTS
+
+Rules combine in this order, and a later one wins where they conflict: the framework baseline
+`{{framework}}/AGENTS.md`, the framework skill, `.claude/skills/generating-specs.md` if it exists, then the workspace
+`AGENTS.md` §2 (Project rules). F1–F6 always win. Project facts are in `AGENTS.md` §3.
+
+Arguments: `<case-id> [<env>] [--force]`. The case file is `cases/<case-id>.md` (the id may include one group folder,
+e.g. `documents/landing-page`). `<env>` is the environment to explore in (`staging` or `production`); there is no default. If
+the spec already exists, it is left alone unless `--force` is given; with `--force` it is regenerated and overwritten.
+
+Follow the skill's procedure exactly, including its `assertion-targets.md` and `readiness.md`; run
+`pnpm spec:lint <case-id>`. Only generate the spec: do not run `pnpm asrun` (running specs is a separate
+process), and do not create baselines.
+
+Do not ask me questions: resolve ambiguity as the skill describes (explore the page, use observed values marked for
+QA, write the remaining questions into the case file), and end with the `RESULT:` line.

package/templates/.claude/commands/heal-spec.md

@@ -1,30 +1,31 @@
----
-description: Diagnose and fix a failing spec from its last report (without hiding real product regressions)
----
-
-Load the framework skill `{{framework}}/.claude/skills/generating-specs/SKILL.md`, section "Healing a failing
-spec", and follow it exactly.
-
-If `.claude/skills/generating-specs.md` exists, apply it after the framework skill; on conflict it wins, except rules
-tagged `[non-negotiable]`. Project facts are in `AGENTS.md` §3.
-
-Arguments: $ARGUMENTS
-Format: `<case-id> <env> [--profiles a,b] [--report <run-id>] [--hints <file>]`, with optional free text after them.
-- `<case-id>` and `<env>` (`staging` or `production`) are required. There is no default environment. Without one,
-  stop and say so.
-- `--profiles`: the profiles to heal. Without it, every profile that is logged in in `<env>`.
-- `--report`: the report (folder name under `reports/`) to read first. Without it, the newest report of this case.
-- `--hints <file>`: a file with what the user knows (what to heal, evidence, clues). Read it first. Any free text
-  after the arguments is the same kind of clue. Both are optional.
-
-Before you decide "product or test", audit the assertion itself (target card, baseline content, readiness): see
-step 4 of the skill's healing section, `assertion-targets.md` and `readiness.md`. Run `pnpm spec:lint <case-id>`.
-Read the existing report first (`pnpm heal:evidence --case <case-id> --env <env>`), and run the case again only when
-the skill says it is needed. Always run with `--logged-in`. Tell me whether it is a test problem or a product
-finding.
-
-Run `pnpm asrun ...`, `pnpm heal:evidence ...`, `pnpm spec:lint ...`, `pnpm baselines:review ...` and
-`pnpm status ...` as plain commands, optionally piped to `tail` or `head`, and do not chain other commands with them
-(`;` or `&&`). Only these exact forms run outside Claude Code's sandbox, which tsx and the browser need. If a
-command still fails with `listen EPERM` or a sandbox error, stop and report it. Do not ask to disable the sandbox,
-and never add `--allow-writes` or set `ASRUN_ALLOW_WRITES`.
+---
+description: Diagnose and fix a failing spec from its last report (without hiding real product regressions)
+---
+
+Load the framework skill `{{framework}}/.claude/skills/generating-specs/SKILL.md`, section "Healing a failing
+spec", and follow it exactly.
+
+Rules combine in this order, and a later one wins where they conflict: the framework baseline
+`{{framework}}/AGENTS.md`, the framework skill, `.claude/skills/generating-specs.md` if it exists, then the workspace
+`AGENTS.md` §2 (Project rules). F1–F6 always win. Project facts are in `AGENTS.md` §3.
+
+Arguments: $ARGUMENTS
+Format: `<case-id> <env> [--profiles a,b] [--report <run-id>] [--hints <file>]`, with optional free text after them.
+- `<case-id>` and `<env>` (`staging` or `production`) are required. There is no default environment. Without one,
+  stop and say so.
+- `--profiles`: the profiles to heal. Without it, every profile that is logged in in `<env>`.
+- `--report`: the report (folder name under `reports/`) to read first. Without it, the newest report of this case.
+- `--hints <file>`: a file with what the user knows (what to heal, evidence, clues). Read it first. Any free text
+  after the arguments is the same kind of clue. Both are optional.
+
+Before you decide "product or test", audit the assertion itself (target card, baseline content, readiness): see
+step 4 of the skill's healing section, `assertion-targets.md` and `readiness.md`. Run `pnpm spec:lint <case-id>`.
+Read the existing report first (`pnpm heal:evidence --case <case-id> --env <env>`), and run the case again only when
+the skill says it is needed. Always run with `--logged-in`. Tell me whether it is a test problem or a product
+finding.
+
+Run `pnpm asrun ...`, `pnpm heal:evidence ...`, `pnpm spec:lint ...`, `pnpm baselines:review ...` and
+`pnpm status ...` as plain commands, optionally piped to `tail` or `head`, and do not chain other commands with them
+(`;` or `&&`). Only these exact forms run outside Claude Code's sandbox, which tsx and the browser need. If a
+command still fails with `listen EPERM` or a sandbox error, stop and report it. Do not ask to disable the sandbox,
+and never add `--allow-writes` or set `ASRUN_ALLOW_WRITES`.

package/templates/.claude/commands/make-case.md

@@ -1,12 +1,13 @@
----
-description: Turn raw test notes (pasted text or a file) into case documents in cases/
----
-
-Load the framework skill `{{framework}}/.claude/skills/making-cases/SKILL.md` and turn this input into case
-documents: $ARGUMENTS
-
-If `.claude/skills/making-cases.md` exists, apply it after the framework skill; on conflict it wins, except rules
-tagged `[non-negotiable]`. Project facts are in `AGENTS.md` §3.
-
-The input is either text or a path to a file with the notes. Follow the skill's procedure exactly. Ask me the open
-questions before writing any case file. Do not generate specs; that is `/gen-spec`.
+---
+description: Turn raw test notes (pasted text or a file) into case documents in cases/
+---
+
+Load the framework skill `{{framework}}/.claude/skills/making-cases/SKILL.md` and turn this input into case
+documents: $ARGUMENTS
+
+Rules combine in this order, and a later one wins where they conflict: the framework baseline
+`{{framework}}/AGENTS.md`, the framework skill, `.claude/skills/making-cases.md` if it exists, then the workspace
+`AGENTS.md` §2 (Project rules). F1–F6 always win. Project facts are in `AGENTS.md` §3.
+
+The input is either text or a path to a file with the notes. Follow the skill's procedure exactly. Ask me the open
+questions before writing any case file. Do not generate specs; that is `/gen-spec`.

package/templates/.mcp.json

@@ -1,8 +1,8 @@
-{
-  "mcpServers": {
-    "playwright-test": {
-      "command": "./node_modules/.bin/playwright",
-      "args": ["run-test-mcp-server"]
-    }
-  }
-}
+{
+  "mcpServers": {
+    "playwright-test": {
+      "command": "{{playwright}}",
+      "args": ["run-test-mcp-server"]
+    }
+  }
+}

package/templates/AGENTS.md

@@ -1,45 +1,64 @@
-# <project name> — asrun workspace
-
-This project uses the asrun framework, which lives in `{{framework}}` as an installed dependency. The framework is
-read-only here: never edit files inside it, and never commit test data into it.
-
-Read this file, then the framework baseline, before any AI step.
-
-## 1. Framework baseline (binding)
-
-Read `{{framework}}/AGENTS.md` in full. It is part of this project's rules. Its hard rules carry ids `F1`..`F10`,
-its browser rules `B1`..`B4`, its assertion rules `A1`..`A6`. Rules tagged `[non-negotiable]` cannot be narrowed.
-
-The framework skills are in `{{framework}}/.claude/skills/`. The commands in `.claude/commands/` load them. A
-project that needs different wording puts an override at `.claude/skills/<skill>.md` (for example
-`.claude/skills/exploring-cases.md`); the command applies the framework skill first and the override afterwards, and
-on conflict the override wins except for `[non-negotiable]` rules. `pnpm asrun doctor` lists every override.
-
-## 2. Project rules (only stricter)
-
-Add rules that narrow the baseline for this project, and name the baseline rule each one narrows. The rules `F1`..`F6`
-cannot be narrowed, so they never appear here. Example:
-
-| Rule | Project rule |
-|---|---|
-| F9  | Staging writes are limited to accounts named `qa-*` and names starting with `[asrun]`. |
-| F7  | This project runs production profiles only from a scheduled job; people use `--env staging`. |
-
-`pnpm asrun doctor` fails when this table names a `[non-negotiable]` rule.
-
-## 3. Project facts
-
-- Profiles and environments: `profiles.yaml`.
-- Areas: one folder per area below `cases/` (for example `cases/<area>/<name>.md`).
-- Expected values: they live in each case's `## Values` block, never here and never in `profiles.yaml`.
-- Who owns a finding, and where findings are reported: <fill in>.
-
-## Layout of this workspace
-
-- `cases/**/*.md`       human-written test cases (committed)
-- `tests/**/*.spec.ts`  generated Playwright specs and their `*-snapshots/` baselines (committed)
-- `profiles.yaml`       one entry per environment, connection settings only (committed)
-- `.auth/`              saved logins: never read, never commit
-- `reports/`            run reports: never commit
-- `{{framework}}/`  the framework (installed package): never edit
-- `.env`            local settings (`ASRUN_ROOT`): never commit
+# <project name> — asrun workspace
+
+This project uses the asrun framework, which lives in `{{framework}}` as an installed dependency. The framework is
+read-only here: never edit files inside it, and never commit test data into it.
+
+Read this file and the framework baseline it points at, before any AI step.
+
+## 1. How rules combine
+
+Rules are applied in this order, and a later layer wins where they conflict (the framework baseline, "Precedence"):
+
+1. `F1`–`F6` of the framework baseline: safety, in every project. Nothing here can change them.
+2. The framework baseline, `{{framework}}/AGENTS.md`.
+3. The framework skill (`{{framework}}/.claude/skills/<skill>/SKILL.md`).
+4. A project skill override, `.claude/skills/<skill>.md` (optional; the command and the skill read it).
+5. This file, §2 below: what this project does differently.
+
+The framework skills are loaded by the commands in `.claude/commands/` (Claude Code) and `.opencode/commands/`
+(OpenCode). The skills live in the framework package; §3 holds this project's facts.
+
+## 2. Project rules
+
+Only what differs from the baseline: name the rule id, and whether it `narrows` (stricter) or `replaces` (a different
+default, for example the artifact language) the baseline rule. `replaces` is refused for `F1`–`F6`. Rows whose first
+cell is not a rule id are ignored, so the placeholder below can stay until you need it.
+
+| Rule | Project rule | Effect |
+|---|---|---|
+| <rule id, e.g. F10> | <what this project does differently from the baseline> | narrows |
+
+Examples (delete what you do not use; the fenced block is an example, not a rule):
+
+```markdown
+| F10 | Case prose, report summaries and assertion messages in Simplified Chinese; code and commit messages stay English. | replaces |
+| F9  | Staging writes are limited to accounts named `qa-*` and names starting with `[asrun]`. | narrows |
+| F7  | This project runs production profiles only from a scheduled job; people use `--env staging`. | narrows |
+```
+
+`pnpm asrun doctor` fails when this table names a `[non-negotiable]` rule, an unknown rule id, or an `Effect` that is
+not `narrows` or `replaces`.
+
+The structural tokens are fixed English whatever the project language: the section headings (`## Values`, `## Targets`,
+...), a step's `- Recipe (phase): ...` lines, `### T<n>`, the `TODO` blocks with their `Answer:` line,
+`[input]`/`[writes]`/`[email]`, `RESULT:`, and the front-matter keys. See "Fixed tokens" in the framework baseline.
+
+## 3. Project facts
+
+- Profiles and environments: `profiles.yaml`.
+- Areas: one folder per area below `cases/` (for example `cases/<area>/<name>.md`).
+- Expected values: they live in each case's `## Values` block, never here and never in `profiles.yaml`.
+- Who owns a finding, and where findings are reported: <fill in>.
+
+## Layout of this workspace
+
+- `cases/**/*.md`       human-written test cases (committed)
+- `tests/**/*.spec.ts`  generated Playwright specs and their `*-snapshots/` baselines (committed)
+- `profiles.yaml`       one entry per environment, connection settings only (committed)
+- `.claude/commands/`   `/make-case`, `/explore-case`, `/gen-spec`, `/heal-spec` for Claude Code
+- `.opencode/commands/` the same commands for OpenCode (it does not read `.claude/commands`)
+- `.claude/skills/`     optional overrides of a framework skill: `<skill>.md`
+- `.auth/`              saved logins: never read, never commit
+- `reports/`            run reports: never commit
+- `{{framework}}/`  the framework (installed package): never edit
+- `.env`            local settings (`ASRUN_ROOT`): never commit

package/templates/cases/_template.md

@@ -1,63 +1,57 @@
----
-id: {{id}}
-title: One-line summary of what this case proves
-login: required        # required | none  (none = public page, no saved session needed)
-suites: [smoke, regression]   # a case may be in several suites; filter with `pnpm asrun --suite <name>`
-# writes: [staging]    # omit = read-only. The environments in which the case may create or change data of the test accounts (and cleans it up); elsewhere it is skipped with a notice
-# writes-note: What the case creates or changes, e.g. one draft named "[asrun] ...", deleted at the end.   (required when writes is set)
-# envs: [production, staging]  # optional: run only in these environments (default: all); must include every environment in `writes`
----
-
-## Goal
-Why this case exists, in one or two sentences.
-
-## Steps
-1. Open <page or path, e.g. /account/>.
-2. <What to look at or click.>
-
-## Expected
-- <Behaviour that must hold for every profile.>
-
-## Values
-The exact values the spec asserts. `default` applies to every profile; an entry named after a profile id is
-deep-merged over it. Put only the literals here (names, labels, options, test data names); the checks themselves stay
-in Steps and Expected, and the selectors come from `## Targets`. The case document is the only place where expected
-values live: `profiles.yaml` holds connection settings only.
-
-```yaml
-default:
-  exampleKey: Example value
-example-staging:
-  exampleKey: Example value on staging
-```
-
-## Visual checks
-- <Which element must match a screenshot baseline, e.g. the header logo.>
-
-## Targets
-One card per image, logo, icon, file, PDF or repeated text that a check looks at. Checks above refer to it as `[T1]`.
-Written by `/explore-case`; do not guess: when it is unclear which element is meant, answer the TODO with the exact
-image, text, place or UI. Rules: `{{framework}}/.claude/skills/exploring-cases/references/assertion-targets.md`.
-
-### T1 <short name, e.g. Preview logo>
-- What: <the thing itself, and what it is NOT when a look-alike exists>.
-- Where: <region of the page, dialog, tab or file page>.
-- Identified by: <role and name, test id, alt text or title; never a position>.
-- Not: <look-alikes that must not be matched, e.g. a content image>.
-- Ready when: <what shows that the content has loaded>.
-- Reference <profile-id>: .explore/targets/<case-id>/T1-<profile-id>.png
-
-## Data
-Only for cases with `writes`. Say what is created, its name (prefix `[asrun]`), and how it is removed at the end
-(also when the case fails). Mark steps that write with `[writes]`, steps that need a person's choice with `[input]`,
-and steps that send email with `[email]` (email is never sent in production; in other environments only for profiles
-with `email: true`).
-
-## Inputs
-Only for cases with `[input]` steps. Written by `/explore-case --attended` from what a person did in the browser, as a
-general recipe: positions instead of names ("select items #1 to #3"), `[asrun]` names for created data, control
-labels and roles but no selectors or ids. One bullet per `[input]` step, keyed by the step number.
-- Step <n> (<what>): <the general recipe>.
-
-## Notes
-Read-only unless the front matter has `writes`.
+---
+id: {{id}}
+title: One-line summary of what this case proves
+login: required        # required | none  (none = public page, no saved session needed)
+suites: [smoke, regression]   # a case may be in several suites; filter with `pnpm asrun --suite <name>`
+# writes: [staging]    # omit = read-only. The environments in which the case may create or change data of the test accounts (and cleans it up); elsewhere it is skipped with a notice
+# writes-note: What the case creates or changes, e.g. one draft named "[asrun] ...", deleted at the end.   (required when writes is set)
+# envs: [production, staging]  # optional: run only in these environments (default: all); must include every environment in `writes`
+---
+
+## Goal
+Why this case exists, in one or two sentences.
+
+## Steps
+1. Open <page or path, e.g. /account/>.
+    - Ready when: <the one positive signal that what this step loads is really there, e.g. the list shows its first
+      row. It says when to look; what must be true afterwards goes under Expected.>
+2. <What to look at or click.>
+3. <A step that needs a person's choice or writes something.> [input] [writes]
+    - Recipe (start): <what the person did, recorded by /explore-case --attended: positions, [asrun] names, control
+      labels; never selectors or ids. One line per phase.>
+
+## Expected
+- <Behaviour that must hold for every profile.>
+
+## Values
+The exact values the spec asserts. `default` applies to every profile; an entry named after a profile id is
+deep-merged over it. Put only the literals here (names, labels, options, test data names); the checks themselves stay
+in Steps and Expected, and the selectors come from `## Targets`. The case document is the only place where expected
+values live: `profiles.yaml` holds connection settings only.
+
+```yaml
+default:
+  exampleKey: Example value
+example-staging:
+  exampleKey: Example value on staging
+```
+
+## Visual checks
+- <Which element must match a screenshot baseline, e.g. the header logo.>
+
+## Targets
+One card per image, logo, icon, file, PDF or repeated text that a check looks at. Checks above refer to it as `[T1]`.
+Written by `/explore-case`; do not guess: when it is unclear which element is meant, answer the TODO with the exact
+image, text, place or UI. Rules: `{{framework}}/.claude/skills/exploring-cases/references/assertion-targets.md`.
+
+### T1 <short name, e.g. Preview logo>
+- What: <the thing itself, and what it is NOT when a look-alike exists>.
+- Where: <region of the page, dialog, tab or file page>.
+- Identified by: <role and name, test id, alt text or title; never a position>.
+- Not: <look-alikes that must not be matched, e.g. a content image>.
+- Ready when: <what shows that the content has loaded>.
+- Reference <profile-id>: .explore/targets/<case-id>/T1-<profile-id>.png
+
+## Notes
+Assumptions and constraints for a reviewer. For a case with `writes`, `writes-note` is the one place that says what is
+created, changed and removed; the removal is a step above, and it runs also when a step fails.

package/templates/opencode.jsonc

@@ -1,11 +1,16 @@
-{
-  "$schema": "https://opencode.ai/config.json",
-  "mcp": {
-    // Playwright's test-runner MCP: opens a page through a profile project, so the saved
-    // login for that profile is applied automatically (use the `project` argument).
-    "playwright-test": {
-      "type": "local",
-      "command": ["./node_modules/.bin/playwright", "run-test-mcp-server"]
-    }
-  }
-}
+{
+  "$schema": "https://opencode.ai/config.json",
+  // The model the AI commands run with. Without one, OpenCode falls back to its built-in free model, which has a
+  // daily usage limit; the field also decides what `opencode run` uses, since a one-shot run ignores the model the
+  // TUI last picked. The AsRun web UI offers the same choice (read from `opencode models`) in its top bar.
+  // "model": "openrouter/deepseek/deepseek-v4.1-flash-1017",
+  "mcp": {
+    // Playwright's test-runner MCP: opens a page through a profile project, so the saved
+    // login for that profile is applied automatically (use the `project` argument).
+    // OpenCode reads this file only (it does not read `.mcp.json`, which is Claude Code's).
+    "playwright-test": {
+      "type": "local",
+      "command": ["{{playwright}}", "run-test-mcp-server"]
+    }
+  }
+}

package/templates/profiles.yaml

@@ -1,29 +1,42 @@
-# One entry per environment target. Each profile becomes one Playwright project named after its id,
-# so every test runs once per profile. Connection settings only: expected values live in the case documents.
-#
-# id:                lowercase words with single dashes. The Playwright project name, the saved session
-#                    file (`.auth/<id>.json`) and the screenshot baseline names all use it.
-# name:              what people see in the UI and the reports.
-# env:               the environment this profile points at (`production`, `staging`, ...). Any environment
-#                    that is not `staging` is protected: cases that write data need a person's confirmation
-#                    there. `--env <env>` selects the profiles of one environment.
-# baseURL:           the site address, without a path.
-# account:           a label for humans (a mailbox or username). Never a password; logins live in .auth/.
-# tags:              optional lowercase words, for grouping and `pnpm asrun --tag <tag>`.
-# email:             `true` only when a real mailbox is connected, so tests may send email. Never in production.
-# sessionCheckPath:  a page that redirects to /login when the session is missing or expired.
-
-profiles:
-  - id: example-staging
-    name: Example (staging)
-    env: staging
-    baseURL: https://staging.example.com
-    tags:
-      - core
-    email: false
-
-  # - id: example-production
-  #   name: Example
-  #   env: production
-  #   baseURL: https://www.example.com
-  #   email: false
+# One entry per environment target. Each profile becomes one Playwright project named after its id,
+# so every test runs once per profile. Connection settings only: expected values live in the case documents.
+#
+# id:                lowercase words with single dashes. The Playwright project name, the saved session
+#                    file (`.auth/<id>.json`) and the screenshot baseline names all use it.
+# name:              what people see in the UI and the reports.
+# env:               the environment this profile points at (`production`, `staging`, ...). Any environment
+#                    that is not `staging` is protected: cases that write data need a person's confirmation
+#                    there. `--env <env>` selects the profiles of one environment.
+# baseURL:           the site address, without a path.
+# account:           a label for humans (a mailbox or username). Never a password; logins live in .auth/.
+# tags:              optional lowercase words, for grouping and `pnpm asrun --tag <tag>`.
+# email:             `true` only when a real mailbox is connected, so tests may send email. Never in production.
+# startPath:         the page "Visit" on the Profiles page opens after a login, e.g. `/app/home`.
+#                    Empty (the default) opens the site root; a path on the site, never another host.
+# sessionCheckPath:  a page only a signed-in visitor sees, e.g. `/settings`; that is how "Verify" and the
+#                    pre-run check find out whether the saved login still works.
+# sessionCheck:      optional, how that page shows a missing login. The defaults fit the common case (a
+#                    redirect to /login); name what your site does when it differs:
+#                      loggedOutUrl:      where a signed-out visitor ends up (default `/login`): a path on the
+#                                         site, or a full URL for single sign-on. A 401/403 response counts too.
+#                      loggedInSelector:  a selector that is only there while signed in, e.g.
+#                                         "input[name='username']". Without it, "not redirected to the login
+#                                         page" is taken as signed in, which a single-page app can mislead.
+#                      loggedOutSelector: a selector that shows the visitor is signed out, e.g. the password
+#                                         field of a login form the site shows at the same address.
+#                      timeoutMs:         how long to wait for one of those signals (default 3000).
+
+profiles:
+  - id: example-staging
+    name: Example (staging)
+    env: staging
+    baseURL: https://staging.example.com
+    tags:
+      - core
+    email: false
+
+  # - id: example-production
+  #   name: Example
+  #   env: production
+  #   baseURL: https://www.example.com
+  #   email: false