# Architect Review Pass 2 — Dual-coach model rerun

Reviewed revision: `/home/cube/projects/richard/traning coach/.gjc/_session-019fabef-8dbb-7000-aec7-3d99dcdecc96/plans/ralplan/dual-coach-model-rerun/stage-02-revision.md`

Revision SHA-256: `63f00dad909cba9f25e1094fa2d204a7b8407e42d59374dda080d9c2896a7be4`

Prior same-lane review: `/home/cube/projects/richard/traning coach/.gjc/_session-019fabeb-7cfa-7000-a3e0-726dfe999666/plans/ralplan/dual-coach-model-rerun/stage-01-architect.md` (`fc2d8f3161f5d9b0b1f776bb2a060afd2a7cac2d595da59a4ed3a6a7f7193036`)

## Summary
Pass-2 delta review confirms that revision 2 resolves all four prior HIGH blockers: immutable legacy history is explicitly admitted without rewrite, canonical/adaptive ownership is separated with recovery rules, the required reminder has a fenced evidence lifecycle, and schedule confirmation has an exact-revision typed authority transition. The risk policy is now executable but remains incompletely governed because its authoritative owner and durable artifact/verification boundary are unnamed; this is a non-blocking carryover MEDIUM finding.

## Claims
- History compatibility now handles both independent legacy exclusions: archived schema-1 `history_imported` roots receive a narrow admission rule, while schema-2 requires a typed manifest day equal to the parsed root KST day; mapping disagreement fails closed and canonical bytes, revision, and epoch remain unchanged (revision lines 43–44, acceptance 1–2).
- Canonical storage is limited to schedule/check-in/confirmation source facts, while `AdaptiveEventStore` alone owns baseline, confirmed strategy, review, approval, activation, and delivery lifecycle. Exact source-tuple dedupe, canonical-first append, crash reconciliation, and stop-on-disagreement replace recency arbitration (lines 45–46, acceptance 3).
- The reminder is a single fixed approved template using the existing customer schedule reservation/fence/receipt ledger. Only delivered plus sent-audited evidence counts; unknown, unaudited, corrupt, expired, or absent evidence neither retries nor creates a non-response candidate (line 50, acceptance 7).
- `schedule_confirm` is distinct from adaptive proposal approval and binds the exact current reference, authenticated review identity, refreshed canonical owner, configuration/customer/epoch pins, origin, expiry, and nonce; supersession invalidates the capability and eligibility (line 47, acceptance 4).
- `dual-coach-risk-v1` now fixes all six normalization bands, the integer-sum formula, inclusive threshold `>=4`, hard safety overrides, fail-closed missing evidence, digest, reason codes, and deterministic candidate key (line 49, acceptance 6).

## Analysis
### Spec compliance
The corrected delta satisfies the locked automatic-reminder requirement without reopening AI/customer auto-delivery: the sole scheduler-eligible content is a static operational reminder, while strategy and coaching output remain behind explicit operator approval/send. The baseline and confirmed strategy, six morning fields, safety overrides, current schedule note, customer isolation, and no-calendar boundary remain intact.

### Prior finding resolution
1. **History compatibility — resolved.** The plan chooses one explicit compatibility contract rather than deferring it: immutable schema-1 history derives the day from KST occurrence under a narrow provenance/status rule, schema-2 requires matching typed provenance, and source-day mappings must agree before projection.
2. **Ledger authority — resolved.** Strategy/review lifecycle no longer appears in both ledgers. Canonical facts project one way into the adaptive journal, with exact source pins and deterministic reconciliation after partial append.
3. **Reminder lifecycle — resolved.** A bounded producer, reservation key, eligibility/pin checks, immediate pre-send response check, durable success evidence, deadline, terminal uncertainty, and non-response dedupe key are all specified.
4. **Schedule-confirm authority — resolved.** The host action is separately typed, exact-reference scoped, single-use, fully pinned, and invalidated by supersession or authority/context change.
5. **Risk policy — partially resolved.** Behavior and identity are deterministic, but “approved policy artifact” does not identify who approves it, where its canonical representation lives, or which boundary verifies that approval/digest before evaluation or activation.

Under the pass-2 ratchet, no previously approved ground was re-litigated and no new scope was introduced. The remaining finding is the unresolved governance portion of the prior MEDIUM risk-policy finding; it does not preserve the prior BLOCK/REQUEST CHANGES verdict after all HIGH blockers are resolved.

## Root Cause
The former blockers came from leaving compatibility, aggregate ownership, delivery proof, and authority transitions to implementation-time choice. Revision 2 repairs those contracts. The sole remaining ambiguity is policy governance: deterministic policy contents are specified, but authoritative custody and approval verification are not.

## Findings
1. **MEDIUM — revision line 49 — Risk-policy authority and artifact location remain unnamed.** Impact: an implementation could self-approve or relocate `dual-coach-risk-v1`, weakening policy drift and activation controls despite persisting a digest. Fix: name the durable repository/runtime artifact and schema, its approving authority, and the verifier that must match the canonical digest before evaluation or activation.

## Recommendations
1. Before implementation of the risk evaluator, add the exact `dual-coach-risk-v1` artifact location/schema, approving authority, and verification boundary. Preserve the already-fixed table, threshold, overrides, missing-evidence hold, digest, and dedupe key.
2. Proceed with the compatibility gate and the corrected ownership/reminder/confirmation contracts unchanged; no further architectural broadening is warranted in this pass.

## Architectural Status
`WATCH`

## Code Review Recommendation
`COMMENT`

## Tradeoffs
- **Approve the corrected architecture with one governance comment:** preserves pass-2 monotonicity and avoids another revision for a non-blocking policy-custody detail, but requires implementation handoff to close that detail before evaluator activation.
- **Require another planning revision:** would make governance explicit earlier, but is disproportionate because the behavioral policy, safety behavior, and all prior HIGH contracts are already executable.

Verification: planning-only delta review. No tests, formatters, implementation, fixtures, migration, activation, or provider actions were run.