repowiseThere are no dates here. Releases land every few days, so any quarter printed on this page would be wrong in the slow direction, and a roadmap that is wrong in the slow direction is worse than one carrying no dates at all. What we commit to is the status column.
The changelog is the evidence, and it is the fastest way to check whether this page is honest. Items disappear from here when they ship.
| Status | What it means |
|---|---|
| In development | Being worked on now. Code exists, it is not finished. |
| Planned | Committed to, not started. |
| Exploring | We think it is a good idea and have not committed to it. Tell us if you need it, that is what moves a row up. |
The canonical, always-current version of this page lives in the OSS repo at ROADMAP.md. If the two ever disagree, that one is right.
Languages
Every language repowise supports ships in the open-source distribution
under AGPL-3.0. No language sits behind the commercial licence, and
none will. If your stack is on the list, the support arrives in
pip install repowise.
Languages land on a five-rung ladder rather than a yes/no list. Today that ladder covers 40 languages, 26 of them parsed to a full AST.
New languages
| Language | Status | Why it is on the list |
|---|---|---|
| PL/SQL | Planned | We already parse SQL through sqlglot. Packages, procedures and triggers are where the business logic actually lives. |
| Apex | Planned | Salesforce estates, where the org is often the least documented system a company runs. Apex is Java-shaped, and Lightning Web Components are already covered as JavaScript and HTML. |
| Template dialects (Django/Jinja, ERB, Blade, Thymeleaf, Go templates) | Planned | Today they parse cleanly as HTML and yield nothing, because {% extends "base.html" %} is plain text to an HTML parser. A stated ceiling, not an oversight. |
| ABAP | Exploring | The same argument as COBOL, in SAP estates. |
| RPG / AS400 | Exploring | Named alongside COBOL often enough to track. |
| Fortran | Exploring | Scientific and engineering codebases with long lifespans and thin documentation. |
| Ada | Exploring | Defense and aerospace, long-lived and thinly documented, usually in the same estates asking about COBOL. |
Deepening languages we already parse
| Language | Status | Next |
|---|---|---|
| Vue, Svelte | In development | Options-API members, {#each} and v-for head bindings, .svelte.ts rune modules |
| COBOL | Planned | Copybook resolution, source-format normalization, broader dialect coverage, and health markers |
| C#, Scala, Ruby | Planned | Dataflow dialects, which is what Extract Method needs in order to lift a span safely |
| C | Planned | It shares the C++ grammar for parsing but reaches no health walker map, so it gets graph coverage without markers |
| SQL / dbt | Planned | Column-level blast radius |
| Object Pascal | Planned | Assertion and performance markers, a dedicated uses resolver |
| Elixir | Planned | Health markers, and a call-resolution strategy so a bare-name call reaches beyond its own file |
| F# | Planned | Health markers, and a resolver that reads the AST index instead of the declared-name regex |
| Objective-C | Planned | Health markers, a resolver that reads the Xcode project rather than file stems, and pairing a header with its implementation across files |
| Razor / Blazor | Planned | @using and @inject edges so component tags resolve through imports, @code members as symbols rather than call edges only |
| Kotlin | Exploring | Dataflow is blocked on the grammar and needs either a grammar upgrade or a text-based jump seam. We would rather say blocked than planned. |
Adding a language touches per-language subpackages rather than the parser core, which is what makes this tractable. Open an issue and we will scope it in public.
Source control beyond git
Plenty of the code most worth indexing has never been near a git remote. It sits in Perforce, in Subversion, or on a mainframe under a change-management system older than most of the people maintaining it.
A repository with no git at all already indexes today. Only one of the five layers is derived from history, so the graph, documentation, decisions and code-health layers all build normally from the working tree. What is missing is the history-derived half: hotspots, ownership, co-change, bus factor, bug history and change risk, all of which need a commit log to mine.
| System | Status | Shape of the work |
|---|---|---|
| Perforce Helix Core | Planned | Changelists map to commits almost directly, and p4 filelog and p4 annotate cover history and blame. Common in games, hardware and embedded. |
| Subversion | Planned | Revisions map cleanly; svn log and svn blame are close analogues. |
| TFVC (Azure DevOps) | Exploring | Changesets, for shops on Azure DevOps that never moved to its git repos. |
| Mercurial | Exploring | Changesets map cleanly and the work is small. Ordered by demand rather than difficulty. |
| CA Endevor SCM | Exploring | Not a commit DAG. Endevor tracks elements moving through a promotion hierarchy, so the practical shape is an export to a filesystem plus a history adapter. |
| ChangeMan ZMF | Exploring | The same argument, with packages instead of elements. |
Ask rather than guess if your system is not listed. The seam is the same for all of them, and what decides the order is which ones customers actually run.
Multi-repo and workspace
| Item | Status | What it adds |
|---|---|---|
| Cross-repo intelligence at scale | In development | Hotspots, dead code and ownership across a whole estate with centralized dashboards, beyond the local-workspace scope already shipping in open source |
| Column-level blast radius for SQL / dbt | Planned | Lineage is table-level today through ref() and source(). Column-level answers "who breaks if I drop this field" |
| Custom decision policies | Planned | Required-reviewer rules, mandatory get_why checks on governed paths, and merge gating tied to findings |
Integrations and enterprise operations
These sit on the hosted platform and the commercial licence. What is available today is listed on the Enterprise page.
| Item | Status |
|---|---|
| GitHub Enterprise, Azure DevOps, GitLab self-managed, Bitbucket | In development |
| SAML / OIDC SSO (Okta, Entra ID, Auth0, Google Workspace) and SCIM provisioning | In development |
| Slack and Microsoft Teams beyond security alerting: hotspot drift, bus-factor warnings, decision staleness, routed by ownership | In development |
| Audit-trail coverage beyond the security surface, covering decisions and overrides | In development |
| Engineering leader dashboard: bus-factor trends, ownership drift, decision-staleness curves, scheduled digests | In development |
| Jira risk-finding links and PR-impact auto-comments on linked issues | Planned |
| Native SIEM connectors (Splunk, Datadog, Elastic) beyond the signed-webhook stream | Planned |
| PagerDuty | Planned |
| SPDX SBOM output and cross-format conversion | Planned |
| ISO 27001 Annex A and GDPR / data-residency control mappings | Planned |
| Role-based access control at repo, module and decision level | Planned |
| Air-gapped install bundle with bundled grammars, embedding model and optional Ollama runtime | Planned |
| Helm chart for the reference topology | Planned |
| Multi-tenant deployment | Planned |
| Backup and restore, point-in-time snapshots of the intelligence layers | Planned |
On the compliance row: we would rather ship two solid mappings than four shallow ones, which is why PCI-DSS 4.0 and SOC 2 are available today and these are not.
Core intelligence
The half of the roadmap that has nothing to do with procurement.
| Item | Status | Note |
|---|---|---|
| A sealed JavaScript / TypeScript retrieval corpus | In development | Built and half graded. The sealed half is unrun, and nothing from it is quoted anywhere until it is evaluated, once. |
| Session intelligence harvesting | Planned | Architectural decisions surfaced from AI coding sessions and proposed to the team knowledge base, so knowledge generated during agent work does not evaporate when the session ends |
| Interface-dispatch recall | Exploring | The measured ceiling on our call-graph recall. On one graded repository, 44% of what we miss is dynamic dispatch alone and a further 39% is dispatch with a closure at one end. Nobody in the measured field has cleared it, at 6.5 possible targets per call site, and matching that recall naively means emitting six edges where one is right. |
| More compiler oracles for graph precision | Exploring | Go and TypeScript are done. C#, Java, Kotlin and C++ each need a toolchain and a working build per repository; Rust has the toolchain and no sound call-graph tool exists for it; Python, Ruby and PHP admit no oracle even in principle. The honest status is "probably not", not "planned". |
What we are not building
- An LLM-based PR reviewer. The PR bot makes zero model calls per review, and that is the product rather than a limitation: nothing to hallucinate, nothing to prompt-inject, and pushing the same diff twice produces the same review twice. If you want intent-reading review, run one of the tools that does that alongside this one.
- Runtime or APM data. Everything here is derived from source and git history. A performance finding we report is a static one, and we label it as static.
- Any language behind a paywall. Stated above, repeated here because it is the question we get asked most.
- Dates. See the top of this page.
Ask for something
Open an issue and say what you need and why. Demand is what moves an Exploring row to Planned, and we say so rather than implying the order is purely technical.
For commercial and procurement timelines, email hello@repowise.dev. For security review, security@repowise.dev.