@haus-tech/haus-workflow 5.5.0 → 5.6.0

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # 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

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",
@@ -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/references/new.md

@@ -67,13 +67,15 @@ 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.
+**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)
 
@@ -149,7 +151,10 @@ 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.
+**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
@@ -166,6 +171,16 @@ repo create`. Carry `--dir` through from Phase 0 for a workspace member; without
   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
@@ -199,23 +214,49 @@ stay there.
    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
+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 did this; check that `.haus-workflow/haus.config.json`
-says `"profile": "poc"`.
+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).
-- `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.
+- 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.
-- `"manus": "playwright test"` in package.json scripts.
+- 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
@@ -262,7 +303,19 @@ Commit the skeleton on `main` (`chore(poc): demo skeleton`).
 **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
+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
@@ -290,9 +343,19 @@ why.
    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
+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

package/package.json

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