# basode: Balanced Software Development Lifecycle – Conceptual Framework and Implementation Guide v0.41

Monolitikus SSOT és Injektált Állapotvezérelt Softver fejlesztés orchestrator modell

Balanced Software Development Lifecycle – Conceptual Framework and Implementation Guide © 2026 by akotomars is licensed under CC BY-SA 4.0

## 0. Rationale: Miért kell ez? Garage in-garbage out felskálázva az AI kódolás által

A lényeg:
Ha az AI-nak téves, hiányos infókat adunk, akkor téves és hiányos eredményt fog létrehozni. Utána ezt humán munkával korrigálni idegtépő – ekkor fordulnak el sokat az AI agentic development-től, pedig csak jól kell csinálni. Ezért készül és fejlődik a Balanced SDLC módszer, kimondhatóbban, röviden: basode.

—

Hagyományos szoftverfejlesztési környezetben a projektmenedzsment és a végrehajtás konzisztenciáját a humán aktorok soft skilljei, a formalizált SOP-k (Standard Operating Procedures), valamint az íratlan közösségi normák és implicit munkaköri leírások, fejlesztési alapelvek, szabályok, nevezéktanok egyensúlya biztosította.

Az autonóm AI ágensek (Agentic AI) belépésével ez a paradigma érvényét veszti. Az ágensek nem rendelkeznek a projekt lokális fájlrendszerén (munkakönyvtárán) kívüli tacit tudással vagy szociális rálátással; működésük szigorúan az explicit módon biztosított kontextusra és determinisztikus utasításokra korlátozódik. A munkavégzés szabályai immár nem a projekten kívül lebegő vállalati kultúra részei, hanem a projekt elválaszthatatlan, kódként kezelt (Docs-as-Code) komponensei kell, hogy legyenek.

A basode keretrendszer erre az architekturális kényszerre reagál. A korábban lágy (soft), humán-vezérelt folyamatokat és projektmenedzsment normákat néhány alappremisszára építve gépileg értelmezhető, nyomon követhető szabályrendszerré konvertálja. Ez a formalizált, egyértelmű keretrendszer radikálisan kitágítja az AI ágensek autonómiájának határait, képessé téve őket időben hosszabb, komplexebb és vertikálisan kiterjedtebb fejlesztési iterációk önálló végrehajtására.

## A tó víztükre, a bedobált kövek és a hullámok

A basode egyik fő pillére az, hogy a szoftverfejlesztés rendszer pillanatnyi állapota ránézésre tiszta legyen: vajon ez egy kész, letisztult, stable állapotban lévő rendszer, vagy épp egy/több igényt dolgoz fel, azaz egy változás zajlik éppen? A stable rendszer egy tó, amelynek tükörsima a felülete, és az új igény egy valami, amit valaki beledobott a tóba. Mindkettő tó ugyanaz a projekt: az egyik épp békés állapotban, a másikban épp hullámokat ver egy igény. A fejlesztés ideje alatt mi is, és a többi érdekelt is folyamatosan köveket dobál a tóba, és a tó, a fejlesztési projekt pedig befogadja az igényeket, és kezeli. A basode a fizikai törvények gyűjteménye, amelyek a tó működését modellezik, és célja, hogy a végén újra sima legyen a tó felülete. – Miért fontos ez? Ha rossz a modellezés, ha rossz fizikát alkotunk meg a világunkban, ahol a tó létezik, akkor az igények egymásra hatása nagyon lassan csitul el – vagy félresiklott projekt esetén: soha el sem csitul, nem lesznek elégedett érdekeltjeink -, és a tó állandóan hullámzik, sok-sok energia megy el arra, hogy a víztükör helyre álljon.

