Skip to content

Roadmap

Thiago Botelho edited this page Aug 15, 2026 · 1 revision

Roadmap

Each phase ships with a versioned contract, tests, and an explicit compatibility statement. The normative version is docs/roadmap.md; this page adds the reasoning behind the order.

Why this order

The tempting order is templates first, because generating a project is the demo that impresses people. This project does the opposite, and the reason is that a generator you cannot verify is a generator nobody keeps using after the first bad run.

So the contracts, the human decisions, and the safety boundaries become testable before anything is allowed to write. By the time 0.3 renders a template, there is already a way to say what the output should look like and to check whether it does.

0.1, catalog and diagnosis · shipped

  • declarative catalog;
  • the .NET modular, React, and PostgreSQL profile;
  • inspection, recommendation, check, and read-only plan;
  • JSON protocol and digests;
  • contract and safety tests.

Released as v0.1.0.

0.2, extensible detection

The known weakness of 0.1 is that a signal is a boolean with no explanation. A rule fails and you are told to add migrations, without being told where the tool looked. Everything in this phase attacks that.

  • Versioned detectors per technology. Detection becomes data with its own version rather than a hardcoded regular expression, so a detector can improve without a tool release.
  • Per-rule evidence, carrying origin and confidence. A finding names the file and the match that produced it. "Failed" becomes "looked in these 40 .cs files, found no FallbackPolicy".
  • Configurable exceptions with a justification and an expiry date. The missing piece for real adoption. A team that will not rename its test directories needs a way to record that decision and have it expire, rather than ignoring a permanently red rule.
  • SARIF or an equivalent format for pipelines. So findings land in the code scanning UI teams already read instead of in a build log nobody opens.
  • Compatibility tests across profile versions. Proving that a profile bump moves scores in the direction the release notes claim.

0.3, templates and preview

The first phase that produces content, and still not the phase that writes it.

  • versioned templates for a system, a module, an endpoint, and a feature;
  • rendering into a temporary directory;
  • a declarative diff, computed against the real repository, applied to nothing;
  • validation of collisions, idempotency, and upgrades;
  • still no direct mutation of the target repository.

Rendering somewhere else and diffing is what makes generation reviewable. You see the change before anything decides to make it, and the same mechanism gives upgrades a preview for free.

1.0, safe integration with Kratos

  • Kratos discovers the provider through handshake;
  • selection and pinning of profile, version, and digest;
  • a plan of typed operations with pre- and post-conditions;
  • review and approval inside Kratos;
  • transactional application, evidence, and rollback by Kratos;
  • contract tests between the two repositories.

Note where the writing happens. Even at 1.0, Mestre Yoda only plans. Typed operations replace prose so an orchestrator can validate them, and the orchestrator is what approves, applies, and rolls back. Splitting recommendation from mutation is the design, not a limitation of the current version.

Out of scope

Five things this project will not do, listed because each has been proposed and each would break something the design depends on.

Folding the Kratos engine into Mestre Yoda. The separation is what keeps the Golden Path consumable by anything, not only by one harness.

Installing harness skills into generated projects. A standard that installs its own enforcement into your repository is a standard you cannot leave.

Executing code from the analyzed repository during inspection. Running a build would improve detection considerably and would also mean running arbitrary code from repositories the tool did not write. See the security model.

Adopting NestJS or Next.js. Not a judgement about those tools. This catalog describes one Golden Path, and a path that includes everything guides nobody.

Imposing Row Level Security without an explicit multi-tenancy decision. RLS turned on because it sounds safe produces a policy layer nobody can reason about.

Following along

Watch the releases or open an issue. The most useful contributions right now are reports of where detection disagrees with a healthy repository, because that list is what should shape 0.2.

Clone this wiki locally