[M332][Lane-D][D002] Governance publication and stewardship evidence implementation
Outcome
Integrate governance and stewardship evidence into the public-facing process surfaces.
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
- Runnable integration on the real compiler/runtime/tooling/package path.
- Executable probes, packaged validation, or operator drills proving the live surface.
- Recovery and failure-mode behavior documented where the surface becomes operator-visible.
Acceptance criteria
- Governance publication reflects the actual review and stewardship process.
- Land runnable behavior on the real compiler/runtime/tooling path rather than a milestone-local scaffold.
- Back the work with executable probes, packaged validation, or operator drills instead of prose-only assertions.
- Harden determinism, cleanup, failure handling, and recovery on the live path.
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
- Start by extending existing runnable probes and public workflow actions; only add new integration entrypoints when the current path cannot truthfully express the feature.
Dependencies
Notes
- Lane D should feel real to a user or operator, not just to a checker.
- 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-D001
- Directly unblocks:
M332-E001
- Execution instruction: Complete the direct blockers for
M332-D002 and keep the work on the canonical implementation path for M332.
[M332][Lane-D][D002] Governance publication and stewardship evidence implementation
Outcome
Integrate governance and stewardship evidence into the public-facing process surfaces.
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
Required deliverables
Acceptance criteria
Primary implementation surfaces
Useful repo references
docs/governance/extension_author_guide_v1.md,docs/governance/faq_v1.md, andtests/governance/registry_compat/README.mdare 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.jsonanddependency_edges.jsonare good precedents for machine-owned process metadata if governance ends up needing structured review artifacts.Implementation guidance
Dependencies
M332-D001Notes
tmp/and make closeout evidence replayable.Execution Order
M331M332-D001M332-E001M332-D002and keep the work on the canonical implementation path forM332.