Kimi K3 का उपयोग करके कंपनी OS कैसे बनाएं (बिल्डर्स गाइड)

यह Kimi K3 का पूरा A-Z विवरण है कि यह क्या है और केवल AI एजेंट्स का उपयोग करके अपना पूरा व्यवसाय कैसे चलाएं।

यह आपके Kimi के साथ काम करने के तरीके को पूरी तरह से बदल देगा।

TLDR;

यदि आप 4480-शब्दों का लेख नहीं पढ़ना चाहते हैं, तो यहाँ GitHub रिपॉजिटरी है जिसे आप अपने एजेंट को दे सकते हैं।

https://github.com/codejunkie99/meridian-company-os इन बिल्ड्स को भूलने से पहले बुकमार्क कर लें।

प्रस्तावना

वे तत्व जिनकी हर कंपनी OS को आवश्यकता होती है, शुरुआत से प्राप्त, उन प्रॉम्प्ट्स के साथ जो प्रत्येक का निर्माण करते हैं। सिद्धांत सीखें, प्रॉम्प्ट लें, अपना खुद का बनाएं।

मैंने एक बनाया है (meridian-company-os, MIT लाइसेंस प्राप्त) और यह इस गाइड का संदर्भ है, इसका उद्देश्य नहीं। उद्देश्य इसके नीचे के नौ तत्व हैं, क्योंकि वे वही तत्व हैं जो किसी भी कंपनी OS के नीचे होते हैं जिसे आप कभी बनाएंगे।

इन 9 बिल्ड्स को भूलने से पहले बुकमार्क कर लें।

कमांड कॉकपिट: बिल्ड 5 से ऑपरेटर सरफेस, और नौ तत्वों का कुल योग।

परिचय

आप एक चैट विंडो और एक प्रार्थना के साथ एजेंट्स का ऑर्केस्ट्रेशन कर रहे हैं। एक एजेंट जो पैसा खर्च कर सकता है, कोड शिप कर सकता है, और अन्य एजेंट्स को किराए पर ले सकता है, वह एक कंपनी है, और आप उस कंपनी को एक सर्च बॉक्स के टूलिंग से चला रहे हैं। यह गाइड इसे ठीक करती है।

जुलाई 2026 तक की स्थिति यह है। वर्कर टियर पर एक कोडिंग एजेंट किसी भी फ़ाइल को जिसे आप एक पैराग्राफ में वर्णित कर सकते हैं, एक मिनट से भी कम समय में, पैसे के लिए जनरेट करेगा।

यह आपके बजट को खुशी-खुशी खर्च भी करेगा, अपनी खुद की मंजूरी को हल करेगा, और रिफ्रेश होने पर सब कुछ भूल जाएगा, क्योंकि किसी ने दीवारें नहीं बनाईं। मॉडल सस्ता हो गया। इसके आसपास का ऑपरेटिंग स्ट्रक्चर नहीं बनाया गया।

एक कंपनी OS एक अच्छा चैट UI नहीं है। यह छह सवालों का जवाब है, हर समय:

• किसके पास क्या है
• कौन से लक्ष्य मायने रखते हैं
• क्या अवरुद्ध है
• पैसा कितनी तेजी से जल रहा है
• आपकी हाँ का इंतजार किसे है
• जब आप गए थे तब क्या हुआ

सभी छह का उत्तर दें और आपके पास एक कंपनी OS है। कम का उत्तर दें और आपके पास एक डेमो है।

यह किसी एक का दर्शन नहीं है, और यह मेरे रिपॉजिटरी का वॉकथ्रू नहीं है। यह आवश्यक तत्व हैं, प्रत्येक के साथ एक सामान्यीकृत प्रॉम्प्ट है जिसे आप अपने कोडिंग एजेंट को देते हैं, संदर्भ कार्यान्वयन जो इसने मेरे लिए तैयार किया, और एक जाँच जो साबित करती है कि तत्व मौजूद है।

मेरा स्टैक React 19 + TypeScript + Vite था। आपका कुछ भी हो सकता है। तत्व नहीं बदलते हैं।

पूरी चीज़ वास्तव में कैसे बनाई गई थी, ताकि आप विधि की नकल कर सकें न कि केवल आउटपुट की:

• रनटाइम: प्रत्येक फ़ाइल Kimi K3 द्वारा Kimi Code CLI के माध्यम से जनरेट की गई थी (~/.kimi-code/bin/kimi, kimi login एक बार)।
• लूप, नौ बार: प्रॉम्प्ट लिखें, इसे kimi -p के माध्यम से पाइप करें, जाँच चलाएं। गलत फ़ाइल? प्रॉम्प्ट ठीक करें और पुनः जनरेट करें, कभी भी फ़ाइल को हाथ से न बदलें।
• टियरिंग: वर्कर टियर पर K3 ने नौ में से आठ बिल्ड्स को संभाला; एक (रिड्यूसर) को फ्रंटियर मॉडल पर भेजा गया।
• कौशल, पूरे रन में इंस्टॉल किए गए: योजना और समीक्षा अनुशासन के लिए Superpowers (obra/superpowers); संस्करण-सटीक React 19 और Vite 6 दस्तावेज़ों के लिए Context7 (upstash/context7), ताकि K3 पुराने APIs का भ्रम पैदा करना बंद कर दे।

यह पूरी टूलचेन है। आप इसे नीचे प्रत्येक बिल्ड के अंदर काम करते हुए देखेंगे।

अंत में आपके पास क्या होगा, तत्व दर तत्व:

• एक शब्दावली: टाइप किए गए संज्ञा जिन पर हर कंपनी OS को सहमत होना चाहिए (बिल्ड 0)
• एक दुनिया: एक बीजयुक्त कंपनी जो मध्य-संचालन में है, ताकि कंसोल कभी खाली न हो (बिल्ड 1)
• सत्य का एक स्रोत: एक स्टोर, एक रिड्यूसर, कोई व्यू स्टेट का मालिक नहीं है (बिल्ड 2)
• एक दिल की धड़कन: कंपनी आपकी घड़ी पर नहीं, अपनी घड़ी पर चलती है (बिल्ड 3)
• एक स्मृति: स्टेट जो रीलोड से बच जाता है (बिल्ड 4)
• एक ऑपरेटर सरफेस: एक स्क्रीन जो उत्तर देती है क्या हुआ, क्या मुझे इसकी आवश्यकता है, मैं क्या करूं (बिल्ड 5)
• एक गेट: पैसा और शक्ति आपकी हाँ के लिए कतार में हैं (बिल्ड 6)
• एक कमांड लाइन: टाइप किए गए कमांड किसी भी मॉडल को कॉल करने से पहले वास्तविक क्रियाएं बन जाते हैं (बिल्ड 7)
• एक वास्तविक रनटाइम: एक वास्तविक एजेंट जो तार-तार होकर, एक बाड़ के पीछे जुड़ा हुआ है (बिल्ड 8)

यह किसके लिए है: किसी भी व्यक्ति के लिए जिसके पास टर्मिनल, एक कोडिंग एजेंट, और एक समय में एक से अधिक एजेंट चलाने का इरादा है। आप मेरी फ़ाइलों की नकल नहीं करते हैं। आप सिद्धांत और प्रॉम्प्ट लेते हैं, और आपका एजेंट आपकी फ़ाइलें लिखता है।

इसे कैसे पढ़ें: क्रम में, जाँच करते हुए। प्रत्येक तत्व पिछले वाले को मानता है। जाँच इस बात का प्रमाण है कि तत्व मौजूद है; इसे छोड़ें और आप अफवाह पर निर्माण कर रहे हैं।

हर चीज़ के नीचे सिद्धांत। तीन, और अगले नौ बिल्ड्स में हर डिज़ाइन निर्णय उनमें से एक का उदाहरण है:

1. एक कंपनी स्टेट है। वाइब्स नहीं, चैट हिस्ट्री नहीं। टाइप किए गए तथ्यों का एक पेड़, और हर स्क्रीन उस पर एक खिड़की है, कभी उसका स्रोत नहीं।
2. शक्ति गेट्स के माध्यम से बहती है। कोई भी चीज़ जो खर्च करती है, किराए पर लेती है, शिप करती है, या फायर करती है, एक स्पष्ट हाँ के लिए कतार में है। कोई गेट नहीं, कोई कंपनी नहीं, बस एक UI के साथ एक लीक।
3. जो लिखा नहीं गया वह हुआ ही नहीं। हर दिल की धड़कन, निर्णय, और डॉलर एक केवल-जोड़ें लॉग में उतरता है। लॉग कंपनी की अपनी स्मृति है।