A hétköznapi életünkben a valós fizika elrendezi, hogy elsimuljon a víz. A mi világunkban ezt azon alapelvek biztosítják, amit összefoglalunk. Ezek az elvek a másik pillére a működésnek: a bedobott dolog beérkezése a tóba, az út, amit a dolog bejár: ha egy kő, akkor a tó aljára süllyedésig, ha egy tavirózsa, akkor a felszínén fog lebegni. A nyom, amit a tó állapotán hagy: ha nagy kő, akkor láthatóan emeli a víz szintjét – és a sok kicsi kő is megteszi ezt, és ha tavirózsa, akkor pláne látványos a tó felszínén: fejlődik a szoftver, és ez a felszínén is észlelhető lesz, és a tó medre, alakja is változik. Ez a mi szoftverünk is: az igény megvalósítása a felszínt is, és a megvalósító kódot is változtatja. A fizikánk biztosítja, hogy mindenféle óriás és kis dolog érkezése is a tó felszínének csillapodásához vezessen, és ezt hatékonyan tegye.

A tóban dolgozó fizikai erők itt az emberi és AI agent munka, és az infra, amit használunk. Ezekkel szeretnénk takarékosan bánni. Még egyszer: ha rossz fizikát alkotunk, akkor egy kő bedobása a mi világunk természete szerint nem egy elcsituló hullám lesz, hanem egy sok-sok ideig csapdosó tófelszín, vagy egy óriási gyönyörű, de pille súlyú tavirózsa ahelyett, hogy finoman a felszínen maradna, minimális hullámveréssel, ehelyett a méretéből adódóan cunamit okoz – azaz sokkal több erőforrást (pl. tokent) fogyaszt, mint egy jó fizika esetén -, és ha ez a csapdosási-hullámzási idő végtelen, akkor lelövik a fizika-szimulációnkat, azaz az elégedetlen megrendelők leállítják a projektet, pl. mi magunk: elfogy a pénzünk, amit a tokenekre, az infrára és a saját időnk költségéből erre szántunk.

—

A hasonlat hasonlata, az érthetőség kedvéért:

A számvitelnek is megvan a maga tava, köve, és fizikája.

Amikor a kettős könyvvitelű céghez megérkezik egy új számla bizonylat: e bizonylat az impulzus, és a számlabizonylat élete, annak a számviteli rendszerre, főkönyvre, naplókra tett hatása, a tartozik-követel bejegyzések változása a hullámverés. A rendszer fizikája szerint a bizonylat okozta impulzus végül legkésőbb az év végi mérlegben teljesen elfoglalja a helyét, és kialakítja az új egyensúlyi állapotot, ez újra a sima víztükört. És ahogy majd később látjuk a basode alkalmazásakor egy új igény befogadásakor, itt is hasonló dolog történik: Egy utalásos számla esetén kettéválik a nyilvántartás:
– az üzleti eredményt befolyásolja a számlabizonylat összege,
– és egy másik dokumentációs szinten pedig várjuk, hogy a bankszámlán majd megtörténjen a pénzmozgás.

Szóval ha behajít valaki egy új dolgot a cég pénzügyeinek tavába, azt a számvitel úgy kezeli le, hogy több helyre is felírja, az egyik helyre már mint valóságot (hiszen az üzleti eredményt már befolyosásolja a bejött impulzus), a másik helyen elindítja a fizikai megvalósulást: hogy valamikor majd utalni kell a bankszámláról. Persze ez egy hosszú folyamat: megvizsgálni a számlát, hogy mi is ez, különféle érdekeltek igazolják, hogy tényleg fizethető, stb. Ha jól emlékszem, akkor régebben a papír bizonylatra írtak rá mindenféle fejlegyzést az érdekeltek, ami a mostani kanban jegyhez hasonlítható: a papír bizonylat maga volt a változás manifesztációja, és egyúttal maga is változott a folyamat során: mint egy kanban jegyen, követhető volt a változás folyamata rajta is.

A számvitel tele van finomra polítozott SOP-okkal (standard operating procedure), szabályokkal, tiszta elvárásokkal, amelyek mára akár 100%-ig automatizáltak. A szoftver fejlesztésben igyekszünk elérni hasonló eredményt a basode módszerrel.

