@asrunjs/asrun 0.11.0 → 0.12.0

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

@@ -6,7 +6,8 @@ Load the `exploring-cases` skill and explore: $ARGUMENTS
 In this repository the workspace is `examples/demo` (set `ASRUN_ROOT=examples/demo`); the framework is `.`.
 Rules combine in this order, and a later one wins where they conflict: the framework baseline `AGENTS.md`, the
 framework skill, `.claude/skills/exploring-cases.md` if it exists, then the workspace `AGENTS.md` §2 in `examples/demo`
-(Project rules). F1–F6 and R2 always win.
+(Project rules). F1–F6 and R2 always win. The effective set is what `pnpm asrun rules` prints; §2 is applied as
+written and is never turned into a question (a difference from a framework default is not a conflict).
 Arguments: `<case-id> <env> [--attended] [--profiles a,b] [--hints <file>]`. 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

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

@@ -6,7 +6,8 @@ Load the `generating-specs` skill and generate the spec for: $ARGUMENTS
 In this repository the workspace is `examples/demo` (set `ASRUN_ROOT=examples/demo`); the framework is `.`.
 Rules combine in this order, and a later one wins where they conflict: the framework baseline `AGENTS.md`, the
 framework skill, `.claude/skills/generating-specs.md` if it exists, then the workspace `AGENTS.md` §2 in `examples/demo`
-(Project rules). F1–F6 and R2 always win.
+(Project rules). F1–F6 and R2 always win. The effective set is what `pnpm asrun rules` prints; §2 is applied as
+written and is never turned into a question (a difference from a framework default is not a conflict).
 Arguments: `<case-id> [<env>] [--force] [--hints <file>]`. 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. `--hints <file>` (or free text

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

@@ -6,7 +6,8 @@ Load the `generating-specs` skill, section "Healing and refining a spec", and fo
 In this repository the workspace is `examples/demo` (set `ASRUN_ROOT=examples/demo`); the framework is `.`.
 Rules combine in this order, and a later one wins where they conflict: the framework baseline `AGENTS.md`, the
 framework skill, `.claude/skills/generating-specs.md` if it exists, then the workspace `AGENTS.md` §2 in `examples/demo`
-(Project rules). F1–F6 and R2 always win.
+(Project rules). F1–F6 and R2 always win. The effective set is what `pnpm asrun rules` prints; §2 is applied as
+written and is never turned into a question (a difference from a framework default is not a conflict).
 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

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

@@ -6,6 +6,7 @@ Load the `making-cases` skill and turn this input into case documents: $ARGUMENT
 In this repository the workspace is `examples/demo` (set `ASRUN_ROOT=examples/demo`); the framework is `.`.
 Rules combine in this order, and a later one wins where they conflict: the framework baseline `AGENTS.md`, the
 framework skill, `.claude/skills/making-cases.md` if it exists, then the workspace `AGENTS.md` §2 in `examples/demo`
-(Project rules). F1–F6 and R2 always win.
+(Project rules). F1–F6 and R2 always win. The effective set is what `pnpm asrun rules` prints; §2 is applied as
+written and is never turned into a question (a difference from a framework default is not a conflict).
 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/.claude/skills/exploring-cases/SKILL.md

@@ -15,10 +15,15 @@ in the browser while the agent waits, and how it is recorded). All but the last
 too.
 
 ## Before you start
-Read the workspace `AGENTS.md`: its §2 holds the project rules, and it points at the framework baseline. If
-`.claude/skills/exploring-cases.md` exists in the workspace, read it and apply it after this skill. Then apply
-`AGENTS.md` §2, which wins over both (the baseline, "Precedence"). F1–F6 and R2 always win. This is not a stop
-condition: continue with the procedure below.
+Run `pnpm asrun rules --json` (or `pnpm asrun rules` for people): it prints the framework baseline, the project's
+`AGENTS.md` §2 rules and the project settings (the test-data prefix). Those are the effective rules; if the command is
+unavailable, read the workspace `AGENTS.md` directly. Also read `AGENTS.md` §2, and `.claude/skills/exploring-cases.md`
+in the workspace, applying the override after this skill and §2 after both (the baseline, "Precedence"). F1–F6 and R2
+always win. **Never turn a project rule into a question:** a difference between §2 and a framework default is not a
+conflict; apply §2 and, if a row's id does not fit its text, apply the text and report the mismatch. This is not a stop
+condition: continue with the procedure below. If `pnpm asrun rules` exits 1 (an invalid §2 row or a prefix that the
+document and `package.json` disagree on), do not guess and do not turn it into a case question: report its errors and
+end with `RESULT: needs-input`; a person fixes `AGENTS.md` or `package.json` first.
 
 ## Where this skill sits
 Three steps, each learns one thing:
@@ -70,7 +75,8 @@ one exception is a handoff in an attended run, where waiting for the person is t
    - ambiguous steps and checks without an expected result;
    - steps that write data or need a choice: mark them `[writes]` / `[input]`. The front matter must list the
      environments the finished spec may write in (`writes: [staging]`, or `[staging, production]`) with a
