Hogyan működikHow it works

Egy kör, lépésről lépésreOne round, step by step

1. Cél

   Te írod: mit építsen vagy bővítsen a csapat. A legjobb cél egy interfész-specifikáció – fájlok, útvonalak, mezőnevek, a válaszok formája, a hibaágak. Ha nem tudod pontosan megfogalmazni, a Cél-segéd beszélgetve segít, és csapatot is javasol.

2. Architect

   Az első munkás megtervezi a fájlszerkezetet, kiosztja, ki melyik fájlért felel, és rögzíti a pontos felületet – ebből dolgozik mindenki, a tesztíró is. A terv egyszer készül el, és a futás végéig nem sodródik. Aki a tervben „nem vesz részt”, azt meg sem hívjuk. Meglévő projektnél az Architect látja a meglévő kódot és a futás előtt zöld teszteket, és a terv nem írhatja felül őket.

3. Munkások

   A csapatot grafikusan rakod össze: az egymás mellé tett munkások párhuzamosan dolgoznak, az egymás alá tettek sorban – a későbbi sor már látja a korábbi sor ugyanabban a körben elkészült fájljait (a frontend a kész backend API-ra épít). Javítókörben a munkás nem írja újra az egész fájlt, csak célzott cseréket küld.

4. Determinisztikus kapuk

   Szintaxis és sablonok, fájlok közötti hivatkozások, a projekt tesztjei, statikus biztonsági vizsgálat, build. Egy kapu vagy átmegy, vagy nem – itt nincs vélemény.

5. Visszajelzés

   Ha egy kapu piros, a hiba a felelős munkáshoz megy vissza a tényleges hibasorral – nem mindenkihez. A teszt bukása a logikát írókhoz kerül, nem a sablont vagy stílust író frontendhez.

6. Kapuőr

   Ha minden kapu zöld, egy külön modell ellenőrzi, hogy a célban felsorolt követelmények teljesülnek-e. Elutasítani csak úgy tud, hogy megnevezi a konkrét követelményt és a konkrét kódrészt. Stílus, ízlés vagy elméleti aggály nem elég.

7. Commit

   Minden kör külön git commitot kap, a kapuk állapotával az üzenetben. Utólag végigkövethető, mi történt, és mikor romlott el valami.

1. Goal

   You write it: what the team should build or extend. The best goal is an interface spec – files, routes, field names, the shape of the responses, the error branches. If you can't phrase it precisely, the Goal assistant helps in a conversation and proposes a team too.

2. Architect

   The first worker designs the file structure, assigns who owns which file and pins down the exact interface – everyone works from it, the test writer too. The plan is made once and does not drift until the end of the run. Workers the plan marks as “not taking part” are not called at all. On an existing project the Architect sees the existing code and the tests that passed before the run, and the plan may not override them.

3. Workers

   You build the team visually: workers placed side by side run in parallel, workers placed below run in sequence – a later row already sees the files the earlier row produced in the same round (the frontend builds on the finished backend API). In a fix round a worker does not rewrite the whole file, it sends targeted replacements.

4. Deterministic gates

   Syntax and templates, cross-file references, the project's tests, a static security scan, build. A gate passes or it doesn't – there are no opinions here.

5. Feedback

   When a gate is red, the error goes back to the responsible worker with the actual failing line – not to everyone. A failing test goes to the workers who wrote the logic, not to the frontend that only wrote templates or styles.

6. Gatekeeper

   When every gate is green, a separate model checks whether the requirements listed in the goal are met. It can only reject by naming the specific requirement and the specific piece of code. Style, taste or a theoretical worry is not enough.

7. Commit

   Every round gets its own git commit, with the gate results in the message. You can trace afterwards what happened and when something broke.

A kapukThe gates

Biztonsági hálókSafety nets

• A legjobb kör marad. Ha egy kör rontana a legjobb addigi állapoton, az FRST visszaállítja azt – a futás soha nem végződhet rosszabbul, mint a legjobb köre.
• Regresszió. Ami a futás előtt vagy az előző körben jó volt, és most bukik, azt név szerint kapja vissza a munkás: „ez korábban átment, a te változtatásod törte el”.
• Nincs haladás, nincs pénzégetés. Ha három egymást követő kör pontosan ugyanazt a hibát adja, a futás megáll.
• Költségplafon. Futásonként beállítható; ha eléri, a futás megáll. A költséget a saját kulcsodon a szolgáltató számlázza.
• Munkás-hiba nem kész. Ha egy munkás elhasalt, a félig frissült projektre nem kerül „kész” pecsét.

• The best round wins. If a round would make things worse than the best state so far, FRST restores it – a run can never end worse than its best round.
• Regressions. Whatever passed before the run or in the previous round and fails now goes back to the worker by name: “this passed before, your change broke it”.
• No progress, no burning money. If three consecutive rounds produce exactly the same failure, the run stops.
• Cost cap. Set per run; when reached, the run stops. The cost is billed by the provider on your own key.
• A failed worker is not done. If a worker failed, a half-updated project never gets a “done” stamp.

Hogyan írj jó céltHow to write a good goal

A mérésekben minden egykörös siker mögött pontos specifikáció állt. A cél nem ötlet, hanem interfész-leírás: amit nem írsz le, azt az Architect kitalálja – és akkor te nem tudod, mit kapsz.

In the measurements, every one-round success had a precise spec behind it. A goal is not an idea, it's an interface description: whatever you leave out, the Architect invents – and then you don't know what you'll get.

• Fájlszerkezet: melyik fájl mit tartalmaz.
• Végpontok és státuszkódok, a hibaágakkal együtt (400, 401, 404, 409, 422 – melyik mikor).
• Adatbázis-séma oszlopnevekkel és típusokkal.
• A válaszok pontos formája, példával.
• Meglévő projektnél: mi nem változhat – a meglévő válaszformák, nevek, tesztek; sémaváltozásnál migráció, adatvesztés nélkül.
• Kerüld a „stb.” és a „hasonlóan” szavakat – azok kitalálásra hívnak.

• File structure: which file contains what.
• Endpoints and status codes, including the error branches (400, 401, 404, 409, 422 – which one when).
• Database schema with column names and types.
• The exact shape of the responses, with an example.
• On an existing project: what must not change – existing response shapes, names, tests; for schema changes, a migration without data loss.
• Avoid “etc.” and “similarly” – they invite guessing.

Ha a célod alapján egy másik fejlesztő is ugyanazt az alkalmazást írná meg, akkor jó a cél.

If another developer would build the same application from your goal, it's a good goal.

Modellek és kulcsokModels and keys

Minden munkásnak külön modellt választhatsz: Google Gemini, Anthropic Claude, OpenAI, Groq, OpenRouter, SambaNova – a saját kulcsoddal. A mérések nagy része Gemini Flash modellekkel készült, néhány centes futásonkénti költséggel. Ha a gépeden van Claude Code, az frst-bridge programmal azt is csapattagnak veheted: a kérdés a gépedre jön, ott eszközök nélkül fut, és csak a szöveges válasz megy vissza – kizárólag a saját futásaidhoz.

You can pick a separate model for each worker: Google Gemini, Anthropic Claude, OpenAI, Groq, OpenRouter, SambaNova – with your own key. Most measurements used Gemini Flash models, at a few cents per run. If you have Claude Code on your computer, the frst-bridge program lets you add it as a team member: the prompt comes to your machine, runs there without tools, and only the text answer goes back – for your own runs only.