// PRODUCT ROADMAP
What works now. What we are building next.
This roadmap separates released Runtime capabilities from active development, committed direction and open research. A status is not a release-date promise. Theme Upload and user Runtime execution are not yet open.
The public trust surfaces available today.
The Demo, report contract, Documentation and public rules make the review model inspectable before Runtime access opens.
Released
Description
Review precise, rule-backed issues found in the theme.
Why it exists
Developers need located technical issues instead of generic scores.
Released
Description
Inspect the source evidence behind each Finding.
Why it exists
A Finding must show what triggered it before it can be trusted.
Released
Description
Understand why a Finding matters and what it means.
Why it exists
Evidence becomes actionable only when its technical impact is clear.
Released
Description
See how the Runtime established confidence in a Finding.
Why it exists
Users need to distinguish verified results from uncertain signals.
Released
Description
Preview a bounded correction for supported Findings.
Why it exists
A safe preview helps evaluate a correction without changing the theme.
Released
Description
Inspect stable rule identities and public methodology.
Why it exists
Public rule contracts make Runtime behavior inspectable over time.
The user Runtime workflow being built.
Active work, shown without a promised release date. Access is opened deliberately while its verification contract is established.
In Development
Description
Upload a Shopify theme archive for verification.
Why it exists
The Runtime needs a stable, reviewable input before analysis begins.
In Development
Description
Run the complete verification Runtime against a theme.
Why it exists
A single audit establishes the deterministic boundary for every result.
In Development
Description
Generate a bounded patch with explicit verification steps.
Why it exists
Corrections should inherit the same evidence and validation discipline as Findings.
Product workflows that follow a trusted audit.
Accepted product direction, not released functionality. Scope and order may change as the Runtime is validated.
Planned
Description
Apply a verified patch through an explicit controlled flow.
Why it exists
Theme changes require deliberate authorization and a visible execution boundary.
Planned
Description
Return safely to the theme state before an applied change.
Why it exists
Every controlled change needs a defined recovery path.
Planned
Description
Keep prior audit runs attached to a theme.
Why it exists
Teams need a durable record of what the Runtime observed and when.
Planned
Description
Compare Findings between two audit runs.
Why it exists
A comparison proves which issues appeared, changed or were resolved.
Planned
Description
Coordinate audit access across a Shopify team or agency.
Why it exists
Verification becomes operational when access and ownership are explicit.
Planned
Description
Export audit results in supported portable formats.
Why it exists
Findings must move cleanly into review, delivery and compliance workflows.
Possible interfaces around the Runtime.
Exploration only. These interfaces do not define the current product and carry no delivery commitment.
Research
Description
Run the verification Runtime from a terminal workflow.
Why it exists
Some teams need verification close to local development and automation.
Research
Description
Inspect Runtime Findings inside the editor.
Why it exists
Editor context could shorten the path from Evidence to investigation.
Research
Description
Connect verification results to repository workflows.
Why it exists
Repository feedback could place verified Findings beside proposed changes.
Research
Description
Expose Runtime context through a controlled MCP interface.
Why it exists
Controlled machine access could make verified context reusable by other tools.
Research
Description
Integrate the Runtime through a documented public contract.
Why it exists
A stable API could support workflows beyond Syphio's own interfaces.
// FEATURE ACCESS
Follow the feature, not a generic newsletter.
Every request remains attached to one stable roadmap key. Released capabilities never enter this workflow.