-     `writes-note`, the data must be named `[asrun] ...` and cleaned up, and a step that sends email is never
+     `writes-note`, the data must be named with the project's test-data prefix (default `[asrun]`, printed by
+     `pnpm asrun rules`) followed by a run stamp, and cleaned up; a step that sends email is never
      allowed in production and only in other environments when the profile has `email: true`;
    - missing or doubtful `suites`/`envs`, a `writes` environment that `envs` excludes, and visual checks that are
      too broad (screenshot a small element);
@@ -128,7 +134,9 @@ one exception is a handoff in an attended run, where waiting for the person is t
    `[blocking]` TODO, never a guess. Check the screenshots you saved: each must show what its card says.
 6. **Write the recipe lines** for every `[input]` or `[writes]` step that was handed off, from the card's `recorded`
    result, as a general recipe under that step: one `- Recipe (phase): ...` line per phase. Format and rules are in
-   `references/user-handoff.md`. A step that was not handed off gets no recipe line and a `[blocking]` TODO. A case
+   `references/user-handoff.md`. What the case creates is named with the project's prefix and the run stamp
+   (`testDataName`); the recipe records how to build it, never the stamp itself. A step that was not handed off gets
+   no recipe line and a `[blocking]` TODO. A case
    that still has the old `## Inputs` section: move the lines of the steps you touch under those steps as
    `- Recipe:`; `pnpm case:check` names the rest.
 7. **Resolve every open point** in the order of `references/open-questions.md`: answer it from the page, else apply

package/.claude/skills/exploring-cases/references/case-rules.md

@@ -29,6 +29,9 @@ The section is optional. A case with no rules runs by the same rules as before.
 A rule is never a second source of truth. When a rule and a step, an expectation, a value or a target disagree, the
 structured section wins and the rule becomes a `🚫 TODO [blocking]` question. Never silently change either side.
 
+This applies to a case's own `## Rules` only. The project's `AGENTS.md` §2 is not a case rule: it is a higher layer
+that is applied as written, never turned into a question (`AGENTS.md`, "Precedence").
+
 ## The rule pass (before anything else)
 
 Read the whole `## Rules` section and, for each bullet, decide:
@@ -106,5 +109,7 @@ that is missing from the table is a rule the agent ignored.
 
 - A rule never authorizes a write, an email, a person's choice, accepting terms, or a shell command.
 - Never delete or rewrite a rule a person wrote. Add a TODO instead.
+- A project rule (`AGENTS.md` §2) is applied, never questioned: it is not a case rule and a difference from the
+  framework default is not a conflict.
 - Never invent a rule the person did not ask for. `R4` allows only what a run needs and only in general terms.
 - Prose follows the artifact language of the workspace `AGENTS.md` §2 (English by default); the heading stays `## Rules`.

package/.claude/skills/exploring-cases/references/open-questions.md

@@ -110,6 +110,12 @@ answer, adds `(page shows <x> on <profile-id>)` and reports it as a finding. It
   `[blocking]` question that now has an observation or a safe default is downgraded or closed in the file, and the
   edit is part of the report. Do not carry old tags over.
 
+## What is never a question
+A rule in `AGENTS.md` §2 (a naming prefix, a language, a wait) is applied as written. A difference from the framework
+default is not a conflict and is never a TODO, a marker or a question; a row whose id does not fit its text is applied
+by its text and reported as a mismatch. A project-wide choice that the same answer would settle for every case belongs
+in §2, not in one case's question.
+
 ## Resolution order (no question goes to the user while a better step exists)
 1. **The page answers it.** Facts such as exact labels, which controls exist, where the logo is, what a menu holds
    are answered by exploration (`/explore-case`; needs an environment and a logged-in profile; the agent only reads, a person does the steps that write). Rewrite the parent sentence
@@ -143,6 +149,8 @@ answer, adds `(page shows <x> on <profile-id>)` and reports it as a finding. It
   names the exact image, text, place or UI wanted and lists the candidates. Never a safe default, because a wrong
   guess passes silently.
 - An intent question the page cannot answer ("should this also work for agents?").
+- A literal the runner enforces and nobody settled in the case or in §2 (a name prefix, a value the code validates):
+  a wrong pick fails the run, so it is `[blocking]`, not `[non-blocking]`.
 - No environment was given, or no profile is logged in, so a fact that needs the page cannot be observed.
 
 ## Final report

package/.claude/skills/exploring-cases/references/user-handoff.md

