# Uniph.ai — Detailed Roadmap

Last updated: January 2026

This document expands [ROADMAP.md](ROADMAP.md) with concrete deliverables, API/UI touchpoints, dependencies, and acceptance criteria. Use it for sprint planning and alignment.

---

## Guiding Principle

Uniph.ai is an **objective-first AI life orchestration platform**: autonomous by default, governed at risk boundaries, and measured by outcome quality.

---

## Part 1 — Shipped (Verified)

What is implemented and reachable in the current codebase.

### 1.1 Core LifeOS

| Area | Backend | Frontend / UX |
|------|---------|----------------|
| **Users** | `POST /api/users/sync`, `GET /api/users/me`; Prisma `User` | Session via NextAuth; sync on dashboard load |
| **Goals** | `GET/POST/PATCH/DELETE /api/goals`, `/api/goals/categories`; legacy + `/api/runtime/goals` (CRUD, reorder, archive, tree) | `/dashboard` (runtime goals), `/goals/[id]` (legacy fetch), GoalEditor |
| **Tasks** | `GET/POST/PATCH/DELETE /api/tasks` | `/goals/[id]` via TaskListClient |
| **Integrations** | `GET/POST /api/integrations` | Settings surfaces, orchestrate flow |
| **Infer** | `POST /api/infer/chat`, `/api/infer/goals` | Dashboard chat, goal suggestions |

**Key files:** `backend/src/routes/{users,goals,tasks,integrations,infer}.ts`, `frontend/src/app/dashboard/`, `frontend/src/app/goals/[id]/`.

---

### 1.2 Collaboration (Internal Execution Context)

| Area | Backend | Frontend / UX |
|------|---------|----------------|
| **Workspaces** | `GET/POST/PATCH /api/workspaces`, summary/questions/context | `/workspaces` redirects to `/dashboard`; workspace concepts used internally |
| **Contributions** | `GET/POST /api/contributions`, per-workspace | Used by agents and trace, not primary user UI |
| **Runs** | `GET/POST /api/workspaces/:id/runs`, `GET /api/runs/:id` | Mission-control / trace |
| **Events** | Agent eventing in runner | Logged; trace endpoints |
| **Outcomes** | `/api/runtime/outcomes` (list, get, progress SSE, action) | `/dashboard`, `/outcome/[id]` |

**Key files:** `backend/src/routes/workspaces.ts`, `contributions.ts`, `runs.ts`, `backend/src/routes/v2/outcomes.ts`, `frontend/src/app/outcome/[id]/`.

---

### 1.3 Agent Management & Identity

| Area | Backend | Frontend / UX |
|------|---------|----------------|
| **Registration / API keys** | `GET/POST /api/agents`, key auth | Settings → Agents |
| **Workspace permissions** | WorkspaceAgent, posting permissions | Backend-enforced |
| **Identity lifecycle** | Create/list/update identity; connect/callback/refresh/revoke; audit list | `/settings/agents` (connect, refresh, revoke, audits) |
| **Identity health** | `GET /api/agents/:id/identity/health` | Reconnect prompts in UI |

**Key files:** `backend/src/routes/agents.ts`, `frontend/src/app/settings/agents/`.

---

### 1.4 Governance & Execution

| Area | Backend | Frontend / UX |
|------|---------|----------------|
| **Contracts** | Version, compose, validator | Mission-control, evaluation |
| **Policy** | Create/list/evaluate; approval decisions | Mission-control Approval Inbox |
| **Action jobs** | Queue, list, retry, trace | Execution trace surfaces |
| **Trace** | `GET /api/execution/trace?workspaceId=...` | Deep trace when needed |

**Key files:** `backend/src/routes/{contracts,governance,execution}.ts`, `frontend/src/app/mission-control/`.

---

### 1.5 Memory

| Area | Backend | Frontend / UX |
|------|---------|----------------|
| **CRUD** | `GET/POST /api/memory`, `GET/DELETE /api/memory/:id` | `/settings/memory` |
| **Recall** | `POST /api/memory/recall` | Settings, agent use |
| **Stats** | `GET /api/memory/stats` | Memory settings UI |
| **Compact / retention / purge** | `POST /api/memory/compact`, `/retention`, `/purge` | Settings memory actions |

**Key files:** `backend/src/routes/memory.ts`, `frontend/src/app/settings/memory/`.

