@asrunjs/asrun 0.8.0 → 0.9.0

package/docs/ai-workflow.md

@@ -8,16 +8,25 @@ so the procedure lives in one place and a project can refine it (see
 | Command | What it does |
 |---|---|
 | `/make-case <notes-or-path>` | Turn raw notes into case documents. Optional step. |
-| `/explore-case <case-id> <env> [--attended]` | Open the real pages and write what they show into the case. |
+| `/explore-case <case-id> <env> [--attended] [--profiles a,b]` | Open the real pages and write what they show into the case. |
 | `/gen-spec <case-id> <env> [--force]` | Write `tests/<case-id>.spec.ts` and fill the case's `## Values`. |
-| `/heal-spec <case-id> <env> [--profiles a,b] [--report <run-id>] [--hints <file>]` | Diagnose a failing spec from its last report and fix it. |
+| `/heal-spec <case-id> <env> [--profiles a,b] [--report <run-id>] [--hints <file>]` | Repair a failing spec, or refine a case and its spec on request, from the last report and what you asked for. |
 
 The environment is **required** by every command except `/make-case`, which does not open pages. There is no default.
 
+`--profiles` exists on `/explore-case` and `/heal-spec`, not on `/gen-spec`: a spec runs once per profile in the
+environment, so it is generated from every profile the case holds information for, never from a chosen subset.
+
 Every command ends with `RESULT: ready` or `RESULT: needs-input`. `needs-input` means somebody has to answer a
 question in the case file (or, in the web UI, in the job's **Answer** sheet). A one-shot run cannot ask in the chat:
 it writes its questions into the case and stops.
 
+A one-shot run is a **build** run: it writes the case or the spec, never a plan. AsRun starts OpenCode with
+`--agent build`, because OpenCode keeps the agent (build or plan) on the session and a plan session would only propose
+changes and ask a question nobody can answer. Whatever mode a run finds itself in, it still ends with the `RESULT:`
+line: a run that was not allowed to write files (plan mode, a read-only sandbox) is `needs-input`, not a plan and a
+question.
+
 In the web UI you never type a command: choose the step in a case toolbar and press **Run AI**, or paste notes on
 **Cases > From memo**. The UI runs the selected AI tool and streams the output into the Jobs bar.
 
@@ -55,6 +64,11 @@ publishes, shares or deletes anything, in staging or in production. It:
 - lists the candidates instead of guessing a target (`## Targets`);
 - edits the case file only (plus reference screenshots under `.explore/targets/`).
 
+With many profiles, `--profiles a,b` opens only those (ids from `profiles.yaml`, comma-separated). The others are not
+opened and nothing is written about them, so a case can be explored in passes: A and B first, C later. Runs add up; the
+case keeps what the earlier runs recorded. In the web UI the profile picker of the toolbar does the same: every profile
+that is logged in in that environment is ticked, and the list you tick is remembered for the next run there.
+
 **To accept the suggestion, delete the whole block.** **To answer, write after `Answer:`.** Then run the command
 again. In the web UI, the run's **What to do next** bar offers **Answer**: the question list, an answer box,
 **Use the suggested defaults** and **Generate spec**. A continued job keeps the same conversation and permissions, and
@@ -92,8 +106,14 @@ Skip this for a `login: none` case. Sessions are per profile; see [profiles.md](
 ```
 
 The agent replays the case on the real pages with your saved sessions (it never writes data) and writes
-`tests/header-logo.spec.ts`. It fills the case's `## Values` for the profiles it explored and checks the files
-(`pnpm typecheck`, `pnpm case:check`; `pnpm spec:lint <case-id>` must have no failure).
+`tests/header-logo.spec.ts`. It fills the case's `## Values` for the profiles the case holds information for and checks
+the files (`pnpm typecheck`, `pnpm case:check`; `pnpm spec:lint <case-id>` must have no failure).
+
+Its profile scope comes from the case, not from a selection: every profile id the case names — the keys of
+`## Values`, a target card's `Reference <profile-id>:` line, an observation — plus `default`. That is why one run per
+subset adds up: explore A and B first and C later, and `/gen-spec` covers all three. A profile the case says nothing
+about runs on `default` alone, and the report names it. A profile that is not logged in is not dropped: its part is
+written from the case and marked `not verified on the page`.
 
 It does **not** run the spec and does **not** create screenshot baselines: running is a separate step (6).
 
@@ -125,7 +145,7 @@ profile. Baselines are the source of truth for pixel checks.
 Then run all profiles and read the report: the video of each test, screenshots on failure, and the trace with the page
 and the network requests. See [commands.md](./commands.md) for filters and baselines.
 
-## Healing a failing spec
+## Healing or refining a spec
 
 ```
 /heal-spec header-logo staging
@@ -133,14 +153,15 @@ and the network requests. See [commands.md](./commands.md) for filters and basel
 
 or **Heal spec** in the case toolbar, or **Heal this failure** on a failed result of the Reports page.
 
-The agent decides whether the test needs updating or whether it found a real product problem. It **never** edits an
-expectation just to make a failure disappear.
+The command does two jobs: it repairs a spec that fails, and it refines a case and its spec when you ask for an
+improvement. A passing last run is not a reason to refuse a request. It decides whether the test needs updating or
+whether it found a real product problem, and it **never** edits an expectation just to make a failure disappear.
 
 - The environment is required. Only the profiles that are logged in there run (`--logged-in` leaves the others out
   instead of failing them).
-- The web UI first opens a dialog: which profiles to heal (every logged-in profile ticked) and an optional text box
-  for what you want healed, with evidence or clues. The text is stored in `.tmp/hints/` and passed as `--hints`.
-  Clues guide the diagnosis; they never lower the bar for a product finding.
+- The web UI first opens a dialog: which profiles to run (every logged-in profile ticked) and an optional text box
+  for what should be repaired or improved, with evidence. The text is stored in `.tmp/hints/` and passed as `--hints`.
+  It guides the work; it never lowers the bar for a product finding.
 - It reads the existing report first:
 
   ```bash
@@ -149,7 +170,13 @@ expectation just to make a failure disappear.
 
   It prints status, failed step, error, call log and screenshots per profile, and whether the report is fresh or
   stale. The case is run again only when there is no report, the report is stale, it does not explain the failure, or
-  a clue has to be checked. After editing the spec, it runs the case once to confirm.
+  a request has to be checked. It reads the pages (read-only) when a change has to be judged on them, and it never
+  performs a step that writes data. After editing the spec, it runs the case once to confirm.
+- The case is the source of truth: a change to a step, an expectation, a value or a target is written into the case
+  first, then into the spec. A large change regenerates the spec from the case.
+- **Review gate.** If the change leaves an open question or an unconfirmed observation in the case, healing stops
+  before the spec: you review the case, answer or accept what it asks, and run `/explore-case` again. The spec is
+  generated after that, not before.
 
 ## Why a generated spec can be trusted
 

package/docs/theme-guide.html

@@ -257,6 +257,29 @@
   .side .item { padding: 8px 16px 8px 12px; border-bottom: 1px solid var(--line); border-left: 4px solid transparent; font-family: var(--mono); font-size: 14px; }
   .side .item.selected { background: var(--theme-bg); border-left-color: var(--theme); }
 
+  /* Filter bar (mirror components/filter-chips.tsx and components/search-field.tsx). */
+  .filters { display: flex; flex-wrap: wrap; align-items: center; gap: 4px; }
+  .filters .group-label { margin-right: 2px; font-size: 12px; color: var(--ink-3); }
+  .filter-chip {
+    display: inline-flex; align-items: center; gap: 4px; height: 24px; padding: 0 6px; border-radius: 2px;
+    background: var(--card); color: var(--ink-2); font-size: 12px; box-shadow: inset 0 0 0 1px var(--line-mid);
+  }
+  .filter-chip .count { color: var(--ink-3); }
+  .filter-chip.on {
+    background: var(--theme-btn); color: #fff; font-weight: 500;
+    box-shadow: inset 0 0 0 1px var(--theme-btn);
+  }
+  .filter-chip.on .count { color: rgb(255 255 255 / .75); }
+  .filter-chip.on.production { background: var(--jiang); box-shadow: inset 0 0 0 1px var(--jiang); }
+  .filter-chip.on.staging { background: var(--cheng); box-shadow: inset 0 0 0 1px var(--cheng); }
+  .filter-chip.on.other { background: var(--gold-deep); box-shadow: inset 0 0 0 1px var(--gold-deep); }
+  .filter-search { position: relative; width: 260px; max-width: 100%; }
+  .filter-search svg { position: absolute; left: 8px; top: 50%; transform: translateY(-50%); color: var(--ink-3); }
+  .filter-search .fake {
+    display: flex; align-items: center; height: 32px; padding: 0 8px 0 28px; border: 1px solid var(--line-mid);
+    border-radius: 4px; background: #fff; color: var(--ink-3); font-size: 14px;
+  }
+
   .seal-stamp {
     display: inline-flex; align-items: center; justify-content: center; width: 28px; height: 28px; border-radius: 3px;
     background: var(--seal); color: var(--paper); font-family: var(--serif); font-weight: 400; font-size: 16px; line-height: 1;
@@ -302,6 +325,7 @@
     <a href="#badges">Badges</a>
     <a href="#action-colors">Action colors</a>
     <a href="#dropdowns">Dropdowns</a>
+    <a href="#filter-bars">Filter bars</a>
     <a href="#multi-value">Multi-value fields</a>
     <a href="#icons">Icons</a>
     <a href="#tooltips">Tooltips</a>
@@ -503,6 +527,7 @@
         <tr><td><code>info</code> (light blue)</td><td>A view toggle that must be easy to find, not an action on data: "Full screen" / "Restore" in the Jobs drawer bar. Blue = read-only.</td></tr>
         <tr><td><code>secondary</code> (white)</td><td>Everything else: Verify, Visit, Discard, Copy, navigation.</td></tr>
         <tr><td><code>danger</code> (white, red text)</td><td>Cancel a running job, destructive confirmations.</td></tr>
+        <tr><td><code>invalid</code> (red field)</td><td>A control that is required and still empty, drawn as a button because it opens a panel instead of a native list (the environment picker of the case toolbar). The same red as an invalid dropdown; it is not an action.</td></tr>
       </tbody>
     </table>
     <p class="small muted">Hover lifts the button 1px; disabled is 50% opacity with no shadow. With an icon, add <code>gap-1.5</code> to the button.</p>
@@ -522,7 +547,7 @@
       <tbody>
         <tr><td><span class="badge green">green</span></td><td>ok: Logged in</td><td>Succeeded</td></tr>
         <tr><td><span class="badge red">red</span></td><td>expired, missing</td><td>Failed</td></tr>
-        <tr><td><span class="badge amber">amber</span></td><td>unverified, error</td><td>Needs your input (an AI run that ended with <code>RESULT: needs-input</code>)</td></tr>
+        <tr><td><span class="badge amber">amber</span></td><td>unverified, error</td><td>Needs your input (an AI run that ended with <code>RESULT: needs-input</code>) or No result (a run that printed no <code>RESULT:</code> line at all)</td></tr>
         <tr><td><span class="badge blue">blue</span></td><td>-</td><td>Running</td></tr>
         <tr><td><span class="badge gray">gray</span></td><td>-</td><td>Cancelled</td></tr>
       </tbody>
@@ -584,7 +609,7 @@
       <tbody>
         <tr><td><code>explore-case</code></td><td>blue (qing)</td><td>Edits only the case file (wording, observations, open questions, inputs). The agent only reads pages; you do the steps that write data.</td></tr>
         <tr><td><code>gen-spec</code></td><td>amber (gold)</td><td>Writes: creates the spec and fills the case's <code>## Values</code>. Does not run the tests.</td></tr>
-        <tr><td><code>heal-spec</code></td><td>red (seal)</td><td>Rewrites an existing spec and runs the tests.</td></tr>
+        <tr><td><code>heal-spec</code></td><td>red (seal)</td><td>Repairs the spec or refines the case and the spec, then runs the tests.</td></tr>
       </tbody>
     </table>
     <p class="small muted">
@@ -600,6 +625,14 @@
       <code>Select</code> is a button that draws its own list under it, in a <code>card-popup</code> panel, which is what
       gives every dropdown the same raised look.
     </p>
+    <p class="small muted">
+      Two controls put their label inside the button and open a panel with a title rather than a bare list: the
+      environment picker of the case toolbar (<code>Env: staging</code>, <code>components/env-picker.tsx</code>) and the
+      profile picker beside it (<code>Profiles: 2 of 3</code>, <code>components/profile-picker.tsx</code>). They are
+      buttons because their list needs a title and a line of explanation, not a <code>Select</code>; they keep this
+      section's height, <code>card-popup</code> panel, keyboard and click-outside rules. Do not turn them back into a
+      <code>Select</code> that repeats the label on every row.
+    </p>
     <div class="demo">
       <span class="select"><span class="fake">staging</span><svg class="chev" xmlns="http://www.w3.org/2000/svg" width="14" height="14" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><polyline points="6 9 12 15 18 9"></polyline></svg></span>
       <span class="select focus"><span class="fake">staging</span><svg class="chev" xmlns="http://www.w3.org/2000/svg" width="14" height="14" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><polyline points="6 9 12 15 18 9"></polyline></svg></span>
@@ -654,6 +687,60 @@
       </tbody>
     </table>
 
+    <h3 id="filter-bars">Filter bars</h3>
+    <p>
+      A list that can get long (the profiles of the workspace, the profiles of a case's Values table) gets a filter bar
+      above it: <code>SearchField</code> and <code>FilterChips</code> from <code>ui/web/src/components/</code>. They are
+      controls only; the page decides what a value means and filters its own rows.
+    </p>
+    <div class="demo" style="display:block">
+      <div class="filter-search" style="margin-bottom:8px">
+        <svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><circle cx="11" cy="11" r="8"></circle><line x1="21" y1="21" x2="16.65" y2="16.65"></line></svg>
+        <span class="fake">atpil</span>
+      </div>
+      <div style="display:flex;flex-wrap:wrap;gap:8px 16px">
+        <div class="filters">
+          <span class="group-label">Env</span>
+          <span class="filter-chip">All <span class="count">17</span></span>
+          <span class="filter-chip on production">PRODUCTION <span class="count">7</span></span>
+          <span class="filter-chip on staging">STAGING <span class="count">8</span></span>
+          <span class="filter-chip">SANDBOX <span class="count">2</span></span>
+        </div>
+        <div class="filters">
+          <span class="group-label">Tag</span>
+          <span class="filter-chip">All <span class="count">17</span></span>
+          <span class="filter-chip on">atp <span class="count">6</span></span>
+          <span class="filter-chip">compass <span class="count">4</span></span>
+          <span class="filter-chip">corp <span class="count">4</span></span>
+        </div>
+      </div>
+      <p class="small muted" style="margin:8px 0 0">Showing 6 of 17 profiles · <span style="text-decoration:underline">Clear filters</span></p>
+    </div>
+    <p class="small muted">
+      Search "atpil" with the dashes left out, both environments pressed and one tag: the two groups are combined with
+      AND.
+    </p>
+    <pre class="card mono" style="overflow:auto">import {SearchField} from '../components/search-field';
+import {FilterChips} from '../components/filter-chips';
+
+&lt;SearchField value={query} onChange={setQuery} ariaLabel="Search profiles" placeholder="Search id, name..." /&gt;
+&lt;FilterChips label="Env" selected={envFilter} onChange={setEnvFilter} allCount={profiles.length}
+  options={envs.map((env) =&gt; ({value: env, label: env.toUpperCase(), count: countOf(env), tone: envFillClass(env)}))} /&gt;</pre>
+    <table>
+      <thead><tr><th>Part</th><th>Rule</th></tr></thead>
+      <tbody>
+        <tr><td>Search</td><td>One <code>SearchField</code> at the top. It looks in id, name, account, environment, tags and address; every word of the query must match one of them. A compact copy without <code>-</code>, <code>_</code>, <code>.</code> or spaces lets <code>atpil</code> find <code>atp-il-staging</code>.</td></tr>
+        <tr><td>Groups</td><td>One <code>FilterChips</code> per kind of value (environment, tag). Inside a group a row matches <b>any</b> pressed value; the groups are combined with <b>AND</b>. An empty group filters nothing.</td></tr>
+        <tr><td>All</td><td>The first chip of a group clears that group only. It is pressed while the group has no selection, so "no filter" can always be told from "everything selected".</td></tr>
+        <tr><td>Counts</td><td>Each option shows how many rows it would leave, and <code>All</code> shows the group's total. Counts come from the unfiltered list, so they do not dance while a value is pressed.</td></tr>
+        <tr><td>Pressed look</td><td>Neutral chips take the page accent (<code>theme-btn</code>, white text). Environment chips pass <code>envFillClass(env)</code>, the same solid marker as <code>EnvBadge</code>, so color means the environment here too.</td></tr>
+        <tr><td>State</td><td>The chip is the button: <code>aria-pressed</code>, a tooltip with its name (and "pressed" while on), and the count as a second, quieter part of the label.</td></tr>
+        <tr><td>Feedback</td><td>While a filter is active, show <code>Showing N of M</code> and <b>Clear filters</b>. When nothing matches, the empty state repeats the clear action instead of leaving a blank table.</td></tr>
+        <tr><td>Not remembered</td><td>A filter is a way of looking, not a setting: do not put it in <code>localStorage</code>. A reload shows everything, so nothing looks missing after lunch.</td></tr>
+        <tr><td>In the case panel</td><td>The Values table adds a two-button <b>Rows: Keys / Profiles</b> switch beside the search as soon as a case names two profiles, and shows the search and the environment chips only when it names more than three. The filters and the switch belong to that case; opening another case starts unfiltered.</td></tr>
+      </tbody>
+    </table>
+
     <h2 id="multi-value">Multi-value fields</h2>
     <p>
       A field whose value is a list is never a <a href="#dropdowns">Dropdown</a> plus an "Add" text input: that mixes a
@@ -829,11 +916,12 @@
     </p>
     <p class="muted">
       The preview block that holds the editor caret is shaded with <code>theme-bg</code> at 60% and a 2px <code>theme</code> left
-      border (an overlay, so it follows the page theme). The editor and the preview scroll together and a click in the preview
-      moves the caret; the logic is in <code>ui/web/src/lib/preview-sync.ts</code>.
+      border (an overlay, so it follows the page theme). The overlay paints <b>behind</b> the text, never over it: the
+      highlighted block keeps its own text color instead of looking washed out. The editor and the preview scroll together
+      and a click in the preview moves the caret; the logic is in <code>ui/web/src/lib/preview-sync.ts</code>.
     </p>
     <p class="muted">
-      The previous / next buttons of the case toolbar move the caret to the next marker and blink that marker for a moment in
+      The previous / next buttons at the right end of the editor toolbar move the caret to the next marker and blink that marker for a moment in
       both panes (<code>cm-kw-flash</code> in the editor, <code>kw-flash</code> over the <code>&lt;mark&gt;</code> of the
       document): <code>gold-glow</code> at 65% behind it and a 2px <code>dai-deep</code> ring with a wider
       <code>gold-glow</code> glow around it, the ring blinking on and off three times (0.45&nbsp;s each), then it goes away.

package/docs/troubleshooting.md

@@ -69,6 +69,10 @@ is recorded.
 checkout has the card but not the screenshot. Run the exploration again on this machine (or look at the card and the
 report's baseline).
 
+**`/explore-case` takes long with many profiles** — pass `--profiles a,b` (the toolbar's profile picker does the same):
+only those profiles are opened, and a later run with the others adds what it finds. `/gen-spec` has nothing to pick: it
+covers every profile the case names.
+
 ## Installing
 
 **`pnpm add` installs the previous release instead of `latest`** — pnpm holds back versions published in the last
@@ -131,6 +135,6 @@ read it. `doctor` lists the overrides it sees.
 project. Add `--reset-rules` to replace them with the template, and expect to lose the project's rules.
 
 **The AI did something you did not expect** — exploring and generating only read pages and edit the case file; healing
-edits the spec and runs it under the same write gate as any run (staging writes are allowed, any other environment
-needs a person's confirmation). None of them writes product data on its own, and none updates a baseline. If a step
-needs a person to write, run it with `--attended`; that is where a person acts, in the browser.
+edits the case and the spec and runs the spec under the same write gate as any run (staging writes are allowed, any
+other environment needs a person's confirmation). None of them writes product data on its own, and none updates a
+baseline. If a step needs a person to write, run it with `--attended`; that is where a person acts, in the browser.

package/docs/web-ui.md

@@ -36,6 +36,10 @@ The UI's look is the **Inkstone** theme; the palette, buttons, badges and icons
 
 One row per profile, with the same login check as `pnpm status`.
 
+- **Filters** above the table: a search over id, name, account, environment, tags and address (a word may leave out
+  the dashes, so `atpil` finds `atp-il-staging`), plus multi-select chips for environments and tags. Every chip shows
+  how many profiles it leaves; the bar shows `Showing N of M profiles` and **Clear filters** while it is active. The
+  filters are not remembered, so a reload shows every profile again.
 - **Log in** starts `pnpm signin <profile-id>`: log in in the browser window that opens, then press **Done, save the
   session** on the card in that window (the job's "I've logged in, save the session" button does the same). A
   logged-in profile shows `Login YES`.
@@ -53,7 +57,7 @@ One row per profile, with the same login check as `pnpm status`.
 
 The case list is grouped by folder and collapses. The editor opens in **Single** with the **Panel** full width; the
 toolbar switches to **Split** (source left, one pane right; drag the divider to resize, double-click to reset) or, in
-Single, to **Editor** or **Doc**.
+Single, between **Panel**, **Editor** and **Doc**.
 
 - **Source and preview** scroll together, the preview block at the caret is shaded, and a click in the preview puts
   the caret on that line. `Ctrl/Cmd+S` saves.
@@ -66,7 +70,11 @@ Single, to **Editor** or **Doc**.
   answer and the AI folds it in). Then the front matter (title, login, suites, writes and its note, environments), the
   steps (sentence, `[writes]` / `[input]` / `[email]` tags, `- Ready when:` lines, `- Recipe:` lines), the
   `## Expected` and `## Visual checks` bullets (drag to reorder), the `## Values` table (one column per profile; an
-  empty cell inherits `default`), and the `## Targets` cards read-only, with what each is missing. `[T1]` chips open
+  empty cell inherits `default`), and the `## Targets` cards read-only, with what each is missing. With two or more
+  profiles the Values section offers a **Rows: Keys / Profiles** switch, and from four profiles on it also adds a
+  search and environment chips. With more profiles than keys it starts as one row per profile, so every name and
+  environment stays readable instead of being squeezed into a narrow column. Both the header and the profile/key
+  column stay in place while the table scrolls. `[T1]` chips open
   the card: what it is, where, how it is identified, what it must not be, and its reference screenshots. Every section
   collapses and has a **?** with a short help card. Panel edits land in the same draft as the source editor, so one
   save covers both, and **Discard** throws them away together.
@@ -76,7 +84,9 @@ Single, to **Editor** or **Doc**.
   the spec is rewritten. **Delete** (type the id, or fill it in with the feather icon) removes the case, its spec and
   its baselines; both dialogs list exactly what they touch, and are refused while an AI or test run is in progress.
 - **Toolbar:** command (explore / generate / heal, explore by default), **Environment** (required, no default),
-  **Attended** (only for explore, ticked by default), **Run AI**, copy the shell command, open the AI guide.
+  **Profiles** (explore only: every profile that is logged in is ticked, the choice is remembered per environment, and
+  only the ticked ones are opened), **Attended** (only for explore, ticked by default), **Run AI**, copy the shell
+  command, open the AI guide.
 - **From memo** opens a Markdown editor with a preview for raw notes. **Make cases** saves them to `.tmp/memos/` and
   runs `/make-case` one-shot (defaults for gaps, `TODO` for unknown values, no page exploration, existing cases never
   overwritten); **Copy /make-case** copies the memo for the interactive dialogue. When the run ends, **What to do
@@ -117,9 +127,21 @@ cancelled there. Opening it shrinks the page instead of covering it.
   `.tmp/ui-jobs/`.
 - When an AI job ends, a thin **What to do next** bar appears under the log (or **Details** opens it in a sheet):
   open questions with an answer box and **Use the suggested defaults**, the confirmations the exploration marked, and
-  the next action (**Generate spec**, **Open Run tests**). A run that ends with `needs-input` gets an amber *Needs
-  your input* badge; sending answers continues the same conversation, once per turn and only while the UI server has
-  not restarted. After a restart, answer in the case file and run the command again.
+  the next action (**Generate spec**, **Open Run tests**, **View spec**, **Re-explore**). A run that ends with
+  `needs-input` gets an amber *Needs your input* badge; sending answers continues the same conversation, once per turn
+  and only while the UI server has not restarted. After a restart, answer in the case file and run the command again.
+- A run that ends without its `RESULT:` line gets an amber *No result* badge and a banner under the command instead of
+  a "what to do next" bar: nothing is known about what it did, so read the log before trusting the case or the spec.
+  A run that is not allowed to write files (plan mode, a read-only sandbox) ends that way; the framework starts
+  OpenCode with `--agent build` so that a one-shot run is never a plan.
+- A **Generate spec** or **Re-explore** button opens the case with its Run AI button already on that command, in the
+  case view: the button gets a dark ring and an amber pulse, and a gold strip under the toolbar says what is still
+  missing (an environment, a save), until the run starts or you pick another command.
+- After **Generate spec**, **View spec** opens the case on the spec editor. After **Heal spec**, the bar says either
+  that the case and the spec are up to date (with **View spec**), or that the case changed and needs your review: then
+  it counts the must-answer questions, suggestions and lines to confirm, and offers **Review the questions** /
+  **Review the marked lines** and **Re-explore** — healing does not generate a spec from a case that still asks
+  something.
 
 ## Help and AI guide
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@asrunjs/asrun",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "description": "Multi-profile end-to-end test suite: plain-language cases, AI-written Playwright specs, evidence for every run.",
   "license": "UNLICENSED",
   "author": "Zoro Chen",

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

@@ -8,15 +8,20 @@ Rules combine in this order, and a later one wins where they conflict: the frame
 `{{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
+Arguments: `<case-id> <env> [--attended] [--profiles a,b]`. 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.
+`--profiles a,b` explores only those profiles (comma-separated ids from `profiles.yaml`); without it, at least one
+logged-in profile per domain. A profile the list leaves out is not opened and nothing is written about it: runs add up,
+so a later run covers the rest.
 
 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.
+the chat: write open questions into the case file as the skill describes, and end with the `RESULT:` line. If you are
+not allowed to write files at all (a plan-mode run, a read-only sandbox), say what blocked you and end with
+`RESULT: needs-input`.

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

@@ -12,10 +12,13 @@ Rules combine in this order, and a later one wins where they conflict: the frame
 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.
+There is no profile option: the spec is generated for every profile the case holds information for (its `## Values`
+keys, its target cards and its observations), not for a chosen subset and not only for the profiles that are logged in.
 
 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.
+QA, write the remaining questions into the case file), and end with the `RESULT:` line. If you are not allowed to write
+files at all (a plan-mode run, a read-only sandbox), say what blocked you and end with `RESULT: needs-input`.

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

@@ -1,8 +1,8 @@
 ---
-description: Diagnose and fix a failing spec from its last report (without hiding real product regressions)
+description: Repair a failing spec, or refine a case and its spec on request, without hiding real product regressions
 ---
 
-Load the framework skill `{{framework}}/.claude/skills/generating-specs/SKILL.md`, section "Healing a failing
+Load the framework skill `{{framework}}/.claude/skills/generating-specs/SKILL.md`, section "Healing and refining a
 spec", and follow it exactly.
 
 Rules combine in this order, and a later one wins where they conflict: the framework baseline
@@ -13,19 +13,29 @@ 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>`.
+- `--profiles`: the profiles to run when evidence is needed. 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.
+- `--hints <file>`: a file with what the user wants repaired or improved, with any evidence. Read it first. Any free
+  text after the arguments is the same kind of request. 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>`.
+A passing run is not a reason to refuse a request: healing also refines a case and its spec. Never lower the bar for a
+product finding to make a test pass.
+
+Do not ask me questions in the chat: this may run unattended. Resolve what the report, the case and the page can
+resolve, and write what still needs a person into the case as a `[blocking]` question. End with the `RESULT:` line:
+`ready` when the healing or the refinement is finished, `needs-input` when something is still open. If you could not
+write files at all (a plan-mode run, a read-only sandbox, a refused permission), say in one sentence what blocked you
+and end with `RESULT: needs-input`: never answer with a plan and a question instead.
+
+Before you decide "product or test", audit the assertion itself (target card, baseline content, readiness): see step 5
+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.
+the skill says it is needed. Always run with `--logged-in`. If the change leaves an open question or an unconfirmed
+marker in the case, stop there, tell me to review the case and run `/explore-case`, and end with
+`RESULT: needs-input`. Otherwise 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`.
+(`;` 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`.