# Existing platform review

Review window: 7–8 September 2026. Target: authenticated `platform.ankra.app` and the local `portal` source tree. All live inspection was read-only. The design contains fictional data instead of copied customer or account details.

## Coverage and evidence levels

| Evidence | Scope | What this does and does not establish |
| --- | --- | --- |
| Live application route manifest | 252 route patterns | Enumerates discoverable pages, including dynamic patterns; not every instantiated URL |
| Local source inventory | 221 TSX page modules read; 218 after excluding three framework modules | Imports, implementation references, labels, and UI components inventoried; local source differs from the deployed application |
| Combined page inventory | 253 route patterns | All mapped to a proposed screen or shared pattern in route-coverage.csv |
| Server-rendered structure | 172 concrete route requests: 170 HTTP 200, one 404, one 500 | Titles, headings, controls, and response structure; authenticated hydration, data loading, and all interaction states are not implied by HTTP 200 |
| Hydrated browser review | Dashboard, Applications, AI home, cluster overview, Security, Cost, Stacks | Real visible content and selected navigation inspected in the available account |
| Design validation | 170 generated frames | Browser rendering, layout checks, selected screenshot review, and the main linked walkthrough |

Parameterized routes without a safe known resource ID were covered through route/source inspection and shared patterns. No production resource was created, altered, deployed, deleted, or decommissioned to reveal a screen. Billing, permission, destructive-action, and authentication flows were not submitted. The selected cluster's Stacks page displayed a data-fetch error; its live populated state was not verified.

This is an all-route design audit, **not a claim that every page and every role-specific state was fully exercised in the live product**. Some current features appear only in the deployed route manifest and not the older local source. The CSV's `reviewMethod`, `localSource`, and `serverStatus` fields retain these distinctions. Raw live-page captures and source metadata stay in the original workspace and are excluded from the shareable ZIP.

## Findings and design responses

| Existing surface or use case | Design response | Representative frames |
| --- | --- | --- |
| Dashboard and AI entry points both summarize operational work | A single daily operating overview, with a dedicated Intelligence workspace and a human-decision inbox | overview, ai-home, inbox |
| AI chat, board, tasks, agents, goals, runs, schedules, alerts, conditions, usage, settings | Distinguish conversation, durable task, proposal, execution, and receipt; make boundaries visible | ai-chat, ai-board, task-detail, agents, agent-detail, agent-run-detail, automations, ai-usage |
| Cluster context and nested Kubernetes pages | Persistent scope in the shell; stable local tabs and shared resource/detail patterns | clusters, cluster-overview, resources, resource-detail, pod-detail, node-detail |
| GitHub-connected applications and delivery | Make source → detection → proposed configuration → build → release → deploy explicit | app-create, applications, app-overview, app-deploy, app-settings |
| Preview/demo environments and shared profiles | Expose environment lifetime, inputs, version, owner, cost expectations, and cleanup | preview-config, preview-detail, stack-profiles, profile-detail |
| Add-ons, Helm charts, manifests, drafts, dependency graphs, deploy waves | Consolidate Stacks & catalog; preserve expert composition and reviewable deployment ordering | stacks, stack-builder, stack-review, catalog, catalog-detail, registries |
| Imported, managed, cloud, self-managed, and playground clusters | Shared creation shell with provider-specific capability/configuration contracts | cluster-create, cluster-configure, cluster-import, node-groups, mesh |
| Metrics, logs, events, operations, troubleshooting | Consistent entity/time scope, source freshness, and a contextual investigation entry | metrics, logs, events, operations, operation-detail, ai-investigation |
| Security findings, occurrences, coverage, SBOM, policies, exposure, compliance | Prioritize actionable risk while preserving unique-finding versus occurrence semantics and stale/unknown states | security, security-findings, security-finding, security-sbom, security-policies, security-network, compliance |
| Cost forecasts, allocation, comparisons, savings, source/provider credentials | Label forecasts and estimates; reveal price source and allocation gaps before proposing changes | cost, cost-clusters, cost-workloads, cost-compare, cost-savings, cost-providers |
| Organization settings, access, credentials, activity, billing, support | Stable administrative destination with explicit roles, secret handling, auditability, and recovery | org-settings, members, roles, credentials, audit-log, billing, support |
| MFA, passkeys/authentication, tokens, profile, notification integrations | Separate personal access from organization policy and agent credentials | sign-in, mfa-challenge, authentication, profile, tokens, integrations |

The navigation proposal is an inference from the reviewed workflows. It is not an existing product decision or a requirement to change the backend route structure.

## Capabilities that must survive migration

### AI and automation

Retain task ownership, priority, evidence, agent goals, schedules, tool/skill availability, per-run history, permissions, budgets, model/provider selection, workspace context, memory, repository/runbook context, feedback, usage, autonomy, webhooks, MCP connections, Slack, and Teams. Integrations remain scoped and revocable. A connection does not itself authorize writes.

### Applications and composition

Retain GitHub installation/setup, repository and branch selection, code detection, generated configuration or proposed PRs, builds, images/containers, releases, deployment drafts, secret bindings, preview/demo configuration, lifetime, and status. Preserve chart repositories, exclusions, profile versions and inputs, persisted drafts, manual YAML editing, parent dependencies, readiness gates, and ordered waves.

### Infrastructure and Kubernetes

Do not flatten provider-specific capabilities into an identical wizard. Retain imported versus managed distinctions, control-plane/worker groups, VMs, cloud credentials, regions/zones, node operations, mesh configuration, resource namespaces, workload kinds, storage, networking, configuration, Helm releases, resource events, logs, RBAC, audit, and connection health. Unavailable capabilities explain why they are unavailable.

### Security and cost

Retain finding occurrence counts, unique findings, severity, fixability, coverage, freshness, image/package identity, SBOM detail, policy exceptions and expiry, network exposure, compliance evidence and reporting. Cost requires provider pricing provenance, freshness, estimated versus actual values, projection assumptions, workload and cluster allocation, comparisons, and savings validation. The board's example amounts are not pricing advice or measured savings.

### Administration

Retain organization switching, memberships, invitations, roles/groups, service tokens, credential ownership, encryption configuration, backups, DNS/Cloudflare, pipelines, variables, plan and invoices, account profile, authentication/MFA/passkeys, personal API tokens, notifications, support tickets, onboarding, and permission-aware error states.

## Decisions to validate with product owners

1. Should Overview replace both current dashboard summaries, while AI home becomes the durable work hub?
2. What is the canonical relationship between a condition, an alert, an insight, a task, and an incident? The proposal links them without making them interchangeable.
3. Which production actions are eligible for policy-approved automation, and which always require a human?
4. Which provider-specific cluster capabilities must remain in the first release of the new shell?
5. Which role can approve a plan, expand a budget, create a credential, or change an autonomy policy? The example permission names are illustrative, not a substitute for the current backend contract.
6. What accessibility, localization, desktop/mobile, and enterprise-account requirements need explicit acceptance tests?

## Remaining validation

Before implementation sign-off, exercise populated dynamic pages with safe fixture data, alternate organization roles, restricted subscription states, large tables, long resource names, partial outages, expired plans, and real provider failures. Review provider-specific forms and high-impact settings with their owners. Conduct task-based usability tests with platform engineers, application developers, and organization administrators. Complete a real Figma import check before publishing the library to a team.
