audit: media-library - Validate recovered assets #288

Audit Summary

Validate recovered Figma assets and catalogue evidence supplied by the recovery work.

Additional Context

Dependent on #282 pilot completion. This issue covers validation of the 12-asset pilot recovery and preparation for full 56-asset recovery.

Acceptance Criteria

• Reconcile sample size, inventory counts and recovery-success thresholds.
• Record source, original/derivative status, dimensions, format and fidelity per reviewed asset. Record print-suitability findings, unknowns and delivery gaps per reviewed asset; print-ready delivery remains deferred.
• Validate catalogue entries and explicit unknowns.
• Document defects, inaccessible assets and manual-export implications.

Dependencies

Dependency roles: capability findings inform recovery; recovered samples support this audit. #279 supplies initial modelling, #281 supplies migration design, #289 supplies final schema approval, #290 supplies configuration evidence and #291 supplies implementation evidence. These descriptions do not create blocking relationships.

• Blocked by: aiops: media-library - Evaluate Figma skills and agent-assisted asset recovery #282 (pilot completion required)
• Related: content-model: media-library - Define the asset catalogue and provenance model #279 (catalogue schema), design: media-library - Design the import and reference-migration workflow #281 (migration script)

Deliverables

• Recovery validation report
• Quality assessment of exported assets
• List of manual intervention requirements (if any)
• Recommendations for design: media-library - Design the import and reference-migration workflow #281 implementation

References

• aiops: media-library - Evaluate Figma skills and agent-assisted asset recovery #282 Recovery Pilot Plan: .github/reports/toa-media-library/TOA-280-RECOVERY-PILOT-PLAN.md
• Sample Catalogue: .github/reports/toa-media-library/SAMPLE-CATALOGUE.json

Immediate next steps

Obtain actual samples and provenance from recovery work, informed by capability findings. Agree the sample and criteria, then assess originals/derivatives, dimensions, formats, fidelity, catalogue consistency, rights unknowns and print suitability.

Evidence required

Asset-level pass/fail/unknown results linked to files/manifests, defects, manual-export requirements and reviewed catalogue discrepancies. Print-ready delivery remains deferred; this audit does not perform extraction or restoration.

Current status — 19 October 2026

Backlog. The 12-ID selection contains valid catalogue/source IDs, not recovered samples. Validation tooling exists, but tracked files do not establish an executed pilot or asset-validation report.

Definition of Ready (DoR)

• Audit outcome and recovery/catalogue relationships are identified.
• Pilot results, representative files, quality criteria and reviewer are available.

Definition of Done (DoD)

• Reviewed report links asset-level results and unresolved gaps.
• Findings inform schema finalisation and migration design without claiming full recovery.

Specification references

• 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 scope: US1–US2, T019 and T024 pilot/schema checks. T032–T035 define supporting checks rather than evidence of executed validation. Recovered samples and agreed thresholds remain prerequisites.

Branch instructions

• Repository: lightspeedwp/ThisOneTimeOnAcidCom.
• Implementing target: this recovered-asset validation audit; counterpart GitHub issue 288. Assess supplied recovery evidence; do not extract, restore or migrate assets.
• Evidence: D = develop at 4ecdb26d9655a48bf000a7c89da2f70383edce87; G = organisation governance at 8f28eca80bff198879f7aaf496717dc0551bb32e, checked 20 October 2026.
• Branch state: proposed new branch, not created. Absent from the returned 38-branch inventory; exact-head PR search returned no matches. Refresh before separately authorised creation. No automatic reuse, rename, reset, cherry-pick or force-push.
• Proposed branch: audit/media-library-recovered-assets.
• Starting point and PR base: refreshed develop, not production main.
• Naming authority: local guide and validator authorise audit and the type/scope-title pattern. Static inspection only; no validator executed. Older root-guide statements about absent prefix lists conflict with current evidence.
• Existing work: the surviving fix/toa-media-library-coderabbit-findings branch belongs to merged PR296’s mixed testing/audit contribution, not a verified active match. PR321 merged recovery scripts; PR313 merged specification/research material. Neither proves recovered samples or completed validation.
• PR template unresolved: G’s route map maps audit to pr_feature.md, but its branching strategy names pr_audit.md. The local script falls back to default/type:task; the workflow suggests pr_default.md/type:maintenance, and that template filename is absent from the inspected shared directory. Obtain maintainer disposition and explicit selection before PR creation. Do not assume automatic loading, adopt feature defaults or repair workflows/templates/labels here.
• Parent context: retain existing hierarchy. Do not propagate parent identifiers/URLs into branches, PRs, commits or implementation prompts; never use the parent as a native development or closing target.
• Allowed closing targets: none for partial work. Any future association with this issue or counterpart requires separate review.
• Constraints: description planning only. Prior branch/file plans are guidance, not completed implementation. No repository edits, execution, branch/PR operations, merge or deployment authorised.

Expected file changes

Conditional plan for the audit outcome, not documentation standing in for unperformed validation. Existing evidence inspected at D; proposed destinations absent from inspected parent listings. Separate repository-write and audit-execution permission required.

No moves or deletions. New report location follows root reports/topic guidance; preserve historical reports and recovered-assets material without relocation or wholesale rewriting.

Readiness and audit boundaries

• Recovered-assets currently contains a selection file and placeholder report, not tracked recovered binaries, extraction manifest or validation output. Selected-ID counts and total counts are inventory claims, not recovery results. Reconcile sample identities with catalogue/source records; do not adopt unsupported print assertions.
• Recovery yield remains unknown. Assess print suitability and document gaps; print-ready delivery is deferred. Historical percentages, pixel dimensions or DPI claims are not automatically acceptance gates. GitHub + Netlify remains planning-only.
• Use provisional modelling/criteria to produce findings for final schema approval; do not impose a circular dependency on an already-final schema. Schema/runbook reconciliation remains separate.
• Record source, original/derivative uncertainty, measured dimensions/format, visual fidelity, rights/credit unknowns and print-suitability gaps. Classify pass/fail/partial/unverifiable with evidence; missing evidence is not a pass. Human visual review is required where originals are accessible.
• Existing extracted-assets validator checks partial PNG headers, sizes and catalogue dimensions; it skips non-recovered records and overwrites a validation-report output. Its percentage describes recovered entries, not total recovery yield. It cannot establish complete integrity, fidelity, rights, schema compliance or print readiness. Use/output preservation requires separate permission; no validator changes proposed.
• Preserve protected images/imports/references, fallback component, attribution, changelog, Supabase utilities and human-controlled configuration. No catalogue updates, scripts, dependencies, installations, builds, tests, recovery, uploads or cloud actions included.

Exclude credentials, private account details and restricted recovery material from publicly synced content. Approval to append this plan changes no status, ownership, labels, relationships, hierarchy or PR associations and grants no implementation or execution authority.