mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-13 18:32:12 +03:00
Landed with the design call resolved per the owner's pick — **option 1**: the synced store is now endpoint-agnostic (persistDiscoveredModels and managedModelImport no longer drop non-chat models at write time), and chat selectability moved to read time (auto-pool expansion in autoStrategy applies filterChatSelectableModels; the models-route projection already had its chatOnly filter). Your discovery test now passes end-to-end (3/3): /api/show capabilities persist per connection and image/embedding requests route through the advertising host. Reconciliation notes: conflicted areas merged onto the current tip (adobe discovery import, requestedModel preflight signature, resolvedProvider fast-path coexists with the synced-route override — explicit resolution wins); carried base-red drains (#10055 memoization, #11071 test variants) dropped as already-landed; the managed-model-import exclusion test was propagated to the new contract (image/video models persist; the read filter still hides them from chat pickers — pinned by a new assertion). Full battery: 205/206 focused (the one red is a confirmed periodic-timer timing flake on the loaded devbox — 20/20 isolated), autoCombo vitest 30/30, combo suites 46/46, gates + typecheck clean. Thank you @yourspraveen — the capability probe + routing design was right; it just needed the store contract opened up. Fixes #11087.
2.0 KiB
2.0 KiB
Developer environment notes
This page explains the project's local .env behavior and how to handle environment files and secrets when developing OmniRoute.
.env postinstall behavior
The project may generate a local .env file during npm install / postinstall for developer convenience. This file is intended only for local development and testing and must never be committed to version control.
Key points:
- The repository's
.gitignorealready ignores.env*files (see the.gitignoreentry). Do not remove or alter that rule unless you deliberately intend to commit a specific example file and have a documented process for it. - If a real secret is accidentally committed to the repo, rotate/revoke the credential immediately and remove it from the repository history (for example, using
git filter-repoor an equivalent remediation workflow). Contact the security/contact owner if you need help. - For CI and production, use the CI secrets or a secrets manager (GitHub Actions Secrets, Azure Key Vault, HashiCorp Vault, etc.) rather than committing secrets to files.
Recommended local workflow
- Keep
.envin your local workspace only. Use.env.example(already tracked) to document required variables and acceptable example values. - When running tests locally that require secret-like values, prefer synthetic placeholders or runtime-generated ephemeral keys rather than real credentials.
- Add a short comment in tests that use placeholders so reviewers understand the fixture is synthetic.
Scanner notes
- Some compiled or binary assets (e.g., embedded base64 WASM blobs) can contain ASCII substrings that look like credentials and may trigger text-based secret scanners. If these assets are legitimate, either mark them in the scanner's allowlist or exclude the directories in the scanner config.
If you find a leak
- Rotate/revoke the key immediately.
- Remove the secret from the history and force-push a cleaned branch if necessary.
- Notify maintainers and follow your org's incident response checklist.