Naly ইঞ্জিনিয়ারিং নোট: Codex CLI, কাঠামোবদ্ধ JSON এবং ক্রন-সুরক্ষিত AI ওয়ার্কার

সারাংশ

Naly নির্ধারিত AI কাজের জন্য Codex CLI-কে কন্ট্রোল প্লেন হিসেবে ব্যবহার করে: প্রতিটি ক্রন এন্ট্রি একটি চেক-ইন করা স্ক্রিপ্ট চালায় যা ওয়েব সার্চ ও কঠোর আউটপুট চুক্তি সহ একটি সীমাবদ্ধ সহকারী কাজ শুরু করে, তারপর পরবর্তী প্রকাশ, রিপ্লে এবং রিট্রাইয়ের জন্য যাচাইকৃত JSON আর্টিফ্যাক্ট লিখে। এতে মডেল কাজটি একটি অপারেশনাল পাইপলাইনের মতো আচরণ করে—একই কমান্ড, স্পষ্ট স্কিমা, স্পষ্ট আর্টিফ্যাক্ট—বরং পরিবর্তনশীল ইন্টারঅ্যাক্টিভ ওয়ার্কফ্লোর মতো নয়। 2026-06-25 অনুযায়ী, এই পার্থক্যটি গ্রোথ-ক্রিটিক্যাল কন্টেন্ট ইনফ্রার জন্য নির্ভরযোগ্যতার সুবিধা।

Naly-তে এটি কোথায় অবস্থান করে

Naly-তে ইতোমধ্যেই ডিসকভারি, রিটেনশন এবং ডিস্ট্রিবিউশন ওয়ার্কফ্লো ঘিরে সক্রিয় GST অগ্রাধিকার রয়েছে। এই প্যাটার্নটি সরাসরি সেই বাস্তবায়ন স্তরের সাথে মিলে যায়।

• Cron job একটি একক tsx স্ক্রিপ্ট প্রতি ব্যবহার-ক্ষেত্রে চালু করে যাতে প্রতিটি রান ভার্সনড কোডের মধ্যে থাকে, কোনো অনানুষ্ঠানিক শেল স্নিপেটের মধ্যে নয়।
• Codex CLI যুক্তি ও রিট্রিভাল কাজটি সম্পন্ন করে, আর Naly orchestration control হ্যান্ডেল করে: schedule, রিট্রাই, লকিং এবং স্থায়ী আর্টিফ্যাক্ট।
• কাঠামোবদ্ধ আউটপুট downstream সিস্টেমে প্রবাহিত হয় যা Next.js, React, Drizzle ORM এবং Neon-এর উপর নির্মিত—যেখানে স্কিমা অনুমানের প্রয়োজন নেই।
• বহিঃস্থ লগ ও রান মেটাডেটা লিখে রাখা হয় NALY_LOG_ROOT, যার ফলে পোস্ট-মর্টেম প্রক্রিয়া প্রক্রিয়া-আউটপুট বাফারিং থেকে স্বাধীনভাবে পুনরুত্পাদনযোগ্য থাকে।

মূল থিসিসটি হলো: production ব্যবহারে LLM গুণগত মান শুধু সিস্টেমের অর্ধেক; ওই LLM-কে ঘিরে নির্ধারিত সীমানাই বাকি অর্ধেক।

প্রযুক্তিগত প্রক্রিয়া

1) চুক্তি-প্রথম ওয়ার্কার এন্ট্রি-পয়েন্ট

প্রতিটি কাজ শুরু হয় তিনটি অপরিবর্তনীয় ইনপুট দিয়ে:

• একটি কোডিফায়েড প্রম্পট টেমপ্লেট এবং কাজের উদ্দেশ্য।
• একটি response স্কিমা যা যাচাই করতে হবে।
• একটি রান এনভেলপ (run_id, source_query, attempt, env), API কলের আগে স্থায়ীভাবে সংরক্ষণ করা হয়।

Naly cron থেকে Codex CLI ব্যাচ মোডে চালায়, ইন্টারঅ্যাক্টিভ মোডে নয়। Codex একটি লোকাল coding agent হিসেবে নথিভুক্ত এবং ওপেন-সোর্স বিতরণ ও সক্রিয় রিলিজসহ একটি standalone CLI হিসেবে সরবরাহ করা হয়েছে, এবং স্ক্রিপ্টেড পরিবেশে চালানো যায় Codex CLI, OpenAI Codex repo।

