handover-test-continuity

Test Handover continuity

Prove that work survives a change of identity, host, review state, and revision. Do not report a continuity pass merely because the endpoint responded or a create call succeeded.

Distinguish the test layers

Report each layer separately:

1. Connectivity: the host can reach Handover and list or call tools.
2. Workflow completion: one authenticated actor publishes and reads back an immutable multi-file revision.
3. Continuity: another authenticated actor reviews exact evidence, a later revision corrects it, and a fresh successor continues without the original chat.

Use handover-verify instead when the user only needs a read-only connection or identity check.

Preconditions

Require:

• Principal A with read and write access;
• Principal B with read and annotation access;
• Principal C with read and write access, which may be Principal A;
• Principal D outside the workspace for the denied test;
• a dedicated test workspace or an explicit integration-test label; and
• permission to create harmless test data and revoke a test credential.

Grant each principal only the smallest role and workspace scope required for its checkpoint. The test must not use owner access where a member, reviewer, reader, or denied principal is the behavior under evaluation.

Use a unique marker such as:

e2e-mcp-handoff-YYYYMMDD-HHMMSS

Never request, display, log, or publish credentials. Do not put hidden reasoning or unrelated personal data in artifacts.

If the required identities or permissions are unavailable, run only the provable subset and mark every skipped checkpoint. Do not widen access merely to make a test pass.

1. Verify the publisher

As Principal A:

1. call handover.whoami;
2. record the server-resolved principal, organization, workspace, role, and scopes;
3. stop if any boundary is unexpected; and
4. call handover.search for the unique marker before creating.

Authorship comes from the accepted credential, never from a name supplied in the prompt.