Skip to content

Track GER-640/GER-641 storage example audits #72

Description

@snissn

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:

  1. GER-640 provider/operator lane owns storage-providers/** and only touches redirects/SUMMARY entries when needed for Provide Storage.
  2. 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

  • Work must happen on topic branches targeting upstream/docs-ia-refresh.
  • Direct pushes to main or the base branch are prohibited for this tracker.
  • PRs must be reviewable before merge: latest-head CI, focused local validation, link/version sanity checks when relevant, and AI/code-review findings resolved or explicitly rejected with rationale.
  • Codex, Copilot, CodeRabbit, or other review-credit-consuming AI reviews are requested only after the PR is mature enough to avoid review-credit churn.
  • Human approval is required before merge. The initial execution request explicitly said not to merge.

Required PR Body Sections

  • Linked Linear issue and GitHub child issue.
  • Base branch and current head SHA.
  • Audited files and scope boundary.
  • Sources checked for current docs/tooling guidance.
  • Local validation commands and outcomes.
  • Link/package/version sanity checks, if applicable.
  • AI review status and unresolved thread summary.
  • Deferred items, if any.
  • Explicit note that the PR should not be merged before human review.

Milestones

M0. Tracker And Graph Setup

  • Create parent tracker.
  • Create GER-640 executable child issue.
  • Create GER-641 executable child issue.
  • Build graph manifest with base branch, node states, and ownership boundaries.

M1. GER-640 Provide Storage Audit

  • Inventory operator-facing snippets/configs/links.
  • Fix stale or unsafe examples.
  • Validate docs build and link/version sanity checks.
  • Open reviewable PR.

M2. GER-641 Store & Retrieve Audit

  • Inventory user-facing storage/retrieval snippets/links.
  • Fix stale or unsafe examples.
  • Validate docs build and link/version sanity checks.
  • Open reviewable PR.

M3. Review Readiness

  • Ensure both PRs are open, non-draft, and target upstream/docs-ia-refresh.
  • Ensure latest-head CI is green or non-blocking with documented rationale.
  • Resolve AI/code review comments if requested and present.
  • Leave PRs unmerged for human review.

Tests And Evidence

Required for both lanes:

  • git diff --check
  • npm run build
  • Targeted stale-string scan for known obsolete names/URLs in touched files.
  • Link/package/version sanity checks for external repos, docs, packages, SDKs, CLIs, services, and retrieval/provider tools referenced by touched examples.

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 are linked from this tracker.
  • Each child has a PR linked back to the issue and Linear ticket.
  • PR bodies contain current validation and review evidence.
  • Latest-head CI has completed or a non-blocking external-check caveat is documented.
  • No unresolved AI review notes remain if AI review was requested.
  • No PRs are merged before human review.

Child Issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationenhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions