acstack 0.0.0-stage → 0.47.0

package/skills/record-context/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: record-context
+description: Write durable records when a decision lands – an architecture decision record (ADR), a short file stating one decision and why, if the decision is hard to reverse and surprising and a real trade-off; a glossary entry if a term got settled; both, or neither. Invoke after a map node resolves or after an equivalent decision is settled in conversation. Neither is the common case; silence is a valid outcome.
+---
+
+# Record durable context
+
+A decision just landed. Two independent tests decide what, if anything, it
+leaves behind. Apply both; they share a trigger and nothing else.
+
+## ADR – all three, or no ADR
+
+An ADR is an architecture decision record: a short file that states one
+decision and the reasoning behind it. Write one only when the decision is:
+
+1. **Hard to reverse** – undoing it later means real rework, not an edit.
+2. **Surprising without context** – a competent newcomer would ask "why on
+   earth is it like this?"
+
+3. **A real trade-off** – the decision gives something up. A choice with no
+   losing side needs no record.
+
+Most decisions meet none of these. Do not lower the bar – an ADR that records
+an obvious choice buries the ones that matter.
+
+### Writing one
+
+- Path: `docs/adr/NNNN-slug.md`. The number is the highest existing number plus
+  one, zero-padded to four digits. Create the directory lazily.
+
+    If the file for that number appeared since you scanned (a parallel teammate
+    wrote one), renumber to the new highest plus one. In agent teams, ADR
+    writing is a shared-file concern – route it through the orchestrator or the
+    sequential after-team step, never two teammates at once.
+
+- Body: a `# title` heading, then one to three sentences stating the decision
+  and the why. Optional short `## Considered options` and `## Consequences`
+  sections when they carry weight the summary cannot.
+
+- Tone: per the `writing` skill.
+
+### Example
+
+`docs/adr/0004-invariant-tool-path.md`:
+
+```markdown
+# One invariant path for the command line tool
+
+Every skill calls the command line tool for ACStack as
+`~/.claude/acstack/bin/acstack`. The SessionStart hook repoints that symlink
+at the copy inside the current plugin cache. A version bump moves the target.
+No skill file changes.
+
+## Considered options
+
+A bare `acstack` command reads the user's shell PATH. A subshell, a fresh
+agent context and a continuous integration run each start without that PATH.
+
+## Consequences
+
+A skill that runs before the hook finds no symlink. An absent symlink means
+the hook has not run. The fix is to restart the agent session.
+```
+
+### You generate the index
+
+After writing any ADR, rewrite `docs/adr/index.md` in full, with one line
+per ADR. Sort the lines by number, ascending. Each line takes its number
+and slug from the filename, and its title from the file's first heading:
+
+```markdown
+- [0001](0001-one-node-type.md) – One node type for questions and work
+```
+
+Generated, never hand-edited – a derived view cannot drift from its source.
+If you find hand edits in it, regenerate; the files are the truth.
+
+## Glossary – when a term got settled
+
+If the decision fixed what a word means – picked between competing names,
+sharpened a fuzzy term, coined one – record it:
+
+- **Cross-domain terms** go in `CONTEXT.md` at the repo root.
+- **Domain terms** go in `acstack/specs/<domain>/CONTEXT.md`, beside that
+  domain's `spec.md`. Find the domain in `acstack/domain-map.yaml`.
+
+- Create both files lazily; there is no index file –
+  `domain-map.yaml` already lists every domain.
+
+Format: a `# Glossary` heading, then one `**term** – definition` line per
+term, alphabetical, one or two sentences each. Each definition follows the
+`writing` skill.
+
+Glossary and nothing else – no implementation notes, no specs, no scratch
+content. The moment it accepts anything else it becomes another document
+competing with the living specs.
+
+**The human wins.** A glossary records the vocabulary humans agreed on.
+Nobody rewrites it to match code. If code and glossary disagree, surface the
+disagreement to the user; only a human decision changes the entry.
+
+## Neither
+
+If the decision fails the ADR bar and settled no term, write nothing and
+say nothing. The durable trail for ordinary decisions is the resolved node
+and the living specs.