2) কেন কাঠামোবদ্ধ আউটপুট অ-আলোচনীয়

OpenAI structured-output গাইডে parser-supported schema extraction এবং মেশিন পাইপলাইনের জন্য প্রয়োজনীয় strict mode আচরণের বর্ণনা আছে। Naly-তে মডেল আউটপুটকে চূড়ান্ত সত্য হিসেবে নয়, মধ্যবর্তী আর্টিফ্যাক্ট হিসেবে ধরা হয়, তাই JSON চুক্তির মাধ্যমেই নির্ভরযোগ্যতা প্রয়োগ করা হয়:

• প্রয়োজনীয় ফিল্ড (headline, evidence list, confidence, citations, failure reason)
• ডিফল্টসহ ঐচ্ছিক ফিল্ড
• সংখ্যাগত confidence এবং সীমাবদ্ধ enums
• স্পষ্ট parser ব্যর্থতা রান এরর হিসেবে দেখানো হয়, নীরবে স্বয়ংক্রিয়ভাবে সংশোধিত টেক্সট হিসেবে নয়।

3) ক্রন থেকে এজেন্ট লাইফসাইকেল ও কনকারেন্সি কন্ট্রোল

Cron 5-ফিল্ড টাইমিং ফর্ম্যাট অনুযায়ী নির্ধারিত লাইনগুলো কার্যকর করে এবং যখন ফিল্ডগুলো মিলে যায় তখন একটি কমান্ড শুরু করে crontab. production safety-এর জন্য Naly অতিরিক্তভাবে যোগ করে:

• লক গার্ড (প্রতি টাস্কে একটিমাত্র সক্রিয় রান)
• idempotent রান কী
• জিটারসহ সীমিত রিট্রাই পলিসি
• প্রতিটি ধাপের জন্য বহিঃস্থ লগ ক্যাপচার
• Drizzle/Neon দ্বারা পরিচালিত ডেটাবেস টেবিলে পোস্ট-রান state update।

flock এই guardrail প্যাটার্নের জন্য এটি ঠিকভাবে ডিজাইন করা: একটি লক নিন, critical section চালান, আগে থেকেই লকড থাকলে পরিষ্কারভাবে exit করুন flock, কারণ lock state ফাইল ডিসক্রিপ্টরকে অনুসরণ করে; ফলে ওভারল্যাপিং ক্রন উইন্ডোগুলো স্পষ্টভাবে নিষিদ্ধ হয় এবং state corrupt করে না।

4) এই প্যাটার্নে MCP কেন গুরুত্ব পায়

Model Context Protocol JSON-RPC, capability negotiation এবং কাঠামোবদ্ধ tool call ব্যবহার করে host/client/server tool contract ফরমালাইজ করে MCP। Naly-তে MCP-স্টাইল সীমানা অন্তর্নিহিত coupling কমায়: ওয়েব সার্চকে একটি নিয়ন্ত্রিত টুল ইন্টারফেস হিসেবে উপস্থাপন করা যায় যেখানে স্পষ্ট ক্ষমতা থাকে, ফ্রি-ফর্ম শেল-লেভেল আচরণের পরিবর্তে।

সাহিত্য যা বলছে

সাম্প্রতিক গবেষণা দেখায় নির্ভরযোগ্যতা কাঁচা ক্ষমতার সমান নয়। AI Agent Reliability পেপারে কাজের যথার্থতা এবং চালনার সামঞ্জস্যের মধ্যে উল্লেখযোগ্য ফাঁক দেখানো হয়েছে এবং অপারেশনাল মূল্যায়নের জন্য explicit reliability dimensions (consistency, robustness, predictability, safety) প্রস্তাব করা হয়েছে Towards a Science of AI Agent Reliability. এটি Naly-এর run-state-first নকশাকে সমর্থন করে: কোনো রান সফল হলেও যদি পরিষ্কার আর্টিফ্যাক্ট সহ পুনরুত্পাদনযোগ্য না হয়, তবে সেটি production-grade নয়।

