"namespace:ai.mcp360.connect" matching MCP tools:

• get_authentication_status

  connect

  Return the identity-credential signals for a single work — whether it is ready to authenticate, whether the signed credential has gone stale (canonical hash drift per ADR-0024 / Invariant 12), and the per-category Identity Eight slot fillings. Use this before suggesting "your work is ready to authenticate" or "you need to re-authenticate" — never infer from get_work alone. `ready_to_authenticate` is a METADATA gate only: it means the Identity Eight is complete, NOT that the artist can authenticate right now. Authentication requires a paired device. Before telling the artist a work is "ready to authenticate," confirm a paired device exists by calling list_authentication_devices and checking `has_signing_genesis`: if it is FALSE the account has never paired, so the true next step is first-device pairing (open Raisonnai on the computer — it runs inline at first authenticate per ADR-0029), not authentication itself. Surface pairing as the next step, not "ready to authenticate." TRIGGER: "is [work] ready to authenticate," "what's pending on my work," "do I need to re-authenticate." Look up work_id via search_natural_language — never ask the user for it.

  Connector

• create_custody_event

  connect

  Record a consignment or loan: a work moves physically to a gallery, dealer, museum, or other holder without ownership changing. Use kind=consignment when the work is placed with a gallery or dealer for potential sale (typically with commission and asking price). Use kind=loan for exhibition loans, museum loans, or private loans without sale intent. TRIGGER: "I just consigned this to Pace," "on loan to the Whitney," "sent to Gagosian for the summer," "loaned to a private collector." Present a summary (work, holder, kind, dates, plus commission and price for consignments) and confirm before saving. Consignments support exclusivity. Only one active exclusive consignment per work is allowed; concurrent attempts return HTTP 409 with the blocking event in details.blocking_event. Does NOT trigger pending_resignature. Custody lives on a separate timeline from the signed record, so recording a consignment or loan does not invalidate the existing VC. Resolve work_id via search_natural_language. Never ask the user for the UUID.

  Connector

• list_custody_events

  connect

  List the custody timeline for a work: consignments and loans where the work is physically held by someone other than the owner. Separate from provenance (ownership history) and exhibitions (public display history). TRIGGER: "is this on consignment," "where is the work physically," "who has it now," "show consignment history," "show loan history." Returns events in reverse chronological order (newest start_date first) with kind, status, holder, dates, prices, commission, exclusivity. Resolve work_id via search_natural_language. Never ask the user for the UUID.

  Connector

• get_synset_info

  dannet

  Get comprehensive RDF data for a DanNet synset (lexical concept). UNDERSTANDING THE DATA MODEL: Synsets are ontolex:LexicalConcept instances representing word meanings. They connect to words via ontolex:isEvokedBy and have rich semantic relations. KEY RELATIONSHIPS (by importance): 1. TAXONOMIC (most fundamental): - wn:hypernym → broader concept (e.g., "hund" → "pattedyr") - wn:hyponym → narrower concepts (e.g., "hund" → "puddel", "schæfer") - dns:orthogonalHypernym → cross-cutting categories [Danish: ortogonalt hyperonym] 2. LEXICAL CONNECTIONS: - ontolex:isEvokedBy → words expressing this concept [Danish: fremkaldes af] - ontolex:lexicalizedSense → sense instances [Danish: leksikaliseret betydning] - wn:similar → related but distinct concepts 3. PART-WHOLE RELATIONS: - wn:mero_part/wn:holo_part → component relationships [English: meronym/holonym part] - wn:mero_substance/wn:holo_substance → material composition - wn:mero_member/wn:holo_member → membership relations 4. SEMANTIC PROPERTIES: - dns:ontologicalType → semantic classification with @set array of dnc: types Common types: dnc:Animal, dnc:Human, dnc:Object, dnc:Physical, dnc:Dynamic (events/actions), dnc:Static (states) - dns:sentiment → emotional polarity with marl:hasPolarity and marl:polarityValue - wn:lexfile → semantic domain (e.g., "noun.food", "verb.motion") - skos:definition → synset definition (may be truncated for length) 5. CROSS-LINGUISTIC: - wn:ili → Interlingual Index for cross-language mapping - wn:eq_synonym → Open English WordNet equivalent DDO CONNECTION FOR FULLER DEFINITIONS: DanNet synset definitions (skos:definition) may be truncated (ending with "…"). For complete definitions, use the fetch_ddo_definition() tool which automatically retrieves full DDO text, or manually examine sense source URLs via get_sense_info(). NAVIGATION TIPS: - Follow wn:hypernym chains to find semantic categories - Check dns:inherited for properties from parent synsets - Use parse_resource_id() on URI references to get clean IDs - For fuller definitions, examine individual sense source URLs via get_sense_info() Args: synset_id: Synset identifier (e.g., "synset-1876" or just "1876") Returns: Dict containing JSON-LD format with: - @context → namespace mappings - @id → entity identifier (e.g., "dn:synset-1876") - @type → "ontolex:LexicalConcept" - All RDF properties with namespace prefixes (e.g., wn:hypernym) - dns:ontologicalType → {"@set": ["dnc:Animal", ...]} (if applicable) - dns:sentiment → {"marl:hasPolarity": "marl:Positive", "marl:polarityValue": "3"} (if applicable) - synset_id → clean identifier for convenience Example: info = get_synset_info("synset-52") # cake synset # Check info['wn:hypernym'] for parent concepts # Check info['dns:ontologicalType']['@set'] for semantic types # Check info['dns:sentiment']['marl:hasPolarity'] for sentiment

  Connector

