Контекст
#321 премести схема-корпуса на native Vectorize namespace (SCHEMA_NS = 'schema-v2', rag.ts) и retrieval-ът чете само от него. indexSchemaCorpus съществува и е тестван — но нищо в репото не може да го изпълни: grep из целия repo намира само rag.ts, тестовете и README, а „инструкцията" в README е гол TS израз (indexSchemaCorpus(embeddingRunnerFor(env.AI), env.VECTORIZE)), реферираш bindings, които съществуват единствено вътре в Worker-а.
Следствие: след deploy всяка среда е на full-dictionary fallback — всеки ход логва {"evt":"assistant.rag","matched":0,"aboveFloor":0,"kept":0} — и данните за рекалибрацията на релевантния floor (#318) не се трупат от реален RAG. Безопасно, но обезсмисля grounding-а, докато някой не напише код на ръка.
Какво трябва да може
Еднократно (при provisioning) и при всяка промяна на корпуса: embed на chunk-овете (в момента 25) + upsert в schema-v2 — с логваната бройка, за да е проверимо.
Варианти
-
Secret-gated admin route в Worker-а (напр. POST /admin/index-schema, Bearer secret през wrangler secret put).
- ➕ ползва същите bindings и СЪЩИЯ код (
buildSchemaChunks/indexSchemaCorpus) — нула дрифт; работи еднакво във всяка среда.
- ➖ нова повърхност в публичния Worker: иска rate limit, метод/секретна проверка и security преглед.
-
Node скрипт през Cloudflare REST API (Workers AI run + Vectorize upsert с API token, извън Worker-а).
- ➕ никаква нова повърхност; пуска се от лаптоп или CI.
- ➖ скриптовете в репото са .mjs без TS loader → или дублира корпуса (дрифт риск — точно класата грешка, която дрифт-пазачът лови), или вкарва tsx/loader зависимост.
-
Deploy стъпка (workflow вика (1) след deploy, само при промяна на корпуса — сравнение по хеш на chunk текстовете, записан напр. като KV ключ или резервиран вектор).
- ➕ не се забравя никога; ре-индексът спира да е ръчна дисциплина.
- ➖ изисква (1) или (2) като механизъм; трябва маркер, за да не прави embed на всеки deploy.
Предложение
(1) + (3): малък route, заключен със secret + POST-only + структуриран лог {"evt":"assistant.index","upserted":N,"ns":"schema-v2"}, викан ръчно при provisioning и от deploy стъпка при промяна на корпуса. Вариант (2) отпада главно заради дублирането — README вече документира, че текстът на chunk-овете е source of truth само ако индексът се репопулира, и второ копие на корпуса извън describe-schema.ts е готов източник на тих дрифт.
Критерии за готово
Свързани: #317 (native namespaces), #318 (наблюдаемост и рекалибрация на floor-а), #321 (schema-v2 прехода; там е отбелязано като follow-up).
Контекст
#321 премести схема-корпуса на native Vectorize namespace (
SCHEMA_NS = 'schema-v2',rag.ts) и retrieval-ът чете само от него.indexSchemaCorpusсъществува и е тестван — но нищо в репото не може да го изпълни: grep из целия repo намира самоrag.ts, тестовете и README, а „инструкцията" в README е гол TS израз (indexSchemaCorpus(embeddingRunnerFor(env.AI), env.VECTORIZE)), реферираш bindings, които съществуват единствено вътре в Worker-а.Следствие: след deploy всяка среда е на full-dictionary fallback — всеки ход логва
{"evt":"assistant.rag","matched":0,"aboveFloor":0,"kept":0}— и данните за рекалибрацията на релевантния floor (#318) не се трупат от реален RAG. Безопасно, но обезсмисля grounding-а, докато някой не напише код на ръка.Какво трябва да може
Еднократно (при provisioning) и при всяка промяна на корпуса: embed на chunk-овете (в момента 25) + upsert в
schema-v2— с логваната бройка, за да е проверимо.Варианти
Secret-gated admin route в Worker-а (напр.
POST /admin/index-schema, Bearer secret презwrangler secret put).buildSchemaChunks/indexSchemaCorpus) — нула дрифт; работи еднакво във всяка среда.Node скрипт през Cloudflare REST API (Workers AI run + Vectorize upsert с API token, извън Worker-а).
Deploy стъпка (workflow вика (1) след deploy, само при промяна на корпуса — сравнение по хеш на chunk текстовете, записан напр. като KV ключ или резервиран вектор).
Предложение
(1) + (3): малък route, заключен със secret + POST-only + структуриран лог
{"evt":"assistant.index","upserted":N,"ns":"schema-v2"}, викан ръчно при provisioning и от deploy стъпка при промяна на корпуса. Вариант (2) отпада главно заради дублирането — README вече документира, че текстът на chunk-овете е source of truth само ако индексът се репопулира, и второ копие на корпуса извънdescribe-schema.tsе готов източник на тих дрифт.Критерии за готово
schema-v2(и бъдещ bump) без писане на нов код.indexSchemaCorpus.Свързани: #317 (native namespaces), #318 (наблюдаемост и рекалибрация на floor-а), #321 (schema-v2 прехода; там е отбелязано като follow-up).