यहाँ से कोई निबंध नहीं।

पूर्वापेक्षाएँ

1node --version              # v20+; कोई भी आधुनिक रनटाइम काम करता है, संदर्भ ने इसका उपयोग किया
2npm --version               # node के साथ आता है
3
4# कोडिंग एजेंट जो हर फ़ाइल जनरेट करता है:
5ls ~/.kimi-code/bin/kimi    # kimi code cli स्थापित
6kimi login                  # एक बार; oauth क्रेडेंशियल्स को स्थानीय रूप से संग्रहीत करता है
7
8# पहले प्रॉम्प्ट से पहले kimi code में स्थापित कौशल:
9#   superpowers  (github.com/obra/superpowers)   योजना + समीक्षा अनुशासन
10#   context7     (github.com/upstash/context7)   ताजा, संस्करण-सटीक दस्तावेज़

रनटाइम को एक बार पिन करें: Kimi K3 वह वर्कर टियर है जिसने संदर्भ फ़ाइलें जनरेट कीं। एक अलग मॉडल चलाएं और आपको अलग फ़ाइलें मिलती हैं, जो ठीक है, क्योंकि आप अपना बना रहे हैं, मेरा नहीं। आप प्रॉम्प्ट और जाँच को स्थिर रखते हैं।

Kimi K3 क्यों

Kimi K3 एक नज़र में: लॉन्च स्पेक्स और सार्वजनिक बेंचमार्क स्टैंडिंग, कंसोल से मेल खाने के लिए स्टाइल किया गया।

रनटाइम का चुनाव, तेज़। सिर्फ़ हाइप नहीं, बल्कि ट्रेडऑफ़।

यह क्या है

• Moonshot AI का ओपन-वेट मॉडल, 16 जुलाई, 2026 को आउट हुआ।
• 2.8T स्पार्स MoE (प्रति टोकन 896 में से 16 विशेषज्ञ), 1M कॉन्टेक्स्ट, नेटिव विज़न।
• पहला ओपन 3T-क्लास मॉडल, अब तक का सबसे बड़ा ओपन-वेट रिलीज़।
• पूर्ण वेट 27 जुलाई को आते हैं; तब तक केवल होस्टेड।

यह कहाँ हारता है (ईमानदारी से)

• Fable 5 Moonshot की अपनी लॉन्च टेबल पर 35 में से 22 जीतता है; K3 12 जीतता है।
• इंटेलिजेंस इंडेक्स पर 189 में से 4 (~57, Fable 5 के 60 और GPT-5.6 Sol के 59 के मुकाबले)।
• FrontierMath Tier 4 पर 40% से कम, जहाँ बंद फ्रंटियर लगभग 90 है।
• भ्रम दर ~51%, इसलिए लूप में एक वेरिफायर रखें।

यह कहाँ जीतता है (यह सटीक वर्कलोड)

• ब्लाइंड फ्रंटएंड कोड एरेना में #1 (1,679, Fable 5 से आगे)।
• Terminal-Bench 2.1 पर 88.3%; SWE मैराथन और लॉन्ग-होराइज़न एजेंटिक कोडिंग में अग्रणी।
• "बिना पटरी से उतरे एक मल्टी-स्टेप टूल-कॉल सेशन से बचने" का कौशल जो एजेंट रनटाइम को बनाता या बिगाड़ता है।

यह चुनाव क्यों है

• ओपन वेट: एक बार ड्रॉप होने पर सेल्फ-होस्ट करें, अपने रनटाइम के मालिक बनें।
• सस्ता: $0.30/M कैश-हिट इनपुट, $15/M आउटपुट, Fable 5 से लगभग 70% कम।
• आप पूरे दिन एजेंट चलाते हैं, और आप अपना रनटाइम, डेटा और लागत वक्र किसी विक्रेता से किराए पर नहीं ले सकते।
• एजेंटिक कोडिंग में फ्रंटियर-पर्याप्त, ओपन, और 70% सस्ता, किराए के बेंचमार्क अंकों से बेहतर है जिन्हें आप स्वयं नहीं चला सकते।

नक्शा

नौ तत्व, और संदर्भ कार्यान्वयन में वे जो फ़ाइलें बने। आपके फ़ाइल नाम अलग होंगे। आपके तत्व अलग नहीं होंगे।

1any-company-os/
2  स्कैफोल्ड                    बिल्ड (यह खंड): रनटाइम + सख्त प्रकार, न्यूनतम निर्भरताएँ
3  डोमेन मॉडल                  बिल्ड 0: संज्ञा           -> src/lib/types.ts
4  बीजयुक्त दुनिया              बिल्ड 1: कभी खाली बूट न करें -> src/lib/seed.ts, skills.ts
5  सत्य का स्रोत               बिल्ड 2: एक स्टोर          -> src/lib/store.tsx
6  दिल की धड़कन                 बिल्ड 3: 2.6s टिक        -> src/lib/sim.ts
7  स्मृति                       बिल्ड 4: रीलोड से बचे     -> store.tsx में दृढ़ता
8  ऑपरेटर सरफेस                बिल्ड 5: कॉकपिट          -> src/App.tsx, views/Command.tsx
9  गेट                         बिल्ड 6: अनुमोदन इनबॉक्स  -> views/Approvals.tsx
10  कमांड लाइन                  बिल्ड 7: इससे बात करें     -> views/KimiSpace.tsx
11  वास्तविक रनटाइम              बिल्ड 8: बाड़ वाला एजेंट -> server/kimiBridge.ts, vite.config.ts

इस गाइड के सभी दस प्रॉम्प्ट prompts/ में चलाने योग्य फ़ाइलों के रूप में भी शिप होते हैं, प्रति तत्व एक, ताकि kimi -p "$(cat prompts/00-scaffold.md)" बॉक्स से बाहर काम करे।

पहले, स्कैफोल्ड। सिद्धांत: कम निर्भरताएँ, कम झूठ। एक कंपनी OS का एकमात्र काम भरोसेमंद स्टेट है, और हर निर्भरता किसी और का स्टेट है जिस पर अब आपको भरोसा करना है।

प्रॉम्प्ट, kimi -p के माध्यम से:

1मैं एक कंपनी OS बना रहा हूँ। मनुष्यों और AI एजेंटों की पूरी कंपनी चलाने के लिए एक कंसोल। मेरे लिए एक लीन सेटअप चुनें: टाइप की गई भाषा, तेज़ डेव लूप, और जितना संभव हो सके शून्य रनटाइम डिप्स के करीब। स्कैफोल्ड सेट करें और मुझे बताएं कि आपने क्या डाला और क्यों। कोई भी चीज़ जिसे आप एक पंक्ति में उचित नहीं ठहरा सकते, उसे बाहर निकाल दें।

K3 ने संदर्भ के लिए क्या तैयार किया: React 19 + TypeScript 5.8 सख्त + Vite 6, और React के अलावा बिल्कुल एक रनटाइम निर्भरता (lucide-react आइकन के लिए)। स्क्रिप्ट्स: dev, build (tsc -b && vite build), preview।

Context7 ने यहाँ पहले से ही मायने रखा: इसके बिना, K3 ने React 18 पैटर्न को स्कैफोल्ड किया; इसके साथ, कॉन्फ़िगरेशन पहले प्रयास में Vite 6 नेटिव आया।

जाँच: इंस्टॉल करें और टाइपचेक करें, एग्जिट कोड 0। अपनी रनटाइम निर्भरताओं की गणना करें; यदि आप प्रत्येक को एक पंक्ति में उचित नहीं ठहरा सकते हैं, तो यह बिल्ड पूरा नहीं हुआ है।

1npm install && npx tsc --noEmit; echo "exit: $?"

बिल्ड 0: शब्दावली

एक पंक्ति में क्यों: एक कंपनी स्टेट है, इसलिए किसी भी व्यवहार के अस्तित्व में आने से पहले, कंपनी जिस हर संज्ञा पर चलती है, उसकी बिल्कुल एक टाइप की गई परिभाषा होनी चाहिए।

