bug: assets - Restore original Figma artwork #7

Describe the bug

The audit reports 75 unique figma:asset/ references, an empty src/assets/ directory and placeholder substitution in vite.config.ts. This count is reported evidence, not independently verified.

To Reproduce

Inventory references and available assets; inspect build warnings and affected pages for placeholder artwork.

Expected behavior

Available original Figma artwork resolves correctly instead of placeholder substitution.

Current status — 19 October 2026

In Progress. The current source baseline is 128 literal Figma-hash references covering 56 distinct IDs, matching the catalogue. This is not a recovery yield or an explanation of the historical 75-asset count.

A 12-ID pilot selection and recovery-support scripts exist. Selected IDs are not recovered samples. Tracked files do not establish recovered originals, verified replacements or completed restoration; external runs remain unknown.

Screenshots

Supplied audit. No additional visual comparison supplied.

WordPress Environment

Not applicable: Figma Make-generated React/Vite frontend hosted on Netlify.

Device and Browser Info

Browser, accessibility and Lighthouse testing not performed by audit.

Additional Context

• Obtain original Figma Make exports and reconcile with referenced assets.
• Restore available artwork with verified mappings; document unavailable exports.
• Confirm restored assets resolve during builds without placeholder substitution.
• Perform visual review of affected pages and check image-loading regressions.
• Preserve existing Vite asset-resolution behaviour unless a change is explicitly required.

Asset exports are a dependency. Hosting configuration cannot restore missing artwork. Audit applied no changes.

Figma extraction and media-library handoff

• Run a read-only Claude/Figma extraction pilot against the editable TOA Make project. Inventory existing website images and their source references and page/component usage; retrieve accessible assets without changing the project or repository.
• Reconcile the recovered assets with the reported 75 unique figma:asset/ references. Treat that count as unverified until independently checked.
• Distinguish original exports from rendered derivatives, record dimensions and formats, and document inaccessible assets and manual-export gaps. Do not assume Make supports automatic recovery of every original.
• Compare recovered artwork with the images on thisonetimeonacid.figma.site / thisonetimeonacid.com and verify replacement mappings before changing existing protected references.
• Hand verified source references, filenames, dimensions, usage and available credits/rights to the catalogue defined in epic: media-library - Define asset recovery and library strategy #267. Flag missing metadata rather than inventing it.

The extraction pilot does not authorise uploading assets to a new service or replacing references. GitHub + Netlify is approved for planning only; provider evaluation and implementation approval remain separate gates.

Read-only recovery pilot brief

Outcome

Produce a reproducible inventory and representative asset sample from the editable TOA Figma Make project, distinguishing original exports, rendered derivatives and inaccessible assets.

Prerequisites

• Confirm the editable project link, authenticated access and permitted extraction method.
• Confirm where recovered samples may be saved.
• Agree which pages/components constitute the representative sample.

These inputs remain unconfirmed; this brief does not authorise execution.

Pilot procedure

1. Inventory source references
   • Record unique asset IDs and total occurrences separately.
   • Map references to pages/components.
   • Reconcile the historical claims of 75 references, 56 unique IDs and 128 occurrences; do not assume they measure the same thing.
2. Retrieve representative samples
   • Use only the confirmed, permitted read-only method.
   • Record whether each file is an original export, rendered derivative or of unknown provenance.
   • Document inaccessible assets and manual-export requirements. Do not assume every original is recoverable.
3. Verify provenance and usage
   • Record source reference, filename, format, dimensions and page/component usage.
   • Compare samples with the published artwork to propose mappings—not apply them.
   • Record available credits and rights; mark missing information as unknown.

Deliverables

• Inventory with extraction method, date, counting rules and reproducible steps.
• Representative recovered files in the approved location.
• Proposed source-to-usage mapping with confidence and supporting evidence.
• Gap log covering inaccessible assets, uncertain provenance and manual-export needs.
• Handoff identifying which samples can support website and book-publishing evaluation.

Success criteria

• Counts are reproducible, with discrepancies explained or explicitly unresolved.
• Every retrieved sample has provenance, format, dimensions and usage recorded.
• Originals and derivatives are clearly distinguished.
• Proposed mappings have visual evidence; uncertain matches remain unapproved.
• Access limitations, rights gaps and recovery failures are documented.
• No project, repository, website or hosting configuration has changed.