—

Visszatérve a hasonlatokból

A basode a számvitelhez hasonló rendszert vezet be a szoftver fejlesztésbe: szigorú kötelezettség, hogy legalább két helyre „könyveljük” az új igényt: beírjuk a kész rendszer működési dokumentációjába WIP (work in progress) jelöléssel- analóg azzal, hogy már az üzleti eredményt az utalástól függetlenül módosítja a bejött számla -, és ez azonnal egyensúlyba is kerül – technical debt formájában – úgy, hogy maga a feladat megjelenik a feladatkezelőben, majd szépen – ahogy a számla az igazolás, könyvelés, utalás során – a feladatunkon is elvégzünk jópár műveletet, aminek a végén a megvalósítással eltűnik a technical debt és a működés doksiból a tartozás jelzése: kivesszük a WIP jelzést.

A tó elcsitult, és a kő is leért a tó aljára: új egyensúly, új stabil verzió jött létre, ami kicsit más, mint a korábbi: a felülettel pillanatnyilag elégedettek az érdekeltek.

És akkor valaki újabb követ dob a tóba, jön egy új igény, és kezdődik minden előről: ez a mi software development life cycle-ünk, a balanced software development life cycle, röviden basode.

## I. Elméleti és absztrakt modell

todo: behozni a ci/cd-t mint párhuzamos target systemet
todo: behozni a release managementet, mint külső ciklust (mikor történhet release? amikor a kanban táblában csak start előtti és tesztelés+dokumentálás utáni jegyek vannak)

Ez a szekció a basode (balanced Software Development Life Cycle) módszertan technológia-független, elméleti alapjait rögzíti. A keretrendszer a szoftverfejlesztést egy megosztott memóriájú, monolitikus állapotgépként kezeli, amely egyetlen determinisztikus igazságforrásra (SSOT) támaszkodik.

**1. A kettős termékmodell**
A basode egyidejűleg két, logikailag elkülönülő rendszert fejleszt:
* **Target System (Termék A):** A létrehozandó szoftverproduktum (a célrendszer, a „3d nyomtatóval készítendő pohár”).
* **Delivery System (Termék B):** A szoftvert előállító módszer (dSdlc helyi implementációja), infrastruktúra és folyamatrendszer (a „3D nyomtató”). A Delivery System módosítása mindig prioritást élvez a Target Systemmel szemben. Ha már valaki rendelkezik kiforrott basode implementációval a saját fejleszői és infra környezetére, akkor ennek a súlya projketről projektre csökken, egyúttal azért kell ezt mindenképp megemlítani, mert a reaálitás az, hogy ez egy folyamatosan változó rendszer – ha másért nem, akkor az agentic programozást támogató IDE-k és más környezetek gyors fejlődése miatt.

**2. N-rétegű dokumentáció (doclayerN)**
A Target System állapotát hierarchikus absztrakciós rétegek írják le:
* **doclayer0 (Ideák):** Strukturálatlan, rendszeren kívüli igények. Az idea: a kő, ami repül a tó felszíne felé.
* **doclayer1 (TargetSpec):** A Target System elvárásait tartalmazó, irodalmi szintű specifikáció. Ez a globális SSOT. A becsobbant kő, ami átalakítja majd a tó medrét és a felszínét is.
* **doclayer2…N-2 (TargetSpectől a tech spec felé):** a projekt jellegétől függően ide N réteg kerülhet be, ahol az aktorok megvitatják és pontosítják, konkretizálják a megvalósítás irányába a feladatot.
* **doclayerN-1 (Funkcionális modell):** Technikai specifikációk és átmeneti modellek, amelyek a megvalósítást vezérlik.
* **doclayerN**
** **doclayerN-a** Az implementáció “működő” része:** A tesztek, a futó forráskód és az infrastruktúra. A tó medre, és víz a tóban.
** **doclayerN-b** Az implementáció “passzív” része:** User manual, tudásbázis, interaktív help, RAG a rendszert támogató LLM részére, stb. – mindezt a termék részének tekintjük, és az SDLC ciklus végén tökéletes összhangban kell legyen az -a réteggel: hiszen a usereket valid doksik tudják képben tartani a rendszer használatáról. A tó partján lévő turista tájékoztató táblák: a pecázási lehetőségekről, a csónak használatáról, a kis szigetre vezető felnyitható hídról.