पहले सिद्धांत। पूछें कि मनुष्यों और एजेंटों की किसी भी कंपनी में अपरिवर्तनीय रूप से क्या मौजूद है, और आपको सात संज्ञाएँ मिलती हैं:

• एक अभिनेता जो काम करता है और पैसा खर्च करता है
• एक लक्ष्य जो कहता है क्यों
• एक कार्य जो कहता है क्या, एक स्थिति और एक मालिक के साथ
• शक्ति की प्रतीक्षा कर रहा एक निर्णय (एक अनुमोदन)
• खर्च की एक इकाई (बही खाता)
• एक घटना जो कहती है कि यह हुआ (एक लॉग लाइन)
• एक कंटेनर जो उन सभी को रखता है (कंपनी)

हर कंपनी OS ये सात संज्ञाएँ और राय है। पहले संज्ञाओं को टाइप करें और राय ईमानदार रहती हैं।

सामान्यीकृत प्रॉम्प्ट। ध्यान दें कि यह संज्ञाओं और प्रत्येक से पूछे जाने वाले दो प्रश्नों का नाम देता है, और मेरे स्टैक के बारे में कुछ नहीं:

1ठीक है, किसी भी तर्क से पहले मैं संज्ञाएँ चाहता हूँ। यदि मैं मनुष्यों और एजेंटों की एक कंपनी चला रहा हूँ, तो वे चीजें क्या हैं जिनका अस्तित्व होना चाहिए? अभिनेता, लक्ष्य, कार्य, अनुमोदन, खर्च किया गया पैसा, लॉग में एक पंक्ति, कंपनी जो यह सब रखती है। यह सब प्रकारों में मॉडल करें, कोई व्यवहार नहीं। प्रत्येक संज्ञा के लिए दो प्रश्न पूछें: ऑपरेटर को क्या देखने की आवश्यकता है, और सिस्टम को क्या लागू करने की आवश्यकता है? स्थितियाँ बंद यूनियन हैं, स्ट्रिंग नहीं। पैसा और टोकन संख्याएँ हैं, वाइब्स नहीं। और यदि मेरे दो संज्ञाएँ गुप्त रूप से एक ही चीज़ हैं, तो इसे बताएं, मुझे एक गड़बड़ शिप न करने दें।

संदर्भ कार्यान्वयन। K3 ने src/lib/types.ts उत्सर्जित किया, 416 पंक्तियाँ, शून्य तर्क। वे आकार जो पूरे सिस्टम को ले जाते हैं, और प्रत्येक के अंदर दिखाई देने वाला प्रवर्तन प्रश्न:

1export type AgentStatus = "working" | "idle" | "paused" | "blocked" | "offline";
2
3export interface Agent {
4  id: ID; companyId: ID; name: string; title: string; department: string;
5  kind: "ai" | "human"; runtime?: string; model?: string; managerId?: ID;
6  status: AgentStatus; heartbeat: string;
7  monthlyBudget: number; spent: number;        // enforce: spend has a ceiling
8  successRate: number; tasksCompleted: number;
9  skills: string[]; color: string; lastHeartbeat?: number;
10}
11
12export type ApprovalType = "hire" | "spend" | "override" | "publish" | "terminate";
13export interface Approval {
14  id: ID; companyId: ID; type: ApprovalType; title: string; rationale: string;
15  requestedBy: ID; amount?: number;
16  status: "pending" | "approved" | "rejected";  // enforce: three states, no fourth
17  checks: PolicyCheck[];                        // the machine argues its case
18  decidedAt?: number; decidedBy?: string;
19}
20
21export interface ActivityEvent {
22  id: ID; companyId: ID; ts: number; actorId: ID;
23  kind: "heartbeat" | "task" | "delegation" | "spend"
24      | "approval" | "governance" | "goal" | "system";
25  message: string; amount?: number;             // what is not written down did not happen
26}

Kimi पास कैसे गया: एक kimi -p कॉल, पूरी फ़ाइल एक बार में।

Superpowers कौशल ने यहाँ अपनी जगह बनाई। इसके समीक्षा अनुशासन ने K3 को "आपके दो संज्ञाएँ ओवरलैप होती हैं" नोट जोड़ने के लिए प्रेरित किया: एक प्रतिनिधिमंडल और एक कार्य असाइनमेंट लगभग एक ही संज्ञा थे, जिसे एक नए इंटरफ़ेस के बजाय Task पर delegatedBy फ़ील्ड के रूप में हल किया गया। यह प्रॉम्प्ट का अंतिम वाक्य है जो वास्तविक काम कर रहा है।

जाँच: टाइपचेक शून्य any के साथ पास होता है। फिर संज्ञा ऑडिट: अपने इंटरफ़ेस को grep करें और पुष्टि करें कि सात संज्ञाओं में से प्रत्येक का बिल्कुल एक घर है।

1npx tsc --noEmit && grep -c "^export interface" src/lib/types.ts

बिल्ड 1: दुनिया

एक पंक्ति में क्यों: आप एक खाली कंपनी को संचालित करना नहीं सीख सकते हैं, इसलिए OS को एक ऐसी दुनिया में बूट होना चाहिए जो पहले से ही मध्य-संचालन में हो।

पहले सिद्धांत। एक ऑपरेटर सरफेस पहचान के माध्यम से सिखाता है: आप एक ओवर-बजट एजेंट, एक अवरुद्ध कार्य, एक लंबित किराया देखते हैं, और आप सीखते हैं कि नियंत्रण क्या करते हैं। एक खाली स्थिति कुछ नहीं सिखाती है, और रेंडरिंग बग्स को भी छिपाती है (एक खाली कॉलम और एक टूटा हुआ कॉलम समान दिखता है)।

इसलिए किसी भी कंपनी OS को एक नियतात्मक बीजयुक्त दुनिया की आवश्यकता होती है: हर बूट पर एक ही दुनिया, हर स्थिति का प्रतिनिधित्व किया गया, हर गेट पहले से ही एक निर्णय धारण कर रहा है।

सामान्यीकृत प्रॉम्प्ट:

1हमारे द्वारा अभी लिखे गए प्रकारों को लें और मेरे लिए एक पूरी कंपनी बनाएं जो पहले से चल रही है, ताकि ऐप के पास स्क्रीन पर सामग्री हो जैसे ही वह बूट हो। यहाँ कौन काम करता है? उन्हें वास्तविक शीर्षक दें, कौन किसको रिपोर्ट करता है, बजट जो वे आधा जला चुके हैं, हिट रेट। अभी क्या काम किया जा रहा है, क्या अटका हुआ है? मेरे इनबॉक्स में कौन से निर्णय हाँ की प्रतीक्षा कर रहे हैं? मॉडल में हर स्थिति कम से कम एक बार दिखाई देती है। इसे ऐसा महसूस कराएं जैसे मैं मंगलवार दोपहर 2 बजे एक लाइव कंपनी में चला गया, न कि एक खाली टेम्पलेट। कोई random() नहीं, हर बूट पर एक ही दुनिया।

संदर्भ कार्यान्वयन। K3 ने दो फ़ाइलें तैयार कीं।

seed.ts (~600 पंक्तियों के फिक्स्चर):

• दो कंपनियाँ, प्रत्येक में छह या अधिक एजेंट जिनमें रिपोर्टिंग लाइनें और आंशिक रूप से खर्च किए गए बजट हैं
• मिशन-से-कंपनी-से-टीम लक्ष्य वृक्ष
• सभी छह स्थितियों में कार्य
• नीति-जाँच परिणामों के साथ लंबित अनुमोदन

और skills.ts, स्थापना योग्य क्षमता पैक का एक रजिस्ट्री जो उनके वास्तविक स्रोतों को श्रेय देता है:

1export const SKILLS: Skill[] = [
2  s("superpowers", "Superpowers", "obra/superpowers",
3    "https://github.com/obra/superpowers", "developer",
4    "Battle-tested workflow superpowers: TDD, debugging, planning, and review discipline."),
5  s("context7", "Context7", "upstash/context7",
6    "https://github.com/upstash/context7", "developer",
7    "Pulls fresh, version-accurate library docs into the agent's context window."),
8  // ...design, marketing, social, finance, operations, legal packs
9];

