Parent and architecture

• Implementation epic: #6
• Accepted architecture decision: #1
• Depends on: SESSION-02 #21, SESSION-04 #23, SESSION-06 #25

Outcome

Expose a frontend-neutral, tenant-authorized session listing/history API that can support a Codex/Hermes-style web UI without scanning tenant payloads.

Estimate

• 8 SP / 5 engineering days
• Risk: medium

Scope

• Add authenticated application/API operations to:
  • create a session;
  • bind/switch an authorized frontend;
  • list active sessions by owner/recent activity;
  • list archived sessions;
  • open session metadata;
  • page ordered canonical events;
  • page runs for a session;
  • archive and unarchive.
• Return bounded display metadata: title, preview, creation time, last activity, status, frontend origin, provider/harness observations and current run state.
• Use fixed-fan-out owner/status activity indexes and opaque continuation tokens.
• Resolve event payload references only after tenant/participant authorization.
• Add a synthetic second-frontend adapter used by integration/E2E tests.
• Keep Telegram commands on the same application operations rather than a parallel session implementation.
• Document API authorization, pagination, consistency and error contracts.
• Add admin-safe metadata views without granting ordinary workers tenant-wide listing rights.

Non-goals

• Production web frontend.
• Full-text/semantic search.
• Cross-tenant admin payload search.
• Shared/group session product UX beyond participant authorization contracts.

Verification

• Active and archived lists paginate in deterministic recent-activity order across fixed buckets.
• Continuation tokens cannot be replayed for another tenant/owner/status.
• Event pages preserve strict event order and never return another tenant's payload.
• Archive/unarchive updates lists without deleting history.
• Telegram and the synthetic frontend open the same authorized canonical session.
• No hot API path performs a full-table scan.

Acceptance criteria

• The API supports the required future session UI without exposing storage implementation details.
• Every read is tenant and participant scoped.
• Listing complexity is bounded by configured index fan-out and page size.
• Archived sessions remain openable and unarchivable.
• Provider/harness metadata is clearly execution observation, not session identity.