• set_idle_content

  agentView

  Sets or clears the default idle content for a display. Idle content is shown whenever the display has no active live content (after clear_display, after duration expires, or on first connect). Provide html to set idle content, or omit it to clear idle content and revert to the system default. Provide content_description to improve later state reads. Requires admin scope. Returns id, name and idle content metadata.

  Connector

• respond_to_consignment_request

  connect

  Approve or decline an incoming consignment request. Approve → creates an active custody_event (kind=consignment) using the proposed terms unless overridden. Decline → marks the request declined; no custody_event is created. Approval is a CUSTODY event, not a provenance event — ownership stays with the artist until a sale is recorded. Confirm the action with the user before calling, especially for decline. Use list_consignment_requests to find the request_id — never ask the user for it.

  Connector

• get_authentication_queue

  connect

  List everything queued for the artist to authenticate on their iPhone — RAIs ready to authenticate, RAI Issues awaiting authentication, and active device-rotation flows. Per CLAUDE.md §Cryptographic signing → HITL: the AI assistant can see what's queued but cannot authenticate on the artist's behalf. The response carries `has_signing_genesis` (boolean) — check it BEFORE relaying a next step. If `has_signing_genesis` is FALSE the account has never paired a device: the queue is structurally empty and "open Raisonnai on your iPhone" is the WRONG instruction (there is no app session to open into yet). Instead tell the artist to open Raisonnai on their computer — pairing their iPhone runs inline the first time they authenticate a work (ADR-0029, no credentials typed on the phone). If `has_signing_genesis` is TRUE, relay the normal next step: "open Raisonnai on your iPhone to authenticate."

  Connector

• automation_create

  Perspective AI

  Creates an automation on a perspective. Triggers: per_interview (fires on every completed conversation) or scheduled (daily/weekly digest). Channels: webhook, email, slack, hubspot. Execution modes: direct (fast, deterministic) or agent (LLM-powered). Behavior: - Each call creates a new automation — even if name/config matches an existing one. - Once enabled, the automation starts firing on real events: per_interview sends on every completed conversation going forward; scheduled sends a real message on the configured cadence (daily/weekly). - Webhook URLs are validated. For HubSpot, the workspace's HubSpot connection is required — errors with "Could not resolve HubSpot portal ID — please reconnect HubSpot" if not connected. - Errors when the perspective is not found or you do not have access. When to use this tool: - The user wants ongoing notifications on every completed conversation (per_interview). - Building a daily/weekly digest delivered to Slack, email, HubSpot, or a webhook (scheduled). When NOT to use this tool: - Trying a one-off send before going live — create the automation, then use automation_test (use override_email / override_webhook to avoid hitting real recipients). - Editing or toggling an existing automation — use automation_update. - Connecting Slack or HubSpot — use integration_manage first; the provider must be connected before slack/hubspot channels work. Example — per-conversation Slack notify: ``` { "perspective_id": "...", "automation": { "name": "Notify Slack", "trigger": { "type": "per_interview" }, "execution_mode": "agent", "channel": { "type": "composio", "delivery_config": { "provider": "slackbot", "tool_slug": "SLACKBOT_SEND_MESSAGE", "params": { "channel": "#research" }, "resource_id": "...", "resource_name": "..." } } } } ``` Typical flow: 1. integration_manage (operation: "list"/"connect") → ensure Slack / HubSpot is connected (only needed for those channels) 2. automation_create → create the automation 3. automation_test (with overrides) → verify delivery before relying on it

  Connector