यहाँ एक लूप है जिस पर ध्यान देने योग्य है। मेरे Kimi Code CLI के अंदर चलने वाले दो कौशल, जब यह फ़ाइल जनरेट कर रहे थे, रजिस्ट्री की पहली दो प्रविष्टियाँ हैं जो फ़ाइल परिभाषित करती है।

जिस OS का आप निर्माण कर रहे हैं, वह अपने एजेंटों पर कौशल स्थापित करता है, उसी तरह जैसे आपने अभी इसे बनाने वाले एजेंट पर कौशल स्थापित किए हैं। विधि ही उत्पाद है।

यहाँ एक पुनर्जनन की आवश्यकता थी। K3 के पहले पास ने हर कार्य को in_progress में रखा, जो "हर स्थिति कम से कम एक बार" पंक्ति में विफल रहता है। फिक्स सीड को संपादित करना नहीं था; यह वह पंक्ति थी जो प्रॉम्प्ट में जोड़ी गई, फिर kimi -p फिर से। प्रॉम्प्ट को ठीक करें, कभी फ़ाइल को नहीं।

जाँच: दो बार बूट करें, दुनिया का अंतर देखें। नियतात्मक का अर्थ है समान।

1node -e "const {seedState}=await import('./src/lib/seed.ts'); \
2  console.log(Object.keys(seedState().tasks).length)"   # हर रन पर समान गणना

बिल्ड 2: सत्य का स्रोत

एक पंक्ति में क्यों: एक कंपनी स्टेट है, इसलिए स्टेट केवल एक ही स्थान पर बदल सकता है, और बाकी सब कुछ एक खिड़की है।

पहले सिद्धांत। हर मल्टी-एजेंट डैशबोर्ड की विफलता मोड समान है: पाँच घटक प्रत्येक सत्य की एक प्रति रखते हैं, बहते हुए। इलाज संरचनात्मक है, अनुशासनात्मक नहीं।

एक स्टोर। एक रिड्यूसर, स्टेट प्लस एक्शन से स्टेट तक एक शुद्ध फ़ंक्शन। व्यू पढ़ते हैं; व्यू डिस्पैच करते हैं; व्यू कभी म्यूटेट नहीं करते हैं।

ऐसा करें और हर बाद का तत्व (लॉग, गेट, दिल की धड़कन) एक आर्किटेक्चर निर्णय के बजाय एक रिड्यूसर केस बन जाता है।

सामान्यीकृत प्रॉम्प्ट:

1हर स्क्रीन को सत्य के एक स्रोत पर एक खिड़की होना चाहिए, न कि हर जगह स्टेट का अपना छोटा ढेर। मेरे लिए वह स्रोत बनाएं। यदि स्टोर ही एकमात्र स्थान है जहाँ स्टेट बदल सकता है, तो इसका आकार क्या है, और एक बटन इससे कुछ बदलने के लिए कैसे कहता है बिना अंदर पहुँचकर और बकवास को म्यूटेट किए? एक शुद्ध रिड्यूसर, एक एक्शन यूनियन, सामान्य रीड्स के लिए सेलेक्टर। इसे ऐसा रखें कि मैं बाद में दुनिया को फिर से लिखे बिना नए एक्शन जोड़ सकूं। इसे बनाएं। फिर मुझे बताएं कि वह एक मामला कौन सा है जिस पर आप शर्त लगाएंगे कि मैं पहले तोड़ूंगा।

संदर्भ कार्यान्वयन। src/lib/store.tsx, लगभग 1,400 पंक्तियाँ: StoreProvider, useStore() जो { state, dispatch } लौटाता है, एक रिड्यूसर जो Action यूनियन के हर सदस्य को कवर करता है, और सेलेक्टर (companyAgents, companyTasks, companyApprovals, agentName)। वह मामला जो सिद्धांत दो और तीन को एक साथ वहन करता है:

1case "decideApproval": {
2  const a = s.approvals[action.id];
3  if (!a || a.status !== "pending") return s;          // no double-deciding
4  const decided = { ...a, status: action.approve ? "approved" : "rejected",
5                    decidedAt: Date.now(), decidedBy: "you" } as const;
6  return {
7    ...s,
8    approvals: { ...s.approvals, [a.id]: decided },
9    activity: [{ id: crypto.randomUUID(), companyId: a.companyId,
10      ts: Date.now(), actorId: "you", kind: "governance",
11      message: `${action.approve ? "Approved" : "Rejected"}: ${a.title}` },
12      ...s.activity],                                   // the decision is written down
13  };
14}

Kimi पास कैसे गया: यह एकमात्र बिल्ड है जिस पर K3 अटक गया। दो वर्कर-टियर प्रयासों ने ऐसे रिड्यूसर तैयार किए जिन्होंने तीन मामलों में नेस्टेड ऑब्जेक्ट्स को म्यूटेट किया, दोनों जाँच द्वारा पकड़े गए, अंतर पढ़ने से नहीं। बिल्ड को फ्रंटियर मॉडल पर भेजा गया, वही प्रॉम्प्ट शब्दशः, पहले पास पर साफ।

व्यवहार में यह टियरिंग नियम है: K3 डिफ़ॉल्ट वर्कर है, फ्रंटियर मॉडल एकमात्र बिल्ड के लिए आरक्षित है जहाँ शुद्धता ही पूरा बिंदु है। जिस मामले के बारे में पूछा गया कि वह किस पर शर्त लगाएगा कि मैं पहले तोड़ूंगा, इसने पहले से तय किए गए अनुमोदन पर निर्णय लेने का नाम दिया, इसलिए status !== "pending" गार्ड।

जाँच: grep द्वारा संपूर्णता। यूनियन में हर एक्शन का एक केस है, या यह एक मृत बटन है जो दबाए जाने की प्रतीक्षा कर रहा है।

1grep -c 'case "' src/lib/store.tsx    # >= आपके Action यूनियन में सदस्यों की संख्या
2npx tsc --noEmit

बिल्ड 3: दिल की धड़कन

एक पंक्ति में क्यों: वास्तविक कंपनियाँ तब चलती हैं जब आप नहीं देख रहे होते हैं, इसलिए OS को अपनी घड़ी पर टिकना चाहिए या यह आपको एक झूठ पर प्रशिक्षित कर रहा है।

पहले सिद्धांत। एजेंट लगातार खर्च और प्रगति करते हैं; आपका ध्यान अलग-अलग है। एक कंसोल जो केवल तब बदलता है जब आप क्लिक करते हैं, आपको सिखाता है कि क्लिकों के बीच कुछ नहीं होता है, जो बिल्कुल गलत और बिल्कुल महंगा है।

इसलिए किसी भी कंपनी OS को एक दिल की धड़कन की आवश्यकता होती है: एक छोटा, सीमित, शुद्ध स्टेट संक्रमण जो एक टाइमर पर फायर किया जाता है। सीमित भार वहन करने वाला शब्द है। एक असीमित टिक एक भगोड़ा है; एक सीमित हर टिक पर खर्च के पैसे और पाइप साबित करता है।

सामान्यीकृत प्रॉम्प्ट:

1मैं चाहता हूँ कि यह चीज़ बिना किसी वास्तविक एजेंट के प्लग इन किए भी जीवित रहे, ताकि जब मैं इसे खोलूं तो संख्याएँ पहले से ही चल रही हों। एक चल रही कंपनी की एक दिल की धड़कन की कल्पना करें, जैसे इसके 2 सेकंड। क्या बदलता है? थोड़ा पैसा जलता है, कुछ काम आगे बढ़ता है, एक लॉग लाइन गिरती है। उस एक कदम को एक शुद्ध state -> state फ़ंक्शन बनाएं ताकि मैं इसे एक टाइमर पर फायर कर सकूं और भरोसा कर सकूं कि यह कभी कुछ दूषित नहीं करता है। सब कुछ सीमित करें: प्रति टिक खर्च, प्रति टिक प्रगति, लॉग लंबाई। सबसे छोटी विश्वसनीय मात्रा क्या है, और मैं इसे भागने से कैसे रोकूं? टिक बनाएं और आपके द्वारा चुनी गई संख्याओं का बचाव करें।

संदर्भ कार्यान्वयन। src/lib/sim.ts: runTick(state): State, हर 2,600 ms पर प्रदाता में एक अंतराल द्वारा फायर किया जाता है। प्रति टिक: एक काम करने वाला एजेंट $0.40 से $3.04 तक जमा करता है, एक खुला कार्य 3 से 10 प्रतिशत प्रगति प्राप्त करता है, एक दिल की धड़कन लाइन उतरती है, और लॉग को नवीनतम-पहले 500 प्रविष्टियों पर सीमित किया जाता है।

