v1 readiness: define the compatibility, support and deprecation contract

[AminChirazi]

needs-human — this is a public-product contract and a release-scope decision.

Readiness gap

Flowproof correctly describes itself as early and warns that interfaces may change between minor versions. Before enterprises can treat a recording as durable evidence, they need to know which artifacts and interfaces survive an upgrade.

The compatibility surface is broader than the Rust API:

• .flow.yaml specs and suite.yaml;
• JSONL traces and cassettes;
• CLI commands, exit codes and --json output;
• run records, JUnit, HTML and audit output;
• the Python API;
• npm launcher/platform-package resolution;
• the MCP server’s tools and structured result shapes;
• supported operating systems, runtimes and browser/SAP dependencies.

Without a written contract, “record once, replay forever” is stronger than the upgrade guarantee surrounding the recording.

Acceptance criteria

• Publish a support matrix for operating systems, architectures, Python, Node, browsers and SAP GUI versions.
• Identify which surfaces become stable at v1 and which remain explicitly experimental.
• Define backward/forward compatibility for specs, traces, cassettes and persisted run records.
• Define the migration behavior when a newer engine reads an older trace, and the failure behavior when an older engine reads a newer trace.
• Publish semantic-versioning rules and a minimum deprecation window for CLI, Python and MCP surfaces.
• Define the number or duration of supported release lines and the security-fix/backport policy.
• Add compatibility fixtures from representative old releases and run them in CI.
• Define measurable v1 exit criteria, including the existing live-SAP, containment and multi-turn readiness issues.
• Reconcile the marketing phrase “replay forever” with the precise support guarantee in documentation.