• tfdeploy

  InsideOut (Riley)

  WORKFLOW: Step 4 of 4 - Deploy infrastructure to the cloud Deploy infrastructure by starting a Terraform job for an InsideOut session. This tool initiates the actual deployment process after Terraform files have been generated. IMPORTANT: This starts a long-running job (15+ minutes). Use tfstatus to monitor progress. SINGLE-FLIGHT: only one TF job (apply/plan/destroy/drift) runs per session at a time. If another job is already in flight, tfdeploy returns tf_job_conflict with the live job_id — attach with tfstatus/tflogs instead of retrying, or pass force_new=true to override. Returns confirmation that the deployment has started. REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: plan_id (string) — Apply a previously created plan from tfplan. Preview-then-apply workflow: tfplan → tflogs (review) → tfdeploy(plan_id=...). OPTIONAL: sandbox (boolean, default false) — deploys real generated Terraform. Set to true for cheap sandbox template (testing only). OPTIONAL: ignore_drift (boolean, default false) - when true, proceeds with deploy even if infrastructure drift is detected. By default, deploys fail on drift. Use after reviewing drift details via tfdrift or tflogs. OPTIONAL: force_new (boolean, default false) - bypass the session-level single-flight guard. Use only when the existing run is provably wedged. CREDENTIAL FLOW (if credentials are missing): 1. Response includes a connect_url — present it to the user 2. Call credawait(session_id=...) to poll for credentials 3. When credawait returns success, retry tfdeploy Do NOT call credawait without first showing the connect URL to the user.

  Connector

• tfdeploy

  InsideOut (Riley)

  WORKFLOW: Step 4 of 4 - Deploy infrastructure to the cloud Deploy infrastructure by starting a Terraform job for an InsideOut session. This tool initiates the actual deployment process after Terraform files have been generated. IMPORTANT: This starts a long-running job (15+ minutes). Use tfstatus to monitor progress. SINGLE-FLIGHT: only one TF job (apply/plan/destroy/drift) runs per session at a time. If another job is already in flight, tfdeploy returns tf_job_conflict with the live job_id — attach with tfstatus/tflogs instead of retrying, or pass force_new=true to override. Returns confirmation that the deployment has started. REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: plan_id (string) — Apply a previously created plan from tfplan. Preview-then-apply workflow: tfplan → tflogs (review) → tfdeploy(plan_id=...). OPTIONAL: sandbox (boolean, default false) — deploys real generated Terraform. Set to true for cheap sandbox template (testing only). OPTIONAL: ignore_drift (boolean, default false) - when true, proceeds with deploy even if infrastructure drift is detected. By default, deploys fail on drift. Use after reviewing drift details via tfdrift or tflogs. OPTIONAL: force_new (boolean, default false) - bypass the session-level single-flight guard. Use only when the existing run is provably wedged. CREDENTIAL FLOW (if credentials are missing): 1. Response includes a connect_url — present it to the user 2. Call credawait(session_id=...) to poll for credentials 3. When credawait returns success, retry tfdeploy Do NOT call credawait without first showing the connect URL to the user.

  Connector