संख्याओं का बचाव करने के लिए कहा गया, K3 का उत्तर डिज़ाइन के रूप में जीवित रहता है: एक टिक जो मानव आंख को बमुश्किल दिखाई देता है (2.6s), खर्च इतना छोटा है कि एक घंटे का सिमुलेशन पॉकेट चेंज खर्च करता है, एक लॉग कैप ताकि मेमोरी क्रॉल न कर सके।

1export const TICK_MS = 2600;
2
3export function runTick(s: State): State {
4  const tickN = Math.floor(Date.now() / 1000);
5  const agents = Object.values(s.agents).filter((a) => a.status === "working");
6  if (agents.length === 0) return s;
7  const actor = pick(agents, tickN);
8  const spend = +(0.4 + (tickN % 13) * 0.22).toFixed(2);   // $0.40..$3.04, bounded
9  // ...advance one task, append events...
10  return { ...s, activity: [...events, ...s.activity].slice(0, 500) };  // capped
11}

और बिल्कुल एक अंतराल, एक अनुवर्ती kimi -p संपादन द्वारा एक एकल हुक पर तार-तार: जबकि simRunning, हर TICK_MS पर {type:"tick"} डिस्पैच करें, क्लीनअप पर साफ़ करें, कहीं और कोई अंतराल नहीं।

जाँच: 30 सेकंड के लिए फ़ीड देखें; लाइनें लगभग हर 2.6s पर उतरती हैं। रोकें; यह जम जाता है। फिर से शुरू करें; यह चलता है। 2.6s से तेज़ आने वाली लाइनों का मतलब है दो अंतराल, और दो अंतराल का मतलब है कि कोई घटक प्रदाता का काम कर रहा है।

बिल्ड 4: स्मृति

एक पंक्ति में क्यों: एक कंपनी जो रिफ्रेश होने पर खुद को भूल जाती है, वह एक डेमो है, और डेमो और सिस्टम के बीच की रेखा एक रीलोड है।

पहले सिद्धांत। सभी स्टेट को दो प्रकारों में विभाजित करें और डिज़ाइन स्वयं लिखता है। डोमेन स्टेट (यहाँ कौन काम करता है, क्या खर्च किया गया, क्या तय किया गया) कंपनी है; इसे जीवित रहना चाहिए। सत्र स्टेट (आप किस स्क्रीन पर थे, एक खुला मोडल, एक टोस्ट) आपकी यात्रा है; इसे बनाए रखना एक बग है।

इसलिए: डोमेन स्लाइस का एक अनुमतिसूची स्नैपशॉट, वास्तविक संपादनों के बाद एक डिबाउंस पर लिखा गया, बूट पर बहाल किया गया। और एक ऑर्डरिंग कानून: पुनर्स्थापना पूर्ण होने से पहले कभी न लिखें, अन्यथा आप कंपनी को एक रिक्त के साथ अधिलेखित कर देते हैं।

सामान्यीकृत प्रॉम्प्ट:

1अभी एक रिफ्रेश पूरी कंपनी को वापस सीड पर नष्ट कर देता है। यह एक डेमो है, सिस्टम नहीं। मैं चाहता हूँ कि स्टेट रीलोड से बचे। इस बारे में सोचें कि वास्तव में क्या सहेजे जाने योग्य है बनाम क्या नहीं: वास्तविक कंपनी डेटा क्या है बनाम मैं कहाँ क्लिक कर रहा था? वास्तविक चीज़ों को अनुमतिसूचीबद्ध करें, सत्र की बकवास को स्पष्ट रूप से बाहर करें। विफलता का मामला क्या है यदि मैं गलत सेकंड में सहेजता हूँ, और मैं कैसे सुनिश्चित करूं कि मैं कभी भी अच्छे डेटा को आधे-लोडेड रिक्त के साथ अधिलेखित न करूं? सेव + रिस्टोर पथ बनाएं और मुझे उसमें कदम रखने से पहले ऑर्डरिंग ट्रैप के बारे में चेतावनी दें।

संदर्भ कार्यान्वयन। एक हाइड्रेट एक्शन, एक persistable() अनुमतिसूची (companies, agents, goals, tasks, approvals, runs, activity, customSkills, activeCompanyId), एक 400 ms डिबाउंस्ड राइट, और प्रॉम्प्ट में नामित ट्रैप एक पंक्ति द्वारा संरक्षित है:

1useEffect(() => {
2  if (!state.hydrated) return;      // the ordering law: never write before restore
3  const id = window.setTimeout(() => {
4    window.localStorage.setItem(SNAPSHOT_KEY, JSON.stringify(persistable(state)));
5  }, 400);
6  return () => window.clearTimeout(id);
7}, [state]);

Kimi पास कैसे गया: मौजूदा स्टोर के खिलाफ एक kimi -p संपादन, एक नई फ़ाइल नहीं। प्रॉम्प्ट का चेतावनी खंड यही कारण है कि hydrated गेट मौजूद है।

उस ट्रैप में कदम रखने से पहले इसका नाम बताने के लिए कहा गया, K3 ने इस सटीक रेस का नाम दिया: पहला रेंडर स्नैपशॉट लोड होने से पहले पर्सिस्ट इफ़ेक्ट को फायर करता है, सहेजे गए डेटा पर सीड लिखता है। सस्ते मॉडल वास्तविक बग ढूंढते हैं जब प्रॉम्प्ट बग ढूंढना डिलीवरेबल बनाता है।

जाँच: दो स्थितियाँ, दोनों तक पहुँचा जा सकता है। सिम को 20 सेकंड तक चलने दें, रिफ्रेश करें, संख्याएँ जारी रहती हैं। कुंजी साफ़ करें, रिफ्रेश करें, साफ़ सीड वापस आती है।

1# ब्राउज़र कंसोल में:
2localStorage.removeItem("meridian.snapshot")   # आपकी अलग होगी; फिर रीलोड करें

बिल्ड 5: ऑपरेटर सरफेस

एक पंक्ति में क्यों: ऑपरेटर तीन सवाल एक निश्चित क्रम में पूछता है (क्या हो रहा है, क्या मुझे इसकी ज़रूरत है, मैं क्या करूं), और मुख्य स्क्रीन को उन्हें ऊपर से नीचे तक जवाब देना होता है।

पहले सिद्धांत। कॉकपिट को सवालों से प्राप्त करें, न कि स्क्रीनशॉट में अच्छा दिखने वाली चीज़ों से:

• क्या हो रहा है: एक नॉर्थ-स्टार नंबर प्लस एक लाइव फ़ीड।
• क्या मुझे इसकी ज़रूरत है: एक रिस्क रडार (कौन ब्लॉक है, कौन बजट से बाहर है) और निर्णयों की प्रतीक्षा कर रही एक गिनती।
• मैं क्या करूं: उनमें से हर एक एक क्लिक दूर है, खोजबीन नहीं।

और क्योंकि एक कंपनी एक स्थिति है, हर विजेट स्टोर की एक शुद्ध रीड है। एक कॉकपिट जो अपने नंबरों को कैश करता है, वह एक झूठा उपकरण है।

सामान्यीकृत प्रॉम्प्ट:

1मुझे एक स्क्रीन चाहिए जिसे मैं पूरे दिन घूरता रहूं। मैं ऑपरेटर हूं। जब मैं इसे खोलता हूं तो यह इस क्रम में जवाब देती है: क्या हो रहा है, क्या मुझे इसकी ज़रूरत है, मैं इसके बारे में क्या करूं। तो: एक नंबर जो बताए कि क्या हम जीत रहे हैं, कौन आग पर है या बजट से बाहर है, मेरे 'हां' का इंतजार क्या कर रहा है, प्रति टीम कितनी तेजी से पैसा खर्च हो रहा है, और अभी क्या हुआ इसकी एक लाइव फ़ीड। हर विजेट सिर्फ स्टोर को पढ़ता है, कुछ भी अपनी कोई स्थिति नहीं रखता, जिस किसी चीज़ की मुझे ज़रूरत है वह यहां से एक क्लिक दूर है। शेल + यह कॉकपिट बनाएं, ऊपर से नीचे इसी क्रम में।

