Public launch scope completion

Problem

The YAML contract and normalizer have been validated internally but still contain gaps that are unacceptable for a public launch — undefined behavior for malformed input, missing validation for certain field combinations, and no documented rollback path if a user upgrades and encounters breaking changes. Shipping the core runtime publicly without production-safe compile/normalize behavior and clear rollback guidance risks damaging credibility with early external adopters who expect stability from a launched product.

Context

• The backlog for the YAML contract, compiler/normalizer, execution adapters, and release/versioning is broader than what public launch can safely absorb, so this task has to separate launch-critical scope from attractive but deferrable work.
• A credible launch needs stable default behavior, explicit unsupported cases, and a rollback story for the riskiest surfaces rather than a promise to finish everything.
• Expected touchpoints include dataface/core/, schema/compiled types, docs, and core test suites, launch checklists, and any tasks or docs that currently blur the line between required launch scope and post-launch follow-up.

Possible Solutions

• A - Keep the full backlog in scope until the last minute: preserves ambition, but guarantees launch risk remains unclear.
• B - Recommended: define a minimum externally supportable launch scope and close only those blockers: make explicit deferrals, owner assignments, and rollback expectations.
• C - Shrink scope aggressively to the point of a weak launch: lowers risk, but may undercut the product story and user value.

Plan

1. Audit the open work for the YAML contract, compiler/normalizer, execution adapters, and release/versioning and classify each item as launch-critical, launch-adjacent, or post-launch follow-up.
2. Document the required launch behaviors, known unsupported cases, and any rollback or kill-switch expectations for high-risk areas.
3. Close or explicitly defer the remaining blockers, linking each deferral to a tracked follow-up with clear risk notes.
4. Reconcile the launch scope with docs, QA/review evidence, and operator expectations so launch readiness is credible and explainable.

Implementation Progress

Review Feedback

• [ ] Review cleared