Detailed Roadmap
Uniph.ai — Detailed Roadmap
Last updated: January 2026
This document expands 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.mdordocs/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.mdand 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 | Short roadmap (shipped / in progress / next). | | ROADMAP_DETAILED.md | This document. | | STATUS.md | What’s working today; verification checklist. | | GET_APP_WORKING.md | Prerequisites and fix list when the app doesn’t work. | | FEATURE_CATALOG.md | Feature inventory by surface and API. | | API.md | REST API reference. | | NETLIFY_DEPLOY.md | Deploy frontend and backend to Netlify. |