test-native-extension

Runs the 4-layer validation ladder for a third-party control repo — the one that ships as a .ppmplugin binary bundle, not as a TypeScript extension. Layers 1–4 are automated; Layer 5 is interactive (requires a real device or simulator and the Companion PCF deployed to a test environment).

Run order is layer-by-layer for Layers 1–4. Stop on the first failure in the automated layers. Layer 5 is not gated by the skill — it prints the device recipe and exits; the user runs it on their own time and updates .extension-state.md manually.

What this skill does NOT validate: native code compilation into a loadable DEX / framework. That's the job of /build-android-binary and /build-ios-binary — they run the real Gradle / xcodebuild toolchain against the pinned RN version and surface the real compiler error. Standalone pod lib lint and ./gradlew assembleDebug from this skill would give false-confidence (they resolve dependencies from public CDN/maven, not against the wrap host's pinned versions). This skill is the structural pre-flight that runs in seconds with no toolchain — it asserts the native source is shaped correctly (right base class, right symbols, the Android getName() ↔ iOS +moduleName ↔ manifest agreement) so the build skills don't fail late on a fixable-in-seconds mistake. There is no TypeScript / INativeExtension layer in this track to type-check — a native-only .ppmplugin bundle dispatches straight to NativeModules.<nativeModule>.<method> (ppmplugin-format §2 — Runtime dispatch contract).

1. Read shared/shared-instructions.md, shared/naming-conventions.md, shared/ppmplugin-format.md.

