# Bounded MCP continuity regression design

Observed 2026-09-09 UTC. Changed files only:

- `scripts/test_v049_mcp_continuity.py` (new isolated suite).
- `reports/v049-mcp-continuity-test-design.md` (this report).

No implementation changes, production/network access, canonical credential access,
commits or packages. The narrow two-file assignment supersedes startup intake
mutation for this worker; the main owns intake synchronization and final delivery.

## Execution and boundary

Run from `[PRIVATE LOCAL PATH]`:

```powershell
& .local-secrets/weaponizedautonomy-mcp-venv/Scripts/python.exe -B scripts/test_v049_mcp_continuity.py
```

Final fake-only run: **41 tests; 14 passed; 27 failed; 0 errors; 0 skipped**.
Exit status 1 is intentional evidence of unsupported requirements, not an
expected-failure exemption. Connector SHA-256 observed for these runs:
`156f77093596c1899e9a3a12e674e55e1f9749e2981f05f686288c57ee56f33d`.

Fixtures use `_new_state` plus a known full principal. Custody deep-copies every
save/load; a fresh connector receives only this retained state and the fake
backend. No WinCred object is constructed. Guards deny real store/client
construction and socket connection; bytecode writing is disabled. The two
hard-coded bearer-shaped values are never-enrolled synthetic fixtures.

The fake records every mutation's bearer, candidate, operation-derived key,
full expected predecessor principal and pre-send custody snapshot. Changed
retries fail instead of being accepted by a permissive mock. A lost-before-send
response has zero effects; lost-after-commit has one. Replay cannot create a
second effect. Separate injection controls distinguish candidate authentication,
old authentication, temporary unavailability, terminal candidate rejection and
failed custody writes. No assertion depends on a new principal field name:
the pre-send check locates the complete verified principal in retained state.

## Failure map to requirements

| Requirement | Failing cases | Observed behavior |
| --- | ---: | --- |
| Persist fresh full predecessor proof before sending | 1 | Retained principal is stale rather than the just-verified `/me` result. |
| Fresh-process exact retry, no new candidate | 3 | Uncommitted pending request is discarded; committed public retry attempts a different request; repeated deferrals lose intent. |
| Compare full identity/scope and candidate credential ID | 11 | Initial rotation misses workspace/project/scope type/scope ID differences; recovery misses all six identity/scope fields and credential ID. |
| Successor authentication plus old authentication rejection before promotion | 9 | Old-still-active succeeds in both paths; old transport/403/503 failures do not prevent promotion; recovery never probes old rejection. |
| Terminal candidate rejection retains pending proof | 1 | With old still active, pending candidate is silently discarded before exact replay. |
| Redaction and truthful ambiguous-effect reporting | 2 | Reflected bearer in error request ID survives to tool result; committed lost-response error claims `safeNoOp: true`. |

Named cases are discoverable directly in the suite. Scope cases are individually
generated for `agentId`, `workspaceId`, `projectId`, `scopeType`, `scopeId`,
`authority` and `credentialId`, separately for normal rotation and recovery.
Unavailable cases individually test no HTTP status, 403 and 503 on each bearer
in both paths; none is accepted as proof of authentication revocation.

Passing cases cover the ordinary success path, pre-send custody failure with no
mutation, candidate-unavailable retention (six cases), both rejected retention,
post-verification save failure/recovery, three existing initial binding checks,
and ordinary return/error/stdout/stderr redaction. These passes do not cancel the
missing checks above. The reflected-error test deliberately exercises the
connector's dependency boundary; it does not claim the current live transport
has returned such metadata.

## Integration notes and unproven boundaries

Keep these tests strict while main repairs the existing connector. Preserve
`rotate_credential(confirmation, operation_id)` and `_recover_rotation(state)`
signatures; extended state can flow through the copy-preserving fake. Re-run on
the final implementation and record the new source identity/results. A fake
success here is not native custody durability, cross-process locking, total
machine-loss recovery, real HTTP replay, actual ChatGPT connection, or deployed
acceptance. No real Windows credential serialization or cryptographic custody
is exercised. The separate implementation worker must test those boundaries.