docs: 0.13.0 release baseline — fluid mission, packaging modes, accessPolicy surface

[fas89]

Pins the docs baseline to CLI 0.13.0. supportedFluidContractVersion stays 0.7.5 — 0.7.6 is opt-in preview, not the default.

New pages

• docs/cli/mission.md — the headline new top-level command. Four subcommands (check / run / trust / list), exit codes, spec format, the deliberately-frozen predicate mini-language, budgets + gates, the .fluid/missions/ trust boundary, the receipts layout, and the zero-LLM mission check CI recipe. The drift gate requires this page — mission is a real registered command at 0.13.0.
• docs/RELEASE_NOTES_0.13.0.md — mirrors the 0.12.0 structure (headline / who should upgrade / what changed / compatibility).

Updated pages

• cli/generate-iac.md + cli/apply.md — declarative packaging modes (0.7.6 preview): isolated vs shared container ownership, the six container kinds, per-provider emit differences, the pre-plan ownership-transition guard, and the new --adopt-shared-container flag. Clearly marked opt-in; an absent packaging block is a distinct LEGACY sentinel with byte-identical emit.
• providers/gcp.md — accessPolicy is now the IaC access-grant surface. Documents cross-project grants the schema-valid way, a declared principal-type → BigQuery/GCS field table, and metadata.policies as deprecated and schema-invalid (it fails fluid validate; fluid generate iac never validated, which is why the old path appeared to work). Also notes the group-emitted-as-user bug that the declared prefix fixes.
• providers/aws.md + providers/gcp.md — shared-vs-isolated container pointers into the packaging reference.
• cli/README.md, .vuepress/config.ts — both new pages wired into the index and nav.

Verification

PyPI does not carry 0.13.0 yet, so the gate was run against a clean python3.12 -m venv installed from the v0.13.0 git tag source:

$ fluid --version
FLUID Forge CLI v0.13.0

$ python3.12 scripts/check_cli_docs.py
OK: fluid CLI version matches docs (0.13.0).
OK: `fluid init --quickstart` emits fluidVersion 0.7.2 (matches pin).
OK: all 69 CLI subcommands are documented (docs/cli/ has 69 pages).

The gate re-runs in PR CI against the published wheel once 0.13.0 is on PyPI.

Also verified live against that venv: mission list, mission check (scorecard render + --json), the documented exit codes (0 green / 1 red / 2 harness error), mission trust on a built-in, and apply --help carrying --adopt-shared-container. Every internal link and heading anchor in the changed files resolves; config.ts's 192 markdown refs all exist on disk.

Allowlist

scripts/cli-docs-allowlist.yml audited against the 0.13.0 parser — no changes needed. mission was never listed (it did not exist at 0.12.0), and every remaining entry is still load-bearing: undocumented_ok = dmm / export-opds / marketplace / opds / viz-plan; docs_only_ok = README / export-odps / generate-artifacts / generate-iac / generate-vector. Nothing stale, nothing redundant.

Note for review

The --adopt-shared-container --help text says it "Logs a WARNING-level audit event", but _apply_opentofu_engine.py emits packaging_adoption_override through _logging.info() (INFO). The docs say "emits a structured audit event" rather than repeat the level claim — worth reconciling in the CLI repo.

[fas89]

Gate review: PASSED — re-verified against the published wheel

You checked PyPI before my publish finished, so your gate ran against a tag-built venv. 0.13.0 is live now, so I re-ran it against the real artifact:

pip install data-product-forge==0.13.0   →   FLUID Forge CLI v0.13.0
OK: fluid CLI version matches docs (0.13.0).
OK: `fluid init --quickstart` emits fluidVersion 0.7.2 (matches pin).
OK: all 69 CLI subcommands are documented (docs/cli/ has 69 pages).

All 6 CI checks green; worktree clean; 9 files, scope exactly right.

Your inaccuracy find was better than you knew. You flagged that --adopt-shared-container's help promises a WARNING-level audit event while the code emits INFO — and correctly documented the behaviour rather than repeating the claim. Tracing the precedent that code comment cites turned up the same defect in opentofu_destructive_gate_override, so --allow-data-loss was under-logging too. Both are fixed in forge-cli #450 with a non-vacuous pin. Your page needs no change: it describes the shipped 0.13.0 behaviour accurately, and the level claim becomes true next release.

Good calls on the two judgment items as well — renaming headings to avoid guessing VuePress's slugify for dotted versions, and sourcing the OSI/dbt claim to the --osi-sidecar-format help text rather than asserting it independently.