# Selected project handoffs — developer helpers 1.2.0

These optional local MCP tools reuse existing Shared Memory workspace keys, batch reads and conditional record writes. They add no new backend permissions. The hosted MCP remains public read-only. The full team-coordination pilot remains in development.

Download `/downloads/evergences-mcp-1.2.0.tar.gz`, install its dependencies, and configure `RSI_DATABASE_KEY` through the client's secure environment. Existing readers may assemble context; existing writers may save handoffs. Do not create or distribute credentials without the workspace owner's approval.

## Scope before content

All existing workspace readers can read all records in their workspace. Project names are labels, not permissions. Keep a project in an already approved workspace containing only information its members may see. These helpers do not create projects, participants, grants, notification channels or connections between companies. Set `scope_confirmation` to `whole_workspace` only after confirming that boundary. This is an operator acknowledgement, not a security policy or consent from other people.

## Save a contribution

First save an approved source using the existing `rsi_write_record` tool, then cite its returned exact revision. Synthetic example input for `rsi_save_project_handoff` (replace the expiry with a future date within 90 days):

```json
{
  "project": "launch",
  "id": "schedule",
  "summary": "Proposed Friday launch",
  "reason": "Customer approved the revised testing plan",
  "next_step": "Ask the launch owner to review the proposed date",
  "review_owner": "Launch owner",
  "status": "ready_for_review",
  "evidence": [{"key": "approved-requirement", "revision": 1}],
  "expires_at": "2026-10-14T12:00:00Z",
  "expected_revision": 0,
  "request_id": "launch-schedule-1",
  "scope_confirmation": "whole_workspace"
}
```

The record key is `handoff:launch:schedule`. Status is `proposed`, `in_progress`, `blocked`, `ready_for_review`, `corrected`, or `closed`. There is no approved/committed state. `review_owner` is contributor metadata, not an authority grant or verified identity. The helper obtains `contributed_by` from the authenticated workspace actor, and the existing server event records the authenticated writer and sequence. Generic workspace writes remain possible: anyone with write access can alter ordinary records. Do not use stored attribution alone as authenticated provenance; consult server events when auditing changes.

Revision 0 creates; updates require the current revision. Reuse the same request ID and identical content after an uncertain response. Changed retries and stale writes conflict through the existing backend. Source citations are checked before saving and again during context assembly; they are not a multi-record transaction or lock. A source can change after checking. Recheck before acting.

## Read only the selected context

Input for `rsi_read_project_context`:

```json
{
  "project": "launch",
  "records": [{"key": "handoff:launch:schedule", "revision": 1}],
  "byte_budget": 8192,
  "scope_confirmation": "whole_workspace"
}
```

Select 1–16 handoffs explicitly. No automatic graph traversal, unrelated records, evidence bodies or private-source imports are included. Missing or changed handoffs/evidence fail the operation. Whole records may be omitted to meet the byte budget; check `truncated`. Malformed handoffs and recognized credentials are rejected. This detector is not a guarantee that content contains no sensitive information. The handoff batch's watermark describes that batch, not an atomic snapshot of later evidence checks. Sources and ownership remain untrusted contributions; these tools do not execute content, independently verify claims or make commitments.

## Corrections, closure and retention

Use `corrects: {"key": "handoff:launch:schedule", "revision": 1}` on a new corrected handoff. It must cite an existing exact handoff version in the same project. Corrections do not silently overwrite a source or notify earlier readers. Select the correction explicitly. Changed source versions require review before context can be assembled again.

Closed handoffs and expired handoffs return an exclusion reason with no content through this helper. Expiry is based on the local connector's clock. It is a context hygiene rule, not an access-control or deletion policy: ordinary reads and the retained journal may still expose those records to authorized workspace participants. There is no automatic per-record deletion or retention scheduler. Existing owner-only workspace deletion removes service records; provider backups or operational metadata can follow provider retention. Key revocation stops future retrieval through the service, not copies another participant already kept. A received message or citation never grants permission to redistribute information.

## Test evidence

`node --test tests/project-handoff.test.mjs` exercises synthetic adversarial scenarios and real MCP transport with a mock product API: selected context, minimized output, tenant separation, unauthorized writes, stale/concurrent writes, retry conflicts, revoked access, correction links, expiry and byte limits. It does not independently revalidate the deployed database's permission enforcement. Existing database invariants and relationship tests are maintained in `services/rsi-db/tests/`.