{"type":"transition_applied","payload":{"type":"transition_applied","status":"running","residency_state":"resident"}} {"type":"assistant_message","payload":{"text":"I read this as an advisory architecture review - I’ll trace the fixed-profile onboarding flow end to end, compare minimal deterministic designs, and return a decision-ready recommendation with contracts, migration impact, test seams, risks, and evidence paths without editing files."}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"steered","payload":{"delivered":"steer"}} {"type":"steered","payload":{"delivered":"steer"}} {"type":"assistant_message","payload":{"text":"## Decision\n\nThe `equation_sex_basis` patch is symptom-level and should be removed. Clarification eligibility must be computed from a deterministic assessment of the complete 22-field profile. The provider must not supply, add, remove, prioritize, or resolve clarification questions.\n\nRecommended architecture: one pure field-policy module plus the existing reconciliation persistence module. No generic rules engine, plugin system, event bus, or provider reconciliation layer is warranted.\n\n## Current architecture and defect\n\n### Call graph\n\n```text\nexternal customer adapter (not present in this source tree)\n -> NutritionOnboardingService.start_or_resume()\n -> submit_answer() x22\n -> transient/workflow.json\n -> reconciliation_answers()\n -> external model/provider (caller absent from this tree)\n -> record_reconciliation(advisory, clarifications)\n -> _normalized_reconciliation_inputs()\n -> build_reconciliation()\n -> transient/workflow.json[\"reconciliation\"]\n -> revise_reconciliation_answer()\n -> advance_reconciliation()\n -> attest_baseline()\n -> build_onboarding_baseline()\n -> baseline-candidate.json\n -> safety_hold or owner_review\n -> owner/clinical review\n -> finalize()\n -> restriction KB reconciliation\n -> deterministic calculation\n -> readiness artifacts and registry projection\n```\n\n`NutritionOnboardingStore.deliver()` also accepts a `provider`, but that is publication delivery and is unrelated to LLM reconciliation.\n\n### Root defects\n\n- `record_reconciliation()` trusts caller-provided clarification eligibility for every field. `PersistedClarification` validates only shape, field membership, kind, and Korean text.\n- `_normalized_reconciliation_inputs()` filters only `equation_sex_basis`, based on an exact-phrase alias table. All other valid fields remain vulnerable to fabricated provider questions.\n- `revise_reconciliation_answer()` validates only `equation_sex_basis`. Invalid revisions for the other 21 fields advance the cursor and can make reconciliation appear resolved.\n- The maximum of three is rejection, not deterministic capping. Provider output of four questions fails the operation.\n- Provider order becomes customer question order.\n- A resolved record is not re-evaluated after each revision. Questions beyond the original provider list can never surface.\n- Safety is evaluated after attestation, separately from reconciliation. Unknown restriction terms can pass owner review and fail only during finalization.\n- `enforce_reconciliation=False` is the service default, but finalization always requires an input reconciliation digest.\n- `advisory` is an unconstrained dictionary included in the authoritative digest. Equivalent answers can produce different readiness identities because provider prose changed.\n- The `RECONCILING` state exists but is unused.\n- There is no production provider caller in this source tree; only the service boundary and tests are visible.\n\n## The 22-field contract\n\nLegend:\n\n- **V**: deterministically valid and canonical.\n- **A**: malformed, unsupported, or incomplete; deterministic clarification eligible.\n- **C**: deterministic cross-field contradiction; clarification eligible.\n- **S**: safety or human review required; never by itself clarification eligible.\n- **B**: terminal/business block; do not pressure the customer with a clarification.\n\nAll 22 keys are mandatory in `QUESTION_FIELDS`; some values are conditionally nullable.\n\n| # | Field | Current parser/canonicalization | Deterministic disposition |\n|---|---|---|---|\n| 1 | `date_of_birth` | Must be a string; `date.fromisoformat`; derives age at `date.today()`; age 18-120; DOB omitted from canonical baseline. | V: ISO date and adult. A: malformed or implausible date. B: explicit under-18 result (`customer_not_adult`), not an invitation to change DOB. |\n| 2 | `equation_sex_basis` | Exact NFC/whitespace/casefold alias map to `male`, `female`, `decline`. Includes canonical English, Korean forms such as `남성`, `여성입니다`, `선택 안 합니다`, and bounded confirmation phrases. Substrings are rejected. | V: one canonical enum. A: unsupported or multiple-choice prose. B: `decline`, because the only approved calculation currently throws `CalculationDeclinedError`; it must not trigger a coercive re-question. |\n| 3 | `height_cm` | Pydantic `Decimal`, 120-250; serialized as canonical decimal string. No submit-time parser. | V: numeric in range. A: nonnumeric, unit-bearing unsupported text, or out of range. |\n| 4 | `weight_kg` | `Decimal`, 35-300; canonical decimal serialization. | V/A as above. Used in target-direction and trajectory rules. |\n| 5 | `activity_category` | Exact enum: `sedentary`, `light`, `moderate`, `very_active`, `extra_active`. | V: enum. A: anything else. |\n| 6 | `activity_rationale` | String or `None`; NFC and whitespace normalization; `None -> \"\"`; maximum 500 characters. | V: normalized text, including blank under the current contract. A: nontext or too long. No semantic C rule is possible from the current free-text contract. |\n| 7 | `goal_type` | Exact enum: `loss`, `maintain`, `gain`. | V/A. Drives target rules. |\n| 8 | `target_weight_kg` | Nullable `Decimal`, 35-300. | V: null for maintain, numeric for loss/gain. A: malformed/range. C: forbidden for maintain, required for loss/gain, or wrong direction relative to `weight_kg`. |\n| 9 | `target_date` | Nullable Pydantic date. Current model checks only goal/null consistency; calculation later checks date against `starts_on`. | V/A. C: forbidden for maintain, required for loss/gain, not after start, or creates unsafe trajectory. |\n| 10 | `allergies` | `StructuredItems`: exact `none`/`provided`, sequence of strings, NFC/trim, casefold dedupe preserving order, 1-200 chars each, max 40, status/items consistency. | V/A. Recognized terms become exclusions. S: KB-unresolved term requires human review; it is not a clarification about medical details. |\n| 11 | `intolerances` | Same structured parser. | V/A. Recognized terms follow the approved KB action; unresolved terms are S. |\n| 12 | `religious_ethical_exclusions` | Same structured parser. | V/A. Enforced as declared constraints. Under the current source KB, no corresponding source-template terms exist, so provided terms become unresolved and S during finalization. |\n| 13 | `disliked_foods` | Same structured parser. | V/A. No current safety or cross-field validator. Safety exclusions should dominate dislikes without another question. |\n| 14 | `dietary_preferences` | Same structured parser. | V/A. No current deterministic contradiction validator. Restrictions should dominate preferences; semantic provider suspicions remain advisory-only. |\n| 15 | `conditions` | Same structured parser. | V: explicit none or provided list. A: malformed structure. S: any provided condition; current KB wildcard requires human review. Do not request more clinical detail. |\n| 16 | `medications` | Same structured parser. | V/A. S: any provided medication; current KB wildcard requires human review. |\n| 17 | `pregnancy_breastfeeding` | `bool | None`; no custom strict parser. `False` is the only value avoiding current safety hold. | V: explicit false. A: malformed value. S: true or null/declined. No cross-rule with equation basis or identity. |\n| 18 | `eating_disorder_risk` | `bool | None`; no custom parser. Omitted from finalized baseline but used to force safety hold. | V: false. A: malformed. S: true or null/declined. Never ask for diagnosis or details. |\n| 19 | `cooking_access` | String/`None`, NFC/whitespace normalization, `None -> \"\"`, max 500. | V: normalized text, including blank under current schema. A: wrong type or too long. |\n| 20 | `budget_band` | Same free-text parser. | V/A. Blank is currently schema-valid even though downstream adaptive registration expects nonblank input. That mismatch needs an explicit business decision, not an LLM judgment. |\n| 21 | `meal_count` | Pydantic integer, 2-6, default 3. | V: integer in range. A: malformed or out of range. |\n| 22 | `schedule_constraints` | String/`None`, normalized, max 500. | V/A. Blank is currently valid. Semantic interpretation is advisory-only. |\n\nThe model is not configured with Pydantic strict mode. Apart from DOB and equation basis, coercion is delegated to Pydantic at attestation. A deterministic clarification contract should explicitly define accepted wire forms rather than inheriting dependency-level coercion behavior.\n\n## Source-backed cross-field rules\n\nOnly deterministic, contract-backed contradictions should generate questions:\n\n1. `goal_type=maintain` requires both target fields to be null.\n2. `goal_type in {loss,gain}` requires both target fields.\n3. Loss requires `target_weight_kg < weight_kg`.\n4. Gain requires `target_weight_kg > weight_kg`.\n5. `target_date` must be after the bound planned start date.\n6. Loss must not exceed 1% body weight per week.\n7. Gain must not exceed 0.5% body weight per week.\n8. The resulting calculation must stay within the approved 1500-4500 kcal range.\n9. `equation_sex_basis=decline` is an explicit unsupported-calculation block, not ambiguity.\n10. Restriction and medical fields are reconciled against the approved KB; unknown or human-only terms produce safety routing, not further medical questioning.\n\nExplicitly excluded:\n\n- No contradiction between equation basis and pregnancy.\n- No inference of sex, gender, pregnancy, disease, medication effects, or eating-disorder status from another answer.\n- No LLM-derived contradiction between activity category and free-text rationale.\n- No semantic contradiction from cooking, budget, schedule, dislikes, or preferences unless the schema is later made structured.\n- Restriction values override preferences in planning; overlap does not require the customer to restate a safety disclosure.\n\nExact trajectory evaluation currently depends on `starts_on`, which is supplied only at finalization. The assessment therefore needs a trusted `planned_starts_on` in session context and must bind finalization to that same value. Using `date.today()` or an approximate reference date would leave a deterministic late-failure gap.\n\n## Recommended architecture: deterministic post-collection compiler\n\n### Module ownership\n\nA single pure module, conceptually `nutrition_onboarding_input_policy.py`, owns:\n\n- All 22 field specifications.\n- Accepted wire forms and canonicalizers.\n- Field-local reason codes.\n- Cross-field rules.\n- Safety and business-block classification.\n- Fixed Korean question templates.\n- Deterministic priority and dedupe.\n- A versioned policy manifest and digest.\n\nExisting modules retain their responsibilities:\n\n- `nutrition_onboarding_models.py`: canonical value models and final invariants.\n- `nutrition_restriction_kb.py`: restriction term resolution.\n- `nutrition_onboarding_calculations.py`: approved calculation and trajectory limits.\n- `nutrition_onboarding_reconciliation.py`: persisted decision schema, digest validation, and cap.\n- `nutrition_onboarding.py`: authority, locking, orchestration, revisions, and state transitions.\n\nDo not create a generic rule DSL. A tuple of 22 immutable `FieldSpec` values and a short list of explicit cross rules is sufficient.\n\n### Assessment contract\n\nField state should be orthogonal rather than a single enum:\n\n```text\nFieldAssessment\n field\n parse_state: valid | ambiguous\n canonical_value\n reason_codes\n conflict_codes\n safety_codes\n blocking_codes\n```\n\nQuestion eligibility is exactly:\n\n```text\neligible =\n parse_state == ambiguous\n or conflict_codes is not empty\n```\n\nIt is never affected by:\n\n- Model output.\n- Safety-only flags.\n- Owner-review suggestions.\n- Confidence scores.\n- Provider availability.\n\nA profile assessment contains:\n\n```text\npolicy_version\npolicy_digest\nreference_date\nplanned_starts_on\nsource_answers_digest\ncanonical_answers_digest | null\nfield_assessments[22]\nclarifications[0..3]\noutstanding_clarification_count\nsafety_reason_codes\nblocking_reason_codes\nstate: clarifying | resolved | blocked\ndigest\n```\n\n### Service behavior\n\n- `submit_answer()` uses the registry parser for every field. Uniquely canonical values are stored canonically; ambiguous raw values remain transient for correction.\n- A service-owned `reconcile_inputs()` reads answers under the store lock and computes the decision. It does not accept clarification input.\n- `revise_reconciliation_answer()` validates the selected field through the same registry, updates it under lock, and re-runs the complete assessment.\n- It must not call `advance_reconciliation()` blindly.\n- `attest_baseline()` requires a resolved record matching the current source/canonical answer digests, policy digest, dates, and KB digest.\n- Safety codes then route to `SAFETY_HOLD`; they do not make reconciliation unresolved.\n- Blocking codes prevent attestation without manufacturing questions.\n- Reconciliation enforcement becomes mandatory; the feature flag should not allow a digestless candidate.\n\n### Reason codes\n\nGeneric field-local codes, combined with `field`, avoid 22 duplicated enums:\n\n- `missing_required`\n- `invalid_type`\n- `invalid_format`\n- `unsupported_value`\n- `out_of_range`\n- `text_too_long`\n- `item_text_invalid`\n- `too_many_items`\n- `status_items_mismatch`\n\nCross-field codes:\n\n- `target_forbidden_for_maintenance`\n- `target_required_for_goal`\n- `target_direction_conflict`\n- `target_date_not_after_start`\n- `goal_trajectory_unsafe`\n- `calorie_projection_out_of_bounds`\n\nSafety and restriction codes:\n\n- `allergy_exclusion_required`\n- `intolerance_exclusion_required`\n- `religious_ethical_exclusion_required`\n- `restriction_term_unresolved`\n- `condition_requires_clinical_review`\n- `medication_requires_clinical_review`\n- `pregnancy_breastfeeding_requires_clinical_review`\n- `eating_disorder_risk_requires_clinical_review`\n\nBlocking/system codes:\n\n- `customer_not_adult`\n- `calculation_basis_declined`\n- `reconciliation_policy_unavailable`\n- `restriction_kb_unavailable`\n\nOnly field-local and cross-field codes produce questions.\n\n### Dedupe, cap, and order\n\n- Evaluate all fields in exact `QUESTION_FIELDS` order.\n- Field-local parse failures suppress cross-rules involving that field until it is parseable.\n- Deduplicate by field: at most one active question per field.\n- Within a field, precedence is missing, type/format, unsupported/range, then contradiction.\n- Sort by `QUESTION_FIELDS`; never use provider order.\n- Cap at three active questions per assessment wave.\n- Persist `outstanding_clarification_count`, including questions beyond the visible cap.\n- Re-run the whole assessment after every answer. The next deterministic issue then enters the first-three window.\n- Reconciliation is resolved only when the total outstanding count is zero.\n- Safety flags do not consume the cap.\n- A terminal block suppresses further questions.\n\nThis fixes the current false-resolution failure when more than three independent defects exist.\n\n### Model boundary\n\nThe simplest safe boundary is no model in the clarification path.\n\nAn optional advisory summary may be generated after deterministic assessment, but:\n\n- It receives only an allowlisted projection such as canonical goal/activity codes, non-sensitive counts, and reason codes.\n- It does not receive raw DOB, condition names, medication names, pregnancy status, eating-disorder status, or unsupported raw answers.\n- It cannot return clarification fields or questions.\n- Its output is ephemeral presentation data.\n- It is not persisted in the authoritative reconciliation record.\n- It is not included in `input_reconciliation_digest`.\n- Timeout, malformed output, or provider unavailability cannot change state or question order.\n\nFixed Korean templates should produce clarification wording. This also removes provider prose from authoritative digests.\n\n## Persistence and digest semantics\n\n### Current behavior\n\n- `workflow.json` stores raw answers, arbitrary advisory output, questions, cursor, and reconciliation digest.\n- The v1 digest covers provider advisory and question wording.\n- `baseline-candidate.json[\"digest\"]` covers only the baseline payload, not its `input_reconciliation_digest` or `source_answers`.\n- Finalization checks the reconciliation digest only as a 64-character lowercase hash and propagates it.\n- The original reconciliation record disappears with the transient workflow, so readiness cannot independently validate what the opaque digest represented.\n- `baseline-candidate.json` retains `source_answers`, including DOB and medical answers, after successful finalization.\n\n### Required v2 semantics\n\n- `source_answers_digest`: current exact transient answer map, used for revision CAS.\n- `canonical_answers_digest`: present only when all fields parse; covers exactly the canonical 22-field map.\n- `policy_digest`: canonical JSON digest of the explicit policy manifest, KB digest, calculation method/version, templates, field order, `reference_date`, and `planned_starts_on`.\n- `decision_digest`: canonical digest of deterministic assessment data only; no provider content.\n- `input_reconciliation_digest`: the resolved `decision_digest`.\n- Candidate envelope must bind the baseline digest, canonical answers digest, reconciliation digest, and policy digest. The current unbound top-level wrapper is insufficient.\n- Preserve a compact permanent `input-reconciliation-v2.json` containing no raw answers, so readiness can validate the propagated digest after transient deletion.\n- Finalization must verify the permanent decision artifact rather than accepting a syntactically valid hash.\n- Identical canonical inputs, context, KB, and policy produce the same digest.\n- A rule/KB/start-date change intentionally changes the digest and requires reassessment.\n- On successful READY transition, delete the transient workflow and `baseline-candidate.json`; permanent artifacts already contain the approved minimum.\n\n## Privacy constraints\n\nExisting strengths:\n\n- Exact customer/owner route checks.\n- Current consent and disabled-customer checks.\n- Redacted status objects.\n- Owner-only directories and files, symlink rejection, hard-link rejection, atomic private writes.\n- DOB excluded from the canonical baseline.\n- Eating-disorder risk excluded from the finalized baseline.\n\nRequired corrections:\n\n- Do not expose the complete `reconciliation_answers()` dictionary to an advisory provider.\n- Never echo condition, medication, pregnancy, eating-disorder, or DOB values into question text.\n- Do not infer sensitive attributes across fields.\n- Treat `decline` and null safety answers as explicit privacy choices: route safely, do not repeatedly solicit details.\n- Remove arbitrary persisted provider advisory content.\n- Purge `baseline-candidate.json` after finalization; it currently defeats DOB minimization.\n- Keep reason codes non-diagnostic and bounded.\n- Treat answer digests as sensitive local metadata; low-entropy fields make unsalted hashes guessable.\n\n## Alternative design: strict validation at each question\n\nEvery adapter submits only canonical structured values. `submit_answer()` rejects invalid input immediately and returns a fixed correction for that field. Only cross-field and safety assessment remains after field 22.\n\nTrade-offs:\n\n- **Coupling:** tightly couples external chat/UI adapters to canonical wire forms and response handling.\n- **Testability:** excellent; ambiguity never enters persistence.\n- **Migration cost:** higher because every customer-facing adapter must change concurrently, and no such adapter exists in this source tree.\n- **Failure mode:** natural-language chat answers are rejected more often unless each field gains deterministic compatibility aliases.\n- **Benefit:** smallest persisted reconciliation state and no multi-wave parser errors.\n- **Limitation:** target and safety cross-rules still require the complete profile and planned start date.\n\nThis is preferable for a controlled form UI, but the post-collection compiler is the smaller migration for the current service API.\n\n## Migration impact\n\n- Keep `QUESTION_FIELDS` order unchanged.\n- Replace the equation-specific helper and filtering path with the 22-field registry.\n- Introduce `nutrition_input_reconciliation_v2`; do not reinterpret v1 digests.\n- Existing READY artifacts remain immutable and grandfathered.\n- Existing owner-approved/finalizing candidates may finish under v1 only if their current checks pass; they should not be silently recomputed.\n- Incomplete v1 transient sessions should be deterministically reassessed into v2 before further clarification. Partially answered provider question cursors cannot be safely translated without re-evaluation.\n- Remove caller ownership of `clarifications`; this is an API break and warrants a version bump.\n- The external provider caller is not in this repository, so its migration surface cannot be enumerated from this source.\n- Bind `planned_starts_on` earlier in the session or retain deterministic late owner revision. Exact current trajectory semantics cannot be moved earlier without that context.\n- Readiness validation needs a versioned branch for the new permanent reconciliation artifact.\n- `enforce_reconciliation` should cease being optional for new sessions.\n\n## Exact test seams\n\n### Pure field-policy tests\n\n- Registry contains exactly the 22 `QUESTION_FIELDS` in the same order.\n- One valid, one malformed, and every closed boundary for each field.\n- Canonicalization is idempotent.\n- All exact equation aliases remain compatibility-tested; substring and mixed-option text remain ambiguous.\n- Numeric parsers reject booleans and unsupported units.\n- Structured status/items consistency, NFC normalization, dedupe order, lengths, and count.\n- Free-text blank behavior is pinned explicitly rather than inherited accidentally from Pydantic.\n\n### Cross-rule tests\n\n- Maintain with either target populated.\n- Loss/gain with either target missing.\n- Loss target equal to or above current weight.\n- Gain target equal to or below current weight.\n- Target date equal to/before start.\n- Exact 1% loss and 0.5% gain boundaries accepted; one increment above rejected.\n- Calorie floor/ceiling failures map to deterministic reason codes.\n- Equation decline produces block and zero questions.\n- No equation/pregnancy cross-inference.\n- Free-text semantic disagreement never becomes a question.\n\n### Safety tests\n\n- Conditions and medications produce safety codes but no clarification when structurally valid.\n- Pregnancy/eating-disorder true and null produce safety codes, not detail requests.\n- Known restriction term follows KB action.\n- Unknown restriction term produces human-review safety code.\n- Missing/expired KB produces a system block, not a customer question.\n- Safety-only profile resolves reconciliation and then enters `SAFETY_HOLD`.\n\n### Ordering and persistence tests\n\n- Four or more invalid fields produce the first three in contract order and correct outstanding count.\n- Correcting the first issue re-evaluates and surfaces the fourth.\n- Multiple issues for one field yield one active question.\n- No state becomes resolved while outstanding count is nonzero.\n- Stale source-answer digest rejects revision.\n- Same inputs/context/policy produce identical decision digest.\n- Different model summaries do not change state, questions, or digest.\n- Tampered policy, question, safety code, context, or digest is rejected.\n- v1 transient reassessment and immutable READY compatibility are pinned.\n\n### Service integration tests\n\n- Every revision field, not only equation basis, is validated before persistence.\n- Complete valid profile reaches attestation with zero clarification even if a mock provider proposes all 22.\n- Provider timeout, exception, malformed output, or contradictory advice has no behavioral effect.\n- Attestation rejects a stale policy/KB/start-date decision.\n- Candidate envelope tampering with `input_reconciliation_digest` fails.\n- Final readiness validates the permanent reconciliation artifact.\n- Successful finalization removes transient answers and candidate source answers.\n\n### Privacy tests\n\n- Advisory projection excludes DOB and medical values.\n- Status and questions do not contain answer values.\n- Provider output is absent from authoritative private artifacts.\n- Final permanent reconciliation contains digests and policy metadata, not raw answers.\n- Existing 0700/0600, symlink, hard-link, and route-authority tests remain applicable.\n\n## Main risks\n\n1. **Start-date ownership:** exact trajectory eligibility cannot be decided until `planned_starts_on` is bound.\n2. **Wire compatibility:** current Pydantic coercion is broader and less explicit than a strict field registry; tightening it may expose adapter dependencies.\n3. **Decline semantics:** the schema permits equation-basis decline while the only calculation cannot proceed. Product policy must choose terminal no-plan or an approved alternate method.\n4. **Restriction inconsistency:** finalization reconciles the KB source template, while readiness runtime generation rewrites some actions. One authoritative KB projection must be selected.\n5. **Legacy evidence:** old readiness artifacts carry only an opaque reconciliation hash; their decision contents cannot be reconstructed.\n6. **External integration unknown:** no production LLM/provider adapter is present in this source, so caller migration must be located outside this tree.\n\n## Evidence paths\n\n- Field order and examples: `checkin_cli/nutrition_onboarding_contract.py::QUESTION_FIELDS`\n- Current aliases and schema parsing: `checkin_cli/nutrition_onboarding_models.py`\n- Equation-only patch and service call graph: `checkin_cli/nutrition_onboarding.py`\n- Provider-owned v1 clarification schema/cap/digest: `checkin_cli/nutrition_onboarding_reconciliation.py`\n- Current safety hold: `checkin_cli/nutrition_onboarding_authority.py::requires_safety_hold`\n- Goal direction/rate/calorie rules: `checkin_cli/nutrition_onboarding_calculations.py`\n- Restriction resolution and human-only categories: `checkin_cli/nutrition_restriction_kb.py`\n- Approved KB terms: `checkin_cli/policies/nutrition-restriction-kb-template-v1.json`\n- Candidate and readiness digest propagation: `checkin_cli/nutrition_onboarding_finalization.py`\n- Private persistence controls: `checkin_cli/nutrition_onboarding_fs.py`\n- Current symptom-level regression tests: `tests/test_nutrition_onboarding.py`\n- Parser contracts: `tests/test_nutrition_onboarding_models.py`\n- Calculation safety boundaries: `tests/test_nutrition_onboarding_calculations.py`"}} {"type":"assistant_message","payload":{"text":"I read this as a strengthened advisory review - I’ll extend the deterministic onboarding design into one exact automated golden-path rehearsal, trace the activation/check-in/approval/delivery/cleanup surfaces implicated by the red-team block, and define the minimum evidence bundle that must pass before the single final live run."}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"tool_execution","payload":{"tool":"read","is_error":false}} {"type":"tool_execution","payload":{"tool":"bash","is_error":false}} {"type":"assistant_message","payload":{"text":"I read this as architecture finalization - I’ll convert the red-team BLOCKs into one recommended design and a pass/fail rehearsal evidence gate.\n\n## Verdict: NO-GO / BLOCKED\n\nCandidate `573d19e...d5730d7` is not eligible for another live run:\n\n- Observer v7 writes a `SUBSCRIBED` declaration, then sleeps until timeout; it observes no lifecycle events.\n- Launch evidence terminates at `READY_CUSTOMER_CLAIM` after sending the invite.\n- Preview uses isolated in-memory state and cannot prove profile persistence.\n- Reconciliation publication can use the transient provider result instead of the committed filtered record.\n- `op_rev` binds to `QUESTION_FIELDS[0]`, not the clarification being revised.\n- Approval edits Telegram before the approved-card projection is safely persisted.\n- Cleanup v6 has `execution_permission: false`; its inherited cleanup/rollback paths can compete or reverse each other.\n\nAny correction changes the candidate digest, so all current dry-run receipts become predecessor evidence only.\n\n## Architecture decision\n\n### Recommended: one root lifecycle aggregate with immutable blobs and transactional outboxes\n\nCreate one private, candidate-bound lifecycle aggregate per rehearsal:\n\n```text\ndata/lifecycles//\n aggregate.json\n aggregate.lock\n blobs/sha256/\n```\n\n`aggregate.json` is the sole phase authority and contains:\n\n- Candidate, customer, session, actor and route bindings.\n- Monotonic aggregate revision.\n- Current phase.\n- Digests of immutable onboarding, reconciliation, baseline, check-in, draft, approval, delivery and cleanup blobs.\n- Pending external side-effect intents and their attempts/receipts.\n- Transition history and hash-chain head.\n- Holds and exact deterministic reason codes.\n\nEach transition follows:\n\n1. Write an immutable content-addressed blob.\n2. Lock and CAS the expected aggregate revision.\n3. Atomically reference the blob, change phase, and enqueue any side-effect intent.\n4. `fsync` file and directory.\n5. Notify observers after the commit.\n\nAn unreferenced blob is inert and collectible. Existing domain files become recoverable projections of the aggregate, not independent phase authorities.\n\n### Rejected alternative: patch the six individual paths\n\nLocally fixing publication, `op_rev`, projection recovery, observer and cleanup would be smaller, but would preserve independent ledgers and cross-file split-brain windows. It cannot strongly prove one revision-bound lifecycle from invite to cleanup.\n\n## Canonical lifecycle\n\n```text\nPREPARED\n-> OBSERVER_READY\n-> INVITE_INTENT\n-> INVITE_RECEIPTED | INVITE_UNKNOWN\n-> CUSTOMER_INGRESS_COMMITTED\n-> ONBOARDING_COLLECTING\n-> RECONCILIATION_COMMITTED\n-> CUSTOMER_ATTESTED\n-> OWNER_APPROVED\n-> READY\n-> ACTIVATION_INTENT\n-> ACTIVE\n-> CHECKIN_COMMITTED_AND_GENERATION_QUEUED\n-> GENERATING\n-> DRAFT_READY\n-> APPROVED_CARD_PENDING\n-> APPROVED_CARD_PROJECTED\n-> DELIVERY_CAPABILITY_ISSUED\n-> DELIVERY_ATTEMPTED\n-> DELIVERY_RECEIPTED | DELIVERY_UNKNOWN\n-> SENT_AUDITED\n-> CLEANUP_PREPARED\n-> ARCHIVED\n-> DISABLED\n-> QUIESCED\n-> CLEANUP_COMPLETE\n-> SEALED\n```\n\nUnknown invite or delivery outcomes prohibit blind retry.\n\n## Deterministic clarification compiler\n\nKeep the previously recommended 22-entry `FIELD_SPECS` registry. The compiler exclusively owns:\n\n- Parsing and canonicalization.\n- Field and cross-field validation.\n- Clarification eligibility and reason codes.\n- Dedupe, ordering and display cap.\n- Fixed Korean question templates.\n- Holds and state transitions.\n\nThe model may return advisory analysis, but its questions and prose are never persisted as mandatory clarifications or published.\n\nThe authoritative reconciliation v2 digest binds:\n\n```text\ncanonical answers\npolicy/schema digest\nrestriction-KB digest\nreference date\nplanned_starts_on\nall deterministic issues\nvisible issue IDs\nhold decisions\n```\n\nIt excludes provider prose and advisory output. `planned_starts_on` must be fixed before reconciliation and attestation.\n\nAfter every revised answer, recompute the complete issue set. The three-question cap limits presentation only; it never discards unresolved issues.\n\n## Exact 22-answer golden fixture\n\nFixed dates:\n\n- `reference_date`: `2026-08-18`\n- `planned_starts_on`: `2026-08-24`\n\n| Field | Exact customer answer | Canonical value |\n|---|---|---|\n| `date_of_birth` | `1990년 1월 15일입니다.` | `1990-01-15`, age 36 |\n| `equation_sex_basis` | `네, 남성입니다.` | `male` |\n| `height_cm` | `키는 180cm입니다.` | `\"180\"` |\n| `weight_kg` | `현재 체중은 80kg입니다.` | `\"80\"` |\n| `activity_category` | `보통 활동량입니다.` | `moderate` |\n| `activity_rationale` | `주 3회 60분 근력 운동을 하고 평일에는 하루 8천 보 정도 걷습니다.` | normalized text |\n| `goal_type` | `현재 체중을 유지하고 싶습니다.` | `maintain` |\n| `target_weight_kg` | `유지가 목표라 목표 체중은 정하지 않겠습니다.` | `null` |\n| `target_date` | `유지가 목표라 목표 날짜도 정하지 않겠습니다.` | `null` |\n| `allergies` | `음식 알레르기는 없습니다.` | `none, []` |\n| `intolerances` | `음식 불내증은 없습니다.` | `none, []` |\n| `religious_ethical_exclusions` | `종교적 또는 윤리적으로 제외하는 음식은 없습니다.` | `none, []` |\n| `disliked_foods` | `싫어해서 피하는 음식은 없습니다.` | `none, []` |\n| `dietary_preferences` | `특별한 식단 선호는 없습니다.` | `none, []` |\n| `conditions` | `진단받은 질환은 없습니다.` | `none, []` |\n| `medications` | `복용 중인 약이나 보충제는 없습니다.` | `none, []` |\n| `pregnancy_breastfeeding` | `임신 또는 수유에 해당하지 않습니다.` | `false` |\n| `eating_disorder_risk` | `섭식장애 위험이나 과거력은 없습니다.` | `false` |\n| `cooking_access` | `가스레인지, 전자레인지, 냉장고를 사용할 수 있고 기본 조리가 가능합니다.` | normalized text |\n| `budget_band` | `식비 예산은 보통입니다.` | `보통` |\n| `meal_count` | `하루 세 끼를 먹습니다.` | `3` |\n| `schedule_constraints` | `평일 점심은 12시, 저녁은 운동 후 8시쯤이며 그 외 제약은 없습니다.` | normalized text |\n\nExpected compiler result:\n\n```text\nclarification issues: 0\nvisible questions: 0\nsafety holds: 0\nhuman-review requirements: 0\n```\n\n## Six red-team corrections\n\n1. **Observer**\n - Install an actual inotify/application-event subscription before reading the initial aggregate revision.\n - Persist watcher identity, starting revision and cursor in readiness evidence.\n - Block on the event descriptor with a bounded deadline; no sleeps or polling.\n - Replay committed aggregate revisions to close notification races.\n\n2. **Launcher**\n - Invite receipt means only `INVITE_RECEIPTED`.\n - Golden-path PASS requires a Telegram update entering the production adapter and committing `CUSTOMER_INGRESS_COMMITTED`.\n - Preview or direct service calls cannot satisfy this transition.\n\n3. **Reconciliation publication**\n - Commit reconciliation and publication intent in one aggregate transition.\n - Publisher accepts only a reconciliation digest, reloads the committed blob, and renders that record.\n - The transient provider object is discarded after advisory storage.\n\n4. **Revision binding**\n - Bind revision operations to:\n `lifecycle_id + issue_id + exact field + answers_digest_before + reconciliation_digest`.\n - Remove every use of `QUESTION_FIELDS[0]`.\n - CAS the current issue and recompute the compiler after the revision.\n\n5. **Approved-card projection**\n - Approval atomically creates `APPROVED_CARD_PENDING`.\n - The projector edits the exact Telegram message.\n - Success or Telegram’s exact “not modified” response commits `APPROVED_CARD_PROJECTED`.\n - Edit failure remains recoverable pending/unknown; no capability can be issued.\n - Restart retries the same idempotent edit, never sends a replacement customer message.\n\n6. **Cleanup**\n - One lock, one monotonic cleanup journal and one controller.\n - Archive first; then freeze ingress, disable customer and delivery, reconcile outboxes, stop owned processes, seal, and prune only permitted transient data.\n - Failure resumes forward from its committed phase. It never re-enables the customer or restores delivery.\n - A concurrent cleanup returns the current phase or existing receipt.\n\nTo remove the current circular seal dependency:\n\n1. Observer produces pre-cleanup lifecycle and membership seals.\n2. Cleanup archives, disables and quiesces.\n3. Observer records `CLEANUP_COMPLETE` and produces final seals.\n4. Cleanup verifies immutable publication, prunes ephemeral state, and writes its terminal receipt.\n\n## One-pass automated rehearsal\n\nRun against the newly sealed installed wheels and an ephemeral profile. Use the production Telegram/runtime handlers and real profile persistence. Fake only external Telegram/provider I/O, preserving their receipt and unknown-outcome contracts.\n\nSequence:\n\n1. Subscribe observer and await its readiness event.\n2. Persist invite intent and fake Telegram invite receipt.\n3. Feed a serialized Start update through the actual adapter.\n4. Feed consent plus the exact 22 messages above through adapter ingress.\n5. Return adversarial provider advisory containing fabricated DOB and sex-basis questions.\n6. Assert committed reconciliation has zero issues and publication contains none of that text.\n7. Attest, owner-approve, finalize, and explicitly activate.\n8. Submit one complete daily nutrition check-in through the real wizard:\n `80 kg`, `2200 kcal`, `C220/P150/F80`, three meals, `2.5 L`, `7.5 h`, sleep/condition `4`, normal digestion, low stress, 60-minute strength session, no note.\n9. Prove check-in and unique generation job commit together.\n10. Generate one draft, approve it and project the approved card.\n11. Issue one capability, consume it before transport, record one delivery receipt, and reach `SENT_AUDITED`.\n12. Replay the send callback and prove transport count remains one.\n13. Execute cleanup to final immutable seals and verify no active residual state.\n\nTests subscribe to exact commit signals before triggering operations and await them with bounded timeouts. Fixed sleeps are forbidden.\n\n## Mandatory adversarial branches\n\nThe same test invocation must also prove:\n\n- Provider-invented questions never become authoritative or visible.\n- Ambiguous height such as `180 또는 185cm` produces only the schema-owned fixed issue.\n- Goal-direction conflict is deterministic.\n- Conditions, medication, pregnancy or eating-disorder risk produce a hold, not a sensitive clarification.\n- Stale answer/reconciliation digests mutate nothing.\n- A later-field revision records that exact field, never `date_of_birth`.\n- Crash after reconciliation commit recovers publication from the committed record.\n- Provider generation failure creates no draft.\n- Telegram card-edit failure blocks capability issuance and recovers after restart.\n- Unknown delivery consumes capability and prohibits another send.\n- Cleanup failure remains truthfully incomplete and resumes forward.\n- Two cleanup callers create one archive and one receipt.\n- Preview output cannot satisfy any acceptance transition.\n\n## Minimum evidence bundle\n\n1. **`candidate-seal.json`** \n New candidate digest, source/wheel/inventory/config/harness digests and installed-byte proof.\n\n2. **`fixture-manifest.private.json`** \n Exact 22 inputs, dates, canonical map and expected digests; mode `0600`. Public evidence exposes only its digest.\n\n3. **`observer-subscription.json`** \n Watcher identity, subscribed directory/source, start revision and readiness commit preceding invite intent.\n\n4. **`lifecycle-events.jsonl` plus final seal** \n Hash-chained actual revisions from invite through cleanup. Each row carries artifact and receipt digests but no raw health text.\n\n5. **`transport-receipts.json`** \n Invite receipt, card-edit receipt, capability issuance/consumption, exactly one customer delivery receipt and replay count.\n\n6. **`adversarial-matrix.json`** \n One independently verifiable result for every branch above, including before/after aggregate revisions.\n\n7. **`cleanup-receipt.json` and archive manifest** \n Exact retained, archived, deleted, still-present and not-delivered sets; disabled registry proof; empty pending jobs/outboxes; owned-process exit; final lifecycle and membership seals; immutable-retention publication digest.\n\n8. **`independent-verification.json`** \n Recomputes every digest and transition. It must reject declarations such as `PASS_DRY_RUN` unless backed by the corresponding committed artifact and receipt.\n\n## Final-live-run gate\n\nA final live request is permitted only when:\n\n- The complete automated rehearsal passes once.\n- Related tests, full build and independent verifier pass against the same candidate digest.\n- Cleanup finishes as `SEALED`, with no unexplained residue.\n- The evidence bundle proves zero provider-controlled clarification fields and exactly one delivery.\n\nNo live run should be requested now. No files, state, Telegram operations or tests were changed or executed during this architecture review."}} {"type":"transition_applied","payload":{"type":"transition_applied","status":"completed","residency_state":"resident"}} {"type":"reconcile_reattached","payload":{"session_path":"/home/cube/projects/richard/traning coach/.omo/senpi-task/children/st_01a01327/sessions/st_01a01327/2026-08-18T04-34-39-723Z_01a01326-69eb-7b3d-9620-e8b82c1691a2.jsonl"}} {"type":"reconcile_reattached","payload":{"session_path":"/home/cube/projects/richard/traning coach/.omo/senpi-task/children/st_01a01327/sessions/st_01a01327/2026-08-18T04-34-39-723Z_01a01326-69eb-7b3d-9620-e8b82c1691a2.jsonl"}} {"type":"transition_applied","payload":{"type":"transition_applied","status":"completed","residency_state":"evicted"}} {"type":"evicted","payload":{"cause":"evict"}}