feat(ai-workspace): add local relay profiles

2026-06-20 12:54:19 +03:00
parent 2d5fef3948
commit 3526351b1b
28 changed files with 2959 additions and 77 deletions
@@ -53,6 +53,49 @@ POST  /api/ai-workspace/assistant/v1/threads/:threadId/messages
 GET   /api/ai-workspace/assistant/v1/threads/:threadId/messages
 ```

+Assistant actions:
+
+```text
+POST /api/ai-workspace/assistant/v1/actions
+```
+
+This is the platform entrypoint for ontology-backed assistant tool calls. Natural-language chat dispatch still goes through the selected assistant model/executor first; `ontology-core` is the deterministic policy/action layer the assistant calls after it has interpreted the user's intent.
+
+Request shape:
+
+```json
+{
+  "phase": "preview",
+  "input": {
+    "actionId": "hub.user.block",
+    "targetUserId": "user_123",
+    "confirmed": true,
+    "idempotencyKey": "hub.user.block:user_admin:user_123"
+  }
+}
+```
+
+For write execution, first call `phase=preview`, show the returned `action.confirmation` to the user, then call `phase=execute` with `confirmationToken`. The final mutation still goes through the app-owned Launcher admin API guards; this service only routes the registered action.
+
+Launcher action gateway configuration:
+
+```text
+NDC_ONTOLOGY_LAUNCHER_BASE_URL=http://launcher.local.nodedc
+NDC_LAUNCHER_INTERNAL_ACCESS_TOKEN=...
+```
+
+If `NDC_LAUNCHER_INTERNAL_ACCESS_TOKEN` is not set, the service falls back to `NODEDC_INTERNAL_ACCESS_TOKEN`.
+
+The first HUB action ids exposed to assistants are:
+
+- `hub.user.read_admin_summary`
+- `hub.invite.list_pending`
+- `hub.access_request.list_pending`
+
+Read actions can be executed without user confirmation after the assistant has selected the structured action. Privileged/write actions still require explicit preview, user confirmation, and execute.
+
+App BFFs should pass active scope facts in action input (`clientId`, `coreAssistantRole`, `membershipRole`, `membershipStatus`) so policy stays data-driven instead of prompt-driven.
+
 Supported initial surfaces:

 - `engine`
@@ -71,6 +114,8 @@ Supported initial tool packs:

 Every dispatch builds an `ai-workspace.run-profile.v1` payload. The raw profile is sent only to the bridge worker; public API responses and run metadata keep MCP headers redacted.

+The canonical cross-surface execution contract is [AI Workspace Protocol v1](./docs/AI_WORKSPACE_PROTOCOL_V1.md). It defines layer ownership, run profile shape, tool manifests, worker boundaries, Hub boundaries, app adapter rules, and the migration path from the current scaffold.
+
 The worker uses `runProfile.toolProfile.mcpServers` to create an isolated per-run `CODEX_HOME/config.toml`. Install-time MCP config remains only as a legacy fallback when no dynamic profile is available.

 Runtime deploy readiness is tracked in [TEST_MATRIX.md](./TEST_MATRIX.md). The `smoke:run-profile` script covers the entitlement adapter to run profile contract and public secret redaction.