package/skills/setup/SKILL.md

@@ -0,0 +1,250 @@
+---
+name: setup
+description: Set up ACStack in a project, and change how an already configured project is set up. With no acstack/project.yaml it detects the project type, writes the config, generates the domain map and offers browser verification. With one already there it leads with the health check, then offers to fix each row that failed. Both paths end in the same check, so it is safe to run on the first day and on any day after.
+argument-hint: "[what to set up or change]"
+disable-model-invocation: true
+---
+
+## User input
+
+```text
+$ARGUMENTS
+```
+
+# Setup
+
+One skill, two paths. What the project already has picks the path. Both paths
+join at the health check, so this skill states every fix once.
+
+```mermaid
+flowchart TD
+    HOST["Step 1<br/>declare this machine"] --> FORK{"acstack/project.yaml<br/>is here?"}
+    FORK -- no --> FIRST["Steps 3 to 6<br/>detect, ask, write the config"]
+    FORK -- yes --> CHECK
+    FIRST --> CHECK["Step 7<br/>acstack config check --json"]
+    CHECK --> MENU["Step 8<br/>offer the rows that need a fix"]
+    MENU --> FIX["Step 9<br/>fix one row at a time"]
+    FIX --> BROWSER["Steps 10 and 11<br/>browser mode, Playwriter bridge"]
+    FIX --> OFFERS["Steps 12 and 13<br/>offer the workspace and the design review"]
+    OFFERS --> REPORT["Step 14<br/>report"]
+    BROWSER --> OFFERS
+```
+
+Three terms, before they get used:
+
+- A **health check** is one run of `acstack config check`. It audits the machine
+  and the project. It changes nothing.
+
+- A **row** is one line of that report. It carries an `id`, a `status` and a
+  `message`.
+
+- An **axis** is one setting of the machine, recorded as one `host.*` key in the
+  global config.
+
+The command line tool audits. This skill interviews and writes. Neither one does
+the other's job.
+
+See `docs/adr/0008-cli-audits-skill-interviews.md`.
+
+## Step 1: Declare this machine
+
+The dev setup of the machine is per machine, not per project. It covers which
+orchestrator hosts terminal panes and git worktrees. It also covers which
+browser-verification modes work here.
+
+Those answers live in the global config under the `host.*` keys.
+
+Read what this machine declares:
+
+```bash
+~/.claude/acstack/bin/acstack config get host
+```
+
+On exit 0 the command prints the declared axes, and Step 2 follows. Exit code 2
+means this machine declares nothing yet.
+
+On exit 2, invoke the `host` skill and run its whole interview here. Do not tell
+the user to go and run it later.
+
+Host setup is per machine and safe to re-run, and a half-finished machine leaves
+axes unset. The health check in Step 7 then fails on those axes and blocks
+everything after it.
+
+Do not restate the host skill's questions. It owns them, and it writes its own
+answers. Come back to Step 2 when it finishes.
+
+## Step 2: Choose the path
+
+```bash
+test -f acstack/project.yaml && echo present || echo absent
+```
+
+- **absent** – take the first-run path. Go to Step 3.
+- **present** – take the re-run path. Go straight to Step 7.
+
+## Step 3: Detect the project type and propose defaults
+
+Read [`first-run.md`](first-run.md) on the first-run path, and run Steps 3 to 6 from it.
+
+## Step 4: Ask what to customise
+
+In [`first-run.md`](first-run.md).
+
+## Step 5: Customise the selected sections
+
+In [`first-run.md`](first-run.md).
+
+## Step 6: Write the config
+
+In [`first-run.md`](first-run.md). Then go to Step 7.
+
+## Step 7: Run the health check
+
+Both paths arrive here. Run the check and read its JSON:
+
+```bash
+~/.claude/acstack/bin/acstack config check --json
+```
+
+That path is a symlink into the released plugin cache, so it carries the shipped
+CLI. An agent testing this branch before the release runs
+`node cli/dist/index.js config check --json` from the repo instead.
+
+It prints one object to standard output and nothing else:
+
+```json
+{"checks": [{"id": "domain-map", "status": "pass", "message": "acstack/domain-map.yaml maps 4 domains"}]}
+```
+
+Each `status` is `pass`, `fail` or `info`. The exit codes carry the same news:
+
+| Exit code | What it means |
+| --- | --- |
+| 0 | nothing failed, though rows still report info |
+| 1 | at least one row failed |
+| 2 | a required host axis has no value |
+
+Branch on the `id` of a row. Never branch on its `message`. The identifiers are
+an interface and the messages get reworded.
+
+On exit 2, go back to Step 1 and run the host interview. Nothing else can be
+trusted until every required axis has a value.
+
+Print the failing rows to the user before you ask anything. A project set up
+months ago deserves to hear what fails first.
+
+## Step 8: Offer the rows that need a fix
+
+Build one multi-select question in the question tool (AskUserQuestion with
+`multiSelect: true` on Claude Code). Put one option in it per row you are going
+to offer, and say in each description what the row reported. This is the pre-selection the user sees: only real gaps reach the menu.
+
+Offer a row when any of these holds:
+
+- Its `status` is `fail`.
+- Its `id` is `preferred-browser-mode`, its `status` is `info`, and
+  `acstack/project.yaml` configures a `frontend` block. The project has a
+  frontend and has named no browser mode for it.
+
+- Its `id` is `output-style` and its `status` is `info`. The row passes when the
+  settings files select `acstack:ac-writing-style`, so `info` means they select
+  some other style, or select none.
+
+- Its `id` is `frontend-verification` and its `status` is `info`. The project
+  configures a frontend and `workflow.frontend_verification` is not `true`.
+
+Each of those rules reads the `status` and the `id`. Read neither row's message
+to decide, for the reason Step 7 gives: the message is prose and it gets
+reworded.
+
+Add three options at the end of the list, whatever the check reported:
+
+- **Re-declare this machine** – invoke the `host` skill. It re-asks every axis,
+  required and optional, and starts from the current answers.
+
+    The check reports an `optional-axis:<key>` row as `info`, never as `fail`.
+    So this option is the only way one of them reaches a question.
+
+- **Change one setting** – for a key the check has no opinion about, such as
+  `workflow.tdd.strict`. Point the user at `docs/config-reference.md`, which
+  lists every key, its values and its default. Then write the key:
+
+  ```bash
+  ~/.claude/acstack/bin/acstack config set workflow.tdd.strict false
+  ```
+
+  Do not restate the reference here.
+
+- **Skip** – leave everything as it is.
+
+## Step 9: Fix one row at a time
+
+Each `id` maps to one fix. Work the selected rows in this order:
+
+| Row id | The fix |
+| --- | --- |
+| `no-project` | there is no project here, so go to Step 3 |
+| `required-axis:<key>` | invoke the `host` skill |
+| `orchestrator:<name>` | invoke the `host` skill |
+| `browser-mode:<mode>` | invoke the `host` skill, or the second fix in `row-fixes.md` for the mode that failed |
+| `preferred-browser-mode` | invoke the `host` skill on a `fail`, Step 10 on an `info` |
+| `optional-axis:host.terminal_workspace` | Step 12 |
+| `optional-axis:<key>` | invoke the `host` skill, through the menu option in Step 8 |
+| `domain-map` | Step 9a in `row-fixes.md` |
+| `agent-browser` | Step 9b in `row-fixes.md` |
+| `agent-browser-json` | Step 9c in `row-fixes.md` |
+| `verification-knowledge` | Step 9d in `row-fixes.md` |
+| `frontend-verification` | run `acstack config set workflow.frontend_verification true` |
+| `output-style` | Step 9e in `row-fixes.md` |
+
+Read [`row-fixes.md`](row-fixes.md) when a selected row is `browser-mode:<mode>`, `frontend-verification`, `domain-map`, `agent-browser`, `agent-browser-json`, `verification-knowledge` or `output-style`. It holds the second fixes and Steps 9a to 9e.
+
+## Step 10: Ask the project's browser mode
+
+Read [`browser.md`](browser.md) when a `preferred-browser-mode` row reports `info`.
+
+## Step 11: Connect the Playwriter bridge
+
+Read [`browser.md`](browser.md) when the user picks the remote mode in Step 10, or a `browser-mode:remote` row fails.
+
+## Step 12: Offer the terminal workspace
+
+Read [`terminal-workspace.md`](terminal-workspace.md) on every run, after the rows are fixed.
+
+## Step 13: Offer the design review
+
+Read [`design-review.md`](design-review.md) when Step 7 reported a `frontend-verification` row. With no such row the project has no frontend, so go to Step 14.
+
+## Step 14: Report
+
+Read [`report.md`](report.md) on every run, as the last step.
+
+## What this skill leaves to others
+
+- `acstack config check` owns every audit rule. Do not re-probe the machine with
+  shell commands of your own.
+
+- `acstack config show` owns printing the current setup. It reports the profile,
+  the commands, the directories and what the project says about its browser. This
+  skill never re-prints those itself.
+
+- `docs/config-reference.md` owns the key reference. It lists each key, its
+  values, its default, and what changes when you change it.
+
+- `acstack config set <key> <value>` owns the single-key change, in both files.
+  It reads the key to decide which one.
+
+    A `host.*` key goes to the global config at `~/.config/acstack/config.json`.
+    Every other key it knows goes to `acstack/project.yaml`, and the write keeps
+    the comments and the key order. It refuses a key neither schema knows, so
+    never fall back to editing the file.
+
+- The `host` skill owns the machine interview and every `host.*` question, with
+  one exception. Step 12 of this skill asks `host.terminal_workspace`. The
+  workspace installs binaries, so the offer belongs after the project works.
+
+- The `impeccable` plugin owns its own install and its own `PRODUCT.md`.
+  `/impeccable init` writes that file. Step 13 names the command and copies
+  nothing out of the plugin.
+
+- `docs/dev-setups.md` documents the nine `host.*` axes.

