[M332][Lane-B][B001] Extension/RFC/compatibility review policy

[doublemover]

[M332][Lane-B][B001] Extension/RFC/compatibility review policy

Outcome

Define the canonical policy for extensions, RFCs, compatibility review, and language evolution.

Why this matters

This issue exists inside M332 Governance, extension lifecycle, and ecosystem sustainability because it advances the milestone focus: make the project sustainable once people depend on it: extension/RFC workflow, compatibility review, package ecosystem governance, contributor and maintainer operating model, and policy surfaces that prevent the completed language from decaying into ad hoc evolution. The milestone exit gate is: The language and ecosystem have a durable governance and evolution model that can handle extensions, compatibility pressure, releases, and outside contribution without losing coherence.

Design corrections folded in

• Codify governance from the real package, support, security, and adoption surfaces rather than inventing it in a vacuum.
• Treat governance as an engineering surface with executable review paths and machine-owned evidence.
• Keep extension and compatibility review coupled to the actual release and support model already established.

Required deliverables

• One canonical semantic or policy contract on the real implementation path.
• Guardrails or fail-closed behavior only where they materially prevent overclaiming.
• Documentation updates that narrow the public claim surface to the evidence.

Acceptance criteria

• Language evolution is bounded by an explicit compatibility review model.
• Define one canonical semantic or policy model and retire competing interpretations.
• Keep claims narrower than the evidence and fail closed where runtime behavior is intentionally deferred.
• Make downstream artifact and runtime work executable without reopening first-order design decisions.

Primary implementation surfaces

• governance docs, RFC/extension flows, and compatibility review policies
• package ecosystem and support-matrix claim surfaces
• release, update, and security response workflows
• contributor, maintainer, and extension-author guidance under docs/
• tmp/reports/ governance, process, and review evidence

Useful repo references

• docs/governance/extension_author_guide_v1.md, docs/governance/faq_v1.md, and tests/governance/registry_compat/README.md are the best existing governance-related anchors in-tree.
• scripts/check_objc3c_dependency_boundaries.py, release/update/security publication tooling, and package/distribution runbooks are the live process surfaces governance needs to codify rather than bypass.
• tmp/github-publish/*/program_manifest.json and dependency_edges.json are good precedents for machine-owned process metadata if governance ends up needing structured review artifacts.

Implementation guidance

• Write the contract against the live code and probe surfaces so the later implementation issues can diff behavior directly instead of rediscovering intent.

Dependencies

• M332-A001

Notes

• Lane B should sharpen executable meaning and explicit policy, not merely restate intent.
• Prefer integrating with existing compiler/runtime/tooling/package surfaces rather than creating milestone-specific parallel scaffolds.
• Store transient validation captures under tmp/ and make closeout evidence replayable.
• Keep public and internal claims narrower than the evidence wherever uncertainty remains.

Execution Order

• Direct milestone blockers: M331
• Direct issue blockers: M332-A001
• Directly unblocks: M332-C001
• Execution instruction: Complete the direct blockers for M332-B001 and keep the work on the canonical implementation path for M332.

[doublemover]

Implemented in commit 649948143.

Validation:

• python scripts/build_governance_extension_review_policy_summary.py