pjandro/OmniRoute
1
0
Fork 0
mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-09-21 22:32:22 +03:00
Code Issues Packages Projects Releases Wiki Activity
Files
af2002a49349ca60d7e804c7d0470ac4e58fee97
OmniRoute/docs/i18n/ne/docs/ops/RELEASE_CHECKLIST.md
Diego Rodrigues de Sa e Souza 58f88a83e4 feat(i18n): 7 new locales — Hausa, Yoruba, Igbo, Amharic, Uzbek, Georgian, Armenian (66 locales) (#13727) 
Batch 3 (last) of the locale-expansion plan: ha, yo, ig, am, uz, ka, hy on every surface — dashboard catalog, docs mirror (22-file core + llm.txt + CHANGELOG), CLI catalog, README flag block, locale tables and 🌐 language bars. Also closes the key gap the batch-1 (43 keys) and batch-2 (10 keys) catalogs carried since their base merges, fixes the Igbo "Model" copy and allowlists the Uzbek cognate. Translation-ratio baseline covers 65 locales.

⚠️ base-red inherited: #12732
2026-09-15 09:50:01 -03:00

46 KiB
Raw Blame History

RELEASE_CHECKLIST (नेपाली)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

title: "रिलिज चेकलिस्ट" version: 3.8.51 lastUpdated: 2026-08-28

रिलिज चेकलिस्ट

अन्तिम पटक अद्यावधिक गरिएको: 2026-08-28 — v3.8.51 स्वचालनका लागि Claude Code सीपहरू प्रयोग गर्ने सुव्यवस्थित रिलिज प्रवाह।

रिलिजहरूबीच queue/branch लाई हरियो राख्नुहोस्: RELEASE_GREEN.md हेर्नुहोस् (/green-prs परिवार + npm run check:release-green + /babysit + रात्रीकालीन प्रक्रिया)। यसलाई आवधिक रूपमा — र विशेषगरी यो चेकलिस्टभन्दा अघि — चलाउँदा रिलिज PR सुरुदेखि नै हरियो हुन्छ।

छोटकरीमा

# 1. संस्करण बढाउनुहोस् + CHANGELOG उत्पन्न गर्नुहोस् (सीप)
/version-bump-cc patch    # वा minor/major

# 2. स्थानीय रूपमा गुणस्तर गेट चलाउनुहोस्
npm run check              # lint + परीक्षणहरू
npm run test:coverage      # पूर्ण कभरेज गेट (60/60/60/60)

# 3. बिल्ड र स्मोक परीक्षण
npm run build
npm run test:e2e           # वैकल्पिक तर सिफारिस गरिएको

# 4. रिलिज उत्पन्न गर्नुहोस् (सीप)
/generate-release-cc

# 5. डिप्लोय गर्नुहोस् (सीप)
/deploy-vps-both-cc        # वा akamai-cc / local-cc

# 6. रिलिज प्रमाणहरू सङ्कलन गर्नुहोस् (सीप)
/capture-release-evidences-cc

npm विश्वसनीय प्रकाशन (v3.8.51 देखि पूर्वनिर्धारित) — अनुरोधमा staged, वैकल्पिक उपायका रूपमा direct

npm-publish.yml ले पूर्वनिर्धारित रूपमा npm Trusted Publishing (OIDC) मार्फत प्रकाशन गर्छ: stage-npm job (github-hosted) ले त्यस रनका लागि GitHub को id-token लाई छोटो अवधिको npm प्रमाणपत्रसँग साट्छ — repository secrets मा लामो अवधिको npm token हुँदैन, 2FA prompt हुँदैन, र provenance संलग्न हुन्छ। 2FA छल्ने tokens हटाइँदै गर्दा npm ले अब स्वीकृत गरेको bypass यही हो; यसले WS1.3 को प्रत्याभूति कायम राख्दै परियोजनामा v3.8.48 सम्म रहेको पूर्ण स्वचालित प्रवाह पुनर्स्थापित गर्छ (चुहिएको token ले एक्लै प्रकाशन गर्न सक्दैन — किनकि कुनै token नै हुँदैन)।

एकपटकको सेटअप (owner): npmjs.com → package omniroute → Settings → Trusted Publisher → GitHub: owner diegosouzapw, repo OmniRoute, workflow npm-publish.yml (environment: none)। यो उपलब्ध नभएसम्म स्वचालित चरण ENEEDAUTH सहित असफल हुन्छ: publish_mode=staged (तल) वा direct प्रयोग गरेर पुनः dispatch गर्नुहोस्।

Staged प्रकाशन (अनुरोधमा — publish_mode=staged)

npm-publish workflow ले अब सीधै प्रकाशन गर्दैन: यसले प्याक गरिएको tarball (check:pack-boot) लाई boot गर्छ र त्यसपछि npm stage publish चलाउँछ — owner ले अनुमोदन नगरेसम्म ठ्याक्कै ती bytes registry मा राखिन्छन्, तर install गर्न मिल्दैनन्। मानवीय 2FA gate प्रमाणभन्दा अघि नभई त्यसपछि सारिएको छ।

Workflow हरियो भएपछि owner को प्रवाह:

  1. npm stage list omniroute — stage id फेला पार्नुहोस् (workflow summary मा पनि प्रिन्ट गरिन्छ)।
  2. Staged bytes प्रमाणित गर्नुहोस् (सिफारिस गरिएको): npm stage download <id>, त्यसपछि डाउनलोड गरिएको tarball लाई अस्थायी prefix मा install गरेर boot गर्नुहोस् (npm run check:pack-boot ले CI मा यही pack→install→boot निर्णय स्वचालित गर्छ)।
  3. npm stage approve <id> — 2FA prompt नै प्रकाशन हो। npm stage reject <id> ले खारेज गर्छ।
  4. प्रकाशनपछिको सुरक्षा-जाल: प्रकाशनपछिको verifier (v3.8.49 योजनाको WS1.4) ले प्रकाशित संस्करणलाई सफा container मा सार्वजनिक registry बाट install गरेर boot गर्छ।

आपत्कालीन वैकल्पिक उपाय: publish_mode=direct सहितको workflow_dispatch ले पुरानो तत्कालीन npm publish पुनर्स्थापित गर्छ (staging स्वयंले गलत व्यवहार गरेमा मात्र प्रयोग गर्नुहोस्; कारण अभिलेख गर्नुहोस्)।

एकपटकको सुदृढीकरण (owner, npmjs.com): omniroute का लागि Trusted Publisher लाई stage-only mode मा कन्फिगर गर्नुहोस्, ताकि चुहिएको लामो अवधिको token ले कहीँबाट पनि सीधै npm publish गर्न नसकोस् — CI ले stage मात्र गर्न सक्छ; owner को 2FA ले मात्र रिलिज गर्छ।

बिग्रिएको artifact का लागि playbook (अपरिवर्तित): पूर्वनिर्धारित प्रतिक्रियाका रूपमा npm deprecate omniroute@<bad> "<reason> — use <fixed>" प्रयोग गर्नुहोस् (केही मिनेटमै, उल्ट्याउन मिल्ने); npm unpublish लाई 72h/no-dependents सीमाभित्र मात्र प्रयोग गर्नुहोस् र पहिलो कदमका रूपमा कहिल्यै नचलाउनुहोस्। Docker: version tag कहिल्यै पुनर्लेखन नगर्नुहोस् — rollback भनेको latest लाई पछिल्लो राम्रो digest तर्फ पुनः देखाउनु हो।

Docker Hub latest (हरेक स्थिर SemVer प्रकाशनमा आवश्यक): docker-publish workflow ले दुवै X.Y.Z लाई र, जब should-promote-latest.sh ले यो उच्चतम स्थिर SemVer हो भनी सहमति जनाउँछ, :latest लाई एउटै digest सहित tag गर्नुपर्छ। Job पछि: Hub को latest digest नयाँ SemVer digest सँग बराबर हुन्छ र last_updated अगाडि सरेको हुन्छ। रिलिज नोटहरूले git मा मात्र भएका सुधारहरूबारे बताइरहेको अवस्थामा :latest लाई पुरानो build मै नछोड्नुहोस्। Compose quickstarts ले :latest प्रयोग गर्छन्; GitOps ले X.Y.Z मै pin गरिरहनुपर्छ। Docker रिलिज च्यानलहरू र #10317 हेर्नुहोस्।

हटफिक्स फास्ट-लेन (लेबल hotfix)

hotfix लेबल लगाइएको PR ले भारी CI म्याट्रिक्स (9-shard E2E, coverage ratchet, quality-gate, quality-extended) छोड्छ र छिटो, उच्च-सङ्केतयुक्त गेटहरू कायम राख्छ: build, unit shards, integration, vitest, lint/typecheck, docs-sync, check:pack-artifact र tarball boot-smoke (check:pack-boot)। लक्ष्य: ~33min को सट्टा ≤15min मा हरियो।

प्रवेश नीति — चारवटै अनिवार्य (Chromium/VS Code/Node का आपत्कालीन लेनहरूमा आधारित):

  1. गम्भीरता: उत्पादन बिग्रिएको छ — प्रकाशित artifact बुट हुँदा क्र्यास हुन्छ / सुरक्षा समाधान / रिलीजका प्रत्येक प्रयोगकर्ता प्रभावित छन्। "महत्त्वपूर्ण" भनेको "बिग्रिएको" होइन।
  2. अधिकार: repository मालिकले मात्र hotfix लेबल लगाउँछन्। लेबल नै स्वीकृति हो — campaign PR मा कहिल्यै स्वयं-सेवा नगर्नुहोस्।
  3. प्रमाण: PR body ले अघिल्लो पूर्ण रूपमा हरियो heavy run (छोडिएका job हरूले पुनः प्रमाणीकरण गर्ने suite) र समाधानको आफ्नै पहिले असफल-त्यसपछि-सफल परीक्षण लिंक गर्छ।
  4. दायरा: cherry-pick मात्र — न्यूनतम समाधान, कुनै refactor वा असम्बन्धित परिवर्तन हुँदैन।

छोडिएको coverage/ratchet सतहलाई release branch मा हुने अर्को full run (निरन्तर release-green) द्वारा पुनः प्रमाणीकरण गरिन्छ — लेनले प्रतीक्षा मात्र छोड्छ, प्रमाणीकरण कहिल्यै छोड्दैन। परीक्षण-मात्रका diff हरू (tests/ अन्तर्गतका सबै फाइल, tests/e2e/ अन्तर्गत कुनै पनि नभएको) ले कुनै लेबलविना स्वचालित रूपमा E2E म्याट्रिक्स छोड्छन्।

विस्तृत जाँचसूची

रिलीजपूर्व

  • यस रिलीजका लागि लक्षित सबै PR हरू release/vX.Y.0 मा merge भएका छन्
  • यस संस्करणका सबै खुला Linear/issue item हरू बन्द गरिएका वा अर्को milestone मा सारिएका छन्
  • release/vX.Y.0 branch मा CI हरियो छ
  • कोडमा कुनै TODO(release) marker छैन: grep -r "TODO(release)" src/ open-sse/
  • Docker base image अद्यावधिक छ (हाल node:24.15.0-trixie-slim)

संस्करण र परिवर्तन विवरण

  • /version-bump-cc <patch|minor|major> चलाउनुहोस् (Claude Code skill)
    • package.json, electron/package.json को संस्करण बढाउँछ
    • पछिल्लो tag यताका git commit हरूबाट CHANGELOG.md पुनः उत्पन्न गर्छ
    • README.md badge हरू अद्यावधिक गर्छ
  • CHANGELOG.md लाई म्यानुअल रूपमा समीक्षा गर्नुहोस् र आवश्यक भए commit message हरू सफा गर्नुहोस्
  • CHANGELOG.md को पछिल्लो semver section package.json को version सँग बराबर भएको सुनिश्चित गर्नुहोस्
  • आगामी कामका लागि ## [Unreleased] लाई पहिलो changelog section का रूपमा राख्नुहोस्
  • docs/openapi.yaml अद्यावधिक गर्नुहोस् → info.version package.json को version सँग बराबर हुनुपर्छ

कोड गुणस्तर

  • npm run lint — 0 त्रुटि (चेतावनीहरू पहिलेदेखि नै छन्)
  • npm run typecheck:core — त्रुटिरहित
  • npm run typecheck:noimplicit:core — त्रुटिरहित (कडा)
  • npm run check:cycles — कुनै circular dependency छैन
  • npm run check:any-budget:t11 — budget भित्र
  • npm run check:route-validation:t06 — त्रुटिरहित
  • npm run check:node-runtime — समर्थित runtime को न्यूनतम सीमा पूरा भएको (>=22.22.2 <23, >=24.0.0 <27, src/shared/utils/nodeRuntimeSupport.ts को SUPPORTED_NODE_RANGE अनुसार; package.json को engines सँग मिलाइएको)

परीक्षण

  • npm run test:unit — सफल
  • npm run test:vitest — सफल (MCP server, autoCombo, cache)
  • npm run test:coverage — gate 60/60/60/60 पूरा भएको (statements/lines/functions/branches)
  • npm run test:integration — सफल (परिवर्तनले DB / handler छोएमा)
  • npm run test:combo:matrix — सफल (combo strategy matrix: सबै 19 सार्वजनिक routing strategy का selection decision हरूलाई निर्धारणात्मक रूपमा प्रमाणित गर्छ; combo routing, strategy resolution वा fallback logic छुँदा चलाउनुहोस्)
  • RUN_COMBO_LIVE=1 npm run test:combo:live — वैकल्पिक/म्यानुअल (गेट गरिएको वास्तविक-upstream smoke; VPS root@192.168.0.15 बाट read-only DB snapshot लिन्छ; वास्तविक provider हरू प्रयोग गर्छ, credit खर्च हुन्छ; CI मा कहिल्यै चल्दैन; gate नभए सफा रूपमा छोडिन्छ)
  • npm run test:combo:live:vps — वैकल्पिक/म्यानुअल (Phase-3 VPS live smoke: plain Node ESM मार्फत live .15 server विरुद्ध 7 HTTP scenario; ssh root@192.168.0.15 आवश्यक; __live_test__* combo हरू मात्र सिर्जना/मेटाउँछ; वास्तविक provider हरू प्रयोग गर्छ; CI मा कहिल्यै चल्दैन)
  • npm run test:e2e — सफल (UI परिवर्तनहरू)
  • npm run test:protocols:e2e — सफल (MCP/A2A परिवर्तनहरू)
  • npm run test:ecosystem — सफल

हुकहरू (Husky द्वारा प्रमाणीकरण गरिएको)

Husky hook हरू .husky/ मा हुन्छन् र git operation का बेला स्वचालित रूपमा चल्छन्।

  • pre-commit: npx lint-staged + node scripts/check/check-docs-sync.mjs + npm run check:any-budget:t11
  • pre-push: छिटा निर्धारणात्मक gate हरू — npm run check:any-budget:t11 && npm run check:tracked-artifacts (2026-06-13 मा सक्रिय गरिएको)। जानाजानी test:unit समावेश गरिएको छैन (ढिलो; CI को test-unit job द्वारा समेटिएको)।
    • release branch push गर्नुअघि npm run test:unit म्यानुअल रूपमा चलाउनुहोस्।

यदि कुनै hook असफल भयो भने: अन्तर्निहित समस्या समाधान गर्नुहोस्, --no-verify प्रयोग गरेर नछल्नुहोस्।

परम्परागत कमिटहरू

रिलीजमा जाने सबै commit हरूले type(scope): subject ढाँचा पालना गर्नुपर्छ।

मान्य type हरू: feat, fix, refactor, docs, test, chore, perf, style, ci

मान्य scope हरू: db, sse, oauth, dashboard, api, cli, docker, ci, mcp, a2a, memory, skills, cloud-agent, guardrails, compression, auto-combo, resilience, providers, executors, translator, domain, authz

Breaking change हरू: BREAKING CHANGE: footer वा scope पछि ! थप्नुहोस् (जस्तै feat(api)!: drop /v0)।

दस्तावेजीकरण

  • npm run check:docs-sync सफल हुन्छ (pre-commit द्वारा स्वतः चलाइन्छ)
  • npm run check:docs-all सफल हुन्छ (समष्टिगत: docs-sync + docs-counts + env-doc-sync + deprecated-versions + doc-links)
  • npm run check:env-doc-sync 0 सहित बन्द हुन्छ — कोड ↔ .env.example ↔ docs/reference/ENVIRONMENT.md env अनुबन्ध अक्षुण्ण छ
  • npm run check:doc-links 0 सहित बन्द हुन्छ — पुनर्संरचनापछि कुनै आन्तरिक markdown सन्दर्भ टुटेका छैनन्
  • भण्डारण/runtime विचलनका लागि docs/architecture/ARCHITECTURE.md समीक्षा गरिएको छ
  • env var र सञ्चालनसम्बन्धी विचलनका लागि docs/guides/TROUBLESHOOTING.md समीक्षा गरिएको छ
  • यदि .env.example परिवर्तन भएको छ भने: docs/reference/ENVIRONMENT.md अद्यावधिक गरिएको छ
  • यदि नयाँ सुविधामा UI छ भने: docs/guides/USER_GUIDE.md मा त्यसको उल्लेख छ
  • यदि नयाँ सुविधामा API छ भने: docs/reference/API_REFERENCE.md + docs/openapi.yaml अद्यावधिक गरिएका छन्
  • यदि नयाँ सुविधा module हो भने: समर्पित docs/<MODULE>.md अवस्थित छ
  • यदि breaking change छ भने: docs/guides/TROUBLESHOOTING.md मा migration टिप्पणी छ

i18n

  • npm run i18n:check 0 सहित बन्द हुन्छ — अनुवाद स्थिति (.i18n-state.json) स्रोत कागजातहरूसँग समक्रमित छ (strict mode मा कुनै विचलित स्रोत छैनन्; अन्तिम क्षणका कागजात परिमार्जनहरूका लागि warn-mode सल्लाह स्वीकार्य छ, तर tagging गर्नुअघि यो 0 हुनुपर्छ)
  • npm run i18n:check-ui-coverage 0 सहित बन्द हुन्छ — प्रत्येक UI locale 80% coverage न्यूनतम सीमामा वा त्यसभन्दा माथि छ
  • npm run i18n:sync-ui:dry ले सबै 42 locale मा 0 हराएका key रिपोर्ट गर्छ
  • यदि स्रोत English कागजातहरू परिवर्तन भएका छन् भने, tagging गर्नुअघि npm run i18n:run चलाउनुहोस् (.env मा OMNIROUTE_TRANSLATION_API_KEY आवश्यक हुन्छ)
  • साना परिवर्तन भएमा अनुवाद योगदानहरू अर्को release सम्म स्थगित गर्न सकिन्छ (CHANGELOG मा ट्र्याक गर्नुहोस्)

Database Migration हरू

  • यदि src/lib/db/migrations/ मा नयाँ file हरू छन् भने:
    • प्रत्येक migration idempotent छ (CREATE TABLE IF NOT EXISTS, आदि)
    • Migration हरू transaction भित्र राखिएका छन्
    • सही रूपमा नम्बर दिइएका छन् (अनुक्रममा कुनै खाली ठाउँ छैन)
  • नयाँ installation मा परीक्षण गर्नुहोस्: ~/.omniroute/omniroute.db मेटाउनुहोस् र npm run dev चलाउनुहोस्
  • विद्यमान installation मा परीक्षण गर्नुहोस्: DB backup गर्नुहोस्, migration चलाउनुहोस्, schema प्रमाणित गर्नुहोस्
  • migration ले table पुनर्लेखन गरेमा WAL file हरू (-wal, -shm) सही रूपमा व्यवस्थापन गरिएका छन्

Provider Catalog (Zod द्वारा प्रमाणित)

  • src/shared/constants/providers.ts को Zod schema load हुने समयमा मान्य छ
    • सबै provider सँग आवश्यक field हरू (id, label, kind, आदि) छन्
    • नयाँ निःशुल्क provider का लागि freeNote प्रदान गरिएको छ
    • OAuth provider हरूको oauthConfig src/lib/oauth/constants/oauth.ts मा दर्ता गरिएको छ
  • यदि नयाँ provider थपिएको छ भने: open-sse/executors/ मा सम्बन्धित executor छ
  • यदि non-OpenAI format हो भने: open-sse/translator/ मा translator छ
  • Model हरू open-sse/config/providerRegistry.ts मा दर्ता गरिएका छन्
  • tests/unit/ का unit test हरूले provider classification र routing समेट्छन्

Desktop (Electron)

यदि electron/ परिवर्तन भएको छ भने:

  • npm run electron:smoke:packaged सफल हुन्छ
  • :win, :mac, :linux मध्ये कम्तीमा एउटाका लागि build परीक्षण गरिएको छ
  • Code signing certificate हरूको म्याद सकिएको छैन (signing गरिँदै छ भने)
  • electron/package.json को version मूल package.json सँग मेल खान्छ
  • stable मा release गरिँदै छ भने auto-update channel pointer अद्यावधिक गरिएको छ

Build संरचना

Repository ले तीनवटा भिन्न output directory प्रयोग गर्छ — तिनलाई कहिल्यै नमिसाउनुहोस्:

Directory उद्देश्य ट्र्याक गरिएको?
src/ Application source (TypeScript / TSX) हो
.build/ Build intermediate हरू — next build output (distDir) होइन (gitignored)
dist/ वितरणयोग्य npm bundle — assembleStandalone द्वारा संयोजित होइन (gitignored)

Operator टिप्पणी: remote VPS image directory /usr/lib/node_modules/omniroute/app/ नै रहन्छ। केवल in-repo build output सरेको हो (app/ → dist/)। Deploy skill हरूले dist/ का सामग्री remote app/ dir मा rsync गर्छन् — VPS path परिवर्तन गर्न आवश्यक छैन।

एकल-build प्रवाह:

npm run build:release
  └─ rm -rf .build dist          (clean)
  └─ next build → .build/next/   (intermediates)
  └─ assembleStandalone          (copies standalone + static + public + natives → dist/)
  └─ writes dist/BUILD_SHA       (HEAD sentinel)

Deploy का लागि npm run build चलाएर त्यसपछि छुट्टै npm run build:cli नचलाउनुहोस् — एउटै command मा clean rebuild + sentinel गर्ने npm run build:release प्रयोग गर्नुहोस्।

Artifact प्रमाणीकरण

  • npm run build:release सफल हुन्छ र dist/BUILD_SHA == git rev-parse --short HEAD
  • npm run check:pack-artifact सफा छ — कुनै app.__qa_backup, scripts/scratch, package-lock.json, वा अन्य स्थानीय अवशेष छैन
  • Build पछि dist/server.js अवस्थित छ

Tagging र Release

  • /generate-release-cc (Claude Code skill) चलाउनुहोस्:
    • vX.Y.Z tag सिर्जना गर्छ
    • Tag र branch push गर्छ
    • Changelog body सहित GitHub Release खोल्छ
    • Electron installer हरू संलग्न गर्छ (build गरिएको भए)
  • वा manually: 
    git tag -a vX.Y.Z -m "Release vX.Y.Z"
git push origin vX.Y.Z
gh release create vX.Y.Z --notes-from-tag

Deploy

Deploy skill हरूले हल्का rsync प्रवाह प्रयोग गर्छन् — npm pack छैन, npm i -g छैन:

  • Target सँग मेल खाने deploy skill प्रयोग गर्नुहोस्:
    • /deploy-vps-local-cc — स्थानीय VPS (192.168.0.15)
    • /deploy-vps-akamai-cc — Akamai VPS (69.164.221.35)
    • /deploy-vps-both-cc — दुवै
  • Deploy गर्नुअघि, dist/BUILD_SHA == git rev-parse --short HEAD पुष्टि गर्नुहोस्
  • Build त्यहीँ चल्नुपर्छ जहाँ node_modules वास्तविक छ (मुख्य checkout वा npm ci गरिएको worktree — symlink गरिएको worktree होइन)
  • Deploy गरिएको instance को smoke test गर्नुहोस्:
    • /dashboard/health खोल्नुहोस् → version string release सँग मेल खान्छ भनी जाँच गर्नुहोस्
    • ज्ञात provider विरुद्ध /v1/chat/completions request चलाउनुहोस्
    • /api/monitoring/health ले CLOSED circuit breaker हरू फर्काउँछ भनी प्रमाणित गर्नुहोस्
    • MCP transport हरूले प्रतिक्रिया दिन्छन् भनी पुष्टि गर्नुहोस् (/mcp HTTP, /mcp-sse SSE)

Release पछिका कार्यहरू

  • /capture-release-evidences-cc चलाउनुहोस् (Claude Code skill)
    • नयाँ सुविधाहरूका WebP स्क्रिनसट/रेकर्डिङहरू सङ्कलन गर्छ
    • रिलिज नोटहरू / ब्लग पोस्टमा संलग्न गर्छ
  • रिलिज घोषणासहित GitHub Discussions / Discord अद्यावधिक गर्नुहोस्
  • अर्को संस्करणका लागि माइलस्टोन खोल्नुहोस्
  • गम्भीर भएमा: छलफललाई पिन गर्नुहोस् वा इन-एप ब्यानरका लागि news.json मा पोस्ट गर्नुहोस्

Radar सार्वजनिक-लन्च गेट

Radar घोषणा जानाजानी active: false सहित कमिट गरिएको छ। तलका प्रत्येक बुँदाको प्रमाण उपलब्ध भएपछि सक्रियकरण छुट्टै परिवर्तनका रूपमा गरिन्छ:

  • स्ट्याक गरिएका सबै Radar PR हरू मर्ज भएका छन् र release-tip CI हरियो छ
  • RADAR_ENABLED लाई पूर्वनिर्धारित रूपमा अझै बन्द राखेर OSS Radar रुटहरू डिप्लोय र स्मोक-टेस्ट गर्नुहोस्
  • तोकिएको Radar होस्टमा GET /planos, /termos, /privacidade, र /reembolso स्मोक-टेस्ट गर्नुहोस्
  • निजी सेवामा अपरेटरको पहिचान/सम्पर्क/ठेगाना र मालिकद्वारा स्वीकृत कानुनी समीक्षाको अभिलेख राख्नुहोस्
  • Stripe Checkout र हस्ताक्षरित वेबहुकलाई परीक्षण मोडमा मात्र प्रयोग गरी जाँच गर्नुहोस्
  • स्वीकृत प्रेषक/डोमेनबाट एउटा इन्क्रिप्ट गरिएको कारोबारसम्बन्धी इमेल डेलिभरी परीक्षण गर्नुहोस्
  • ब्याकअप पुनर्स्थापना र एउटा पर्यवेक्षित, बजेट-सीमित अनुसन्धान रन सफल भएको प्रमाणित गर्नुहोस्
  • चन्दाको प्रमाण स्वीकार गर्नुअघि BRL/PIX समीक्षा नीति स्वीकृत गर्नुहोस्
  • अघिल्ला गेटहरू पूरा भएपछि मात्र सार्वजनिक Checkout सक्षम गर्नुहोस्, त्यसपछि नयाँ news.json ID सक्रिय गर्नुहोस्
  • Home ब्यानरले स्थानीयकृत पाठ प्रयोग गरेको र पुरानो ID खारेज गरिएपछि नयाँ ID पुनः देखा पर्ने कुरा प्रमाणित गर्नुहोस्

Embedded Services स्मोक परीक्षण (v3.8.4+)

Embedded services सम्बन्धी परिवर्तनहरू समावेश भएको कुनै पनि रिलीज पठाउनुअघि, निम्न कुरा प्रमाणित गर्नुहोस्:

नयाँ-DB बुट (माइग्रेसन टकरावहरू पत्ता लगाउँछ — v3.8.4 hotfix पछि थपिएको)

  • DATA_DIR=$(mktemp -d) npm start & — बुट हुन 10 s पर्खनुहोस्
  • curl -s http://127.0.0.1:20128/api/services/9router/status | jq '.tool' ले "9router" फर्काउँछ (404 होइन, 500 होइन)। माइग्रेसन 071_services.sql लागू भएको र पङ्क्ति seed गरिएको पुष्टि गर्छ।
  • sqlite3 $DATA_DIR/storage.sqlite "PRAGMA table_info(version_manager);" | grep -E "provider_expose|logs_buffer_path|last_sync_at" ले 3 पङ्क्तिहरू फर्काउँछ।
  • sqlite3 $DATA_DIR/storage.sqlite "PRAGMA table_info(webhooks);" | grep -E "kind|metadata_encrypted" ले 2 पङ्क्तिहरू फर्काउँछ (070_webhooks_kind_metadata.sql लागू भएको प्रमाणित गर्छ)।
  • node --import tsx/esm --test tests/unit/db/no-migration-collisions.test.ts सफल हुन्छ — भविष्यका टकरावहरूबाट सुरक्षा गर्छ।

9Router

  • POST /api/services/9router/install ले 2 min भन्दा कम समयमा installedVersion सहित 200 फर्काउँछ
  • POST /api/services/9router/start ले 30 s भन्दा कम समयमा 200 र state: "running" फर्काउँछ
  • GET /api/services/9router/status ले health: "healthy" रिपोर्ट गर्छ
  • "model": "9router/auto/..." सहित POST /v1/chat/completions ले 200 फर्काउँछ (9Router मार्फत अन्त्यदेखि-अन्त्यसम्म राउटिङ)
  • GET /dashboard/providers/services/9router/embed/dashboard ले प्रोक्सीभित्र 9Router को मूल UI रेन्डर गर्छ (प्रत्यक्ष 127.0.0.1:port iframe हुँदैन)
  • POST /api/services/9router/rotate-key ले { keyRotated: true } फर्काउँछ र सेवा सफा रूपमा पुनः सुरु हुन्छ
  • POST /api/services/9router/stop ले 200 र state: "stopped" फर्काउँछ
  • GET /api/services/9router/logs?tail=50 ले हालैका लाइनहरू समावेश भएको snapshot इभेन्टसहित SSE स्ट्रिम फर्काउँछ
  • PATH मा npm नभएको वातावरणमा इन्स्टल गर्दा मैत्रीपूर्ण (stack trace नभएको) त्रुटि सन्देशसहित 500 फर्काउँछ

CLIProxyAPI

  • POST /api/services/cliproxy/install ले 2 min भन्दा कम समयमा 200 फर्काउँछ
  • POST /api/services/cliproxy/start ले 30 s भन्दा कम समयमा 200 र state: "running" फर्काउँछ
  • GET /api/services/cliproxy/status ले health: "healthy" रिपोर्ट गर्छ
  • POST /api/services/cliproxy/stop ले 200 र state: "stopped" फर्काउँछ
  • GET /api/services/cliproxy/logs?tail=50 ले SSE स्ट्रिम फर्काउँछ

सुरक्षा रिग्रेसन

  • curl -H "X-Forwarded-For: 1.2.3.4" http://localhost:20128/api/services/9router/start ले 403 LOCAL_ONLY फर्काउँछ
  • curl -H "X-Forwarded-For: 1.2.3.4" http://localhost:20128/api/services/cliproxy/start ले 403 LOCAL_ONLY फर्काउँछ
  • /api/services/* बाट आउने त्रुटि प्रतिक्रियाहरूमा err.stack वा निरपेक्ष फाइल पाथहरू हुँदैनन्

v3.8.0+ जाँचहरू

कुनै पनि v3.8.x रिलीज पठाउनुअघि, यी अतिरिक्त बुँदाहरू प्रमाणित गर्नुहोस्:

  • omniroute --tray macOS मा बुट हुन्छ (~/.omniroute/runtime/ मा systray2 इन्स्टल भएको)
  • omniroute --tray Linux मा बुट हुन्छ (DISPLAY आवश्यक हुन्छ; सेट नगरिएको भए शिष्ट त्रुटि)
  • omniroute --tray Windows मा बुट हुन्छ (PowerShell NotifyIcon, कुनै अतिरिक्त बाइनरीहरू छैनन्)
  • omniroute config tray enable ले autostart प्रविष्टि सिर्जना गर्छ; disable ले यसलाई हटाउँछ
  • npm install -g omniroute@<this-version> ले घातक निकासबिना postinstall चलाउँछ
  • अद्यावधिक पाथले वैकल्पिक निर्भरताहरू कायम राख्छ: omniroute update --apply र auto-updater ले npm install -g … --include=optional चलाउँछन्, जसले गर्दा optionalDependencies (better-sqlite3, keytar, tls-client, र llmlingua SLM स्ट्याक: @atjsh/llmlingua-2@2.0.5, js-tiktoken) अद्यावधिकपछि पनि कायम रहन्छन्। ultra modelPath SLM टियरलाई tinybert मोडेल पनि आवश्यक पर्छ, जुन पहिलो प्रयोगमा ${DATA_DIR}/models/llmlingua मा स्वतः डाउनलोड हुन्छ। त्यसपछि Postinstall (scripts/build/colocateOptionals.mjs) ले SLM को वैकल्पिक closure लाई dist/node_modules मा एकै ठाउँमा राख्छ, जसले गर्दा worker ले एउटै @huggingface/transformers ^4.2.0 instance resolve गर्छ — standalone trace ले dynamically-import गरिएका optionals होइन, transformers मात्र bundle गर्छ, त्यसैले यसबिना worker ले root को transformers विरुद्ध llmlingua-2 लोड गर्ने थियो र SLM टियरले कुनै सूचना नदिई fail-open गर्ने थियो।
  • omniroute status ले .env बिना काम गर्छ (CLI token पाथ, loopback मात्र)
  • curl http://localhost:20128/api/shutdown ले 401 फर्काउँछ (सधैँ-सुरक्षित route)
  • curl -H "host: evil.com" http://localhost:20128/api/mcp/sse ले 401 फर्काउँछ (loopback guard)
  • पहिलो पटक चलाउँदा SQLite runtime bundled मा resolve हुन्छ (प्लेटफर्मका लागि bundled binary मान्य)
  • node_modules/better-sqlite3 मेटाउँदा SQLite runtime runtime मा fallback हुन्छ
  • Smart MCP filter ले वास्तविक playwright-mcp browser_snapshot आउटपुट compress गर्छ (≥50% कमी)
  • सबै 10 skills/omniroute*/SKILL.md फाइलहरू raw GitHub URL मार्फत सार्वजनिक रूपमा प्राप्त गर्न सकिन्छ
  • नयाँ सेटअपमा onboarding wizard ले "यसले कसरी काम गर्छ" टियर भ्रमण चरण देखाउँछ
  • Home dashboard को टियर coverage widget ले कन्फिगर गरिएका/सक्रिय सङ्ख्याहरू देखाउँछ

रोलब्याक

रिलिजमा गम्भीर समस्या भएमा:

  1. gh release edit vX.Y.Z --prerelease (नवीनतम होइन भनेर चिन्ह लगाउँछ)
  2. git tag -d vX.Y.Z && git push --delete origin vX.Y.Z (प्रयोगकर्ताहरूले अझै अपनाएका छैनन् भने मात्र)
  3. वा: release/vX.Y.0 मा हटफिक्स → प्याच रिलिज vX.Y.(Z+1)
  4. GitHub Discussions र Discord मा तुरुन्त जानकारी दिनुहोस्

कडा नियमहरू

  • main मा कहिल्यै सिधै कमिट नगर्नुहोस्
  • main वा release/* ब्रान्चहरूमा कहिल्यै git push --force प्रयोग नगर्नुहोस्
  • Husky हुकहरू (--no-verify) कहिल्यै नछोड्नुहोस्
  • गोप्य जानकारी, क्रेडेन्सियलहरू वा .env फाइलहरू कहिल्यै कमिट नगर्नुहोस्
  • कभरेज ≥60/60/60/60 (स्टेटमेन्टहरू/लाइनहरू/फङ्सनहरू/ब्रान्चहरू) कायम रहनुपर्छ
  • src/, open-sse/, electron/, वा bin/ मा प्रोडक्सन कोड परिवर्तन गर्दा सधैँ परीक्षणहरू समावेश वा अद्यावधिक गर्नुहोस्

स्वचालित सिङ्क जाँच

PR खोल्नुअघि डक्स सिङ्क गार्ड स्थानीय रूपमा चलाउनुहोस्:

npm run check:docs-sync

CI ले पनि यो जाँच .github/workflows/ci.yml (lint जब) मा चलाउँछ।

Reference in New Issue View Git Blame Copy Permalink