संदर्भ कार्यान्वयन। एक साइडबार शेल (नेव, कंपनी स्विचर, सिम टॉगल) और CommandView: डेल्टा के साथ नॉर्थ-स्टार, रिस्क रडार, पेंडिंग-अप्रूवल काउंट जो गेट पर डीप-लिंक करता है, company.budgets से डिपार्टमेंट बर्न बार, नवीनतम-20 गतिविधि फ़ीड। सभी सेलेक्टर, कोई लोकल इंटरवल नहीं, मोनो में मशीन वैल्यूज़।

Context7 ने फिर से अपनी कमाई की: React 19 मेमोइज़ेशन गाइडेंस करंट आया, इसलिए प्रति-टिक री-रेंडर सस्ते रहते हैं बिना स्टेल-API वर्कअराउंड के।

कॉकपिट एक ऑपरेटर सरफेस है; वर्क बोर्ड दूसरा है, जो उसी स्टोर और उसी टोकन से बना है। एक बार BUILD 2 मौजूद होने पर, हर सरफेस उस पर एक शुद्ध विंडो है।

जाँच: कॉकपिट को ठंडा खोलें और बिना क्लिक किए दस सेकंड के भीतर तीनों सवालों का जवाब जोर से दें। कंपनियां स्विच करें; हर विजेट बिना किसी पुराने नंबर के रिसाव के बदल जाता है। अप्रूवल काउंट पर क्लिक करें; आप गेट पर पहुंच जाते हैं।

बिल्ड 6: गेट

एक पंक्ति में क्यों: शक्ति गेटों के माध्यम से बहती है, इसलिए खर्च करने, काम पर रखने, शिप करने या निकालने वाली कोई भी चीज़ एक स्पष्ट रिकॉर्डेड 'हां' के बिना हल नहीं होती है।

पहले सिद्धांत। स्वायत्तता एक बजट है, अधिकार नहीं। पाँच क्रियाएँ जो आपको नुकसान पहुँचा सकती हैं (खर्च करना, काम पर रखना, ओवरराइड करना, प्रकाशित करना, समाप्त करना) प्रत्येक को निर्णय के समय चार चीज़ों की आवश्यकता होती है:

• अनुरोध
• अनुरोधकर्ता का तर्क
• मशीन की अपनी नीति जाँच, खुले तौर पर तर्कित
• एक निर्णय जो एक नाम और टाइमस्टैम्प के साथ स्थायी लॉग में दर्ज हो

एक और, जो चूकना आसान है: जब कोई नीति जाँच विफल होती है, तो अनुमोदन को ओवरराइड करने जैसा महसूस होना चाहिए। डिफ़ॉल्ट वह जगह है जहाँ शासन मरने जाता है।

सामान्यीकृत प्रॉम्प्ट:

1पूरी चीज़ का नियम यह है: एक एजेंट कभी भी मेरे 'हां' कहे बिना पैसा खर्च नहीं करता, किसी को काम पर नहीं रखता, कुछ सार्वजनिक नहीं करता, या किसी को नौकरी से नहीं निकालता। मुझे एक ऐसा इनबॉक्स बनाएं जहां वह 'हां' रहता है। हर आइटम अनुरोध, कौन पूछ रहा है, क्यों, कितना, और सिस्टम की अपनी नीति जाँच (बजट में? क्या कोई मैनेजर है? सीमा के भीतर?) दिखाता है ताकि मैं निर्णय लेने से पहले उसका तर्क देख सकूं। अनुमोदन और अस्वीकृति दोनों मेरे नाम के साथ लॉग में एक स्थायी निशान छोड़ते हैं, सिर्फ एक यूआई टॉगल नहीं। और अगर कोई जाँच विफल हुई, तो अनुमोदन को आसान डिफ़ॉल्ट न बनाएं, मुझे जानबूझकर ओवरराइड करने दें। इनबॉक्स बनाएं।

गेट। हर कार्ड अनुरोध, अनुरोधकर्ता, तर्क, राशि और सिस्टम की अपनी नीति जाँच दिखाता है। अनुमोदन और अस्वीकृति ही एकमात्र निकास हैं, और दोनों लॉग में लिखते हैं।

संदर्भ कार्यान्वयन। ApprovalsView: पहले पेंडिंग, प्रत्येक कार्ड में टाइप बैज, अनुरोधकर्ता, तर्क, मोनो में राशि, और विवरण टेक्स्ट के साथ पास/फेल नीति जाँच। डिफ़ॉल्ट-फ़्लिपिंग लाइन, बिल्कुल जैसा प्रॉम्प्ट ने मांगा था:

1const failed = a.checks.some((c) => !c.passed);
2// ...
3<button className={failed ? "danger" : "primary"}
4  onClick={() => dispatch({ type: "decideApproval", id: a.id, approve: true })}>
5  {failed ? "Override and approve" : "Approve"}
6</button>

निर्णय स्वयं BUILD 2 का decideApproval केस है, जो बात का केंद्र है: गेट एक स्क्रीन है, लेकिन कानून रिड्यूसर में रहता है। UI में लागू किया गया गेट एक सुझाव है।

जाँच: एक सीडेड आइटम को अनुमोदित करें; यह निर्णय ले लिया गया में चला जाता है, "आपके द्वारा अनुमोदित" स्टैम्प के साथ, और एक गवर्नेंस लाइन फ़ीड में आती है। एक विफल जाँच वाला आइटम ढूंढें; बटन "Override and approve" पढ़ता है।

फिर एक मिनट के लिए सिम देखें: यदि कोई अनुमोदन आपके क्लिक के बिना हल होता है, तो गेट टूट गया है और जब तक यह ठीक नहीं हो जाता, तब तक कुछ और मायने नहीं रखता।

बिल्ड 7: कमांड लाइन

एक पंक्ति में क्यों: ऑपरेटर आदेश जारी करते हैं, और एक आदेश जिसे पार्स करने में एक मॉडल कॉल खर्च होता है, वह regex से धीमा, महंगा और कम नियतात्मक होता है।

पहले सिद्धांत। ऑपरेटर के उच्चारण दो प्रकार के होते हैं। कमांड ("create task x, assign to bea, p1", "move MER-1042 to review", "budget report") का निश्चित व्याकरण और एक ज्ञात क्रिया होती है: उन्हें स्थानीय रूप से पार्स करें, वास्तविक स्टोर क्रिया भेजें, प्रिंट करें कि वास्तव में क्या बदला। कुल लागत शून्य, विलंबता शून्य।

बाकी सब बातचीत है, और यही वह चीज़ है जिसके लिए मॉडल है। रूटिंग नियम पहले नियतात्मक है, मॉडल फ़ॉलबैक के रूप में, और हमेशा ट्रेस दिखाएं। एक ओएस जो चुपचाप काम करता है, वह उस ओएस से अप्रभेद्य है जो कुछ नहीं करता।

सामान्यीकृत प्रॉम्प्ट:

1इस कंपनी को चलाने का सबसे तेज़ तरीका एक कमांड लाइन है, न कि इधर-उधर क्लिक करना। मुझे एक चैट चाहिए जहां मैं टाइप करूं "create task: fix onboarding, assign to bea, p1" या "move MER-1042 to review" या "budget report" और यह बस कर दे, स्टोर को हिट करे, मुझे दिखाए कि वास्तव में क्या बदला। कोई मॉडल कॉल नहीं, कोई लागत नहीं, कोई इंतजार नहीं, जब यह एक ज्ञात कमांड हो। केवल जब कुछ मेल नहीं खाता, तब यह बाद में एक वास्तविक मॉडल पर गिरता है। पहले पार्स करें, वास्तविक क्रिया भेजें, ट्रेस प्रिंट करें। और जिस चीज़ को आप बस निष्पादित कर सकते हैं, उसके लिए मॉडल पर रूट न करें।

टाइप किए गए कमांड सीधे स्टोर को हिट करते हैं और ट्रेस प्रिंट करते हैं, कोई मॉडल कॉल नहीं। केवल एक गैर-कमांड वाक्य स्थानीय K3 रनटाइम पर गिरता है, जो यहां अपने `kimi -p (local, k3)` ट्रेस के साथ उत्तर देते हुए दिखाया गया है।

संदर्भ कार्यान्वयन।

