[M318][Lane-D][D001] New-work proposal and publication workflow integration

[doublemover]

[M318][Lane-D][D001] New-work proposal and publication workflow integration

Outcome

Integrate anti-noise governance into the workflow for adding new roadmap work and publication artifacts.

Why this matters

This issue exists inside M318 Governance hardening, anti-noise budgets, and sustainable progress enforcement because it advances the milestone focus: ratchet the cleaned-up repo shape after the corrective tranche so validation, workflow, hygiene, and proof surfaces do not drift back toward noise and ambiguity. The milestone exit gate is: The repo has enforceable budgets, waiver rules, and regression reporting over the corrected surfaces, with anti-noise policy wired into normal maintainer practice.

Design corrections folded in

• Place governance after the corrective tranche so it ratchets the corrected shape instead of prematurely freezing a moving target.
• Treat exceptions as first-class objects with owners and expiry rather than hidden tribal knowledge.
• Make anti-noise policy measurable and replayable through generated reports.

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

• New draft work is checked against budgets and waiver policy before publication.
• 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

• CI and policy guards for scripts, validation surfaces, residue, and artifact authenticity
• planning docs and publication helpers that define how new work is added
• maintainer review checklists and contribution policy surfaces
• tmp/reports/ budgets, waivers, and anti-regression outcomes

Useful repo references

• scripts/check_repo_superclean_surface.py, scripts/check_documentation_surface.py, scripts/check_objc3c_dependency_boundaries.py, and scripts/ci/check_task_hygiene.py are the current enforcement anchors.
• docs/runbooks/objc3c_maintainer_workflows.md and docs/runbooks/objc3c_public_command_surface.md are the operator-facing policy surfaces likely to need governance ratchets.
• scripts/objc3c_public_workflow_runner.py should remain the canonical workflow surface when new governance checks become public commands.

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

• M318-C002

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: M316
• Direct issue blockers: M318-C002
• Directly unblocks: M318-E001
• Execution instruction: Complete the direct blockers for M318-D001 and keep the work on the canonical implementation path for M318.

[doublemover]

Closed via 2e0609a (M318-D001 freeze long-term governance reporting contract).