pjandro/OmniRoute
1
0
Fork 0
mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-09-19 21:32:20 +03:00
Code Issues Packages Projects Releases Wiki Activity
Files
53a147c7ca61c06fd6a00a8c2eefde383e28be76
OmniRoute/docs/i18n/ro/docs/ops/RELEASE_CHECKLIST.md
Diego Rodrigues de Sa e Souza b637350680 fix(docs): re-sync the 65 documentation mirror sets; section-level docs pipeline; drift gate blocking (#13940) 
1,104 mirrors rewritten over five passes of run-translation on the 22-source core set: the 14 sources edited since their translation, the 322 mirrors that were still English copies, and the frontmatter the old extractor leaked into the newer locales' bodies. The pipeline now caches per-`## `-section hashes and retranslates only changed sections, never reuses a section that is still English, rebuilds English-copy / leaked mirrors even when the source is unchanged, merges the state on save (parallel runs), and the drift gate (scoped to the core set) is blocking. Final audit: 0 stale, 0 English copies, 0 leaked frontmatter across 1,430 core mirrors.

⚠️ base-red inherited: #12732
2026-09-17 02:55:31 -03:00

31 KiB
Raw Blame History

Release Checklist (Română)

🌐 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 · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

Ultima actualizare: 2026-08-28 — v3.8.51 Flux de lansare simplificat, care utilizează abilitățile Claude Code pentru automatizare.

Mențineți coada/ramura verde între lansări: consultați RELEASE_GREEN.md (familia /green-prs + npm run check:release-green + /babysit + rularea nocturnă). Rularea periodică a acestora — și mai ales înaintea acestei liste de verificare — face ca PR-ul de lansare să pornească verde.

Pe scurt

# 1. Incrementați versiunea + generați CHANGELOG-ul (abilitate)
/version-bump-cc patch    # sau minor/major

# 2. Rulați local verificările de calitate
npm run check              # lint + teste
npm run test:coverage      # verificare completă a acoperirii (60/60/60/60)

# 3. Compilați și efectuați testul de bază
npm run build
npm run test:e2e           # opțional, dar recomandat

# 4. Generați lansarea (abilitate)
/generate-release-cc

# 5. Efectuați implementarea (abilitate)
/deploy-vps-both-cc        # sau akamai-cc / local-cc

# 6. Capturați dovezile lansării (abilitate)
/capture-release-evidences-cc

Publicare de încredere npm (implicită începând cu v3.8.51) — etapizată la cerere, directă ca soluție de rezervă

npm-publish.yml publică implicit prin npm Trusted Publishing (OIDC): jobul stage-npm (găzduit de GitHub) schimbă id-token-ul GitHub pentru o acreditare npm cu durată scurtă de viață, valabilă pentru rularea respectivă — fără token npm cu durată lungă de viață în secretele depozitului, fără solicitare 2FA, cu proveniența atașată. Aceasta este metoda alternativă acceptată de npm acum, când tokenurile care omit 2FA sunt retrase; ea restabilește fluxul complet automat pe care proiectul l-a avut până la v3.8.48, păstrând în același timp garanția WS1.3 (un token divulgat nu poate publica singur — nu există niciun token).

Configurare unică (proprietar): npmjs.com → pachetul omniroute → Settings → Trusted Publisher → GitHub: proprietar diegosouzapw, depozit OmniRoute, flux de lucru npm-publish.yml (mediu: niciunul). Până când această configurare există, pasul automat eșuează cu ENEEDAUTH: relansați cu publish_mode=staged (mai jos) sau direct.

Publicare etapizată (la cerere — publish_mode=staged)

Fluxul de lucru npm-publish nu mai publică direct: pornește arhiva tar împachetată (check:pack-boot), apoi rulează npm stage publish — octeții exacți sunt depozitați în registru, dar nu pot fi instalați până când proprietarul îi aprobă. Punctul de control 2FA uman a fost mutat DUPĂ verificare, nu înaintea acesteia.

Fluxul proprietarului după ce fluxul de lucru devine verde:

  1. npm stage list omniroute — găsiți ID-ul etapei (afișat și în rezumatul fluxului de lucru).
  2. Verificați octeții etapizați (recomandat): npm stage download <id>, apoi instalați arhiva tar descărcată într-un prefix temporar și porniți-o (npm run check:pack-boot automatizează în CI același verdict de împachetare→instalare→pornire).
  3. npm stage approve <id> — solicitarea 2FA REPREZINTĂ publicarea. npm stage reject <id> elimină etapa.
  4. Plasă de siguranță după publicare: verificatorul post-publicare (WS1.4 din planul v3.8.49) instalează versiunea publicată din registrul public într-un container curat și o pornește.

Soluție de rezervă pentru urgențe: workflow_dispatch cu publish_mode=direct restabilește vechiul npm publish imediat (utilizați-l numai dacă etapizarea însăși funcționează defectuos; consemnați motivul).

Consolidare unică a securității (proprietar, npmjs.com): configurați Trusted Publisher pentru omniroute în modul exclusiv etapizat, astfel încât un token cu durată lungă de viață divulgat să nu poată executa npm publish direct de nicăieri — CI poate doar să etapizeze; numai autentificarea 2FA a proprietarului permite lansarea.

Procedură pentru artefacte defecte (neschimbată): npm deprecate omniroute@<bad> "<reason> — use <fixed>" ca reacție implicită (durează câteva minute și este reversibilă); utilizați npm unpublish numai în intervalul de 72 de ore/fără dependenți și niciodată ca primă măsură. Docker: nu rescrieți niciodată o etichetă de versiune — revenirea înseamnă redirecționarea etichetei latest către ultimul digest valid.

Eticheta Docker Hub latest (obligatorie la fiecare publicare SemVer stabilă): fluxul de lucru docker-publish trebuie să eticheteze atât X.Y.Z, cât și, atunci când should-promote-latest.sh confirmă că aceasta este cea mai mare versiune SemVer stabilă, :latest cu același digest. După job: digestul latest din Hub este identic cu digestul noii versiuni SemVer, iar last_updated s-a modificat. Nu lăsați :latest asociat unei compilări mai vechi în timp ce notele de lansare descriu remedieri care există numai în git. Configurările de pornire rapidă Compose utilizează :latest; GitOps trebuie să fixeze în continuare versiunea X.Y.Z. Consultați Canalele de lansare Docker și #10317.

Calea rapidă pentru hotfix-uri (eticheta hotfix)

Un PR etichetat cu hotfix omite matricea CI complexă (E2E cu 9 fragmente, verificarea progresivă a acoperirii, quality-gate, quality-extended) și păstrează verificările rapide, cu semnal puternic: compilare, fragmente de teste unitare, integrare, vitest, lint/verificarea tipurilor, docs-sync, check:pack-artifact și testul rapid de pornire din arhiva tar (check:pack-boot). Obiectiv: rezultat verde în ≤15 min în loc de ~33 min.

Politica de acces — toate cele patru condiții sunt obligatorii (modelată după căile de urgență Chromium/VS Code/Node):

  1. Severitate: producția este defectă — un artefact publicat se blochează la pornire / o remediere de securitate / fiecare utilizator al versiunii este afectat. „Important” nu înseamnă „defect”.
  2. Autoritate: numai proprietarul depozitului aplică eticheta hotfix. Eticheta REPREZINTĂ aprobarea — nu o aplicați niciodată pe cont propriu unui PR de campanie.
  3. Dovezi: corpul PR-ului conține un link către execuția complexă anterioară, complet verde (suita pe care sarcinile omise ar valida-o din nou), plus testul specific remedierii, inițial eșuat și apoi reușit.
  4. Domeniu de aplicare: exclusiv cherry-pick — remedierea minimă, fără refactorizări, fără modificări colaterale.

Suprafața omisă privind acoperirea/verificarea progresivă este validată din nou de următoarea execuție completă pe ramura de lansare (stare verde continuă a lansării) — această cale omite AȘTEPTAREA, niciodată validarea. Diferențele care conțin numai teste (toate fișierele în tests/, niciunul în tests/e2e/) omit automat matricea E2E, fără nicio etichetă.

Listă de verificare detaliată

Înainte de lansare

  • Toate PR-urile destinate acestei versiuni sunt îmbinate în release/vX.Y.0
  • Toate elementele Linear/problemele deschise pentru această versiune sunt închise sau mutate la următoarea etapă
  • CI este verde pe ramura release/vX.Y.0
  • Nu există marcaje TODO(release) în cod: grep -r "TODO(release)" src/ open-sse/
  • Imaginea de bază Docker este actualizată (în prezent node:24.15.0-trixie-slim)

Versiune și jurnal de modificări

  • Executați /version-bump-cc <patch|minor|major> (abilitate Claude Code)
    • Actualizează versiunile din package.json, electron/package.json
    • Regenerează CHANGELOG.md din commiturile git ulterioare ultimei etichete
    • Actualizează ecusoanele din README.md
  • Revizuiți manual CHANGELOG.md și corectați mesajele commiturilor, dacă este necesar
  • Asigurați-vă că cea mai recentă secțiune semver din CHANGELOG.md corespunde versiunii din package.json
  • Păstrați ## [Unreleased] drept prima secțiune a jurnalului de modificări pentru lucrările viitoare
  • Actualizați docs/openapi.yaml → info.version trebuie să corespundă versiunii din package.json

Calitatea codului

  • npm run lint — 0 erori (avertismentele sunt preexistente)
  • npm run typecheck:core — fără probleme
  • npm run typecheck:noimplicit:core — fără probleme (strict)
  • npm run check:cycles — fără dependențe circulare
  • npm run check:any-budget:t11 — în limita bugetului
  • npm run check:route-validation:t06 — fără probleme
  • npm run check:node-runtime — este respectată versiunea minimă acceptată a mediului de execuție (>=22.22.2 <23, >=24.0.0 <27, conform SUPPORTED_NODE_RANGE din src/shared/utils/nodeRuntimeSupport.ts; aliniată cu engines din package.json)

Testare

  • npm run test:unit — reușește
  • npm run test:vitest — reușește (server MCP, autoCombo, cache)
  • npm run test:coverage — pragul 60/60/60/60 este îndeplinit (instrucțiuni/linii/funcții/ramuri)
  • npm run test:integration — reușește (dacă modificările afectează baza de date / gestionarii)
  • npm run test:combo:matrix — reușește (matricea strategiilor combinate: demonstrează în mod determinist deciziile de selecție ale tuturor celor 19 strategii publice de rutare; executați când modificați rutarea combinată, rezolvarea strategiilor sau logica de rezervă)
  • RUN_COMBO_LIVE=1 npm run test:combo:live — opțional/manual (test rapid condiționat cu servicii externe reale; preia un instantaneu doar în citire al bazei de date de pe VPS-ul root@192.168.0.15; accesează furnizori reali, consumă credite; nu rulează niciodată în CI; este omis fără probleme în absența condiției)
  • npm run test:combo:live:vps — opțional/manual (test rapid live pe VPS pentru faza 3: 7 scenarii HTTP pe serverul live .15 prin Node ESM simplu; necesită ssh root@192.168.0.15; creează/șterge numai combinații __live_test__*; accesează furnizori reali; nu rulează niciodată în CI)
  • npm run test:e2e — reușește (modificări ale interfeței)
  • npm run test:protocols:e2e — reușește (modificări MCP/A2A)
  • npm run test:ecosystem — reușește

Hook-uri (validate de Husky)

Hook-urile Husky se află în .husky/ și rulează automat la operațiunile git.

  • pre-commit: npx lint-staged + node scripts/check/check-docs-sync.mjs + npm run check:any-budget:t11
  • pre-push: verificări deterministe rapide — npm run check:any-budget:t11 && npm run check:tracked-artifacts (activate la 2026-06-13). Exclude intenționat test:unit (lent; acoperit de sarcina CI test-unit).
    • Executați manual npm run test:unit înainte de a trimite ramurile de lansare.

Dacă un hook eșuează: remediați problema de bază, nu îl ocoliți cu --no-verify.

Commituri convenționale

Toate commiturile destinate lansării trebuie să respecte formatul type(scope): subject.

Tipuri valide: feat, fix, refactor, docs, test, chore, perf, style, ci

Domenii valide: db, sse, oauth, dashboard, api, cli, docker, ci, mcp, a2a, memory, skills, cloud-agent, guardrails, compression, auto-combo, resilience, providers, executors, translator, domain, authz

Modificări incompatibile: adăugați subsolul BREAKING CHANGE: sau ! după domeniu (de exemplu, feat(api)!: drop /v0).

Documentație

  • npm run check:docs-sync trece (rulat automat de pre-commit)
  • npm run check:docs-all trece (comandă-umbrelă: docs-sync + docs-counts + env-doc-sync + deprecated-versions + doc-links)
  • npm run check:env-doc-sync se încheie cu codul 0 — contractul variabilelor de mediu dintre cod ↔ .env.example ↔ docs/reference/ENVIRONMENT.md este intact
  • npm run check:doc-links se încheie cu codul 0 — nu există referințe markdown interne nefuncționale după restructurare
  • docs/architecture/ARCHITECTURE.md a fost verificat pentru neconcordanțe privind stocarea și mediul de execuție
  • docs/guides/TROUBLESHOOTING.md a fost verificat pentru neconcordanțe privind variabilele de mediu și operațiunile
  • Dacă .env.example s-a modificat: docs/reference/ENVIRONMENT.md a fost actualizat
  • Dacă funcționalitatea nouă are o interfață: docs/guides/USER_GUIDE.md o menționează
  • Dacă funcționalitatea nouă are un API: docs/reference/API_REFERENCE.md + docs/openapi.yaml au fost actualizate
  • Dacă funcționalitatea nouă este un modul: există un fișier dedicat docs/<MODULE>.md
  • Dacă este o modificare incompatibilă: docs/guides/TROUBLESHOOTING.md conține o notă de migrare

i18n

  • npm run i18n:check se încheie cu codul 0 — starea traducerilor (.i18n-state.json) este sincronizată cu documentația sursă (fără surse divergente în modul strict; avertismentele din modul de avertizare sunt acceptabile pentru retușuri de ultim moment ale documentației, dar rezultatul trebuie să fie 0 înainte de etichetare)
  • npm run i18n:check-ui-coverage se încheie cu codul 0 — fiecare localizare a interfeței atinge sau depășește pragul minim de acoperire de 80%
  • npm run i18n:sync-ui:dry raportează 0 chei lipsă în toate cele 42 de localizări
  • Dacă documentația sursă în limba engleză s-a modificat, rulați npm run i18n:run (necesită OMNIROUTE_TRANSLATION_API_KEY în .env) înainte de etichetare
  • Contribuțiile la traduceri pot fi amânate pentru următoarea versiune dacă sunt minore (urmăriți-le în CHANGELOG)

Migrări ale bazei de date

  • Dacă src/lib/db/migrations/ conține fișiere noi:
    • Fiecare migrare este idempotentă (CREATE TABLE IF NOT EXISTS etc.)
    • Migrările sunt încadrate în tranzacții
    • Sunt numerotate corect (fără întreruperi în secvență)
  • Testați pe o instalare nouă: ștergeți ~/.omniroute/omniroute.db și rulați npm run dev
  • Testați pe o instalare existentă: creați o copie de siguranță a bazei de date, rulați migrarea și verificați schema
  • Fișierele WAL (-wal, -shm) sunt gestionate corect dacă migrarea rescrie tabele

Catalogul furnizorilor (validat cu Zod)

  • Schema Zod din src/shared/constants/providers.ts este validă la încărcare
    • Toți furnizorii au câmpurile obligatorii (id, label, kind etc.)
    • freeNote este furnizat pentru noii furnizori gratuiți
    • Furnizorii OAuth au oauthConfig înregistrat în src/lib/oauth/constants/oauth.ts
  • Dacă este adăugat un furnizor nou: există executorul corespunzător în open-sse/executors/
  • Dacă formatul nu este OpenAI: există un translator în open-sse/translator/
  • Modelele sunt înregistrate în open-sse/config/providerRegistry.ts
  • Testele unitare din tests/unit/ acoperă clasificarea și rutarea furnizorilor

Desktop (Electron)

Dacă electron/ s-a modificat:

  • npm run electron:smoke:packaged trece
  • Buildurile au fost testate pentru cel puțin una dintre opțiunile :win, :mac, :linux
  • Certificatele de semnare a codului nu sunt expirate (dacă se folosește semnarea)
  • Versiunea din electron/package.json corespunde cu cea din fișierul package.json rădăcină
  • Indicatorul canalului de actualizare automată a fost actualizat dacă versiunea este publicată în stable

Structura buildului

Repository-ul utilizează trei directoare de ieșire distincte — nu le confundați niciodată:

Director Scop Urmărit?
src/ Sursa aplicației (TypeScript / TSX) Da
.build/ Fișiere intermediare de build — ieșirea next build (distDir) Nu (ignorat de git)
dist/ Pachet npm distribuibil — asamblat de assembleStandalone Nu (ignorat de git)

Notă pentru operator: directorul imaginii VPS de la distanță rămâne /usr/lib/node_modules/omniroute/app/. Doar ieșirea buildului din repository s-a mutat (app/ → dist/). Instrumentele de deployment sincronizează prin rsync conținutul din dist/ în directorul app/ de la distanță — nu sunt necesare modificări ale căilor VPS.

Flux cu un singur build:

npm run build:release
  └─ rm -rf .build dist          (curățare)
  └─ next build → .build/next/   (fișiere intermediare)
  └─ assembleStandalone          (copiază standalone + static + public + natives → dist/)
  └─ writes dist/BUILD_SHA       (santinelă HEAD)

NU rulați npm run build urmat de o comandă separată npm run build:cli pentru deployment — utilizați npm run build:release, care efectuează într-o singură comandă un rebuild curat și creează santinela.

Validarea artefactelor

  • npm run build:release reușește și dist/BUILD_SHA == git rev-parse --short HEAD
  • npm run check:pack-artifact nu raportează probleme — fără app.__qa_backup, scripts/scratch, package-lock.json sau alte reziduuri locale
  • dist/server.js există după build

Etichetare și publicare

  • Rulați /generate-release-cc (instrument Claude Code):
    • Creează eticheta vX.Y.Z
    • Publică eticheta și ramura
    • Deschide o versiune GitHub Release cu conținutul jurnalului de modificări
    • Atașează programele de instalare Electron (dacă au fost create)
  • Sau manual: 
    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

Deployment

Instrumentele de deployment utilizează fluxul rsync simplificat — fără npm pack, fără npm i -g:

  • Utilizați instrumentul de deployment care corespunde țintei:
    • /deploy-vps-local-cc — VPS local (192.168.0.15)
    • /deploy-vps-akamai-cc — VPS Akamai (69.164.221.35)
    • /deploy-vps-both-cc — ambele
  • Înainte de deployment, confirmați că dist/BUILD_SHA == git rev-parse --short HEAD
  • Buildul trebuie să ruleze acolo unde node_modules este real (checkout principal sau arbore de lucru în care s-a rulat npm ci — NU un arbore de lucru bazat pe linkuri simbolice)
  • Efectuați un test rapid al instanței pe care s-a făcut deployment:
    • Deschideți /dashboard/health → verificați dacă șirul versiunii corespunde versiunii publicate
    • Rulați o cerere /v1/chat/completions către un furnizor cunoscut
    • Verificați dacă /api/monitoring/health returnează disjunctoare de circuit CLOSED
    • Confirmați că transporturile MCP răspund (/mcp HTTP, /mcp-sse SSE)

După publicare

  • Rulați /capture-release-evidences-cc (abilitate Claude Code)
    • Capturează capturi de ecran/înregistrări WebP ale funcționalităților noi
    • Le atașează la notele de lansare/postarea de pe blog
  • Actualizați GitHub Discussions / Discord cu anunțul lansării
  • Deschideți un reper pentru versiunea următoare
  • Dacă este critic: fixați discuția sau publicați în news.json pentru bannerul din aplicație

Criterii pentru lansarea publică Radar

Anunțul Radar este inclus în mod intenționat cu active: false. Activarea este o modificare separată, după ce există dovezi pentru fiecare element de mai jos:

  • Toate PR-urile Radar stivuite sunt îmbinate, iar CI-ul pentru versiunea finală este verde
  • Implementați și testați rapid rutele OSS Radar, cu RADAR_ENABLED încă dezactivat în mod implicit
  • Testați rapid GET /planos, /termos, /privacidade și /reembolso pe gazda Radar desemnată
  • Înregistrați identitatea/datele de contact/adresa operatorului și revizuirea juridică aprobată de proprietar în serviciul privat
  • Testați Stripe Checkout și webhook-ul semnat numai în modul de testare
  • Testați livrarea unui e-mail tranzacțional criptat folosind expeditorul/domeniul aprobat
  • Dovediți restaurarea copiei de rezervă și efectuați o rulare de cercetare supravegheată, cu buget limitat
  • Aprobați politica de revizuire BRL/PIX înainte de a accepta dovezi privind donațiile
  • Activați Checkout public numai după îndeplinirea criteriilor precedente, apoi activați noul ID din news.json
  • Verificați dacă bannerul de pe pagina principală folosește text localizat și dacă un ID nou reapare după ce un ID mai vechi este închis

Teste rapide pentru serviciile încorporate (v3.8.4+)

Înainte de a publica orice versiune care include modificări ale serviciilor încorporate, verificați:

Pornire cu o bază de date nouă (detectează coliziunile migrărilor — adăugat după remedierea rapidă v3.8.4)

  • DATA_DIR=$(mktemp -d) npm start & — așteptați 10 s pentru pornire
  • curl -s http://127.0.0.1:20128/api/services/9router/status | jq '.tool' returnează "9router" (NU 404, NU 500). Confirmă că migrarea 071_services.sql a fost aplicată și că rândul a fost adăugat.
  • sqlite3 $DATA_DIR/storage.sqlite "PRAGMA table_info(version_manager);" | grep -E "provider_expose|logs_buffer_path|last_sync_at" returnează 3 rânduri.
  • sqlite3 $DATA_DIR/storage.sqlite "PRAGMA table_info(webhooks);" | grep -E "kind|metadata_encrypted" returnează 2 rânduri (validează aplicarea migrării 070_webhooks_kind_metadata.sql).
  • node --import tsx/esm --test tests/unit/db/no-migration-collisions.test.ts trece — protejează împotriva coliziunilor viitoare.

9Router

  • POST /api/services/9router/install returnează 200 cu installedVersion în mai puțin de 2 min
  • POST /api/services/9router/start returnează 200 și state: "running" în mai puțin de 30 s
  • GET /api/services/9router/status raportează health: "healthy"
  • POST /v1/chat/completions cu "model": "9router/auto/..." returnează 200 (rutare integrală prin 9Router)
  • GET /dashboard/providers/services/9router/embed/dashboard redă interfața nativă 9Router în interiorul proxy-ului (fără iframe direct către 127.0.0.1:port)
  • POST /api/services/9router/rotate-key returnează { keyRotated: true }, iar serviciul repornește fără probleme
  • POST /api/services/9router/stop returnează 200 și state: "stopped"
  • GET /api/services/9router/logs?tail=50 returnează un flux SSE cu un eveniment snapshot care conține liniile recente
  • Instalarea într-un mediu fără npm în PATH returnează 500 cu un mesaj de eroare clar (fără urmă de stivă)

CLIProxyAPI

  • POST /api/services/cliproxy/install returnează 200 în mai puțin de 2 min
  • POST /api/services/cliproxy/start returnează 200 și state: "running" în mai puțin de 30 s
  • GET /api/services/cliproxy/status raportează health: "healthy"
  • POST /api/services/cliproxy/stop returnează 200 și state: "stopped"
  • GET /api/services/cliproxy/logs?tail=50 returnează un flux SSE

Regresie de securitate

  • curl -H "X-Forwarded-For: 1.2.3.4" http://localhost:20128/api/services/9router/start returnează 403 LOCAL_ONLY
  • curl -H "X-Forwarded-For: 1.2.3.4" http://localhost:20128/api/services/cliproxy/start returnează 403 LOCAL_ONLY
  • Răspunsurile de eroare de la /api/services/* nu conțin err.stack sau căi absolute către fișiere

Verificări pentru v3.8.0+

Înainte de a publica orice versiune v3.8.x, verificați și următoarele elemente:

  • omniroute --tray pornește pe macOS (systray2 instalat în ~/.omniroute/runtime/)
  • omniroute --tray pornește pe Linux (necesită DISPLAY; eroare tratată elegant dacă nu este setat)
  • omniroute --tray pornește pe Windows (PowerShell NotifyIcon, fără binare suplimentare)
  • omniroute config tray enable creează intrarea de pornire automată; dezactivarea o elimină
  • npm install -g omniroute@<this-version> rulează postinstall fără ieșire fatală
  • Calea de actualizare păstrează dependențele opționale: omniroute update --apply și actualizatorul automat rulează npm install -g … --include=optional, astfel încât optionalDependencies (better-sqlite3, keytar, tls-client și stiva SLM llmlingua: @atjsh/llmlingua-2@2.0.5, js-tiktoken) să supraviețuiască unei actualizări. Nivelul SLM ultra modelPath necesită și modelul tinybert, descărcat automat în ${DATA_DIR}/models/llmlingua la prima utilizare. Apoi, postinstall (scripts/build/colocateOptionals.mjs) amplasează împreună în dist/node_modules închiderea opțională SLM, astfel încât workerul să rezolve o SINGURĂ instanță @huggingface/transformers ^4.2.0 — trasarea autonomă include în pachet doar transformers, nu și opționalele importate dinamic, astfel încât, fără această măsură, workerul ar încărca llmlingua-2 folosind transformers din rădăcină, iar nivelul SLM ar eșua silențios în modul permisiv.
  • omniroute status funcționează fără .env (calea tokenului CLI, numai loopback)
  • curl http://localhost:20128/api/shutdown returnează 401 (rută protejată permanent)
  • curl -H "host: evil.com" http://localhost:20128/api/mcp/sse returnează 401 (protecție loopback)
  • Runtime-ul SQLite se rezolvă la bundled la prima rulare (binarul inclus este valid pentru platformă)
  • Runtime-ul SQLite revine la runtime când node_modules/better-sqlite3 este șters
  • Filtrul inteligent MCP comprimă rezultatul real al playwright-mcp browser_snapshot (reducere ≥50%)
  • Toate cele 10 fișiere skills/omniroute*/SKILL.md pot fi preluate public prin URL-ul GitHub raw
  • Expertul de configurare inițială afișează pasul de prezentare a nivelurilor „Cum funcționează” la o configurare nouă
  • Widgetul de acoperire a nivelurilor din panoul principal afișează numărul de niveluri configurate/active

Revenire la versiunea anterioară

Dacă versiunea lansată are o problemă critică:

  1. gh release edit vX.Y.Z --prerelease (o marchează ca nefiind cea mai recentă)
  2. git tag -d vX.Y.Z && git push --delete origin vX.Y.Z (doar dacă nu a fost încă adoptată de utilizatori)
  3. Sau: remediere rapidă pe release/vX.Y.0 → versiune de corecție vX.Y.(Z+1)
  4. Comunicați imediat în GitHub Discussions și Discord

Reguli stricte

  • Nu faceți niciodată commit direct în main
  • Nu utilizați niciodată git push --force pentru ramurile main sau release/*
  • Nu omiteți niciodată hook-urile Husky (--no-verify)
  • Nu includeți niciodată în commit secrete, credențiale sau fișiere .env
  • Acoperirea trebuie să rămână ≥60/60/60/60 (instrucțiuni/linii/funcții/ramuri)
  • Includeți sau actualizați întotdeauna testele atunci când modificați codul de producție din src/, open-sse/, electron/ sau bin/

Verificarea automată a sincronizării

Rulați local verificarea sincronizării documentației înainte de a deschide un PR:

npm run check:docs-sync

CI rulează, de asemenea, această verificare în .github/workflows/ci.yml (sarcina lint).

Reference in New Issue View Git Blame Copy Permalink