AURA
En Digital Audio Workstation skrevet i Rust: sequencer, mikser, busser og sends, CLAP- og LV2-plugin-hosting, MIDI inn og ut, kontrollflater, sanntids lydmotor med harde deadlines. Alt sammen skrevet av agenter.
Poenget var aldri å bevise at AI kan skrive kode. Poenget var å se om en arbeidsflyt kan bære et prosjekt som er for komplisert til å holdes i hodet — uten at et menneske leser diffene.
knobo/aura-dawHele styringen er én fil
next-prompt.md er inngangen. Den er kort med vilje, og
beskriver seg selv som en dispatcher, ikke en briefing: hva som er claimet, hva
som er ledig, og hvor detaljene ligger. Detaljene hører hjemme i backlog-filene.
Vokser denne fila, er det et symptom.
## Active claims
| Job | Branch | Claimed | Notes |
|---|---|---|---|
| _(none)_ | | | |
## Next up — unclaimed
1. **Owner ear-checks** are owed on several landed tracks.
No suite substitutes for them.
2. **Plan V — V4: per-node automation clock.**
→ docs/backlog/plan-v-players.md
3. **G3 — sidechain edges** (bass ducks the pads).
**Do not start unless asked:** Composer H2+ (deprioritised);
the native-GUI embed work; wiring the JIT kernel into
`mixer::render` — **decided against**, see GAP_ANALYSIS §8.Sløyfen
Kutt din egen worktree
Fra origin/main, alltid. Aldri gjenbruk en eksisterende, aldri branch fra det som tilfeldigvis er sjekket ut, aldri åpne en worktree hvis branch er merget — den er brukt opp.
Sjekk hva som allerede er i arbeid
Claims-tabellen er den varige oversikten, men en claim som ikke er merget finnes bare som en åpen PR. Derfor sjekkes alle tre: åpne PR-er, remote branches, worktrees.
Claim jobben før du starter den
Legg til raden din, commit den som første commit på branchen, push, åpne PR med én gang — draft er fint. En ucommittet claim er ingen claim.
Implementer, og skriv ned det du oppdager
Nye oppgaver som dukker opp underveis skrives inn i riktig backlog-fil, ikke i chatten. Det som kostet deg en time havner i TRAPS.md.
Slipp claimen i PR-en som lander jobben
Merging gjør det ikke for deg. Siste commit sletter raden og flytter utfallet til LANDED.md. En rad som blir stående peker på en branch som ikke finnes lenger.
Review er å bruke appen
Ingen leser diffene. Kontrollen ligger i at funksjonaliteten må kunne oppleves: to pads i samme choke group — det andre trykket må kutte det første uten klikk. En pad kvantisert til 1/4, avfyrt utenfor beatet mens arrangementet ruller — den må lande på beatet, og blokkgranulariteten på ~5 ms skal ikke høres som flam.
Backloggen kaller dette owner ear-checks, og hver landet track lister sine egne. Ingen testsuite erstatter dem.
Hva som faktisk gikk galt
Den dyreste feilen prosjektet har hatt er ikke en bug. Det er to agenter som gjorde ferdig den samme oppgaven. Hele claim-seremonien finnes utelukkende på grunn av det.
Den nest dyreste: en rad i tabellen som ble stående etter merge. Da peker den på en branch som ikke finnes, og neste agent kan ikke skille en død rad fra levende arbeid. Regelen om å slette raden er skrevet av agenten som selv glemte det.
Hvorfor det holder
Hukommelsen er filer
Hver sesjon starter kald. Alt som må overleve — beslutninger, feller, hva som er landet — ligger som markdown i repoet, og oppdateres i samme PR som endringen.
Isolasjon er billig
Én worktree per jobb fra origin/main. Agentene kan jobbe i parallell uten å tråkke i hverandres arbeidstre.
Backloggen vokser innenfra
Agenten som oppdager at noe mangler, skriver det ned der neste agent leter. Planlegging og utførelse er samme handling.
Det åpenbare motargumentet: dette fungerer fordi feil i en DAW er hørbare. Flytt samme arbeidsflyt til en betalingsflyt eller en tilgangskontroll, og «test appen etterpå» slutter å være en review. Der bruker jeg den motsatte polen.