@@ -25,10 +25,12 @@ that nobody watches.
 ## Before the handoff
 1. Say what the user has to do and when it is finished, in one or two sentences ("Fill in the form, pick two
    items, then press Done"). Name the finish condition first (below).
-2. Put every text the user has to type into `copy` (the `[asrun] ...` name of a document, a title), so it can be
-   copied with one click.
+2. Put every text the user has to type into `copy` (the name of a document, a title), so it can be
+   copied with one click. Build a created name with the project's test-data prefix (default `[asrun]`, printed by
+   `pnpm asrun rules`) and a run stamp: `<prefix> <base> (<YYYY-MM-DD HH-mm-ss>, UTC)`, the same shape
+   `testDataName()` builds. The stamp is chosen now, not recorded in the recipe.
 3. Never ask the user to send email (production: never; other environments: only when `email` is `true` for the
-   profile). Never ask for login or 2FA. Name everything the user creates `[asrun] <something>`.
+   profile). Never ask for login or 2FA. Name everything the user creates `<prefix> <something> (<run stamp>)`.
 4. Do not start a recording yourself: the card starts and stops it (see "Recording"). Never call
    `browser_start_recording` or `browser_stop_recording`: the `playwright-test` MCP lists them but cannot run them
    (`devtools` tools; see `tools.md`).
@@ -40,7 +42,7 @@ timeout), so no polling from outside is needed. The loop:
 - **Shows a small floating card, not a bar.** It sits in the bottom-left corner and only the card takes clicks, so
   nothing of the page is covered or blocked. The user can **drag** it by its title bar and **minimize** it to a small
   pill that still has a Done button. Position and minimized state survive a page reload (kept in `sessionStorage`).
-- **Click to copy.** Every text in `copy` (for example the `[asrun] ...` name the user has to type) is shown on its
+- **Click to copy.** Every text in `copy` (for example the `<prefix> <name> (<run stamp>)` the user has to type) is shown on its
   own line with a copy icon; one click puts it on the clipboard and the icon shows "Copied". Pass only text that the
   case says to type; leave `copy` empty when there is none.
 - **Resets the flag first**: `window.__handoff = null` on every page it paints. A flag left over from an earlier
