fix(assistant): semantic_search през native Vectorize namespace вместо metadata филтър

[nedda76]

Closes #317

Какво

semanticSearch минава от filter: { ns: 'entity' } към native Vectorize namespace (ENTITY_NS = 'entity-v1') — последната употреба на metadata филтър в RAG модула изчезва.

Защо

Vectorize зачита metadata филтри само върху свойства с провизиран metadata index (wrangler vectorize create-metadata-index), а репото не провизира нито един. Върху реален индекс филтрираната заявка греши или под-филтрира — тихо, защото извикващите поглъщат грешката. Native namespace-ът не изисква индекс и се прилага преди всякакви филтри. Схема-страната мина на същия модел в #223; това изравнява entity-страната.

Entity корпус никога не е индексиран (indexer-ът е „Какво остава" от Фаза 2), така че няма legacy кохорт за миграция.

От ревюто (второ комитче)

• Header-ът на модула вече не твърди, че FTS инструментът search_entities съществува (само спецификация е).
• Правилото „WHEN TO BUMP" изрично НЕ се пренася върху entity корпуса — той е производен от данните и бъдещият indexer се нуждае от собствен reconciliation/delete път.
• metadata.ns е маркиран като форензично поле — НЕ филтруемо.
• semanticSearch деградира match без score до 0 вместо TypeError в tools.ts (+ тест).
• Namespace тестовете коват и броя на заявките (toHaveBeenCalledTimes(1)), за да не може filter-базиран retry да мине зелен.

Стак

Стъпва върху #223 (fix/assistant-integrity-grounding) — за ревю са последните 2 комита (612ed88, ceb1942); останалото е диффът на #223, който ще изчезне след мърджа му. Ред на мърдж: #223 → този PR.

Проверено

tsc -b чист, 182/182 теста на assistant пакета, Prettier чист.

Свързани issue-та

• Реф assistant: CD гаранция, че schema-v2 корпусът е индексиран — health check след deploy (и кой може да го направи) #346 — CD гаранция, че schema-v2/entity-v1 са индексирани (health check след deploy). Този PR не го затваря: деплой без indexSchemaCorpus в новия namespace остава безопасен fallback, видим само в stats линията от feat(assistant): наблюдаем RAG fallback — статистика на retrieval-а и логнати деградации #321; механизмът, който пълни namespace-а, е Изпълним вход за indexSchemaCorpus — нищо не може да напълни schema-v2 #328.

[ydimitrof]

Ревю на PR: fix(assistant): semantic_search през native Vectorize namespace вместо metadata филтър

Обща оценка: 9.5/10 — APPROVE (с една незадължителна, насочена към бъдещето бележка).

Фаза 0 — Сигурност (задължителна, блокираща): ЧИСТО ✅

• Няма твърдо кодирани тайни. BGGPT_API_KEY се подава само през wrangler secret put (интерактивно), README изрично отбелязва „никога не се комитва".
• Няма нови/съмнителни URL-и. @cf/baai/bge-m3 е Workers AI идентификатор на модел, не мрежов адрес.
• Няма зловредни шаблони (backdoors, инжекции, обфускация).
• Зависимости: единствената промяна е osv-scanner.toml — игнориране на GHSA-f88m-g3jw-g9cj (libvips CVE в sharp<0.35.0). Обосновката е коректна: транзитивна, само-dev зависимост през miniflare, извън разгърнатия Worker, без достъпна поправка в диапазона (^0.34.5), с ignoreUntil дата. ✅
• Подобрение на сигурността: в report-schema.ts резолвнатите колони вече се строят ЯВНО поле по поле вместо { ...c } — това спира пренасянето на непознати, модел-подадени свойства към рендера (validateEmitShape не отхвърля непознати ключове). Заедно с whitelist-а isAlign (left|right) това затваря вектор за атрибут-инжекция. Отлично.

Тестове (3.0/3.0) ✅

Изключително силно тестово покритие, писано да разкрива дефекти, не да минава тривиално:

• rag.test.ts пинва литерала schema-v2/entity-v1 (не SCHEMA_NS), така че bump-ът е съзнателен акт; проверява toHaveBeenCalledTimes(1) + expect.not.objectContaining({ filter }) — exhaustively изключва скрит filter-based fallback; покрива scoreless match и relevance floor.
• system-prompt.test.ts тества през реалния write→read seam (indexSchemaCorpus → retrieveSchemaContext → buildSystemPrompt) и гарантира, че всеки trap се рендира точно веднъж (регресията с двойно рендиране).
• sql-guard.test.ts, report-schema.test.ts, emit-report-schema.test.ts покриват новите пътища (агрегати, магнитуден суфикс, cap-ове, align).

Код-качество (2.0/2.0) ✅

• renderTraps() е споделен между describeSchema() и hardTraps() — премахва дублиране и drift на trap-текста между двата пътя (изпълнява NO CODE DUPLICATION).
• Промяната от /милиард|милион/ към суфиксите /илион|илиард/ е коректна (мил-ион ⊃ илион, мил-иард ⊃ илиард), затваря реда нагоре (квинтилион/секстилион) вместо ръчен списък; свръх-флагването е в безопасната посока за gate.
• sql-guard разширението (group_concat/string_agg/json_group_array/json_group_object) коректно адресира същия OOM-amplification клас като printf. Заслужава похвала честната бележка, че denylist-ът е catch-up игра и allowlist е трайната поправка.

Документация (2.0/2.0) ✅

README е обстоен: правилото „WHEN TO BUMP", версионираният native namespace, rollback-семантиката (нов кохорт до стария), безопасният fallback (0 чънка → пълен статичен речник) и предупреждението, че entity корпусът е data-derived и НЕ следва append-only bump правилото. Ясен операционен runbook преди deploy.

Производителност (2.0/2.0) ✅

• MIN_SCHEMA_SCORE floor предотвратява „частично grounding, по-слабо от no-RAG" — реален коректностен и качествен gain.
• Native namespace изключва stale кохорти на източника (никакви пропилени topK слотове), без нужда от provisioned metadata index.
• sql-guard спира single-row OOM на изолата.

Security (agent-level, 1.0/1.0) ✅

Няма нови уязвимости; входната валидация и error handling са затегнати.

Дребни / незадължителни бележки (не блокират)

1. Асиметрия във floor-а (вж. inline): retrieveSchemaContext има MIN_SCHEMA_SCORE, но semanticSearch няма релевантен праг — само деградира липсващ score до 0. Днес е безвредно (entity namespace е празен по дизайн), но когато entity indexer-ът от Фаза 2 напълни корпуса, нискорелевантни попадения ще стигат до модела като „hits". Препоръка: симетричен праг при активиране на индексера.
2. Почистване на стар кохорт е ръчно: wrangler vectorize delete-vectors иска изричен списък id-та, възстановими от git историята на buildSchemaChunks — крехко, но документирано и небезопасно само при преждевременно триене (rollback остава без RAG). Приемливо за v1.
3. Структурни типове vs реални bindings: коментарът честно отбелязва, че as unknown as кастът в route-а скрива drift от tsc спрямо worker-configuration.d.ts — заслужава внимание при бъдещи промени по VectorIndex.

CLAUDE.md съответствие: без частични имплементации, без TODO-симплификации, без дублиране, без мъртъв код, смислени тестове, консистентно наименуване, разделени концерни. Промяната е атомарна и фокусирана върху единствен концерн (native namespace миграция + свързаните hardening follow-up-и от предходни ревюта).

Препоръка: APPROVE — може да се мърдж-не безопасно; бележка №1 да се адресира заедно с entity indexer-а във Фаза 2.

[ydimitrof]

Ревю на PR: fix(assistant): semantic_search през native Vectorize namespace

Фаза 0 — Сканиране за критична сигурност: ЧИСТО ✅

• Твърдо кодирани тайни: няма. BGGPT_API_KEY навсякъде се третира като wrangler secret и изрично „никога не се комитва".
• URL промени: няма нови URL-и; @cf/baai/bge-m3 е име на Workers AI модел, не мрежов адрес.
• Зловредни шаблони: няма backdoor/eval/обфускация.
• Промени в зависимости: няма нови пакети. osv-scanner.toml добавя потискане на CVE (sharp <0.35.0, GHSA-f88m-g3jw-g9cj) — обосновката е коректна (транзитивна dev-only зависимост през miniflare, не влиза в деплойнатия Worker; няма upstream fix в диапазона) и има ignoreUntil, който ще я извади наяве. Прието.

Резултат: не се блокира. Преминаваме към пълно ревю.

Обобщение по измерения

Архитектура / коректност (силно): Смяната от metadata filter: { ns } към native Vectorize namespace е правилният подход — native namespace-ите работят без provisioned metadata индекс (issue #317) и изключват стари кохорти на ниво заявка, вместо да хабят topK слотове. Версионирането в namespace-а И в id-тата (schema-v2:) прави ре-индекса cohort-safe спрямо Worker rollback. Правилото „WHEN TO BUMP" е ясно документирано и разграничението, че за entity-корпуса (data-derived) то НЕ важи едно към едно, е точно.

Сигурност (agent-level):

• sql-guard.ts — добавянето на group_concat/string_agg/json_group_array/json_group_object към денилиста затваря реален клас на memory-amplification (цял scan → една клетка преди capRows). Правилно е разпознат string_agg като SQLite ≥3.44 синоним. Забележката, че позитивен allowlist е трайното решение, е коректна.
• emit-report-schema.ts — таваните за масиви (MAX_BLOCKS/ITEMS/COLUMNS) + short-circuit преди per-item scan-а е добра защита срещу необвързан вход; isAlign whitelist предотвратява out-of-enum стойност да стигне до renderer, който я интерполира в атрибут/стил.
• report-schema.ts — експлицитното изграждане на колоните (вместо spread) блокира преминаването на непознати model-supplied ключове; суфиксният шаблон -илион/-илиард затваря магнитудите нагоре. Приемането на near-collision (напр. „Илион") е съзнателен fail-toward-flagging избор — приемливо.

Тестове: Много силно покритие — floor-филтъра, scoreless match, exhaustive corpus-length проверка (никой trap chunk не се преиндексира), и композиционен тест през реалния write→read seam (indexSchemaCorpus → retrieveSchemaContext → buildSystemPrompt) с проверка „всеки trap се рендира точно веднъж". Тестовете са смислени, не тривиални.

Документация: README-секцията за ре-индексиране и почистване на стари кохорти е изчерпателна и обвързва операционните последствия (rollback прозорец) с кода.

Забележки (незадължителни)

1. Натрупване на orphan вектори: старите schema:* вектори (default namespace) остават в индекса завинаги след bump. Безвредни за retrieval (namespace ги изключва), но растат разхода/размера. README го признава като „не е задължително" почистване — ОК, но си струва проследяване в беклога.
2. MIN_SCHEMA_SCORE/MIN_ENTITY_SCORE = 0.35 са консервативни и добре обосновани; тъй като entity-корпусът е още непопълнен, стойността е неизбежно неоткалибрирана до първите реални данни — предвидете преразглеждане при пускане на entity indexer-а.

Вердикт

Няма блокиращи или критични находки. Кодът е чист, добре тестван и добре документиран. Слагам COMMENT вместо APPROVE само защото quality-gate изисква реално изпълнение на тестовия пакет (pnpm --filter web test) и typecheck, което не мога да изпълня в тази среда — препоръчвам APPROVE след потвърждение, че CI е зелен.

[ydimitrof]

Ревю на PR: fix(assistant): semantic_search през native Vectorize namespace вместо metadata филтър

Обобщение

PR-ът мигрира scoping-а на RAG извличането от metadata filter: { ns } към native Vectorize namespaces (schema-v2, entity-v1), премахва зависимостта от несъществуващ metadata index (#317), въвежда версиониране на корпуса, relevance floor за двата пътя (MIN_SCHEMA_SCORE / MIN_ENTITY_SCORE), изважда DATA_TRAPS от векторния корпус и ги инжектира безусловно чрез hardTraps(). Придружен е от подсилване на sql-guard, emit-report-schema капове, разширяване на prose-number gate-а и osv-scanner ignore за dev-only sharp CVE.

Обща оценка: ~9.4/10 — препоръка APPROVE. Промяната е атомарна, добре мотивирана и изключително добре покрита с тестове. Не открих блокиращи проблеми.

Phase 0 — Security-Critical Scan: CLEAN

• Hardcoded secrets: няма. BGGPT_API_KEY се борави само през wrangler secret put (документирано, интерактивно, некомитвано).
• URL промени: няма нови външни URL-и; @cf/baai/bge-m3 е Workers AI capability, не мрежов ендпойнт.
• Malicious patterns: няма backdoor/обфускация/eval.
• Dependencies: няма нови пакети; osv ignore за GHSA-f88m-g3jw-g9cj е за транзитивен dev-only sharp през miniflare, извън деплойнатия Worker, с ignoreUntil дата и ясен REMOVE WHEN — обосновката е коректна.

Security (agent-level): силна

• sql-guard разширява денилиста с string-building агрегати (group_concat/string_agg/json_group_array/json_group_object) — реален memory-amplification клас, спрян преди capRows. Затварянето на quoted-identifier байпаса ("group_concat"(x), [..], `..`) е точна находка. Регексът fail-ва към флагване, което е правилната посока.
• emit-report-schema: isAlign whitelist + експлицитното изграждане на колони в report-schema.ts (без { ...c }) премахва канал за пропускане на непроверени model-полета към рендера — добро defense-in-depth срещу attribute/style injection.
• Prose-number gate: покриването на -илион/-илиард суфиксите (вместо явен списък) затваря defamation-scale вектора нагоре; над-флагването на „Илион/Троя" е приемливо за register-а.

Tests: отлични

• Всеки нов клон има целеви тест: namespace литерали пиннати (умишлено не през константата), relevance floor (над/под/scoreless), cap short-circuit, quoted-identifier байпас, композиционен тест през реалния write→read seam с проверка „всеки trap точно веднъж". Тестовете са смислени, не тривиални.
• Забележка: не изпълних тестовия пакет в тази среда (typecheck/pnpm --filter web test не са пуснати) — валидацията стъпва на статичен прочит на diff-а. Preмерджа потвърдете зеления пакет.

Code Quality / CLAUDE.md: съответства

• renderTraps() премахва дублиране между describeSchema() и hardTraps() — единен източник, не могат да дрейфнат.
• Няма partial impl / TODO / dead code; коментарите документират инвариантите (WHEN TO BUMP, forensic-only metadata) добре.

Незначителни наблюдения (non-blocking) — виж inline коментарите

1. Регекс-денилистът е по своята същност догонваща игра; positive allowlist остава трайното решение (вече е трекнато).
2. Миграционен detail за orphan вектори в default namespace от евентуално предишно индексиране — уверете се, че README cleanup пътят го покрива.

Performance: без регресии

Relevance floor намалява шума в prompt-а; native namespace изключва stale кохорти на ниво индекс (не хаби topK слотове). Няма нови N+1 или неограничени скани — каповете (MAX_BLOCKS/ITEMS/COLUMNS) добавят горна граница там, където преди нямаше.

Documentation: пълна

README покрива ре-индексиране, версиониране, rollback прозорец и разликата entity-vs-schema BUMP правилото. Точно и актуално.

[ydimitrof]

Прегледах PR-а като инженер на Sigma. Основната промяна — semantic_search и schema retrieval да минават през нативен Vectorize namespace (entity-v1 / schema-v2) вместо metadata filter { ns } — е коректна и добре обоснована: metadata филтър изисква provisioned metadata индекс, какъвто репото няма (#317), а нативните namespace-и изключват старите кохорти още на източника, така че pre-v2 trap-векторите не могат да заемат topK слотове. Версионирането на namespace-а и id-тата (нов кохорт до стария) пази rollback на Worker-а, а неиндексирана среда пада безопасно към пълния статичен речник.

Проверих приоритетно:

• Злонамерен код / сигурност: няма exfiltration, нови мрежови извиквания или подозрителни зависимости. Добавянето в osv-scanner.toml (sharp през miniflare, dev-only, с ignoreUntil) е добре мотивирано и легитимно. Няма prompt-injection към ревюто; текстът за игнориране на инструкции в тестовете е защитна клауза, не команда.
• Инжекции: SQL guard-ът е разширен смислено — string-building агрегатите (group_concat / string_agg / json_group_*) и quoted-identifier байпасите вече се хващат; регексът fail-ва към блокиране, което е правилната посока. XSS повърхността при align е затворена с whitelist в validateEmitShape плюс експлицитно изграждане на колоните в bindReport (без spread на непознати ключове).
• Data integrity: hard-traps се инжектират безусловно през hardTraps(), така че RAG turn никога не остава с по-малко ограничения от no-RAG fallback — добро решение на регресията с двойно рендиране/липсващ trap. Relevance floor-овете предпазват от инжектиране на off-topic контекст.
• Коректност: cap-овете на масивите (blocks/items/columns) и short-circuit при over-cap са тествани и разумни; Number.isFinite в entity пътя коректно отхвърля scoreless match при всеки floor.

Едно оперативно уточнение (не блокира): вече deploy-натите среди трябва да пуснат indexSchemaCorpus наново след мърдж, иначе schema-v2 е празен и RAG grounding-ът временно пада към пълния речник — безопасно, но добре е да е стъпка в runbook-а на deploy. README го покрива.

Кодът е чист, добре тестван и добре документиран. Оставям само една дребна бележка за консистентност.

[lyubomir-bozhinov]

Прегледах #319 (собствените 5 комита над #223, при HEAD ac8840ff) — фокус: native Vectorize namespacing + relevance floor.

Data isolation — чисто: и трите Vectorize извиквания подават явен, hardcoded namespace: upsert + schema query namespace: SCHEMA_NS ('schema-v2', rag.ts:125/159), entity query namespace: ENTITY_NS ('entity-v1', :217). Няма path без namespace (тестът пин-ва query на 1 извикване + not.objectContaining({filter})), няма user input в namespace-а (въпросът влиза само в embed() като текст на вектора). Version-mismatch е fail-safe: неиндексиран env → 0 съвпадения → retrieveSchemaContext връща [] → системният промпт пада на пълния статичен речник (describeSchema()), никога грешен корпус.

Relevance floor — чисто и симетрично: и двата пътя са байт-за-байт filter((m) => Number.isFinite(m.score) && m.score >= minScore) (:170, :224) — scoreless/undefined/NaN пада за ВСЕКИ floor, вкл. explicit 0 (поправя base-овия (m.score ?? 0) >= 0 smuggle). MIN_SCHEMA_SCORE === MIN_ENTITY_SCORE === 0.35.

Наблюдение (не дефект): entity корпусът още не е индексиран → semanticSearch връща 0 днес (документирано, „Няма семантични съвпадения."); бъдещият entity indexer ТРЯБВА да upsert-ва с namespace: ENTITY_NS — вече отбелязано в коментара.

Merge-ред: стек над #223 → #223 първо. Нямам блокери по собствената делта на #319.

[nedda76]

Благодаря за прегледа. По собствената делта на #319 няма промени; клонът е пребазиран върху обновения #223 (jsonb в денилиста + затворен comment-desync байпас на функционалния денилист, вече пазен и на AST ниво — детайлите са в коментара там), така че дифът тук отново е петте комита на entity namespace-а плюс основата.

[nedda76]

Пребазирано върху текущия main (8529c12); собствената делта на PR-а е непроменена.

[ydimitrof]

Прегледах цялостно PR-а като старши инженер по проекта Sigma, включително обкръжаващия код, а не само дифа.

Обобщение: Промяната е чиста, добре обоснована и изключително добре покрита с тестове. Основната цел (native Vectorize namespace вместо metadata филтър за retrieveSchemaContext и semantic_search) е коректно реализирана и подобрява поведението: стари кохорти (напр. pre-v2 schema:trap:N) вече не могат да заемат topK слотове, а липсата на metadata index (#317) е адресирана. Съпътстващите защити са солидни:

• Сигурност (SQL guards): Затворен е реален bypass — коментар, скрит зад кавичка в quoted identifier (AS "x'y"), който преди е разминавал stripComments/splitStatements. Новото моделиране на четирите форми на цитиране ('…', "…", `…`, […]) чрез споделен quotedSpanEnd, плюс denylist за string-building агрегати (group_concat/string_agg/json(b)_group_*) на две нива (лексикално + AST по разрешеното от парсера име) е защита в дълбочина с fail-closed поведение. Positive controls срещу over-blocking присъстват.
• Данни/коректност: Relevance floor с Number.isFinite (а не ?? 0) коректно третира match без score като „под прага", което същевременно премахва потенциален TypeError в score.toFixed. Празен резултат безопасно връща пълния статичен речник.
• XSS/валидация: whitelist за align (left|right) и явното изграждане на колоните в bindReport (вместо spread, който би пренесъл непроверени полета към renderer-а) са добри hardening мерки. Ограниченията на дължината на масивите (blocks/items/columns) са разумни.
• Prompt hardening: hardTraps() гарантира, че RAG ход никога не е с по-малко ограничения от no-RAG fallback; тестът за „exactly once" рендиране е точно на място.

Не открих враждебен код, ексфилтрация, неочаквани мрежови извиквания, промени по auth/permissions/workflow файлове или зависимости извън заявената цел. Няма инструкции за ревюто в диффа (без prompt-injection).

Един оперативен момент за внимание е отбелязан inline (не блокиращ). Одобрявам.

[nedda76]

Отворих #346 за CD гаранцията, за която питахте в ревюто — health check след deploy, че schema-v2 е индексиран, и какво от него можем сами (health route в Worker-а, нула нови scope-ове) срещу какво иска собственика на акаунта (Vectorize/Workers AI права на deploy token-а за CI-страна проверка). Предпоставката е #328. Референцията е и в описанието на PR-а.

[nedda76]

Пребазирах върху текущия main (62369ff) и обновения #223 (ce9463d — поправка на лексикалния guard, детайлите са в коментара там). Собствената делта на PR-а е patch-идентична (git range-diff).

Reviewed-SHA: 488e03a одобрено — делтата е непроменена спрямо одобрената; сливането с main е проверено (засегнатите от двете страни файлове не си противоречат, main не добавя миграции в този интервал); CI-еквивалентът минава локално.