Этап 4 corrective pack 2 по family isolation после текущих routing fixes
This commit is contained in:
+72
@@ -0,0 +1,72 @@
|
||||
# ЭТАП 4 — переход к семействам вопросов и source-to-proof контрактам
|
||||
|
||||
Статус: `APPROVED_EXECUTION_MODEL`
|
||||
Дата: `2026-03-29`
|
||||
Область: `Stage 4 (P0-only)`
|
||||
|
||||
## 1. Почему режим работы меняется
|
||||
|
||||
Точечная отладка отдельных вопросов была полезна как разведка, но как основная модель развития она не масштабируется:
|
||||
|
||||
- один удачный ответ не закрывает класс дефектов;
|
||||
- слишком много ручной подгонки под формулировки;
|
||||
- приемка становится неустойчивой.
|
||||
|
||||
Stage 4 официально переводится в `family-based execution`.
|
||||
|
||||
## 2. Что уже известно по Stage 4
|
||||
|
||||
- общий аудит дал `MULTI_NODE_FAILURE_CONFIRMED`;
|
||||
- VAT family: рабочий positive path уже есть на части кейсов;
|
||||
- RBP family: выведена из критического режима, но есть незакрытый `source coverage`;
|
||||
- FA family: proof path поднят, но live acceptance еще требует дожима.
|
||||
|
||||
## 3. Новый официальный формат Stage 4
|
||||
|
||||
С этого момента:
|
||||
|
||||
- единица анализа: `question family`;
|
||||
- единица реализации: `family pack`;
|
||||
- единица приемки: `family acceptance` на наборе вариаций.
|
||||
|
||||
## 4. Реестр family (активный)
|
||||
|
||||
1. VAT chain
|
||||
- Card: [Stage 4 - Family Card v1 — VAT chain.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 — VAT chain.md)
|
||||
- Latest run: [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\run_summary.json)
|
||||
|
||||
2. RBP tail / write-off overstay
|
||||
- Card: [Stage 4 - Family Card v1 RBP.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 RBP.md)
|
||||
- Latest run: [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix\run_summary.json)
|
||||
|
||||
3. FA amortization coverage
|
||||
- Card: [Stage 4 - Family Card v1 FA.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 FA.md)
|
||||
- Latest run: [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure\run_summary.json)
|
||||
|
||||
## 5. Что считается закрытием family
|
||||
|
||||
Family считается закрытой не по одному ответу, а только при выполнении всего контракта:
|
||||
|
||||
- оформлена family card;
|
||||
- source coverage и ограничения зафиксированы;
|
||||
- relation map собран и проверяем;
|
||||
- live recipe воспроизводим;
|
||||
- admissibility и answer/proof contract зафиксированы;
|
||||
- regression-пакет проходит приемку;
|
||||
- `false_grounded_answer_rate = 0`.
|
||||
|
||||
## 6. Границы Stage 4
|
||||
|
||||
Это не Stage 5 и не новая архитектура:
|
||||
|
||||
- без новых доменов;
|
||||
- без graph/schema expansion;
|
||||
- без Stage 5 как core path;
|
||||
- без полного redesign.
|
||||
|
||||
## 7. Execution-практика
|
||||
|
||||
- планируем и исполняем работу family-pack'ами;
|
||||
- после каждого прогона обязательны run-артефакты в `llm_normalizer/docs/runs`;
|
||||
- фиксируем приемку на уровне family, а не единичного вопроса;
|
||||
- сквозная навигация по family и run ведется в [STAGE_04_FAMILY_BACKLOG_2026-03-29.md](X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\03_execution\STAGE_04_FAMILY_BACKLOG_2026-03-29.md).
|
||||
@@ -0,0 +1,159 @@
|
||||
# FAMILY_CARD_TEMPLATE (runtime-aligned)
|
||||
|
||||
**document_status:** `ACTIVE`
|
||||
**template_scope:** `Stage 4 (P0-only)`
|
||||
**execution_unit:** `family pack`
|
||||
|
||||
## 0) Header (обязательные метаданные family)
|
||||
|
||||
- `family_name`:
|
||||
- `family_id`:
|
||||
- `stage_scope`:
|
||||
- `current_family_status`: `accepted` / `accepted_with_limitations` / `not_accepted`
|
||||
- `primary_gap`:
|
||||
- `latest_pack`:
|
||||
- `next_pack_focus`:
|
||||
- `family_source_of_truth_questions`:
|
||||
- `family_latest_live_replay`:
|
||||
- `family_latest_acceptance_run`:
|
||||
|
||||
## 1) Что фиксирует документ
|
||||
|
||||
- Зачем карточка нужна для этой family.
|
||||
- Почему карточка делится на:
|
||||
- `Runtime V1 (as-is)` — только подтвержденный факт по коду/артефактам;
|
||||
- `Target V2 (planned)` — план следующего доведения.
|
||||
|
||||
## 2) Runtime V1 (фактический контракт)
|
||||
|
||||
### 2.1 Claim contract (as-is)
|
||||
|
||||
- `primary_claim_type`:
|
||||
- `additional_claim_types` (если уже first-class в runtime):
|
||||
- `claim_boundaries` (что не входит в Stage 4):
|
||||
|
||||
### 2.2 Required anchors (runtime-enforced)
|
||||
|
||||
- Какие anchors обязательны именно сейчас.
|
||||
- Какие reason codes использует runtime при нехватке anchors.
|
||||
|
||||
### 2.3 Claim-bound live recipe (runtime-enforced)
|
||||
|
||||
- Список обязательных live/MCP call id.
|
||||
- Что каждый шаг должен подтверждать.
|
||||
- Что считается успешным live hit.
|
||||
|
||||
### 2.4 Route behavior (as-is)
|
||||
|
||||
- Как runtime принудительно удерживает route для family.
|
||||
- Какой no-route recovery используется.
|
||||
- Какие debug audit-поля экспортируются.
|
||||
|
||||
### 2.5 Evidence / admissibility behavior (as-is)
|
||||
|
||||
- Какие правила admissibility реально применяются.
|
||||
- Какие baseline reject reasons наблюдались до последнего пакета.
|
||||
- Что уже исправлено на materialization уровне.
|
||||
|
||||
### 2.6 Runtime acceptance snapshot
|
||||
|
||||
- `*_FIXED` / `NOT_FIXED` статусы из последнего run.
|
||||
- Краткий verdict latest pack.
|
||||
|
||||
### 2.7 known_runtime_limits (as-is)
|
||||
|
||||
- `source coverage` ограничения.
|
||||
- Возможные scope/route inconsistency в живых трассах.
|
||||
- Краевые риски по anchor quality / mapping.
|
||||
|
||||
## 3) Target V2 (planned, не критерий текущей приемки)
|
||||
|
||||
### 3.1 Planned claim extension
|
||||
|
||||
- Какие дополнительные claim types хотим сделать first-class.
|
||||
|
||||
### 3.2 Planned anchor extension
|
||||
|
||||
- Какие anchors добавятся как обязательные для зрелой версии family.
|
||||
|
||||
### 3.3 Planned family metrics
|
||||
|
||||
- Набор целевых метрик family.
|
||||
- Отдельно пометить, какие уже есть в harness, а какие пока target-only.
|
||||
|
||||
## 4) Required entities and relations (business contract)
|
||||
|
||||
### 4.1 Минимально необходимые сущности в 1C
|
||||
|
||||
- Набор сущностей, без которых proof closure невозможен.
|
||||
- Что optional enrichment.
|
||||
|
||||
### 4.2 Критические relation links
|
||||
|
||||
- Минимальная цепочка source-to-proof связей.
|
||||
- Какие связи должны быть прямыми, какие допускаются косвенными.
|
||||
|
||||
## 5) Snapshot/Live coverage verdict
|
||||
|
||||
- Что покрывает snapshot-only.
|
||||
- Что требует live.
|
||||
- Итог: `snapshot_only_sufficient` / `snapshot_plus_live_required` / `live_primary_required`.
|
||||
|
||||
## 6) Answer/proof modes contract
|
||||
|
||||
### `grounded_positive`
|
||||
|
||||
- Условия допуска.
|
||||
- Что обязательно должно быть в ответе.
|
||||
- Короткий пример `grounded_positive`.
|
||||
|
||||
### `limited_or_insufficient_evidence`
|
||||
|
||||
- Условия, когда обязательно остаемся в limited mode.
|
||||
- Что обязательно должно быть явно обозначено (missing link/ограничение).
|
||||
- Короткий пример `limited`.
|
||||
|
||||
### Запрещенные паттерны
|
||||
|
||||
- Какие формулировки считаются недопустимыми.
|
||||
- Короткий антипример запрещенного ответа.
|
||||
|
||||
## 7) Gap register (family)
|
||||
|
||||
Использовать таблицу:
|
||||
|
||||
| gap_id | category | severity | current_state | note |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| FAM-G1 | `...` | blocker/high/medium | open/partial/closed | ... |
|
||||
|
||||
Рекомендуемые категории:
|
||||
|
||||
- `missing_source_data`
|
||||
- `source_not_connected_to_runtime`
|
||||
- `wrong_route_selection`
|
||||
- `wrong_entity_mapping`
|
||||
- `wrong_live_call_target`
|
||||
- `evidence_not_materialized`
|
||||
- `admissibility_reject_not_due_to_data`
|
||||
- `answer_layer_underuses_available_evidence`
|
||||
|
||||
## 8) Code-path inventory (где живет контракт)
|
||||
|
||||
- Модули normalizer/router/claim-bound/evidence/admissibility/answer.
|
||||
- Ключевые файлы runtime.
|
||||
- Папка run-артефактов, на которую опирается статус family.
|
||||
|
||||
## 9) Regression set and acceptance policy
|
||||
|
||||
- Обязательные контрольные вопросы для этой family.
|
||||
- Набор формулировочных вариаций.
|
||||
- Правило: после каждого family pack обязателен run folder в `llm_normalizer/docs/runs`.
|
||||
- Правило: приемка фиксируется на уровне family, не на уровне одного удачного ответа.
|
||||
- Правило: `false_grounded_answer_rate` должен оставаться нулевым.
|
||||
|
||||
## 10) Project decision line (для этой family)
|
||||
|
||||
- Одна короткая строка в проектном стиле:
|
||||
- текущий статус family;
|
||||
- главный незакрытый узел;
|
||||
- что является условием перехода в fully accepted.
|
||||
+70
@@ -0,0 +1,70 @@
|
||||
# STAGE_04_DECISION_NOTE_FAMILY_BASED_EXECUTION
|
||||
|
||||
Дата: `2026-03-29`
|
||||
Статус: `DECISION_APPROVED`
|
||||
Область: `Stage 4 (P0-only)`
|
||||
|
||||
## Почему принято решение
|
||||
|
||||
Stage 4 дошел до состояния, где вопрос-by-вопрос режим уже неуправляем:
|
||||
|
||||
- повторяются однотипные доменные поломки;
|
||||
- стоимость точечной отладки растет;
|
||||
- приемка становится хрупкой.
|
||||
|
||||
## Что меняется официально
|
||||
|
||||
- единица анализа: `question family`;
|
||||
- единица реализации: `family pack`;
|
||||
- единица приемки: `family acceptance`.
|
||||
|
||||
## Что не меняется
|
||||
|
||||
- Stage 4 остается Stage 4;
|
||||
- границы `P0-only` сохраняются;
|
||||
- без новых доменов и без Stage 5 как core path.
|
||||
|
||||
## Активные family в проекте
|
||||
|
||||
1. VAT chain
|
||||
- Card: [Stage 4 - Family Card v1 — VAT chain.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 — VAT chain.md)
|
||||
|
||||
2. RBP tail
|
||||
- Card: [Stage 4 - Family Card v1 RBP.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 RBP.md)
|
||||
|
||||
3. FA amortization coverage
|
||||
- Card: [Stage 4 - Family Card v1 FA.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 FA.md)
|
||||
|
||||
Общий реестр и run-навигация:
|
||||
[STAGE_04_FAMILY_BACKLOG_2026-03-29.md](X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\03_execution\STAGE_04_FAMILY_BACKLOG_2026-03-29.md)
|
||||
|
||||
## Контрольные lane (не first-class family)
|
||||
|
||||
В Stage 4 используются контрольные lane для route/purity regression, но они не переводятся в активные family автоматически:
|
||||
|
||||
- `settlements_60_62` (control lane)
|
||||
- `month_close_indirect_costs` (control/sanity lane)
|
||||
|
||||
Назначение control lanes:
|
||||
|
||||
- проверка family isolation и wrong-route leakage;
|
||||
- проверка domain purity и live recipe binding на смежных формулировках;
|
||||
- защита от регрессий между core families.
|
||||
|
||||
## Правило внедрения (управление vs исполнение)
|
||||
|
||||
- Внедрение в проектный контур: **сразу все 3 family**.
|
||||
- Исполнение технических паков: **по одной family за раз**, с обязательным регрессом на остальные 2.
|
||||
- Контрольные lane обязательны в regression-наборе, но не считаются отдельной единицей family acceptance.
|
||||
|
||||
Это дает:
|
||||
|
||||
- единый язык управления Stage 4;
|
||||
- устойчивый технический темп без расползания контекста;
|
||||
- быструю локализацию регрессий.
|
||||
|
||||
## Официальная формулировка
|
||||
|
||||
`Stage 4 officially transitions from question-by-question debugging to family-based execution over source-to-proof contracts for P0 accounting domains.`
|
||||
|
||||
`Этап 4 официально переводится из режима точечной отладки отдельных вопросов в режим поочередного закрытия семейств бухгалтерских вопросов через source-to-proof контракты.`
|
||||
+105
@@ -0,0 +1,105 @@
|
||||
# STAGE_04_FAMILY_BACKLOG_2026-03-29
|
||||
|
||||
Статус: `WORKING_BACKLOG`
|
||||
Режим: `Stage 4 (P0-only)`
|
||||
Единица исполнения: `family pack`
|
||||
|
||||
## Контур
|
||||
|
||||
Этот backlog фиксирует Stage 4 не по отдельным вопросам, а по семействам с source-to-proof контрактом.
|
||||
|
||||
В этом backlog:
|
||||
|
||||
- `core families` = VAT / RBP / FA;
|
||||
- `control lanes` = settlements_60_62 / month_close_indirect_costs (только для regression/sanity, не как отдельные family acceptance).
|
||||
|
||||
## Навигация
|
||||
|
||||
- Family registry: [STAGE_04_FAMILY_REGISTRY_2026-03-29.json](X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\03_execution\STAGE_04_FAMILY_REGISTRY_2026-03-29.json)
|
||||
- VAT family card: [Stage 4 - Family Card v1 — VAT chain.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 — VAT chain.md)
|
||||
- VAT latest run: [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\run_summary.json)
|
||||
- RBP family card: [Stage 4 - Family Card v1 RBP.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 RBP.md)
|
||||
- RBP latest run: [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix\run_summary.json)
|
||||
- FA family card: [Stage 4 - Family Card v1 FA.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 FA.md)
|
||||
- FA latest acceptance run: [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure\run_summary.json)
|
||||
- FA latest live replay: [fa_live_raw.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure_live_attempt\fa_live_raw.json)
|
||||
|
||||
## Control lanes (regression only)
|
||||
|
||||
1. `settlements_60_62`
|
||||
- Назначение: ловить wrong-claim leakage (settlement -> VAT/FA) и polarity regression.
|
||||
- Статус в Stage 4: `CONTROL_LANE_ONLY`.
|
||||
|
||||
2. `month_close_indirect_costs`
|
||||
- Назначение: sanity-check для period-close вопросов и cross-family contamination.
|
||||
- Статус в Stage 4: `CONTROL_LANE_ONLY`.
|
||||
|
||||
## Family 1 - НДС-цепочка (VAT chain)
|
||||
|
||||
- `current_status`: `PARTIALLY_WORKING / NON-BLOCKER`
|
||||
- `primary_gap`: residual admissibility/materialization quality (account scope mismatch, weak mapping noise)
|
||||
- `latest_pack`: `2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt`
|
||||
- `next_pack`: targeted live narrowing + reject cleanup для VAT proof-path
|
||||
- `acceptance_target`: устойчивый grounded-positive на VAT-вариациях при `false_grounded = 0`
|
||||
- `family_card`: [Stage 4 - Family Card v1 — VAT chain.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 — VAT chain.md)
|
||||
- `latest_acceptance_run`: [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\run_summary.json)
|
||||
- `latest_live_replay`: [1_live_replay.txt](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\1_live_replay.txt)
|
||||
|
||||
Что уже работает:
|
||||
- positive path по VAT подтвержден в replay.
|
||||
- temporal/company-scope для live-кейсов стабилизирован в рамках Wave 19.2.
|
||||
|
||||
Что дочищаем:
|
||||
- снижение inadmissible residual noise;
|
||||
- повышение стабильности admissibility на смежных формулировках.
|
||||
|
||||
## Family 2 - РБП (RBP tail / write-off overstay)
|
||||
|
||||
- `current_status`: `ACCEPTED_WITH_LIMITATIONS`
|
||||
- `primary_gap`: source coverage (данные/источники для полного object-level proof)
|
||||
- `latest_pack`: `2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix`
|
||||
- `next_pack`: source coverage recovery + route tightening для полного claim closure
|
||||
- `acceptance_target`: non-zero admissible evidence + mechanism-specific вывод на core RBP вариациях
|
||||
- `family_card`: [Stage 4 - Family Card v1 RBP.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 RBP.md)
|
||||
- `latest_acceptance_run`: [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix\run_summary.json)
|
||||
- `latest_live_replay`: [1.txt](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix\1.txt)
|
||||
|
||||
Что уже работает:
|
||||
- live route и evidence materialization подняты (`FIXED`).
|
||||
|
||||
Что не закрыто:
|
||||
- source coverage остается `NOT_FIXED`, поэтому часть кейсов ограничивается честно, но без полного proof closure.
|
||||
|
||||
## Family 3 - Амортизация ОС (FA amortization coverage)
|
||||
|
||||
- `current_status`: `PROOF_PATH_RAISED, LIVE_ACCEPTANCE_PENDING`
|
||||
- `primary_gap`: object-level relation clarity в live + production live acceptance
|
||||
- `latest_pack`: `2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure`
|
||||
- `next_pack`: live replay acceptance + relation/anchor consistency на вариациях
|
||||
- `acceptance_target`: доказуемая полнота/неполнота охвата ОС с явным expected vs actual set и `false_grounded = 0`
|
||||
- `family_card`: [Stage 4 - Family Card v1 FA.md](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 FA.md)
|
||||
- `latest_acceptance_run`: [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure\run_summary.json)
|
||||
- `latest_live_replay`: [fa_live_raw.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure_live_attempt\fa_live_raw.json)
|
||||
|
||||
Что уже работает:
|
||||
- claim-bound FA path, targeted checks, expected/actual set и relation-map вынесены в артефакты.
|
||||
- локальный pack достиг `FA_PACK_ACCEPTED` в controlled mock replay.
|
||||
|
||||
Что остается:
|
||||
- формальная live приемка family pack в рабочем канале (текущий live attempt: `http_status=400`).
|
||||
|
||||
## Сводная таблица family-level исполнения
|
||||
|
||||
| Family | Current status | Family card | Latest acceptance run | Latest live replay | Primary gap | Next pack focus |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| VAT chain | partially working | [VAT card](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 — VAT chain.md) | [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\run_summary.json) | [1_live_replay.txt](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\1_live_replay.txt) | admissibility residual noise | live narrowing + reject cleanup |
|
||||
| RBP tail | accepted with limitations | [RBP card](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 RBP.md) | [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix\run_summary.json) | [1.txt](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix\1.txt) | source coverage | source recovery + route tightening |
|
||||
| FA amortization | proof path raised, live pending | [FA card](X:\1C\NDC_1C\IN\Stage 4 - Family Card v1 FA.md) | [run_summary.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure\run_summary.json) | [fa_live_raw.json](X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure_live_attempt\fa_live_raw.json) | live object-level closure | live replay acceptance + relation consistency |
|
||||
|
||||
## Правило исполнения (обязательно)
|
||||
|
||||
1. Новые задачи Stage 4 заводятся как family packs, не как одиночные вопросы.
|
||||
2. После каждого прогона обязательны run-артефакты в `llm_normalizer/docs/runs`.
|
||||
3. Приемка фиксируется на уровне family acceptance, а не по одному удачному ответу.
|
||||
4. Для каждой family в backlog обязательно должны быть заполнены: `family_card`, `latest_acceptance_run`, `latest_live_replay`.
|
||||
5. Control lanes обязательны в regression-наборе каждого pack, но не повышаются в first-class family без отдельного проектного решения.
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
{
|
||||
"schema_version": "stage4_family_registry_v1",
|
||||
"updated_at": "2026-03-29",
|
||||
"stage_scope": "Stage 4 (P0-only)",
|
||||
"execution_unit": "family_pack",
|
||||
"acceptance_unit": "family_acceptance",
|
||||
"families": [
|
||||
{
|
||||
"family_id": "VAT_CHAIN_COMPLETENESS_V1",
|
||||
"family_name": "VAT chain",
|
||||
"status": "PARTIALLY_WORKING_NON_BLOCKER",
|
||||
"family_card": "X:/1C/NDC_1C/IN/Stage 4 - Family Card v1 — VAT chain.md",
|
||||
"latest_pack": "2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt",
|
||||
"latest_acceptance_run": "X:/1C/NDC_1C/llm_normalizer/docs/runs/2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt/run_summary.json",
|
||||
"latest_live_replay": "X:/1C/NDC_1C/llm_normalizer/docs/runs/2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt/1_live_replay.txt",
|
||||
"primary_gap": "residual_admissibility_materialization_quality"
|
||||
},
|
||||
{
|
||||
"family_id": "RBP_TAIL_WRITEOFF_OVERSTAY_V1",
|
||||
"family_name": "RBP tail",
|
||||
"status": "ACCEPTED_WITH_LIMITATIONS",
|
||||
"family_card": "X:/1C/NDC_1C/IN/Stage 4 - Family Card v1 RBP.md",
|
||||
"latest_pack": "2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix",
|
||||
"latest_acceptance_run": "X:/1C/NDC_1C/llm_normalizer/docs/runs/2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix/run_summary.json",
|
||||
"latest_live_replay": "X:/1C/NDC_1C/llm_normalizer/docs/runs/2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix/1.txt",
|
||||
"primary_gap": "source_coverage"
|
||||
},
|
||||
{
|
||||
"family_id": "FA_AMORTIZATION_COVERAGE_V1",
|
||||
"family_name": "FA amortization coverage",
|
||||
"status": "PROOF_PATH_RAISED_LIVE_ACCEPTANCE_PENDING",
|
||||
"family_card": "X:/1C/NDC_1C/IN/Stage 4 - Family Card v1 FA.md",
|
||||
"latest_pack": "2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure",
|
||||
"latest_acceptance_run": "X:/1C/NDC_1C/llm_normalizer/docs/runs/2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure/run_summary.json",
|
||||
"latest_live_replay": "X:/1C/NDC_1C/llm_normalizer/docs/runs/2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure_live_attempt/fa_live_raw.json",
|
||||
"primary_gap": "live_object_level_relation_clarity_and_live_acceptance"
|
||||
}
|
||||
],
|
||||
"rollout_policy": {
|
||||
"project_adoption": "all_three_families_immediately",
|
||||
"technical_execution": "one_family_per_pack_with_full_cross_family_regression",
|
||||
"hard_rule": "false_grounded_answer_rate_must_remain_zero"
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user