KimiSpaceView: कमांड व्याकरण के विरुद्ध regex पार्स, स्टोर के सेलेक्टर के माध्यम से नाम-से-आईडी रिज़ॉल्यूशन, डिस्पैच, चैट में वापस ट्रेस लाइन। फ़ॉलबैक शाखा इस बिल्ड में एक प्लेसहोल्डर प्रिंट करती है, क्योंकि मॉडल BUILD 8 की समस्या है:

1if ((m = input.match(/^create task:\s*(.+?),\s*assign to\s+(\w+),\s*(p[0-3])$/i))) {
2  dispatch({ type: "createTask", title: m[1],
3    assigneeId: agentIdByName(m[2]), priority: m[3] as never, by: "you" });
4  next.push({ role: "system", body: `Created task "${m[1]}" (${m[3]}) -> ${m[2]}` });
5} else {
6  next.push({ role: "assistant", body: "(would route to local kimi runtime)" });
7}

जाँच: create task: refresh onboarding emails, assign to Bea, p1 एक वास्तविक कार्य बनाता है जिसमें एक जनरेटेड कोड होता है और ट्रेस प्रिंट करता है। budget report प्रति विभाग सीमा के विरुद्ध खर्च प्रिंट करता है, तुरंत, बिना किसी स्पिनर के, क्योंकि कोई मॉडल कॉल नहीं किया गया। एक बकवास वाक्य प्लेसहोल्डर को हिट करता है।

कमांड हैंडलिंग जो लोडिंग स्थिति दिखाती है, वह एक मॉडल कॉल है जिसके लिए आप भुगतान कर रहे हैं और नहीं करना चाहिए।

बिल्ड 8: वास्तविक रनटाइम

तीन पंक्तियों में क्यों: अब तक सब कुछ एक सिमुलेशन पर चलता है, और एक कंपनी ओएस जो कभी किसी वास्तविक एजेंट को नहीं छूता, वह एक डियोरामा है। अंतिम तत्व एक वास्तविक रनटाइम के लिए पुल है, और यह सिस्टम में सबसे खतरनाक फ़ाइल है, क्योंकि यह एक प्रक्रिया को जन्म देता है जो सोच और खर्च कर सकती है।

तो बाड़ ही सुविधा है: एक साथ एक, एक इनपुट कैप, एक किल टाइमर, एक पृथक वर्कडिर, और क्रेडेंशियल्स जो कभी वापस तार के पार नहीं जाते।

पहले सिद्धांत। आपका रनटाइम जो भी हो (एक CLI, एक API, एक कतार), पुल को समान पाँच दीवारों की आवश्यकता होती है, प्रत्येक एक हमले का जवाब देती है:

• एक बार में कितने: एक, या एक अटका हुआ रन भगदड़ बन जाता है।
• कितना बड़ा इनपुट: सीमित, या कोई आपके बजट में एक किताब चिपका देता है।
• कितनी देर: एक किल टाइमर, या एक हैंग लॉक को हमेशा के लिए पकड़े रहता है।
• कहाँ: एक समर्पित वर्कडिर, या एजेंट आपकी रिपॉजिटरी पढ़ता है।
• क्या वापस लीक होता है: कुछ नहीं। किसी भी प्रतिक्रिया में कोई टोकन या क्रेडेंशियल कभी नहीं, बिल्कुल नहीं।

और एक कृपा नियम: यदि रनटाइम अनुपस्थित है, तो सिमुलेशन में बदल जाएं, कभी क्रैश न करें। कंसोल को अपने एजेंटों से अधिक जीवित रहना चाहिए।

सामान्यीकृत प्रॉम्प्ट:

1ठीक है, अब तक सब कुछ नकली है, एक अच्छा सिम। अब मेरे असली एजेंट को जोड़ें। मेरे पास इस मशीन पर एक असली CLI इंस्टॉल और लॉग इन है। जब मैं कुछ ऐसा टाइप करता हूं जो कोई ज्ञात कमांड नहीं है, तो असली एजेंट को स्पॉन करें और वास्तविक मॉडल, मेरे अपने क्रेड्स के साथ उत्तर दें। लेकिन यह ऐप का सबसे डरावना रास्ता है, यह एक ऐसी प्रक्रिया को जन्म दे रहा है जो खर्च कर सकती है, इसलिए इसे कड़ी बाड़ लगाएं और मुझे बाड़ बताएं इससे पहले कि आप इसे बनाएं: एक बार में कितने चलते हैं, कितना बड़ा इनपुट, कितनी देर में इसे मारेंगे, यह कहाँ चलता है, क्या कभी वापस लीक नहीं होना चाहिए। और अगर CLI नहीं है, तो क्रैश न करें, सिम मोड में रहें।

संदर्भ कार्यान्वयन। Kimi यहाँ दोनों निर्माता और निर्मित है: पुल जिस रनटाइम को जन्म देता है, वह वही ~/.kimi-code/bin/kimi है जिसने ऊपर हर फ़ाइल उत्पन्न की, इसे kimi -p के रूप में stdin पर ऑपरेटर के संदेश के साथ लागू किया गया, kimi लॉगिन क्रेडेंशियल्स का पुन: उपयोग करते हुए।

बाड़, जैसा भेजा गया:

• एक बार में एक चैट (एक दूसरा समवर्ती अनुरोध HTTP 409 प्राप्त करता है)
• 8,000-वर्ण इनपुट कैप
• 180-सेकंड किल टाइमर
• एक समर्पित .kimi-runtime वर्कडिर
• कोई एंडपॉइंट जो टोकन लौटाता है

दो एंडपॉइंट: GET /local-runtime/status और POST /local-runtime/kimi/chat। और क्योंकि पुल एक स्थानीय प्रक्रिया को जन्म देता है, देव सर्वर केवल 127.0.0.1 से बंधता है:

1export default defineConfig({
2  plugins: [react(), kimiOAuthProxy(), localKimiBridge()],
3  // local-first: ब्रिज आपके CLI को स्पॉन करता है, इस मशीन से परे कभी एक्सपोज़ न करें
4  server: { port: 4173, host: "127.0.0.1" },
5  preview: { port: 4173, host: "127.0.0.1" },
6});

एक अंतिम kimi -p संपादन ने BUILD 7 की प्लेसहोल्डर शाखा को वास्तविक POST से बदल दिया, ऑफ़लाइन फ़ॉलबैक बरकरार रखा।

जाँच: सुविधा नहीं, बाड़ साबित करें। स्टेटस एंडपॉइंट CLI की रिपोर्ट करता है; एक गैर-कमांड वाक्य का वास्तविक मॉडल द्वारा उत्तर दिया जाता है। फिर उस पर हमला करें: एक साथ दो चैट, दूसरा 409 लौटाता है; 9,000 वर्ण चिपकाएं, स्पॉन से पहले अस्वीकृत; CLI बाइनरी का नाम बदलें, ऐप सिम मोड में चालू रहता है।

1curl -s http://127.0.0.1:4173/local-runtime/status

रोलआउट

एक ओएस जिसे आपने एक सप्ताहांत में बनाया, फिर भी हफ्तों में अपनाया जाता है। ग्रेजुएट करें।

• सप्ताह 1, निरीक्षण करें। बिल्ड 0 से 5, केवल सिमुलेशन। टिक को पैसे और काम को स्थानांतरित करते देखें। ग्रेजुएट करें जब आप कॉकपिट के तीनों सवालों का दस सेकंड के भीतर जवाब दे दें।
• सप्ताह 2, गेट। बिल्ड 6 और 7। सीडेड अनुमोदन तय करें; टाइप किए गए कमांड द्वारा कंपनी चलाएं। ग्रेजुएट करें जब आपके द्वारा लिया गया हर निर्णय लॉग में एक मेल खाने वाली गवर्नेंस लाइन दिखाता है।
• सप्ताह 3, कनेक्ट करें। बिल्ड 8। वास्तविक रनटाइम चैट का उत्तर देता है, ऑटोपायलट बंद रहता है। ग्रेजुएट करें जब जब आप उन पर हमला करते हैं तो 409, 8k कैप और किल टाइमर सभी फायर करते हैं।
• सप्ताह 4, संचालित करें। एक वास्तविक एजेंट, एक वास्तविक कार्य, एक छोटा बजट। हर रन की समीक्षा करें। ग्रेजुएट करें जब एक पूरा दिन बिना किसी ऐसे खर्च के बीत जाए जिसकी आपने उम्मीद नहीं की थी और बिना किसी ऐसे निर्णय के जो आपने नहीं देखा।

