@haus-tech/haus-workflow 4.4.0 → 4.5.0

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

@@ -14,6 +14,13 @@ whenever this procedure is reached with **no name** — whether from the no-arg
 no argument — do **not** silently fall through to Mode B (workspace); ask first, via
 `AskUserQuestion`:
 
+**Skip this question when `SKILL.md`'s Step 1.5 already determined the cwd is Workspace
+scope** (a `haus.workspace.yaml`/`repos.manifest.json` already exists at the git root) —
+in that case go straight to Mode B (unless a `name` was already given, in which case Mode
+A takes over as usual). Asking "single repo or whole workspace?" again here would
+contradict a scope Step 1.5 already resolved. Only ask below when Step 1.5 found Project
+or Not-set-up scope (or no scope check ran, e.g. reached from an older caller).
+
 ```
 "Clone a single repo, or a whole workspace?"
 Options:
@@ -63,3 +70,187 @@ Clone a whole **workspace** from its manifest. Workspace-only (a `repos.manifest
    **Transport fallback.** Manifest URLs may be SSH (`git@github.com:org/repo.git` or `ssh://…`). Probe SSH connectivity once up front (`ssh -T git@github.com`); if it fails, **auto-fall back to the HTTPS URL** (`https://github.com/org/repo.git`) using your `gh auth` credentials, clone over HTTPS, and **report that you switched transport** so the user knows their SSH is down. Don't halt the run for an SSH outage when HTTPS works.
 
 7. After the loop, report which repos were cloned, reused (local), skipped (already present), and failed. Remind the user that installing dependencies and configuring each repo (`.env`, services) is still a manual step for now.
