I read this as hands-on QA execution - I will enumerate the scenario matrix, run the installed r44 runtime only against disposable offline roots, and report observed evidence with a PASS/FAIL verdict.


I read this as hands-on QA execution - the required pre-execution matrix is below; I will now bind it to the r44 sealed runtime and execute every P0/P1 case without Telegram/provider access.

| ID | Pri | Scenario |
|---|---|---|
| S01 | P0 | Issue invite |
| S02 | P0 | Claim valid link |
| S03 | P0 | Wrong-user claim rejection |
| S04 | P0 | Wrong-chat claim rejection |
| S05 | P0 | Expired invite rejection |
| S06 | P0 | Replay claim rejection |
| S07 | P0 | Consent capture |
| S08 | P0 | Complete all onboarding answers |
| S09 | P0 | Reject malformed answer |
| S10 | P0 | Pause then restart and resume |
| S11 | P0 | Revise onboarding response |
| S12 | P0 | Owner review |
| S13 | P0 | Membership preflight |
| S14 | P0 | Membership finalize |
| S15 | P0 | Membership verification |
| S16 | P0 | Activation |
| S17 | P0 | First customer check-in |
| S18 | P0 | Edit and save check-in |
| S19 | P0 | Duplicate check-in prevention |
| S20 | P0 | Safety hold |
| S21 | P0 | Capacity-full rejection |
| S22 | P0 | Crash/restart persistence |
| S23 | P0 | Permission-denied data root |
| S24 | P0 | Symlinked data-root rejection |
| S25 | P1 | Stale callback rejection |
| S26 | P1 | Uncertain publication is terminal/no retry |
| S27 | P1 | Exact owner/chat/topic isolation |
| S28 | P1 | Consent required before finalization |
| S29 | P1 | Review gated on complete onboarding |
| S30 | P1 | Activation gated on verified membership |
| S31 | P1 | Duplicate link issuance prevention |
| S32 | P1 | Check-in append-only edit lineage |
| S33 | P1 | Restart preserves anti-replay state |
| S34 | P1 | Invalid callback never mutates state |
| S35 | P2 | CLI help and operator error rendering |
| S36 | P2 | Empty disposable root bootstrap |
| S37 | P2 | Boundary-length valid answers |
| S38 | P2 | Rejected answer leaves prior state intact |


I read this as hands-on QA execution - r44 is the sealed successor runtime at `.../.strict-runtime/62f33e7d-v150/venv` with the sealed wheel hashes `hermes=df4e61...4455b22` and `physique=7c5172...b061f`; the run will use that interpreter, installed modules only, a socket-connect tripwire, and `/tmp` roots only.


I read this as QA execution with a fixture-schema failure - the installed registry rejects the hand-written admission policy before any runtime scenario, so I am correcting only the disposable fixture to use the installed schema and will rerun the full matrix.


I read this as QA diagnosis - 41 scenario assertions passed, while post-activation check-in is blocked by the installed multi-customer authority binding rather than check-in behavior; I am tracing that binding in the installed runtime and will supply a disposable valid authority fixture if the public contract supports it.


I read this as precise check-in-flow diagnosis - the primary save succeeded, and only the edit path is failing; I am exposing the returned public reply reason rather than changing runtime code.


I read this as adapter-contract diagnosis - correction cards require their newly published Telegram message ID to be bound before a callback, and the earlier harness deliberately reused the old launcher ID; I am binding the correction prompt as the real adapter does and rerunning.


I read this as completed QA verification - the full rerun passed with 45 scenario assertions, zero socket-connect attempts, and evidence retained under a disposable `/tmp` root; I am now validating the evidence matrix and runtime provenance for the report.


I read this as offline-network verification - the sandbox cannot create a network namespace, so I am repeating the successful disposable run under `strace -f -e network` to verify subprocess CLI paths as well as in-process adapters made no Internet/Telegram connection.


I read this as completed offline production-runtime QA - all required paths passed against the installed r44 runtime, with disposable roots and no network.

**Result: PASS**
`blocker_count=0`
Evidence: `/tmp/r44-hands-on-qa-5mk8qezm/evidence.json` (mode `0600`)

- Runtime: `.../62f33e7d-v150/venv/bin/python`
- Installed versions: `hermes-agent 0.17.0`, `physique-checkin-cli 0.1.0`, `python-telegram-bot 22.6`
- 38 unique scenarios, 45 assertions: **45 PASS / 0 FAIL**
- Socket tripwire: `0` attempts
- Full rerun under `strace -f -e network`: **0 socket/connect/send network syscalls**
- No repository or live-profile edits; live gateway process untouched.

