Public launch scope completion

Problem

The context catalog needs to transition from an internal tool to a publicly available feature, but the gap between internal-quality and production-safe behavior has not been assessed or closed. Public users will encounter data sources, schema patterns, and scale that internal testing never covered. Without clearly defined launch-critical scope, production safety guarantees, and rollback mechanisms, a public launch risks exposing users to incomplete metadata, silent enrichment failures, or unrecoverable states.

Context

• The backlog for context schema/catalog contracts and Nimble enrichment flows across product surfaces 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/ai/, context-contract docs, eval wiring, and inspect-derived artifacts, 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 context schema/catalog contracts and Nimble enrichment flows across product surfaces 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