package/skills/setup/browser.md

@@ -0,0 +1,123 @@
+# Setup: browser mode and Playwriter bridge
+
+`SKILL.md` decides when to read this file: Step 9 routes a `preferred-browser-mode` info row to Step 10, or a `browser-mode:remote` failure to Step 11.
+
+## Step 10: Ask the project's browser mode
+
+Both paths reach this step. The first run reaches it because a fresh frontend
+project states no preference. A re-run reaches it because the user picked that
+row from the menu.
+
+The machine says what it can do, in the `host.browser.*` axes. This question asks
+a different thing: which of those modes this project would like to use.
+
+Offer only the modes the machine declares available. When the machine declares
+none, offer all three and run the `host` skill first.
+
+The block below is the full menu, not the question to ask word for word. Drop the
+entry for any mode the machine declares unavailable, then ask the rest.
+
+```json
+{
+  "question": "How will you connect a browser for frontend verification?",
+  "options": [
+    {"label": "Remote browser (Playwriter bridge)", "description": "Best experience – drive Chrome on your desktop/laptop via the Playwriter extension over SSH. Choose this if you develop on a remote VM."},
+    {"label": "Headless (automatic)", "description": "The frontend-verifier launches headless Chromium when needed. No setup required. Choose this for CI or if you don't need to see the browser."},
+    {"label": "Local with display", "description": "Launch a visible browser on this machine. Choose this for desktop Linux, macOS, or WSL with display access."},
+    {"label": "Skip for now", "description": "I'll set this up later – /acstack:host to declare what this machine can do, /acstack:setup for the project's preference"}
+  ]
+}
+```
+
+Write the answer as `remote`, `headless` or `local`. Write the port beside it:
+`19988` for `remote`, and `9555` for the other two.
+
+```bash
+~/.claude/acstack/bin/acstack config set frontend.browser.mode remote
+~/.claude/acstack/bin/acstack config set frontend.browser.cdp_port 19988
+```
+
+Then write `agent-browser.json` with the same port, the way Step 9c in `row-fixes.md` does.
+
+On **Skip for now**, leave `frontend.browser` unset and write no
+`agent-browser.json`. Say that `docs/config-reference.md` documents the three
+keys for later.
+
+On **Headless**, no setup follows. Tell the user the frontend verifier launches
+headless Chromium when it needs one.
+
+On **Local with display**, look for a Chromium binary. Tell the user the frontend
+verifier launches it when it needs one.
+
+On **Remote browser**, ask what the verifier does when the browser answers nothing:
+
+```json
+{
+  "question": "When the remote browser isn't connected, what should the frontend-verifier do?",
+  "options": [
+    {"label": "Fall back to headless", "description": "Launch headless Chromium automatically. Verification still runs, just without your real browser."},
+    {"label": "Fail", "description": "Report FAIL so you know the bridge is down. Choose this if headless results aren't useful for your app."}
+  ]
+}
+```
+
+Write `frontend.browser.fallback` as `headless` for the first answer, and as
+`none` for the second. Only `none` acts. It forbids another mode from standing
+in.
+
+Then go to Step 11.
+
+## Step 11: Connect the Playwriter bridge
+
+This step is the one copy of the bridge setup. Step 10 reaches it on a `remote`
+answer. Step 9 reaches it on a `browser-mode:remote` failure.
+
+Remote mode drives Chrome through the Playwriter extension, which uses the
+`chrome.debugger` API. Chrome itself opens no CDP listener. Show these steps:
+
+```
+To connect your browser via the Playwriter bridge:
+
+1. On the browser machine, install Node 18+ and Playwriter:
+
+   npm install -g playwriter
+
+2. In Chrome on the browser machine (preferably a dedicated profile), install the Playwriter extension and pin it:
+
+   https://chromewebstore.google.com/detail/playwriter-mcp/jfeammnjpkecdekppnclgkkffahnhfhe
+
+3. Run two long-running processes on the browser machine:
+
+   Relay:         playwriter serve --host 127.0.0.1
+   Reverse tunnel: ssh -N -R 19988:127.0.0.1:19988 <user>@<dev-machine>
+
+4. In Chrome, click the Playwriter toolbar icon on each tab you want automated.
+
+5. Verify from this (dev) machine:
+
+   curl -s http://localhost:19988/json/version
+```
+
+Show these gotchas after the steps:
+
+- Playwriter hardcodes port `19988`. Nobody can change it.
+- The relay runs on the same host as Chrome. The extension rejects any
+  `/extension` client that is not `127.0.0.1`.
+
+- Each tab needs the extension icon clicked once. Playwriter cannot attach to a
+  `chrome://` or `about:` page.
+
+- A stale relay holds port 19988 on the browser machine. Run
+  `playwriter serve --host 127.0.0.1 --replace` to kick the previous one.
+
+For a Windows laptop setup that opens no window, see
+`plugins/acstack/docs/playwriter-bridge-windows.md`. It covers auto-reconnecting
+scheduled tasks, ssh-agent key persistence and one-time admin registration. It
+ships `relay.ps1`, `tunnel.ps1` and `register-tasks.ps1` under
+`plugins/acstack/assets/playwriter-bridge/`.
+
+Then re-run the health check from Step 7 and read the `browser-mode:remote` row.
+It passes once something answers on the port.
+
+Do not curl the port yourself. The check is the one place that probes the
+machine.