2. Apply the per-skill minimal prereq policy (shared-instructions.md §1.5). Layers 1–3 need no toolchain (pure read + grep + validate against the working tree). Layer 4 needs Node + npm only when a PCF is present — and only for the first run (to npm install the PCF's own deps from the public npm registry). This track is self-contained and requires no package-feed or source-control authentication (shared-instructions §0a). Run the /test-native-extension check from prereq-check.md (Layers 0–3 need nothing; Node + npm only if a PCF is present for Layer 4 — there is no "baseline" check in this self-contained track).

   Print the prereq status as a visible block per shared-instructions.md §9.2 before continuing:

   Copy

   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    Prereq check — /test-native-extension
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   
    🟢 ✓ git installed
    🟢 ✓ Node 20+ installed            (only needed for Layer 4 — PCF compile)
    🟢 ✓ npm installed                 (only needed for Layer 4 — PCF compile)
   
    🟢 3 checks passed. Ready to proceed.

   If no pcf/ is present, Node/npm aren't needed at all — note them as n/a (no PCF) rather than failing. Layers 1–3 always run regardless. If any check fails, print the → Fix: line for that check and STOP.

3. Read ./PRD.md. If missing, the Layer 3 contract asserts fall back to the native source itself as source-of-truth (it's still useful) — note it and continue rather than STOP.

4. Read ./.extension-state.md. If Phase is below manifest (no native module on disk yet), STOP — there's nothing scaffolded to test.

OS-neutral — run these checks with the built-in Read/Grep tools, not a shell. Every extraction/assert in this skill (the find / grep / sed / awk snippets below) is shown in bash for readability only — it describes what to match, not a shell to execute. RUN them with the agent's built-in Read and Grep tools (plus your own parsing), which behave identically on macOS, Linux, and Windows PowerShell. Do NOT shell out to grep/sed/awk/sort/find — they aren't on a stock Windows box, and Layers 0–3 are deliberately pure read+parse (no toolchain) so they run everywhere. Layer 4's npm run build is the only real command, and npm is cross-platform.

First, auto-detect whether the PCF companion is on disk — use the Grep tool (glob: pcf/**/ControlManifest.Input.xml) so case differences and minor layout variations don't trip the check. (Illustrative bash — don't run it verbatim on Windows):

PCF_MANIFEST=$(find pcf -type f -name "ControlManifest.Input.xml" 2>/dev/null | head -1)
[ -n "$PCF_MANIFEST" ] && PCF_PROJECT_ROOT=$(dirname $(dirname "$PCF_MANIFEST"))

If $PCF_MANIFEST is set, the PCF is scaffolded; use $PCF_PROJECT_ROOT (e.g. pcf/<Pascal>PCF) for Layer 4's build step. If empty, distinguish: no pcf/ at all → "not yet scaffolded"; pcf/ exists but no manifest → "scaffold appears incomplete; re-run /generate-pcf-companion or inspect the folder."

Also detect the manifest that drives Layer 2. Prefer the committed ./manifest.json (the source of truth /generate-native-extension writes at scaffold time, so it normally exists here, right after scaffold) and fall back to the staged build copy:

MANIFEST=$( [ -f ./manifest.json ] && echo ./manifest.json || ls ppmplugin/staging/manifest.json 2>/dev/null )

If $MANIFEST is empty, Layer 2 is skipped (no manifest on disk yet — a hand-authored module that hasn't run /generate-ppmplugin-manifest; with the scaffold, ./manifest.json is present from the start).

This drives Layer 4 (PCF compile) and Layer 5 (manual recipe — both require the PCF to exist).

Print:

Test plan
─────────
Repo: <cwd>
Extension: @powerapps/extension-<kebab>  (class <Pascal>Extension, module <Pascal>Module)
PCF companion: <found pcf/<Pascal>PCF/ | NOT yet scaffolded>
Manifest: <found ./manifest.json (committed) | ppmplugin/staging/manifest.json (staged) | NONE>

Automated layers (skill runs these and reports pass/fail):
  0. Holistic contract check — native ↔ manifest ↔ PCF cross-grep (warn-only)
  1. Native-source structure — getName()/+moduleName/@ReactMethod asserts + load/init readiness (no-arg package ctor, iOS [cls new]/requiresMainQueueSetup, non-throwing construction)
  2. Manifest validation     — <ppmplugin-format §4 rules | SKIPPED — no manifest>
  3. Native-source contract  — request/response/error grep cross-check
  4. PCF compile             — <npm run build in pcf/<Pascal>PCF | DEFERRED>

Manual layer (skill prints a recipe; you run it on a device on your own time):
  5. Device end-to-end       — <print recipe | DEFERRED>

Not validated by this skill: native iOS / Android compile into a loadable DEX / framework (run /build-android-binary // /build-ios-binary for that).

Stop on first failure: <yes by default>

Use AskUserQuestion:

Run the test plan?

• Run the default set above (recommended)
• Run only Layers 1–3 (skip PCF compile; skip the Layer 5 recipe)
• Run a single layer (specify which)
• Cancel

If the user picks a single layer, validate dependencies — e.g. "Layer 3 (contract asserts) is more useful after Layer 1 (structure asserts) has passed in this run or a recent run; do you want to skip the check and run anyway?". Don't enforce strictly; surface the implication and let the user decide.

Diagnostic layer, not a hard gate. Reports findings; downgrades to warnings rather than blocking. Useful for catching drift between native modules ↔ manifest.json ↔ PCF before the harder-to-debug runtime symptoms surface in Layer 5.

This layer cross-checks the contracts that flow across the native modules, the staged manifest.json, and the PCF. None of these checks compile or run code — they're all grep/parse-based. If any check finds a mismatch, the skill prints a numbered warning with the mismatched values + suggested fix, but continues to Layer 1 unless the user opts to stop. The point is to surface inconsistencies early; the engineer decides which ones matter.

No tsc to run in this track — the control ships as a native binary, not a TS extension. Instead, grep/parse the native module source and assert it is shaped for the wrap runtime and the plugin's upload-compatibility checks. These are the same conformance asserts /build-android-binary and /build-ios-binary run before they compile (ppmplugin-format §5, §5b) — running them here surfaces a fixable-in-seconds mistake before a minutes-long build.

For Android (android/.../<Pascal>Module.kt):

• the module class extends ReactContextBaseJavaModule (the host loads it as a React Native module).
• override fun getName() returns the canonical-prefixed '<Pascal>Module' (ppmplugin-format §3) — and it MUST equal the manifest receivers[].nativeModule if a manifest is staged.
• at least one @ReactMethod fun <m>(...) is declared (a module with no @ReactMethod dispatches nothing).
• a ReactPackage is present (the createNativeModules registration the DEX needs — its FQN becomes entrypoints.android.packageClass).
• no @ReactModule annotation (that's the SDK-era registration path; the wrap host registers via the ReactPackage, not the annotation — its presence is SDK leakage that /audit-ppmplugin rejects).

For iOS (ios/RCT<Pascal>Module.h / .m):

• the header class declares <RCTBridgeModule>.
• No RCT_EXPORT_MODULE(...) macro is present; the .m declares + (NSString *)moduleName and its return string equals Android getName() and the manifest receivers[].nativeModule. The Obj-C class name equals entrypoints.ios.moduleClass.
• at least one RCT_EXPORT_METHOD(<m>:...) is declared, and the method names are a subset of the manifest receivers[].methods[].

Auto-skip only if no manifest was found ($MANIFEST empty per the detection in Step 2 — neither ./manifest.json nor a staged copy). Print ⊝ Layer 2 (manifest validation): SKIPPED — no manifest on disk (hand-authored module). Run /generate-ppmplugin-manifest first. Mark state as n/a. Continue to Layer 3. (With the scaffold, ./manifest.json exists from native-gen, so this layer normally runs right here.)

When a manifest is on disk ($MANIFEST — the committed ./manifest.json or the staged copy), re-run the plugin-maintained upload-compatibility checks locally against it — the same checks /generate-ppmplugin-manifest runs (ppmplugin-format §4). This cheap pre-flight catches common upload failures such as a mis-shaped name or nativeModule before any build. This layer defers to /generate-ppmplugin-manifest as the source of the rule set — it does not re-author the manifest, only validates the one on disk and points back at that skill to fix.

No tsc --noEmit fixtures to run in this track — there's no TS src/ and no src/types.ts whose shape a type-fixture could pin. Instead, this layer grep-cross-checks the request / response / error-code contract between the two native parsers (iOS .m, Android .kt) and the PCF, deriving the expected field set from ARCHITECTURE §4 (or, if no PRD, treating the native source as the source-of-truth). It's the deeper sibling of Layer 0's checks 4–6 — Layer 0 surfaces them warn-only as part of the holistic sweep; Layer 3 gates on them.

For each operation:

• request fields — the NSDictionary key reads in the iOS parser, the ReadableMap key reads in the Android parser, and the PCF's request.<field> build must reference the same field names (ARCHITECTURE §4.1). A field read on one platform but not the other = platform-specific INVALID_INPUT.
• response fields — the keys in the iOS successJsonWith: build, the Android successJson build, and the PCF's response.result.<field> reads must match (ARCHITECTURE §4.2).
• error codes — every code in ARCHITECTURE §5 must be emitted by at least one native site (iOS errorJsonWithCode:message:, Android errorJson(code, message)) and handled by the PCF setError (case or default).
• error message plumbing — the native error helpers must carry a message argument, the PCF's setError(code, message) must be two-arg and assign this.errorMessage, and the ControlManifest must declare the three standard diagnostic outputs (Status, ErrorCode, ErrorMessage) with getOutputs() returning them. This is what makes a field failure debuggable from Power Fx with no native console.

No analogue in this track — always n/a. The mock-context runtime layer instantiated the TS extension class (new <Pascal>Extension(ctx)) and drove handleMessageAsync against minimal/full host-context shapes. The .ppmplugin ships no TS extension class, no handleMessageAsync, and no host INativeExtensionContext — dispatch goes straight to NativeModules.<nativeModule>.<method> over the wrap bridge (ppmplugin-format §2, §6). There is nothing to instantiate off-device.

The equivalent "does it actually run?" assurance for a native-only bundle lives in two places, neither of which this skill can do off-toolchain:

• does the native code compile into a loadable binary → /build-android-binary // /build-ios-binary (real Gradle / xcodebuild).
• does the built .ppmplugin load + dispatch on the wrap runtime → /audit-ppmplugin (the byte-scan + structure gate) and the Layer 5 device recipe.

Print ⊝ Layer 3.5 (mock-context runtime): n/a — native-only track has no TS extension class to instantiate (see /audit-ppmplugin + Layer 5). and continue to Layer 4.

Auto-skip if no ControlManifest.Input.xml was found under pcf/ (per the find-based detection in Step 2). Print ⊝ Layer 4 (PCF compile): SKIPPED — PCF not yet scaffolded. Run /generate-pcf-companion first. Mark state as n/a. Continue to Layer 5.

This layer compiles the Companion PCF — manifest XML + index.ts + any engineer customizations. Catches:

• TS errors in index.ts (introduced by hand-edits after scaffold)
• Property name mismatches between ControlManifest.Input.xml and index.ts (e.g. manifest declares PenColor but the code references p.penColor)
• Missing output property declarations (e.g. §8.3 was edited but the PCF wasn't regenerated)
• Broken pcf-scripts deps

The PCF tooling uses npm, not pnpm — this is a PCF ecosystem convention. Do not unify.

Catches the "the Android build rejects this module on lint" class of bug locally. Real cost on pen-input: 8 Android lint warnings surfaced only when the integration build ran, forcing a patch round-trip. Each could have been caught here.

Android Studio's lint rules are stricter than a quick grep (it checks call patterns, resource references, deprecated APIs, accessibility). /build-android-binary compiles the staging-copy module against the pinned AGP; running ./gradlew lint here first surfaces the same warnings before that build.

This layer is interactive and outside the scope of automation — it requires a built + audited .ppmplugin, the wrap host that loads it, a device or simulator, and the Companion PCF deployed to a test environment. The skill prints a copy-pasteable recipe; the engineer runs it; the skill records the outcome.

Why Layer 5 is NOT redundant after Layers 0–4 all pass. Layers 0–4 verify structure — the symbols line up, the key matches, the manifest is aligned, the PCF compiles. Layer 5 is the first time the actual bytes move over the wire. Wire-format and runtime bugs that every structural layer is blind to — a direct cordova.exec call instead of sendAsync (→ nothing dispatches, silent on Android), the host's re-stringification of the response, the wrap {message} response container the PCF must unwrap, a native-module constructor that throws at startup (→ crash on launch, before any UI), a permission denied at runtime — only surface here. An all-green Layers 0–4 means "the shapes are right," NOT "it dispatches on device." Do not treat a green automated run as end-to-end confidence; the first launch + first tap are the real tests. (Layer 0 checks 1b/12/13 grep for the sendAsync transport, the constructor crash pattern, and the response-unwrap pre-device; the Layer 5 crash-scan below is the definitive catch.)

Print:

Layer 5 — Manual end-to-end validation (interactive)
─────────────────────────────────────────────────────

This validates the full path: Canvas formula → PCF → SendMessagePlugin bridge → NativeModules.<nativeModule>.<method> → response back to Canvas.

PREREQUISITES (one-time per machine):
  • A built + audited bundle: run /generate-ppmplugin (or the stage skills) so ppmplugin/<name>.ppmplugin exists and passed /audit-ppmplugin
  • A wrap host configured to side-load the .ppmplugin (the wrap shell from the wrap pipeline — its load/upload flow is owned there)
  • Active pac auth profile against your test environment (`pac auth list` — star should be on the test env)
  • For iOS device: a provisioning profile that allows running the wrap app on your device
  • For Android device: USB debugging enabled + `adb devices` shows your device

BUILD & AUDIT THE BUNDLE (each iteration of the control):

  # 1. From the control repo, produce a verified bundle:
  cd <this repo>
  /generate-ppmplugin
  # → drives manifest → build-android/ios → assemble → audit; lands ppmplugin/<name>.ppmplugin

  # 2. Confirm it's READY TO UPLOAD:
  /audit-ppmplugin
  # → CRITICAL-free verdict before you side-load it

LOAD INTO THE WRAP HOST:

  # Side-load ppmplugin/<name>.ppmplugin into the wrap host per the wrap pipeline' load flow.
  # The host runtime registers the DEX's ReactPackage / the iOS framework's moduleClass +moduleName;
  # the manifest's receivers[] become the routing keys the SendMessagePlugin bridge dispatches to.

DEPLOY THE PCF (if not already done):

  # Easiest: use the dedicated skill — it handles prefix selection + env confirmation:
  /publish-pcf-companion

  # Manual equivalent (substitute a 2–8 char prefix):
  cd pcf/<Pascal>PCF
  pac pcf push --publisher-prefix pamext
  # The control appears in Canvas Studio under Custom controls > PowerApps namespace.

RUN ON DEVICE:

  # iOS: build & run the wrap app on simulator or device (Xcode).
  # Android: install the wrap app on connected device / running emulator.

RUNTIME CRASH-SCAN (Android — the DEFINITIVE catch for the launch-crash + response-shape classes
that every static layer is blind to; run right after launching the wrap app):

  # A) CONSTRUCTION CRASH — a native-module constructor / init{} that throws at bridge startup
  #    takes down the host BEFORE any UI (e.g. registerTorchCallback(cb, null) on a Looper-less
  #    thread → "Can't create handler…"). Launch the app, then scan logcat for the signatures:
  adb logcat -c
  adb shell monkey -p <wrap-package> -c android.intent.category.LAUNCHER 1 >/dev/null
  sleep 8
  if adb logcat -d | grep -iE "Looper\.prepare|Can't create handler|Loaded 0 plugin package|UnsatisfiedLinkError|FATAL EXCEPTION"; then
    echo "✗ LAUNCH CRASH / plugin-load failure — see the matched line (fix: defer ctor side-effects to lazy init, Handler(Looper.getMainLooper()), try/catch)"
  else
    echo "✓ no launch crash / plugin-load failure in the first 8s"
  fi

  # B) RESPONSE ROUND-TRIP — a PCF that only deepParses misses the wrap {isUpdate, message:"<json>"}
  #    container and fails EVERY call with UNEXPECTED_PAYLOAD though native succeeded. On the canvas
  #    screen bind a label to Self.<name>Json, tap the control once, and read it:
  #      ✓ shows the module's own {"status":"ok",…}                     → PCF unwraps correctly
  #      ✗ shows {"isUpdate":…,"message":"{\"status\"…"}               → PCF isn't unwrapping the
  #        container (fix: extractResponse, not a bare deepParse — /generate-pcf-companion + §2)
  #      ✗ Status=error, ErrorCode=UNEXPECTED_PAYLOAD                    → same root cause

INSTALL-FAILURE SCAN (run if the wrap app won't install at all — before the launch scan):

  # Android — a failed `adb install` prints the reason; the common ones map to a fix:
  #   INSTALL_FAILED_INSUFFICIENT_STORAGE  → free space / wipe the emulator
  #   INSTALL_FAILED_UPDATE_INCOMPATIBLE / signatures do not match  → uninstall the old app first:
  #       adb uninstall <wrap-package>
  #   INSTALL_FAILED_NO_MATCHING_ABIS      → the .so / ABI in android/lib/<abi> doesn't match the device
  #   INSTALL_FAILED_OLDER_SDK             → device OS below the wrap app minSdk
  # iOS — install/launch failing before any JS runs is usually signing, not your module:
  #   "Unable to install" / codesign / provisioning  → the wrap app's profile doesn't allow this device
  #   dyld: Library not loaded / @rpath …<Name>.framework  → the framework wasn't embedded by the wrap
  #     pipeline (a packaging issue, not a source bug) — re-check /assemble-ppmplugin + /audit-ppmplugin.

RUNTIME CRASH-SCAN (iOS — the analogue of the Android scan; run right after launching the wrap app on
a simulator/device. A throwing/heavy init or a module that won't load surfaces in the device log):

  # Stream the wrap app's log and scan for the iOS launch/init + load-failure signatures:
  xcrun simctl spawn booted log stream --level=default --predicate 'processImagePath CONTAINS "<wrap-app>"' &
  # (device: use Console.app filtered to the app, or `idevicesyslog`.) Then launch the app and watch for:
  #   ✗ "Native module '<X>' not loaded" / NSClassFromString → nil   → +moduleName / dead-code-stripping / used RCT_EXPORT_MODULE (§5b)
  #   ✗ dyld: Symbol not found / @rpath …React                       → React linked strongly, or RN pin ≠ host RN
  #   ✗ *** Terminating app due to uncaught exception … in -[<Module> init]  → throwing init (defer to lazy first call)
  #   ✓ no such lines in the first ~8s after launch                  → no iOS launch/init crash

WHAT TO VERIFY (per ARCHITECTURE §8 Edge cases — copy into a checklist):

  [ ] Happy path: <one-line happy-path scenario>
       Expected: <Pascal>PCF1.<OutputName> = '<value>' per ARCHITECTURE §8
  [ ] Error case <CODE_1>: <how to trigger>
       Expected: <Pascal>PCF1.<OutputName> = 'error: <CODE_1>'
  [ ] Error case <CODE_2>: <how to trigger>
       Expected: <Pascal>PCF1.<OutputName> = 'error: <CODE_2>'
  ... (one row per error code in ARCHITECTURE §5)

TROUBLESHOOTING:

  • Bridge resolves "NOT_IN_PAM" → opening in Studio preview (no bridge). Open in the wrap app on a device.
  • "native module '<nativeModule>' not loaded" → the .ppmplugin didn't register. Re-run /audit-ppmplugin (catches the DEX/framework structure + SDK-leakage causes on disk) and re-side-load.
  • Bridge times out → check Logs via Xcode Console (iOS) or `adb logcat` (Android) filtered to `<nativeModule>` or `SendMessagePlugin`.

Tailor each <...> to the docs. Pull the happy-path scenario from ARCHITECTURE §6.2 (Bridge wiring trigger) + PRD §1 (Summary). Pull each error row from ARCHITECTURE §8.

Print and move on. Do NOT wait for the user to run the recipe and report back — manual device testing can take 5–10 minutes; making the skill block on it makes the iteration loop awkward. The recipe is next-steps guidance, not a gated layer.

The skill's job at Layer 5 ends here. The user runs the recipe on their own time. To record the outcome later, the user can either:

• Edit .extension-state.md directly — under "Validation history", update the Manual / device (Layer 5): line with pass | partial | fail | manual + an ISO timestamp + (optionally) a note about which rows failed.
• Re-run /test-native-extension — Layers 1–4 are cheap; the Layer 5 recipe re-prints and the user can update state manually after running it again.

The skill's responsibility is to make sure the recipe is correct and tailored to the current PRD. The execution and result-recording are the user's.

Pointer-only — routes to /audit-ppmplugin. Not run here. Only relevant once a built bundle exists on disk.

If a built ppmplugin/*.ppmplugin is present (this skill's structural layers run on source; they don't unzip a bundle), point at the dedicated deep-verification gate rather than re-implementing it:

BUILT_BUNDLE=$(ls ppmplugin/*.ppmplugin 2>/dev/null | head -1)

If $BUILT_BUNDLE is set, print:

ⓘ Layer 6 (deep bundle audit): a built bundle exists (<path>).
   Run /audit-ppmplugin for the byte-level verification this skill can't do on source:
   zip structure, manifest↔bundle consistency, DEX SDK-leakage byte-scan, iOS framework
   structure — the gate that proves it will actually load + dispatch on the wrap runtime.

If no built bundle exists, omit this layer silently (nothing to audit yet — the build skills haven't run).

Opt-in, advisory, whole-repo. The reasoning counterpart to the fast deterministic greps in Layer 0. Layer 0 (checks 12–17) and /audit-ppmplugin Category F catch the deterministic subset of the runtime-safety class — a Looper-less constructor Handler, an un-unwrapped {message} response, a Promise-taking method with zero settle sites, a declared-but-unchecked dangerous permission, an unguarded currentActivity. They're fast and false-positive-light because they're narrow. This layer is the broad reasoning pass that catches what a grep can't: a resource released on only some paths, a Promise double-settled under an error branch, UI presented off the main thread three calls deep, a manager acquired in a helper and never torn down.

When to offer it. After the automated layers pass, if the control has native modules (ios/ or android/ present), offer it via the Step 8.1 next-step gate as one option — never run it by default. It reasons over the whole tree (slower) and is advisory: it returns DONE_WITH_CONCERNS, it does not flip Overall to blocked. A broad reasoning pass must not false-positive-gate a working control.

What it runs. Read shared/self-critique-protocol.md and run it in holistic review mode (see that file's Run modes) — i.e. enumerate every source file in the control (ios/, android/, pcf/, manifest.json, AndroidManifest.xml / Info.plist, build.gradle / podspec), not just files touched this run — with emphasis on Gate 9 (Runtime safety & resource lifecycle). Gates 1–8 also apply, but Gate 9 is the reason this layer exists as a device-independent complement to the Layer 5 on-device crash-scan.

Output. Per-module findings table (Item | Question | Finding | Severity | Fix). Print ⓘ Layer 7 (deep runtime-safety review): <N> concern(s) — advisory, not blocking and list them. Record the count in .extension-state.md under Validation history as Deep review (Layer 7): <N> concerns — <timestamp>. If the user wants any concern fixed, route to /debug-extension.

Build a summary table:

Test summary
────────────
Layer 0 (contract check):       <pass | warn-N | skip> — <time>
Layer 1 (native structure):     <pass | fail | skip> — <time>
Layer 2 (manifest validation):  <pass | fail | n/a — no manifest> — <time>
Layer 3 (native contract):      <pass | fail | skip> — <time>
Layer 4 (PCF compile):          <pass | fail | n/a — PCF not scaffolded> — <time>
Layer 5 (manual E2E):           recipe printed (run on device when ready)
Layer 7 (deep runtime review):  <N concerns | not run — opt-in>

Overall (automated): <pass | blocked>

Note: native iOS / Android compile into a loadable DEX / framework is NOT validated by this skill — run /build-android-binary // /build-ios-binary.

The skill's Overall reflects only the automated layers (1–4). Layer 5 is recipe-only — its execution and result-recording are the user's responsibility. The user updates .extension-state.md manually after running the recipe on a device.

Update ./.extension-state.md:

• Validation history block: write one line per automated layer (1–4) with the result + ISO timestamp. The Layer 5 line is left as manual / device (Layer 5): recipe printed at <timestamp> — the user updates it manually after running on device.
• Phase: if all automated layers (1–4) that were run passed, set Last completed: tested and Next: /generate-ppmplugin or /audit-ppmplugin or /publish-pcf-companion (whichever applies for the user's next intent). Otherwise keep Status: blocked with the first-failing-layer reason.

The literal first line of your final message MUST be one of:

After the first line, blank line, then the human-readable summary.

• Stop on first failure (automated layers only). Don't run Layer 2 if Layer 1 failed, etc. Wasted compute and confusing reports.
• Layer 5 is print-only. Do NOT ask the user "Did it pass?" — don't gate the skill on a manual device test that takes 5–10 minutes. Print the recipe, finalize Layers 1–4 results, exit. The user runs the recipe on their own time and updates state manually.
• Don't run native compile here. Native compilation into a loadable DEX / framework is /build-android-binary // /build-ios-binary — they build the staging-copy module against the pinned AGP / xcodebuild settings (ppmplugin-format §5, §5b). A bare pod lib lint / ./gradlew assembleDebug from this skill would give false-confidence (it resolves deps from public CDN/maven, not against the wrap host's pinned RN). If a previous version of this skill emitted .test/ios/ or .test/android/ scaffolding, those directories should be deleted — they're not part of the current flow.
• No --force flags to make a layer "pass". Fix the source — don't disable strict mode, suppress warnings, or skip dependency resolution.
• Don't write to .extension-state.md mid-layer. Update once at the end with all layers' results, or update incrementally with Status: blocked on each failure — but never leave the file in a half-updated state if you stop mid-run (Crashed-Claude problem).
• Don't run npm publish / pnpm publish / pac pcf push. Those belong to the publish skills.