Vitte

214. Vitte Platform Governance Complete

Objective: stabilize technical governance so platform evolution remains predictable.

Date: 2026-05-24

1) Architecture Review Process

Architecture review is required for:

  • new compiler stage or major pipeline change,
  • new runtime contract,
  • new backend or backend ABI shift,
  • stateful package manager behavior changes,
  • deterministic/reproducibility contract changes.

Review checklist:

  1. problem statement and alternatives,
  2. compatibility class impact (C0..C3),
  3. observability/diagnostics impact,
  4. rollback strategy,
  5. tests and gate coverage plan.

Decision states: accepted, accepted-with-conditions, rejected, superseded.

2) RFC Process

RFC required for:

  • C2/C3 public surface changes,
  • deprecation/removal of stable interfaces,
  • language syntax/semantics changes,
  • governance policy updates.

Lifecycle RFC:

  1. Draft (rfc:draft)
  2. Review (rfc:review)
  3. Decision (rfc:accepted or rfc:rejected)
  4. Implementation tracking (rfc:implemented)
  5. Post-release validation (rfc:validated)

Minimum RFC sections:

  • motivation,
  • design,
  • compatibility and migration,
  • diagnostics and tooling effects,
  • test/reproducibility plan,
  • rollout/rollback plan.

3) Diagnostics Policy

Diagnostics must be:

  • deterministic in ordering and formatting under deterministic mode,
  • tied to stable diagnostic codes for stable surfaces,
  • actionable (cause + minimal fix path),
  • covered by snapshot tests for regressions.

Policy constraints:

  • new diagnostic code requires docs entry and fixture,
  • changing stable diagnostic wording requires migration note if scripts rely on text,
  • diagnostics JSON schema changes are C3 and require staged rollout.

4) Stdlib Acceptance Policy

A stdlib module can be promoted from experimental to stable only if:

  1. API docs exist and examples compile,
  2. deterministic behavior requirements are explicit,
  3. profile/runtime constraints are documented,
  4. tests include nominal + edge + failure fixtures,
  5. migration impact is evaluated.

Label promotion:

  • stdlib:experimental,
  • stdlib:candidate,
  • stdlib:stable.

5) Backend Acceptance Policy

A backend is accepted as platform-supported only if:

  1. it passes deterministic build/rebuild checks on supported targets,
  2. contract snapshots exist for ABI/IR boundaries,
  3. failure modes produce structured diagnostics,
  4. reproducibility and stress tests run in CI,
  5. rollback path to previous backend remains available.

Backend maturity states:

  • backend:experimental,
  • backend:supported,
  • backend:contract-critical.

6) Stability Guarantees

Guaranteed stable by default:

  • documented CLI commands/options (except explicit experimental flags),
  • diagnostic code identifiers,
  • stable stdlib module APIs,
  • reproducible build behavior covered by release gate.

Not guaranteed unless promoted:

  • internal module layout,
  • internal compiler IR details not documented as contract,
  • experimental modules/backends/features.

7) Cadence Governance

  • Weekly: issue triage and policy drift scan.
  • Bi-weekly: architecture and RFC review batch.
  • Per release: compatibility and deprecation audit.
  • Quarterly: support window + maturity baseline review.