relex-intakelisted

# End-to-end client intake You can take a matter from a client's first request all the way to a signed engagement + an issued invoice, entirely over the MCP — without ever handling the client's name, email, or ID. Identities are resolved server-side from ID-ONLY references; you work in labels and refs. ``` find the request → snapshot + conflicts → write the intake → agreement from a template → e-sign (id-only) → invoice → record ``` Everything here is **organisation-only** (agreements, invoices, clients are org features). In a personal workspace these calls return `organization_required` — tell the user to switch to (or set up) an organisation. ## 1 · Find the request Two sources, both PII-safe: - **By email** — `execute POST /users/me/connectors/gmail/sync` pulls recent mail into private knowledge (redacted on ingest; returns counts only). Then `execute GET /knowledge` lists sources as METADATA ONLY (filename, folder, status, page/party counts, dates) — never content. To read the substance of a request, run a case turn (`POST /agent {type:"case_req"}`, which searches the redacted corpus) or hand the user the knowledge deep link. The Gmail connector must be connected in the browser first. - **By guest link** — the client joined a case via a guest link. Read the roster with `GET /ontology/case/{caseId}/participants` (`relex-participants`): the client is usually `[GUEST_1]`. Read what they wrote via `execute GET /cases?caseId={caseId}&full=true` (note: c