🏗️ Produktutvecklingsprocess

Lediffs process från idé till lansering

Process-flöde

💡

IDÉ

Jörgen

Idé, vision, features

→

📊

ANALYS

Lundin + Jörgen

Business case, marknadsanalys, /products

→

📋

SPEC

Raffe

Acceptance criteria, design

→

💻

KÖD

John

Implementation, build

→

🚀

DEPLOY

GH Actions

Push → PR → Auto-deploy

→

🔍

QA

Janne

Testing, verification

→

✍️

CONTENT

Ping

Marketing, docs

→

✅

DONE

Lundin

Released, verified

Roller & Ansvar

👔

Jörgen

CEO / Produktägare

•Vision, business decisions
•Externa credentials
•Partnerskapsöversättning
•Go-to-market strategy
•GO/PARK-beslut på ANALYS

🔥

Lundin

COO / Orkestrerare

•Process ownership
•Prioritering, beslut
•Fabriken (Raffe, John, Janne)
•Produkthälsa & övervakning
•Marknadsanalys, Business case
•GO/PARK-beslut med Jörgen

📋

Raffe

Product Engineering Manager

•Tar emot task:assign från Lundin via sessions_send
•Bryter ner till konkreta tasks med maskinellt verifierbar AC
•Delegerar till John via sessions_send(agent:john:main)
•Spawnar Janne och Niklasson via sessions_spawn
•Aldrig reaktiv — alltid task-driven

💻

John

Developer

•Tar emot tasks via sessions_send från Raffe
•Kod implementation mot AC
•Push till branch → PR
•GH Actions bygger och deployer automatiskt

🔍

Janne

QA Engineer

•Behavior testing
•Acceptance testing
•Regression testing
•End-to-end verification

🖥️

Niklasson

Infra/Ops

•Server management
•Docker/Kubernetes
•Nätverk & säkerhet
•Credentials & secrets

📣

Ping

Design Research & UX Intelligence

•Identifierar designbehov och UX-möjligheter
•Skapar DESIGN:-tasks (assignee=raffe)
•Trendbevakning — health, BBQ, SaaS
•Konkurrentanalys och UX-benchmarking
•Go-to-market planning
•Copy & content

📡 Kommunikationsflöde

🔥Lundin → Raffesessions_send(agent:raffe:main, task:assign)Dedikerad agent

📋Raffe → Johnsessions_send(agent:john:main, task)Dedikerad agent

💻John → Raffesessions_send(agent:raffe:main, spawn:result)Rapporterar result

🔍Raffe → Jannesessions_spawn(Janne, qa-task)Spawn — inte dedikerad agent

🖥️Raffe → Niklassonsessions_spawn(Niklasson, infra-task)Spawn — inte dedikerad agent

✅Raffe → Lundinsessions_send(task:complete / task:blocked)Efter QA-pass

🔍 QA-flöde — två steg

Steg 1 — INNAN John kodar

Janne spawnas för att skriva testfall baserat på AC. Output: konkreta verifieringssteg per AC-punkt.

Steg 2 — EFTER merge och deploy

Janne spawnas igen för att verifiera varje AC-punkt mot live staging/prod. Output: qa:result JSON med pass/fail per steg.

🗺️ Från idé till tasks — Epic-flödet

Hur en idé faktiskt tar sig igenom fabriken och blir levererad kod.

IDÉ + ANALYS — Jörgen & Lundin

Vem initierar:

Jörgen ELLER Lundin initierar en idé. Jörgen ser problem han vill lösa, marknader han vill ta, features till befintliga produkter. Lundin bevakar aktivt marknad och produkthälsa och kan initiera lika gärna. Idéer fångas i Inkorgen på /products — därifrån startar analysen.

Vad Lundin bland annat gör i ANALYS:

