@haus-tech/haus-workflow 5.0.0 → 5.0.1

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

@@ -65,7 +65,7 @@ respektive skill. Här bor bara routing, kontextbärande, arkivet och dispatchen
 - **Experimentdata når aldrig Asana.** `utvärdera` skriver aldrig via
   request-sync; dess enda Asana-kontakt är läsande hämtning av önskemålet i
   huvudkonversationen. `experiments/`-trädet är inte postkataloger: sync,
-  batch och guard läser bara `.haus/requests/<gid-eller-slug>/` på toppnivån
+  batch och guard läser bara `.haus-workflow/requests/<gid-eller-slug>/` på toppnivån
   och rör aldrig `experiments/`.
 - **Maskinen kör om enbart vid scriptbevisat kontraktsbrott.** Omdispatch
   (budget EN per agent) svarar på ett fel som precheck, resolve-anchors eller
@@ -74,7 +74,7 @@ respektive skill. Här bor bara routing, kontextbärande, arkivet och dispatchen
   maskinkörningar producerar fler röster, aldrig mer sanning. Ingen ny
   omkörningsmekanism får läggas till som bryter mot detta.
 
-## Arkivet: `.haus/requests/`
+## Arkivet: `.haus-workflow/requests/`
 
 Orkestreringens kuvert. De haus-hanterade request-skillsen känner inte till det;
 den här skillen (och agenterna via sina prompter) underhåller det.
@@ -84,7 +84,7 @@ samma önskemål) blir flera kataloger — poängen sätts per post, så en kata
 med flera specar går inte att bedöma.
 
 ```
-<repo-rot>/.haus/requests/<gid-eller-slug>/
+<repo-rot>/.haus-workflow/requests/<gid-eller-slug>/
 ├── spec.md                        EN spec, bytetrogen — det granskaren godkänner
 ├── granskarblock.md               "## Till granskaren" (bunt: samma block
 │                                  kopieras till varje delkatalog)
@@ -109,10 +109,15 @@ omdispatch-regeln i dispatch-kontraktet.
 - Katalognamn: Asana-gid när posten finns på brädan, annars en kebab-slug av
   spec-rubriken. Bunt utan gid: `<slug>-1`, `<slug>-2`, … När gid myntas senare:
   döp om katalogen till gid och notera sluggen i `state.json.former_slug`.
-- **Första gången arkivet skapas i ett repo:** säkerställ att `.haus/requests/`
-  står i repots `.gitignore` (lägg till raden om den saknas, säg det).
-  Prisunderlag ska inte in i kundens historik. `.haus/request.json` (syncens
-  config) förblir spårad.
+- **Gitignore ägs av haus, inte av dig.** `.haus-workflow/requests/` står i den
+  haus-hanterade `.gitignore`-blocken och skrivs av `haus apply` — lägg aldrig till
+  raden själv, och hand-editera aldrig blocket. Står arkivet ändå spårat i git:
+  kör `haus apply --write`, som både skriver regeln och avspårar filerna.
+  Prisunderlag ska inte in i kundens historik. `.haus-workflow/request.json` (syncens
+  config) förblir spårad — den är konfiguration, inte arbetsmaterial.
+- **Gammalt arkiv under `.haus/`:** flyttas av `haus apply` till
+  `.haus-workflow/` (ADR-0103). Skriv aldrig till `.haus/` igen, och flytta inte
+  själv — kör `haus apply --write` och låt kommandot göra det.
 
 ### `state.json`
 
@@ -215,7 +220,7 @@ omdispatch-regeln i dispatch-kontraktet.
 Modellkörningar från `utvärdera` bor i ett eget träd och är aldrig prisposter:
 
 ```
-<repo-rot>/.haus/requests/experiments/<slug>/
+<repo-rot>/.haus-workflow/requests/experiments/<slug>/
 ├── experiment.json          ticketreferens, datum, modellista, manifest-hash,
 │                            status per körning
 ├── <modell>/                `default` som modellvärde ger katalognamnet
