[M332][Lane-A][A001] Governance, extension lifecycle, and process gap inventory

[doublemover]

[M332][Lane-A][A001] Governance, extension lifecycle, and process gap inventory

Outcome

Inventory the remaining governance and extension-lifecycle gaps once package, adoption, support, and security surfaces are live.

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

• Boundary inventory, non-goals, and successor map in the canonical planning artifacts.
• Measured counts and inventories pulled from replayable queries instead of hand-entered literals.
• Truthful updates to milestone, program, and publication metadata when the boundary changes.

Acceptance criteria

• Governance work is grounded in the already-implemented product and ecosystem surfaces.
• Freeze the boundary truthfully, including non-goals and unresolved follow-on work.
• Capture only the direct blockers and successor surfaces needed for downstream execution.
• Back every count or inventory claim with a generated snapshot or a replayable source reference.

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

• Name concrete files and command surfaces while scoping the boundary; vague subsystem labels slow down the first implementation issue.

Dependencies

• none

Notes

• Lane A removes ambiguity; it should not create a second planning layer.
• 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: none
• Directly unblocks: M332-B001, M332-B002
• Execution instruction: Complete the direct blockers for M332-A001 and keep the work on the canonical implementation path for M332.

[doublemover]

Implemented in commit badff4d4a.

Validation:

• python scripts/build_governance_budget_inventory_summary.py

Measured current inventory:

• package_script_count: 168
• package_script_budget: 168
• checker_wrapper_test_count: 0