I read this as an independent safety audit of the complete new-user workflow - I’ll trace the production candidate without touching it, then run only isolated disposable tests and report one decisive verdict with evidence.


The candidate is an exported/sealed tree rather than a Git worktree (`.git` is absent), so I’m switching identity verification to its seal/manifests and tracing the focused v1.5 tests and runtime wiring directly.


The runtime trace has exposed a likely decisive blocker: `/start rc1_<token>` is implemented, but the sealed runtime exports no operator command to create that token; the only producer is an internal Python method used by fixtures. I’m now running the focused workflow suites in a network namespace to confirm everything after that missing entrypoint is safe and isolated.


I read this as a final onboarding safety verdict - I audited live state read-only and exercised the smallest isolated workflow suites.

## Verdict: FAIL

A brand-new user cannot enter the NutriCoach v1.5 r28 onboarding workflow through a supported operator surface.

### Decisive blocker

The customer entrypoint is:

```text
/start rc1_<22-character-token>
```

or:

```text
/start@<bot_username> rc1_<22-character-token>
```

However, r28 exposes no CLI or operator command that creates this invitation token.

- Token creation exists only as the internal Python method `RoomBootstrapStore.prepare_rehearsal_customer_invite(...)`.
- Its only callers in the candidate tree are tests/disposable fixtures.
- Installed `dualcoach_admin` customer commands are only:
  - `activate`
  - `staff-membership-preflight`
  - `staff-membership-finalize`
  - `staff-membership-verify`

Therefore an operator cannot establish the prerequisite token through the sealed product, and a new user cannot begin onboarding.

## Live observations

Read-only inspection confirmed:

- Running runtime: `.../.strict-runtime/1128e376-v150/venv`
- Candidate digest: `1128e376747835bc75c5cfe43f024ce644d72492796acc5778f8a13aa382c528`
- Capacity: `5`
- Enabled customers: `1`
- Disabled drafts: `1`
- Room bootstrap: enabled
- Nutrition onboarding: enabled
- Weekly authority binds the one enabled customer.
- The five core workflow source files tested exactly match the r28 manifest hashes.
- Channel Inbox remains unconfigured/off; this does not block private bot-DM onboarding.

Runtime inspection command:

```bash
R=/home/cube/.hermes/profiles/dualcoachtest/.strict-runtime/1128e376-v150/venv
"$R/bin/python" -B - <<'PY'
import inspect, json
from pathlib import Path
import gateway.platforms.telegram as telegram
import gateway.platforms.dualcoach_admin as admin

registry = json.loads(
    Path("/home/cube/.hermes/profiles/dualcoachtest/customers/registry.json").read_text()
)
print(inspect.getfile(telegram))
print("capacity", registry["admission_policy"]["max_enabled_customers"])
print("enabled", sum(c["enabled"] for c in registry["customers"]))
print("customer commands", sorted(
    next(a for a in admin._parser()._actions if getattr(a, "choices", None))
    .choices["customer"]._actions[1].choices
))
PY
```

## Required workflow preconditions

If the missing invitation command is supplied, successful onboarding requires:

1. A unique disabled customer draft and no nonterminal bootstrap for that key.
2. A token generated by the canonical bootstrap store.
3. Customer opens the token within 24 hours.
4. `/start` occurs in a private DM where `from_user.id == chat.id`; customer must not be the owner.
5. Registration creates an exact disabled registry row; it grants no activation.
6. Customer explicitly grants current `privacy-v1` consent.
7. Answers arrive from the exact registered route and in question order.
8. Owner review/finalization produces readiness artifacts while the customer remains disabled.
9. Fresh Telegram staff-membership evidence and deployment receipt exist.
10. `dualcoach_admin customer activate ...` receives the exact bootstrap generation, data root, evidence paths, and current external Task26 authority.
11. Activation remains serialized and total enabled customers must not exceed five.
12. Weekly startup authority then registers enabled, consenting customers only.

The mandatory fresh Telegram membership probe and real message delivery were intentionally not exercised because this audit prohibited network access and real-user messaging.

## Disposable verification

All suites ran with `/` read-only, `/tmp` disposable, and a separate network namespace:

```bash
bwrap --unshare-net --ro-bind / / --proc /proc --dev /dev --tmpfs /tmp \
  /bin/bash -lc '<pytest command>'
```

Observed:

- Bootstrap TTL/single-use, weekly registration, disabled-draft preservation, no-provider startup, routing/consent isolation: **13 passed**
- Capacity five, overflow rejection, independent receipts/data roots, scheduling fanout, onboarding consent/finalization, weekly cross-customer substitution rejection: **15 passed**
- Transaction rollback, exact stage sequence, Channel Inbox off, bootstrap network gate: **16 passed**

Total: **44 passed**.

These suites prove that after admission begins:

- Five enabled customers are accepted.
- The sixth enabled customer is rejected.
- Disabled drafts do not consume enabled capacity.
- Customer routes, data roots, activation receipts, weekly registration, and scheduling remain isolated.
- Missing/revoked consent fails closed.
- Weekly startup performs no provider call.

## No-external-write evidence

Before and after testing, SHA-256 inventory over live `config.yaml`, registry, gateway state, and all 690 data files was identical:

```text
b9788dbc193eb9526ae60f48a50c4f39e724bfff2b111338ba5a553458163fe6
693 files
diff: empty
```

Additional guarantees:

- `bwrap --unshare-net` removed network access.
- `/` was mounted read-only.
- All pytest roots and `HOME` were under disposable `/tmp`.
- No test process retained a network socket.
- No Telegram API, provider, real-user message, live registry mutation, profile mutation, or customer-data external write occurred.