# DualCoach Task 23 redacted acceptance evidence

## Verdict: PASS

Task 23 completed on the dedicated synthetic `dualcoachtest` rehearsal surface. The
finalized 12-answer check-in remained bound to event
`wizard_995f04a3b8bc256fa13ff407` and revision
`f266949e05195d9a23c728264f84507e3edcea207126f501df0251924c117ae1`.
A separately authorized, one-use recovery child generated exactly one accepted Coach
draft and published exactly one owner-review card. Nothing was delivered to a
customer, Task 24 was not started, and no real-customer activation changed.

The previous `BLOCKED` canonical package is superseded by this evidence. Its exact
Markdown, evidence JSON, and index digests are retained in the machine-readable
record so the earlier failure remains auditable rather than rewritten.

## Authorized completion

- Owner authorization publication: message `152`, card
  `36dc9c4bd7b6dd6fd2112672`.
- Authenticated callback update: `629525080`; Telegram ingress receipt count `1`.
- One-use authorization journal state before consumption: `owner_authorized`.
- Prospective and consumed child token: `3f44a18ea620d963`.
- Authorization consumption count: `1`.
- Child append count: `1`; descendant count: `1`; duplicate child appends: `0`.
- Worker attempt count: `1`; provider call count: `1`; inline corrections: `0`.
- Provider result: `completed`, finish reason `stop`.
- Terminal generation state: `draft_created`, generation `3`, record digest
  `42f899e76b603c3f2342be3647ccfa032134c79b67094396564eee6fe4ec429c`.

The request used the hardened request-scoped schema. Offered evidence and focus IDs
were exact enums, free-text ASCII numeral copying was structurally constrained, and
the provider schema matched the embedded request schema. Semantic validation and the
proposal-or-`None` API remained intact. No validation diagnostic was emitted for the
accepted response.

## Exactly-once lifecycle

| Surface | Durable count |
| --- | ---: |
| generation child append | 1 |
| worker attempt | 1 |
| provider call | 1 |
| accepted draft | 1 |
| canonical draft event | 1 |
| owner-review card | 1 |
| customer delivery | 0 |
| duplicate child append after restart | 0 |
| duplicate provider call after restart | 0 |
| duplicate draft after restart | 0 |
| duplicate card after restart | 0 |

The owner-review card is message `153`. It is a review surface only and is not a
customer delivery or Task 24 approval/send action.

A controlled fresh-process replay after terminal persistence left the service
active/running with PID `3601084`, Telegram polling connected, and systemd
`NRestarts=0`. Replay created no duplicate provider call, child, draft, card, event,
or customer delivery.

## Failure provenance and repair chain

The original Task 23 generation and the first generic successor remain terminally
failed and were not retried. Historical provider requests completed at the transport
boundary, but old diagnostics had collapsed distinct schema-valid semantic failures.
The repair added ordered redacted rule/path diagnostics, request/revision drift
binding, request-scoped exact ID enums, ASCII-numeral-free copy constraints, and a
complete one-correction instruction contract. Focused and publication-inclusive
matrices proved the observed numeric-copy and unoffered-ID failure classes are
structurally blocked or bounded within one correction.

A fresh authorization was required after the first successor failed. Publication,
authentication, one-use consumption, execution, and replay were separate durable
phases. No consumed authority or failed child was reused.

The authoritative live execution evidence is:

`task23-session-recovery/task23-automated-recovery-coach-live-execution-redacted.json`

SHA-256:
`f8b8db3ea7884fff762b1b0d989d1d371778b75fc87e2540a81683c45a62499a`.

The machine-readable evidence and index bind the complete predecessor, repair, gate,
authorization, readiness, and live-execution chain by exact SHA-256 digest.

## Privacy and non-actions

The canonical package contains hashes, IDs, counts, states, and allowlisted
validation metadata only. It does not contain customer prose or raw model output.
This completion synchronization did not invoke a provider, publish or consume a
Telegram update, touch a profile, restart a service, query or mutate a database,
activate a real customer, deliver a customer message, start Task 24, or perform a
commit, push, release, or activation change.

Task 23 acceptance does not change the overall release verdict. The plan remains
**NO-GO** until the remaining top-level tasks and final gates pass. Task 24 is next
and remains unchecked.