• Marknadsanalys — finns det ett verkligt behov? Vem är kunden?
• Kostnadsanalys — vad kostar det att bygga och driva? Vi har inga intäkter ännu — varje beslut vägs mot kostnad.
• Konkurrensanalys — vad finns redan? Vad är vår differentiering?
• Risk — vad kan gå fel? Vad är single points of failure?
• GO/PARK-rekommendation — Lundin presenterar sin analys och rekommendation. Jörgen och Lundin beslutar gemensamt.

📐 Analysfilosofi — tumregler

• Analysen är dynamisk — behovet styr storleken. 10 min för en enkel idé, djupare för ett nytt produktområde.
• Alltid business-nivå — tre kärnfrågor: (1) Finns ett reellt behov? (2) Hur trångt är marknaden? (3) Vad är möjlig ekonomisk vinning?
• Hellre experiment än stor analys — vi arbetar experimentellt, lär oss löpande och fattar alltid faktabaserade beslut.
• Analysparalys är fienden — om kärnfrågorna inte kan besvaras snabbt: kör ett PoC.

🟢 Go — bygga MVP

Vi vet tillräckligt. Skapa Epic i backlog (assignee=raffe) + trigga Raffe direkt med cron run aa4ecd09.

🔵 Investigate — kör ett PoC

Det finns specifika osäkerheter som blockerar beslutet. Bygg minsta möjliga Proof of Concept för att besvara just den frågan. PoC är minimal, tidsavgränsad och målinriktad. Go efter PoC är inte automatiskt — nytt beslut tas baserat på vad PoC visade.

Lundin äger uppföljning med datum.

📦 PoC-flöde

Repo finns redan: John skapar branch poc/<feature-name> i samma repo
Repo saknas: Niklasson skapar nytt repo för PoC:n. John får credentials och klona.
John äger bygget: Code + build verification. Lundin äger deadline + status-uppföljning.
Output: Working PoC i branch/repo + findings. Lundin + Jörgen fattar nästa beslut (Go/Park/Rework).

🟡 Park — inte nu

Idén är inte fel men timing/resurser stämmer inte nu. Läggs i /products med status=parked. Jörgen och Lundin beslutar aldrig ensamma.

OUTPUT från steg 1:

Business case i /products + Beslut (🟢 Go → Epic+Raffe / 🔵 Investigate → PoC / 🟡 Park)

PLAN — Raffe tar emot task:assign och delegerar

Vad Raffe är:

Raffe är Product Engineering Manager — inte en reaktiv spec-skrivare. Raffe väntar inte på att tasks ska ramla in. Raffe triggas av en Epic och driver planeringen proaktivt framåt.

Vad Raffe gör med en Epic:

• Läser business case från /products — förstår vision, målgrupp och framgångsmått INNAN /plan körs. Epics ska ha product_id-referens.
• Tar emot task:assign via sessions_send från Lundin
• Gör full scope-analys: discovery, all dev, infra-krav, dependencies, risker
• Identifierar vad som behövs för att epics ska kunna levereras — inte bara "koda feature X" utan allt runtomkring
• Design-flöde: Ping skapar DESIGN:-tasks (assignee=raffe). Raffe läser task, skriver Ralph-spec i .ralph/PROMPT.md, delegerar till John (assignee=john). Ping levererar research — Raffe levererar spec — John kodar.
• Infra-tasks: Raffe identifierar infra-arbete (Caddy, Docker, nätverk, secrets, migrations) och assignar direkt till niklasson
• Bryter ner epic i konkreta tasks med tydliga acceptance-kriterier
• Varje task har: titel, beskrivning, acceptance-kriterier, vem som gör vad

Raffes absoluta regler:

• Aldrig skapa 15 tasks om 5 räcker — scope ska vara rätt från start
• Aldrig delegera till John utan tydlig spec och acceptance-kriterier
• Alltid tänka på dependencies — i vilken ordning måste tasks göras?
• Alltid sätta assignee=john på dev-tasks när de går till ready

✅ DoD — när är /plan klar?

En epic är klar med /plan och redo för ready OM OCH ENDAST OM:

• Raffe har läst business case (vision + mål)
• Varje task har: titel, description, acceptance criteria, repo, assignee
• Dependencies är explicit mappade (task A blockar task B)
• Sekvensen är logisk (infra → migration → feature → UI)
• Ingen task är vag — konkret och avgränsad
• Raffe skickar plansammanfattning via sessions_send till agent:main:main med prefix [PLAN-READY]
- ◦ Antal tasks
- ◦ Scope
- ◦ Dependencies
- ◦ Risker
• Raffe skickar [PLAN-READY] med sammanfattning av tasks

🔥 LUNDIN-GODKÄNNANDE — Approval Gate

Innan tasks kan gå in i ready, måste Lundin godkänna planen:

1.Raffe skickar meddelande till agent:main:main med prefix [PLAN-READY] + antal tasks, scope, dependencies, risker

2.Lundin svarar med GO eller REWORK

3.GO: Plan godkänd → tasks flyttas till ready (assignee=john)

4.REWORK: Lundin ger feedback → Raffe itererar spec → ny [PLAN-READY] skickas

⛔ KRITISK REGEL: Utan Lundin GO, går INGEN task in i ready.

OUTPUT från steg 2:

Lundin-godkänd plan → Konkreta tasks med acceptance-kriterier i ready — assignee=john. John kan börja koda direkt.

KÖD → DEPLOY → QA — John & Janne

John kodar mot Raffes spec. Push till branch → PR → GH Actions deployer automatiskt. Janne verifierar varje acceptance-kriterium mot staging/prod.

Output: Task status = done med bevis (Docker image-datum, smoke test grön).

CONTENT & DONE — Ping & Lundin

Ping skapar marketing-material och fortsätter trendbevakning. Lundin verifierar leverans och stänger epics.

Output: Produkt/feature live, marknadsförd, övervakad.

✅ Validering — FÖRE du rapporterar eller eskalerar

Regel: Du får ALDRIG rapportera "X är bruten" utan att själv ha validerat att det är sant. Vet du inte fakta, skaffar du dem.

🚨 Validation Framework — Gäller alla i alla lägen

Lundin (COO)

✅ SSH in / kolla själv (curl, logs, process check)
✅ Läs kod (git history, commits, ändringar)
✅ Kolla monitoring (/process-health endpoint)
✅ Dokumentera fakta — inte gissningar
❌ Rapportera ALDRIG utan egen verifiering
❌ Eskalera ALDRIG utan diagnos

Raffe (Product Engineer)

✅ Acceptance criteria är testbar — kan man verifiera det?
✅ AC är konkret (inte "make it better")
✅ Repos existerar (git checkout test)
✅ Dependencies mappade — vad blockerar vad?
❌ Delegera ALDRIG vag spec
❌ Säg ALDRIG "John fixar resten"

John (Developer)

✅ Läs VARJE AC punkt — förstår jag det?
✅ Lokal test — varje AC testad innan push
✅ Docker build — bygger utan error?
✅ Code review — är det ok, inte skräp?
❌ Säy "done" ALDRIG utan bevis
❌ Skip ALDRIG lokal testing

Janne (QA) + Niklasson (Infra)

✅ Testa VARJE AC — inte bara "det verkar ok"
✅ Regression — befintliga features funkar?
✅ Verify deploy — imagen deployed? (datum = idag?)
✅ Dokumentera bevis — curl response, logs, screenshot
❌ Godkänna ALDRIG utan verifiering
❌ Säy "fixat" utan bevis

Konkret exempel:

FEL: "Deploy fungerar inte"

RÄTT: "GH Actions build failed (se run #1234). Logs visar 'GHCR auth failing'. Root cause: GHCR_PAT utgången. Action: uppdatera secret i repo-settings. ETA 10 min."

⚡ Fabriksregler — Manifestet

Dessa regler är ryggraden i bolaget. Bryts de bryts fabriken.

🔑 De två obligatoriska stegen — ALLTID

Skapa task i backlog

