Files
boc/projects/landvex/00-styrning/AGENTARME.md
T
Bernt 7d40cf95bf landvex: IOL v3 + Identify API + Neo4j-graf + byggpipeline
- FastAPI Identify API (port 8081)
- Neo4j propertygraf (64 noder, 80 kanter)
- Ingest-pipeline (Python)
- Byggscript + integrationstester
- Docker Compose setup
2026-07-05 05:55:48 +00:00

5.9 KiB
Raw Blame History

AGENTARMÉ — implementeringsorder v1

Landvex produktionspaket · 58 agenter · 11 skvadroner · 4 faser

Detta dokument är arbetsordern. Paketets filer är enda sanningskällan. Ingenting implementeras som inte går att spåra hit.

Hårda regler — gäller varje agent, utan undantag

  1. Enda sanningskälla: 10-data/ + lvx-objekt-schema.json. Ingen agent uppfinner fakta, fält, klasser, standarder eller ID:n.
  2. Aldrig mock i kundnära väg. Saknad förmåga levereras som ärligt svar med konfidens + automatisk bounty (mönstret i 30-produkt/lvx-api-demosvar.json, case 3) — aldrig som låtsad träff, aldrig som stubbe i miljö en kund kan nå.
  3. PLATSHÅLLARE serialiseras aldrig ut ur något publikt gränssnitt. Filtret sitter i serialiseringskoden och testas.
  4. Källa på varje påstående. Publika svar bär verifieringsniva, konfidens och kallor[] — obligatoriska fält enligt API-kontraktet.
  5. Standarder refereras med organ + beteckning + roll. Standardtext återges aldrig (juridikregeln).
  6. ID:n mintas endast via registertjänsten (lvx-id-register.json-logiken i ingest.py). ID:n återanvänds aldrig, av ingen.
  7. Verifieringstrappan är enkelriktad: obekräftad → källbelagd (kräver källor) → fältverifierad (endast fotoflödet) → tillverkarbekräftad (endast portalflödet). Ingen kod får sätta nivå utanför sitt flöde.
  8. Grind före merge/deploy: 00-styrning/verifiera.py grönt + checksummor mot MANIFEST.json. Rött stoppar allt.
  9. Ontologi-/schemaändring endast via Ändringsrådet (skvadron A) med versionslyft och migrering.
  10. Osäkerhet uttrycks, döljs aldrig. Konfidens är produktyta, inte intern metadata.

Skvadroner (58 agenter)

A · Programkontor & arkitektur (3) — äger detta dokument, MANIFEST, gränssnittskontrakt och Ändringsrådet. Godkänner fasgrindar. Input: allt. Output: beslut, versionslyft.

B · Plattform & SRE (6) — Fas 0: dev/stage/prod, IaC, hemligheter, observabilitet, larm, backup/DR. Driftsätter samtliga tjänster. DoD: verifiera.py körs grönt i CI på varje miljö; återställningstest genomfört.

C · Datakärna & graf (6) — laddar lvx-klassposter-master-v3.json + modellfilerna till dokument-+graflager; grafen härleds alltid ur posterna (aldrig handredigerad); ID-registertjänst med atomär mintning. DoD: laddad databas reproducerar exakt grafstatistiken i lvx-graf-kanter-v3.json (176 kanter · 80 LVX · 82 standard).

D · Ingest-automation (7) — produktifierar 20-automation/ingest.py till tjänst: tre köer (schemalagd / kunddriven / fält), skördare med källvitlista och referatregel, extraktor-API bakom lvx-extraktionsprompt.md, granskningskö-UI för konflikter, körningsrapporter. DoD: våg 7-batchen i intag/ replayad genom tjänsten ger identiskt resultat (4 nivålyft, 1 mint, 0 fel).

E · Object API (7) — implementerar 30-produkt/lvx-pilot-api-spec.md exakt: 6 endpoints, svarskontraktet, PLATSHÅLLARE-filter, feedback→bounty, nycklar, rate limits och usage-mätning per identify för debitering (SaaS-kärnan). DoD: kontraktstester gröna; de tre golden-casen reproduceras via API:t mot riktig data.

F · Vision & identify (6) — utvärderings- och träningsflöde från bountydata; identify-modell bakom API:t. Tills modellen når beslutad tröskel svarar identify med klasskandidat + ärlig konfidens — regel 2 i praktiken. DoD: golden-case-regressionssvit; konfidenskalibrering rapporterad.

G · QUIXZOOM fältflöde (6) — bounty-motorn (lvx-zoomer-bounties-vag1.json + auto-förslagen): poäng, först-på-individ ×2, dubblettkontroll hash+geo, hårdkodade säkerhets- och integritetsregler (auto-blurr, inga registreringsskyltar), foto→OCR→fältverifierad-lyft, LVX-I-individregister. DoD: ett komplett e2e-lyft källbelagd→fältverifierad i stage med riktigt foto.

H · Tillverkarportal (4) — flödet som sätter tillverkarbekräftad: claims kopplade till modellposter, spårbara godkännanden, aldrig standardtext. DoD: en modellpost lyft e2e i stage.

I · Säkerhet, juridik & compliance (4) — källpolicy (referat, aldrig kopiering), licensregister per källa, GDPR för positionsdata, åtkomstmodell, pentest. DoD: godkänd granskning av serialisering + datalager.

J · QA & verifiering (5) — äger och utökar verifiera.py; kontraktstester mot API-spec; datagrind 0 valideringsfel; golden-case-replay i CI; last- och kaostester. DoD: grindarna blockerar på riktigt (bevisat med avsiktligt rött bygge).

K · Kund, pilot & SaaS-paketering (4) — Pilot/Pro/Enterprise enligt API-specens paketering, mätarbaserad debitering på identify, onboarding, pilotworkshop med 40-strategi/landvex-pilotpitch.pptx. DoD: första designpartner tecknad till pilotstart.

Faser & grindar

Fas 0 — Grund (B, C, J): miljöer uppe, data laddad, verifiera.py grönt i CI. → Grind 0: checksummor + 0 valideringsfel + grafstatistik reproducerad.

Fas 1 — Produkt (D, E, F, I): ingest-tjänst och Object API live mot riktig data. → Grind 1: golden cases via API:t; våg 7-replay identisk; pentest av API-ytan.

Fas 2 — Flyhjul (G, F): fältflödet live; feedback→bounty→foto→fältverifierad sluter loopen. → Grind 2: första e2e-nivålyftet; kunddrivna kön mätbar.

Fas 3 — Skala (H, K, D): tillverkarportal, fler skördebatchar genom pipelinen, pilotkund onboardad. → Grind 3: tillverkarbekräftad e2e; kostnad per verifierat faktum rapporteras sjunkande.

Beroenden: C före D/E · E före F/G-exponering · G före H:s fältdata · J tvärs igenom alla faser.

Eskalering

Datakonflikt → granskningskö (D) → Ändringsrådet (A). Schemabehov → A med versionslyft. Säkerhets-/juridikfynd → I stoppar berörd leverans omedelbart. Oklarhet om fakta → svaret är alltid: gå till källfilen; finns det inte där, finns det inte.