Naly इंजीनियरिंग नोट्स: Codex CLI, स्ट्रक्चर्ड JSON और Cron-सुरक्षित AI वर्कर

सार

Naly में Codex CLI को शेड्यूल किए गए AI काम के लिए control plane के रूप में इस्तेमाल किया जाता है: प्रत्येक cron entry एक चेक किए गए स्क्रिप्ट को चलाती है जो web search के साथ एक bounded assistant task शुरू करती है और रन के बाद downstream publish, replay और retries के लिए सत्यापित JSON artifacts लिखती है। इससे मॉडल का काम एक ऑपरेशनल पाइपलाइन की तरह व्यवहार करता है—एक ही command, स्पष्ट schema, स्पष्ट artifacts—न कि बदलने वाली इंटरैक्टिव workflow की तरह। जून 2026-06-25 तक, यह विभाजन growth-critical कंटेंट इंफ्रास्ट्रक्चर के लिए विश्वसनीयता का बड़ा लाभ है.

Naly में यह कहाँ बैठता है

Naly में पहले से ही खोज, प्रतिधारण और वितरण वर्कफ्लो पर सक्रिय GST प्राथमिकताएँ हैं। यह पैटर्न सीधे उसी execution layer में फिट होता है:

• Cron jobs प्रत्येक use case के लिए एक अकेला tsx script चलाती हैं ताकि हर रन versioned code के भीतर रहे, न कि ad hoc shell snippets के साथ।
• Codex CLI तर्क और retrieval का काम करती है, जबकि Naly orchestration control संभालता है: schedule, retries, locking और durable artifacts।
• स्ट्रक्चर्ड आउटपुट Next.js, React, Drizzle ORM और Neon पर बने downstream systems को सीधे feed करता है, बिना downstream schema अनुमान के।
• बाहरी लॉग और रन metadata लिखे जाते हैं NALY_LOG_ROOT, जिससे post-mortems process output buffering से स्वतंत्र और पुनरुत्पाद्य बनते हैं।

मुख्य बात यह है: production उपयोग के लिए मॉडल की गुणवत्ता केवल आधी प्रणाली है; उस मॉडल के आसपास की deterministic boundaries दूसरी आधी।

तकनीकी तंत्र

1) Contract-first worker entrypoint

हर task तीन स्थिर इनपुट से शुरू होती है:

• एक codified prompt template और task intent।
• एक response schema जिसे validate किया जाना अनिवार्य है।
• एक रन envelope (run_id, source_query, attempt, env), जो API call से पहले persist किया जाता है।

Naly cron से Codex CLI को interactive mode के बजाय batch mode में चलाता है। Codex को एक स्थानीय coding agent के रूप में दस्तावेज़ित किया गया है और इसे open-source distribution और active releases के साथ एक standalone CLI के रूप में ship किया गया है, और इसे scripted environment में चलाया जा सकता है Codex CLI, OpenAI Codex repo।

2) क्यों स्ट्रक्चर्ड आउटपुट गैर-समझौताकारी है

OpenAI structured-output गाइड्स parser-supported schema extraction और मशीन-पाइपलाइनों के लिए आवश्यक strict mode behavior को describe करती हैं। Naly में मॉडल आउटपुट को अंतिम सत्य नहीं, बल्कि एक intermediate artifact माना जाता है, इसलिए JSON contract पर ही reliability लागू की जाती है:

• required fields (headline, evidence list, confidence, citations, failure reason)
• डिफ़ॉल्ट के साथ optional fields
• numeric confidence और bounded enums
• parser failures को स्पष्ट रन errors के रूप में surface किया जाता है, चुपचाप auto-corrected text के रूप में नहीं।

3) Cron-to-agent lifecycle with concurrency control

Cron मानक 5-field टाइमिंग fields के अनुसार scheduled लाइनें चलाता है और जब fields match करती हैं तब command शुरू करता है crontab. Production safety के लिए Naly इसमें जोड़ता है:

• lock guard (प्रति task एक active run)
• idempotent run key
• jitter के साथ bounded retry policy
• हर चरण के लिए external log capture
• डाटाबेस टेबलों में पोस्ट-रन state update, जो Drizzle/Neon द्वारा संचालित हैं।

flock यह ठीक इसी guardrail pattern के लिए design किया गया है: lock acquire करना, critical section execute करना, और पहले से locked होने पर cleanly exit करना flock. क्योंकि lock state file descriptors के साथ जुड़ा रहता है, overlapping cron windows को स्पष्ट रूप से रोक दिया जाता है ताकि state corrupt न हो।

4) इस pattern में MCP क्यों महत्वपूर्ण है

Model Context Protocol host/client/server tool contracts को JSON-RPC, capability negotiation और structured tool calls के साथ औपचारिक रूप देता है MCP. Naly में MCP-style boundaries implicit coupling को कम करती हैं: web search को free-form shell-level व्यवहार के बजाय स्पष्ट capabilities के साथ नियंत्रित tool interface के रूप में मॉडल किया जा सकता है।