| Priority | Scenarios | Outcome |
|---|---|---|
| P0 | S01 invite; S02 claim; S03 wrong actor; S04 wrong chat; S05 expiry; S06 replay; S07 consent/start; S08 all 22 answers; S09 malformed answer; S10 pause/restart/resume | PASS |
| P0 | S11 revise; S12 attestation/owner review; S13 membership preflight; S14 membership verify; S15 activation; S16 lifecycle finalize; S17 first check-in; S18 edit/save; S19 duplicate prevention; S20 safety hold | PASS |
| P1 | S21 capacity limit; S22 crash/restart; S23 symlink rejection; S24 permission rejection; S25 stale callback; S26 uncertain publication/no retry; S27 callback authorization; S28 reconciliation; S29 disabled-before-activation; S30 post-lifecycle verification | PASS |
| P1 | S31 duplicate nonterminal invite; S32 active check-in integration; S33 durable update replay handling; S34 stale card binding | PASS |
| P2 | S35 installed-runtime provenance; S36 disposable-root isolation; S37 canonical field coverage; S38 error response behavior | PASS |

Key observed evidence:
- Onboarding reached `ready` only after customer attestation and owner approval; customer remained disabled until guarded activation.
- Membership preflight/verify/finalize/post-lifecycle verify succeeded with the read-only fake Bot API.
- Check-in created two events after correction; duplicate save created zero extra events.
- Safety input stopped at `safety_hold`.
- Unknown publication outcome remained terminal `UNCERTAIN` after restart with exactly one provider call.


I read this as a read-only live-cron diagnosis - I will identify the live r44 profile, copy it into `/tmp`, invoke the installed tick at the specified KST instant with send/network tripwires, and report the exact failing task branch without modifying production state.


I read this as establishing a faithful disposable snapshot - the live profile is `dualcoachtest` (active r44 gateway PID `1418148`); I will copy only its configuration, customer registry, runtime state, and profile package into `/tmp`, then run the exact authorized method against that copy.


I read this as the controlled reproduction - the harness now calls the installed `_send_nutrition_coaching_tick_authorized` directly at `2026-08-31T08:55+09:00`, records each `failures.append` source branch, and replaces every topic send with a fake receipt.


I read this as a disposable-snapshot relocation issue - the installed committed-registry loader correctly rejects an activation-journal path still pointing at the live root; I will repair only copied path bindings and their dependent receipts, then rerun.


I read this as completing the faithful host setup - the direct method reached the installed weekly-dispatch branch, which needs the adapter-owned weekly authority normally created at gateway startup; I will construct that authority from the copied configuration and registry rather than bypassing the branch.


I read this as isolating the live-specific failure condition - the installed adapter has no code path that installs `_weekly_operations_explanation_model`; Monday's weekly branch therefore has a concrete fail-closed candidate. I will still run the actual method after rebinding the copy's inode-based authority in memory, without changing production or the copied evidence payload.


I read this as executing the sealed-authority reproduction - the harness now uses normal adapter construction and copied state, with only source inode metadata virtualized so relocation cannot invalidate the production authority; it will report the method's real `SendResult` and branch trace.


I read this as a second authority integrity finding - the copied bytes pass the descriptor-root check but fail at the canonical customer-registration check; I will compare that registration's exact pinned identities with the live read-only state to distinguish a relocation artifact from the cron's actual fail-closed branch.


I read this as resolving a clone-only path-affinity artifact - the failed canonical binding is caused by the registry loader incorporating the absolute profile root, not by differing live inode pins; I will preserve the live-derived binding while rebasing only runtime file paths to the copy, so all reads/writes still target `/tmp`.


I read this as a stop-and-report request - I will make no further harness changes; I will verify only the weekly draft error handling needed to state whether the missing model is deterministically converted into the cron failure.


I read this as a narrow diagnosis report - exact replay is blocked by relocated authority identity, so I will report only proven findings.

- Exact `SendResult.error` is unavailable: normal r44 adapter construction on the disposable copy fails before `_send_nutrition_coaching_tick_authorized` can run. The first executed failure is `construct_owned_customers`' canonical-registration guard: `weekly reminder canonical registration is unavailable` (`source.binding_digest != canonical row.binding_digest` for `pilot_20260820_01`). This is a copy-relocation artifact, not proof that the live process takes that branch.
- No live failing branch is proven from read-only evidence beyond the cron's generic `inline-card send failed`. The active process may retain already-open authority capabilities that a copied profile cannot recreate.
- Missing weekly explanation model is **not** the root cause. `generate_weekly_explanation()` raises `OSError`, but `call_weekly_provider()` catches it and `WeeklyOwnerDraftService` deterministically persists `PROVIDER_FAILURE_FALLBACK`; it should not produce a failed `SendResult` if authority and persistence remain valid.
- Network isolation held for the attempted reproduction: socket tripwire recorded zero attempts; `strace` recorded zero network syscalls.

Minimal recommendation: make the cron record/log the returned `SendResult.error` and accumulated failure keys, rather than replacing them with `inline-card send failed`.