Boundaries and stop conditions

No Figma edits, repository commits, reference replacements, provider uploads, purchases or configuration changes. Stop if retrieval requires additional permissions, bypassing access controls or modifying the source project.

The pilot establishes recovery feasibility; it does not complete artwork restoration or demonstrate print readiness.

Linked Stories/Tasks/PRs

No implementation PR or epic supplied.

Milestones & Timeline

Estimate L. No milestone or deadline requested.

Acceptance Criteria

• Reconcile unique assets, static imports, runtime references and historical counts.
• Record recovered originals, derivatives, source metadata and inaccessible/manual-export gaps; mark unknown credits and rights explicitly.
• Restore only verified, authorised mappings; preserve protected references and unrelated behaviour.
• Record build, image-loading and visual-comparison results across affected pages.

Definition of Ready (DoR)

• Recovery outcome and export dependency are documented.
• Source access, representative exports, replacement permissions and review scope are confirmed.

Definition of Done (DoD)

• Recovery and validation evidence satisfies the criteria; remaining gaps are reviewed.
• Applicable implementation contributions are approved and merged, with required documentation/changelog handling.

Immediate next steps

Confirm authenticated access, permitted extraction and sample destination. Recover representative originals or derivatives, document inaccessible/manual-export gaps and propose visually evidenced mappings. Do not replace protected references without explicit approval.

Evidence required

Reproducible inventory, recovered files, extraction manifest, provenance, dimensions, original/derivative classification and verified mappings; subsequently authorised build and visual-regression results.

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.

Relevant requirements: US1, FR-001–005. T039–T043 provide recovery context, but do not deliver authorised restoration. T039’s allocation conflicts with the current separation between capability evaluation and actual recovery.

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

• Specification
• All planning docs

Asset Inventory Reconciliation Complete (2026-10-17)

✅ Discrepancy Resolved: Verified asset count is 56 unique assets (not 75 as historically claimed).

Key Reconciliation Findings

Root Cause of 75 vs 56 Discrepancy

The 75-asset claim originated from an earlier audit before repository refactoring. Current verified inventory (56) reflects:

• Figma Make deduplication (removed duplicate asset IDs)
• Codebase consolidation (merged redundant imports)
• Asset cleanup since historical audit

Impact: 19 fewer assets = faster recovery + simpler migration

Phase 1 Action Items (Reduced Scope)

Phase 1a: Catalogue Population (Week 1)

• Extract and standardize metadata for all 56 assets
• Populate FULL-CATALOGUE.json with dimensions, credits, usage context, print-readiness
• Complete 38 unmapped asset definitions

Phase 1b: Recovery Pilot (Concurrent, 3–5 days)

• Sample 10–15 assets via Figma Make extraction
• Assess export fidelity and identify manual-export gaps
• Document recovery method per asset category

Phase 1c: Infrastructure (Parallel, 2–3 days)

• Configure Git LFS for asset tracking
• Validate Netlify deployment and cost (confirm zero-cost assumption)
• Draft team workflow documentation

Verified Data Source

All reconciliation data from consolidated audit reports (develop branch):

• 01-asset-inventory.json — complete 56-asset inventory
• SAMPLE-CATALOGUE.json — schema template with sample records
• EXECUTIVE-SUMMARY.md — audit findings and recommendations

Consolidated via: PRs #296 + #297 (merged 2026-10-17)

Acceptance Criteria Status

• Reconcile unique assets, static imports, runtime references and historical counts
• Record recovered originals, derivatives, source metadata and inaccessible/manual-export gaps
• Restore only verified, authorised mappings; preserve protected references
• Record build, image-loading and visual-comparison results

Proceed with Phase 1 catalogue population and recovery pilot.

Unanswered clarification questions

These questions clarify the recovery pilot. They do not authorise extraction, reference replacement, provider upload or configuration changes.

1. Is authenticated access to the editable Figma Make project available?
2. Which read-only extraction method is permitted?
3. What sample destination and representative pages or components are approved?
4. Who will review the proposed asset mappings and identify unresolved or missing artwork?
5. What revision-specific evidence should distinguish recovered files from reference inventories and qualify the conflicting historical count and reconciliation claims?