Audit Store & Retrieve Data examples

[snissn]

Goal

Audit and fix end-user Store & Retrieve Data examples on top of upstream/docs-ia-refresh, with current guidance for storage and retrieval flows.

Done means storage/retrieval examples point readers toward maintained Filecoin storage patterns, stale deal-client/helper flows are corrected or retired, 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-641/audit-and-fix-code-examples-store-and-retrieve-data-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:

• build/cookbook/store-data.md
• build/cookbook/retrieve-data.md
• build/cookbook/filecoin-pin/**
• build/advanced/filecoin-onchain-cloud.md
• build/getting-started.md
• getting-started/how-storage-works/storage-onramps.md
• getting-started/how-retrieval-works/**
• .gitbook.yaml redirects only when stale store/retrieve URLs point to obsolete example flows.

Non-Goals

• Do not edit operator/provider configuration covered by GER-640 except to avoid a direct conflict.
• Do not edit FVM smart-contract examples already handled by GER-639.
• Do not perform broad conceptual rewrites unless needed to fix or contextualize storage/retrieval examples.
• Do not merge the PR before human review.

Required Work

• Inventory all commands, code snippets, package imports/versions, API endpoints, auth/env variables, CLI flows, upload examples, retrieval examples, and external links in scope.
• Verify examples against current recommended paths: Filecoin Onchain Cloud/Synapse, Filecoin Pin/PDP-backed flows, storage onramps, Lassie/IPFS retrieval, and maintained third-party docs where applicable.
• Replace, retire, or clearly mark legacy deal-client/manual market-deal examples, Powergate/Estuary/web3.storage-era helper references, or unmaintained retrieval workflows unless intentionally preserved as legacy content.
• Make examples safe and usable: no fake live credentials, no reusable private keys, no unexplained hard-coded account data, and no snippets that look copyable but are missing required imports, variables, funding/auth assumptions, or expected outputs.
• Preserve clear user choice between managed onramps, programmable/on-chain storage, direct retrieval clients, and operator-hosted storage paths.

Validation Requirements

• git diff --check
• npm run build
• Targeted stale-string scan across touched store/retrieve docs.
• Link/package/version sanity checks for referenced tools, packages, SDKs, services, and retrieval clients.
• 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 user-facing store/retrieve 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: #76\n\nValidation captured in the PR body. This remains review-only until merge approval.