+
+## Local-dev setup (optional)
+
+**Always ask before doing this work — never assume.** Everything from here through Step 4
+hits the network, needs auth, and can touch databases; confirm before each phase, and
+respect repos the user already has.
+
+Use `AskUserQuestion`:
+
+```
+"Set the cloned repo(s) up for local dev too?"
+Options:
+  1. Yes
+  2. No
+```
+
+The `cloneandsetup` and `project:cloneandsetup` aliases pre-answer **Yes** — when reached
+via one of those aliases, **skip this `AskUserQuestion` call entirely** and carry the
+resulting repo list straight into Step 1 below. On a bare **No** answer (not via one of
+those aliases), stop after the clone report. On a manual **Yes**, carry the resulting repo
+list into the setup phases below.
+
+### Step 1 — Prerequisite gate (one consolidated check)
+
+Before any setup work, probe **everything** the workspace will need and surface **all** gaps in a single prompt — never discover them piecemeal mid-flow. For the repos being set up, check:
+
+- **Auth tokens** — `NODE_AUTH_TOKEN` exported (private `@`-scoped npm packages fail without it); `~/.composer/auth.json` (or a repo-local `auth.json`) present if any repo has private composer deps.
+- **Docker daemon** — running (`docker info`); required for any repo's `needs:` services.
+- **PHP environment** — `valet`, `herd`, `ddev`, or `php` on PATH, if any repo is a PHP/WordPress site.
+- **WP-CLI** — `wp --version`, if any repo's `seed:` pulls a WordPress DB.
+- **Node versions** — the versions named in each repo's `.nvmrc` / `engines.node` are installable via `nvm`.
+- **Data-access preflight** — for every data load the workspace will run (each repo's `seed` **and** the workspace `seeds`), check up front that the user can actually reach the source, so nobody ends up with a half-set-up environment that only fails at the seed step. See below.
+
+#### Data-access preflight
+
+The single most common way cloneAndSetup leaves a **half-completed environment** is discovering at the `seed:` step — after cloning, installing, and bringing up services — that the user lacks the AWS/SSH/etc. access to pull the data. Catch it **here**, before any heavy work, and make the data outcome a deliberate choice.
+
+1. **Collect every seed:** each repo's `seed` plus the workspace `seeds`. For each, determine its required access:
+   - If `seed` is an **object with `access`**, run each entry's `check` (a read-only probe; exit 0 = reachable).
+   - If `seed` is a **bare string**, infer the channel and probe generically: `aws …`/SSM → `aws sts get-caller-identity`; `dep db:pull …` / `ssh`/`scp`/`rsync <user@host>` → `ssh -o BatchMode=yes -o ConnectTimeout=5 <host> true`; `northflank …` → `northflank whoami`. A purely local seed (no remote) needs nothing.
+2. **Report one table** alongside the rest of the gate — per data source: its `label`, the access it needs, and ✓ reachable / ✗ + the `login` remedy (verbatim).
+3. **Resolve every ✗ with one consolidated choice**, then remember it for the run:
+   - **Set up access now** → print the `login` text, let the user do it, **re-check**, then seed normally.
+   - **Create that DB EMPTY for now** (only when `empty-ok` is true — the default) → the datastore comes up empty (schema via migrations/`needs:`), the app still boots, and the user can run that one seed later. Name the exact command to fill it.
+   - **Abort.**
+4. **Only a gap on a seed with `empty-ok: false` is a HARD STOP** (the repo is genuinely broken without data — log in or abort). Every other gap offers the empty path; one source's missing access never blocks another's.
+
+This is the one prompt the "no half-completed environment" goal justifies. The two valid end-states are **seeded** or **deliberately empty** — never a third "did the expensive work then died at seed."
+
+Then list the repos and what each will run (node, deps, localdev steps, **data sources + the chosen seed/empty plan**), **report every gap at once**, and get a single go-ahead. For **reused** local clones, ask whether to re-run setup. For each gap, name what it blocks; the user decides whether to fix it now (**ask before any global/system install**) or proceed and skip the affected steps. Don't begin per-repo work until this gate is acknowledged.
+
+### Step 2 — Per-repo dependency pass
+
+For each repo, in its own directory, detect and install from the repo's own files (read its `docs/setup.md` / `CLAUDE.md` / `README.md` first — they win). Select node from `.nvmrc`/`engines.node` (`nvm install`), enable the pinned package manager (`corepack enable`), install JS deps (`yarn`/`pnpm`/`npm` by lockfile), composer deps if `composer.json` + `composer` present. Run each repo's steps in one login shell so the node version stays active. Per-repo failure is reported and skipped, not fatal.
+
+**Leave `.env` to Step 3 → "Env".** The dependency pass installs only; the env phase writes each repo's `.env` deterministically once services, links, and values are in place.
+
+### Step 3 — Local-dev orchestration
+
+This is the phase that takes the workspace from "installed" to "ready to run." It is driven by `localdev.yml` files; a repo with none is set up by Step 2 only.
+
+#### House conventions (the "how", so repos specify only the "what")
+
+Specify the least. Infer the rest from the repo's stack + these conventions, and work out the concrete commands at run time:
+
+- **IMPORTANT — never install anything without asking first; global/system tools especially** (Homebrew, Docker, Laravel Herd, global `npm`/`composer` packages). Detect what's already present; if something required is missing, name it, say why it's needed, and get an explicit **yes** before installing. Prefer the least-invasive option, and don't switch or override tools the dev already has.
+- **PHP / WordPress sites are served by the developer's own PHP environment.** If they already have one — detect `valet`, `herd`, `ddev`, or `php` on PATH — **use it**: just satisfy the env contract (docroot → the repo's `web/`, HTTPS) and report the URL; never override what they already run. **Only when no local PHP environment exists** (a completely fresh machine) suggest installing **[Laravel Herd](https://herd.laravel.com)** as the default (asking first) and point its docroot at `web/` + `herd secure`.
+- **Databases and other services (a repo's `needs:`) run in Docker as a shared, workspace-owned `docker-compose` project** — grouped and self-contained (`up`/`down` together, named volumes), namespaced per workspace instance via `COMPOSE_PROJECT_NAME` + its own host ports so the workspace can run multiple times side by side. Image/port/env per the house convention (`mysql:8`, `postgres:16`, …). Don't reuse a repo's own compose that bind-mounts repo-relative init files (`seed.sql`) — author the service in the workspace compose. Services come up **empty** (seeding is the separate `seed:` step); record chosen host ports in the workspace `localdev.yml` `env` map.
+- **Dependencies** install from the lockfile (Step 2).
+- A repo's `localdev.yml` carries **only what can't be inferred** — its `needs`, repo-specific `build`/`seed` commands, env keys, and URL. Detect the stack (e.g. Bedrock = `composer.json` + `web/` docroot + `wp-cli.yml`; Vendure/Node = `docker-compose.yml` + `@vendure/*`) and apply the matching convention.
+
+#### The `localdev.yml` format
+
+**Per-repo — `<repo>/.haus-workflow/localdev.yml`** (how to set up THAT repo alone; sibling-agnostic):
+
+All fields optional. **Prefer intent (`needs`/`build`/`seed`/`serve`) over explicit `steps`** —
+the conventions above turn intent into commands.
+
+```yaml
+needs: [mysql] # services this repo requires; provisioned in Docker, env wired to them
+needsEnv: [WP_HOME, DB_NAME] # env keys that must be present to run/serve
+build: 'yarn build' # optional: the build command (run after deps)
+seed: 'dep db:pull staging-oderland' # optional: how to load data; remote/destructive → confirm first
+# `seed` may also be an OBJECT when the load needs external access (AWS, SSH, …) so the
+# Step-1 data-access preflight can check it up front and offer an empty-DB fallback:
+seed:
+  run: './scripts/pull-aws-db.sh --yes' # the seed command
+  empty-ok: true # default true: skipping yields a coherent EMPTY DB (schema via migrations).
+  #              # false = the repo is broken without data → a missing-access gap HARD-STOPS.
+  access: # what the user must have to run `run`; each entry probed in the Step-1 preflight
+    - label: 'AWS CLI credentials — eu-north-1 / 842675986884'
+      check: 'aws sts get-caller-identity --region eu-north-1' # read-only probe; exit 0 = OK
+      login: 'Set up the AWS CLI (brew install awscli; aws configure …) — or pick empty DB.'
+serve: # optional: how it runs (printed as a next-step, never auto-started)
+  via: herd # herd | valet | docker | command — for PHP envs, bring-your-own (don't install)
+  url: 'https://example.test'
+  start: 'yarn dev'
+steps: # optional escape hatch: explicit ordered shell steps when intent isn't enough
+  - run: 'composer install'
+    node: 10 # nvm version for THIS step
+    remote: true # SSH → confirm first
+    destructive: true # overwrites data → confirm first
+    optional: true # failure is non-fatal, continue
+```
+
+**Workspace — `<workspace>/.haus-workflow/localdev.yml`** (the glue BETWEEN repos):
+
+The workspace `env` map is the **single source of truth for cross-repo values** — DB names, ports, host URLs are chosen once and recorded here as literals. The env phase reads values **from here** and writes them into each repo's `.env`. Recording them here (not only in a repo's `.env`) means a later `seed:` / `db:pull` step can find them without depending on env-file load order.
+
+```yaml
+order: [repo-a, repo-b] # setup/startup order, by manifest id
+links:
+  - { type: symlink, from: <repo-folder>, to: <repo-folder>/path/to/link }
+  - { type: composer-path, in: <repo>, dep: <sibling-repo> }
+  - { type: yarn-link, in: [<repo>, ...], dep: <sibling-package-repo> }
+env:
+  - value: 'app_local' # a chosen literal — the recorded source of truth, OR …
+    # source: { repo: <repo>, provides: '<value>' }   # … a value produced by another repo
+    sinks:
+      - { repo: <repo>, key: DB_NAME } # written under `key` into each sink's .env
+seeds: # optional: data sources NOT owned by a manifest repo (e.g. a shared WordPress host
+  #    pulled by a workspace script). Same shape as a per-repo `seed` object; included in
+  #    the Step-1 data-access preflight.
+  - label: 'WordPress host (example.se)'
+    run: './scripts/pull-wp-example.sh'
+    empty-ok: true
+    access:
+      - label: 'SSH user@host'
+        check: 'ssh -o BatchMode=yes -o ConnectTimeout=5 user@host true'
+        login: 'Add your SSH key to the host (ssh-add …) / request access — or skip the pull.'
+```
+
+#### Run order
+
+1. **Discover** `.haus-workflow/localdev.yml` in the workspace root and each repo.
+2. **Resolve order** from the workspace `order` (repos not listed run last, in manifest order). No workspace file → manifest order.
+3. **Per repo, in order**, apply intent via the conventions:
+   - **`needs`** → add the service to the **workspace compose project** and `docker compose up -d` if not already running (namespaced by `COMPOSE_PROJECT_NAME`, free host ports per instance; not the repo's own bind-mounting compose). Comes up **empty**; record host ports in the workspace `localdev.yml` `env` map — data lands in `seed:`.
+   - **`build`** → run it (honor any node version the repo's docs note).
+   - **`serve`** → for `via: herd` / PHP envs, install nothing — verify the dev's environment serves `web/`, and report the URL.
+   - **`seed`** → populate the empty datastore (`seed.run`, or the bare-string form). **Always a distinct, confirm-gated step, separate from `needs:` bring-up** (don't conflate "DB up" with "DB has data"). **Honor the data plan chosen in the Step-1 data-access preflight** — don't re-discover access here: if the user chose _empty_ for this source, skip it (the DB stays empty, schema via migrations) and print the command to fill it later; if they chose _seed_, run it. Still verify the run-time prerequisites the preflight couldn't (the target repo's **`.env` written** — done in the Env step above; WP-CLI present for `wp`/`db:pull` seeds) and **confirm first** for every remote (SSH/AWS) or destructive (overwrites data) seed — every run, even on re-run. Missing prerequisite → skip with a clear message, don't guess.
+   - **`steps`** (escape hatch) → run in order, selecting `node:` per step, `optional:` failures continue, **confirming before any `remote:`/`destructive:` step** — every run, even on re-run.
+4. **Links** (workspace-owned, performed generically — do NOT call a repo's own `setup-dev-mode.sh`, which is deprecated):
+   - `symlink` → `ln -s <from> <to>`; replace an existing symlink, but never clobber a real directory without confirmation.
+   - `composer-path` → in `in`'s `composer.json`, set the `dep`'s require to `{ "type": "path", "url": "../<dep-folder>", "options": { "symlink": true } }`, then `composer update <vendor/dep>`.
+   - `yarn-link` → `yarn link` in the `dep` repo, then `yarn link <pkg-name>` in each `in` repo (read `<pkg-name>` from the dep's `package.json`).
+5. **Env (deterministic):** write each repo's `.env` from known values — no improvising.
+   1. **Compute** each repo's values, in this precedence: the workspace `localdev.yml` `env` map (chosen literals + cross-repo `source` values — the single source of truth) → generated secrets (DB passwords/tokens minted this run) → **a value already present locally** in a sibling repo's `.env.example` / `.env` (matched by key, or by the same value under a framework-prefix swap `MIX_` ↔ `VITE_` ↔ `NEXT_PUBLIC_` ↔ `REACT_APP_`) — reuse it: it is already on the machine, so copying it into this repo's local (gitignored) `.env` adds nothing new to git → the **dev-defaults table** below for anything still unset.
+   2. **Write** them into each repo's `.env` (create it if absent; **upsert** keys, never clobbering a value the user already set). These are local dev files — write them directly.
+   3. **Secrets that exist nowhere locally** (third-party API keys, prod credentials, license keys the machine doesn't already have — §1 reuse only applies when the value is present locally) can't be invented, so the flow **explicitly tells the user it needs them** — never silently leaving a blank and proceeding as if set up. Put each in as a clearly-marked `KEY=` blank and report it, naming **which key**, **what it unlocks** (the step or feature that fails without it), and **how to get it manually**: from the provider's own account/dashboard (e.g. the Laravel Nova licence page, the Mediaflow API account), by copying it from the deployed environment's env vars (the server / hosting config), or by asking a colleague who already has it. **NEVER write a secret value into a git-tracked file:** `.env` writes are local and gitignored (fine — reuse freely), but the workspace `localdev.yml` `env` map is committed, so it carries non-secret cross-repo literals only (DB names, ports, host URLs), never credentials. Report all blanks together as one actionable list, not piecemeal.
+
+   **Dev-defaults table** — used only when neither `localdev.yml` nor a generated secret supplies the value:
+
+   | Key                              | Default                                                             |
+   | -------------------------------- | ------------------------------------------------------------------- |
+   | `DB_HOST`                        | `127.0.0.1`                                                         |
+   | `DB_PORT`                        | `3306` (mysql) / `5432` (postgres) — or the port chosen on conflict |
+   | `DB_USER` / `DB_PASSWORD`        | `root` / a generated secret                                         |
+   | `WP_HOME`, `WP_SITEURL`, `*_URL` | the repo's `serve.url`                                              |
+   | `WP_ENV` / `APP_ENV`             | `development`                                                       |
+
+6. **Report, then offer to start.** Give the per-repo summary, then **ask the user whether to start everything now.**
+   - **Yes** → start each repo in the workspace `order` (its `serve.start`, e.g. `yarn dev`; bring up any remaining foreground services), run any follow-ups (e.g. `wp sync-products sync`), then **print the live URLs** (each repo's `serve.url`).
+   - **No** → just print the ordered start commands + follow-ups as next steps; start nothing.
+
+**Default is "ready to run" (D2):** the preparation — datastores up (workspace `docker compose` project), seeds applied (confirm-gated), links, builds, each repo's `.env` written — always happens. Starting the **foreground** dev servers and the initial product sync happen **only if the user says yes** to the start prompt above; otherwise they're printed, not run.
+
+### Step 4 — Report and define "done"
+
+**"Done" is an explicit terminal state**, not "looks set up". The preparation reaches:
+
+- datastores up (workspace `docker compose` project),
+- dependencies installed and builds green,
+- links wired,
+- each repo's `.env` written from known values.
+
+From there, **live URLs are reachable only if** every required secret is satisfiable **and** the user starts the servers. If a secret can't be minted (a third-party key, a prod credential), say exactly which keys are still blank and what the user must fill — don't imply links a missing secret will quietly break.
+
+Summarise per repo (node, deps, localdev steps, links, env). Then **ask whether to start everything now**:
+
+- **Yes** → start the dev servers in workspace `order`, run any follow-ups, and **print the live URLs** so the user can open the running app.
+- **No** → print the ordered start commands + follow-ups instead, and start nothing.
+
+Never start the app without that explicit yes.

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

@@ -10,6 +10,21 @@ the agent; collect answers with AskUserQuestion and pass everything as flags.
 
 ## Phase 0 — Entry
 
+**Scope check first.** If `SKILL.md`'s Step 1.5 found the cwd is **Workspace** scope (or
+**Member repo of a workspace** resolved to "Whole workspace"), ask via `AskUserQuestion`
+before anything else: "Add the new project as a member of this workspace, or scaffold it
+standalone elsewhere?"
+
+- **Add as workspace member** — scaffold under the workspace root (default folder: the
+  project name, sibling to the other member repos) instead of the cwd. After Phase 3
+  creates the repo, tell the user to add an entry for it to `haus.workspace.yaml` /
+  `repos.manifest.json` themselves — this flow only scaffolds and does not write either
+  file (no CLI command mutates them yet).
+- **Standalone** — proceed exactly as below, unaffected by the workspace.
+
+Skip this ask entirely when Step 1.5 found Project or Not-set-up scope — proceed straight
+to the rest of Phase 0.
+
 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.

package/library/global/skills/request-assess-impact/SKILL.md

@@ -41,6 +41,11 @@ Befintligt mönster som återanvänds, eller något som inte finns idag. Namnge
 **Verifiering**
 Vad som kan bevisas automatiskt, och vad som kräver att en människa kör igenom det — i hur många scenarier, på hur många enheter, i hur många miljöer. Endast bygget. Kundens acceptanstest hör inte hit; skriv det inte ens som notering.
 
+Skriv dessutom ut **om den berörda ytan har automatiska tester i dag**, och exakt vilken del som saknar dem. Det avgör om posten ska få en egen testpost, byggd före ändringen. Blanda inte ihop det med sådant som kräver en människa av sin natur — kontroll mot en extern tjänsts testläge, visuell granskning, flera enheter eller miljöer — det står kvar oavsett testsvit.
+
+**Delbarhet**
+Faller arbetet i delar som var för sig går att uppskatta? Ett kort svar räcker normalt: ja med delarna uppräknade i en mening, eller nej med skälet. Begär poängsättningen en uppdelning skrivs delarna ut fullständigt, se nedan.
+
 **Konsekvens av fel**
 Vad som händer i värsta fall om posten blir fel. Konkret, inte kategoriskt: "en notis visas i fel ordning" respektive "en användare ser en annan kunds order" är olika saker. Återanvänds befintlig säkerhets- eller behörighetsmekanik enligt etablerat mönster — skriv det, och skriv att det är etablerat.
 
@@ -55,6 +60,25 @@ Vad som måste vara klart först — andra poster, ramverk, tredje part.
 
 Varje påstående ska vara belagt i koden eller specen. Kan du inte belägga något: skriv ordagrant att du inte kunnat verifiera det, och varför. Det är ett bättre utfall än en rad som ser säker ut — klassaren läser osäkerheten och eskalerar, och det är rätt.
 
+## När poängsättningen begär en uppdelning
+
+Kommer posten tillbaka med utfallet `DELA_UPP` gick den inte att ringa in mot skalan som helhet. Din uppgift är då att peka ut delarna. Poängsättningen får varken läsa repot eller skriva underlag, så den kan inte göra det själv.
+
+**Skriv ut varje del med tre saker:** vad den omfattar, uttryckt som vilken del av specen den täcker; om den går att driftsätta och lämna i produktion på egen hand; och vad den delar med de övriga i fråga om manuell genomgång.
+
+Den sista punkten avgör om uppdelningen är värd något. Kräver alla delar samma manuella genomgång av samma flöden i samma miljöer, så multipliceras det tyngsta arbetet av uppdelningen i stället för att delas. Skriv i så fall ut det.
+
+**Två sorters delar, och de hamnar olika:**
+
+- Går delen att leverera på egen hand blir den en **egen request**, med egen spec och egen leverans. Skriv det, men skriv inte specen — det är `request-write-spec` som gör det.
+- Går den inte att leverera på egen hand blir den en **del av samma post**, som levereras tillsammans med resten.
+
+**Delarna ärver postens spec och den här analysen.** Skriv ingen egen spec och ingen egen analys per del. Varje del får en omfattningsrad som säger vilken del av specen den täcker, och poängsätts mot det gemensamma underlaget. Kunden har beställt en sak; uppdelningen är intern struktur.
+
+**Dela ett steg.** Kommer en del tillbaka och inte går att ringa in heller, ska den offereras — inte delas vidare. Delar man tills varje bit får plats under skalans tak blir summan för hög av skäl som inte har med arbetet att göra.
+
+**Minst två delar.** Blir det bara en har posten inte delats, och då är svaret att den inte är delbar.
+
 ## Vägval
 
 **Du beslutar, du frågar inte.** Ett vägval är en gaffel där båda vägarna fungerar. Du väljer och redovisar valet — det är därför steget klarar sig utan en människa, och det är också vad kunden betalar oss för.

package/library/global/skills/request-score/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: request-score
-description: Sätter poäng på en spec plus påverkansanalys genom att jämföra uppdraget mot en skala av sexton referensuppdrag. Använd alltid när användaren vill "sätt poäng", "poängsätt", "kör poängen", "vad landar det här på", "var på skalan ligger det", eller när en spec har en påverkansanalys och ska prissättas. Används även som grind på en fullständig implementationsplan före första kodraden — "kör guarden", "stämmer poängen fortfarande". Använd den även när poängsättning bara antyds, t.ex. när någon klistrar in en spec med underlag och frågar hur stort det är. Output är JSON med poäng och belägg, aldrig ett pris.
+description: Sätter poäng på en spec plus påverkansanalys genom att jämföra uppdraget mot en skala av sjutton referensuppdrag. Använd alltid när användaren vill "sätt poäng", "poängsätt", "kör poängen", "vad landar det här på", "var på skalan ligger det", eller när en spec har en påverkansanalys och ska prissättas. Används även som grind på en fullständig implementationsplan före första kodraden — "kör guarden", "stämmer poängen fortfarande". Använd den även när poängsättning bara antyds, t.ex. när någon klistrar in en spec med underlag och frågar hur stort det är. Output är JSON med poäng och belägg, aldrig ett pris.
 ---
 
 # request-score
@@ -29,44 +29,73 @@ underlaget är svaret låg konfidens, inte en egen efterforskning.
 
 ## Stoppfrågorna först
 
-Poäng sätts bara på en post som går att bygga. Tre utfall stoppar poängsättningen:
+Poäng sätts bara på en post som går att bygga. Fyra utfall stoppar poängsättningen:
 
-| Utfall | När | Vad som ska hända |
-| --- | --- | --- |
-| `KONCEPT` | Formen är okänd — designfråga, oavgjort vägval, flera lösningsvägar utan beslut | Egen post som levererar ett förslag och en poäng på bygget |
-| `DIAGNOS` | Orsaken är okänd och går att undersöka. Gäller framför allt fel där ingen vet varför något är trasigt | Tidsboxad undersökning som levererar besked och en poängsatt åtgärd |
-| `TILLBAKA_TILL_SPEC` | Specen lämnar ett utfallsval obesvarat **och valet ändrar arbetsmängden** | Specen kompletteras, sedan ny körning |
+| Utfall               | När                                                                                                   | Vad som ska hända                                                   |
+| -------------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
+| `KONCEPT`            | Formen är okänd — designfråga, oavgjort vägval, flera lösningsvägar utan beslut                       | Egen post som levererar ett förslag och en poäng på bygget          |
+| `DIAGNOS`            | Orsaken är okänd och går att undersöka. Gäller framför allt fel där ingen vet varför något är trasigt | Tidsboxad undersökning som levererar besked och en poängsatt åtgärd |
+| `TILLBAKA_TILL_SPEC` | Specen lämnar ett utfallsval obesvarat **och valet ändrar arbetsmängden**                             | Specen kompletteras, sedan ny körning                               |
+| `DELA_UPP`           | Posten går inte att ringa in på egen hand — se nedan                                                  | Ny analysrunda som pekar ut delarna, sedan en körning per del       |
 
-### Obesvarade utfallsval: förutsättning eller stopp
+### När posten inte går att ringa in
+
+Två lägen ger `DELA_UPP`:
+
+- Du hittar inget tak, alltså inget referensuppdrag som posten säkert är mindre än.
+- Golv och tak ligger långt isär och inget referensuppdrag finns emellan, alltså det
+  läge som annars bara hade gett `confidence: lag`.
+
+Skriv i `notes` vilket av lägena det var, och vilka delar av påverkansanalysen som
+pekar mot att posten rymmer flera skilda arbeten. **Peka inte ut delarna själv.** Du
+får varken läsa repot eller skriva underlaget, och att avgöra vad som går att leverera
+för sig kräver båda. `request-assess-impact` gör uppdelningen; du säger bara att den
+behövs.
+
+Delningen görs ett steg. Kommer en del tillbaka och inte går att ringa in heller, blir
+den `OVER_SKALAN` och offereras — den delas inte vidare.
+
+**En post som redan har poängsatta delar poängsätts aldrig som helhet.** Föräldern bär
+summan av sina delar, inte en egen siffra.
+
+### Obesvarade utfallsval
 
 Påverkansanalysens granskarblock listar under _Obesvarade utfallsval_ de val specen
 lämnat öppna, var och en med alternativen, om de skiljer sig i vad som måste byggas,
-och vilket alternativ analysen är skriven utifrån. De ska inte behandlas lika. Ställ en
-fråga per val:
+och vilket alternativ analysen är skriven utifrån.
 
-**Ändrar valet hur mycket arbete posten kräver?** Analysens rad om huruvida
-alternativen skiljer sig i vad som måste byggas är svaret. Saknas den raden — analysen
-kan vara skriven före den här regeln — behandla valet som ett stopp och skriv i `notes`
-att analysen behöver kompletteras.
+En post stoppas nästan aldrig för ett sådant val. Gå igenom dem i fyra steg.
 
-**Nej** — då är det en **förutsättning**, inte ett stopp. Välj det rimligaste
-alternativet, skriv in det i `assumptions_stated` med vad som valts och varför, och
-poängsätt vidare. Förutsättningarna följer med förslaget till kund tillsammans med
-specen och priset, så kunden godkänner alla tre på en gång. Väljer kunden annorlunda
-är det en ändring som inte rör priset.
+**Steg 1 — stryk det som inte löser problemet.** Läs specens rubrik _Problem_. Ett
+alternativ som inte löser det problemet är inget alternativ, det är en otillräcklig
+lösning, och det ska varken väljas eller presenteras. Att prissätta det vore att sälja
+något som inte gör det kunden bett om.
 
-Typexempel: vilket av två befintliga sätt att visa att något laddar som används, vilken
-av två likvärdiga formuleringar en text får, var i en befintlig vy ett fält placeras.
+Testet är specens egna ord, inte din uppfattning om vad kunden borde vilja. Löser
+alternativet problemet som det är beskrivet? Delvis räcker inte.
 
-**Ja** — då stoppar posten. Utfallsvalet avgör vad som ska byggas och därmed vad det
-kostar, och att gissa vore att prissätta något kunden inte beställt.
+**Steg 2 — återstår ingenting, stoppa.** Då motsäger specen sig själv: problemet går
+inte att lösa inom det den beskriver. Sätt `outcome` till `TILLBAKA_TILL_SPEC` och
+skriv i `customer_rationale` vad som behöver avgöras, i kundens språk.
 
-Typexempel: om en funktion ska finnas på både mobil och dator eller bara en av dem, om
-befintlig data ska konverteras eller lämnas, om ett flöde ska ha ett steg till.
+**Steg 3 — ändrar valet arbetsmängden?** Analysens rad om huruvida alternativen skiljer
+sig i vad som måste byggas är svaret. Gör de inte det är valet en **förutsättning**:
+välj det rimligaste, skriv in det i `assumptions_stated` med vad som valts och varför,
+och poängsätt vidare. Kunden godkänner förutsättningen tillsammans med spec och pris.
 
-Är du osäker på om valet ändrar arbetsmängden: behandla det som ett stopp och skriv
-ut varför. Ett onödigt stopp kostar några minuter, ett gissat utfallsval kostar en
-felprissatt post.
+Typexempel på förutsättning: vilket av två befintliga sätt att visa att något laddar som
+används, vilken av två likvärdiga formuleringar en text får, var i en befintlig vy ett
+fält placeras.
+
+**Steg 4 — flera alternativ som alla löser problemet.** Poängsätt **det enklaste** som
+postens poäng. Poängsätt varje övrigt alternativ för sig, med egen inringning, och lägg
+dem i `alternatives`. De går till kund som alternativa lösningar med egna priser.
+
+Saknas analysens rad om arbetsmängd — den kan vara skriven före den regeln — avgör
+själv utifrån vad analysen beskriver, och skriv i `notes` att raden saknades.
+
+Varje alternativ ringas in precis som huvudalternativet. Ett alternativ med en poäng
+men utan inringning är lika ogiltigt som en post utan.
 
 Ett antagande som inte går att undersöka är inget stopp. Det blir ett villkor på posten:
 "bygger på att X; faller X tidigt avbryts posten utan debitering". Osäkerhet löses med
@@ -86,8 +115,9 @@ mellan två körningar. Ringa in i stället, i fyra steg. Alla fyra redovisas i
 Får du inget golv: posten är mindre än A1 och får A1:s poäng. Skalans nedre ände är
 ändå dominerad av den fasta processavgiften.
 
-Får du inget tak: posten är större än skalans högsta referensuppdrag. Sätt utfallet
-till `OVER_SKALAN` och sätt ingen poäng — underlaget för den nivån är för tunt för att
+Får du inget tak: posten är större än skalans högsta referensuppdrag. Sätt då `DELA_UPP`
+och ingen poäng, så att posten först prövas i delar. Är detta redan en del av en delad
+post sätter du i stället `OVER_SKALAN` — underlaget för den nivån är för tunt för att
 jämföra mot, och posten ska offereras separat.
 
 **Steg 3 — snäva in.** Gå igenom referensuppdragen mellan golv och tak. För varje: är
@@ -118,9 +148,9 @@ ligger högt.
 repot saknar testsvit. Räkna bara det manuella arbete som återstår när en fungerande
 testsvit gjort sitt: det som kräver en människa av sin natur, alltså kontroll mot en
 extern tjänsts testläge, visuell granskning, eller genomgång på flera enheter eller i
-flera miljöer. Att ett repo saknar tester är Haus egen tekniska skuld, och den ska
-kunden inte betala för. Skriv i så fall en rad om det under `notes`, så att skulden
-syns i stället för att bakas in i priset.
+flera miljöer. Saknas testsviten är det inte en rabatt: täckningen byggs som en egen
+post före ändringen och poängsätts för sig. Skriv en rad under `notes` om vilken yta
+som saknar täckning, så att den posten går att skapa.
 
 **Vad som händer om det blir fel.** Felaktig betalning, felaktig åtkomst till någon
 annans uppgifter, förlorad data eller bruten befintlig funktion väger tungt. Fel text
@@ -164,7 +194,7 @@ Bygger fullplanen ett annat vägval än det som såldes är det en händelse att
 {
   "request_id": "",
   "mode": "pricing | guard",
-  "outcome": "POANG | KONCEPT | DIAGNOS | TILLBAKA_TILL_SPEC | OVER_SKALAN | INPUT_SAKNAS",
+  "outcome": "POANG | KONCEPT | DIAGNOS | TILLBAKA_TILL_SPEC | DELA_UPP | OVER_SKALAN | INPUT_SAKNAS",
   "score": null,
   "type": "",
   "bracket": {
@@ -177,6 +207,7 @@ Bygger fullplanen ett annat vägval än det som såldes är det en händelse att
   "confidence": "hog | medel | lag",
   "conditions": [],
   "assumptions_stated": [],
+  "alternatives": [],
   "dependencies": [],
   "notes": [],
   "customer_rationale": "",
@@ -198,9 +229,20 @@ påverkansanalysen. Citat, inte parafras.
 arbetsmängden: vad du valt, och varför. De går med förslaget till kund som
 förutsättningar och godkänns tillsammans med specen och priset.
 
+`alternatives` är de övriga vägar som också löser problemet, en post var med `label`
+(vad alternativet innebär, i kundens språk), `score`, `bracket` och `adds` (vad som
+tillkommer jämfört med det valda). Alternativ som inte löser specens problem hör inte
+hit och ska utelämnas helt. Är listan tom fanns bara en väg som löser problemet.
+
 `notes` är iakttagelser som inte hör till poängen men som någon bör känna till, till
 exempel att ett repo saknar testsvit.
 
+**Ett antagande som analysen flaggat som overifierat ska alltid ut.** Går det att
+undersöka hör det till `notes` med hur det undersöks. Går det inte att undersöka blir
+det ett villkor i `conditions`, formulerat som "bygger på att X; faller X tidigt
+avbryts posten utan debitering". Ett overifierat antagande som varken syns i det ena
+eller det andra försvinner tyst, och då bär Haus en risk ingen beslutat om.
+
 `confidence` sätts till `lag` när posten inte liknar något referensuppdrag, när golv och
 tak ligger långt isär och inget referensuppdrag finns emellan, eller när
 påverkansanalysen anger att något inte kunnat verifieras och det påverkar placeringen.
@@ -213,6 +255,10 @@ ser rimlig ut.
 hur skalan räknade. Nämn aldrig poäng, referensuppdrag, ankare eller skalan. Kunden ska
 kunna invända mot omfattningen, inte mot modellen.
 
+Finns alternativ: beskriv dem sist, som egna vägar med var sitt pris. En mening var
+räcker — vad kunden får i stället, och vad som tillkommer. Priset räknas ur poängen
+någon annanstans; skriv aldrig ut poängen.
+
 Den ska vara förenlig med specens _Ingår inte_. Motiverar du poängen med arbete som
 specen uttryckligen undantar har du poängsatt fel post.