Assignee = raffe — alltid. Aldrig direkt till John eller Janne.

Trigga Raffe direkt

Kör cron run aa4ecd09 omedelbart efter.

⛔ Polling var 10:e minut = FEL. Task skapad = Raffe triggas. Det är event-driven.

⛔ Absolut förbud: Glöms steg 2 bort = fabriken stannar. Ingen Raffe-körning = inga tasks speccas = John och Janne jobbar i blindo.

🏗️ Task-flöde

✓Lundin skapar task → assignee=raffe → trigger cron

✓Raffe spec:ar, bryter ner epic, delegerar till John/Janne

✓John kodar, bygger, pushar till main

✗Lundin kodar ALDRIG — oavsett hur liten ändringen är

✗Tasks assignas ALDRIG direkt till John utan Raffe-steg

🚀 Deploy-regler

✓Push till branch → PR → GH Actions → GHCR → auto-deploy. Punkt.

✗ALDRIG SSH direkt till prod för kod eller restart

✗ALDRIG manuell docker pull/restart på servern

→Deploy = inte klar förrän smoke test är grönt

🚫 Absoluta förbud — bryts aldrig

Varje agent har hårda gränser. Bryts de bryts hela systemet.

🔥

Lundin — kodar ALDRIG

COO / Orkestrerare

⛔Redigerar INGA kodfiler
⛔Kör INGA builds
⛔Pushar INGET till git
⛔"Jag fixar det snabbt själv" — FÖRBJUDET
✓Diagnostisera JA (läsa kod, curl, loggar)
✓Identifiera → formulera spec → delegera till Raffe

📋

Raffe — kodar ALDRIG

Product Engineering Manager

⛔Implementerar INGEN kod
⛔Sätter sig INTE in_progress på dev-tasks
⛔Delegerar ALDRIG direkt till Janne utan John-steg
⛔Skapar INTE 15 tasks om 5 räcker
✓Spec, /plan, acceptance criteria, delegering
✓Triggas av Epic → planerar → tasks i ready

💻

John — deployer ALDRIG manuellt

Developer

⛔SSH:ar ALDRIG till prod för att ändra kod
⛔Kör ALDRIG docker pull/restart manuellt
⛔Markerar ALDRIG task done utan verifierat bevis
⛔Hoppar ALDRIG över QA-steget
✓Push → PR → GH Actions deployer. Punkt.
✓Bevis = Docker image-datum = idag

🔍

Janne — godkänner ALDRIG utan test

QA Engineer

⛔Godkänner ALDRIG task utan att testa varje AC
⛔Godkänner ALDRIG utan verifierat deploy-bevis
⛔Skippar ALDRIG regression-tester
✓Varje AC testad → done. Annars → tillbaka till John.
✓Smoke test grönt = minsta krav för done

⚡ Fabriksarkitektur — Event-Driven Pipeline

Fabriken är event-driven, inte polling-baserad. Crons är watchdogs för fastnade tasks, aldrig systemets hjärta.

📊 Pipeline-flöde

Epic

📋

→

Backlog

📦

→

Ready

⚙️

→

In Progress

🔧

→

QA / Done

✅

🔑 Principer:

• Event-driven: Statusförändringar triggerar omedelbar notifiering (webhooks till /api/broadcast)
• Raffe triggas av Epic: Task skapad → cron run aa4ecd09 → Raffe startar planering direkt
• John hämtar nästa ready task: 2-minuters cron kollar ready-kön, fortsätter utan väntan
• GH Actions deployer automatiskt: Push → PR → merge → GHCR → auto-deploy
• Janne verifierar och marerar done: Smoke test → done-status → nästa task

📋

Raffe — Product Engineering Manager (Event-Driven)

Triggas av Event: Epic → Backlog

Vad Raffe gör:

• Triggas av Epic i backlog (EVENT)
• Läser business case från /products
• Delegerar till John via sessions_send(agent:john:main) och spawnar Janne/Niklasson
• Identifierar alla dependencies och risker
• Bryter ner i konkreta tasks med AC
• Delegerar till John (dev) och Niklasson (infra)

