Romyq · Public Roadmap
Roadmap
This roadmap is honest about the current state of the project. Each section is clearly labeled. Features are not presented as available until they are available.
Implemented
v0.10.3These features are available in the current release.
- Lifecycle generation8-stage lifecycle from mission definition to verified completion. Persists across sessions in .romyq/.
- Complexity profilesThree profiles: Basic (3 phases), Intermediate (5 phases), Advanced (7 phases). Selected at init.
- Project memoryPersistent state in .romyq/: task history, knowledge base, execution memory, rules, decisions, capabilities, lifecycle, and project constitution. Human-readable JSON and Markdown.
- Governance engineConstitution-based rule enforcement. Proposed tasks evaluated before execution. Violations trigger replanning.
- Readiness scoringWeighted aggregate of phase completion, capability coverage, done criteria, and governance state.
- Recommendation engineEmits Continue, Pause, Review, or Stop after every task. Re-evaluated after every operator command.
- TimelineChronological, append-only log of every phase transition, task outcome, and operator command.
- Operator shellInteractive REPL with built-in commands: status, roadmap, phase, readiness, recommendation, pause, resume, stop, rules, knowledge, dashboard. Free-text sends a steering instruction.
- Provider transparencyPlanning and execution providers are configurable independently. DeepSeek, Gemini, Claude, OpenAI-compatible.
- Multi-project supportMultiple projects managed from a single session. Each maintains independent state, memory, and rules.
- Decision logEvery governance decision recorded in .romyq/decisions.json. Human-readable. Diffable.
- Error recoveryLifecycle state preserved on failure. Resume from last checkpoint with romyq resume.
In Progress
activeWork underway in the current development cycle.
- DocumentationExpanding coverage of all commands, concepts, and lifecycle stages.
- Test coverageExpanding test suite beyond the current 1,555 tests.
Planned
v0.11Confirmed scope for the next minor release. Not yet implemented.
- Bounded improvement cyclesAllow multiple revision passes per task. Current implementation does a single pass then moves on.
- Structured lifecycle reviewsFormal review step at the boundary between phases. Currently phase transitions happen automatically.
- Enhanced visibility toolingBetter dashboard output and status reporting. The current dashboard is functional but limited in what it exposes.
- Improved provider coordinationBetter handling of planning provider failures and fallback behavior.
Research
exploringBeing evaluated. No timeline. Not committed.
- Checkpoint and rollbackAbility to snapshot lifecycle state at arbitrary points and restore. Architecture not yet decided.
- Better knowledge extractionMore accurate extraction of project facts from large codebases. Current approach works but has precision limits.
- Lifecycle templatingPre-defined lifecycle templates for common project types (REST API, CLI tool, library). Under consideration.
Potential
futureIdeas that may or may not ever happen. Not commitments.
- Desktop UIA graphical interface for the dashboard. Low priority. The terminal interface is the intended primary interface.
- Team workflowsMultiple operators contributing to a single lifecycle. Significant architecture work required. Not currently planned.
- Cloud-optional syncOptional sync of lifecycle state across machines. Explicitly not planned in the near term. Local-first is not a constraint we plan to relax.
Not Planned
out of scopeFeatures explicitly outside the scope of this project.
- SaaS or hosted offeringRomyq will not become a cloud service. This is a design principle, not a temporary constraint.
- Telemetry or analyticsNo usage data will ever be collected. The project has no server-side infrastructure to receive it.
- AI model fine-tuningRomyq orchestrates existing LLM providers. It does not train or fine-tune models.
- IDE pluginNot planned. The CLI interface is the intended interface. IDE integration would add maintenance burden without clear benefit.
Questions about the roadmap? Open a GitHub Discussion ↗ or contact us.