**3. Triage és kettős könyvelés (WIP injektálás)**

A tóba csapódás pillanata az, amikor az igény/ötlet/idea/feladat/bugreport doclayer0-ból a doclayer1-be átkerül – a levegőből becsapódik a tóba. Ekkor döntünk úgy mi (product owner vagy project manager vagy bármilyen fórum, ez project charter kérdése), hogy a behajított dolog valóban a tavunkba való – ha nem, akkor az érdekeltnek visszajelzünk („szerintem beszélj a rendszergazdátokkal”, „vegyetek gyorsabb szervert”, „új jelszót nem tőlünk tudsz kérni”). Minden egyes dologról szóló pozitív döntés pillanatában a basode folyamatunk szerint végrehajtott kettős könyvelés a fizikánk része. Az információ szinkronban két vektoron materializálódik:
1. **Állapot-kimozdítás a doclayer1-en:** Az elvárás explicit markerrel (WIP injektálás) bekerül a TargetSpec dokumentumba, rögzítve a célállapotot.
2. **Hullámok indulnak a tavon: állapot-kimozdítás a feladatkövető rendszerben:** A becsapódott idea dedikált munkaelemmé válik a folyamatkezelőben, amely a doclayer2 módosítását is reprezentálja.
3. Innentől egy standard SDLC pipeline következik, ami a doclayer-eken vonultatja végig a megvalósulásig a feladatot, azaz a víz mozog, ahogy az új dolog beérkezett a tóba. Ha ez egy felszíni dolog, tavirózsa, akkor csak UI mélységig hatoló kihatással, de ha egy új követ hajítottak be, akkor a mederig kísérjük a feladatkezelővel a változás útját. Tesztekkel, stb., egy saját részletezettségű SDLC szerint. A feladatkazelőben a feladatot reprezentáló adathalmaz (gh issue, kanban tábla, stb., röviden: jegy) tartalmazza a fizikai impulzust: a saját tartalma – teendő – és a doclayer-ek állapota mutatja, hogy mennyi teendő van. Ahogy fogynak a jegyen a teendők, azzal egyidőben változik a doclayer-ek állapota, azaz a valóság. Szépen ahogy haladunk a letesztelt és elfogadott implementáció felé, úgy csökkent a hullám mérete: csökken a jegyen a teendők mennyisége.
4. Amnikor a jegyen végül elfogynak a feladatok, akkor a jegy az archívumba kerül, a target system doclayer1-ből pedig eltűnik a WIP bejegyzés okozta „feszültség”. Elültek a hullámok, beáll a fizikai egyensúly, a sima víztükör.

**4. Nem lineáris változások és az Instant-Issue**
Alulról építkező (bottom-up), kritikus architekturális vagy a Delivery Systemet érintő problémák esetén az Instant-Issue eljárás lép életbe. Ez az SDLC futószalag azonnali befagyasztását (pipeline freeze), soron kívüli hatásvizsgálatot, és a Delivery System (vagy a Target System alsóbb rétegeinek) prioritást élvező korrekcióját jelenti.

**5. Architekturális függetlenség**
A basode elméleti logikája független a fizikai adattárolás módjától, a konkurenciakezeléstől (pl. elosztott verziókezelés vs. fájlzárolás) és a választott projektmenedzsment-metodológiától (agilis, vízesés).

—

## II. Gyakorlati implementáció (Antigravity környezet)