@@ -71,7 +73,7 @@ badge, no count in the tab title and no notification (a HINT in the job log says
    async (page) => {
      page.context().__handoffCfg = {
        message: '<what the user does, one sentence>',
-       copy: [],                  // texts to type, e.g. ['[asrun] published document']
+       copy: [],                  // texts to type, e.g. ['[autotest] published document (2026-11-09 12-34-56)']
        doneText: null,            // text that appears when finished, or null
        maxMs: 600000,
      };
@@ -114,8 +116,9 @@ The Done button is always there (also on the minimized card) as the fallback, an
 - `outcome: 'timeout'` or `'skip'`: do not guess. Write a `TODO [blocking]` under the step and go on with what does
   not depend on it.
 - Take a snapshot, write down what the user did from the card's `recorded` (see "Recording"), then continue read-only.
-- At the end of the exploration hand off once more when the user created data: "Delete the [asrun] items you
-  created, then press Done". The case must clean up after itself, and so must the exploration.
+- At the end of the exploration hand off once more when the user created data: "Delete the test items you
+  created (they start with <the project's prefix> and carry this run's timestamp), then press Done". The case must
+  clean up after itself, and so must the exploration.
 
 ## Recording
 The card records what the person does: it starts the recording when it shows and stops it on every way out (Done,
@@ -134,7 +137,8 @@ Make the recipe as general as possible, because lists and data change:
   name or id. "Select items #1 to #3 from the list."
 - **Random is allowed only when the user asks for it** ("pick any 3"). The default is the position, because it can be
   repeated. A random pick must be written into the test's annotations when the spec runs.
-- **Text the case creates**: `[asrun] <something>`.
+- **Text the case creates**: `<prefix> <something> (<run stamp>)` (prefix from `package.json`
+  `"asrun.testDataPrefix"`, default `[asrun]`). The recipe says how to build it; it never records the stamp itself.
 - **A value that has to exist** (an existing name, a search term): the recipe says what it must be like ("a name
   that returns a result") and notes the observed value as plain text `(seen on <profile>: "<value>")`. Do not put a
   brittle literal in as the only truth. One claim carries one signal: when a `[non-blocking]` TODO under the recipe

package/.claude/skills/generating-specs/SKILL.md

@@ -37,10 +37,15 @@ spec afterwards (see the report). Healing (below) is the exception: it reads the
 and the spec, and runs only the profiles that are logged in, and only when the report is not enough.
 
 ## Before you start
-Read the workspace `AGENTS.md`: its §2 holds the project rules, and it points at the framework baseline. If
-`.claude/skills/generating-specs.md` exists in the workspace, read it and apply it after this skill. Then apply
-`AGENTS.md` §2, which wins over both (the baseline, "Precedence"). F1–F6 and R2 always win. This is not a stop
-condition: continue with the procedure below.
+Run `pnpm asrun rules --json` (or `pnpm asrun rules` for people): it prints the framework baseline, the project's
+`AGENTS.md` §2 rules and the project settings (the test-data prefix). Those are the effective rules; if the command is
+unavailable, read the workspace `AGENTS.md` directly. Also read `AGENTS.md` §2, and `.claude/skills/generating-specs.md`
+in the workspace, applying the override after this skill and §2 after both (the baseline, "Precedence"). F1–F6 and R2
+always win. **Never turn a project rule into a question:** a difference between §2 and a framework default is not a
+conflict; apply §2 and, if a row's id does not fit its text, apply the text and report the mismatch. This is not a stop
+condition: continue with the procedure below. If `pnpm asrun rules` exits 1 (an invalid §2 row or a prefix that the
+document and `package.json` disagree on), do not guess and do not turn it into a case question: report its errors and
+end with `RESULT: needs-input`; a person fixes `AGENTS.md` or `package.json` first.
 
 ## Inputs
 - The case id and the environment to explore in (`staging` or `production`). There is no default. If the
@@ -138,7 +143,7 @@ Decide this first, before exploring anything. The spec path is `tests/<id>.spec.
    avoid. **Never perform a step that writes or needs a choice**: the agent does not write
    data, in staging or in production, and it does not hand off to a person here or wait for one. A rule never
    authorizes one of those steps. Write those steps
-   of the spec from the `- Recipe:` lines under the step (positions, `[asrun]` names, control labels and roles that
+   of the spec from the `- Recipe:` lines under the step (positions, created names, control labels and roles that
    `/explore-case` recorded). Pages that only exist after such a step cannot be seen from here: write their locators
    from a fresh note first, then from the recipe, and mark them in the report as "observed by explore on <profile>" or
    "not verified on the page"; leave the first run of the spec (or `/heal-spec`) to confirm the latter. Do this for at
@@ -207,11 +212,13 @@ Decide this first, before exploring anything. The spec path is `tests/<id>.spec.
 
 ## Cases that write data
 Only when the case front matter lists environments under `writes` (for example `writes: [staging]`). Never add
-`--allow-writes` or set `ASRUN_ALLOW_WRITES`. Use the `records` fixture, `configureCase` and `emailStepAllowed` as
-described in `references/conventions.md`. The agent does not perform write steps while generating (see step 4); the
-spec does, when a person runs it in an environment that `writes` lists. Elsewhere the runner skips the case with a
-notice. Never send email in production; in other environments only if `profile.email` is true, otherwise skip that step and say so
-in the report.
+`--allow-writes` or set `ASRUN_ALLOW_WRITES`. Use the `records` fixture, `configureCase`, `testDataName` and
+`emailStepAllowed` as described in `references/conventions.md`. Every name the case creates is
+`testDataName(expected.<key>)`, using the base literal from `## Values` and the project prefix from
+`pnpm asrun rules`; use the composed value for the form, the locators and `records.track`. The agent does not perform
+write steps while generating (see step 4); the spec does, when a person runs it in an environment that `writes` lists.
+Elsewhere the runner skips the case with a notice. Never send email in production; in other environments only if
+`profile.email` is true, otherwise skip that step and say so in the report.
 
 ## Healing and refining a spec
 Inputs: the case id and the environment (both required, there is no default: without an environment stop and say so),

package/.claude/skills/generating-specs/references/conventions.md

@@ -47,8 +47,12 @@ and `@writes` for cases that write data (drives `--read-only`).
   A case that writes only in some environments is skipped (not failed) in the others, with a notice.
 
 ## Cases that write data (`writes: [<env>, ...]`)
-- Name everything the case creates `[asrun] <something>` (`TEST_DATA_PREFIX` in `@asrunjs/asrun/records`). `records.track`
-  refuses other names, so cleanup can never touch real data.
+- Name everything the case creates through `testDataName(base)` (`@asrunjs/asrun/records`), where `base` is the
+  literal from the case's `## Values`: it returns `<prefix> <base> (<UTC run stamp>)`, for example
+  `[asrun] Draft CMA (2026-11-09 12-34-56)`. The prefix is the project's `asrun.testDataPrefix` (default `[asrun]`,
+  printed by `pnpm asrun rules`). `records.track` refuses a name without the prefix, and the stamp keeps two runs
+  apart so a person can find and delete one run's data. Compose a name once and use that variable for the form, the
+  locators, the assertions and `records.track`; never pass a raw `expected.*` value as the created name.
 - Register data with the `records` fixture right after creating it, together with the function that removes it:
   `await records.track({kind: 'Document draft', name, where: '/app/documents'}, async () => {...delete it from the documents list...});`
   Everything tracked is removed after the test, newest first, also when the test failed. The remove function opens

package/.claude/skills/making-cases/SKILL.md

@@ -16,10 +16,15 @@ Read the workspace `AGENTS.md` (hard rules and project rules) and `cases/_templa
 This skill writes `cases/*.md` only. It never writes specs, `profiles.yaml`, or anything under `tests/`.
 
 ## Before you start
-Read the workspace `AGENTS.md`: its §2 holds the project rules, and it points at the framework baseline. If
-`.claude/skills/making-cases.md` exists in the workspace, read it and apply it after this skill. Then apply `AGENTS.md`
-§2, which wins over both (the baseline, "Precedence"). F1–F6 and R2 always win. This is not a stop condition:
-continue with the procedure below.
+Run `pnpm asrun rules --json` (or `pnpm asrun rules` for people): it prints the framework baseline, the project's
+`AGENTS.md` §2 rules and the project settings (the test-data prefix). Those are the effective rules; if the command is
+unavailable, read the workspace `AGENTS.md` directly. Also read `AGENTS.md` §2, and `.claude/skills/making-cases.md`
+in the workspace, applying the override after this skill and §2 after both (the baseline, "Precedence"). F1–F6 and R2
+always win. **Never turn a project rule into a question:** a difference between §2 and a framework default is not a
+conflict; apply §2 and, if a row's id does not fit its text, apply the text and report the mismatch. This is not a stop
+condition: continue with the procedure below. If `pnpm asrun rules` exits 1 (an invalid §2 row or a prefix that the
+document and `package.json` disagree on), do not guess and do not turn it into a case question: report its errors and
+stop before writing anything; a person fixes `AGENTS.md` or `package.json` first.
 
 ## Inputs
 - Raw notes: pasted text or a file path. Any language, any quality.
@@ -43,7 +48,9 @@ continue with the procedure below.
    with a clear message until it is filled), never into `profiles.yaml`.
 5. **Ask before writing.** Show the user a short plan and the open questions in one message: the proposed split
    into cases, the classification (which steps write, which send email), and the gaps with your suggested default
-   for each. Wait for answers. Do not write case files before that.
+   for each. Wait for answers. Do not write case files before that. **Never ask a project-wide question:** §2 and
+   `pnpm asrun rules` settle project policy (the test-data prefix, the language, a wait); apply them. Ask only about
+   this case's unknowns.
 6. **Split** (`references/splitting.md`) and **write** `cases/<id>.md` for each case from `cases/_template.md`.
    - Group folder: when the notes (or the user) name an area (documents, search, account...), put the cases in
      `cases/<group>/<name>.md` and set `id: <group>/<name>` in the front matter. Use one folder level and

package/.claude/skills/making-cases/references/writes-and-email.md

@@ -14,9 +14,12 @@ dialog (read-only) but sending the share is `[writes]` and probably `[email]`. W
 ## What a case with writes must look like
 - Front matter: `writes: [<env>, ...]`, the environments the finished spec may write in (`[staging]`; add `production`
   only when the notes or the user say so), and a `writes-note` that says what is created, changed and removed, in one
-  sentence ("Creates one draft document named '[asrun] ...', publishes it, deletes it at the end"). The `writes-note`
+  sentence ("Creates one draft document named '[asrun] ... (<run stamp>)', publishes it, deletes it at the end"). The `writes-note`
   is the only summary; there is no separate Data section, and the removal itself is a step in `## Steps`.
-- Everything created is named `[asrun] <something>` (the spec enforces this).
+- Everything created is named `<prefix> <something> (<run stamp>)`, where the prefix is the project's
+  `asrun.testDataPrefix` (default `[asrun]`; `pnpm asrun rules` prints it) and the stamp is the UTC time of the run
+  (`testDataName()` builds it). The case's `## Values` holds the base without the stamp; the spec composes it, so two
+  runs never collide and a person can find one run's data in the product.
 - The case ends by deleting what it created. If the notes do not say how to delete it, that is a gap: ask, and
   never guess a delete path. Until it is known, write the likeliest delete step ("Select the 'Delete' option of the
   item's menu on the list page.") and put a `TODO [blocking]: How is <thing> deleted?` block under that step (see

package/AGENTS.md

@@ -2,7 +2,7 @@
 
 This file is the binding baseline for every project that uses the AsRun framework. It describes no particular
 product: a project adds its own rules in its own `AGENTS.md` §2, and they win where they differ (see "Precedence").
-Its hard rules carry ids (`F1`..`F10`, `B1`..`B4`, `A1`..`A6`).
+Its hard rules carry ids (`F1`..`F11`, `B1`..`B4`, `A1`..`A6`, `R1`..`R4`).
 
 Paths are relative to the **workspace root**: the project that owns `profiles.yaml`, `cases/` and `tests/`. In a
 project that uses asrun, the framework files are in `node_modules/@asrunjs/asrun` (an installed dependency: never edit it).
@@ -19,9 +19,16 @@ Rules are applied in this order; a later layer wins where they conflict.
    own procedure.
 5. **The project's `AGENTS.md` §2 (Project rules).** It states the project's intent and wins over layers 2–4.
 
-A project writes §2 only for what differs from the defaults here, names the rule id, and says whether it `narrows` or
-`replaces` the rule. `replaces` is refused for F1–F6 and R2; `pnpm asrun doctor` checks the table. A rule file never
-renames the structural tokens under "Fixed tokens".
+A project writes §2 only for what differs from the defaults here. A row names a baseline rule and says whether it
+`narrows` (stricter) or `replaces` (a different default) it; a rule with no baseline counterpart gets a project id
+(`P1`, `P2`, ...) and `adds`. `replaces` is refused for F1–F6 and R2; `pnpm asrun doctor` checks the table and
+`pnpm asrun rules` prints the effective set. A rule file never renames the structural tokens under "Fixed tokens".
+
+**A project rule is applied, never questioned.** §2 wins over the baseline defaults by definition, and a `P<n>` rule
+stands next to them: a difference between §2 and a framework default (a naming prefix, a language, a wait) is not a
+conflict and never becomes a TODO, a marker or a question in a case. The only refusal is a §2 row that weakens
+F1–F6/R2, and `doctor` reports that before any run. Options the framework needs at run time (the test-data prefix)
+live in `package.json` `"asrun"`, so the document and the code read the same value.
 
 Inside a case, `## Rules` is a case-local layer below this file and the project's §2: it says how to run that case,
 never what is true (`R1`), and a rule that conflicts with the rest of the case is a question, not an override.
@@ -57,6 +64,12 @@ never what is true (`R1`), and a rule that conflicts with the rest of the case i
   written in English by default. A project replaces this in §2 of its own `AGENTS.md` (for example Simplified Chinese
   for case prose and reports). Code, comments, identifiers, commit messages and the structural tokens under
   "Fixed tokens" always stay in English.
+- **F11 — Test data is findable per run.** A step that writes names what it creates with the project's test-data
+  prefix and a run stamp: `testDataName(base)` in `@asrunjs/asrun/records` builds `<prefix> <base> (<YYYY-MM-DD
+  HH-mm-ss>)`, the UTC time of the run id (so it matches `reports/<runId>` and the ledger). The prefix is
+  `asrun.testDataPrefix` in the project's `package.json` (default `[asrun]`). Two runs never share a name, and a
+  person can search the product for one run's data to edit or delete it by hand. The case's `## Values` holds the base
+  literal without the stamp; the spec composes it, and a check on the created item uses the composed name.
 
 ## Browser exploration rules (`B`)
 These apply to every agent that drives a browser to explore pages for cases or specs (`making-cases`,
@@ -160,7 +173,7 @@ This file holds the rules. The exact shape those rules apply to is documented on
 - `.claude/skills/exploring-cases/references/tools.md`: which browser tools the `playwright-test` MCP can run, the
   substitute for each one it only lists, and the arguments every call has to carry. Read it before the first browser
   call of a run.
-- `docs/commands.md`: every command and flag.
+- `docs/commands.md`: every command and flag, including `pnpm asrun rules`.
 - `docs/cases.md`: the same case format for the people who write cases by hand.
 - `docs/agents/framework-dev.md`: the framework's own layout and how to change it.
 The project's own `AGENTS.md` §2 (project rules) and §3 (project facts) still win over the documentation where they
@@ -173,6 +186,8 @@ differ, and `F1`–`F6` and `R2` win over everything.
 - `tests/**/*.spec.ts` generated Playwright specs (output of the AI workflow), one per case, same folder as the case,
   with their `*-snapshots/` baselines next to them
 - `profiles.yaml`       one entry per environment: URL, account label, tags, environment (connection settings only)
+- `package.json`        npm scripts and the framework dependency; its `"asrun"` object holds project settings
+  (for example `testDataPrefix`)
 - `AGENTS.md`           the project's own rules: they point at this baseline, and §2 holds what differs
 - `.auth/` `reports/` `.tmp/` `.explore/`  local state, never committed
 

package/README.md

@@ -138,11 +138,14 @@ Rules combine in this order, and a later layer wins where they conflict:
 2. The framework baseline, `node_modules/@asrunjs/asrun/AGENTS.md`.
 3. The framework skill.
 4. Your override, `.claude/skills/<skill>.md`.
-5. Your own `AGENTS.md` §2: a table of rule ids (`F7`–`F10`, `R1`, `R3`, `R4`) with `narrows` or `replaces`, for example
-   the artifact language.
+5. Your own `AGENTS.md` §2: a table of rule ids (`F7`–`F11`, `R1`, `R3`, `R4`) with `narrows` or `replaces`, and
+   project ids (`P1`, ...) with `adds` for a rule the baseline does not have, for example the artifact language or the
+   test-data prefix (`package.json` `"asrun"`). A difference from the baseline is applied, never turned into a
+   question.
 6. A case's `## Rules`: how to run that one case, never what is true.
 
-`pnpm asrun doctor` validates the table and lists the overrides it sees. An update never rewrites your rules:
+`pnpm asrun doctor` validates the table and `pnpm asrun rules` prints the effective set (the AI steps read it before
+they apply anything). An update never rewrites your rules:
 `init --force` refuses `AGENTS.md`, `CLAUDE.md` and `.claude/skills/**` without `--reset-rules`. Never edit the
 framework package itself: an update replaces it, and only the override files are yours. The AI tool stays configurable
 too: `.mcp.json` (Claude Code), `opencode.jsonc` (OpenCode and its model), `.claude/settings.json` (sandbox
@@ -193,7 +196,8 @@ the top bar. The check never blocks a command and stays quiet when the registry
 Tests run against real sites, so the defaults are strict:
 
 - **Read-only unless the case says otherwise.** A case may create, edit or delete data only in the environments it
-  lists under `writes`, and only data of the test accounts, named `[asrun] ...`, which it must clean up. Elsewhere the
+  lists under `writes`, and only data of the test accounts, named with the project's prefix (default `[asrun]`) and a
+  run stamp such as `[autotest] Draft CMA (2026-11-09 12-34-56)`, which it must clean up. Elsewhere the
   case is skipped with a notice, not failed.
 - **A person confirms non-staging writes on every run** by typing the environment name, or in a dialog in the UI.
   `--read-only` leaves those cases out; `--allow-writes=<env>` is for unattended runs, and AI agents never use it.
@@ -202,8 +206,8 @@ Tests run against real sites, so the defaults are strict:
   the browser, in an attended exploration. Logins are always a person's job, 2FA included.
 - **A failing baseline is a person's decision.** An agent never updates a baseline to make a difference disappear.
 
-The rules that enforce this are `F1`–`F10` in [AGENTS.md](./AGENTS.md); a project can tighten or replace the last
-four, never the first six.
+The rules that enforce this are `F1`–`F11` in [AGENTS.md](./AGENTS.md); a project can tighten or replace the last
+five, never the first six.
 
 ## Documentation
 

package/dist/lib/case-doc.d.ts

@@ -131,7 +131,7 @@ export interface CaseReadySignal {
 }
 /**
  * One `- Recipe (phase): ...` bullet under a step: what a person did for that step during `/explore-case --attended`,
- * as a general recipe (positions, `[asrun]` names, control labels). It is not test data: the asserted values live in
+ * as a general recipe (positions, created names, control labels). It is not test data: the asserted values live in
  * `## Values`.
  */
 export interface CaseRecipe {

package/dist/lib/config.d.ts

@@ -0,0 +1,26 @@
+/**
+ * Project-wide settings that the framework needs at run time, read from the `asrun` object of the workspace's
+ * `package.json`:
+ *
+ * ```json
+ * "asrun": { "testDataPrefix": "[autotest]" }
+ * ```
+ *
+ * The file is the project's own: `pnpm asrun init` merges it and never replaces it. A project that does not set an
+ * option gets the default below, so an existing workspace keeps working unchanged.
+ */
+export interface WorkspaceConfig {
+    /** The prefix every piece of data a case creates carries. Default `[asrun]`. */
+    testDataPrefix: string;
+}
+/** The frame's prefix: unmistakably test data, so cleanup can never touch real data. */
+export declare const DEFAULT_TEST_DATA_PREFIX = "[asrun]";
+/**
+ * Reads and validates the project settings. Throws an Error whose message says what to fix, so `doctor` and `rules`
+ * can report it and a spec that imports it fails with the same sentence instead of a confusing one.
+ */
+export declare function readWorkspaceConfig(): WorkspaceConfig;
+/** The prefix every name a case creates must start with. Reads `package.json`; default `[asrun]`. */
+export declare function testDataPrefix(): string;
+/** Forget the cached settings (a tool that edits `package.json` in the same process). */
+export declare function resetWorkspaceConfig(): void;

package/dist/lib/config.js

@@ -0,0 +1,51 @@
+import fs from 'node:fs';
+import path from 'node:path';
+import { ROOT } from './paths.js';
+/** The frame's prefix: unmistakably test data, so cleanup can never touch real data. */
+export const DEFAULT_TEST_DATA_PREFIX = '[asrun]';
+/** A bracketed lowercase word: `[asrun]`, `[autotest]`, `[qa_team]`. Easy to search for in the product. */
+const PREFIX = /^\[[a-z0-9][a-z0-9_-]*\]$/i;
+let cached = null;
+function readPackageJson() {
+    try {
+        const parsed = JSON.parse(fs.readFileSync(path.join(ROOT, 'package.json'), 'utf8'));
+        return parsed !== null && typeof parsed === 'object' && !Array.isArray(parsed)
+            ? parsed
+            : null;
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * Reads and validates the project settings. Throws an Error whose message says what to fix, so `doctor` and `rules`
+ * can report it and a spec that imports it fails with the same sentence instead of a confusing one.
+ */
+export function readWorkspaceConfig() {
+    if (cached !== null)
+        return cached;
+    const pkg = readPackageJson();
+    const section = pkg?.asrun;
+    if (section !== undefined && (section === null || typeof section !== 'object' || Array.isArray(section))) {
+        throw new Error('package.json: "asrun" must be an object, for example "asrun": { "testDataPrefix": "[autotest]" }.');
+    }
+    const raw = section?.testDataPrefix;
+    if (raw !== undefined && typeof raw !== 'string') {
+        throw new Error('package.json: "asrun.testDataPrefix" must be a string like "[asrun]".');
+    }
+    const prefix = (raw ?? DEFAULT_TEST_DATA_PREFIX).trim();
+    if (!PREFIX.test(prefix)) {
+        throw new Error(`package.json: "asrun.testDataPrefix" is "${prefix}"; use a bracketed word such as "[asrun]" or "[autotest]" ` +
+            '(letters, digits, "-" and "_" inside the brackets).');
+    }
+    cached = { testDataPrefix: prefix };
+    return cached;
+}
+/** The prefix every name a case creates must start with. Reads `package.json`; default `[asrun]`. */
+export function testDataPrefix() {
+    return readWorkspaceConfig().testDataPrefix;
+}
+/** Forget the cached settings (a tool that edits `package.json` in the same process). */
+export function resetWorkspaceConfig() {
+    cached = null;
+}

package/dist/lib/fixtures.d.ts

@@ -4,7 +4,7 @@ import { type Profile } from './profiles.js';
 export interface TrackedData {
     /** What it is, e.g. "Document draft". */
     kind: string;
-    /** Its name in the product. Must start with `[asrun]`, so cleanup can never touch real data. */
+    /** Its name in the product. Must start with the project's prefix, so cleanup can never touch real data. */
     name: string;
     /** Where a person finds it by hand if the cleanup fails, e.g. "/app/documents". */
     where?: string;

package/dist/lib/fixtures.js

@@ -2,7 +2,8 @@ import { expect, test as base } from '@playwright/test';
 import { getProfile } from './profiles.js';
 import { caseWrites, caseWritesIn, hasCaseFile, readCaseMeta } from './cases.js';
 import { acquireAccountLock } from './account-lock.js';
-import { ledgerFile, TEST_DATA_PREFIX, writeLedger } from './records.js';
+import { testDataPrefix } from './config.js';
+import { ledgerFile, writeLedger } from './records.js';
 import { caseIdFromFile } from './run-summary.js';
 import { ALLOW_WRITES_ENV, isProtectedEnv } from './write-gate.js';
 import { checkSession, isLoggedOutUrl, parseNotLoggedIn, sessionProblemMessage, signinCommand, } from './session.js';
@@ -76,9 +77,11 @@ export const test = base.extend({
         const save = () => writeLedger(file, entries.map((item) => item.entry));
         await use({
             async track(data, remove) {
-                if (!data.name.startsWith(TEST_DATA_PREFIX)) {
-                    throw new Error(`Test data must be named with the prefix "${TEST_DATA_PREFIX}" (got "${data.name}"). ` +
-                        `Only data that is clearly a test's own may be created and removed.`);
+                const prefix = testDataPrefix();
+                if (!data.name.startsWith(prefix)) {
+                    throw new Error(`Test data must be named with the project's prefix "${prefix}" (got "${data.name}"). ` +
+                        `Set "asrun.testDataPrefix" in package.json when the project uses another marker, and build the name ` +
+                        'with testDataName() so two runs never share it.');
                 }
                 entries.push({
                     entry: {

package/dist/lib/records.d.ts

@@ -1,4 +1,7 @@
-/** Every piece of data a test creates carries this prefix, so it can never be mistaken for real data. */
+/**
+ * The default prefix of data a test creates. The project's `package.json` may set another one
+ * (`"asrun": { "testDataPrefix": "[autotest]" }`); always read the effective value with `testDataPrefix()`.
+ */
 export declare const TEST_DATA_PREFIX = "[asrun]";
 export type RecordStatus = 'open' | 'cleaned' | 'leftover';
 /** One piece of test data a case created, as written to the ledger. */
@@ -10,7 +13,7 @@ export interface LedgerEntry {
     caseId: string;
     /** What kind of thing it is, e.g. "Document draft". */
     kind: string;
-    /** Its name in the product; always starts with TEST_DATA_PREFIX. */
+    /** Its name in the product; always starts with the project's test-data prefix (`testDataPrefix()`). */
     name: string;
     /** Where a person can find and remove it by hand, e.g. "/app/documents". */
     where: string | null;
@@ -20,6 +23,18 @@ export interface LedgerEntry {
     createdAt: string;
 }
 export declare const RECORDS_DIR: string;
+/** The run stamp appended to every name a test creates: the run id's UTC time (`2026-11-09 12-34-56`). */
+export declare function testDataStamp(now?: Date): string;
+/**
+ * The name of one piece of test data: `<base> (<run stamp>)`, for example
+ * `[autotest] Draft CMA (2026-11-09 12-34-56)`.
+ *
+ * The stamp is the run id's UTC time, so it matches the report folder and the ledger entry, and two runs never
+ * share a name: a person can search the product for the run's own data, edit it or delete it by hand. The base is
+ * the case's literal from `## Values`; it must start with the project's prefix. Calling this twice with the same base
+ * (a title before and after an edit, a retry) returns the same name.
+ */
+export declare function testDataName(base: string): string;
 /** The ledger of one test: `.tmp/records/<runId>/<file>.json`. One file per test, so parallel workers never share a file. */
 export declare const ledgerFile: (runId: string, testId: string) => string;
 export declare function writeLedger(file: string, entries: LedgerEntry[]): void;