@haus-tech/haus-workflow 5.4.0 → 5.6.0

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # Changelog
 
+## [5.6.0](https://github.com/WeAreHausTech/haus-workflow/compare/v5.5.0...v5.6.0) (2026-09-13)
+
+### Bug Fixes
+
+- **poc:** what the second PoC run rubbed against ([#557](https://github.com/WeAreHausTech/haus-workflow/issues/557)) ([8b37668](https://github.com/WeAreHausTech/haus-workflow/commit/8b37668bfd0a9a99f7be32cd4863ead8bcf96b27))
+
+## [5.5.0](https://github.com/WeAreHausTech/haus-workflow/compare/v5.4.0...v5.5.0) (2026-09-12)
+
+### Features
+
+- **haus-workflow:** PoC mode in project:new ([#555](https://github.com/WeAreHausTech/haus-workflow/issues/555)) ([ffd2bfa](https://github.com/WeAreHausTech/haus-workflow/commit/ffd2bfa7e34bd66f679d23df3e54868b7536d291))
+
+### Bug Fixes
+
+- **poc:** two gaps the acceptance run found ([#556](https://github.com/WeAreHausTech/haus-workflow/issues/556)) ([728fe3b](https://github.com/WeAreHausTech/haus-workflow/commit/728fe3bc88fe31f1e6189c62108c89fbbe5d86d3))
+
 ## [5.4.0](https://github.com/WeAreHausTech/haus-workflow/compare/v5.3.0...v5.4.0) (2026-09-12)
 
 ### Features

package/dist/cli.js

@@ -2942,6 +2942,7 @@ var PROFILES = {
     workflowTemplateRel: WORKFLOW_TEMPLATE_REL,
     writesCiGate: true,
     writesDecisionsSeed: true,
+    runsDocsPass: true,
     droppedHookCommands: [],
     workflowConfig: "standard"
   },
@@ -2950,6 +2951,7 @@ var PROFILES = {
     workflowTemplateRel: "templates/agentic-workflow-poc.md",
     writesCiGate: false,
     writesDecisionsSeed: false,
+    runsDocsPass: false,
     droppedHookCommands: ["haus decisions guard --from-hook", "haus decisions suggest --from-hook"],
     workflowConfig: "poc"
   }
@@ -7695,9 +7697,9 @@ async function readScannedMarkdown(root) {
 }
 
 // src/decisions/doctor.ts
-init_fs();
 import path40 from "node:path";
 import fs38 from "fs-extra";
+init_fs();
 
 // src/decisions/check.ts
 init_fs();
@@ -8165,19 +8167,21 @@ async function listDecisionNumbers(decisionsDir) {
 }
 
 // src/decisions/doctor.ts
-async function auditDecisionsLayout(root) {
+async function auditDecisionsLayout(root, profile) {
   const findings = [];
   const primary = path40.join(root, DECISIONS_TRIGGERS.decisionsDir);
   const legacy = path40.join(root, DECISIONS_TRIGGERS.legacyDecisionsDir ?? "docs/adr");
   const hasPrimary = await fs38.pathExists(primary);
   const hasLegacy = await fs38.pathExists(legacy);
   if (!hasPrimary && hasLegacy) {
-    findings.push({
-      level: "advisory",
-      line: `- DECISIONS: legacy ${DECISIONS_TRIGGERS.legacyDecisionsDir}/ present \u2014 migrate to docs/decisions/`,
-      sentence: "Decision records still live under the legacy docs/adr/ path",
-      fix: `git mv ${DECISIONS_TRIGGERS.legacyDecisionsDir} ${DECISIONS_TRIGGERS.decisionsDir}`
-    });
+    if (PROFILES[profile].writesDecisionsSeed) {
+      findings.push({
+        level: "advisory",
+        line: `- DECISIONS: legacy ${DECISIONS_TRIGGERS.legacyDecisionsDir}/ present \u2014 migrate to docs/decisions/`,
+        sentence: "Decision records still live under the legacy docs/adr/ path",
+        fix: `git mv ${DECISIONS_TRIGGERS.legacyDecisionsDir} ${DECISIONS_TRIGGERS.decisionsDir}`
+      });
+    }
     return findings;
   }
   if (!hasPrimary) return findings;
@@ -9535,7 +9539,7 @@ async function runDoctor(options) {
   if (docsSkillInstalled) {
     if (await fs41.pathExists(path49.join(root, "docs", "SUMMARY.md"))) {
       ok("- PROJECT DOCS: OK (docs/SUMMARY.md present)");
-    } else {
+    } else if (PROFILES[profile].runsDocsPass) {
       suggest(
         "- PROJECT DOCS: docs/SUMMARY.md missing \u2014 run the writing-documentation skill (`/docs` in Claude Code) to generate the project docs",
         "The project docs index (docs/SUMMARY.md) has not been generated yet",
@@ -9557,14 +9561,14 @@ async function runDoctor(options) {
       ok(`- .prettierignore: protects ${IGNORED_PATHS.join(" and ")}`);
     }
   }
-  if (!await projectRunsCiGate(root)) {
+  if (await projectRunsCiGate(root)) {
+    ok("- CI GATE: OK (a workflow runs `haus ci-gate`)");
+  } else if (PROFILES[profile].writesCiGate) {
     suggest(
       `- CI GATE: missing \u2014 no workflow runs \`haus ci-gate\` (${CI_GATE_WORKFLOW_REL})`,
       "Nothing checks this project on a pull request: setup drift, a missing ADR, or a stale catalog would all land unnoticed",
       "haus apply --write (writes .github/workflows/haus-gate.yml; never overwrites an existing one)"
     );
-  } else {
-    ok("- CI GATE: OK (a workflow runs `haus ci-gate`)");
   }
   if (!PROFILES[profile].writesCiGate) {
     const ciGateContent = await readText(path49.join(root, CI_GATE_WORKFLOW_REL));
@@ -9599,7 +9603,7 @@ async function runDoctor(options) {
   } else {
     ok("- GITIGNORE (haus content): OK (.claude/ and .haus-workflow/ are tracked)");
   }
-  for (const finding of await auditDecisionsLayout(root)) {
+  for (const finding of await auditDecisionsLayout(root, profile)) {
     if (finding.level === "ok") ok(finding.line);
     else suggest(finding.line, finding.sentence, finding.fix);
   }

package/library/catalog/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "6.5.0",
+  "version": "6.5.1",
   "manifestFormat": 2,
   "globalPlugins": [
     {
@@ -56,7 +56,7 @@
     },
     {
       "id": "haus.agentic-workflow-poc",
-      "version": "1.0.0",
+      "version": "1.0.1",
       "source": "haus",
       "type": "template",
       "path": "templates/agentic-workflow-poc.md",
@@ -68,8 +68,8 @@
       "repoRoles": [],
       "ecosystem": "general",
       "installMode": "copy-selected",
-      "tokenEstimate": 2094,
-      "tokenBudget": 2723,
+      "tokenEstimate": 2187,
+      "tokenBudget": 2844,
       "default": false,
       "reviewStatus": "approved",
       "riskLevel": "low"

package/library/global/skills/haus-workflow/SKILL.md

@@ -29,7 +29,7 @@ that branch of the merged task.
 | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `init` (`setup`, `project:init`, `reinit`, `re-init`, `project:reinit`)                                                                                   | _Init procedure below_        | State-aware setup. Not set up → first-time init (skills, commands, workflow + project docs). Already set up → asks: non-destructive refresh, or clean slate (confirmed wipe via `haus undo --yes` / `haus workspace undo`, then re-init). `reinit` aliases jump straight to the clean-slate branch (still confirmed).                                                                                |
 | `clone [name]` (`project:clone`, `cloneandsetup`, `project:cloneandsetup`)                                                                                | _Clone procedure below_       | Clone one repo by name, or a whole workspace from `repos.manifest.json`. Afterwards asks "set up for local dev too?" (deps, databases, links, env via `localdev.yml`). `cloneandsetup` aliases pre-answer that question with yes.                                                                                                                                                                    |
-| `new [description]` (`create`, `project:new`)                                                                                                             | _New-project procedure below_ | Create a brand-new project from a plain-language request — unchanged seven-phase flow.                                                                                                                                                                                                                                                                                                               |
+| `new [description]` (`create`, `project:new`, `poc`, `kunddemo`)                                                                                          | _New-project procedure below_ | Create a brand-new project from a plain-language request, unchanged seven-phase flow. The `poc`/`kunddemo` aliases (and phrases like "ny poc", "customer demo") run the same flow in PoC mode: a throwaway demo repo under the `poc` profile (`--profile poc`), see `references/new.md` → PoC mode.                                                                                                  |
 | `doctor` (`check`, `fix`, `project:doctor`, `project:fix`)                                                                                                | _Doctor procedure below_      | Health check for the detected scope; relays the verdict, then offers to apply the doctor's own suggested fixes and re-checks until green. `fix` aliases pre-answer "fix now?" with yes.                                                                                                                                                                                                              |
 | `refresh` (`update`, `upgrade`, `apply`, `regenerate`, `claude-md`, `project:refresh`, `add-skills`, `opt-in`, `project:add-skills`, `install`, `global`) | _Refresh procedure below_     | Bring haus current. Always: update npm package + catalog + `~/.claude` (seeding it first if never installed). Inside a set-up project/workspace, asks: **Full sync** (re-run the whole setup pipeline in place) or **Just add helpers** (offer opt-in skills/agents + configs only). `add-skills`/`opt-in` aliases jump to the helpers branch; outside any project it stops after the global update. |
 | `uninstall`                                                                                                                                               | `haus uninstall`              | Remove all haus global files from `~/.claude/`. Machine scope only — confirm gate states this does NOT touch the current project (that's `init` → clean slate).                                                                                                                                                                                                                                      |
@@ -52,7 +52,7 @@ into a single `AskUserQuestion` call:
 Question 1: "What would you like to do?"
 Options:
   1. init — set up this project (or workspace) with haus; offers refresh/clean-slate when already set up
-  2. new [description] — create a brand-new project from a plain-language request
+  2. new [description] — create a brand-new project, or a throwaway PoC, from a plain-language request
   3. refresh — update haus itself, then fully sync this project (or just add optional helpers)
   4. More options — see: clone, doctor, uninstall, help
 
@@ -211,7 +211,7 @@ Bring haus current. Global half always runs; the project half depends on scope.
    it must ask the workspace-membership question there before eliciting anything
    else. Otherwise (Project or Not-set-up scope) open it knowing that question is
    skipped.
-2. Open and follow `references/new.md` in this skill's directory. It is a seven-phase AI-driven flow: elicit the request and propose features, gate on user intent, scaffold (registry stacks via `haus new --json --yes` with a `--dry-run` preview; any other stack via a user-confirmed official scaffolder plus manual rails), install context via `haus init`, seed `docs/SPEC.md` + `docs/plans/walking-skeleton.md`, build the walking skeleton with one subagent per feature (against a structure recorded in `docs/DESIGN.md`), verify (build + lint + tests + smoke boot), then write the project docs by following `references/init.md` from step 3 (deep read, `CLAUDE.md` body + `docs/`, recommend re-check, opt-ins). Repos are only ever created private. Failure `detail` is relayed verbatim and nothing is ever auto-deleted. Never run bare interactive `haus new`.
+2. Open and follow `references/new.md` in this skill's directory. It is a seven-phase AI-driven flow: elicit the request and propose features, gate on user intent, scaffold (registry stacks via `haus new --json --yes` with a `--dry-run` preview; any other stack via a user-confirmed official scaffolder plus manual rails), install context via `haus init`, seed `docs/SPEC.md` + `docs/plans/walking-skeleton.md`, build the walking skeleton with one subagent per feature (against a structure recorded in `docs/DESIGN.md`), verify (build + lint + tests + smoke boot), then write the project docs by following `references/init.md` from step 3 (deep read, `CLAUDE.md` body + `docs/`, recommend re-check, opt-ins). Repos are only ever created private. Failure `detail` is relayed verbatim and nothing is ever auto-deleted. Never run bare interactive `haus new`. The same reference carries a **PoC mode** (entered by the `poc`/`kunddemo` aliases, or by the "Production project or throwaway PoC?" question when no phrase was given): the repo gets the `poc` profile before the first design question (`haus new --profile poc` on the fast path; a hand-written `haus.config.json` plus `haus init --json --dry-run --profile poc` and `haus apply --write` on the manual path), the first brainstorm writes `docs/MANUS.md` instead of `docs/SPEC.md`, the only check is the Playwright manus, and Phase 6 skips the docs pass.
 
 ### After `haus uninstall`
 

package/library/global/skills/haus-workflow/references/new.md

@@ -8,6 +8,43 @@ session, from request to running app.
 NEVER run bare `haus new` without flags — its interactive prompts don't work through
 the agent; collect answers with AskUserQuestion and pass everything as flags.
 
+## PoC mode
+
+The same seven phases, for a throwaway proof of concept or customer demo (haus-workflow
+ADR-0125, catalog ADR-0066). Enter it when the request says `new poc`, `poc`, `ny poc`,
+`kunddemo`, `customer demo` or `throwaway demo`. With no such phrase, ask via
+`AskUserQuestion` before Phase 0 runs its own checks: "Production project or throwaway PoC?"
+The answer decides the mode for the rest of the flow, so by the time Phase 0 starts,
+the mode is always known, either from the trigger phrase or from this question.
+Production mode is everything below without the **PoC:** paragraphs.
+
+What PoC mode changes, in one place:
+
+- The project gets the `poc` profile (`--profile poc`) BEFORE the first design
+  question. The profile writes the PoC standard as `.haus-workflow/WORKFLOW.md`, keeps
+  testing/review/security content out, writes no CI gate. Once it is in place, every
+  rule the rest of this flow needs is already loaded.
+- No feature elicitation. The first superpowers brainstorming round IS the design; its
+  output is `docs/MANUS.md` (the demo script), not `docs/SPEC.md`. No `docs/DESIGN.md`,
+  no walking-skeleton plan, no docs pass.
+- The only executable check is `demo/manus.spec.ts`, one Playwright test per manus
+  point. No unit tests, no TDD, no code review. `.haus-workflow/WORKFLOW.md` in the new
+  repo says the same and is authoritative from Phase 5 on.
+- The repo is always private and is archived after the demo. The demo date is written
+  into `docs/MANUS.md` (`Demo: YYYY-MM-DD`); "where are we" reports days left.
+
+Two ways into the repo, decided in Phase 0 by what the cwd is:
+
+- **The cwd is the project** (an empty directory, or a git repo): the manual rails
+  below scaffold into `.`; a repo with a remote is used as is, a repo without one is
+  pushed to a new private GitHub repo after asking where, or kept local only if that is
+  the answer.
+- **The cwd is a parent folder** (anything else): the registry fast path
+  `haus new <stack> <name> --json --yes --profile poc [--dir <path>] [--org <org>]
+[--no-github]` creates `<cwd>/<name>` (or `<path>/<name>` when `--dir` is given, e.g.
+  the workspace root from Phase 0), local only when that is the Phase 1 answer; the
+  handoff tells the user to open that directory as a new Claude Code project.
+
 ## Phase 0 — Entry
 
 **Scope check first.** If `SKILL.md`'s Step 1.5 found the cwd is **Workspace** scope (or
@@ -30,6 +67,16 @@ A description argument ("a frontend app for shopping") goes straight to Phase 1.
 No-argument invocation: ask "What do you want to build?" as free text. Do not present
 a stack menu.
 
+**PoC:** upgrading the haus package rewrites this very file, so if the CLI gets upgraded
+mid-flow, re-read `references/new.md` from disk before continuing rather than carrying on
+from what is already in context. The mode itself is already settled by now, either the
+trigger phrase in the request or the question asked in `## PoC mode` above, so decide the
+way in next: `git rev-parse --is-inside-work-tree` and `ls -A`: an empty directory or a
+git repo means the cwd IS the project (manual rails in Phase 3); anything else means the
+cwd is a parent folder (fast path). A git repo with a remote (`git remote -v`) keeps it;
+one without gets a new private repo in Phase 3, unless local-only is chosen in Phase 1.
+The workspace question above applies unchanged.
+
 ## Phase 1 — Elicit (at most 5 AskUserQuestion rounds)
 
 Ask about dimensions, never from a domain template:
@@ -48,6 +95,19 @@ Ask about dimensions, never from a domain template:
      mis-click in a menu. A public repo is a deliberate manual act outside this flow
      (the CLI flag exists for that; this skill never uses it).
 
+**PoC:** at most 3 rounds, and none of them about features (that is the brainstorm's job
+in Phase 5):
+
+1. What is shown, to whom, and when is the meeting. The date becomes `Demo: YYYY-MM-DD`
+   in `docs/MANUS.md`.
+2. Where the code lives, plus the project name (lowercase letters, digits, `. _ -`),
+   only when a repo must be created: a private repo in the org (default: WeAreHausTech),
+   a private repo on personal GitHub (omit `--org`), or local only, no GitHub repo
+   (`--no-github`). NEVER offer or pass `--public`.
+3. A stack hint, only if the user has one. Otherwise pick the stack yourself from the
+   one-line description (a Vendure storefront demo is `next` or `react-router`); a wrong
+   pick is cheap in a throwaway repo.
+
 Pick the stack yourself from the answers. Confirm the stack with the user only on
 genuine ambiguity (e.g. web vs native unclear).
 
@@ -59,6 +119,11 @@ committed to `main` in the new repo and pushed to the remote if one is created.
 ONE explicit user OK before anything touches disk — this one approval covers those
 actions.
 
+**PoC:** one screen: project name, org, personal, or local only, stack and why, and the
+sentence "PoC profile, private repo if one is created, thrown away after the demo on
+<date>". Say that commits go to `main` until the first green manus exists. One OK covers
+Phases 3 and 4.
+
 ## Phase 3 — Scaffold
 
 Check the registry first: `haus new --list --json`.
@@ -86,6 +151,36 @@ Check the registry first: `haus new --list --json`.
 3. Manual rails: `git init` (if the scaffolder didn't), `git branch -M main`, initial
    commit; then `gh repo create` (confirm first) unless the user declined a repo.
 
+**PoC:** two ways in, decided already in Phase 0 by what the cwd was. Before either
+path's own first commit below, check whatever commit hook a scaffold's files already
+ship (husky, commitlint, lefthook): reading its message-format rules now means finding
+out what it wants before the first commit, not after it rejects one.
+
+- **cwd is the project:** the registry is not used, because `haus new` creates
+  `<parent>/<name>` and refuses an existing directory. Run the official scaffolder into
+  `.` (show the exact command, the user confirms; e.g. `npx create-next-app@16 . --yes
+--typescript --app`), then `git init` (if needed), `git branch -M main`, initial
+  commit. Then, unless a remote exists or local-only was chosen in Phase 1: `gh repo
+create <org>/<name> --private --source . --push` (confirm first; omit `<org>/` for
+  personal GitHub). Local-only stops here: no `gh repo create`, no push, ever.
+- **cwd is a parent folder:** the fast path with the profile: preview with
+  `haus new <stack> <name> --json --yes --dry-run --profile poc [--dir <path>] [--org
+<org>] [--no-github]`, then run it without `--dry-run`, then `cd <name>`. Pass
+  `--no-github` when local-only was chosen in Phase 1; `haus new` then never runs `gh
+repo create`. Carry `--dir` through from Phase 0 for a workspace member; without it a
+  PoC still lands in the cwd, exactly like production. The chained init records the
+  profile and writes the PoC standard; nothing more to do for the profile in Phase 4.
+
+Whichever way in, the profile governs what haus installs and nothing else: a vendor
+starter's own ceremony arrives untouched and no profile can subtract it. Right after the
+first commit, list what came with the scaffold, naming at least its `test` script and
+test directories, any `playwright.config.ts`, commit hooks (husky, commitlint, lefthook),
+CI workflows, and a decisions or `docs/adr/` folder; tell the user in one line what
+stays. Nothing gets deleted: removing files a vendor starter shipped is a surprise in
+someone else's repo, not this flow's call to make. What stays is inert, not authority:
+never run or extend a starter's test suite, and never read its presence as permission to
+add tests.
+
 ## Phase 4 — Context install
 
 Everything from here on runs inside the new project directory — `cd` into it first and
@@ -111,6 +206,71 @@ stay there.
   `docs/plans/walking-skeleton.md` (one task per selected feature with acceptance
   criteria and a verify command).
 
+**PoC:** the profile must be on disk before the preview, because a PoC repo refuses
+`haus init` without `--profile poc`, and a preview never persists the profile
+(ADR-0125). Manual path, in this order:
+
+1. Write `.haus-workflow/haus.config.json` with exactly `{ "profile": "poc" }` (create the
+   directory).
+2. Read: `haus init --json --dry-run --profile poc`; on the zero-signal refusal, confirm
+   and re-run with `--force` as above.
+3. Add a `"manus"` key to package.json scripts now, before the write step, even as a
+   placeholder (`"manus": "playwright test"`). `haus apply --write` derives the PoC's
+   only gate command in `.haus-workflow/workflow-config.md` from whether that key
+   exists, not from its final body, and with no key at all it falls back to a Playwright
+   invocation that resolves against whatever default config the scaffold shipped and
+   finds no tests at all. The skeleton below fills in the real body once the runner
+   config is decided; what matters here is that the key exists first.
+4. Write: `haus apply --write`. It reads the profile: `.haus-workflow/WORKFLOW.md` now
+   starts with `# PoC Workflow Standard`, and there is no `.github/workflows/haus-gate.yml`.
+
+Fast path: the chained init already ran `haus apply --write` inside Phase 3, before this
+phase's `"manus"` script exists, so `.haus-workflow/workflow-config.md`'s "Run the manus"
+line was derived from the fallback command. That file is project-owned and never
+rewritten after its first write, exactly as its own header says, so adding the script
+afterward will not fix it. Once the skeleton below has added the `manus` script and
+decided the runner config, open `.haus-workflow/workflow-config.md` yourself and correct
+that one line to `yarn run manus` / `npm run manus` / `pnpm run manus` (the project's
+package manager) either way, whether the script ended up `"playwright test"` or
+`"playwright test -c playwright.manus.config.ts"`: the line only needs to delegate to
+the script, which already points at the right config. Also check that
+`.haus-workflow/haus.config.json` says `"profile": "poc"`.
+
+Then the demo skeleton, instead of SPEC.md and the walking-skeleton plan:
+
+- `yarn add -D @playwright/test` (or the project's package manager), then
+  `npx playwright install chromium` (a download: ask first).
+- The runner config. If the repo has no `playwright.config.ts`, write one with a
+  `webServer` that starts the dev server and takes its port from `PORT` (default 3000),
+  `testDir: 'demo'`, `reporter: 'line'`, `use.baseURL` from the same port. If the
+  scaffold already shipped a `playwright.config.ts`, which a vendor starter usually has
+  and points at its own e2e suite, leave that file alone and write
+  `playwright.manus.config.ts` beside it with the same contents instead: two configs is
+  the correct outcome, the starter's suite tests the starter and the manus tests the
+  demo. Either way, the config's own `webServer` owns the dev server: never start the
+  dev server yourself in the background and then run the manus against it, or every
+  round starts by hunting the process holding the port.
+- `demo/manus.spec.ts` with the header comment `// The manus. One test per point in
+docs/MANUS.md, same titles, same order. test.fixme() for points decided but not built.`
+  and no tests yet.
+- The `"manus"` script: on the manual path fill in the key added in step 3, and on the fast
+  path add it here. Either way its body is `"playwright test"` when the repo had no
+  config of its own, or `"playwright test -c playwright.manus.config.ts"` when the
+  starter's config forced the second file.
+- `docs/MANUS.md`:
+
+  ```markdown
+  # Manus
+
+  Demo: <date from Phase 1>
+
+  ## Parked
+  ```
+
+  The numbered points are written by the brainstorm in Phase 5, never here.
+
+Commit the skeleton on `main` (`chore(poc): demo skeleton`).
+
 ## Phase 5 — Build the walking skeleton
 
 1. Install dependencies. On the fast path the JSON's `installHint` is written for the
@@ -140,6 +300,29 @@ stay there.
    rule: it applies only to a freshly created single-author repo during this initial
    walking-skeleton build; standard branch rules apply afterwards.
 
+**PoC:** now, with the PoC standard loaded, invoke superpowers:brainstorming. A new
+project is architectural, so it ends in a written design: tell the skill the spec
+location is `docs/MANUS.md` (numbered points in show order, each with what the customer
+sees and what proves it; keep the `Demo:` header).
+
+Before the plan, probe. For every drafted point, run the smallest real query that
+produces that point's proof against the system the demo will use: one GraphQL query, one
+API call, one page load. Do it before any code is written, not when the feature is half
+built. A point whose proof the system cannot produce today goes straight to Parked in
+`docs/MANUS.md` with the one sentence that says what is missing, and the user hears it
+before the plan exists. If the probe kills the system chosen in Phase 1, stop and ask:
+the manus is the scope ceiling, and what it runs against is part of the manus. Do not
+commit a backend URL or token until the probe has confirmed the system can produce the
+points that depend on it.
+
+Then superpowers:writing-plans into
+`docs/plans/round-1.md`, one task per manus point with "the manus point is green" as its
+verification. Build: `demo/manus.spec.ts` gets one `test()` per point as it is built and
+`test.fixme()` for the rest; independent points may go to one subagent each in its own
+worktree once a first green manus exists on `main`; before that, everything lands on
+`main`. No `docs/DESIGN.md`, no TDD, no reviewer dispatch: the standard in the repo says
+why.
+
 ## Phase 6 — Verify + hand off
 
 1. Gate: build passes, lint passes, tests green, dev server boots (smoke check),
@@ -159,6 +342,30 @@ stay there.
    the suggested next step — iterate per feature in fresh sessions inside the
    project directory.
 
+**PoC:** the gate is the manus: `yarn manus` (or the package manager's equivalent) with
+every point green or `fixme`, nothing red, and the last run before you claim anything is
+a cold `--headed` run with the dev server stopped first. Headless wins timing races that
+a demo-day browser loses, so a point that is green headless and red headed is red, and
+headed is the mode the demo is actually shown in. Never put a command in the handoff
+that you have not run yourself in exactly that form. Then: README with the start
+command, the port and the manus command; commit `docs/MANUS.md` and
+`docs/plans/round-1.md`. `haus doctor` shows `Profile: poc`; the CI-gate suggestion, the
+`docs/SUMMARY.md` suggestion and the legacy `docs/adr/` migration finding are all gated
+on the profile now, so a healthy PoC repo will not see any of the three, and seeing one
+means the installed CLI predates this gate, not something to argue past. Whatever doctor
+still flags here is real: read it and act on it, or, for a machine-level finding such as
+a disabled global plugin, check it with the tool that owns it (`claude plugin list`)
+before telling the user doctor is wrong. Then push if a remote exists (never for
+local-only). Then stop: do NOT follow `references/init.md`
+from step 3, because a PoC has no docs pass, no deep read and no recommend re-check. Hand off in
+the user's language, naming the demo date, the two re-entry phrases and the decision the
+meeting ends with: next session, open this repo and say "where are we" / "var är vi",
+or "extend the demo with ..."; after the demo, decide
+actively per the standard's **After the demo** section: archive the repo, or build it for
+real from zero with `docs/MANUS.md` and Parked as input, never from this code. If the
+fast path created `<cwd>/<name>`, say that the user opens that directory as a new Claude
+Code project.
+
 ## Failure rules
 
 - Relay `haus` failure `detail` verbatim; never retry destructively; the project

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haus-tech/haus-workflow",
-  "version": "5.4.0",
+  "version": "5.6.0",
   "description": "Haus AI workflow CLI for Claude Code.",
   "type": "module",
   "bin": {