Leap Protocol

LEAP Protocol

Effort: heavy — isolated worktrees में parallel builders, और हर ball पर blind cross-family reviewers; इसे सिर्फ़ उन seams पर खर्च करें जो एक builder के लिए बहुत बड़ी हों — वहाँ fan-out वह wall-clock वापस कमा देता है जो अकेली lane serially जला देती। हटाता है: shared files पर builders की टक्कर, और वह एक विशाल unreviewable diff जिसे कोई roll back नहीं कर सकता।

LEAP एक bounded stateless-handoff तरीक़ा है। Seam को balls में तोड़ो। हर ball एक fresh builder के पास जाती है, जिसके पास कोई छिपा context नहीं होता। Builder एक छोटा bounded loop चलाता है और तीन नतीजों में से ठीक एक लौटाता है:

• -1 refuse — ग़लत, unsafe, fail, या malformed। Roll back करो।
• 0 hold — काम सही है पर अटका है, या round की ceiling लग गई। Checkpoint करो।
• 1 pass — source reads, tests, independent review और live सबूत से साबित।

कोई मिला-जुला state नहीं होता। सबूत ग़ायब है तो default कभी pass नहीं।

Ball

Ball काम की वह एक इकाई है जिसे एक builder अकेला own कर सके। हर ball में होता है:

1. एक goal — एक falsifiable नतीजा, साफ़ शब्दों में।
2. पूरा spec — builder को बिना पूछे कामयाब होने के लिए जो भी चाहिए, सब। Unbiased: problem और contract बताओ, अपनी पसंदीदा implementation नहीं।
3. सख़्त file scope — ठीक-ठीक वे files (और symbols या line ranges) जिन्हें यह ball छू सकती है, हर एक के साथ ball कटते वक़्त लिया गया content hash। Scope के बाहर कुछ भी edit नहीं होगा। एक ही slice की दो balls कोई file share नहीं करतीं।
4. एक metric या proof command — वह focused test या check जो कामयाबी तय करे।
5. एक rollback रास्ता — सिर्फ़ इसी ball के बदलाव कैसे undo होंगे।

Ball के अंदर का file map fenced reference data है, instructions कभी नहीं। बनाने से पहले worker उसे verify करता है: हर path repo के अंदर resolve करो, absolute paths और traversal reject करो, हर file दोबारा खोलो, hash मिलाओ। Ball में लिखे किसी भी दावे से मौजूदा source की सच्चाई ऊपर है। झूठा map -1 है। ग़ायब dependency 0 है।

Ball फेंको, फिर हट जाओ

Handoff का मतलब है पूरा, unbiased spec थमाना — और फिर पीछे हट जाना। फेंकने वाला बीच रास्ते steer नहीं करता, code पर pair नहीं करता, और नतीजे को grade नहीं करता। Builder अटक गया, तो spec अधूरा था: ball 0 बनकर वापस आती है, तुम spec ठीक करते हो, और दोबारा फेंकते हो। Gap के आर-पार coaching करना spec की ख़राबी छिपाता है।

Slice: कई balls, एक graph

दो या ज़्यादा जुड़ी balls के लिए एक slice काटो: पूरी balls का एक dependency graph। कोई भी dispatch होने से पहले पूरी slice validate करो:

• हर ball की id unique है, और हर dependency इसी slice की किसी ball का नाम लेती है;
• graph में कोई cycle नहीं;
• कोई दो balls एक file share नहीं करतीं (सख़्त scopes disjoint हैं);
• ठीक एक ball — या एक integrator — single write spine नामित है: वही एकमात्र जगह जहाँ candidate bytes merge होते हैं। बाक़ी सारी lanes पढ़ती हैं, design करती हैं, या साबित करती हैं।