• dns_diagnose_sip_target

  Sipflow

  [cost: external_io (DNS via Cloudflare + Google; TLS handshake to public sips/_sips._tcp targets when applicable) | read-only | rate-limited per IP: 10/min, 200/day] Walk DNS the same way a SIP UA does (RFC 3263 §4.1): NAPTR → SRV → A/AAAA. Given a SIP URI ("sip:example.com"), bare hostname ("example.com"), or "host:port" string, return the records that exist and the resolution ladder a UA would try. When the queried target uses TLS (`sips:` URI, `transport=tls/wss`, or any `_sips._tcp` SRV record), the tool also performs a TLS handshake against each resolved sips target and reports the negotiated TLS version + cipher, the leaf certificate's subject / issuer / SANs / validity, the chain length and whether it validates against Node's default trust store, plus two cert-domain checks: RFC 5922 §7.2 strict (cert must cover the original SIP domain) and a lenient SAN match against the SRV target hostname. Egress safety: - Per-IP rate limited. - Hostnames that resolve only to RFC 1918 / loopback / link-local / documentation / multicast space are refused (SSRF guard). - Walk depth capped to prevent runaway NAPTR / CNAME chains. - TLS probes capped at 4 (host, port) tuples per call, 5 s handshake timeout each, public-IP only (we connect to the resolved IP, not the hostname, so the system resolver cannot redirect us into private space). Use to diagnose: - "carrier doesn't answer" / "wrong port" / "TLS instead of UDP" routing puzzles - "carrier rejects our target because no SRV is published" - when A/AAAA resolves but SRV is missing the tool synthesises a copy-pasteable suggested zone-record block pointing at the resolved canonical hostname - "TLS handshake works but cert isn't valid for the SIP domain" - RFC 5922 §7.2 compliance is checked separately from generic chain validation, since the SAN must cover the *original* SIP domain (not the SRV-redirected target) ACL caveat: this tool checks DNS + TLS only. Most carriers (Twilio, Telnyx, Bandwidth, …) authorize inbound SIP by source IP whitelist on the trunk (see https://www.twilio.com/docs/sip-trunking/api/ipaccesscontrollist-resource). Even if DNS resolves cleanly and the TLS cert is valid, INVITEs from any IP not on your trunk's IP ACL will be silently dropped or rejected. Verify reachability from the SBC itself. Pair with: `troubleshoot_response_code` when 503 / 408 / 480 are involved; `search_sip_docs(vendor=...)` for carrier-specific routing docs.

  Connector

• convoopen

  InsideOut (Riley)

  WORKFLOW: Step 1 of 4 - Start infrastructure design conversation Open an InsideOut V2 session and receive the assistant's intro message. The response contains a clean message from Riley (the infrastructure advisor) - display it to the user. ⚠️ Riley will ask questions - forward these to the user, DO NOT answer on their behalf. CRITICAL: This tool returns a session_id in the response metadata. You MUST use this session_id for ALL subsequent tool calls (convoreply, tfgenerate, tfdeploy, etc.). ⚠️ The session_id includes a ?token=... suffix (format: sess_v2_xxx?token=yyy) which is part of the session credential — without it, downstream tools fall back to a tokenless connect URL that 401s. Always pass session_id verbatim to subsequent tools and to the user; do NOT shorten, paraphrase, or strip the ?token= portion when summarizing the session in chat or in your own scratch notes. Use when the user mentions keywords like: 'setup my cloud infra', 'provision infrastructure', 'deploy infra', 'start insideout', 'use insideout', or similar intent to begin infra setup. OPTIONAL: project_context (string) - General tech stack summary so Riley can skip discovery questions and jump to recommendations. The agent should confirm this with the user before sending. Include whichever apply: language/framework, databases/services, container usage, existing IaC, CI/CD platform, cloud provider, Kubernetes usage, what the project does. Example: 'Next.js 14 + TypeScript, PostgreSQL, Redis, Docker Compose, deployed to AWS ECS, GitHub Actions CI/CD, ~50k MAU'. NEVER include credentials, secrets, API keys, PII, source code, or internal URLs/IPs -- only general metadata summaries useful to a cloud architect agent. IMPORTANT: source (string) - You MUST set this to identify which IDE/tool you are. Auto-detect from your environment: 'claude-code', 'codex', 'antigravity', 'kiro', 'vscode', 'web', 'mcp'. If unsure, use the name of your IDE/tool in lowercase. Do NOT omit this — it controls the 'Open {IDE}' button on the credential connect screen. OPTIONAL: github_username (string) - GitHub username for deploy commit attribution. Pre-populates the GitHub username field on the connect page. 💡 TIP: Examine workflow.usage prompt for more context on how to properly use these tools.

  Connector

• confirm_pending_rai_issue

  connect

  Record the Authenticator's intent to authenticate a queued RAI Issue. IMPORTANT: this call does NOT produce the signature. Per CLAUDE.md §Cryptographic signing and ADR-0005, the artist's signing key lives in their iOS Secure Enclave — Raisonnai's servers hold zero keys. Confirmation marks the RAI Issue ready to authenticate; the signature is produced when the artist confirms authentication on their iPhone with Face ID. The AI assistant should tell the user "I've confirmed your RAI Issue — open Raisonnai on your iPhone to authenticate it." Use list_pending_rai_issues to find the issue_id — never ask the user for it.

  Connector

• get_adoption_stage

  Stratalize AI Governance Intelligence

  Public mode returns FS AI RMF framework reference data only — not org-specific scoring. Use when assessing an organization FS AI RMF governance maturity stage or preparing a regulatory AI roadmap presentation. Returns INITIAL, MINIMAL, EVOLVING, or EMBEDDED classification with stage criteria and remediation priorities. Example: EVOLVING stage organizations have documented AI policies but lack systematic model validation — typical gap to EMBEDDED is 18-24 months and 12-15 additional controls. Connect org MCP for org-specific scoring. Source: FS AI Risk Management Framework.

  Connector

• get_work

  connect

  Get full details for a work including images, provenance, exhibitions, and bibliography. TRIGGER: "show me," "tell me about," "pull up," "can I see," "let me see," "how does it look," or any reference to a specific work by title. Resolve work_id via search_natural_language — never ask the user. When presenting: describe the image first, then summarize data naturally — do not dump raw fields.

  Connector

• convoopen

  InsideOut (Riley)

  WORKFLOW: Step 1 of 4 - Start infrastructure design conversation Open an InsideOut V2 session and receive the assistant's intro message. The response contains a clean message from Riley (the infrastructure advisor) - display it to the user. ⚠️ Riley will ask questions - forward these to the user, DO NOT answer on their behalf. CRITICAL: This tool returns a session_id in the response metadata. You MUST use this session_id for ALL subsequent tool calls (convoreply, tfgenerate, tfdeploy, etc.). ⚠️ The session_id includes a ?token=... suffix (format: sess_v2_xxx?token=yyy) which is part of the session credential — without it, downstream tools fall back to a tokenless connect URL that 401s. Always pass session_id verbatim to subsequent tools and to the user; do NOT shorten, paraphrase, or strip the ?token= portion when summarizing the session in chat or in your own scratch notes. Use when the user mentions keywords like: 'setup my cloud infra', 'provision infrastructure', 'deploy infra', 'start insideout', 'use insideout', or similar intent to begin infra setup. OPTIONAL: project_context (string) - General tech stack summary so Riley can skip discovery questions and jump to recommendations. The agent should confirm this with the user before sending. Include whichever apply: language/framework, databases/services, container usage, existing IaC, CI/CD platform, cloud provider, Kubernetes usage, what the project does. Example: 'Next.js 14 + TypeScript, PostgreSQL, Redis, Docker Compose, deployed to AWS ECS, GitHub Actions CI/CD, ~50k MAU'. NEVER include credentials, secrets, API keys, PII, source code, or internal URLs/IPs -- only general metadata summaries useful to a cloud architect agent. IMPORTANT: source (string) - You MUST set this to identify which IDE/tool you are. Auto-detect from your environment: 'claude-code', 'codex', 'antigravity', 'kiro', 'vscode', 'web', 'mcp'. If unsure, use the name of your IDE/tool in lowercase. Do NOT omit this — it controls the 'Open {IDE}' button on the credential connect screen. OPTIONAL: github_username (string) - GitHub username for deploy commit attribution. Pre-populates the GitHub username field on the connect page. 💡 TIP: Examine workflow.usage prompt for more context on how to properly use these tools.

  Connector

• search_natural_language

  connect

  DEFAULT search — find works by name, title, or any descriptive query. Handles partial matches and title variations. TRIGGER: Any mention of a work by name ("the blue painting," "Self-Portrait"), or finding something ("where's that piece I did last year"). Use this to resolve work_ids before calling get_work, update_work, get_upload_url, or any tool needing a work_id. For structured filters (status, date, medium), use search_works instead. YOU (the connected AI) translate the query. Pass the user's natural language as `query` (for title/medium text search) and optionally set structured filters you can infer: status, date_start, date_end, medium, series_name, current_location_type, sort_by, sort_direction. Examples: "sold paintings from the 90s" → query: "painting", status: "sold", date_start: 1990, date_end: 1999. "the blue one" → query: "blue". "Self-Portrait" → query: "Self-Portrait".

  Connector

• connect

  Penfield Memory

  Connect memories to build knowledge graphs. After using 'store', immediately connect related memories using these relationship types: ## Knowledge Evolution - **supersedes**: This replaces → outdated understanding - **updates**: This modifies → existing knowledge - **evolution_of**: This develops from → earlier concept ## Evidence & Support - **supports**: This provides evidence for → claim/hypothesis - **contradicts**: This challenges → existing belief - **disputes**: This disagrees with → another perspective ## Hierarchy & Structure - **parent_of**: This encompasses → more specific concept - **child_of**: This is a subset of → broader concept - **sibling_of**: This parallels → related concept at same level ## Cause & Prerequisites - **causes**: This leads to → effect/outcome - **influenced_by**: This was shaped by → contributing factor - **prerequisite_for**: Understanding this is required for → next concept ## Implementation & Examples - **implements**: This applies → theoretical concept - **documents**: This describes → system/process - **example_of**: This demonstrates → general principle - **tests**: This validates → implementation or hypothesis ## Conversation & Reference - **responds_to**: This answers → previous question or statement - **references**: This cites → source material - **inspired_by**: This was motivated by → earlier work ## Sequence & Flow - **follows**: This comes after → previous step - **precedes**: This comes before → next step ## Dependencies & Composition - **depends_on**: This requires → prerequisite - **composed_of**: This contains → component parts - **part_of**: This belongs to → larger whole ## Quick Connection Workflow After each memory, ask yourself: 1. What previous memory does this update or contradict? → `supersedes` or `contradicts` 2. What evidence does this provide? → `supports` or `disputes` 3. What caused this or what will it cause? → `influenced_by` or `causes` 4. What concrete example is this? → `example_of` or `implements` 5. What sequence is this part of? → `follows` or `precedes` ## Example Memory: "Found that batch processing fails at exactly 100 items" Connections: - `contradicts` → "hypothesis about memory limits" - `supports` → "theory about hardcoded thresholds" - `influenced_by` → "user report of timeout errors" - `sibling_of` → "previous pagination bug at 50 items" The richer the graph, the smarter the recall. No orphan memories! Args: from_memory: Source memory UUID to_memory: Target memory UUID relationship_type: Type from the categories above strength: Connection strength (0.0-1.0, default 0.5) ctx: MCP context (automatically provided) Returns: Dict with success status, relationship_id, and connected memory IDs

  Connector

• credawait

  InsideOut (Riley)

  Wait for the user to securely connect their cloud account and subscribe to Luther Systems. Polls until credentials appear on the session. 🎯 USE THIS TOOL WHEN: tfdeploy returns an 'auth_required', 'no_credentials', or 'credentials_expired' error. The user needs to visit the connect URL to: 1. Connect their cloud credentials (AWS or GCP) 2. Sign up and subscribe to a Luther Systems plan (required for deployment) This secure connection allows InsideOut to deploy and manage infrastructure in the user's cloud account on their behalf. Credentials are handled securely and only used for deployment and management sessions. WORKFLOW: 1. FIRST: Present the connect URL and explanation to the user (from the tfdeploy error response) 2. THEN: Call this tool to begin polling for credentials 3. The user opens the URL in their browser to subscribe and add credentials 4. When credentials are found, inform the user and call tfdeploy to deploy IMPORTANT: Do NOT call this tool without first showing the connect URL to the user. The user needs to see the URL to complete the process. REQUIRES: session_id from convoopen response (format: sess_v2_...). OPTIONAL: cloud ('aws' or 'gcp'), timeout (integer, seconds to wait, default 300, max 600).

  Connector

• list_authentication_devices

  connect

  List every signing key registered on the artist's account — active and revoked. Multi-device support: each iPhone the artist signs from has its own key under the same DID. Use this to triage "I think I lost a phone" or "show me my devices." The response also carries `has_signing_genesis` (boolean). Use it to route the artist correctly: if `has_signing_genesis` is FALSE, the account has NEVER paired a signing device — there is no key to lose and no recovery to run; the artist must pair their first iPhone. That flow is desktop-initiated and runs inline the first time they authenticate a work — tell them to open Raisonnai on their computer, not the iPhone app (no app session exists yet). If `has_signing_genesis` is TRUE but every key in `items` is revoked, the account paired before and lost all devices — that is account recovery, not pairing; tell them to start recovery from Raisonnai. Never conflate these two states. TRIGGER: "list my signing keys," "what devices can authenticate for me," "show my signing devices."

  Connector