Goal
Track and complete the post-IA-refresh code-example audits for the Filecoin docs storage surfaces:
- GER-640: operator-facing Provide Storage examples and configuration.
- GER-641: end-user Store & Retrieve Data examples and links.
Done means reviewable PRs exist on top of upstream/docs-ia-refresh for both lanes, each PR documents its audited files, validation, link/version checks, review status, and any deferred items. The PRs must not be merged until human review approves them.
Why This Exists
filecoin-project#2457 reorganizes the docs around the updated information architecture and GER-639 already refreshed Build-section code examples. The remaining storage-related examples span two distinct audiences and should be audited separately to avoid mixing operator configuration guidance with end-user storage/retrieval workflows.
Current Evidence
Scope
- Provide Storage/operator lane:
storage-providers/** and Provide Storage entries in SUMMARY.md, including PDP, node setup, infrastructure, architecture, deals/economics pages, commands, configuration blocks, ports/endpoints, env vars, and operator links.
- Store/Retrieve user lane:
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/**, and relevant redirects.
Non-Goals And Boundary
- Do not rework FVM smart-contract examples already handled by GER-639.
- Do not rewrite broad conceptual docs unless needed to correct or contextualize a command, snippet, config, link, or redirect.
- Do not merge generated PRs from this tracker without human approval.
- Do not request AI review until a PR has coherent changes, passing local validation, current PR body evidence, and latest-head CI running or green.
Execution Ordering And Blocking
The two child issues are independent siblings and may be implemented in parallel. They share the same base branch but have disjoint primary file ownership:
- GER-640 provider/operator lane owns
storage-providers/** and only touches redirects/SUMMARY entries when needed for Provide Storage.
- GER-641 store/retrieve lane owns user-facing Build cookbook and Getting Started storage/retrieval docs and only touches redirects when needed for stale store/retrieve routes.
If both lanes need the same redirect or landing-page wording, coordinate in the smaller relevant PR and document the ownership choice in the PR body.
Branch And PR Policy
Required PR Body Sections
Milestones
M0. Tracker And Graph Setup
M1. GER-640 Provide Storage Audit
M2. GER-641 Store & Retrieve Audit
M3. Review Readiness
Tests And Evidence
Required for both lanes:
Benchmarks are not required because this is documentation-only work. Any performance claim introduced in docs must cite an external source or be removed.
Completion Criteria
Child Issues
Goal
Track and complete the post-IA-refresh code-example audits for the Filecoin docs storage surfaces:
Done means reviewable PRs exist on top of
upstream/docs-ia-refreshfor both lanes, each PR documents its audited files, validation, link/version checks, review status, and any deferred items. The PRs must not be merged until human review approves them.Why This Exists
filecoin-project#2457 reorganizes the docs around the updated information architecture and GER-639 already refreshed Build-section code examples. The remaining storage-related examples span two distinct audiences and should be audited separately to avoid mixing operator configuration guidance with end-user storage/retrieval workflows.
Current Evidence
FIL-Builders:filecoin-docsbranchupstream/docs-ia-refresh.41e4d14aee1b87ff5d28e3b9b85e8a1fe1c9a229.Scope
storage-providers/**and Provide Storage entries inSUMMARY.md, including PDP, node setup, infrastructure, architecture, deals/economics pages, commands, configuration blocks, ports/endpoints, env vars, and operator links.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/**, and relevant redirects.Non-Goals And Boundary
Execution Ordering And Blocking
The two child issues are independent siblings and may be implemented in parallel. They share the same base branch but have disjoint primary file ownership:
storage-providers/**and only touches redirects/SUMMARY entries when needed for Provide Storage.If both lanes need the same redirect or landing-page wording, coordinate in the smaller relevant PR and document the ownership choice in the PR body.
Branch And PR Policy
upstream/docs-ia-refresh.mainor the base branch are prohibited for this tracker.Required PR Body Sections
Milestones
M0. Tracker And Graph Setup
M1. GER-640 Provide Storage Audit
M2. GER-641 Store & Retrieve Audit
M3. Review Readiness
upstream/docs-ia-refresh.Tests And Evidence
Required for both lanes:
git diff --checknpm run buildBenchmarks are not required because this is documentation-only work. Any performance claim introduced in docs must cite an external source or be removed.
Completion Criteria
Child Issues