Een transcriptextractie overleeft een herstart, en je kijkt mee.
Een gesprekstranscript lezen, content schrijven, een export klaarzetten: dat past niet in een klik. Growth-OS legt de taak vast op het moment dat die wordt aangenomen, meldt echte toestanden terwijl hij draait, en pakt hem na een herstart weer op. Mislukt hij echt, dan zegt hij dat en kun je het opnieuw proberen in plaats van dat hij verdwijnt.
Dit is hetzelfde visuele component als in de ingelogde applicatie, met voorspelbare voorbeelddata.
Scenario
Voorbeeldscherm
Thema van voorbeeldoppervlak
Voorbeeldmodus
Running
The current stage, progress, item counts, milestones and the cancel command you can use.
Inerte voorbeelddata · geen netwerktoegang
Voorbeeld gereed
Het probleem dat dit oplost
Zonder een gedeelde basis bouwt elk team deze randgevallen opnieuw, en anders.
01
The extraction lost to a redeploy
You paste a transcript, the analysis starts, and the server restarts mid-way. Without a durable record there is nothing to resume and nothing to prove it was ever asked for. Here acceptance is a committed row before any worker is involved.
02
The progress bar driven by a timer
With no real job record the page has to guess. Spinners that never resolve, bars that fill at a constant rate, a status that contradicts what the worker actually did. Each state here comes from a checkpoint the worker wrote.
03
Slow work killed and run twice
A naive health check decides that a long analysis is dead and starts it again. Now two runs write results over each other. Telling late apart from lost is exactly the code nobody wants to write twice, so it lives in one place.
Kernpunten
Waarom dit belangrijk is
Accepted means written down
The job, its status record and its trigger commit in one transaction. You see queued straight away, even if the queue itself is unreachable.
Six real states, no fake spinner
Queued, running, waiting, succeeded, failed, canceled. Each one is reported by the worker doing the work, not by a timer in the page.
Nothing fails in silence
Retries are finite. Work that keeps failing lands in the control center, where one click requeues it safely.
Hoe het werkt
Het mechanisme van begin tot eind, zoals het in de repository is geïmplementeerd.
1
Accept in one step
The server checks the request, then commits the record, its process run, its outbox event and its receipt together. You see queued immediately.
2
Hand off safely
A publisher moves the job to the queue after the commit. Attempts are bounded, and a job that keeps failing lands in a visible dead state instead of retrying forever.
3
Work with checkpoints
Workers hold an expiring lease and update the record at each real stage. Large artifacts go to storage; the queue only carries small references.
4
Stream the truth
Status streams live, scoped to your organization and project. Late work reads as waiting rather than failed, and a completion notification cannot send twice.
Technische garanties
Wat dit wel en niet belooft
Veiligheidsgrens
Het voorbeeld op deze pagina draait op voorbeelddata. Echt gedrag vraagt onze database, wachtrij en synchronisatiediensten met toegepaste migraties, dus een geslaagde run op een laptop zegt niets over de deployment.
Implementatiebewijs
De grens hierboven is geen claim maar code. Deze bestanden dragen het contract:
docs/PROCESS-SYSTEM.md
src/features/processes/lifecycle.ts
src/features/processes/realtime-shape.server.ts
Vragen
Veelgestelde vragen
Hiernaast gebruikt
Deze functies delen contracten en grenzen met deze pagina.