Integrate Project/Wiki through the T3 internal MCP (umbrella)

[LanicBlue]

Purpose

Umbrella tracker for integrating the standalone Project/Wiki Services into T3 through the existing T3-owned internal MCP server.

Implementation is split into focused issues below. Keep this issue open until the cross-repository integration is usable end to end.

Core boundary

Services authenticate and authorize Clients. T3 owns the Agents, Sessions, workspaces, internal routing, and Agent-level delegation inside its authenticated Clients.

Project Service
  authenticated T3 Project Client
    -> ProjectConsumerRuntime -> structured Work notice
       -> T3 resolves Agent + Project -> current Session
    <- T3 internal MCP -> Project SDK

Wiki Service
  authenticated T3 Wiki Client
    <- T3 internal MCP -> Agent subtree projection -> Wiki SDK

Service credentials remain in T3 server integrations. Agents/providers never receive raw credentials or direct authenticated Service HTTP instructions.

Identity model

Keep four concepts separate:

Service Client
  authenticated T3 identity toward Project/Wiki Service

Logical Agent
  stable Agent identity inside the T3 Client

Provider Instance
  concrete provider/account/runtime configuration

Session/Thread
  T3 runtime conversation selected/created by Client-owned routing

Stable IDs and display names travel together:

agentId + agentName
projectId + projectName

• IDs are authoritative for identity, routing, assignment, persistence, fencing, and subtree selection.
• Names are mutable display metadata, may collide, and never participate in authorization or idempotency.
• Renaming an Agent/Project does not change executorRef, Wiki subtree, Work association, or Session mapping.

Project identity and API rule

Project Service derives the Client half from the verified credential:

authenticatedClientId + agentId -> server-derived executorRef

T3/Agent cannot choose a different Client identity. Agent-facing MCP tools do not accept clientId, consumerId, agentId, projectId, or executorRef; T3 resolves Agent/Project from the trusted Session and adds them to the SDK request.

Project Service remains unaware of T3 Session/Thread/provider/workspace identity.

Service-side work:

• https://github.com/LanicBlue/project-service/issues/14
• https://github.com/LanicBlue/project-service/issues/15
• Stable SDK/artifact gate: https://github.com/LanicBlue/project-service/issues/12

T3 must wait for the supported Service API/SDK surface rather than importing Service internals or treating local unpublished work as stable.

Project Work delivery rule

Project Service sends a structured, versioned notice only to the authenticated Client that owns the target Agent. The notice identifies:

• agentId + agentName;
• projectId + projectName;
• Work/position/run IDs and revision fences;
• deterministic noticeId;
• optional prompt/summary facts.

T3 owns delivery inside the Client:

• map agentId + projectId to one current Session;
• create a Session when none exists;
• coalesce notices while the Session is busy;
• after the Turn, query authoritative assigned/open Work and send one aggregate notification;
• use Project MCP tools for details/submission;
• preserve Sessions when Service credentials fail.

ACK is a Client delivery fact, not Work completion or proof that an Agent is running.

Wiki rule

Wiki Service authenticates only the T3 Wiki Client and remains unaware of Agents/Sessions.

T3 v1 maps each Agent to a default subtree derived from stable agentId, confines relative paths/references before SDK calls, and derives read/write capability from trusted MCP context. Future custom subtree/read-only/shared-area UI remains T3-owned.

Internal MCP rule

Reuse the existing t3-code MCP seam.

Independent capability scopes include Browser preview, Project read/write, and Wiki read/write. Disabling Browser access must not disable Project/Wiki.

Supported in this phase:

• Codex;
• Claude;
• Cursor;
• Grok;
• locally managed OpenCode.

Externally managed OpenCode server mode is intentionally skipped until upstream or this fork supports safe T3 MCP attachment.

Split implementation issues

• Add Service Client and Logical Agent settings #5 — Service Client settings, secrets, Logical Agents, Project bindings, Settings UI
• Extend the internal MCP with trusted Project/Wiki capabilities #3 — trusted internal MCP context, capabilities, Project/Wiki tool providers
• Route Project Work notices into Agent sessions with coalescing #4 — Project Consumer integration, Session routing, coalesced Work notifications
• Project Wiki subtrees through Agent-scoped internal MCP #2 — Wiki Agent subtree projection and confinement

Cross-repository acceptance

• Project Service prevents an authenticated Client from representing another Client's Agent.
• Project Service publishes the stable SDK/protocol surfaces required by T3.
• T3 stores one Project Client and one Wiki Client per environment with server-only credentials.
• T3 exposes Project/Wiki through the existing internal MCP without service-specific provider adapter code.
• Agent tool inputs cannot select security/routing identity.
• Project Work notices create/route/coalesce into the correct current Session.
• Wiki Agent access stays inside the Agent's T3-projected subtree.
• Credential failures are visible but do not delete Sessions.
• Names remain display-only and ID changes are never implied by renames.
• Tests cover cross-Client spoofing, MCP identity spoofing, notice replay/coalescing, and Wiki subtree escape.

Non-goals

• Do not expose Project/Wiki Services directly as Agent-facing MCP servers.
• Do not put Service credentials in prompts, provider-visible environment, or tool arguments.
• Do not move Project workflow/Flow/Work/Gate/Review into T3.
• Do not make Project Service know T3 Sessions.
• Do not make Wiki Service know T3 Agents/Sessions.
• Do not add a universal cross-service IAM model.
• Do not implement advanced Wiki subtree permission UI in v1.