[Epic] Documentation, governance, and distribution readiness

[plx]

Parent

#26

Objective

Make the supported behavior, security boundaries, release promise, and contributor/maintainer processes accurate and discoverable, then prepare practical distribution after the audited v0.2 release.

Why this blocks release

The README has a broken quickstart, incomplete installation and CLI contract, mutable/unlocked CI guidance, and stale preview language. Specification.md is historical but easy to mistake for a normative contract. The repository lacks CHANGELOG, SECURITY, and CONTRIBUTING documents, has one crate owner, and has no tags/releases or Homebrew distribution.

Workstream order

1. Decide the normative documentation source and retain the historical audit/specification context deliberately.
2. Correct onboarding and document the stabilized grammar, CLI, platform, MSRV, API, security, and support contracts.
3. Add security/contributor/governance documentation and maintainer continuity controls.
4. After the independent audit, publish v0.2 and then a third-party Homebrew tap.

Completion criteria

• Every executable README/example command works in a clean environment.
• Grammar, CLI/env/exit behavior, platforms, MSRV, API stability, exclusions, symlinks, and containment assumptions match implementation.
• Historical specification status is unambiguous and useful prior art is reconciled with draft PR Clean up guide docs and CLI formatting #21.
• CHANGELOG/license clarification, SECURITY, and CONTRIBUTING material exists.
• Crate ownership/recovery and repository support/release responsibilities are documented.
• Publication and tap tickets remain dependency-gated behind the independent audit.

Relationships

• Parent epic: [Epic] Production readiness and formal v0.2.0 release #26
• Native child and dependency links will be added after leaf creation.
• Most behavior documentation is blocked by the relevant contract or implementation ticket and must copy the final decision rather than guess.

Prior art

Draft PR #21 removes the historical specification and cleans part of the README. It is currently conflicting and predates the audit; leaf tickets must explicitly extract, supersede, or reconcile its changes.