@haus-tech/haus-workflow 4.3.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.
@@ -90,9 +114,29 @@ Analysen som ett dokument, en sida. Sedan ett kort block till granskaren:
 ## Till granskaren
 
 **Ej verifierat:** [vad du inte kunnat belägga i koden, och varför]
-**Avvikelse mot specen:** [om koden säger något annat än specen förutsätter · utfallsval specen lämnat obesvarade]
+**Avvikelse mot specen:** [om koden säger något annat än specen förutsätter]
+**Obesvarade utfallsval:** [ett stycke per val — se nedan]
 ```
 
+### Obesvarade utfallsval
+
+Ett utfallsval som specen lämnat öppet skrivs ut med tre saker, och alla tre behövs:
+
+1. **Vilka alternativen är.** Namnge dem, och var i koden vart och ett finns om de
+   bygger på något befintligt.
+2. **Om alternativen skiljer sig i vad som måste byggas.** Skriv rakt ut "båda mönstren
+   finns redan, samma arbete oavsett" eller "det ena kräver att X också ändras". Det är
+   en observation om koden, inte en bedömning av omfattning — du skriver aldrig att
+   något är stort, litet, enkelt eller dyrt.
+3. **Vilket alternativ analysen är skriven utifrån.** Du måste utgå från något för att
+   kunna beskriva systemet. Skriv "beskriven utifrån X", aldrig "vi väljer X" — valet
+   är inte ditt.
+
+Skälet till punkt 2: den som poängsätter posten har inte repot och kan inte se om
+alternativen kostar olika. Utan din rad måste den anta det värsta och stoppa posten,
+även när båda vägarna är samma arbete. Det är den vanligaste orsaken till att en post
+studsar tillbaka till specen i onödan.
+
 Sista raden är den viktigaste. Förutsätter specen något som inte stämmer i systemet är det ett fel som ska tillbaka till specen, inte något som ska klassas.
 
 ## Vad du aldrig gör

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

@@ -0,0 +1,285 @@
+---
+name: request-score
+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
+
+Du sätter poäng på en post genom att jämföra den mot referensuppdragen i
+`references/poangskala.md`. Läs skalan innan du poängsätter första posten i en session.
+
+**Går filen inte att läsa: poängsätt inte.** Säg att `references/poangskala.md` saknas
+och att skillen inte kan köras utan den. Sätt aldrig en poäng på minnet av hur skalan
+brukar se ut. Skalan ändras när nya referensuppdrag läggs till, och en poäng satt på
+en gammal skala ser likadan ut som en satt på rätt skala.
+
+**Du sätter aldrig pris.** Poäng blir pris genom en fast processavgift plus poängen
+gånger en konverteringsfaktor, och det räknas någon annanstans. Ligger prislistan i
+sammanhanget: använd den inte och säg till. Vet du vad poängen kostar drar du mot den
+poäng som känns rimlig att ta betalt för, och då mäter du inte längre uppdraget.
+
+**Du skriver aldrig underlaget.** Saknas spec eller påverkansanalys, avbryt med
+`INPUT_SAKNAS`. Skriv inte en påverkansanalys själv — då jämför du din egen text mot
+skalan, och belägget blir teater. `request-assess-impact` gör det, helst i en egen
+körning.
+
+**Ge inte dig själv repot i den här körningen.** Har du det börjar du verifiera saker
+vid sidan av underlaget, och då poängsätter du inte längre det du fått. Saknas något i
+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. 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                               |
+| `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       |
+
+### 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.
+
+En post stoppas nästan aldrig för ett sådant val. Gå igenom dem i fyra steg.
+
+**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.
+
+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.
+
+**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.
+
+**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.
+
+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
+kunskap eller villkor, aldrig med högre poäng för säkerhets skull.
+
+## Metoden: ringa in, aldrig skatta fritt
+
+En siffra som kommer direkt ur en helhetsbedömning går inte att granska och blir olika
+mellan två körningar. Ringa in i stället, i fyra steg. Alla fyra redovisas i utfallet.
+
+**Steg 1 — hitta ett golv.** Läs skalan och hitta ett referensuppdrag som posten
+**säkert är större än**. Skriv ut vilket och varför.
+
+**Steg 2 — hitta ett tak.** Hitta ett referensuppdrag som posten **säkert är mindre
+än**. Skriv ut vilket och varför.
+
+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 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
+posten större eller mindre, och på vilken grund? Fortsätt tills du har två
+angränsande referensuppdrag som posten ligger mellan.
+
+**Steg 4 — placera.** Sätt poängen mellan de två. Ligger posten närmare det ena, säg
+vilket och varför. Landar den på samma nivå som ett referensuppdrag, ge den det
+ankarets poäng rakt av.
+
+**Avrunda till skalans upplösning.** Under 3 poäng till närmaste 0,25, alltså 0,25,
+0,5, 0,75, 1, 1,25 och så vidare. Från 3 poäng och uppåt till närmaste hela poäng. En
+finare siffra än så låtsas om en noggrannhet som inte finns: två oberoende bedömare
+hamnar i olika klass i en femtedel av fallen. Avrundningen är mekanisk och sker efter
+placeringen, aldrig genom att du väljer ett rundare tal medan du jämför.
+
+## Vad du jämför på
+
+Jämför på vad ändringen **drar med sig**, inte på hur mycket kod som skrivs. Det som
+skiljer referensuppdragen åt, i fallande ordning efter hur mycket de väger:
+
+**Om en människa måste verifiera för hand, och i hur många fall.** Det är den tydligaste
+skillnaden genom hela skalan. Ett uppdrag som täcks av automatiska tester ligger lågt.
+Ett som kräver genomgång i flera scenarier, på flera enheter eller i flera miljöer
+ligger högt.
+
+**Förutsätt alltid att automatiska tester finns**, även när påverkansanalysen säger att
+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. 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
+eller fel sorteringsordning väger lätt.
+
+**Om ändringen rör kod som flera kunder använder.** Då tillkommer migrering per
+installation och en risk som når utanför beställaren. Se A9 och A10.
+
+**Om ett externt system berörs**, och om kopplingen är ny eller befintlig.
+
+**Om en sekvens som användaren passerar i ordning ändras**, och hur många steg.
+
+**Om något ska formges som inte finns i systemet i dag.**
+
+Antal filer och antal rader är **inte** jämförelsegrunder. Se noten sist i skalan: två
+referensuppdrag med samma poäng skiljer sig med en tiopotens i filantal.
+
+## Typen
+
+Använd typen för att hitta jämförbara referensuppdrag snabbare, ingenting annat. Ett
+uppdrag av en typ som saknas i skalan poängsätts mot de närmaste i storlek, inte mot
+någon påhittad justering. Skriv ut vilken typ du bedömt posten som — den loggas för att
+kunna mäta i efterhand om någon typ hamnar systematiskt fel.
+
+## Grindläget
+
+Körs skillen på en fullständig implementationsplan efter kundens godkännande, sätt
+`mode` till `guard`. Samma skala, samma metod.
+
+Endast ny strukturell information ur fullplanen får flytta poängen, aldrig en
+omvärdering av samma fakta. Rapportera vilket jämförelsesteg som ändrades och citatet ur
+fullplanen som orsakade det. Grinden är symmetrisk — en lägre poäng rapporteras lika
+tydligt som en högre.
+
+Bygger fullplanen ett annat vägval än det som såldes är det en händelse att rapportera
+även när poängen blir densamma.
+
+## Output
+
+```json
+{
+  "request_id": "",
+  "mode": "pricing | guard",
+  "outcome": "POANG | KONCEPT | DIAGNOS | TILLBAKA_TILL_SPEC | DELA_UPP | OVER_SKALAN | INPUT_SAKNAS",
+  "score": null,
+  "type": "",
+  "bracket": {
+    "floor": { "anchor": "", "score": null, "why": "" },
+    "ceiling": { "anchor": "", "score": null, "why": "" },
+    "between": ["", ""],
+    "steps": []
+  },
+  "drivers": [],
+  "confidence": "hog | medel | lag",
+  "conditions": [],
+  "assumptions_stated": [],
+  "alternatives": [],
+  "dependencies": [],
+  "notes": [],
+  "customer_rationale": "",
+  "guard_diff": []
+}
+```
+
+`score` sätts bara när `outcome` är `POANG`, och alltid på skalans upplösning: steg om
+0,25 under 3 poäng, hela poäng från 3 och uppåt.
+
+`bracket.steps` är jämförelserna från steg 3, en per referensuppdrag du vägde mot, var
+och en med ankarets id, om posten är större eller mindre, och på vilken grund. Det är
+det som gör poängen granskbar. En poäng utan inringning är inte ett giltigt utfall.
+
+`drivers` är de två eller tre faktorer som mest avgjorde placeringen, med citat ur
+påverkansanalysen. Citat, inte parafras.
+
+`assumptions_stated` är de utfallsval specen lämnat öppna som **inte** ändrar
+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.
+Låg konfidens är ett giltigt utfall och ska inte döljas genom att välja en poäng som
+ser rimlig ut.
+
+### Motiveringen till kund
+
+`customer_rationale` skrivs i kundens språk och beskriver arbetet som ska göras, inte
+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.
+
+## Efter körning
+
+Granskaren läser inringningen, inte slutpoängen. En rimlig poäng med fel jämförelser är
+en felkalibrering som råkade landa rätt, och den kommer tillbaka i en post där den inte
+gör det.
+
+Korrigeringar går till skalan, alltså till referensuppdragen eller till den här
+instruktionen, och till kalibreringsloggen. Aldrig till priset på den enskilda posten.
+
+Visar det sig återkommande att poster av ett visst slag är svåra att placera, är det ett
+tecken på att skalan har ett hål och behöver ett referensuppdrag till. Rapportera det.
+
+## Acceptanstestet — granskarens sak, inte din
+
+Skillen verifieras genom att köras mot poster med känt utfall. Det underlaget ligger med
+flit **inte** i den här mappen — en körning som kan läsa facit kan inte längre testas. Du
+ska varken leta efter det eller rapportera det som saknat.
+
+För granskaren gäller två mått: att två oberoende körningar av samma post ger samma
+poäng, och att inringningen håller vid granskning. Det första är det som avgör om
+kunderna får samma pris för samma arbete.