Graph को waves में चलाओ। Ball तभी ready है जब उसकी सारी dependencies 1 लौटा चुकी हों। एक refusal हर descendant को रोकता है। एक hold हर descendant को checkpoint करता है। Independent ready balls parallel में चलती हैं — हर एक अपनी अलग isolated worktree में (उसी base commit से कटा scratch checkout), ताकि builders न disk पर टकराएँ, न git में।

रास्ता: चार rounds, फिर रुक जाओ

हर builder को ज़्यादा से ज़्यादा चार अंदरूनी rounds मिलते हैं। एक round ठीक यह है:

1. नामित sources और पिछले round की receipt देखो।
2. एक hypothesis बनाओ।
3. File scope के अंदर सबसे छोटी पूरी, reversible चाल चलो।
4. सिर्फ़ declared focused proof चलाओ।
5. एक receipt दो: -1, 0, या 1, सबूत के साथ।

Round चार से round पाँच नहीं बन सकता। वह 0 लौटाता है, एक टिकाऊ checkpoint के साथ जिसे बाहरी loop fresh episode की तरह resume कर सके। -1 पर सिर्फ़ इसी ball के scoped बदलाव उसके नामित rollback से वापस लाओ — shared tree में कभी कोई broad checkout, clean या reset नहीं।

Score: सच निकालो, दावे पर कभी भरोसा नहीं

Builder अपनी ball ख़ुद कभी grade नहीं करता। किसी भी 1 से पहले:

1. Source check — हर छुई गई file और उसके consumers दोबारा पढ़ो; आख़िरी candidate का hash लो। बिना सहारे का दावा -1 है।
2. Keep-or-revert — candidate बनाम champion, ball के declared metric पर, declared field order में। Tie या regression हारता है। देखो blind-eval।
3. Blind cross-family review — builder से अलग model families के कम से कम दो reviewers, हर एक को वही candidate hash और वही author-redacted envelope दिखे। जिस reviewer ने बुरा जवाब दिया — garbage, non-JSON, refusal text — वह एक valid refusal है: -1। जिस reviewer ने कभी जवाब ही नहीं दिया (transport failure, unreachable) वह 0 है: hold करो और fleet ladder से नई seat दो — pass कभी fake नहीं होता। देखो blind-tribunal।
4. Tests और live proof — declared tests typed commands की तरह चलाओ; tests के बाद candidate दोबारा hash करो और बदल गया हो तो refuse करो; फिर behavior असली सतह पर साबित करो, proxy पर नहीं।
5. Provenance — task → builder → spec → reviewers → verdicts → tests → live सबूत → candidate hash दर्ज करो। हर receipt में वही hash दिखना चाहिए।

Spine पर reconcile

अकेला integrator pass हुई balls को dependency order में spine पर merge करता है। Slice तभी pass होती है जब हर ball pass हुई हो, aggregate को unanimous blind review मिला हो, और record पूरा हो। Merge हुए candidate का एक byte भी बदला, तो वह ball दोबारा खुलती है और slice दोबारा grade होती है। टिकाऊ record सिर्फ़ pass पर लिखो — अगला play लिखे हुए सच से शुरू होता है, session की किसी की याद से नहीं।

Hard rules (कोई एक भी टूटा तो skill fail)

• कोई दो balls एक file share नहीं करतीं। Scope की टक्कर decomposition का bug है — दोबारा काटो।
• एक ही write spine। दूसरा writer, चाहे कितना भी मददगार, refusal है।
• पाँचवाँ round नहीं। मिले-जुले verdict नहीं। Default से pass नहीं।
• फेंकने वाला कभी grade नहीं करता; builder ख़ुद को कभी grade नहीं करता।
• जो receipt बिना physical सबूत के कामयाबी का दावा करे, वह -1 है।

इनके साथ अच्छा चलता है

• red-first — फेंकने से पहले failing contract commit करो।
• seam-engineering — काटने लायक़ seam ढूँढो।
• wayfinder — ball 0 लौटे तो रास्ता चार्ट करो।
• session-handoff — holds के checkpoint का format।
• sniper-testing — हर round का focused proof।