@haus-tech/haus-workflow 5.1.0 → 5.3.0

package/library/global/skills/request/scripts/report.mjs

@@ -219,10 +219,32 @@ const KOSTNADSFALT = [
   // sa 5,5 minuter om en sonnetkörning som tog omkring 34. Ett `wall_ms` som
   // saknas eller inte är ett tal är omätt, aldrig noll: en nolla skulle läsas
   // som en ögonblicklig körning.
-  ['Väggtid', 'klocka', (m) => (Number.isFinite(m.wall_ms) ? minuter(m.wall_ms) : null)],
+  // #526: väggtiden mättes under samtidig last. Lasten står i korning.json:s
+  // steg (`samtidiga_processer`, maxvärdet över stegen: det är den värsta
+  // trängseln körningen köade bakom); saknas fältet (äldre körningar, eller
+  // en räknare som föll i varje steg) är samtidigheten okänd, inte noll.
+  [
+    'Väggtid',
+    'klocka',
+    (m, k) =>
+      Number.isFinite(m.wall_ms) ? `${minuter(m.wall_ms)} (${samtidighet(k.matning)})` : null,
+  ],
   ['Dispatcher', 'matning', (m) => tal(m.subagent_stats?.spawned)],
+  // #523: nekade verktygsanrop, summan av `permission_denials` över stegen.
+  // Ett steg utan fältet (null, eller äldre korning.json) räknas inte; bär
+  // inget steg fältet är summan omätt, aldrig noll.
+  ['Nekade anrop', 'matning', (m) => nekadeAnrop(m)],
 ]
 
+/** Summan av nekade verktygsanrop över stegen, null när inget steg bär
+ *  fältet. */
+const nekadeAnrop = (matning) => {
+  const tal = (matning?.steg ?? [])
+    .map((s) => s?.permission_denials)
+    .filter((n) => Number.isFinite(n))
+  return tal.length === 0 ? null : String(tal.reduce((a, b) => a + b, 0))
+}
+
 /** Kanoniska modellnycklar i en körnings korning.json, sorterade. Flera
  *  fakturerade nycklar (t.ex. med `[1m]`-suffix eller ett datumstämplat
  *  snapshot-namn) kan kanonisera till samma sträng; unionen dedupar dem. */
@@ -240,6 +262,17 @@ const kostnadPerNyckel = (m) => {
   return ut
 }
 