Raffe är ALDRIG:

• Reaktiv — väntar inte på instruktioner
• En kodare — implementerar aldrig själv
• Polling-baserad — EVENT-driven alltid
• Vag — varje AC är konkret och testbar
• Otålig — scope är rätt INNAN John startar

🕐 Watchdog Crons — Systemövervakning

Crons är systemets säkerhetsnät — de övervakar, ej styr.

Cron	Syfte	Intervall	Åtgärd
john-work-check-2m	John hämtar nästa ready-task och arbetar	2 min	curl ready-tasks → PATCH in_progress → koda
zombie-check-30m	Hitta tasks stuck in_progress >2h	30 min	Lundin notifieras, investigerar orsak
raffe-trigger	Trigga Raffe när epic skapas	On-demand	sessions_send(agent:raffe:main, task:assign) — Raffe startar planering
velocity-report	Daglig rapport: done-tasks, velocity	08:00 + 18:00	POST till Jörgens DM med metrics

⚠️ Viktigt:

Crons är inte systemets motor. De är säkerhetsnät. Systemet driven av events (PATCH status → broadcast). Om en cron slutar köra: pipelines funkar fortfarande, events funkar fortfarande, jobb görs fortfarande. Crons är backup.

🧟 Zombie-tasks — känna igen och hantera

En zombie-task är en task som sitter in_progress utan att röra sig framåt. Det är ett systemfel — inte en normal situation.

Symptom

• Task in_progress i >2h utan activity
• Agent har tagit task men inte levererat
• Raffe kodar istället för att spec:a
• John markerar done utan bevis

Orsak

• Otydlig spec — John vet inte vad done är
• Externt beroende som blockerar
• Agent utanför sitt mandat
• Task-scope för stor

Åtgärd (Lundin)

• Identifiera root cause
• Sätt task tillbaka till ready
• Skriv tydligare spec
• Delegera korrekt i kedjan

Detta är inte riktlinjer. Det är hur vi jobbar.

Varje regel finns här av en anledning. Bryts en regel bryts leveransen.

🏗️ Produktutvecklingsprocess

Process-flöde

IDÉ

ANALYS

SPEC

KÖD

DEPLOY

QA

CONTENT

DONE

Roller & Ansvar

Jörgen

Lundin

Raffe

John

Janne

Niklasson

Ping

📡 Kommunikationsflöde

🔍 QA-flöde — två steg

🗺️ Från idé till tasks — Epic-flödet

IDÉ + ANALYS — Jörgen & Lundin

PLAN — Raffe tar emot task:assign och delegerar

KÖD → DEPLOY → QA — John & Janne

CONTENT & DONE — Ping & Lundin

✅ Validering — FÖRE du rapporterar eller eskalerar

🚨 Validation Framework — Gäller alla i alla lägen

Lundin (COO)

Raffe (Product Engineer)

John (Developer)

Janne (QA) + Niklasson (Infra)

⚡ Fabriksregler — Manifestet

🔑 De två obligatoriska stegen — ALLTID

Skapa task i backlog

Trigga Raffe direkt

🏗️ Task-flöde

🚀 Deploy-regler

Definition of Done ✅

💻 John (Developer)

🔍 Janne (QA)

🖥️ Niklasson (Infra/Ops)

🚫 Absoluta förbud — bryts aldrig

Lundin — kodar ALDRIG

Raffe — kodar ALDRIG

John — deployer ALDRIG manuellt

Janne — godkänner ALDRIG utan test

⚡ Fabriksarkitektur — Event-Driven Pipeline

📊 Pipeline-flöde

Raffe — Product Engineering Manager (Event-Driven)

🕐 Watchdog Crons — Systemövervakning

🧟 Zombie-tasks — känna igen och hantera

Symptom

Orsak

Åtgärd (Lundin)