Ez a szekció a basode elméleti modelljének specifikus, 3-rétegű (doclayer) leképezését írja le az Antigravity fejlesztési környezetben, helyi fájlrendszer-alapú Kanban feladatkövetéssel.

**1. Tárolási topológia és mappastruktúra**
A rendszer fizikai leképezése az alábbi dedikált könyvtárstruktúrában valósul meg:

* **Target System (Termék A) tárolása:**
* `docs/`: Itt tároljuk a TargetSpec-et (doclayer1), a narratív SSOT-t.
* `blueprints/`: Itt tároljuk a technikai specifikációkat, ábrákat, átmeneti modelleket (doclayer2).
* *(A gyökérkönyvtár és a forráskód mappái reprezentálják a doclayer3-at).*
* **Feladatkövető rendszer:**
* `kanban/`: A helyi issue tracking rendszert tartalmazó mappa, amely a végrehajtást és az állapotátmeneteket menedzseli.
* **Delivery System (Termék B) tárolása:**
* `docs_of_dev/`: A fejlesztési folyamatokat, szabályzatokat téma szerint csoportosító mapparendszer.
* `.agents/`: Az autonóm AI ágensek viselkedési szabályait (rules), képességeit (skills) és standard folyamatait (workflows) tartalmazó mappák.
* **A módszertan tárolása:**
* `docs_of_basode_method/`: Ezen a helyen tároljuk magát a basode framework/keretrendszer leírását, azaz ezt a doksit.

**2. A WIP injektálás gyakorlati szintaktikája**
Az Antigravity környezetben a kettős könyvelés során a fájlokba az alábbi XML-alapú szintaktikával injektáljuk a jövőbeli állapotot:
`Ide kerül a jövőbeli célállapot leírása…`
A ticket attribútum kötelezően a `kanban/` mappában lévő kártya azonosítójára mutat.

—

## III. Gyakorlati példák az iterációra

**Példa 1: Top-Down kettős könyvelés (Új funkció)**
* **Szituáció:** Új fizetési mód (Apple Pay) bevezetése a Target Systembe. A Triage után a feladat a `aplpay42` azonosítót kapja.
* **Végrehajtás a topológiában:**
1. A `kanban/` mappában létrejön a `aplpay42.md` kártya (állapot-kimozdítás a feladatkövetőben).
2. Ezzel párhuzamosan megnyitjuk a `docs/market/fizetesi_modok.md` fájlt (doclayer1), és befecskendezzük a jövőt:
`A rendszer a fizetési felületen sikeresen feldolgozza az Apple Pay tranzakciókat is.`
3. A `blueprints/` mappában (doclayer2) szükség esetén frissülnek a képernyőtervek. Itt is WIP marker jelzi a doksiban, hogy ez változás alatt van.

* **Eredmény:** Amikor a forráskódban (doclayer3) a feladat elkészül, a `` tagek eltűnnek a `docs/market/fizetesi_modok.md`-ből, a szöveg pedig ott marad stabil SSOT-ként. A `aplpay42` kártya lezárt állapotba kerül, és átkerül a megfelelő `kanban/` mappába.

**Példa 2: Bottom-Up Instant-Issue (Delivery System korrekció)**
* **Szituáció:** A forráskódon (doclayer3) dolgozó ágens felismeri, hogy a `blueprints/` (doclayer2) mappában alkalmazott szöveges ábrázolás hibás kódgenerálást okoz.
* **Végrehajtás a topológiában:** Az ágens meghúzza az „Andon cord”-ot. Pipeline freeze lép életbe. A `kanban/` mappában létrejön egy Instant-Issue kártya, amely dedikáltan a Delivery Systemet (Termék B) célozza.
* **Eredmény:** A munka a Target Systemen megáll. A csapat (vagy ágens) frissíti a `docs_of_dev/` mappában a specifikációs szabályzatokat (pl. kötelezővé teszi a Mermaid diagramokat a `blueprints/` alatt). A nyomtató tervrajzának javítása után a futószalag újraindul.