task: media-library - Configure Git LFS and Netlify #290

Task Summary

Validate and configure Git LFS and Netlify settings for GitHub + Netlify storage approach.

Additional Context

GitHub + Netlify is the planning baseline. Provider evaluation, cost verification, any Git LFS requirement and implementation approval remain separate gates.

Acceptance Criteria

• Confirm provider/workflow approval, including visual upload/tagging requirements.
• Verify account allowances, billing and deployment limits against measured demand.
• Configure approved tracking and active deployment settings; demonstrate checkout and deployment without unresolved LFS pointers.
• Document measured build behaviour, monitoring, escalation and fallback options.

Dependencies

Dependency-role clarification: #280 supplies evaluation, #281 supplies design, #289 supplies final schema approval, #290 supplies configuration evidence and #291 supplies implementation evidence. These descriptions do not create blocking relationships.

• Related: design: media-library - Design the import and reference-migration workflow #281 (build script implementation)
• Blocks: Full migration (needs infrastructure ready)

Deliverables

• Git LFS configuration (.gitattributes with bandwidth estimates)
• Netlify build config with optimization steps
• Cost/performance analysis (vs. Cloudinary baseline)
• Team workflow documentation
• Monitoring setup guide

References

• Storage Decision: .github/reports/toa-media-library/DECISION-LOG.md
• Strategy Report § 5: .github/reports/toa-media-library/MEDIA-LIBRARY-STRATEGY-REPORT.md

Immediate next steps

Confirm the provider/workflow decision and whether Git LFS is required. Verify account-specific settings and calculate demand from measured recovered files. Obtain approval before configuration changes.

Evidence required

Dated account/provider sources, measured capacity assumptions, approved configuration decisions, representative checkout/deployment results and monitoring/fallback guidance. Do not describe the approach as zero-cost without evidence.

Current status — 19 October 2026

Backlog. GitHub + Netlify is approved for planning only. No tracked .gitattributes establishes Git LFS configuration. Account settings, allowances, costs and live deployment behaviour remain unverified.

Definition of Ready (DoR)

• Infrastructure outcome is identified.
• Approval, access, billing constraints and active runtime/package-manager settings are confirmed.

Definition of Done (DoD)

• Representative deployment evidence satisfies the criteria.
• Configuration contributions and operational guidance are reviewed, approved and handed over.

Specification references

Historical update correction — 19 October 2026: PR #297 closed without merging. Related specification material nevertheless entered develop through separate integration and successor work; this does not establish delivery approval.

• Specification
• Plan
• Tasks

Draft specification/planning references at revision 02aee367; not evidence of approval, completed recovery or implementation. Task correspondences below describe relevant scope, not exclusive ownership or completed work.

Explicit downstream implementation scope, excluded from this definition package. T007 records decision implications only; no task delivers Git LFS or Netlify configuration.

✅ Update (2026-10-17): Specification consolidation complete (PR #296 + #297 merged). Current references available on develop branch:

• Specification
• Audit Reports
• All planning docs

Branch instructions

• Repository: lightspeedwp/ThisOneTimeOnAcidCom.
• Implementing target: this infrastructure issue; counterpart GitHub issue 290. The first bounded contribution below documents configuration readiness and verification procedures; it does not configure storage or deploy anything.
• Parent context: retain existing coordination hierarchy. Withhold parent identifiers and URLs from branch names, PR titles/bodies and coding prompts while association effects remain unverified. Never use the parent as a native development or closing target.
• Allowed closing targets: none for this partial contribution. Documentation alone cannot satisfy checkout, deployment, measured behaviour or operational acceptance.
• Branch state: proposed new branch, not created. The refreshed 38-branch listing contains no matching proposed branch; no existing branch was verified as suitable for this issue. Repeat collision and related-PR checks before separately authorised work.
• Proposed branch: docs/media-library-infrastructure-readiness.
• Base: develop, checked at 4ecdb26d9655a48bf000a7c89da2f70383edce87 (D). Refresh before branch creation.
• Naming evidence: local guide, local validator and organisation strategy. docs/ is authorised for this documentation-only subset; the issue classification does not determine its prefix. Static inspection only; validation not executed.
• PR template: shared route map maps docs/ to pr_docs.md. The local workflow suggests absent pr_documentation.md and applies a type label; it does not load the PR body. Obtain maintainer agreement on manual template selection before PR creation. Do not repair templates, routes or labels here.
• Existing work: PR341 merged npm/runtime changes, not verified live deployment settings. Open PR343 uses perf/netlify-asset-caching-headers targeting develop; open PR345 uses agent-6ad494753597937a10a0525f targeting main. Their deployment overlap requires coordination, not automatic reuse, rebasing, retargeting, cherry-picking or expansion of this issue.
• Constraints: planning only. No branch, PR, repository edit, installation, hook, build, Git LFS operation, account change, upload, recovery, migration, merge or deployment authorised.

Expected file changes

Provisional readiness-first subset, not a complete implementation plan. D is the revision above; existence of evidence files does not approve their modification.

No moves, deletions, executable files, dependencies or configuration edits in this subset.

The guide must preserve these gates:

• Provider and workflow: GitHub + Netlify remains a planning baseline. Consume the storage-evaluation recommendation, reviewed migration design and final catalogue contract. Obtain explicit implementation approval, including upload/tagging workflow. Existing decision-log “zero-cost” claims and checked specification tasks are not approval evidence.
• Capacity and access: recovered-file sizes, variant demand, storage growth, checkout frequency, bandwidth and build demand remain unmeasured here. Confirm account-specific GitHub/LFS and Netlify allowances, billing limits, authorised access and budget using dated evidence. Do not adopt the decision log’s “>1GB/month” wording as a verified LFS trigger.
• Runtime and deployment: .nvmrc contains 24; package.json declares Node >=24, npm scripts and the npm lockfile; src/app/netlify.toml specifies npm build, Node 24 and npm 10. These contradict stale guidance but do not prove the live runtime. Confirm production branch, base/package directories, effective configuration, build/publish settings, LFS checkout behaviour and deployment-context overrides from authorised account/build evidence.
• Configuration paths: D’s root listing contains neither .gitattributes nor root netlify.toml; nested src/app/netlify.toml exists. Do not create root configuration, edit the nested file, add LFS patterns, move files or rewrite Git history by assumption. After decisions and overlapping PR disposition, obtain a revised exact configuration/test-file plan and approval.
• Acceptance: representative checkout/deployment results, pointer resolution where applicable, measured build behaviour, monitoring and rollback remain outstanding. Unknown recovery yield stays unknown; assess print suitability without promising print-ready delivery. Image processing and reference migration remain separate work.

Preserve protected assets/references, fallback component, Supabase artefacts, attribution, changelog, task-list and centrally managed workflows. Locked governance and templates remain human-controlled. Resolve changelog applicability and future build requirements or an approved documentation-only exception separately.

Saving this appendix may synchronise publicly; exact-preview approval must cover that disclosure. Exclude credentials, private billing details and restricted assets. Approval to append this plan does not authorise implementation or change status, ownership, hierarchy, labels, relationships or PR associations.