Audit Provide Storage operator examples

[snissn]

Goal

Audit and fix operator-facing code, command, and configuration examples in the Provide Storage section on top of upstream/docs-ia-refresh.

Done means the affected provider/operator docs are accurate enough for a storage provider operator to trust, unsafe/stale examples are corrected or removed, and a reviewable PR exists with validation and link/version evidence.

References

• Parent tracker: Track GER-640/GER-641 storage example audits #72
• Linear: https://linear.app/germina-labs/issue/GER-640/audit-and-fix-code-examples-provide-storage-section
• Base PR: docs: refresh information architecture, onboarding, and navigation filecoin-project/filecoin-docs#2457
• Base branch: upstream/docs-ia-refresh

Scope

Primary file ownership:

• storage-providers/**
• Provide Storage entries in SUMMARY.md only when navigation labels or links are directly affected.
• .gitbook.yaml redirects only when stale Provide Storage routes point to removed, misleading, or legacy operator guidance.

Include PDP operator docs, provider getting-started, node setup, architecture, infrastructure, Filecoin deals/economics pages, and any page in scope with commands, config snippets, install steps, ports/endpoints, env vars, or operator-facing links.

Non-Goals

• Do not edit Build cookbook storage/retrieval user flows except to avoid a direct conflict with GER-641.
• Do not edit FVM smart-contract examples already handled by GER-639.
• Do not perform broad conceptual rewrites unless needed to fix or contextualize an example/config.
• Do not merge the PR before human review.

Required Work

• Inventory every command, config block, TOML/YAML/env var, install step, API endpoint, port/network instruction, and external docs link in scope.
• Verify examples against maintained Filecoin operator sources and current project decisions for Lotus, Boost, Curio, PDP, and related provider tooling as applicable.
• Fix broken, obsolete, or misleading examples; remove or redirect unmaintained legacy flows when there is no current replacement.
• Make examples safe and realistic: no real secrets, private keys, hard-coded account data, stale actor/provider IDs presented as reusable values, or mixed generations of provider tooling.
• Label intentionally schematic examples as illustrative and make copyable examples include prerequisites, expected context, and caveats.

Validation Requirements

• git diff --check
• npm run build
• Targeted stale-string scan across touched storage-providers/** files.
• Link/version sanity checks for referenced operator docs, repos, packages, services, and tools.
• PR body lists audited files, sources checked, commands/tests run, AI review status, and deferred items.

Benchmarks are not required because this is documentation-only work.

PR Policy

• Use a topic branch targeting upstream/docs-ia-refresh.
• Keep changes scoped to the operator/provider lane.
• Request AI review only after the PR is mature: coherent changes pushed, local validation complete, PR body current, no known local blockers, and latest-head CI running or green.
• Resolve or explicitly reject AI/code-review comments with rationale.
• Do not merge before human review.

[snissn]

Implementation PR opened: #75\n\nValidation captured in the PR body. This remains review-only until merge approval.