SILVER
/
NODEDC_1C
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NODEDC_1C/docs/accounting-assistant/accounting-assistant/03_execution/FAMILY_CARD_TEMPLATE.md

6.0 KiB
Raw Blame History

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.