fix(kb): przepiecie wszystkich odwolan wewnetrznych po migracji
126 plikow (md, yaml, sh, py) odwolywalo sie do sciezek sprzed migracji.
15 markdown-linkow [..](..) -> policzona sciezka WZGLEDNA wobec pliku
odsylajacego (wczesniej czesc z nich byla repo-root-relative i nie
rozwiazywala sie z katalogu, w ktorym lezala)
200 odwolan tekstowych (backticki, proza, yaml, importy w kodzie)
-> nowa sciezka repo-root-relative, zgodnie z konwencja repo
5 linkow rodzenstwa (gole nazwy plikow, np. "](DEPLOY.md)") — dzialaly
tylko w starym katalogu; przeliczone recznie
Objete m.in.: CLAUDE.md (scripts/onboard/README.md -> kb/runbooks/
node-onboarding-tool.md, docs/backlog.md -> kb/phases/backlog.md),
README.md, .claude/skills/, 20 session logow, kod jobow.
Ostatnie 5 odwolan pochodzi z tresci wciagnietej rebasem z origin/master
(session log 2026-07-31, override node-agenta na SOLARII, dwie pozycje
backlogu) — wskazywaly na docs/incidents/, docs/kb/modules/ i
services/narty27/README.md sprzed migracji.
Dodany wzajemny link miedzy kb/services/control-plane.md (stub kodu)
a kb/subsystems/control-plane.md (opis, deprecated) — dwa dokumenty o tym
samym systemie, latwe do pomylenia.
Weryfikacja na 790 plikach: 0 odwolan do starych sciezek,
0 martwych linkow markdown. Lint OKF: 190/190 plikow ZGODNE.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 15:12:24 +02:00
|
|
|
"""Startup invariant -- module 5 phase 4 (kb/phases/kb-m5-faza4.md, §2 decision 2,
|
feat(kb): add kb-query service skeleton (search API, no ingress yet)
Module 5 phase 4 step 1 (docs/kb/modules/05-faza4-plan.md, §4): first
user-facing HTTP entry point to the KB. FastAPI wrapping
kb_retrieval.cascade_query/flat_query — GET /search (query_text -> embed via
Ollama@SOLARIA -> cascade/flat -> envelope join -> JSON with per-source
links) and GET /healthz. Search API only, no answer synthesis (phase 5) and
no server-side dist filtering — the 0.45/0.55 colour thresholds are a
frontend concern (plan §7, a later step).
Hard startup invariant (plan §2 decision 2): refuses to start unless the
configured EMBED_MODEL is present in both document_chunk.model and
document_summary.embedding_model. Note the latter: document_summary.model is
the LLM that *wrote* the summary (claude-haiku-4-5/gemma3:12b), not the
embedder — checked live against kb-postgres@PIHA before writing this, see
app/startup.py's docstring. Verified end-to-end with a live docker run: the
invariant crash-loops on a mismatched EMBED_MODEL and passes through to a
real /search hit against the live corpus with a correct model.
Repo-only: no deploy, no npm/OIDC/DNS wiring (plan §8, later step), no local
embed fallback (plan §5, later step) — Ollama@SOLARIA is called directly and
a failure surfaces as 503, not a crash.
Also: scripts/deploy/deploy.sh's gate now builds each service via
`docker compose build` instead of a raw `docker build <svc_dir>`, so a
service whose docker-compose.yml declares a repo-root build context (needed
here to COPY packages/kb-retrieval/, the packages/ Dockerfile convention
already documented in CLAUDE.md) resolves the same way in the gate as it
does at real deploy time (deploy-node.sh's `docker compose ... up --build`).
No behavior change for existing single-context services — verified against
llm-gateway's compose file.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-22 16:06:18 +02:00
|
|
|
"twardy inwariant"): the configured `EMBED_MODEL` must already be the model behind the active
|
|
|
|
|
embeddings in both `document_chunk` and `document_summary`, or kb-query refuses to start
|
|
|
|
|
(crash-loop, visible via container restarts in monitoring -- deliberately loud, never a silent
|
|
|
|
|
mismatch). There is no per-request model choice today, so this is the only place drift could
|
|
|
|
|
sneak in (someone changes `EMBED_MODEL` without a re-index).
|
|
|
|
|
|
|
|
|
|
`document_summary.model` is the LLM that WROTE the summary (`claude-haiku-4-5` / `gemma3:12b`
|
|
|
|
|
-- see `services/kb-postgres/init/004_summaries.sql`), not the embedder; the column that
|
|
|
|
|
records which model embedded the summary text is `embedding_model`. The plan's SQL sketch for
|
|
|
|
|
this check named `model` for both tables -- checking `document_summary.model` against
|
|
|
|
|
`EMBED_MODEL` would never match (summaries are never written by `bge-m3`) and the service would
|
|
|
|
|
refuse to start unconditionally. Checked live against kb-postgres@PIHA on 2026-07-22 before
|
|
|
|
|
writing this: `document_summary.model` holds `{claude-haiku-4-5, gemma3:12b}`,
|
|
|
|
|
`document_summary.embedding_model` holds `{bge-m3}` -- `embedding_model` is the correct column.
|
|
|
|
|
"""
|
|
|
|
|
from __future__ import annotations
|
|
|
|
|
|
|
|
|
|
import asyncpg
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class ModelInvariantError(RuntimeError):
|
|
|
|
|
"""The configured EMBED_MODEL is absent from document_chunk/document_summary embeddings."""
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
async def validate_embed_model(conn: asyncpg.Connection, embed_model: str) -> None:
|
|
|
|
|
chunk_rows = await conn.fetch(
|
|
|
|
|
"SELECT DISTINCT model FROM document_chunk "
|
|
|
|
|
"WHERE excluded_reason IS NULL AND embedding IS NOT NULL"
|
|
|
|
|
)
|
|
|
|
|
chunk_models = {r["model"] for r in chunk_rows}
|
|
|
|
|
if embed_model not in chunk_models:
|
|
|
|
|
raise ModelInvariantError(
|
|
|
|
|
f"EMBED_MODEL={embed_model!r} not found among document_chunk.model "
|
|
|
|
|
f"of active embeddings ({sorted(chunk_models) or 'none'})"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
summary_rows = await conn.fetch(
|
|
|
|
|
"SELECT DISTINCT embedding_model FROM document_summary WHERE embedding IS NOT NULL"
|
|
|
|
|
)
|
|
|
|
|
summary_embed_models = {r["embedding_model"] for r in summary_rows}
|
|
|
|
|
if embed_model not in summary_embed_models:
|
|
|
|
|
raise ModelInvariantError(
|
|
|
|
|
f"EMBED_MODEL={embed_model!r} not found among document_summary.embedding_model "
|
|
|
|
|
f"of active embeddings ({sorted(summary_embed_models) or 'none'})"
|
|
|
|
|
)
|