---

### 1.6 Friction-First Onboarding & KPIs

| Area | Backend | Frontend / UX |
|------|---------|----------------|
| **Ambient start** | `POST /api/orchestrate/start` | Dashboard auto-kickoff when no goals |
| **Friction metrics** | `GET /api/evaluation/friction` | Mission-control |
| **Onboarding harness** | `GET /api/evaluation/harness/onboarding-scenarios` | Evaluation UX |
| **SLO** | `GET /api/evaluation/slo` | Mission-control |

**Key files:** `backend/src/routes/orchestrate.ts`, `evaluation.ts`, `frontend/src/app/mission-control/`, `dashboard/page.tsx`.

---

### 1.7 Channels

| Adapter | Backend | Purpose |
|---------|---------|--------|
| **Slack** | `POST /api/slack/events` | Events, task/status/goals |
| **Discord** | `POST /api/discord/interactions` | Slash commands |
| **Email** | Inbound + digest | Inbound-to-task, digest |

**Key files:** `backend/src/channels/{slack,discord,email}.ts`.

---

### 1.8 Runtime API (Intent → Outcome)

| Area | Backend | Frontend / UX |
|------|---------|----------------|
| **Intent** | `POST /api/runtime/intent` | Dashboard submit |
| **Outcomes** | List, get, progress SSE, action | Dashboard cards, `/outcome/[id]` |
| **Intents CRUD** | `GET/PATCH/DELETE /api/runtime/intents` | Dashboard intent history |
| **Suggestions** | `GET /api/runtime/suggestions`, dismiss, interact | Dashboard pills/suggestions |
| **Goals (runtime)** | Full CRUD, reorder, archive, tree | Dashboard goals list, GoalEditor |
| **User input requests** | `GET /api/runtime/user-input-requests`, respond | Surfaces when execution needs input |
| **Workflows** | List, types, execute, executions | n8n integration |
| **Webhooks** | n8n trigger/progress/complete/error, config, executions | Backend ↔ n8n |

**Key files:** `backend/src/routes/runtime/index.ts`, `backend/src/routes/v2/*`, `frontend/src/app/dashboard/SimpleDashboardClient.tsx`.

---

### 1.9 Continuous Self-Improvement Baseline

| Area | Backend | Frontend / UX |
|------|---------|----------------|
| **Feedback signals** | `POST /api/evaluation/signals`, summary | Mission-control Improve panel |
| **Regression summaries** | Evaluation + runner | Improve panel |
| **Release gate check** | `GET /api/evaluation/release-gates`, `POST .../release-gates/check` | Mission-control Release Guardrails |
| **Improvement pulse** | `runImprovementPulse()` in runner (env-driven interval) | Mission-control Improve (runtime status) |
| **Credential friction** | Checkpoints + improvement pulse regressions | Mission-control metrics |

**Key files:** `backend/src/agents/runner.ts`, `backend/src/routes/evaluation.ts`, `frontend/src/app/mission-control/MissionControlClient.tsx`.

---

### 1.10 Deployment & Docs

| Area | Location |
|------|----------|
| **Netlify (both apps)** | `docs/NETLIFY_DEPLOY.md`, `frontend/netlify.toml`, `backend/netlify.toml`, `backend/netlify/functions/server.mjs` |
| **Get app working** | `docs/GET_APP_WORKING.md` |
| **In-app docs** | `/docs`, `frontend/public/docs/`, `frontend/src/app/docs/config.ts` |

---

## Part 2 — In Progress (Detailed)

### 2.1 Agent Identity OAuth Completion

**Current state**

- Token exchange (Google/Microsoft) and refresh endpoint exist: `POST .../auth/connect`, `POST .../auth/refresh`.
- Identity health endpoint and reconnect prompts in UI are live.
- Encrypted storage for identity tokens; audit log.

**Deliverables**

| # | Task | Owner notes | Done |
|---|------|-------------|------|
| 1 | **Provider-native refresh lifecycle** | Auto-refresh before expiry in backend job or on next use; handle refresh_token rotation (Google/Microsoft). | |
| 2 | **Hardened revoke** | On revoke, clear tokens and optionally notify provider; idempotent revoke. | |
| 3 | **Disconnect semantics** | Clear distinction between “revoke at provider” vs “disconnect locally”; document in API. | |
| 4 | **Reconnect UX** | Health-based prompts already exist; add in-app “Reconnect” flow that opens provider OAuth and updates identity. | |
| 5 | **Docs** | Identity lifecycle, callback URLs, and recovery flows in `docs/API.md` and/or dedicated identity doc. | |