सप्ताह 4 वह जगह है जहाँ संख्याएँ सिम्युलेटेड होना बंद कर देती हैं। विभागीय खर्च, अनुमान और एक मॉडल/टोकन बहीखाता, हर वास्तविक डॉलर एक एजेंट और एक कार्य के लिए ट्रेसेबल है।

प्रत्येक पंक्ति अगली को अनलॉक करती है। दिन 1 पर सप्ताह 4 वह तरीका है जिससे आप एक शैक्षिक चालान को निधि देते हैं।

रनबुक

सिस्टम द्वारा उठाया गया हर अलार्म, और कार्रवाई। संकेत किसी भी कंपनी ओएस के लिए सामान्य है; कार्रवाई वह जगह है जहाँ संदर्भ आपको इंगित करता है।

• फ़ीड जमी हुई, सिम चालू। डुप्लिकेट या लापता अंतराल, या एक व्यू ने उत्परिवर्तित स्थिति। प्रदाता में केवल एक सेटइंटरवल। व्यू विंडो हैं।
• रिफ्रेश करने पर नंबर रीसेट हो जाते हैं। स्नैपशॉट ने हाइड्रेट से पहले लिखा, या कभी लिखा ही नहीं। पर्सिस्ट इफ़ेक्ट पर हाइड्रेटेड गेट की जाँच करें।
• अनुमोदन स्वयं हल हो गया। डिसाइड एक्शन के अलावा कुछ और स्थिति को फ्लिप करता है। केवल decideApproval अनुमोदन स्थिति को छू सकता है; रिड्यूसर का ऑडिट करें।
• बर्न बार 100% से अधिक। एक विभाग अपनी सीमा पार कर गया। एक खर्च गेट पहले से ही लंबित होना चाहिए; यदि नहीं, तो जाँच गायब है।
• कमांड कुछ नहीं करता। व्याकरण छूट गया या कोई नाम हल नहीं हुआ। पार्स को प्रतिध्वनित करें; पुष्टि करें कि नाम स्टोर में मौजूद है।
• चैट 409 लौटाता है। एक वास्तविक रन पहले से ही उड़ान में है। प्रतीक्षा करें। एक-समय-में-एक दीवार काम कर रही है।
• चैट 502 लौटाता है। ऑथ प्रॉक्सी अपस्ट्रीम तक नहीं पहुँच सका। नेटवर्क समस्या; ऐप को अभी भी सिम मोड में चलना चाहिए।
• स्टेटस कहता है CLI गायब। रनटाइम अनुपस्थित या लॉग इन नहीं। kimi login चलाएं, या सिमुलेशन में रहें। कभी क्रैश न करें।
• जनरेशन के बाद टाइपचेक विफल होता है। जनरेटेड फ़ाइल मॉडल से भटक गई। प्रॉम्प्ट ठीक करें, पुनः जनरेट करें। हाथ से पैच की गई फ़ाइलें अप्राप्य बिल्ड हैं।

नियम (इसे प्रिंट करें)

1. एक कंपनी स्थिति है: एक टाइप किया गया ट्री, और हर स्क्रीन एक विंडो है, कभी स्रोत नहीं।
2. सात संज्ञाएं, प्रत्येक की एक परिभाषा। दो संज्ञाएं जो ओवरलैप होती हैं, वह एक गड़बड़ है जिसे आप शिप करेंगे।
3. कभी खाली बूट न करें। मॉडल में हर स्थिति सीड में कम से कम एक बार दिखाई देती है।
4. स्थिति एक रिड्यूसर में बदलती है या बदलती नहीं है। एक बटन जो डिस्पैच नहीं करता, मरा हुआ है।
5. हार्टबीट सीमित है: सीमित खर्च, सीमित प्रगति, लॉग 500 पर सीमित।
6. डोमेन स्थिति बनी रहती है; सत्र स्थिति कभी नहीं। हाइड्रेट से पहले कभी न लिखें।
7. शक्ति गेटों के माध्यम से बहती है: खर्च करना, काम पर रखना, ओवरराइड करना, प्रकाशित करना, समाप्त करना सभी एक 'हां' के लिए कतारबद्ध होते हैं।
8. एक विफल नीति जाँच अनुमोदन को एक स्पष्ट ओवरराइड बनाती है, कभी डिफ़ॉल्ट नहीं।
9. गेट का कानून रिड्यूसर में रहता है। UI में लागू किया गया गेट एक सुझाव है।
10. जो लिखा नहीं गया, वह हुआ नहीं। हर निर्णय एक नाम और एक टाइमस्टैम्प लॉग करता है।
11. पहले नियतात्मक, फ़ॉलबैक के रूप में मॉडल। कभी भी किसी regex को पार्स करने के लिए मॉडल को भुगतान न करें।
12. किसी भी वास्तविक रनटाइम पर पाँच दीवारें: एक बार में एक, सीमित इनपुट, किल टाइमर, पृथक वर्कडिर, शून्य क्रेडेंशियल लीकेज।
13. रनटाइम मर जाता है, कंसोल जीवित रहता है। अनुपस्थित CLI का अर्थ सिम मोड है, कभी क्रैश नहीं।
14. स्थानीय बांधें, 127.0.0.1। एक पुल जो आपके CLI को जन्म देता है, वह ऐसी चीज़ नहीं है जिसे आप एक्सपोज़ करते हैं।
15. प्रॉम्प्ट ठीक करें, फ़ाइल कभी नहीं। K3 कार्यकर्ता है; एक बिल्ड को बढ़ाएं, प्रोजेक्ट को नहीं।

समापन

रिपॉजिटरी कभी बात का केंद्र नहीं थी। Meridian एक स्टैक में एक कार्यान्वयन है, जो नौ तत्वों का है जो आपके स्टैक की परवाह नहीं करते: शब्दावली, दुनिया, सत्य, हार्टबीट, मेमोरी, सरफेस, गेट, कमांड लाइन, रनटाइम।

उन नौ को Rails या Rust या मैक्रोज़ वाली स्प्रेडशीट में बनाएं और आपके पास एक कंपनी ओएस है। गेट या लॉग को छोड़ें और आपके पास किसी भी भाषा में एक लीक के साथ एक UI है।

और ध्यान दें कि वास्तव में इसे किसने बनाया: एक वर्कर-टियर मॉडल, दो कौशल, नौ प्रॉम्प्ट, और प्रत्येक के बाद एक जाँच। आपने अभी जो विधि पढ़ी, वह वह मशीन है जिसे यह उत्पन्न करता है। आप स्पेक लिखते हैं, एक सस्ता एजेंट फ़ाइलें लिखता है, दीवारें सभी को ईमानदार रखती हैं, जिसमें आप भी शामिल हैं।

आज रात: BUILD 0 लिखें। अपना एजेंट खोलें, इसे शब्दावली प्रॉम्प्ट दें, और इसे अपनी कंपनी की सात संज्ञाओं के नाम देने दें। इसे एक भी व्यवहार लिखने न दें। संज्ञाएं पूरी पहली रात हैं, और बाकी सब कुछ उन पर एक विंडो है।

तो यहाँ वह सवाल है जिस पर बहस करना सार्थक है: आपकी कंपनी की सात संज्ञाएं क्या हैं, और आपने लगभग किन दो को मर्ज किया? आज रात BUILD 0 बनाएं और अपने प्रकारों के साथ उत्तर दें।

संदर्भ रिपॉजिटरी के निर्माण के दौरान मेरे अपने नोट्स से निर्मित; प्रत्येक फ़ाइल Kimi K3 द्वारा Kimi Code CLI के माध्यम से उत्पन्न की गई थी, और एक फ्रंटियर मॉडल ने इस गद्य को संपादित किया और एक बढ़े हुए बिल्ड (रिड्यूसर) को संभाला। दावे (https://github.com/codejunkie99/meridian-company-os) पर जाँचे जा सकते हैं।

यह Kimi K3 और Kimi Code CLI के साथ निर्माण करते समय लेखकों के नोट्स द्वारा लिखा गया है और इसे Kimi K3 Code और Opus 4.7 द्वारा संपादित किया गया है।