ArchiveFW

Selvinitieret, selvhostet projekt. Bygget og drevet af mig som arkitekt, product owner og reviewer, med AI som en overvåget "lærling" i udviklingsprocessen og i dele af selve produktet.

ArchiveFW er en browserbaseret firmware-værkstedsløsning til mikrocontrollere: rediger C++ i browseren, kompilér med PlatformIO på en server, flash printet via en desktop-agent, og hold hvert build versioneret i Gitea. Det erstatter værktøjskæder på hver enkelt bærbar og uversionerede "final_v2"-mapper med ét reproducerbart, arkiveret workflow.

Tech stack

• Backend: Python (ca. 2.500 linjer), FastAPI/uvicorn, Pydantic v2, SSE-streaming af build- og serielt output, litellm
• Frontend: Vite + TypeScript, Monaco-editor, marked (ca. 2.500 linjer TypeScript)
• Build: PlatformIO CLI, kørt på serveren
• Flashing/serielt: en separat Python-desktop-agent, der forbinder udadgående via WebSocket; esptool, avrdude, micronucleus, OTA, pyserial
• Versionering: Gitea API (ét repo pr. projekt, annoterede tags)
• AI: DeepSeek — kodeassistent, fejlforklaring, biblioteksforslag, release notes
• Platforme: ESP32-familien, ESP8266, Arduino/AVR, STM32, RP2040, Digispark eller et vilkårligt PlatformIO-board
• Drift: systemd (og OpenRC på Alpine til agenten), TOML-konfiguration med miljøvariabler som tilsidesættelse

Største bedrift At adskille, hvor koden bygges, fra hvor hardwaren sidder. Serveren kompilerer; en lille agent på den maskine, der har boardet tilsluttet, forbinder udadgående (ingen firewallændringer), flasher det og deler én seriel port sikkert mellem flere lyttere. Flere agenter kan være forbundet samtidig og vælges uafhængigt fra editoren.

Problemet

Mikrocontrollerarbejde har en tendens til at sprede sig: værktøjskæder installeret pr. bærbar, biblioteker i den version, der tilfældigvis var installeret den dag, og firmwarefiler i mapper, hvis navne er den eneste registrering af, hvad der sidder på en enhed. At genskabe et build måneder senere eller svare på "hvad kører der præcis på den sensornode?" er gætværk. Flashing kræver et USB-kabel, så maskinen med boardet er ofte ikke den med værktøjskæden. Det er samme problem, større teams har med embedded-releases: intet sporbart led mellem kilde, afhængigheder, binærfil og enhed.

Arkitektur og løsning

Browser (Vite + TypeScript + Monaco)
   ↕ HTTP / SSE
FastAPI-server (:8096)  ──  PlatformIO (kompilering), DeepSeek (AI), Gitea (versioner)
   ↕ WebSocket, udadgående fra agenten
Desktop-agent(er) — én pr. maskine med et USB-tilsluttet board
   ↕ esptool / avrdude / micronucleus / pyserial

Designvalg, der er værd at fremhæve

• Stabil projektidentitet. Hvert projekt får et permanent 6-tegns hex-ID, der bruges til mappe, API-rute og URL. Visningsnavnet kan ændres frit. Gitea-repos hedder {slug}-{id}, så de sorterer efter navn og stadig er unikke.
• Udadgående agentforbindelse. Agenten starter WebSocket'en, så serveren kan stå i et serverrum bag en firewall, mens agenten sidder på et skrivebord. Serveren holder et register i hukommelsen over levende agenter efter navn og håndterer navnekollisioner uden et registreringstrin.
• En lille, eksplicit protokol. Agent og server udveksler et dokumenteret sæt JSON-beskeder; en flash-kommando er JSON efterfulgt af en binær ramme med firmwaren. Det gør agenten udskiftelig og testbar for sig selv.
• Delt seriel port med referencetælling. Web-UI'et og en selvstændig monitorside hostet af agenten kan lytte på samme port samtidig uden at slås om den.
• Hvert build registreres. En vellykket kompilering udløser et Gitea-commit (tomt om nødvendigt), så historikken afspejler builds og ikke kun rettelser. Tagging sammensætter en besked, kortbeskrivelse og README-opdatering ud fra den faktiske diff.
• Elegant nedlukning som designpunkt. Streaming-endpoints følger serverens exit-flag og sender en ren afslutningshændelse, så en servicegenstart tager omkring et sekund, selv med en åben seriel monitor.
• Boardstøtte er data. Boardtabellen (arkitektur, PlatformIO-ID, flashmetode) driver UI'et; egne boards accepteres via ID.
• Ingen automatiske tests i repoet. Verifikation er sket mod rigtige boards. I et team ville jeg først tilføje tests omkring compile-flow-parseren og agentprotokollen.

AI som lærling

AI i selve produktet. Editorens chat sender den aktuelle platformio.ini og main.cpp (med linjenumre) og forventer et struktureret svar: en besked, en komplet erstatningsfil og en liste over biblioteker. Brugeren afgør: "Apply Code" og "Add all" er eksplicitte knapper, aldrig automatiske. Kompileringsfejl får en "Fix with AI"-handling. Samme model sammensætter versionstags og release notes ud fra diffen.

AI i udviklingsprocessen (human-in-the-loop). Jeg ejer scope og arkitektur; en AI-kodeassistent implementerer mod en levende funktionel specifikation og en CLAUDE.md. Promptkontekst tilføjes kun til den sidste besked for at holde den cachede prefix stabil. Hardwarehandlinger, som flashing, kører og verificerer jeg selv.

Lederens refleksion

1. Gør artefaktet sporbart fra ende til anden. Kilde, biblioteksversioner, binærfil og enhedstilstand hører til i én historik. Det er det, der lader et team svare på "hvad kører der derude?" på sekunder.
2. Læg processen, hvor ressourcen er. Kompilér centralt, flash lokalt. At dele arbejdet efter, hvad hver maskine er god til, slår at tvinge én maskine til alt.
3. Udadgående forbindelser forenkler netværk. At lade kanten ringe til centrum undgår åbne porte og er lettere at få igennem en it-afdeling.
4. AI foreslår, mennesker anvender. Struktureret AI-output med eksplicitte anvend-knapper giver hastighed uden at give kontrollen over koden fra sig.
5. Små protokoller ældes godt. En dokumenteret beskedliste gjorde støtte for flere agenter til en registerændring frem for en omskrivning.

Ærlige begrænsninger. Single-user og selvhostet, delt token til agenter, ingen automatiske tests, ingen CI. Bygget mellem juni og august 2026. MicroPython og en boardvælger til eksisterende projekter står på ønskelisten.