Roadmap

Purpose

This roadmap tracks the engineering work needed to make the ecosystem more reliable, observable, reproducible, and easier to evaluate. It is updated as the lab evolves. The source of input for the roadmap is the audit findings (Audit Model) and the failure catalog (Failure Catalog).

The roadmap is a living document. It is updated when:

• An audit surfaces a new finding.
• A failure mode becomes common.
• A new capability is added.
• An ADR is accepted.

Status Legend

Each item has a status:

Near Term (Next Iteration)

The work to be done in the next iteration. These items are unblocked and ready to start.

• Normalize tools.json against the current tool inventory.
• Add automated health checks for the core CLI tools.
• Add minimal tests to tools that still depend on manual verification.
• Create an executable dependency audit for the tooling layer.
• Refresh diagrams and examples from the current system state.
• Capture lessons learned beside the relevant case studies.
• Resolve all Critical and High findings from the last monthly audit.
• Wire the research framework's request journal into the audit report generator.
• Add a media-lab-server health check to the weekly script.
• Document the four comandos_terminal/ cheatsheets in a discoverable index.

Medium Term (Next 3-6 Months)

The work to be done in the next 3-6 months. These items are scoped but may need additional design.

• Turn audit findings into tracked implementation tasks.
• Run evaluation passes against representative research workflows.
• Improve artifact traceability across research phases, reports, and summaries.
• Add observability for worker lifecycle, queue state, and failed jobs.
• Define runtime boundaries between Coordinator, worker, tools, and external adapters (as code, not just documentation).
• Build reproducible demos with synthetic or sample data.
• Implement ADR-010 (Smart Orchestrator V2).
• Add per-adapter rate limit dashboards.
• Add a CI-style check that runs the research framework's test suite on every code change.
• Document the migration path from the current research framework to ADR-010.

Long Term (Next 6-12 Months)

The work to be done in the next 6-12 months. These items are aspirational; they will be re-scoped as the lab evolves.

• Create a local status dashboard for the ecosystem.
• Unify indexes for tools, skills, and agents.
• Version tool specifications.
• Add contract tests for tool specifications and generated artifacts.
• Document migration paths when tools or agent roles change.
• Implement ADR-012 (SQLite or PostgreSQL for artifacts).
• Expand individual case studies:
  • The tooling layer.
  • The research framework.
  • The project templates.
  • Memory and context in local agents.
  • Security and auditability in tool-based workflows.
• Implement a multi-mission parallelism mode in the Research Worker.
• Add a streaming report mode (the report is generated incrementally as phases complete).

Maturity Criteria

The ecosystem is mature when it:

• Has reliable health checks for the core tools.
• Produces artifacts that can be traced back to their inputs and phase.
• Records decisions, trade-offs, and known gaps.
• Handles partial failure without hiding degradation.
• Distinguishes current state from future vision.
• Keeps documentation aligned with the observed system state.
• Supports reproducible demos and evaluation runs.
• Has zero Critical findings in the last 3 monthly audits.
• Has at most 2 High findings in the last 3 monthly audits.
• Has a complete and current tool registry.
• Has a complete and current failure catalog.
• Has a working audit report generator that ingests the request journal.
• Has reproducible research missions (same query → same report, modulo provider non-determinism).

Documentation Backlog

• Add diagrams for artifact lifecycle and worker recovery.
• Add a compact evaluation report format.
• Add a versioned matrix for tools, skills, owners, and verification status.
• Keep each page tied to the system it describes: architecture, decisions, workflows, artifacts, operations, and lessons learned.
• Translate the documentation to Spanish (the user-facing language) once the English version is stable.

Architecture Decision Records in Flight

The lab has the following ADRs in flight (in addition to the ones already accepted):

The ADRs are documented in Architecture Decisions.

Closing Note

The project remains applied learning: a local agent architecture built through iteration, with real tools, memory, audits, and documentation. The roadmap keeps that learning connected to operational maturity.

The roadmap is a living document. It will be updated as the lab evolves. The user is the operator; the operator decides what gets done and when.

See also

• Architecture Decisions
• Audit Model
• Failure Catalog
• Telemetry
• Health Checks