Problem
Roomote currently organizes work as individual tasks. Planning can create versioned Markdown artifacts and Build this can launch one task, but users cannot manage a long-running outcome as milestones with dependencies, isolated branches, acceptance criteria, project-level questions, consolidated controls, or cited project knowledge.
Current workaround
Users keep plans in artifacts or external trackers, launch and steer separate tasks manually, follow each PR independently, infer milestone progress, and repeatedly investigate Git, PRs, artifacts, and task history for project summaries.
Proposed behavior
Add a Roomote-native project layer with immutable plans and policies, milestones and executable items, user-configured integration branches, Manual/Guided/Full auto/Custom execution, project chat and controls, optional one-way GitHub Project V2 mirroring, and project-scoped cited lexical/semantic knowledge.
The web dashboard is the primary management surface. Roomote remains authoritative; existing tasks and workflows remain the execution layer.
Product constraints
- Keep Roomote agents as task-running workflows, not persisted Planner/Coder/Coordinator identities.
- Keep
tasks as executions and automation work_items as automation launch records.
- Task completion does not automatically equal item acceptance.
- Raw transcripts and secrets are excluded from durable knowledge by default.
- GitHub is initially an optional one-way mirror.
- Standard PostgreSQL remains functional without pgvector.
- Existing tasks, plan artifacts, follow-ups, cancellation, automations, and ordinary PR delivery remain compatible.
Delivery checklist
Manual project foundation
Coordination and automation
External planning mirror
Knowledge and planning intelligence
Release hardening
Completion criteria
- Users can create/configure projects, approve plans/policies, assign roles, and choose base/integration branches.
- Manual execution works end to end before autonomy is enabled.
- Guided and Full auto obey saved policy, question gates, bounded retries, and acceptance criteria.
- GitHub mirroring is optional and idempotent.
- Project RAG respects authorization/boundaries and returns citations.
- Historical-summary and legacy-repository planning scenarios pass end to end.
- Existing Roomote task behavior remains compatible.
Self-hosting implications
This adds PostgreSQL data and background processing. Lexical retrieval uses built-in PostgreSQL; embeddings use the current inference gateway. pgvector is optional acceleration and must be capability-detected. Storage, model usage, retention, backup, and deletion require documentation and telemetry.
Problem
Roomote currently organizes work as individual tasks. Planning can create versioned Markdown artifacts and Build this can launch one task, but users cannot manage a long-running outcome as milestones with dependencies, isolated branches, acceptance criteria, project-level questions, consolidated controls, or cited project knowledge.
Current workaround
Users keep plans in artifacts or external trackers, launch and steer separate tasks manually, follow each PR independently, infer milestone progress, and repeatedly investigate Git, PRs, artifacts, and task history for project summaries.
Proposed behavior
Add a Roomote-native project layer with immutable plans and policies, milestones and executable items, user-configured integration branches, Manual/Guided/Full auto/Custom execution, project chat and controls, optional one-way GitHub Project V2 mirroring, and project-scoped cited lexical/semantic knowledge.
The web dashboard is the primary management surface. Roomote remains authoritative; existing tasks and workflows remain the execution layer.
Product constraints
tasksas executions and automationwork_itemsas automation launch records.Delivery checklist
Manual project foundation
Coordination and automation
External planning mirror
Knowledge and planning intelligence
Release hardening
Completion criteria
Self-hosting implications
This adds PostgreSQL data and background processing. Lexical retrieval uses built-in PostgreSQL; embeddings use the current inference gateway. pgvector is optional acceleration and must be capability-detected. Storage, model usage, retention, backup, and deletion require documentation and telemetry.