@@ -255,7 +260,7 @@ Modellkörningar från `utvärdera` bor i ett eget träd och är aldrig prispost
   skrivs exakt så, mellanslag och diakritiska tecken inkluderade. Äldre filer
   med `baselinemodell` och `kandidatmodell` läses utan fel; nya skrivningar
   använder bara `varianter`.
-- `experiments/` ärver gitignore-skyddet från `.haus/requests/`.
+- `experiments/` ärver gitignore-skyddet från `.haus-workflow/requests/`.
 
 ## Uppgift: `speca`
 
@@ -325,7 +330,7 @@ driftvakt.
      Endast `✅ Spec ok` (normaliserad på alfabetiska kärnan) släpper igenom.
      Annan status: visa den och stanna. En inklistrad spec för en post som har
      gid räknas inte — det är brädstatusen som gäller, läs den ändå.
-   - **Posten saknar gid MEN repot har `.haus/request.json`:** vägra — repot är
+   - **Posten saknar gid MEN repot har `.haus-workflow/request.json`:** vägra — repot är
      kopplat till en bräda, så en gid-lös post ska in via intaget och granskas
      där, inte prissättas vid sidan av. Grinden är värd något bara om den inte
      går att kliva runt.
@@ -851,7 +856,7 @@ runt `claude -p`-anropet och skriver `matning.json`, och den kör
   ticket. `/clear` mellan tickets behövs inte — processgränsen är
   motsvarigheten. Headless-körningen förutsätter att uppgiften kan köra utan
   interaktiva permission-frågor, vilket håller: den läser repot och skriver
-  enbart under `.haus/requests/` — plus EN läsande Asana-hämtning per ticket
+  enbart under `.haus-workflow/requests/` — plus EN läsande Asana-hämtning per ticket
   (steg 1), så MCP-behörigheten för läsning måste täcka headless-körning.
 - **Kör vidare vid fel.** En ticket vars gid inte går att hämta eller vars
   process kraschar noteras i sammanfattningen; resten av listan fortsätter.

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

@@ -17,7 +17,7 @@ Skapa aldrig en request direkt på samlingsbrädan. En request som föds där sy
 
 ## Sessionsstart
 
-Läs `.haus/request.json` i repo-roten:
+Läs `.haus-workflow/request.json` i repo-roten:
 
 ```json
 {
@@ -39,7 +39,7 @@ Brädnamn är inte unika och flera brädor kan höra till samma kund. Använd al
 
 ## Uppsättning
 
-Kör den här när `.haus/request.json` saknas, och när användaren ber om det — "sätt upp", "koppla repot", "kör uppsättningen igen". Ett steg i taget, med användarens svar emellan. Fråga aldrig allt på en gång.
+Kör den här när `.haus-workflow/request.json` saknas, och när användaren ber om det — "sätt upp", "koppla repot", "kör uppsättningen igen". Ett steg i taget, med användarens svar emellan. Fråga aldrig allt på en gång.
 
 **1 — Var är repo-roten?**
 
@@ -399,7 +399,7 @@ Task name ska vara det förändrade tillståndet, inte uppgiften, samma regel so
 
 ### Sektion på kundbrädan
 
-- **Finns `customer_section` i konfigurationen:** använd den, men verifiera först att sektionen fortfarande finns på brädan — sektioner byter namn och tas bort. Är den borta: fråga vilken som gäller nu och uppdatera `.haus/request.json`.
+- **Finns `customer_section` i konfigurationen:** använd den, men verifiera först att sektionen fortfarande finns på brädan — sektioner byter namn och tas bort. Är den borta: fråga vilken som gäller nu och uppdatera `.haus-workflow/request.json`.
 - **Saknas `customer_section` och brädan har flera sektioner:** fråga **en gång** och använd svaret för hela omgången. Skapar du tio tasks ur ett mejl ska du inte fråga tio gånger. Erbjud att spara svaret i konfigurationsfilen så frågan inte återkommer.
 - **Har brädan bara en sektion:** fråga inte.
 - **Spänner omgången flera sektioner** — ett mejl innehåller ofta önskemål som hör till olika projekt — gissa inte utifrån innehållet. Fråga en gång om alla ska till samma sektion, och be om fördelningen om svaret är nej.

package/package.json

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