aiops: media-library - Evaluate Figma skills and agent-assisted asset recovery #282

AI Ops Summary

Evaluate existing Figma skills before proposing custom skills or a specialised agent for TOA asset recovery.

Build Summary

Not applicable: this evaluation does not authorise building an agent or changing repository or Figma content.

Current status — 19 October 2026

In Progress. The extractor resolves image hashes through the file image map. Validation/catalogue-update scripts and mocked CLI tests exist; those tests were not run in this audit.

The separate access-test script still treats hashes as node IDs. No tracked authenticated results, extraction manifest or recovered files establish successful live recovery.

Linked Stories/Tasks/PRs/Epic

Parent: #267. Actual extraction, reconciliation and restoration remain in #7. No implementation PR specified.

Milestones & Timeline

Not set.

Problem / Opportunity

Determine whether existing Figma skills and authenticated access support asset recovery, and whether recurring work justifies reusable instructions or a specialised agent.

Approach / Solution

Assess authenticated Figma Make access and extraction capabilities. Evaluate recovery fidelity and original-versus-derivative limitations. Document manual-export fallbacks and safeguards against unapproved modifications.

Acceptance Criteria

• Record tested Figma/Make capabilities, access prerequisites and permission failures.
• Assess representative recovery evidence for fidelity, formats, metadata and original/derivative limitations.
• Document manual-export fallbacks, inaccessible assets and repeatability limits.
• Recommend existing skills, reusable instructions or a specialised agent using evidenced recurring needs.

Additional Context

Keep actual extraction, reconciliation and restoration in #7; do not duplicate that implementation scope. This evaluation does not authorise building an agent or changing repository or Figma content.

Use the approved AI Ops title prefix aiops: rather than the template's conflicting automation: pattern. The shared template itself is unchanged.

Definition of Ready (DoR)

• Evaluation boundary and read-only safeguards are documented.
• Access, permitted checks and recovery handoff are agreed.

Definition of Done (DoD)

• Findings distinguish observations, documented claims and unknowns; limitations and recommendation are reviewed.
• Evaluation does not imply repository/Figma changes, external uploads or an agent build.

Immediate next steps

Evaluate existing Figma skills and the implemented method against permitted authenticated Make access. Separate static findings, mocked coverage and observed capabilities. Document permission failures, fidelity limits, manual alternatives and reusable-skill suitability.

Evidence required

Capability matrix, access prerequisites, observed outputs/limitations, recovery evidence from the recovery issue and a reviewed skill/agent recommendation. Tool availability does not establish extraction success.

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: US5, FR-001 and FR-005. T003 explicitly references this evaluation; T039–T043 provide supporting context. T039’s extraction scope conflicts with this issue’s capability-only boundary; reusable-skill suitability is not explicitly tasked.

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

• Specification
• All planning docs

Branch instructions

• Repository: lightspeedwp/ThisOneTimeOnAcidCom.
• Bounded outcome: evidence-backed assessment of existing Figma skills and the tracked recovery method, with an explicitly unexecuted access/evidence protocol. No agent implementation, asset recovery, catalogue update or infrastructure work.
• Evidence baseline R: develop 4ecdb26d9655a48bf000a7c89da2f70383edce87. Organisation baseline O: 8f28eca80bff198879f7aaf496717dc0551bb32e.
• Proposed branch: aiops/media-library-figma-capability-evaluation.
• Branch state: proposed new branch, not created or reused. No matching head or evaluation PR appeared in the refreshed 38-branch/16-open-PR inventory. Refresh before separately approved work; do not repurpose unrelated branches.
• Base: refreshed develop, checked at R.
• Naming policy: local validator authorises aiops; use the documented type/scope-title pattern. Naming inspected statically, not executed.
• PR template: O’s route map maps aiops to the AI Operations template. Local workflow lacks aiops and falls back to pr_default.md/type:maintenance; local script falls back to default/type:task. Obtain maintainer disposition before PR creation. Routing is not automatic body insertion; do not blindly adopt template labels or attribution. No template, taxonomy or workflow changes included.
• Parent context: preserve coordination hierarchy; withhold parent identifiers/links from branches, PRs, commits and coding prompts while association effects remain unverified. Never use an epic as a native development or closing target.
• Allowed closing targets: none for this partial contribution. Any future contextual reference or native association requires separate review; no linking syntax is assumed safe or authorised here.
• Constraints: description planning only. Prior issue plans are guidance, not implementation. No repository edits, branches, PRs, authenticated checks or execution authorised.

Expected file changes

Provisional assessment-only contribution. Evidence read at R; new destinations are proposed. Repository conventions require prompt/report frontmatter and findings-based task tracking. Existence of source evidence grants no edit approval.

No moves, deletions, executable changes, dependency additions or historical report rewrites.

Evidence and readiness gates

• The extraction helper resolves image hashes through meta.images, downloads files and writes a manifest. The access-test helper supplies an image-reference hash as a node ID, performs authenticated requests and writes a report. Neither is a harmless static capability probe; do not run them under this plan.
• Tracked recovered-assets material contains a selection and placeholder report, not recovered binaries or an extraction manifest. Historical success claims are not independently established by those artefacts. Record discrepancies without treating them as recovery evidence.
• Spec 002 US5/FR-001/FR-005 and T003/T039–T043 inform assessment, but extraction language exceeds this issue’s evaluation-only boundary. Checked tasks are not authenticated evidence. Actual extraction/restoration remains separate recovery work.
• Confirm existing skill inventory/versions, reviewer, acceptable sources and changelog disposition. Recommend existing skills, reusable instructions or no automation; do not presume a specialised agent is justified.
• Future authenticated checks need separate approval of principal, file/sample scope, request limits, storage/redaction and access. Do not request secrets in issue content.
• Distinguish static observations, documented claims, mocked coverage and observed authenticated results. Fidelity, original/derivative status, print suitability and repeatability remain unknown without evidence.

Preserve protected images/references, fallback component, attribution, changelog, Supabase utilities, locked governance and managed workflows. No installs, scripts, tests, hooks, builds, extraction, recovery, network/cloud probes or uploads included. Exclude credentials, private account data and restricted assets from public sync. Documentation alone does not complete the issue; description approval grants no implementation or execution authority.