**Dependencies:** OAuth provider limits (rate, consent); env vars for client id/secret per provider.

**Acceptance criteria**

- Tokens refresh automatically when used near expiry (or via scheduled job).
- Revoke and disconnect behavior documented and consistent.
- Reconnect from UI completes without manual API calls.
- Docs describe callback URLs and recovery for Google/Microsoft.

---

### 2.2 Memory Quality & Lifecycle

**Current state**

- CRUD, recall, stats, compact, retention, purge implemented.
- Confirmation token for destructive actions; retention/compaction can be run manually or scheduled.

**Deliverables**

| # | Task | Owner notes | Done |
|---|------|-------------|------|
| 1 | **Recall precision** | Improve recall (e.g. semantic or relevance scoring) to reduce stale/irrelevant results. | |
| 2 | **Stale-memory suppression** | Policy or scoring to deprioritize or hide very old/low-importance entries in recall. | |
| 3 | **Scheduled compaction/retention** | Runner or cron to run compaction and retention on a schedule; configurable interval. | |
| 4 | **Destructive workflow UX** | Purge/delete flows in `/settings/memory` with clear confirmation and optional undo window. | |
| 5 | **Edit/forget** | Edit memory entry content; “forget” (soft delete or flag) with confirmation. | |

**Dependencies:** Memory schema (e.g. importance, lastUsed); evaluation baselines for recall quality.

**Acceptance criteria**

- Recall returns more relevant results; stale entries are suppressed or ranked lower.
- Compaction and retention run on a defined schedule.
- Destructive actions in UI require explicit confirmation and are documented.
- Users can edit and “forget” memory entries from settings.

---

### 2.3 API & Integration DX Hardening

**Current state**

- Runtime API under `/api/runtime/*`; legacy routes under `/api/goals`, `/api/tasks`, etc. Docs exist but are scattered.

**Deliverables**

| # | Task | Owner notes | Done |
|---|------|-------------|------|
| 1 | **Entry-path doc** | Single “API entry points” section: orchestration (orchestrate, runtime intent/outcomes), governance, memory, agents/identity, channels. | |
| 2 | **Identity lifecycle in docs** | Reconnect, refresh, revoke, callback URLs, recovery. | |
| 3 | **OpenAPI or structured spec** | Optional: generate or maintain OpenAPI for core routes for external integrators. | |
| 4 | **Time-to-first-outcome** | Reduce setup steps (e.g. guided “connect one integration” from dashboard; pre-filled templates). | |

**Dependencies:** No code dependency; doc and UX effort.

**Acceptance criteria**

- One place (e.g. `docs/API.md` or `docs/API_ENTRY_POINTS.md`) lists core entry paths by use case.
- Identity lifecycle and recovery are documented.
- New integrators can reach “first outcome” with fewer manual steps (measured or qualitative).

---

### 2.4 Mission-Control & Evaluation UX

**Current state**

- Mission-control page: metrics, Intent Composer, Approval Inbox, Execution Summary, SLO, Memory Maintenance, Friction, Onboarding Harness, Improve (regressions, experiments, release posture, credential friction, pulse), Release Guardrails.
- Improve panel has feedback buttons and runtime pulse info.

**Deliverables**

| # | Task | Owner notes | Done |
|---|------|-------------|------|
| 1 | **Summaries over trace** | Default view: high-level outcomes and risk state; “View trace” or link for deep trace. | |
| 2 | **Approvals-only framing** | Copy and layout emphasize “approve only when needed”; reduce noise from non-approval items. | |
| 3 | **Harness usability** | Onboarding/evaluation harness easier to run and interpret (e.g. one-click “Run harness”, clear pass/fail). | |
| 4 | **Deep trace access** | Keep link/route to full trace for audits and debugging; no removal of trace endpoints. | |

**Dependencies:** Backend already exposes trace and metrics; frontend layout and copy.

**Acceptance criteria**

- Mission-control default view is summary-first; trace is one click away.
- Approval-focused messaging is clear; operators know when to approve.
- Harness can be run and results understood quickly.
- Trace remains available for audits.