साहित्य क्या कहता है

हाल की शोध से पता चलता है कि reliability raw capability के बराबर नहीं होती। AI Agent Reliability paper बताता है कि अलग-अलग रन में task accuracy और consistency के बीच उल्लेखनीय अंतर होता है, और operational evaluation के लिए explicit reliability dimensions (consistency, robustness, predictability, safety) प्रस्तावित करता है Towards a Science of AI Agent Reliability. यह Naly के run-state-first design का समर्थन करता है: अगर कोई run सफल हो पर स्पष्ट artifacts के साथ दोहराया न जा सके, तो वह production-grade नहीं है।

स्ट्रक्चर्ड आउटपुट के संदर्भ में, ToolPRM तर्क देता है कि structured tool-calling behavior को स्पष्ट supervision चाहिए और सुधार तब सबसे मजबूत होता है जब केवल अंतिम परिणाम नहीं, बल्कि internal function-calling process को model किया जाए ToolPRM: Fine-Grained Inference Scaling of Structured Outputs for Function Calling. यह Naly के schema-first runner loop से मेल खाता है: quality gate interface boundaries पर है, केवल सामग्री की fluency पर नहीं।

इसी frontier पर तीसरा paper, SLOT, दिखाता है कि LLMs के ऊपर model-agnostic output-shaping layer जोड़कर एक practical alternative path बनाया जा सकता है SLOT: Structuring the Output of Large Language Models. यह उसी सिद्धांत की पुष्टि करता है: structure reliability एक engineering समस्या है, चाहे base model quality मजबूत हो।

डिज़ाइन trade-offs

1. सख्त schema बनाम मॉडल portability: strict schema downstream ambiguity कम करते हैं, लेकिन providers constraints को अलग तरीके से interpret करने पर कभी-कभी parse churn बढ़ सकता है।
2. Cron simplicity बनाम queue elasticity: cron सरल और दृश्य है, लेकिन bursty workloads में lock-aware backoff या एक queue layer की जरूरत होती है ताकि overlapping runs और missed windows न हों।
3. In-task web search बनाम deterministic replay: नई web search freshness बढ़ाती है लेकिन source volatility लाती है; इसलिए Naly रन artifacts में query text, source list और raw references रखता है।
4. External logs बनाम केवल DB-only logs: filesystem logs process restart होने पर भी बने रहते हैं और ingestion के लिए सस्ते होते हैं; DB logs query ergonomics सरल करते हैं लेकिन यदि सही से partition न किए जाएँ तो open loops में विफल हो सकते हैं।

विफलता के मोड

• Schema drift: provider output schema का उल्लंघन करता है; निवारण है strict validation fail-fast, schema version pinning, और dead-letter runs।
• Overlapping cron executions: double writes या duplicate external actions; निवारण है advisory lock + process-exit guard।
• Search instability: प्रयासों के बीच upstream tool response बदल सकता है; निवारण है retry caps, exponential delay, और persisted upstream references।
• Timing surprises: DST और host टाइमज़ोन का अंतर schedule semantics को प्रभावित कर सकता है; निवारण है UTC scheduling policy और स्पष्ट environment checks।
• Silent partial writes: parse सफल होता है लेकिन downstream write fail हो जाती है; निवारण है transactional persistence ordering और idempotent upserts।
• Security/context leakage: कोई भी tool-capable agent path अधिक आगे बढ़ सकता है, इसलिए MCP-like least-privilege boundaries और स्पष्ट consent/auth assumptions जरूरी हैं, खासकर जहाँ tool execution paths नेटवर्क संसाधनों को touch करते हैं MCP security notes।

कार्यान्वयन नोट्स

• एक business task में केवल एक worker command रखें scripts/ और cron को केवल उसी entrypoint को call करने दें।
• schema file hash को रन metadata में रखें ताकि model upgrade के बाद parser अपेक्षाओं का ऑडिट संभव हो।
• Set करें set -euo pipefail-style behavior wrapper scripts में और हमेशा log नामों में रन IDs शामिल करें।
• लॉग में तीन checkpoints लिखें: started, codex_result_parsed, artifact_persisted।
• Use NALY_LOG_ROOT ताकि runtime traces repository state को प्रदूषित न करें और restart संदर्भों में भी बने रहें।
• Persist attempt, exit_code, retry_reason, और validation_errors ताकि GST और audit dashboards वास्तविक मॉडल regressions को flaky infra से अलग कर सकें।

संदर्भ

• Codex CLI | OpenAI Developers
• OpenAI Codex repository
• Structured Outputs | OpenAI API
• Model Context Protocol specification
• crontab(5) manual page
• flock(1) manual page
• Towards a Science of AI Agent Reliability
• ToolPRM: Fine-Grained Inference Scaling of Structured Outputs for Function Calling
• SLOT: Structuring the Output of Large Language Models