package/skills/setup/design-review.md

@@ -0,0 +1,97 @@
+# Setup: design review
+
+`SKILL.md` decides when to read this file: Step 7 reported a `frontend-verification` row, so the project has a frontend and Step 13 runs from here.
+
+## Step 13: Offer the design review
+
+The design review is two plugins working on the frontend:
+
+- **open-designer** writes a design you can look at before anyone builds it
+- **impeccable** reviews a UI change against the product's own design rules
+
+ACStack needs neither, so this step offers and never assumes.
+
+Ask it only of a project with a frontend. The health check in Step 7 reports a
+`frontend-verification` row for those projects and for no others, so no such row
+means no frontend. Go to Step 14.
+
+Read what this project already decided:
+
+```bash
+~/.claude/acstack/bin/acstack config get workflow.design_review
+```
+
+On exit 0 the user has already answered, either way. Say nothing and go to
+Step 14.
+
+On any exit other than 0 or 2 the CLI is older than this skill and does not know
+the key. Do not ask, and do not try to write the key. Say this instead, then go
+to Step 14:
+
+```
+The acstack CLI on this machine predates workflow.design_review, so I cannot
+record an answer. Restart your agent session to relink the CLI, then run
+/acstack:setup again.
+```
+
+The SessionStart hook repoints `~/.claude/acstack/bin/acstack` at every start,
+so a restart is the whole fix.
+
+On exit 2 nobody has answered yet. Ask once:
+
+```json
+{
+  "question": "Turn on design review for this project's frontend?",
+  "header": "Design",
+  "options": [
+    {"label": "Yes", "description": "You then install two plugins: open-designer, which writes a design you can look at before anyone builds it, and impeccable, which reviews a UI change against the product's design rules. Both are reversible."},
+    {"label": "No", "description": "Leave this project as it is. Nothing in ACStack needs either plugin, and setup never asks again."}
+  ]
+}
+```
+
+Write the answer, whichever way it went:
+
+```bash
+~/.claude/acstack/bin/acstack config set workflow.design_review true   # or false
+```
+
+Write it before doing anything else. The answer is the user's, and two plugins
+they never get round to installing must not bring the question back on the next
+run.
+
+On **Yes**, hand the install to the user. Print these lines, then go to Step 14:
+
+```
+Recorded. Install the two plugins yourself – the installer is reserved for you
+to start:
+
+  /plugin marketplace add ac8318740/ac-agentic-coding
+  /plugin install open-designer@ac-agentic-coding
+
+  /plugin marketplace add pbakaus/impeccable
+  /plugin install impeccable@impeccable
+
+Then run /impeccable init once. It writes PRODUCT.md, the file the design
+review reads.
+```
+
+Three things this step never does:
+
+- It never runs an install. Both plugins change what Claude Code loads, so the
+  user starts them.
+
+- It never writes `PRODUCT.md`. `/impeccable init` owns that file, and a second
+  writer collides with it.
+
+- It never copies a file out of impeccable. Setup names the plugin and stops
+  there.
+
+`acstack config check` grows an `impeccable` row once the user installs the
+plugin, so a later `/acstack:setup` run confirms the install landed.
+
+On **No**, go straight to Step 14. Name neither plugin again, and do not ask
+again.
+
+The key records the answer, never the install. Setup writes it before the user
+installs anything, so `true` never claims either plugin is here.