---

### 2.5 Release Reliability Gates

**Current state**

- `GET /api/evaluation/release-gates`, `POST /api/evaluation/release-gates/check`; improvement pulse runs on schedule; gates (friction, reliability, feedback health, chat persistence) evaluated.

**Deliverables**

| # | Task | Owner notes | Done |
|---|------|-------------|------|
| 1 | **Env & migration verification** | Pre-deploy or deploy-time check: required env set, DB migrations applied (or fail deploy). | |
| 2 | **Smoke gates** | Automated smoke tests (e.g. health, auth, one critical path) that can block or warn on deploy. | |
| 3 | **Rollback guardrails** | Document or automate: when to rollback, how to rollback (Netlify rollback, DB considerations). | |
| 4 | **CI/CD enforcement** | Run release-gate check (or smoke) in CI; block merge or deploy if gates fail (configurable). | |
| 5 | **Operational dashboards** | Optional: dedicated dashboard or panel for gate history and deploy status. | |

**Dependencies:** CI/CD (e.g. Netlify, GitHub Actions); optional monitoring.

**Acceptance criteria**

- Deploy verifies env and migrations where possible.
- At least one automated smoke path runs on deploy or in CI.
- Rollback process is documented (and optionally automated).
- Release gates or smoke can block deploy when configured.

---

## Part 3 — Next (Ordered, with Detail)

### 3.1 Complete Provider-Native Identity OAuth (Google/Microsoft)

- Finish refresh lifecycle (see 2.1).
- Test with real refresh_token rotation and expiry.
- Document and support Apple if desired (calendar limitations noted in past).

---

### 3.2 Memory Quality Controls + Evaluation Baselines

- Edit/forget, recall precision, stale suppression (see 2.2).
- Define evaluation baselines (e.g. recall@k, user feedback) and wire to evaluation pipeline.

---

### 3.3 Finalize API DX Pass

- Entry-path doc, identity lifecycle doc, optional OpenAPI (see 2.3).
- Align `docs/API.md` and in-app docs with actual routes.

---

### 3.4 Clearer Mission-Control Summaries

- Summary-first, approvals-only framing (see 2.4).
- Optional: export or share summary for ops reviews.

---

### 3.5 Enforce Release Gates in CI/CD

- Smoke and gate checks in CI; block or warn on failure (see 2.5).
- Netlify deploy hooks or GitHub Actions as needed.

---

### 3.6 Security & Data Governance

| # | Task | Notes |
|---|------|--------|
| 1 | **Retention policy** | Configurable retention for memory and audit data; enforce in retention job. |
| 2 | **PII policy** | Document what PII is stored; optional masking in logs and trace. |
| 3 | **Export** | User data export (e.g. goals, tasks, memory) in a portable format. |
| 4 | **Delete** | Account or scope delete: remove or anonymize user data; comply with policy. |

---

## Part 4 — Later Expansion Tracks

- **Model routing:** Cost and reliability optimization; tier-based routing (fast/balanced/reasoning).
- **Governance:** Richer policy authoring; approval workflows and delegation.
- **Mission-control analytics:** Deeper scenario harnesses; trend views and alerts.
- **Integrations:** More adapters (e.g. Notion, Linear); ecosystem recipes and templates.

---

## Part 5 — Success Signals

- Lower time-to-first-outcome and fewer required user actions.
- Higher autonomous resolution rate without trust regressions.
- Improved memory precision and lower stale recall rate.
- Higher API onboarding completion and faster adapter activation.
- Fewer deployment regressions and faster recovery when failures occur.

---

## Doc Cross-Reference

| Doc | Purpose |
|-----|--------|
| [ROADMAP.md](ROADMAP.md) | Short roadmap (shipped / in progress / next). |
| [ROADMAP_DETAILED.md](ROADMAP_DETAILED.md) | This document. |
| [STATUS.md](STATUS.md) | What’s working today; verification checklist. |
| [GET_APP_WORKING.md](GET_APP_WORKING.md) | Prerequisites and fix list when the app doesn’t work. |
| [FEATURE_CATALOG.md](FEATURE_CATALOG.md) | Feature inventory by surface and API. |
| [API.md](API.md) | REST API reference. |
| [NETLIFY_DEPLOY.md](NETLIFY_DEPLOY.md) | Deploy frontend and backend to Netlify. |