Imported from shotcowboystyle/meta-wearables-ops-plugin (.agent/skills/meta-wearables-full-sdk-audit/SKILL.md). Install upstream with npx skills add shotcowboystyle/meta-wearables-ops-plugin --skill meta-wearables-full-sdk-audit. Copyright stays with the author.

Meta Wearables full-SDK audit

Use this role before implementation when “full SDK,” “regular SDK,” “all capabilities,” or cross-platform parity could hide an unverified module, consumer feature, stale upstream example, or unsupported device claim.

Read before acting

• Inspect the real iOS package graph or Android Gradle dependency graph, target settings, privacy files, and existing adapter.
• Read the full capability and source-conflict matrix, the device-generation and runtime-support matrix, the iOS API atlas, the Android API atlas, the plugin matrix, and the Android parity route.
• Read input, sensors, and physical interaction before treating IMU, EMG, temple, browser sensor, or Display input wording as a complete capability.
• Read the version-dependency and device-compatibility route before treating Gen 2/Gen 3, firmware, companion versions, or support-table values as resolved.
• Load the portable source-pinned surface manifest before a full-SDK/parity audit; use it as a routing snapshot, never as generated API or hardware proof.
• Load the portable Meta team manifest and run python3 ../meta-wearables-agentic-team/scripts/validate_team_manifest.py in the workspace; use it to prove that selected upstream roles have local owners and device-claim gates.
• Resolve user wording through the manifest terminology_contract before routing; “regular SDK” is an ambiguous phrase, “full SDK” is a composite audit, and “Gen 3” remains an unresolved alias until official and named-device evidence close it.
• Load its preflight_contract, read the target-preflight packet, and select the relevant PRE-* tasks before build, connected, physical, signed, or release-channel work; preflight freezes facts but does not upgrade evidence.
• Load the portable capability/evidence plan and run python3 scripts/validate_capability_evidence_plan.py; use it to carry owner roles, implementation route, privacy path, fallback, minimum evidence levels, and proof task IDs for every selected capability.
• Filter api_surface.rows by the selected journey/platform and carry each row's source anchors, status, compile/runtime gate, privacy path, fallback, and migration note into the audit; these rows remain source routing, not generated-API or physical proof.
• Run python3 scripts/validate_surface_manifest.py after any manifest edit and before packaging; treat count, exact upstream plugin-role list, source-anchor, required-field, duplicate-ID, and secret-scan failures as refresh blockers.
• Run python3 scripts/validate_capability_evidence_plan.py after any capability/evidence-plan edit and before packaging; treat capability-ID, surface, preflight-task, evidence-task, level, duplicate, and secret-scan drift as blockers.
• Read the on-device compliance and runtime contract for processing location, consent, raw-data, thermal, network, retention, and fallback claims.
• Read the operational readiness and recovery route for firmware, companion, on-glasses DAT-app provisioning, Developer Mode versus release-channel, version-dependency, and recovery claims.
• Read the application architecture and platform-boundaries route when the request spans iOS, Android, native Display, Web Apps, shared state, or a phone fallback.
• Read Developer Center project and release operations when the request includes app identity, permission rationale, versions, channels, testers, telemetry, or release access.
• Read the security, attestation, and credential-boundaries route when the request includes identity keys, callbacks, Developer Mode, release attestation, package/signing credentials, Web App origin, privacy-manifest/App Store gates, or an “on-device” trust claim.
• Read transport, audio, and runtime reliability when the request includes Wi-Fi/local network, Bluetooth/link behavior, HFP/A2DP, backpressure, latency, thermal/power, disconnect, or recovery.
• Read debugging, observability, and diagnostic evidence when the request includes a DAT failure, live DAT Inspector/MCP, readiness, event/error diagnosis, or a diagnostic handoff.
• Refresh the official DAT iOS repository, iOS changelog, DAT Android repository, Android changelog, Web Apps toolkit, full platform reference, and Wearables MCP.
• Read the capability audit fixture when evaluating a “full SDK” or parity brief.

Audit workflow

1. Freeze platform, target, OS/min SDK, package/artifact version, repository revision, Meta AI version, device wording, requested capabilities, and intended evidence level.
2. Load the source-pinned manifest, team manifest, resolve terminology_contract, and load the capability/evidence plan; select the matching journey, platform atlas, API-surface rows, capability row, mapped PRE-* tasks, owner role, implementation route, privacy path, fallback, minimum evidence levels, proof tasks, source conflicts, generation status, and evidence IDs before making a coverage claim.
3. Inventory the exact upstream plugin roles and agent-facing root surfaces from each manifest source_inventory.<lane>.plugin_roles list before mapping them to local handoffs; a role count without exact-name coverage is incomplete. Then verify the lane AGENTS.md, README.md, install-skills.sh, .codex-plugin/plugin.json, and public docs MCP references as source/tool routing inputs only. Then inventory native modules: iOS MWDATCore, MWDATCamera, MWDATDisplay, MWDATMockDevice, and the test-only MWDATMockDeviceTestClient; Android mwdat-core, mwdat-camera, mwdat-display, mwdat-mockdevice; and Web Apps as a separate hosted runtime. Keep test-process products separate from runtime capability claims.
4. Use the platform-specific API atlas to resolve exact iOS package products and Android Maven artifacts/symbols before comparing cross-platform concepts.
5. Map every requested capability to current, to-verify, source-conflict, unsupported, or a platform-specific fallback. Include registration, permissions, device selection, session, camera/photo, audio, Display, sensors, health/update, MockDevice, debugging, privacy, and release.
6. Search upstream AGENTS.md, plugin skills, samples, changelog, API reference, and MCP results for stale versions or conflicting symbol/config guidance. Let the selected artifact/API reference win only after recording the conflict and target build gate.
7. Separate consumer product wording, SDK model identity, and observed runtime capability. Treat “Gen 3” and “regular SDK” as unresolved until the current source and named target establish them.
8. Classify each data path as glasses-native, phone-local, remote, mixed, or unknown; audit consent, retention, lifecycle/thermal behavior, and the typed fallback for every requested capability.
9. For any registration, session, update, or release failure, freeze the full operational tuple and route the first failing state through the recovery contract; keep attempted recovery separate from observed recovery.
10. Define the shared product/domain contract and platform-specific adapter boundary; preserve iOS, Android, native Display, Web App, and phone fallback semantics rather than flattening them into a common symbol set.
11. Return the smallest implementation route, missing proof rows, phone/web fallback, compliance owner, privacy owner, and next source-refresh trigger.

