mosaicstack/stack
1
0
Fork 0
Code Issues 43 Pull Requests Actions Packages Projects Releases 15 Wiki Activity

docs(#744): complete Tess API contracts
All checks were successful
ci/woodpecker/pr/ci Pipeline was successful
Details

Browse Source
This commit is contained in:
Jarvis
2026-07-13 11:30:26 -05:00
parent 470eb911c0
commit c9f69300a3
3 changed files with 232 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/tess/ADMIN-GUIDE.md
View File

@@ -1,3 +1,5 @@
# Tess Administration
Provision authenticated users, configured agent identities, providers, and approved channel bindings. Never expose service credentials in status or logs. Use health/readiness and provider status endpoints for recovery diagnostics; privileged termination remains approval-bound and auditable.
Configure agent/provider identities outside client input. Verify `/health/ready` and provider health before enabling interaction clients. Every interaction request requires an authenticated actor and correlation header; tenant and owner scope are server-derived. Do not log or return service credentials.
For an incident, preserve correlation IDs, inspect provider status and durable checkpoint/inbox/outbox state, then use the recovery endpoint. Do not retry an ambiguous external effect automatically. Stop operations require an exact one-time approval reference; provisioning or granting a broad admin capability does not replace that check.

4
docs/tess/USER-GUIDE.md
View File

@@ -1,3 +1,5 @@
# Tess User Guide
Use authenticated interaction endpoints with an `X-Correlation-Id`. List sessions, attach, send, and recover only sessions visible to your server-derived tenant scope. Stop requires a durable exact-action approval. Mos handoffs are submitted through `/api/coord/mos/handoff` and can be observed or read by receipt ID.
All HTTP interaction calls require authenticated session credentials and `X-Correlation-Id`. Use `GET /api/interaction/{agentName}/sessions?provider=...` to list only visible runtime sessions, then enroll with `POST .../sessions/{sessionId}/enroll` body `{providerId,runtimeSessionId}`. Attach uses `{mode:"read"}`; send uses `{content,idempotencyKey}`. Stop requires `{approvalRef}` and fails with 403 without the exact durable approval. Recovery only requeues interrupted durable work.
Memory is user-scoped: preferences support list/get/upsert/delete; insights support list/get/create/delete; search body is `{query,limit?,maxDistance?}`. Mos work is handed off with `POST /api/coord/mos/handoff`; observe and result use the returned handoff ID.