@haus-tech/haus-workflow 5.4.0 → 5.5.0

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## [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

@@ -9557,14 +9557,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));

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,14 @@ 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:** the mode 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 +93,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 +117,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 +149,23 @@ 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.
+
+- **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.
+
 ## Phase 4 — Context install
 
 Everything from here on runs inside the new project directory — `cd` into it first and
@@ -111,6 +191,45 @@ 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. 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 did this; 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).
+- `playwright.config.ts` 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.
+- `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.
+- `"manus": "playwright test"` in package.json scripts.
+- `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 +259,17 @@ 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). 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 +289,20 @@ 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. 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` and nothing needing attention; 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.5.0",
   "description": "Haus AI workflow CLI for Claude Code.",
   "type": "module",
   "bin": {