Fast path

Filter the request into platform, surface, and capability rows, run the terminology contract first, then count coverage and evidence gaps. Use a full-surface traversal only when the request is genuinely full or parity-focused; for one feature return selected rows plus the explicitly non-selected lanes.

Required output

• exact source/package/artifact snapshot and date;
• manifest ID/revision, selected journey, and manifest rows used;
• team manifest ID/revision, selected local role IDs, upstream handoff IDs, and device-claim gates used;
• exact upstream iOS, Android, and Web Apps plugin-role lists, counts, and local handoff coverage;
• terminology-contract term, resolution status, canonical route candidates, and evidence boundary used to interpret the user’s device/SDK wording;
• selected preflight contract reference, applicable PRE-* task statuses, and redacted target/dependency/identity/data-path handoff;
• selected capability/evidence-plan entry with owner roles, implementation route, privacy path, fallback, required evidence levels, and proof task IDs;
• normalized API-surface row IDs used, including source anchors, status, compile/runtime gates, privacy paths, fallbacks, and migration notes;
• full-reference journey-section inventory covering setup/hardware, iOS, Android, Display, lifecycle/permissions, HFP/A2DP, MockDevice, AI/MCP/tooling, organization/project/release-channel administration, and Web Apps;
• full module and capability matrix with platform-specific symbols;
• dedicated iOS and Android API-atlas snapshots, including artifact/source/ compile status and the Android Session/DeviceSession conflict;
• stale/conflicting source ledger and migration actions;
• product-label, SDK-identity, and runtime-capability matrix with explicit Gen 2, Meta Glasses, Display, and Gen 3 treatment;
• target, account, permission, privacy, device, firmware, and release gates;
• version-dependency access state, full phone/companion/on-glasses-DAT-app/ firmware/artifact/runtime tuple, first-party versus community signal class, and COMP-* compatibility evidence rows;
• organization/team/project/platform-app, permission-rationale, version/build, tester/channel, telemetry, and account-recovery gates when distribution is in scope;
• processing-location, network/storage, consent, thermal/lifecycle, and fallback contract;
• transport-hop, iOS/Android configuration/parity, audio-route, queue/backpressure, thermal, and recovery contract;
• read-only debug-server/MCP baseline, first-failure graph, platform state/error map, narrow event digest, redaction review, and DBG evidence rows when diagnosis is in scope;
• operational tuple, Developer Mode/release-channel distinction, provisioning state, first failure, bounded recovery, and post-action evidence;
• shared state/event contract, platform adapter map, concurrency/resource ownership, stale-event strategy, and reducer/fake/mock/browser/physical test seams;
• mock/browser/connected/physical evidence plan;
• explicit Gen 2 mapping and Gen 3 to-verify status unless current official mapping and named-device evidence establish otherwise;
• unresolved gaps. Never return “full SDK” as an unqualified conclusion.

Hard boundaries

• Never count a repository plugin role, llms.txt entry, or MCP search result as a compiled target module or hardware capability.
• Never translate Swift symbols into Kotlin or Web APIs by naming similarity.
• Never treat the Android sample’s phone AudioRecord as a glasses microphone, or the iOS HFP route as an Android DAT audio API.
• Never map “Gen 3” to .metaGlasses, .rayBanMeta, Display, or any product announcement without a current public mapping and named runtime evidence.
• Never call a mock, browser simulator, compile, account configuration, or signed artifact physical or production proof.
• Never include tokens, client credentials, raw media, device identifiers, or private diagnostic payloads in the audit or archive.

Related routes

• Meta agentic team
• DAT API atlas
• DAT Android API atlas
• Developer Center operations
• Transport and runtime reliability
• Debugging and observability
• Input and sensors
• DAT iOS integration
• DAT Android integration
• Web Apps
• Device proof
• Device compatibility
• Operational readiness
• Application architecture
• Source refresh

Sources

• Full capability and source-conflict matrix
• Device-generation and runtime-support matrix
• Version-dependency and device-compatibility evidence
• Source-pinned surface manifest route
• Capability/evidence plan
• DAT iOS repository
• DAT iOS AGENTS.md
• DAT Android repository
• DAT Android AGENTS.md
• Web Apps toolkit
• Full Wearables platform reference
• Wearables MCP
• Ray-Ban Meta Gen 2 announcement
• Meta Glasses announcement