Parts Inventory

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.

Parts Inventory er et kommandolinjeværktøj, der holder styr på elektroniklager i et almindeligt regneark: hvad der er på lager, hvad der er reserveret til hvilket print, og hvad der skal købes. Det læser en stykliste fra KiCad eller EasyEDA, reserverer dele mod lageret og producerer en indkøbsliste, der kan uploades til leverandøren.

Tech stack

• Sprog: Python 3.11+, uv, Pydantic v2 (ca. 930 linjer i alt)
• Lagring: ODS-regnearksfiler (lager og indkøb), kan åbnes og redigeres i LibreOffice
• Input: LCSC-styklister som CSV eksporteret fra KiCad eller EasyEDA
• Grænseflade: en CLI med kommandoer til add, reserve, return, consume, build og export; miljøvariabler til standardstier
• Output: indkøbs-ODS og en LCSC-kurv-CSV, med valgfri påfyldning til minimumsbeholdning

Største bedrift En lille, ærlig model af lager, der passer til, hvordan elektronikarbejde faktisk foregår. Beholdning, reserveret og disponibelt er adskilte tal; en reservation rører ikke den fysiske beholdning; at bygge et print forbruger lager og frigiver reservationen; og et underskud løber ind i en indkøbsliste, der ved modtagelse kobles tilbage til det behov, der skabte den. Den samme model for beholdning / reserveret / disponibelt genfindes i den lager-webUI, jeg tilføjede til ArchivePCB en måned senere.

Problemet

En hobbyist eller et lille team, der bygger print, ender med skuffer fulde af passive komponenter og et regneark, der lyver. Den samme kondensator skal bruges af tre print; ingen ved, om lageret dækker dem alle; ordrer afgives fra hukommelsen og er enten for små (et gået i stå-byg) eller duplikerede. Data findes allerede i hvert prints stykliste, men intet forbinder dem med det, der fysisk står på hylden.

Arkitektur og løsning

Stykliste-CSV (KiCad / EasyEDA, LCSC-delnumre)
        ↓  reserve / return / consume / build
inventory.ods  ⇄  purchasing.ods  →  export-lcsc (kurv-CSV, valgfri påfyldning til minimumsbeholdning)

Designvalg, der er værd at fremhæve

• Et regneark er databasen. Brugeren kan åbne det i LibreOffice, rette en beholdning i hånden, sortere og filtrere. Koden læser og skriver ODS og antager ikke, at den er den eneste redaktør.
• Eksplicit lagermodel. Beholdning, reserveret og disponibelt er adskilt; disponibelt kan blive negativt, hvilket er normalt og signalerer et underskud frem for en fejl.
• Et livsforløb, ikke kun tællere. Reserve, return, consume og build er adskilte kommandoer med definerede virkninger, og modtaget lager reducerer indkøbslisten og kobles til det behov, der var registreret der, også for dele, der ikke var på lager ved reservation.
• Minimumsbeholdning pr. del. En genbestillingstærskel på hver del driver visningen af lav beholdning og den valgfri påfyldning af indkøbseksporten.
• Virker fra enhver mappe. Værktøjet gendanner brugerens arbejdsmappe, efter uv --directory har ændret den, så relative stier i styklisteargumenter opfører sig som forventet.
• Rettelse af filsærheder fra virkeligheden. Ét commit retter en kolonneforskydning, der opstod, når LibreOffice komprimerer gentagne celler i en ODS-fil, en fejl der kun viser sig ved rigtig brug.
• Ingen automatiske tests. Projektet er lille nok (to dage, 8. til 9. april 2026) til, at det blev verificeret ved brug; logikken i operations-modulet er det første, jeg ville sætte under test.

AI som lærling

AI i selve produktet. Ingen. Værktøjet er deterministisk af design.

AI i udviklingsprocessen (human-in-the-loop). Repoet indeholder en funktionel specifikation med den præcise adfærd for hver kommando og indstilling, og en AI-kodeassistent implementerede mod den. Specifikationen er den kontrakt, jeg gennemgår mod.

Lederens refleksion

1. Prototyp modellen på noget småt. En CLI på to dage lod mig udarbejde lager- og reservationsmodellen billigt; samme model blev senere brugt i en webapplikation.
2. Mød brugerens eksisterende værktøjer. Valget af et regnearksformat, folk allerede åbner, fjernede en hel admin-grænseflade.
3. Specificér adfærd, ikke kun funktioner. At skrive ned, hvad hver indstilling gør ved hvert tal, er det, der gør en implementering kontrollerbar.
4. Negative tal kan være information. At behandle et negativt "disponibelt" som et underskudssignal gjorde en tilsyneladende fejl til indkøbslisten.
5. Vid, hvornår et værktøj er et springbræt. Kommandolinjen gjorde sit arbejde som første version af modellen; det rigere lager bor nu i ArchivePCB.

Ærlige begrænsninger. Kun kommandolinje, ODS-fil som lagring uden låsning, ingen automatiske tests, LCSC-specifik og ingen AI.