| 1 | # Live background-work verification |
| 2 | |
| 3 | Run from the repository root with Node 24 and installed dependencies. This uses |
| 4 | real provider CLI credentials and consumes model usage: |
| 5 | |
| 6 | ```sh |
| 7 | node apps/server/scripts/verify-background-live.ts --repeat 2 |
| 8 | ``` |
| 9 | |
| 10 | Each scenario starts the production server in a fresh temporary T3 home and Git |
| 11 | project. It connects through authenticated HTTP and the same typed WebSocket RPC |
| 12 | contract as clients. There are no substituted adapters, in-memory databases, or |
| 13 | seeded projection rows. Existing T3 environments are not modified. |
| 14 | |
| 15 | The scenarios exercise delegated completion after the parent ends its turn, |
| 16 | delivery into an active foreground command, native background-command wake-up, |
| 17 | and nested delegated results. A local HTTP request holds the actual background |
| 18 | command until the required parent state is observed. Its random response is not |
| 19 | included in the parent prompt. Passing requires the agent to retrieve that result, |
| 20 | acknowledge it, and finish; a delivery receipt alone is insufficient. |
| 21 | |
| 22 | Assertions also check task-result publication, acknowledgement state, typed |
| 23 | notifications rather than additional user-message items, run boundaries, and an |
| 24 | empty provider background roster. Successful scenarios restart the real server |
| 25 | and check that the acknowledgement survives and runs remain completed. This is |
| 26 | a clean-restart persistence check, not proof of crash recovery during delivery. |
| 27 | |
| 28 | Use `--scenario idle|active|native|nested`, `--model`, `--provider`, and `--timeout` |
| 29 | in seconds to narrow a run. The default provider is `claudeAgent` and the default |
| 30 | model is `claude-sonnet-4-6`. The native scenario specifically requests Claude's |
| 31 | background Bash tool; do not treat it as generic provider conformance. Active |
| 32 | delivery expects a provider supporting active steering. Missing authentication, |
| 33 | unsupported capabilities, provider failures, and model instruction violations |
| 34 | are failures, never skipped passes. Inspect the retained trace to distinguish them. |
| 35 | |
| 36 | Check the verifier's failure detection with a real failing HTTP dependency: |
| 37 | |
| 38 | ```sh |
| 39 | node apps/server/scripts/verify-background-live.ts --scenario active --fail-gate |
| 40 | ``` |
| 41 | |
| 42 | That command must exit nonzero. It must not be counted as a passing product test. |
| 43 | |
| 44 | Each run prints its evidence directory. It retains the SQLite database, native |
| 45 | provider logs, streamed events, final projection, prompt, revision and dirty-file |
| 46 | inventory, and machine-readable verdict. Suite reports link every attempt, |
| 47 | including failures; repeating a test does not erase an earlier failure. Evidence |
| 48 | is local and may contain provider output. Do not upload the entire T3 home. |
| 49 | |
| 50 | This loop does not verify rendered folding, mobile UI, cancellation, or abrupt |
| 51 | process loss between provider acceptance and receipt persistence. Those require |
| 52 | additional scenarios before claiming complete background-lifecycle coverage. |