doc: уточнения Opus — advisory lock, NFKC, формат промпта с ID

This commit is contained in:
“Naeel”
2026-06-23 00:14:32 +04:00
parent d7ccee0094
commit 0ed3fa4281
+41
View File
@@ -62,3 +62,44 @@
В3 и В4 решаются одним сдвигом — давать LLM spec_current с готовыми ID и считать/резолвить всё на сервере. Это убирает и нестабильные хэши, и пустые ячейки в UI.
**Уточнение Opus:** допники у вас кумулятивные (могут менять то, что добавили предыдущие) или независимые?
---
## Уточнения (23.06.2026)
### 1. Advisory lock в CFML
**Да, безопасен.** `pg_advisory_xact_lock` — транзакционный: снимается автоматически при завершении транзакции (и commit, и rollback).
Условия в Lucee:
- Лок и INSERT в одном `<cftransaction>` — одно соединение, одна транзакция
- `pg_advisory_xact_lock` требует быть внутри транзакции — `<cftransaction>` гарантирует
Ключ: `pg_advisory_xact_lock(hashtext(contract_id))`. Коллизии hashtext безвредны — два контракта просто сериализуются.
### 2. NFKC-нормализация — в PostgreSQL
Делать в PostgreSQL, в том же выражении что считает хэш. Python не дублировать.
NFKC НЕ объединяет разные тире. Нужна связка в одном выражении:
```sql
lower(trim(regexp_replace(translate(normalize(name, NFKC), '–—‑−«»""', '------""'), '\s+', ' ', 'g')))
```
Всё одним выражением — для INSERT-хэша и для lookup.
### 3. Формат spec_current в промпте с готовыми ID
Давать LLM компактный список с коротким суррогатным id (`r1, r2...`):
```json
{"current_spec": [
{"id": "r1", "name": "Аренда стойко-места...", "price": 15000, "qty": 2, "sum": 30000, "date_start": "2025-01-01"}
]}
```
Инструкция в промпте:
- UPDATE: `{"op":"UPDATE","target_id":"r1","new_values":{...}}`
- DELETE: `{"op":"DELETE","target_id":"r2"}`
- ADD: `{"op":"ADD","new_row":{...}}` (без id)
LLM не видит хэши — только выбирает из готового набора. Сервер маппит `id → name_hash`. Устойчивее, меньше токенов, нет шанса опечатки в md5.