package/skills/setup/first-run.md

@@ -0,0 +1,114 @@
+# Setup: first run
+
+`SKILL.md` decides when to read this file: Step 2 found no `acstack/project.yaml`, so the first-run path runs Steps 3 to 6 from here.
+
+The file keeps its schema on both paths, so nothing migrates. `docs/config-reference.md`
+lists every key it can hold.
+
+## Step 3: Detect the project type and propose defaults
+
+Scan the project root for `pyproject.toml`, `package.json`, `go.mod` and
+`Cargo.toml`. If the root gives nothing away, infer the type from `$ARGUMENTS`.
+Read the matching profile from the plugin's `profiles/` directory.
+
+Show a summary:
+
+```
+Profile:      [detected]
+Directories:  src/, tests/
+Commands:     [from profile]
+Frontend:     [if applicable]
+Workflow:     strict TDD, strict orchestrator, spec sync on, grilling via question tool
+```
+
+## Step 4: Ask what to customise
+
+Ask through the question tool (AskUserQuestion on Claude Code) with EXACTLY this
+JSON. On a host without one, print the same questions and options as a
+numbered list. It holds two questions in one call:
+
+```json
+{
+  "questions": [
+    {
+      "question": "Customize project setup? Select items to change, or skip to keep defaults.",
+      "header": "Setup",
+      "multiSelect": true,
+      "options": [
+        {"label": "Profile & paths", "description": "Change language/framework, source dir, test dir"},
+        {"label": "Commands", "description": "Adjust test, build, lint, typecheck, format commands"},
+        {"label": "Frontend", "description": "Change directory, dev server, commands"}
+      ]
+    },
+    {
+      "question": "Customize workflow? Select items to change, or skip to keep defaults.",
+      "header": "Workflow",
+      "multiSelect": true,
+      "options": [
+        {"label": "Grilling", "description": "How grilling asks its questions – a question tool (default) or plain prose"},
+        {"label": "TDD strictness", "description": "Relaxed writes the tests after the code; all three phases still run"},
+        {"label": "Orchestrator", "description": "Allow direct code work instead of subagent delegation"},
+        {"label": "Spec sync", "description": "Disable automatic spec sync on commit"}
+      ]
+    }
+  ]
+}
+```
+
+Read `answers["0"]` as the setup selections and `answers["1"]` as the workflow
+selections. An empty selection means the defaults stand.
+
+## Step 5: Customise the selected sections
+
+Ask one follow-up question at a time through the question tool. Skip every item the
+user did not select.
+
+- **Profile & paths** – ask the language or framework, then the source and test
+  directories.
+
+- **Commands** – show the proposed commands and ask what to adjust.
+- **Frontend** – show the proposed frontend settings and ask what to adjust.
+- **Grilling** – ask `tool`, the host's question tool, against `inline` prose.
+  Recommend `tool`. It writes `workflow.grilling.questions`.
+
+- **TDD strictness** – ask strict against relaxed, and write
+  `workflow.tdd.strict`.
+
+    Strict runs the test-writer first, so the tests exist before the code.
+    Relaxed runs the task-executor first and the test-writer after it. Relaxed
+    drops no phase, and all three agents run under both.
+
+    Recommend strict, because the relaxed test-writer works beside an
+    implementation it must not read.
+
+- **Orchestrator** – ask strict against relaxed.
+- **Spec sync** – ask enabled against disabled.
+- **Python venv** – ask the activation command. Ask it only for a Python profile.
+
+Leave the whole `frontend.browser` block out here. Step 10 owns it, and both
+paths reach Step 10 through the health check.
+
+## Step 6: Write the config
+
+1. Create the `acstack/` directory.
+2. Write `acstack/project.yaml` from the profile and the answers.
+3. Leave the project CLAUDE.md alone. The SessionStart hook loads the
+   orchestrator instructions.
+
+4. Remove a legacy `@import` line from the project CLAUDE.md, if one is there.
+   It points at `.../plugins/cache/ac8318740-plugins/acstack/<version>/CLAUDE.md`.
+
+Then go to Step 7. Everything a fresh project still lacks shows up there as a
+failing row.
+
+## What Steps 7 and 8 show after a first run
+
+A `no-project` row means Step 6 wrote no config. Go back to Step 3 and write it.
+
+On a first run the menu carries several rows, and only one of them failed. A
+fresh project has no domain map, so `domain-map` fails. It selects no output
+style, so `output-style` reports `info`.
+
+A fresh project that configures a frontend adds `preferred-browser-mode` and
+`frontend-verification`, both `info` as well, because it has named no browser
+mode and turned no verification on.