Structured outputs-এর জন্য ToolPRM যুক্তি দেয় যে structured tool-calling আচরণে explicit supervision দরকার এবং উন্নতি বেশি দেখা যায় যখন কেবল চূড়ান্ত ফল নয়, অভ্যন্তরীńত function-calling প্রক্রিয়াকেও মডেল করা হয় ToolPRM: Fine-Grained Inference Scaling of Structured Outputs for Function Calling. এটি Naly-এর schema-first runner loop-এর সাথে সামঞ্জস্যপূর্ণ: গুণগত গেট থাকে interface boundaries-এ, শুধু content fluency-তে নয়।

LLM-এর উপর একই frontier-এ তৃতীয় একটি পেপার, SLOT, দেখায় model-agnostic output-shaping layer যুক্ত করার একটি বাস্তব বিকল্প পদ্ধতি SLOT: Structuring the Output of Large Language Models. এটি একই নীতিকে শক্তিশালী করে: ভিত্তিগত মডেল গুণগত হলেও structure reliability এখনও একটি প্রকৌশলগত সমস্যা।

Design trade-offs

1. Strict schema বনাম model portability: strict schema downstream অস্পষ্টতা কমায় কিন্তু যখন ভিন্ন provider একই সীমাবদ্ধতা আলাদা ভাবে ব্যাখ্যা করে তখন মাঝে মাঝে parse churn বাড়তে পারে।
2. Cron সহজতা বনাম queue elasticity: cron সহজ ও দৃশ্যমান, কিন্তু bursty workload-এ lock-aware backoff বা queue layer দরকার যেন overlapping runs এবং missed windows না হয়।
3. In-task web search বনাম deterministic replay: fresh web search freshness বাড়ায় কিন্তু source volatility আনতে পারে; তাই Naly run artifacts-এ query text, source list এবং raw references সংরক্ষণ করে।
4. External logs বনাম শুধুই DB logs: ফাইলসিস্টেম লগ প্রসেস রিস্টার্টে টিকে থাকে এবং ইনজেশন খরচ কম; DB logs query ergonomics সহজ করে কিন্তু সাবধানে partition না করলে open loops ব্যর্থ করতে পারে।

Failure modes

• Schema drift: provider output স্কিমা লঙ্ঘন করে; প্রতিকার হলো strict validation fail-fast, schema version pinning, এবং dead-letter runs।
• Overlapping cron executions: দ্বিগুণ লিখন বা ডুপ্লিকেট বাইরে কার্যকলাপ; প্রতিকার হলো advisory lock + process-exit guard।
• Search instability: upstream tool response চেষ্টা ভেদে বদলায়; প্রতিকার হলো retry caps, exponential delay, এবং persisted upstream references।
• Timing surprises: DST এবং হোস্ট টাইমজোন পার্থক্য schedule semantics প্রভাবিত করতে পারে; প্রতিকার হলো UTC scheduling policy এবং স্পষ্ট environment checks।
• Silent partial writes: parse সফল হলেও downstream write ব্যর্থ হতে পারে; প্রতিকার হলো transactional persistence ordering এবং idempotent upserts।
• Security/context leakage: যে কোনো tool-capable agent path অতিরিক্ত কাজ করতে পারে, তাই MCP-ধাঁচের least-privilege boundary এবং স্পষ্ট consent/auth অনুমান দরকার, বিশেষত যেখানে tool execution path নেটওয়ার্ক রিসোর্সে পৌঁছায় MCP security notes।

বাস্তবায়ন নোট

• ব্যবসায়িক প্রতিটি কাজের জন্য একটি ওয়ার্কার কমান্ড রাখুন scripts/ এবং cron যেন শুধু সেই এন্ট্রি-পয়েন্টটি কল করে।
• স্কিমা ফাইল হ্যাশ run metadata-তে সংরক্ষণ করুন যাতে মডেল আপগ্রেডের পরও parser প্রত্যাশা audit করা যায়।
• Set set -euo pipefail-e ধরনের আচরণ wrapper script-এ এবং লগ নামগুলোতে সব সময় রান আইডি অন্তর্ভুক্ত করুন।
• লগে তিনটি চেকপয়েন্ট লিখুন: started, codex_result_parsed, artifact_persisted।
• Use NALY_LOG_ROOT runtime traces যেন repository state দূষিত না করে এবং restart contexts-এ টিকে থাকে সেইভাবে।
• Persist attempt, exit_code, retry_reason, এবং validation_errors GST এবং audit dashboards-কে flaky infra ও আসল model regressions আলাদা করতে দেওয়ার জন্য।

References

• 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