+/** Maxantalet samtidiga agentprocesser över stegen, som text. Steg med null
+ *  (räknaren föll) räknas inte; utan ett enda tal är samtidigheten okänd. */
+const samtidighet = (matning) => {
+  const tal = (matning?.steg ?? [])
+    .map((s) => s?.samtidiga_processer)
+    .filter((n) => Number.isFinite(n))
+  if (tal.length === 0) return 'okänd samtidighet'
+  const max = Math.max(...tal)
+  return `${max} ${max === 1 ? 'samtidig' : 'samtidiga'}`
+}
+
 const kostnadsrader = (k, nycklar = modellNycklar(k.matning)) =>
   KOSTNADSFALT.flatMap(([namn, källa, hämta]) => {
     // En del är ingen egen process: mätningen kommer ur headless-svaret för
@@ -259,7 +292,9 @@ const kostnadsrader = (k, nycklar = modellNycklar(k.matning)) =>
     // ljuger inte om de andra. Radlistan har ändå alltid samma längd och
     // samma fältnamn, mätt eller omätt.
     const dok = k[källa]
-    const värde = dok ? hämta(dok) : null
+    // Hela körningen följer med som andra argument: Väggtid läser klockan ur
+    // matning.json men samtidigheten ur korning.json:s steg.
+    const värde = dok ? hämta(dok, k) : null
     const rad = [namn, värde === null ? '<em>omätt</em>' : esc(värde)]
     if (namn !== 'USD') return [rad]
     // #494: orkestratorns (hjälpmodellens) kostnad låg förr inbakad i

package/library/global/skills/request/scripts/svep.mjs

@@ -8,10 +8,13 @@
  * (de rena hjälparna exporteras, huvudloopen körs bara när scriptet startas
  * direkt).
  *
- * Två tickets åt gången, varje ticket kör alla valda modeller samtidigt, och
- * nästa ticket startar först när en tickets samtliga modeller är klara
- * (beslut 2026-09-02). `experiment.json` skrivs ALDRIG härifrån direkt, bara
- * via `archive.mjs experiment` (låst läs-modifiera-skriv), så samtidiga varv
+ * Två tickets åt gången, varje ticket kör sina valda modeller med högst
+ * `--modeller-parallellt` (default 4) i flykt, och nästa ticket startar först
+ * när en tickets samtliga modeller är klara (beslut 2026-09-02; modelltaket
+ * #526, ADR-0120: sex agentprocesser per modell utan tak gav en last som
+ * wall_ms mättes under utan att bokföras). `experiment.json` skrivs ALDRIG
+ * härifrån direkt, bara via `archive.mjs experiment` (låst
+ * läs-modifiera-skriv), så samtidiga varv
  * aldrig tappar varandras rader (#493). Övriga arkivsteg (ny-korning,
  * proveniens, sparr) anropas som kommandon av samma skäl som ADR-0094: ett
  * steg som ålägger startaren en skrivning måste peka ut vem som utför den.
@@ -19,8 +22,8 @@
  * Användning:
  *   node svep.mjs --repo-rot <abs> --konto <namn> --modell <m> [--modell <m>]...
  *                 --exp <experiments/<slug>> [--exp ...]...
- *                 [--tickets-parallellt 2] [--om | --hoppa-över]
- *                 [--claude <kommando>]
+ *                 [--tickets-parallellt 2] [--modeller-parallellt 4]
+ *                 [--om | --hoppa-över] [--claude <kommando>]
  *
  * Ett relativt --exp löses mot <repo-rot>/.haus-workflow/requests/. Varje
  * experimentkatalog måste bära onskemal.md, kallmanifest.md och experiment.json
@@ -58,14 +61,27 @@ export const STATUSAR = ['klar', 'ofärdig', 'stopp', 'väntar på dom']
 /** Statusar den inre processen själv får sätta och som startaren behåller. */
 const INRE_BEHALLS = ['stopp', 'väntar på dom', 'ofärdig']
 const STANDARD_TAK = 2
+/** Modeller per ticket i flykt. Fyra täcker det vanliga svepet (opus, sonnet,
+ *  fable plus en till) utan att sex agentprocesser per modell staplas
+ *  obegränsat (#526). */
+const STANDARD_MODELLTAK = 4
 const SIGINT_EXIT = 130
-const VARDEFLAGGOR = ['repo-rot', 'konto', 'modell', 'exp', 'tickets-parallellt', 'claude']
+const VARDEFLAGGOR = [
+  'repo-rot',
+  'konto',
+  'modell',
+  'exp',
+  'tickets-parallellt',
+  'modeller-parallellt',
+  'claude',
+]
 const BOOLFLAGGOR = ['om', 'hoppa-över']
 
 export const ANVANDNING = [
   'användning: svep.mjs --repo-rot <abs> --konto <namn> --modell <m> [--modell <m>]...',
   '                     --exp <experiments/<slug>> [--exp ...]...',
-  `                     [--tickets-parallellt ${STANDARD_TAK}] [--om | --hoppa-över] [--claude <kommando>]`,
+  `                     [--tickets-parallellt ${STANDARD_TAK}] [--modeller-parallellt ${STANDARD_MODELLTAK}]`,
+  '                     [--om | --hoppa-över] [--claude <kommando>]',
 ].join('\n')
 
 // ---------------------------------------------------------------------------
@@ -112,12 +128,17 @@ export function tolkaArgv(argv) {
   const taket = Number(takText)
   if (!/^\d+$/.test(takText) || taket < 1)
     return { fel: `--tickets-parallellt måste vara ett heltal >= 1 (fick "${takText}")` }
+  const modelltakText = enkla['modeller-parallellt'] ?? String(STANDARD_MODELLTAK)
+  const modellerParallellt = Number(modelltakText)
+  if (!/^\d+$/.test(modelltakText) || modellerParallellt < 1)
+    return { fel: `--modeller-parallellt måste vara ett heltal >= 1 (fick "${modelltakText}")` }
   return {
     repoRot: enkla['repo-rot'],
     konto: enkla.konto,
     modeller: listor.modell,
     exps: listor.exp,
     taket,
+    modellerParallellt,
     om: bool.om,
     hoppaOver: bool['hoppa-över'] || !bool.om,
     claude: enkla.claude ?? 'claude',
@@ -174,19 +195,46 @@ export function senasteKorning(experiment, katalognamn) {
     if (!m) continue
     const n = Number(m[1])
     if (basta === null || n > basta.n)
-      basta = { n, nyckel, status: rad?.status ?? null, orsak: rad?.orsak ?? null }
+      basta = {
+        n,
+        nyckel,
+        status: rad?.status ?? null,
+        orsak: rad?.orsak ?? null,
+        // Startarens pid medan körningen pågår (#516); null i slutstatusen
+        // och i äldre filer.
+        pid: Number.isInteger(rad?.pid) ? rad.pid : null,
+      }
   }
   return basta
 }
 
+/** Lever processen? Signal 0 levererar inget men prövar att pid:n finns.
+ *  EPERM betyder att den finns men tillhör någon annan (det andra kontots
+ *  svep, ADR-0093), alltså levande. ESRCH och allt annat är död. */
+export const processLever = (pid) => {
+  try {
+    process.kill(pid, 0)
+    return true
+  } catch (e) {
+    return e?.code === 'EPERM'
+  }
+}
+
 /** Återupptagningsregeln ur SKILL.md:s Batch-avsnitt. `klar` och `stopp` är
  *  resultat värda att skydda: de hoppas utan --om. `ofärdig` är avbruten data
- *  och körs alltid om. `väntar på dom` omvärderas med `archive.mjs sparr`,
- *  svepet är den enda aktören för den statusen. Ingen körning alls
- *  (status undefined) körs. */
-export function aterupptagning(status, { om = false } = {}) {
+ *  och körs om, UTOM när raden bär en pid som lever: då är det ingen avbruten
+ *  körning utan en som pågår i ett annat svep (två konton mot samma checkout,
+ *  ADR-0093), och en omkörning vore en dubblett av en dyr körning (#516). En
+ *  död pid eller ingen pid alls (äldre rad, korning.mjs:s eget avbrott) körs
+ *  om som förut, så #493:s skydd står kvar. `--om` rör inte det: flaggan
+ *  gäller resultat, inte pågående processer. `väntar på dom` omvärderas med
+ *  `archive.mjs sparr`, svepet är den enda aktören för den statusen. Ingen
+ *  körning alls (status undefined) körs. `levande` är injicerbar för
+ *  testerna. */
+export function aterupptagning(status, { om = false, pid = null, levande = processLever } = {}) {
   if (status === 'väntar på dom') return 'prova-sparr'
   if (status === 'klar' || status === 'stopp') return om ? 'kör' : 'hoppa'
+  if (status === 'ofärdig' && pid !== null && levande(pid)) return 'hoppa'
   return 'kör'
 }
 
@@ -355,8 +403,10 @@ function korInre({ claude, gid, modell, katalog, expDir, repoRot, pagaende, nyck
 
 /** #493: en körning som ny-korning skapat men som dör innan slutstatusen
  *  skrivs fanns förr inte i experiment.json alls. Raden skrivs vid start som
- *  ofärdig och skrivs över av slutstatusen; ett fel här är en varning. */
-export function registreraStart({ expDir, nyckel, arkiv: arkivFn }) {
+ *  ofärdig och skrivs över av slutstatusen; ett fel här är en varning. Raden
+ *  bär startarens pid (#516) så ett andra svep ser att körningen pågår;
+ *  slutstatusen skrivs utan --pid och tar bort den. */
+export function registreraStart({ expDir, nyckel, arkiv: arkivFn, pid = process.pid }) {
   const r = arkivFn([
     'experiment',
     expDir,
@@ -366,6 +416,8 @@ export function registreraStart({ expDir, nyckel, arkiv: arkivFn }) {
     'ofärdig',
     '--orsak',
     'startad, inte avslutad',
+    '--pid',
+    String(pid),
   ])
   return { varning: r.status === 0 ? null : `experiment --status ofärdig: ${felText(r)}` }
 }
@@ -499,7 +551,30 @@ function provaSparr({ gid, modell, expDir, repoRot, nyckel, ut }) {
   }
 }
 
-/** En ticket: underlagskontroll, varianter, sedan alla modeller samtidigt. */
+/** Modellerna för en ticket, högst `taket` i flykt (#526): samma
+ *  schemaläggare som tickets, en nivå ner. `korModell(modell)` kastar aldrig
+ *  (korVarv fångar allt), men ett kast landar ändå som en `ofärdig`-rad för
+ *  den modellen i stället för att stoppa de andra. Raderna kommer i
+ *  modellordning. */
+export async function korModeller(modeller, taket, korModell) {
+  const resultat = await schemalagg(modeller, taket, korModell)
+  return resultat.map((r, i) =>
+    r?.fel === undefined
+      ? r
+      : {
+          modell: modeller[i],
+          status: 'ofärdig',
+          orsak: r.fel,
+          korning: null,
+          wall_ms: null,
+          usd: null,
+          varningar: [],
+        },
+  )
+}
+
+/** En ticket: underlagskontroll, varianter, sedan modellerna med högst
+ *  `--modeller-parallellt` i flykt. */
 async function korTicket(exp, val, pagaende, ut) {
   const namn = path.basename(exp)
   const u = kontrolleraUnderlag(exp)
@@ -518,43 +593,60 @@ async function korTicket(exp, val, pagaende, ut) {
     val.repoRot,
   )
   if (va.status !== 0) varningar.push(`experiment --variant: ${felText(va)}`)
-  const rader = await Promise.all(
-    val.modeller.map(async (modell) => {
-      const senaste = senasteKorning(u.experiment, modellKatalog(modell))
-      const beslut = aterupptagning(senaste?.status ?? undefined, { om: val.om })
-      if (beslut === 'hoppa') {
-        ut(`HOPPAR ${u.ticket} ${modell} ${senaste.status} (${senaste.nyckel})`)
-        return {
-          modell,
-          status: senaste.status,
-          orsak: senaste.orsak,
-          korning: senaste.nyckel,
-          wall_ms: null,
-          usd: null,
-          varningar: [],
-        }
+  const rader = await korModeller(val.modeller, val.modellerParallellt, async (modell) => {
+    const senaste = senasteKorning(u.experiment, modellKatalog(modell))
+    const beslut = aterupptagning(senaste?.status ?? undefined, {
+      om: val.om,
+      pid: senaste?.pid ?? null,
+    })
+    if (beslut === 'hoppa' && senaste.status === 'ofärdig') {
+      // #516: körningen pågår i ett annat svep. Raden heter `pågår`, inte
+      // `ofärdig`: tabellen ska inte påstå att den föll.
+      ut(
+        `HOPPAR ${u.ticket} ${modell} pågår i en annan process (pid ${senaste.pid}, ${senaste.nyckel})`,
+      )
+      return {
+        modell,
+        status: 'pågår',
+        orsak: `i en annan process (pid ${senaste.pid})`,
+        korning: senaste.nyckel,
+        wall_ms: null,
+        usd: null,
+        varningar: [],
+      }
+    }
+    if (beslut === 'hoppa') {
+      ut(`HOPPAR ${u.ticket} ${modell} ${senaste.status} (${senaste.nyckel})`)
+      return {
+        modell,
+        status: senaste.status,
+        orsak: senaste.orsak,
+        korning: senaste.nyckel,
+        wall_ms: null,
+        usd: null,
+        varningar: [],
       }
-      if (beslut === 'prova-sparr')
-        return provaSparr({
-          gid: u.ticket,
-          modell,
-          expDir: exp,
-          repoRot: val.repoRot,
-          nyckel: senaste.nyckel,
-          ut,
-        })
-      return korVarv({
+    }
+    if (beslut === 'prova-sparr')
+      return provaSparr({
         gid: u.ticket,
         modell,
         expDir: exp,
         repoRot: val.repoRot,
-        konto: val.konto,
-        claude: val.claude,
-        pagaende,
+        nyckel: senaste.nyckel,
         ut,
       })
-    }),
-  )
+    return korVarv({
+      gid: u.ticket,
+      modell,
+      expDir: exp,
+      repoRot: val.repoRot,
+      konto: val.konto,
+      claude: val.claude,
+      pagaende,
+      ut,
+    })
+  })
   return { ticket: u.ticket, rader, varningar }
 }
 
@@ -619,9 +711,14 @@ async function main(argv) {
   ut('')
   ut(renderaTabell(rader))
   // Saknat underlag är också exit 1: ett svep som tyst hoppar en ticket ser
-  // annars lyckat ut i en loggrad ingen läser.
+  // annars lyckat ut i en loggrad ingen läser. Detsamma gäller `pågår`
+  // (#516): svepet har inget resultat för den raden, det andra svepet har.
   return rader.some(
-    (r) => r.status === 'ofärdig' || r.status === 'fel' || r.status === 'underlag saknas',
+    (r) =>
+      r.status === 'ofärdig' ||
+      r.status === 'fel' ||
+      r.status === 'underlag saknas' ||
+      r.status === 'pågår',
   )
     ? 1
     : 0

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

@@ -141,6 +141,15 @@ Efter etiketten följer fritexten som förut. Flera avvikelser: etiketten är de
 allvarligaste av dem (motsägelse väger över precisering), och varje avvikelse
 får en egen mening.
 
+### Kundens språk
+
+Prompten bär `SPRÅK: svenska | engelska`, kundens språk. Analysen är
+Haus-intern, men delar av den går vidare till kunden genom poängsättaren: det
+preciserade på avvikelseraden blir en förutsättning i förslaget, och
+alternativen under _Obesvarade utfallsval_ blir kundens alternativ. Namnge
+dem i kundens språk ur promptens `SPRÅK:`-rad; i en fristående körning utan
+raden är det specens språk.
+
 ### Beroenden i arbetskopian
 
 Prompten bär `DEPS: installerade | saknas`. Vid `saknas` finns inga
@@ -167,6 +176,10 @@ delarna ovan (alternativen, om de skiljer sig i vad som måste byggas, vilket
 alternativet analysen är skriven utifrån) skrivs på indenterade underrader
 under den punkten, inte som egna listpunkter. Formkontrollen räknar bara
 listpunkter på kolumn 0; en underrad räknas inte som ett eget alternativ.
+Alternativ i löptext ("(a) text i bilden, (b) egen komponent") räknas inte
+alls: formkontrollen fäller `motsägelse` med sådan prosa i avsnittet som en
+brist och varnar vid `precisering`, så skriv listan eller skriv `inga`, aldrig
+en uppräkning i en mening.
 
 **Struket alternativ.** Ett alternativ som inte löser specens _Problem_ raderas inte,
 det stryks: den översta listpunkten (samma nivå som alternativets "- ") börjar med

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

@@ -304,6 +304,12 @@ 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.
 
+**Kundens språk** är, överallt i den här skillen, det promptens `SPRÅK:`-rad anger
+(`svenska` eller `engelska`); i en fristående körning utan raden är det specens språk.
+Det gäller `customer_rationale`, `conditions`, `assumptions_stated`, `alternatives`
+(`label` och `adds`) och `coverage_post.yta`. Kontrollen fäller kundtext på fel språk,
+och en sådan post dispatchas om i sin helhet.
+
 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.

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

@@ -65,7 +65,7 @@ Hämta brädans sektioner. **En sektion:** ingen fråga, använd den. **Flera se
 
 Hämta fälten på båda brädorna och gå igenom tre saker:
 
-- **Finns fälten?** Kundbrädan behöver `Original request`, `Customer`, `Requested by` och kundstatusfältet. Samlingsbrädan behöver dessa plus `Offer status`, `Source`, `Request type`, `Funding`, `Score`, `Conditional classification`, `Decision`, `Decision reason`, `Spec iterations`, `Class iterations`.
+- **Finns fälten?** Kundbrädan behöver `Original request`, `Original request title`, `Customer`, `Requested by` och kundstatusfältet. Samlingsbrädan behöver dessa plus `Offer status`, `Source`, `Request type`, `Funding`, `Score`, `Has conditions`, `Decision`, `Decision reason`, `Spec iterations`, `Score iterations`.
 - **Är de delade fälten samma fält?** Jämför gid, inte namn. Två fält med samma namn och olika gid är en dubblett — de driftar isär omedelbart, och felet syns först hos kunden.
 - **Går alternativen att slå upp?** Normaliserat, enligt regeln ovan. Rapportera vilka som inte gick att matcha och vilka alternativ som faktiskt finns.
 
@@ -116,6 +116,7 @@ Domän-JSON till vänster, fältnamn till höger. Ingen annan skill får se hög
 | --------------------------- | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- |
 | `request_id`                | task gid                                                     | —                                                                                                                     |
 | `original_request`          | Original request + beskrivningens `## Ursprunglig förfrågan` | Skrivs en gång. Ändras aldrig, inte ens för stavfel                                                                   |
+| `original_request_title`    | Original request title                                       | Skrivs en gång. Ändras aldrig, inte ens för stavfel. Tomt när kunden aldrig skrev en rubrik                           |
 | `source`                    | Source                                                       | Kunden skrev själv · Mejl · Möte · Haus initierade                                                                    |
 | `customer`                  | Customer                                                     |                                                                                                                       |
 | `requested_by`              | Requested by                                                 | people-fält, kräver user gid                                                                                          |
@@ -130,7 +131,7 @@ Domän-JSON till vänster, fältnamn till höger. Ingen annan skill får se hög
 | `customer_rationale`        | beskrivningens `## Lösning och omfattning`                   | Låst efter `Decision`, se nedan                                                                                       |
 | `assumptions_stated` ej tom | beskrivningens `## Lösning och omfattning`                   | Kunden godkänner dem med priset                                                                                       |
 | `alternatives` ej tom       | beskrivningens `## Lösning och omfattning`                   | Egna vägar med var sitt pris                                                                                          |
-| `conditions` ej tom         | Conditional classification                                   | se nedan                                                                                                              |
+| `conditions` ej tom         | Has conditions                                               | se nedan                                                                                                              |
 | `decision`                  | Decision                                                     | Beställd · Ej beställd · Uppskjuten                                                                                   |
 | `decision_reason`           | Decision reason                                              |                                                                                                                       |
 
@@ -139,16 +140,15 @@ där kunden faktiskt läser den. Att skriva samma text på två ställen gav tv
 som kunde glida isär, och fältet fanns bara för att kunna filtrera på en text ingen
 filtrerar på. Fältet får ligga kvar i Asana med sina gamla värden som historik.
 
-**Två fältnamn är historiska.** `Class iterations` och `Conditional classification`
-döptes när modellen satte klasser i stället för poäng. Innehållet är oförändrat i sak —
-en varvräknare och en ja/nej-flagga för villkor — så de används vidare under sina gamla
-namn hellre än att data flyttas. Döps de om i Asana måste den här mappningen uppdateras
-samtidigt.
+**Fältnamnen byttes 2026-09-08 (ADR-0121):** `Score iterations` hette `Class iterations`
+och `Has conditions` hette `Conditional classification`. Innehållet är oförändrat i sak,
+en räknare över poängsättningsvarv och en ja/nej-flagga för villkor. En bräda som
+fortfarande bär de gamla namnen är inte uppdaterad: säg till i stället för att gissa.
 
 `Score` är ett taltfält. Skriv poängen som tal, inte som text, så att den går att
 sortera och summera i listvyer.
 
-`Conditional classification` är härledd: villkorslistan är tom eller inte. Sätt alltid ett värde när en poängsättning skrivs — aldrig tomt, eftersom tomt är reserverat för "ingen har poängsatt än". Bär fältet flera värden samtidigt är det felkonfigurerat som flerval; skriv ett värde och säg till.
+`Has conditions` är härledd: villkorslistan är tom eller inte. Sätt alltid ett värde när en poängsättning skrivs — aldrig tomt, eftersom tomt är reserverat för "ingen har poängsatt än". Bär fältet flera värden samtidigt är det felkonfigurerat som flerval; skriv ett värde och säg till.
 
 Asana konverterar markdown till `html_notes`. Använd `html_notes` för beskrivningen, för subtaskarnas innehåll och för kommentarer, inte `notes`, annars tappas struktur — rubriker, kursiv text och de vågräta linjerna mellan sektionerna försvinner alla med `notes`.
 
@@ -217,7 +217,7 @@ körningen gjordes.
 
 Skälet: en poäng som stiger är en prishöjning. Sker den genom att beskrivningen skrivs om finns inget spår av vad kunden faktiskt godkände, och den fria exiten — modellens centrala kundlöfte — går inte att lösa ut, eftersom det inte längre går att visa vad som ändrats.
 
-Låset gäller beskrivningen och `Score`, som bär den poäng priset räknades ur. Det som är internt får alltid skrivas — subtaskarna (det är hela poängen med dem: de är löpnumrerade och ärver inte kundbrädan, så en poängsättning efter kundbeslut landar där som vanligt), `Conditional classification` och räknarna.
+Låset gäller beskrivningen och `Score`, som bär den poäng priset räknades ur. Det som är internt får alltid skrivas — subtaskarna (det är hela poängen med dem: de är löpnumrerade och ärver inte kundbrädan, så en poängsättning efter kundbeslut landar där som vanligt), `Has conditions` och räknarna.
 
 ### Grindläget stöds inte
 
@@ -334,13 +334,14 @@ Ursprunget avgör vad du gör, och det avgör också hur underlaget ska tolkas s
 
 ### Kunden skrev själv på sin bräda
 
-Kundens ord ligger i beskrivningen, och beskrivningen ska sedan skrivas om till sektionsform. Det är den **enda destruktiva operationen i hela flödet**, och ordningen är inte förhandlingsbar:
+Kundens ord ligger i beskrivningen och i task name, och båda skrivs över senare: beskrivningen görs om till sektionsform, namnet byts till det förändrade tillståndet när specen skrivs. Det är de **enda destruktiva operationerna i hela flödet**, och ordningen är inte förhandlingsbar:
 
-1. Kopiera beskrivningen ordagrant till `Original request`
-2. **Läs tillbaka fältet och verifiera att texten landat**
-3. Först då skriv om beskrivningen — samma text ordagrant under `## Ursprunglig förfrågan`, specen under `## Specifikation`
+1. Kopiera beskrivningen ordagrant till `Original request` och task name ordagrant till `Original request title`
+2. **Läs tillbaka båda fälten och verifiera att texten landat**
+3. Först då skriv om beskrivningen, samma text ordagrant under `## Ursprunglig förfrågan`, specen under `## Specifikation`
+4. **Byt aldrig task name innan `Original request title` är skrivet och läst tillbaka.** Namnbytet sker när specen skrivs, ofta i en senare körning, och då finns kundens rubrik bara i det fältet
 
-Hoppar du över steg 2 och skrivningen tyst misslyckas är kundens egna ord borta för alltid — vilket är precis det `Original request` finns för att förhindra. `Source` = kunden skrev själv.
+Hoppar du över steg 2 och skrivningen tyst misslyckas är kundens egna ord borta för alltid — vilket är precis det `Original request` finns för att förhindra, och ett namnbyte utan steg 4 gör samma sak med rubriken. `Source` = kunden skrev själv.
 
 ### Mejl, möte eller annat underlag
 
@@ -348,6 +349,8 @@ Här skapar agenten både task och spec i ett svep, och kundens ord ligger kvar
 
 **Klistra in det relevanta stycket ur mejlet eller anteckningen ordagrant** i `Original request` och under `## Ursprunglig förfrågan` i beskrivningen — inte en sammanfattning, inte en parafras. Risken för glid är störst just här, eftersom underlaget är råare och agenten tolkat mer.
 
+**Rubriken** är mejlets ärenderad eller anteckningens egen rubrik, ordagrant, i `Original request title`. Skrev kunden aldrig någon rubrik lämnas fältet tomt. En rubrik vi formulerat själva ser i granskningen ut som kundens ord, och ett fält som blandar de två är sämre än ett tomt.
+
 Blir det flera requests ur samma underlag får var och en **sitt eget relevanta stycke**, inte hela mejlet klistrat en gång per post. Ett fält som innehåller allt håller ingenting.
 
 `Source` = mejl eller möte. Statusarna sätts enligt skapandesekvensen nedan. Notera bara att en task inte får hamna i ett granskningsläge utan att specen faktiskt är skriven — en tom task i granskningskön ser ut som ett fel i skillen när det är ett fel i regeln.
@@ -361,9 +364,10 @@ Kundbrädan bär bara det kunden ska se. Interna fält finns enbart på samlings
 | Bara samlingsbrädan                | Delade, syns på båda                       |
 | ---------------------------------- | ------------------------------------------ |
 | Offer status · Source              | Kundstatus                                 |
-| Spec iterations · Class iterations | Original request · Customer · Requested by |
-| Conditional classification         | Request type · Funding                     |
+| Spec iterations · Score iterations | Original request · Customer · Requested by |
+| Has conditions                     | Request type · Funding                     |
 |                                    | Score · Decision · Decision reason         |
+|                                    | Original request title                     |
 
 Ett delat fält är **samma** fält på båda brädorna. Finns två fält med samma namn och olika gid är det en dubblett, inte en delning — de driftar isär omedelbart och felet syns först när en kund tittar på något som inte uppdaterats. Upptäcker du en sådan: skriv inte till någon av dem, säg till.
 
@@ -371,7 +375,7 @@ Ett delat fält är **samma** fält på båda brädorna. Finns två fält med sa
 
 Ordningen spelar roll, eftersom de interna fälten inte existerar på kundbrädan.
 
-**1 — Skapa på kundbrädan** med det som finns där: task name, `Original request`, `Customer`, `Requested by`. Lägg tasken i rätt sektion (se nedan), och **sätt `Request status` redan här**, explicit:
+**1 — Skapa på kundbrädan** med det som finns där: task name, `Original request`, `Original request title`, `Customer`, `Requested by`. Lägg tasken i rätt sektion (se nedan), och **sätt `Request status` redan här**, explicit:
 
 | Läge vid skapandet                   | Request status  |
 | ------------------------------------ | --------------- |
@@ -395,7 +399,7 @@ Försöker du sätta `Offer status` eller `Source` i steg 1 avbryter uppslagning
 
 Efter skapandet rör du aldrig `Request status` igen. Då härleds den av Asana-regeln ur `Offer status`.
 
-Task name ska vara det förändrade tillståndet, inte uppgiften, samma regel som specrubriken. Finns ingen spec än: använd önskemålets egna ord, och byt namn när specen skrivs.
+Task name ska vara det förändrade tillståndet, inte uppgiften, samma regel som specrubriken. Finns ingen spec än: använd önskemålets egna ord, och byt namn när specen skrivs. Men namnbytet förutsätter att `Original request title` bär den ursprungliga rubriken och att den är läst tillbaka, se _Kunden skrev själv på sin bräda_.
 
 ### Sektion på kundbrädan
 
@@ -428,7 +432,7 @@ Skälet: `Request status` är det enda i hela flödet en kund ser. Två fält so
 
 Feedback är en kommentar plus en flytt bakåt till närmaste AI-läge. Två regler:
 
-**Bumpa räknaren.** Bakåt till 📥 höjer `Spec iterations`. Bakåt till ✅ höjer `Class iterations` (fältets namn är historiskt; det räknar poängsättningsvarv). Läs nuvarande värde och skriv värdet plus ett — sätt aldrig ett absolut tal från minnet.
+**Bumpa räknaren.** Bakåt till 📥 höjer `Spec iterations`. Bakåt till ✅ höjer `Score iterations` (räknar poängsättningsvarv). Läs nuvarande värde och skriv värdet plus ett — sätt aldrig ett absolut tal från minnet.
 
 **Ändrad spec ogiltigförklarar poängsättningen.** Går en post bakåt till 📥 ska den passera ⚖️ igen på vägen tillbaka. Skriv inte över `Score` med ett nytt värde utan att posten gjort den resan.
 

package/library/global/skills/request-write-spec/SKILL.md

@@ -68,6 +68,8 @@ Det är hela inputen. Ditt jobb är beredningen — att växa en spec ur den. En
 
 **Leta innan du antar.** Inventera vad sessionen ger dig tillgång till och använd det. Vilka källor som finns beror på uppdraget: i ett befintligt system är kodbasen bäst (finns vyn redan? vilket mönster används för liknande listor? vad heter begreppen i koden?), följt av tidigare specar och tickets för samma kund (hur har liknande poster lösts? vilka termer använder kunden — "skattning", "skift", "verksamhet"?). I ett nytt projekt finns ingen kodbas — då är briefen, offertunderlaget eller annat projektmaterial källan, och lösningen förankras i vad det materialet säger om målgrupp, flöden och befintliga system hos kunden. Det du hittar i källorna är inte antaganden — det är fakta, och de gör specen träffsäker på riktigt. Först när en fråga inte går att besvara ur det som finns blir den ett antagande i granskarblocket. Skriv gärna i granskarblocket _var_ du hämtat de viktigaste faktana ("mönstret finns i användarhanteringsvyn", "enligt briefen sid 2") — det låter granskaren skilja verifierat från gissat på en sekund.
 
+**Leta efter det som redan finns innan du skriver Lösning.** Sök i källmanifestet (`KÄLLOR:`) och med Grep i repot efter en inbyggd funktion i plattformen eller ett redan installerat paket som gör det önskemålet ber om: en väljare, en meny, en export, en behörighetsmodell som redan finns. Redovisa fyndet i granskarblocket under _Vägval jag gjort_ eller _Prisavgörande öppet val_, även när du inte hittade något ("ingen inbyggd yta för X funnen i KÄLLOR eller repot"). Det du inte letat efter kan du inte välja bort medvetet, och ett omedvetet egenbygge är det dyraste valet specen kan göra åt kunden (se regeln under Output).
+
 Sedan gäller för själva skrivandet:
 
 **Härled problemet ur önskemålet.** "Kan själv lägga till" betyder att någon idag inte kan själv — det görs via Haus eller inte alls. Det är problemraden. Du behöver inte veta detaljerna; skriv den mest sannolika vardagen och redovisa den som antagande om du är osäker.
@@ -101,7 +103,7 @@ Skriv varje spec som ett eget block, exakt enligt formatet. Efter VARJE spec: et
 **Antaganden:** [tolkningar av otydligt underlag, en rad var — "tom" om inga]
 **Vägval jag gjort:** [beslut du fattat på eget bevåg + en rads motivering — märk ut de som rör vad användaren får, de är specbeslut och det är dem granskaren måste titta på]
 **Öppna utfallsval:** [frågor om vad användaren får som inte gick att avgöra ur underlaget — "inga" om inga. Rena byggbeslut hör inte hit]
-**Prisavgörande öppet val:** [nej · eller "ja: <valet i en mening, i kundens språk>" när alternativen skiljer sig i vad som måste byggas och du inte kan välja ett utan att gissa kundens avsikt. Ett ja stoppar posten före analys tills valet är avgjort; ett val som redan står under "Avgjorda val" i KÄLLOR flaggas aldrig]
+**Prisavgörande öppet val:** [nej · eller "ja: <valet i en mening, i kundens språk>" när alternativen skiljer sig i vad som måste byggas och du inte kan välja ett utan att gissa kundens avsikt. Inbyggd funktion kontra egenbygge är ALLTID ett ja med båda alternativen namngivna, se nedan. Ett ja stoppar posten före analys tills valet är avgjort; ett val som redan står under "Avgjorda val" i KÄLLOR flaggas aldrig]
 **Flaggor:** [Koncept-/Diagnos-kandidat med skäl (specen själv bär markörraden, det här är granskarens sammanfattning) · misstänkt bunt/beroende till annan post · sådant som ser ut att röra behörighet, betalning, oåterkallelig data eller personuppgifter]
 **Struket ur underlaget:** [tidsord, belopp, interna anteckningar som inte hör hemma i spec]
 ```
@@ -114,6 +116,8 @@ De två vägvalsraderna är åtskilda för att de kräver olika sak av granskare
 
 Prisavgörande öppet val är det enda i granskarblocket som stoppar posten. Vanliga öppna utfallsval löses av poängsättarens fyrstegsregel; den här raden är för valet där två alternativ ger två olika priser och bara kunden kan välja.
 
+**Egen lösning kontra plattformsfunktion.** Finns i källmanifestet, eller i din egen sökning i repot, en inbyggd funktion i plattformen eller ett redan installerat paket som täcker önskemålet, och du väljer att bygga en egen yta i stället, eller tvärtom väljer bort en fungerande inbyggd yta för en egen, är det ALLTID `Prisavgörande öppet val: ja` med båda alternativen namngivna (inbyggd funktion respektive egenbygge), aldrig ett Vägval jag gjort. Skillnaden i pris mellan de två är som störst just där, och bara kunden kan välja. Ett egenbygge som inte ens nämner den inbyggda ytan ser ut som det enda sättet, och kunden betalar tre gånger priset utan att ha valt det.
+
 ## Exempel i korthet
 
 Rått önskemål: _"Som chef vill jag själv kunna radera en skattning så att olämpligt innehåll kan tas bort direkt utan att ringa Haus."_

package/package.json

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