Roadmap: FrameVitals 0.3.x project maturity and product evolution

[parthdongre]

Goal

Use the 0.3.x development cycle to turn FrameVitals from a feature-rich alpha into a more trustworthy, contributor-friendly, production-oriented OSS project without sacrificing its source-aware performance work.

This roadmap is intentionally split into phases. It is a planning guide, not a promise that every item must land in one release.

Phase 1 — Project maturity / trust

These should happen first because they improve every future contribution and release.

• Deploy documentation to GitHub Pages #44 — Deploy documentation to GitHub Pages
• Add Pyright type checking for the public API #45 — Add Pyright type checking for the public API
• Add coverage reporting and a non-regression guardrail #46 — Add coverage reporting and a non-regression guardrail
• Split CI benchmarks into PR, scheduled, and manual tiers #47 — Split CI benchmarks into PR, scheduled, and manual tiers

Phase 2 — Correctness and API stability

Strengthen the architecture introduced in 0.2.0 and make the growing public surface safer to depend on.

• Add cross-backend parity tests for pandas, Arrow, DuckDB, native, and fallback execution #48 — Add cross-backend parity tests for pandas, Arrow, DuckDB, native, and fallback execution
• Define public API stability and deprecation policy for the 0.3.x line #49 — Define public API stability and deprecation policy for the 0.3.x line

Phase 3 — Product capabilities

Build on contracts and quality gates with features that are useful in production data pipelines.

• Add data contract diffing and schema evolution classification #50 — Add data contract diffing and schema evolution classification
• Make quality gate decisions more explainable and configurable #51 — Make quality gate decisions more explainable and configurable

Phase 4 — Ecosystem and contributor experience

Make FrameVitals easier to extend and harder for examples/docs to become stale.

• Add a third-party check plugin authoring guide and reference example #52 — Add a third-party check plugin authoring guide and reference example
• Turn examples and documentation snippets into executable smoke tests #53 — Turn examples and documentation snippets into executable smoke tests

Release direction

A possible sequence:

• 0.2.x: focused bug fixes, dependency updates, release hardening
• 0.3.0: maturity foundations + selected API/product work from this roadmap
• 0.3.x: contract/gate improvements, ecosystem work, backend parity expansion
• 1.0.0: only after the public API, serialized formats, and compatibility policy are stable enough to make stronger guarantees

Principles

• Keep main release-ready.
• Integrate normal development through dev.
• Use focused feature branches/PRs rather than long-lived one-off experiment branches.
• Preserve explicit execution provenance and statistical fidelity when optimizing performance.
• Prefer measurable correctness/performance claims over marketing claims.
• Keep optional dependencies optional and core installation lightweight.
• Favor issues that outside contributors can understand and validate independently.

Adding roadmap items

New roadmap issues should explain:

1. the user/developer problem,
2. why FrameVitals should solve it,
3. concrete acceptance criteria,
4. compatibility/performance implications where relevant,
5. whether the work is release-blocking or can land incrementally.