Framein - cockpit, proxy या harness नहीं, बल्कि AI coding agent के नीचे की work-state layer

इन दिनों मैं अपनी ज़्यादातर coding terminal agents के साथ कर रहा हूँ। VS Code के अंदर Claude Code, Codex, और Gemini CLI को साथ-साथ खोलकर रखता हूँ; बेस implementation Claude को सौंप देता हूँ, और जब security या regression जैसी चीज़ों पर बाहरी नज़र चाहिए होती है, तो Codex से review करवाता हूँ। लेकिन ऐसा करते-करते हर बार model बदलने पर मुझे फिर से समझाना पड़ता था कि लक्ष्य क्या है, क्या नहीं टूटना चाहिए, और पिछला model क्या कोशिश करके विफल हुआ था। आखिरकार मैं उन तीन terminals के बीच एक human clipboard बनकर रह गया था।

ऐसे मिलते-जुलते tools खोजे तो वे पहले से बहुत थे। कई agents को एक विंडो में दिखाने वाले cockpit tools (Claude Squad, Orch term जैसे), एक harness से दूसरे model को बुलाने देने वाले proxy tools (opencodex, oh-my-free-models जैसे), और roles बाँटकर काम वितरित करने वाले orchestrators (Oh My OpenCode जैसे) तक। लेकिन जिस समस्या से मैं सच में जूझ रहा था — model बदलने पर भी काम खुद बीच में न टूटे — उसे सीधे संभालने वाले tools हैरानी की बात है कि कम थे। ज़्यादातर का फोकस "handoff को बेहतर करने" पर था।

Framein ने handoff को बेहतर करने के बजाय handoff की अलग ज़रूरत ही खत्म करने का रास्ता चुना। यह न कोई नया IDE है, न cockpit, न proxy, न एक और harness। यह उन agents के नीचे बिछने वाली एक पतली local work-state layer है, जिन्हें आप पहले से इस्तेमाल कर रहे हैं। तीनों agents repo के अंदर वही task contract, decision log, और verification results साथ में पढ़ते हैं, इसलिए "हैंड ऑफ़ करना" अपने-आप में अलग step नहीं रह जाता। अगला model मेरे द्वारा लिखे गए सारांश को नहीं, बल्कि असली तथ्यों को पढ़ता है।

इसका loop चार verbs पर आधारित है। यहाँ 'lead' से मतलब उस model से है जो इस समय वास्तविक implementation संभाल रहा है। यह उसे review करने वाले model से अलग पहचानने के लिए इस्तेमाल किया गया शब्द है।

• start : implementation डगमगाने से पहले request को task contract (goal, acceptance criteria, protected areas, non-goal) के रूप में स्थिर किया जाता है।
• challenge : किसी दूसरे model से सीमित दायरे वाली आपत्ति मँगाई जाती है, lead को केवल एक बार जवाब देने दिया जाता है, और फिर मैं फैसला करता हूँ। जब कोई model आत्मविश्वास से कहता है कि "implementation पूरी हो गई है", तब वही contract और diff पढ़ने वाला दूसरा model पूछता है, "इस plan में कौन-सा risk छूट गया है?" — यह उसी के लिए जगह है।
• capsule : अगले lead के पढ़ने लायक facts (contract, diff, verification, ADR, ledger) तैयार किए जाते हैं।
• ship : model के "काम पूरा हो गया" कहने पर नहीं, बल्कि वास्तविक build/test/risk gate के आधार पर task बंद किया जाता है।

इसे terminal से सीधे call किया जा सकता है; Claude/Gemini के अंदर /fr:* slash commands के रूप में, और Codex में $fr-* skills के रूप में भी बुलाया जा सकता है। किसी भी तरफ़ से बुलाएँ, यह वही local engine और वही state पढ़ता-लिखता है। मौजूदा harness, skill packs, और personas को जस का तस रखते हुए, उनके नीचे सिर्फ contract, ledger, और gates जोड़ने वाली संरचना है।

डिज़ाइन में जिन बातों पर मैंने खास ध्यान दिया, वे ये हैं।

• decision records (ADR) append-only हैं। edit या delete नहीं, सिर्फ नए record से replacement होता है। मेरा मानना है कि जिसे चुपचाप बदला जा सके, ऐसा decision record दूसरे model के उस पर भरोसा करते ही बेकार हो जाता है।
• यह credentials इकट्ठा नहीं करता। न token relay, न subscription pooling, न terminal input/output scraping। authentication हर official CLI के पास ही रहती है, और ज़रूरत पड़ने पर उन्हें सिर्फ local में call किया जाता है। (इसलिए यह proxy श्रेणी से अलग layer है।)
• runtime dependencies 0 हैं। सिर्फ Node 22 के built-in node:sqlite और built-in test runner का इस्तेमाल होता है। SQLite store cache है, और source of truth git-friendly JSON snapshots हैं; इसलिए छह महीने बाद dependency changes की वजह से install टूटने जैसी समस्या नहीं होगी।

अभी यह pre-release v0.0.6 पर है, और core (store, CLAUDE.md/AGENTS.md/GEMINI.md projection, task contract, verify/risk/ship gates, /fr:*·$fr-* wrappers, MCP server) तक implement हो चुका है, साथ ही 249 tests pass हो रहे हैं। जिन चीज़ों को अभी और निखारा जा रहा है, वे हैं Windows code signing path, signed/notarized executable distribution, clean machines पर install verification, और multi-developer workflow।

इसे npm install -g framein से install किया जा सकता है (Node 22.5+ आवश्यक), और यह MIT license के तहत है। इसका नाम फिल्मी शब्दावली से लिया गया है। जब subject frame से बाहर चला जाता है तो उसे frame-out कहते हैं, और उसे फिर से स्क्रीन के अंदर लाना frame-in कहलाता है। बिखरे हुए तीन agents को एक frame के भीतर वापस लाने के अर्थ में इसका नाम रखा गया है।

अगर आप पहले से cockpit, proxy, या harness इस्तेमाल कर रहे हैं, फिर भी नीचे task state के बार-बार लीक होने जैसा महसूस करते हैं, या दो से ज़्यादा coding agents के बीच काम कर रहे हैं, तो मैं जानना चाहूँगा कि क्या Framein उस खाली जगह को भरता है।

वेबसाइट : https://www.framein.dev/ko
GitHub : https://github.com/framein-dev/framein
डेवलपर नोट (यह क्यों बनाया) : https://www.framein.dev/ko/why