Skip to main content

Design Docs

Design docs explain why Routa is shaped the way it is. Read this section when product behavior, system boundaries, or long-lived invariants matter more than install steps.

If you are still trying to get Routa running, go back to Quick Start, Platforms, or Use Routa.

Choose A Reading Path

What You Get From This Section

Boundaries

System Shape

Learn which responsibilities belong to the web app, desktop runtime, server, and ACP layer.

Product Model

Core Concepts That Matter

Understand workspaces, repositories, providers, Sessions, Kanban, and Team as durable product objects.

Decision History

Why It Works This Way

Use ADRs and redesign notes when a change would otherwise fight an intentional system decision.

Focused Design Material

Use these when you already know the main product model and need a narrower topic:

Legacy Specs And Migration Status

Historical design material still exists under .kiro/specs/, but it is not automatically canonical. Keep using this page as the curated entry point instead of treating the raw archive as the source of truth.

Legacy Specs Inventory
Legacy SpecScopeCurrent Handling
.kiro/specs/docker-agent-execution/design.mdDocker-backed ACP agent execution architectureindexed only
.kiro/specs/docker-agent-execution/requirements.mdDocker agent execution requirementsindexed only
.kiro/specs/docker-agent-execution/tasks.mdDocker agent execution task breakdownindexed only
.kiro/specs/kanban-workspace-repository/requirements.mdWorkspace repository requirements for Kanbanindexed only
.kiro/specs/playwright-page-snapshots/requirements.mdPage snapshot requirementsindexed only
.kiro/specs/workspace-centric-redesign/design.mdWorkspace-first redesign architectureindexed only
.kiro/specs/workspace-centric-redesign/requirements.mdWorkspace-first redesign requirementsindexed only
.kiro/specs/workspace-centric-redesign/tasks.mdWorkspace-first redesign task breakdownindexed only

Curation Rules

  • Migrate only reviewed, still-relevant knowledge from .kiro/specs/.
  • Do not copy large historical specs verbatim into docs/ unless they are being actively normalized.
  • When a legacy spec becomes canonical, create a focused document here and link back to the source in a short provenance note.
  • Prefer one canonical document plus pointers over parallel copies with drift.