Vigil-SOC/vigil

Follow-up to #643. That issue specified the daemon and API process boundaries and #685 implemented them; llm-worker is the third deployable and was never in scope. See #643 for the shared background on why fail-fast is the behavior we're keeping. Background #685 added core.config.validate_settings_or_exit() and called it at two process boundaries, so a malformed env value now produces a single configuration error: <field>: <reason> line on stderr and exits os.EX_CONFIG (78) instead of a ValidationError traceback from whatever code happened to read config first. services/worker did not get the same treatment. Per CLAUDE.md, services/ holds "exactly api, daemon, worker" — so two of three deployables now fail cleanly and the third still fails the old way: DAEMON_HEALTH_PORT=not-an-int python -m services.worker → pydantic ValidationError traceback, exit 1 The trace surfaces at core/llm/defaults.py:16, reached through the import-time get_settings() at services/worker/jobs.py:16 — one

Summary docker/docker-compose.yml publishes PostgreSQL, Redis and the Bifrost gateway on 0.0.0.0, so all three are reachable from anywhere on the operator's network. For a SOC platform this is worth tightening — the machine running Vigil holds security findings, case data and LLM credentials. Tested on v0.4.0 (8abecc2). Current behaviour $ docker ps --format '{{.Names}}\t{{.Ports}}' deeptempo-postgres 0.0.0.0:5432->5432/tcp, [::]:5432->5432/tcp deeptempo-redis 0.0.0.0:6379->6379/tcp, [::]:6379->6379/tcp deeptempo-bifrost 0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp From docker/docker-compose.yml: line 13 — - "5432:5432" line 33 — - "6379:6379" line 207 — - "8080:8080" Why each one matters Postgres ships with POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-deeptempo_secure_password_change_me}. The default is in the repo, so an install that hasn't overridden it is open to anyone on the LAN. It holds findings, cases, approval_actions and llm_provider_configs. Redis runs with n

Summary A custom OpenAI-compatible provider (OpenRouter, LiteLLM, vLLM, Together) can be registered in the UI, passes the connection test, and still never routes: every completion fails with no keys found that support model: <model>. Bifrost stays pointed at api.openai.com. Root cause is two stacked defects in services/bifrost_admin.py. The second one is broader than the title suggests — it silently disables all runtime sync to Bifrost, keys included. Tested on v0.4.0 (8abecc2) with maximhq/bifrost:latest. Defect A — base_url is never propagated bifrost_admin.py syncs the key value (push_provider_key) and the model allow-list (sync_provider_models). Neither touches network_config.base_url. LLMProviderConfig.base_url is read — _do_sync_all_provider_models puts "base_url": row.base_url into the row dict at services/bifrost_admin.py:309 — but it is only used to feed model discovery and the connection test, both of which call the upstream directly. That's why the test passes while

Coding: Low · Vigil context: Med · Lane: backend · Type: investigation, not migration investigations.trigger_ids is annotated Mapped[List[dict]] (database/models.py:2000) but is used as though it holds a list of ids — daemon/orchestrator.py:950 does trigger_ids = inv.trigger_ids or [] and :1167 passes inv_record.get("trigger_ids", []) straight through. The annotation and the usage disagree, so the ORM type cannot be trusted here. That is the finding. Until it is resolved, nobody can say whether this column belongs with the scalar-array promotions or the child-table ones. No migration in this issue. The deliverable is an answer. Acceptance criteria Identify every writer and record the actual element type — from code that constructs the elements, not from a pass-through. Sample real rows if any environment has them, and say which environment. Correct the Mapped[...] annotation to match reality. That alone is worth the PR. State the verdict: ARRAY(TEXT) of finding ids, a join tabl