@1aboveio/skills 1.0.13 → 1.0.14

package/skills/engineering/engineering-runtime/coherence/workflow.json

@@ -369,7 +369,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "5a7d8e43506d55cf9ea6e4a7c3bc44caf32f384f61b2ac83048760f522ec74c8",
+      "contentDigest": "d50381c5d34f05b3c4ac60bd0d1a5a56fdeb7112caf3a58303e2c8d5b9cd73d4",
       "digestExcludes": []
     },
     {
@@ -382,7 +382,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "d60f3b5770b305d86d703aecf9a08f4ed9b1ea428e881c34212529ef8d12d1f4",
+      "contentDigest": "7fb81756e33e2582cc02b2a964af1361a474ddae64f1304dfdff680162e5f35e",
       "digestExcludes": []
     },
     {
@@ -395,7 +395,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "a97b8b8e123e4da19f49614540de3dd607f0711eb8b406516ca023d695a3dcfe",
+      "contentDigest": "08e07649d8ee91496a4275c9417cd679932d798c91cdbb483ca45979733dd0c3",
       "digestExcludes": []
     },
     {
@@ -408,7 +408,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "a0ac298524bc181d5310ee8f05eb0171a8ab801f68ca18ea55b90b9a8cf54b57",
+      "contentDigest": "45e72502bf9d1f707caf2990ba8a9bda7fbda4e748b5f798731a1d0d992b0b02",
       "digestExcludes": []
     },
     {
@@ -421,7 +421,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "3d5b22f5e45edbcca8b88a6802231a830f90b083de6d3fbdc0ceb823ae5971a5",
+      "contentDigest": "5cf9c65216eda37ed0acebcaa97be9eea9239fad96397cdd858b4694cae9d906",
       "digestExcludes": []
     },
     {
@@ -434,7 +434,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "e66777d1d522e495078dfdcb506ae815810bf0c8aa648349da4a3bb12566cfdd",
+      "contentDigest": "6e1c15f7d61a3bb2af78df82b57674152d9c321cc17b5a83d32379cc0a9104ef",
       "digestExcludes": []
     },
     {
@@ -447,7 +447,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "01d95a93132107140a55a13fceafb0d3993c742e80dd7f367018306d71690b36",
+      "contentDigest": "303941d679cacbafc5594a6b8369e016cef3cdf3c065ae919edc8695cbce8a69",
       "digestExcludes": []
     },
     {
@@ -460,7 +460,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "75aebb12f6d3461fe1892bce7b535ec8dcf94b3943aa8c488cf46255654f5e57",
+      "contentDigest": "d8de3acaf463033d55e5bedf17b5aeac8e9a1d77267c5960af18bdebbaf18c7d",
       "digestExcludes": []
     },
     {
@@ -473,7 +473,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "c5f4d18c646ece47620c9d778860c96f2f3764caa1ecaff0ef821835b7421aa0",
+      "contentDigest": "8b8a149b90292ae4b0c3dd8b34a387ea7fa8c154610c232c8c55ce9781cca03d",
       "digestExcludes": []
     },
     {
@@ -486,7 +486,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "491cfe94839fa027fed6c79631a8dc581f65ef1e1b222a61f76e15863e540e5b",
+      "contentDigest": "553b2748b6357b92caa30ee29351add044d10cc6ad28e4cdb809f4f23bb5a9da",
       "digestExcludes": []
     },
     {
@@ -499,7 +499,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "ec5d51ec669aa5ed0693d54ef70efd97a19dd9817accfdb2ca7afe1a711547e7",
+      "contentDigest": "65bb8314e2fe1f2ebbdca60f2dcd433af44a8eeba080adf30f0682ef5c0a2acd",
       "digestExcludes": []
     },
     {
@@ -512,13 +512,13 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "de617480630819345cb53fea3fbd5ca2e9d4d360680a9feace942c518806f59b",
+      "contentDigest": "9fb61a9e59fee73ff803113e9d33e47bc19a2ef5ce92c06f63a4d5cca8a72189",
       "digestExcludes": [
         "coherence/workflow.json"
       ]
     }
   ],
-  "releaseIdentity": "4eabbf3d0e0d3af4e9436e1a4e4c07ef153a7cc07d74d42ab94c15717146dfa3",
+  "releaseIdentity": "d0f4c3cc3c13714b4d4be17f6b8b1f56aff7fe1901be7c7823f4faba348baeb6",
   "lifecycleAuthority": "native-skills-cli",
   "repairRecipe": {
     "id": "engineering-workflow-dependency-first",

package/skills/engineering/ensure-coverage/SKILL.md

@@ -2,7 +2,7 @@
 name: ensure-coverage
 description: "Define or audit behavior-first test criteria — ACs, required test levels, mock/integration/E2E policy — across three axes: breadth (Coverage Ledger), depth (over-mocking), presentation (perceivability of browser surfaces). NOT judging whether a single test is any good (test-quality), authoring browser tests (e2e-test), reviewing a PR (better-review), or delivering issues (resolve-issues)."
 disable-model-invocation: true
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Ensure Coverage

package/skills/engineering/golden-path/SKILL.md

@@ -3,7 +3,7 @@ name: golden-path
 description: "Golden-path E2E: the short list of user journeys whose failure blocks a release, kept in a repo as one contract (golden-paths.json) with a generated GOLDEN_PATHS.md and a generated GitHub Actions workflow, and run against a local build or a deployed URL for an ALIVE/DEAD verdict. Use to set golden paths up in a repo ('init golden paths', 'add golden-path CI'), to migrate an older smoke.manifest.json or a hand-built smoke setup ('audit', 'migrate smoke'), to add, change, or remove a golden path, to ask 'is the build alive?' or run them before a PR or release, or when a change touches a flow listed in GOLDEN_PATHS.md. NOT for writing the Playwright specs themselves (e2e-test), deciding what a change must prove (ensure-coverage), or general workflow YAML (github-actions)."
 dependencies:
   - e2e-test
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Golden path

package/skills/engineering/harness-runtime/SKILL.md

@@ -3,7 +3,7 @@ name: harness-runtime
 description: Internal import-only library shared by first-party engineering packages. Not a workflow skill; never select or invoke it as a user capability.
 disable-model-invocation: true
 user-invocable: false
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Harness Runtime

package/skills/engineering/resolve-issues/SKILL.md

@@ -8,7 +8,7 @@ dependencies:
   - better-review
   - golden-path
   - harness-runtime
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Resolve issues

package/skills/engineering/resolve-issues/references/exploration.md

@@ -100,7 +100,7 @@ four are copied.
        reproduce a failed journey with it before they push a fix; never a CI
        dispatch (`gh workflow run`, `gh run rerun`). `check` may be one.
      - `skill` (every suite, present or missing): the absolute `SKILL.md` path of the installed skill for this
-       kind of journey (an emulator journey: `android-foundation`; a browser
+       kind of journey (an emulator journey: `android-development`; a browser
        one: `e2e-test`), or `null` when none is installed.
        Example: `check` dispatches the workflow input that runs the Charge
        journey; `local` runs that Charge journey script on an owned emulator,

package/skills/engineering/resolve-release/SKILL.md

@@ -4,7 +4,7 @@ description: "Slash/explicit-only (/resolve-release). Full GitHub Flow release f
 disable-model-invocation: true
 metadata:
   workflow-role: coordinator
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Resolve release

package/skills/engineering/rush-issues/SKILL.md

@@ -6,7 +6,7 @@ metadata:
   workflow-role: coordinator
 dependencies:
   - resolve-issues
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Rush issues (shortcut of resolve-issues)

package/skills/engineering/rush-release/SKILL.md

@@ -6,7 +6,7 @@ metadata:
   workflow-role: coordinator
 dependencies:
   - resolve-release
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Rush release (shortcut of resolve-release)

package/skills/engineering/test-quality/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: test-quality
 description: "Seven principles for tests that catch real bugs, and an audit that reports weak, redundant, and not-coverage tests without fixing them. Use when writing, changing, or reviewing tests, or when asked whether tests are useful, redundant, over-mocked, flaky, only assert static text, or test config files, or asked to make a slow test suite faster without losing coverage, or when the user asks to write the testing conventions into a repo's CONTRIBUTING.md. NOT defining what a spec must prove (ensure-coverage) or authoring browser tests (e2e-test)."
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Test Quality

package/skills/risk-compliance/compliance-audit/SKILL.md

@@ -2,7 +2,7 @@
 name: compliance-audit
 version: 2.9.0
 description: "Audit operations against financial-compliance checklists (AML/KYC, VARS, PCI-DSS, TPA oversight, onboarding, transaction monitoring). Produces tracker.md (with a tracker.xlsx export) and phase-trail.md with layered validation; cites evidence by original filename. Input: reg-parser or the built-in VARS checklist."
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Compliance Audit

package/skills/risk-compliance/contract-compare/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: contract-compare
 description: "Compare two or more contracts side-by-side for structured diff, gap analysis, and benchmarking. Use when: comparing contracts or agreements, contract diff, compare terms, vendor-vs-vendor, compare our template vs theirs, compliance gap between contracts. NOT for single-contract risk review — use contract-review for that."
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Contract Compare

package/skills/risk-compliance/contract-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: contract-review
 description: "Review contracts for legal, commercial, and compliance risks via convert → chunk review → merge → validate (+ optional mandate preprocessing). Use for reviewing, auditing, or checking any contract, agreement, NDA, MSA, or SLA; input a file path (PDF/DOCX/TXT) or pasted text."
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Contract Review

package/skills/risk-compliance/doc-authenticity/SKILL.md

@@ -3,7 +3,7 @@ name: doc-authenticity
 version: 0.4.1
 description: "Screen PDF documents and raster images for fabrication, tampering, Photoshop or other image-editor use, and content validity. Detects file type, runs format-specific authenticity forensics, classifies bank statements, conversation logs, invoices, agreements, and other documents, then applies type-specific validity checks. Produces separate authenticity (NO_EVIDENCE_OF_MODIFICATION / SUSPICIOUS / LIKELY_MODIFIED / INCONCLUSIVE) and validity (VALID / INVALID / INCONCLUSIVE) verdicts. Use whenever a user asks whether a document, screenshot, scan, statement, invoice, contract, chat log, receipt, or payment evidence is genuine, original, edited, Photoshopped, manipulated, fake, or valid."
 disable-model-invocation: true
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Document and Image Authenticity

package/skills/risk-compliance/fraud-detection/SKILL.md

@@ -12,7 +12,7 @@ description: >
   impact, and a business report. Use for fraud, scam, mule, account-takeover,
   chargeback, dispute, transfer, collection, or payout risk analysis even when the
   user does not name this skill.
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Fraud Detection

package/skills/risk-compliance/payment-analysis/SKILL.md

@@ -14,7 +14,7 @@ description: >
   transactions" — even if they do not say payment-analysis. Do NOT use for
   fraud rule discovery (fraud-detection) or TLD / MCC-miscoding
   clusters (tld-detection).
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Payment Analysis

package/skills/risk-compliance/portfolio-payment-analysis/SKILL.md

@@ -5,7 +5,7 @@ description: >
   and investigate selected merchants' authorization, settlement and disputes,
   including descriptor mapping and overlapping exports. Portfolio-level payment
   overviews belong to payment-analysis; fraud rule discovery belongs to fraud-detection.
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Portfolio payment analysis

package/skills/risk-compliance/similar-domain/SKILL.md

@@ -8,7 +8,7 @@ description: >
   links, an entity chain, and a watchlist for the operator's next domains.
   Not transaction data (tld-detection) or fraud rules (fraud-detection).
 disable-model-invocation: true
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Similar Domain

package/skills/risk-compliance/tld-detection/SKILL.md

@@ -6,7 +6,7 @@ description: >
   patterns, with USD and BIN-country currency views, group profiles and priorities.
   Not payment-analysis, fraud-detection, or website research.
 disable-model-invocation: true
-release-version: 0.45.2
+release-version: 0.46.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # TLD detection

package/skills/app-dev/android-foundation/SKILL.md

@@ -1,248 +0,0 @@
----
-name: android-foundation
-description: "Prove and debug Expo / React Native apps on an owned Android emulator. Use for stuck Android debugging, post-deploy startup or rendering failures, Metro answering while the app does not render, UiAutomator failures, missing controls, ADB drops, harness-test failures, APK builds, assigned or fresh SDK/NDK/JDK workspace setup, and native journey validation. Before fixing and rerunning or redispatching a failed Android CI job, reproduce its failing checkpoint off CI: a rerun is not a debugger. Diagnose existing setups without rebuilding the whole environment. NOT for workflow YAML, CI speed or runner design (github-actions), browser tests (e2e-test), iOS (ios-foundation), plain Jest component tests, or signing and store release."
-release-version: 0.45.2
----
-**Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
-# Android foundation
-
-Prove or debug a native Expo / React Native device journey using the repo's existing
-build scripts, native project, harness and wrapper. Use `github-actions` for CI YAML
-and runner integration. The CI template is a starting point; preserve existing workflows.
-
-Pick the mode first:
-
-- **Diagnosis:** an existing workspace or CI run fails or stalls. Follow
-  [Diagnosis](#diagnosis) first; a harness change does not automatically require a cold
-  setup. Re-run only the setup stages whose assumptions changed.
-- **Setup proof:** a new workspace or CI job, or a toolchain, dependency or native
-  change that invalidates setup. Run every stage and write the
-  [evidence record](#evidence-record).
-- **Feature work:** validating a product change in a workspace already set up. Follow
-  [Feature work](#feature-work): focused checks per candidate, targeted device checks
-  where needed, and integrated journeys at explicit checkpoints.
-
-## Routing
-
-| Step | Read |
-| --- | --- |
-| Workspace resolution, then shell snippets for every stage | [references/workspace.md](references/workspace.md), [references/setup.md](references/setup.md) |
-| Stages 6–8 in one command | [scripts/device-run.sh](scripts/device-run.sh) |
-| Adding the Android job to CI | [references/ci.md](references/ci.md), template [assets/android-ci-job.yml](assets/android-ci-job.yml) |
-| Proving a product change on the emulator | [Feature work](#feature-work) |
-| A stage failed or a worker appears stuck | [Diagnosis](#diagnosis), then [references/diagnosis.md](references/diagnosis.md) and [Triage](#triage) |
-| Writing up setup proof | [Evidence record](#evidence-record) |
-
-## Rules
-
-- Resolve the workspace first; [references/workspace.md](references/workspace.md) owns
-  precedence: an assigned isolated workspace and candidate HEAD win, feature work, fixes and
-  diagnosis reuse the owned workspace, and standalone setup creates one managed workspace
-  only with no usable assignment. Read its actual HEAD; never substitute `origin/main`, a new
-  branch or another checkout, mutate a peer's checkout or symlink its writable `node_modules`.
-- Tool shells keep no variables, functions or traps between calls. Write the environment
-  to `.cache/android-env.sh` once and source it at the start of every command. Use the
-  repo's existing owned-resource launcher. For a new local setup without one, use
-  `scripts/device-run.sh` for stages 6–8 in one command. Do not wrap an existing owner
-  with a second emulator/database lifecycle.
-- Keep local writable caches private under `.cache/`: Gradle home, Android user/AVD
-  homes, temporary files, npm, node-gyp and pnpm. In CI, an already isolated runner slot
-  may provide those paths; verify its ownership contract rather than layering another
-  cache system on top. Never share writable state across concurrent owners.
-- Read toolchain versions from the repo: the root `packageManager` and `engines`, the
-  native Gradle config, and the CI preflight. The repo is the source of truth, not this skill.
-- Check that every required SDK component (platform, build-tools, NDK, CMake,
-  platform-tools, emulator, system image) is already installed. If one is missing, stop and
-  provision it separately. Never upgrade or install into a shared SDK during a journey;
-  build with `-Pandroid.builder.sdkDownload=false`.
-- Install with `--frozen-lockfile`. Do not routinely run `clean`, reinstall dependencies or
-  run `expo prebuild`. The native project is tracked, and prebuild needs a reviewed native
-  change.
-- Build every configured ABI for setup proof and release acceptance. An x86_64-only CI
-  APK only proves the emulator ABI. For feature work, the emulator ABI is enough unless the
-  change touches native code or ABI configuration.
-- Determine how the selected build loads code and assets. A typical debug build needs
-  Metro; a release build normally embeds its bundle. Do not introduce Metro or debug
-  preferences into a release failure without evidence that the build uses them.
-  A successful build does not prove execution on a device.
-
-## Stages
-
-These are the full setup-proof stages, not a per-candidate checklist. For established
-workspaces, select checks under [Feature work](#feature-work). Run the selected stages
-in dependency order. Stop at the first failure and triage it.
-
-1. **Workspace and environment.** Resolve the assigned or standalone workspace
-   ([references/workspace.md](references/workspace.md)) and export the private cache paths,
-   `JAVA_HOME` (JDK 17), `ANDROID_HOME` and `ANDROID_SDK_ROOT`. Print the versions of
-   node, pnpm, java, python3, adb and the emulator. Assert that each SDK component
-   directory exists. Read the journey wrapper and device harness for the names they expect:
-   the venv path, the port variables, the database variables and the database-name prefix
-   the harness accepts.
-2. **Install and check.** Run a frozen install, the app's unit tests, typecheck, and
-   `expo export --platform android` with a placeholder `EXPO_PUBLIC_API_URL`. Create a
-   Python venv for UI automation at the path the journey wrapper reads, and pin the
-   `uiautomator2` version the harness expects.
-3. **Gradle dependencies.** Pick one:
-   - Seed: `rsync --ignore-existing` only `caches/modules-2/files-2.1/` from a trusted
-     Gradle home, excluding `*.lock`, `*.lck` and `*.tmp`. Never share writable caches,
-     metadata, credentials or APKs.
-   - Proxy: a private Gradle home does not inherit `~/.gradle/init.d`. Install the proxy's
-     init script into `$GRADLE_USER_HOME/init.d/` and export a route for every repository
-     the build uses, JitPack included. Ping the proxy first.
-   - Neither: build against upstream and expect a long cold build.
-   If the opted-in proxy fails, treat it as an error. Never fall back to direct downloads
-   and never disable TLS checks. The proxy covers Gradle Maven repositories only. Route the
-   Gradle wrapper ZIP and pnpm as the repo's CONTRIBUTING says.
-4. **Build.** Run the repo's Android build script with `--max-workers=2
-   -Dorg.gradle.parallel=false -Pandroid.builder.sdkDownload=false --console=plain
-   --info`, keeping the log. For setup proof, hash the APK and list its `lib/<abi>/`
-   entries.
-5. **Owned emulator.** Create a new private AVD in `$ANDROID_AVD_HOME` by copying only
-   `config.ini` from an installed AVD. Never copy its user data or snapshots. Check that
-   `image.sysdir.1` points to an installed, host-compatible image, and set `target` to
-   match it. Writing `config.ini` from scratch needs the hardware keys:
-   [gotchas](references/gotchas.md#a-hand-written-avd-misses-the-screen). Give the guest
-   4 GB: replace any `hw.ramSize` with `hw.ramSize=4096` (`device-run.sh` also passes
-   `-memory 4096`). At 2 GB, the usual `avdmanager` value, adb drops mid-journey ([gotchas](references/gotchas.md#the-adb-transport-drops-mid-journey)).
-6. **Register cleanup before starting anything.** `device-run.sh` installs the `EXIT`
-   trap and the `INT`/`TERM` handlers first.
-7. **Start resources.** The script refuses an emulator console port outside 5554–5584
-   (adb scans only that range) and any busy port, starts the ADB server, then the emulator
-   (PID recorded) and `postgres` (`--cidfile`, random loopback port), and waits for
-   `sys.boot_completed=1` and `pg_isready` with a time limit on every command.
-8. **Journey.** The script hands the harness a database named with its accepted prefix and
-   runs the journey wrapper. Expect every scenario's `PASS` marker, plus screenshots, the
-   backend log and the Metro log.
-
-## Owned-resource cleanup
-
-- Clean up only what this run started: the emulator child PID, the container ID from the
-  CID file, and the named database; these are short-lived, unlike the development workspace
-  and its private caches. Signal the PID with `TERM`, wait up to 10 seconds, then `KILL`.
-  Then `wait` for it and confirm nothing is left. Count wait status 0 or 143 (ended by your
-  `TERM`) as a clean stop; count a needed `KILL` or any other status as a failure.
-- Never use broad `pkill`, `docker system prune` or a shared `adb kill-server` for cleanup.
-  Use the live child's process owner, not an ADB serial that may be reused. A numeric
-  PID can also be reused after exit; it is not durable ownership evidence.
-- Give every startup, readiness and cleanup command a 30-second limit that kills the
-  command's whole process group. Treat exit 124 (timeout) as a terminal failure, not as
-  "not ready yet".
-- Preserve the stage's original non-zero exit status even when cleanup succeeds. Print
-  `original_stage_exit=<n> cleanup_exit=<n>`.
-- After SIGKILL or a host crash, verify recorded resources before recovery: process
-  start identity, command/run scope and boot identity where available, or container ID
-  and ownership labels. Never signal a numeric PID solely because an old record names
-  it. If ownership cannot be verified, leave it alone and report the gap. Keep logs.
-- For the local setup flow, point the database URL only at its disposable loopback
-  container. An existing isolated remote test flow must use its own disposable data and
-  ownership checks. Never use development, production or another worker's database for
-  fixture writes or cleanup. A public render-only smoke needs no database.
-- Expo may rewrite `android/tsconfig.json` or delete `android/expo-env.d.ts` while it runs.
-  Inspect those changes and restore them before you commit.
-
-## Delivery focus
-
-Read [references/delivery-focus.md](references/delivery-focus.md) before starting or
-continuing work. Keep an existing acceptance checkpoint, reuse available evidence,
-justify new infrastructure and carry failure history across workers. Required CI and
-the full acceptance criteria still apply; report delivered behavior before activity.
-
-## Diagnosis
-
-Follow the procedure below and [references/diagnosis.md](references/diagnosis.md).
-`diagnosing-bugs`, when available, can help with deeper hypothesis testing; it is not
-required to use this skill.
-
-The developer owns technical diagnosis. The coordinator owns its scope and broader
-acceptance scheduling. Failures in focused implementation validation stay with the
-developer within that task's scope. Failures after review handoff or in broader
-acceptance get a separate bounded diagnosis assignment, which may use the same developer:
-name the failed checkpoint, retained evidence, next question and return condition.
-Return scope growth or inconclusive evidence to the coordinator; do not silently extend
-implementation into a full acceptance campaign. Independent review checks the fix.
-
-1. Record the failed SHA, actual checkout, build variant, device type and retained
-   evidence. Locate the earliest failing stage: build/install → launch → load code/assets
-   → initialize → render → interact. Distinguish host/CI, harness, transport and product
-   failures; an absent screen alone does not identify which one failed.
-2. Choose the smallest test that can expose the suspected defect: a host test for logic,
-   real producer/consumer composition for a contract, or a device test for native/runtime
-   behavior. Collect evidence appropriate to that stage. A service probe proves only the
-   probe, not that the application used the same path.
-3. State competing explanations and a distinguishing observation. Change one variable.
-   For reversible defects, a failure → correction → failure comparison can strengthen
-   the finding; it is optional, not a gate. For intermittent failures, use a bounded,
-   repeatable trigger and compare failure rates. Do not replay Authentication or financial
-   actions merely to obtain a comparison.
-4. Keep the first exception and its evidence separate from cleanup errors. Bound the
-   full command and each subprocess wait, allowing the resource owner time to clean up.
-   A live worker or an outstanding tool call is not evidence of progress.
-5. Verify the fix at the failing checkpoint, then run the affected validation once.
-   Broader acceptance belongs to its scheduled integration or release checkpoint, not
-   automatically to this diagnosis assignment. Preserve any explicitly required gate.
-   Report local reproduction, source CI and post-deploy acceptance separately. A local
-   result on another API/ABI or a copied APK is not proof of the original CI artifact.
-
-Continue when the next attempt tests a new prediction, collects a missing observation,
-reduces the reproduction, or adds a justified sample for an intermittent failure. Name
-that purpose and bound its cost. Changing workers or repeating an unchanged run without
-such a purpose is not progress. When no available experiment distinguishes the remaining
-explanations, report the missing evidence or access instead of restarting the campaign.
-
-## Triage
-
-Name the earliest stage that failed. In CI, that is the first failed step. If the same
-journey passed on another run of the same commit, suspect the run or the journey before
-the product.
-
-| Stage | Typical signal |
-| --- | --- |
-| Prerequisites / install | missing SDK directory, wrong JDK, lockfile drift |
-| Harness unit tests (CI, before the APK) | a harness test fails on host state its fixture should fake (`requires 2 GiB reserve`) |
-| Export / APK | Metro bundling error, Gradle compile or dependency-resolution error |
-| Gradle network | Maven download or TLS-handshake errors on a cold build: fix routing, not code |
-| Emulator boot / ADB | `sys.boot_completed` never reaches 1, device offline, exit 124 |
-| Device to Metro | red box, "unable to load script", missing `adb reverse` mapping |
-| Bridge passes, debug app fails to load | possible app/probe endpoint mismatch; inspect the actual request before choosing a cause ([React Native example](references/diagnosis.md#example-react-native-debug-app-uses-another-metro)) |
-| Device to Metro, mid-journey | a screen's first Metro asset fails (`Unable to download asset from url: http://127.0.0.1:8081/assets/…`) while API calls still succeed |
-| Backend / Login | backend log errors, verification code not found in the database |
-| Backend tool, CI only | a Backend-backed step gets a 5xx in CI only; the log names a missing program (`Browser was not found at the configured executablePath`) |
-| adb transport, mid-journey | `connection terminated: read failed` in the adb trace after boot, then lost `adb reverse`: usually guest RAM |
-| UiAutomator server | `RemoteDisconnected` while the adb transport stays up: the on-device server was relaunched |
-| Journey harness | a wait right after a navigation times out while the destination is on screen |
-| Journey harness, short screen | a wait for a label times out only on a short or landscape screen, which shows the content above it |
-| Product assertion | a screen or state mismatch with a screenshot |
-
-Then match the signal against [references/gotchas.md](references/gotchas.md). If nothing
-matches, [confirm the suspected cause](references/gotchas.md#confirm-a-suspected-cause)
-before changing code.
-
-Preserve the failure evidence. Do not blindly replay steps that send codes, verify sessions
-or charge payments just to get a passing screenshot. One passing run does not prove the
-build is reliable.
-
-## Feature work
-
-Read [references/feature-work.md](references/feature-work.md) before validating a
-product change in an established workspace. Preserve required CI and acceptance gates.
-
-## Evidence record
-
-For setup proof only. Record:
-
-- Source SHA and the workspace root/path/base/branch/owner from the lifecycle record; host OS
-  and architecture, the Expo SDK, and the node, pnpm, JDK, Python and emulator versions.
-- System image API, image type and ABI. The AVD name, serial and ports are run
-  identifiers, not shared resources.
-- Each stage's exit status and duration.
-- The APK's SHA-256 (`shasum -a 256` or `sha256sum`) and its per-ABI `lib/` entries
-  (`unzip -l`), checked on the APK itself rather than inferred from Gradle flags.
-- The journey's `PASS` markers and the cleanup results: database dropped, emulator exited,
-  container removed, no listeners left on the backend or Metro ports.
-- Earlier failed or incomplete attempts. A later pass does not erase them.
-
-State what the run does not prove: tablet, accessibility (TalkBack), physical devices,
-signing, distribution, and any feature acceptance beyond the journey. Publish only
-sanitized evidence: no authentication codes, session cookies, customer data or raw
-payment payloads.

package/skills/app-dev/android-foundation/references/delivery-focus.md

@@ -1,31 +0,0 @@
-# Delivery focus
-
-Name one immediate checkpoint from the task's existing acceptance criteria: for example,
-open the app and render the expected screen. Keep that target visible while diagnosing;
-passing setup or adding helper code is not a substitute. Each independent work unit has
-its own checkpoint, so this does not serialize unrelated work.
-
-- Preserve a known-working source/artifact and relevant environment as a comparison when
-  one already exists. Do not start a baseline campaign or count that old artifact as proof
-  of the candidate. Reuse caches and valid results under the repo's ownership rules.
-- Run the smallest test that reaches the failing behavior. After it supports the fix,
-  complete focused validation and hand off to independent review. Run affected integrated
-  acceptance at its explicit plan checkpoint and preserve required CI; do not repeatedly
-  rebuild the full campaign to discover the next local defect or defer all journeys to
-  the final task.
-- Before adding a service, transport or test abstraction, state which existing criterion
-  needs it, why the current path cannot answer the question and the smallest alternative.
-  Make routine choices within authorization; preserve shared-resource and acceptance
-  approval boundaries. Do not expand infrastructure merely because a screen failed.
-- Every continuation states the current checkpoint, new evidence or concrete blocker,
-  and the next distinguishing test. Carry prior failures across worker changes. If
-  successive attempts leave the same checkpoint unproved, reassess and reduce the case
-  or change the approach before assigning another similar attempt. Diagnostics can guide
-  that decision but do not count as delivered functionality or reset coordinator limits.
-- Report behavior delivered and criteria still unproved first. Reuse existing results for
-  time to reproduce, time to verified fix and full CI runs when available; never invent
-  those measurements or create a reporting project to obtain them.
-
-When a coordinator owns the run, keep this context in its existing plan note and worker
-result. Follow its retry/replan rules; add no separate ledger, check or acceptance gate.
-

package/skills/app-dev/android-foundation/references/feature-work.md

@@ -1,50 +0,0 @@
-# Feature work
-
-Read the repository's validation and delivery policy first. Preserve required CI and
-acceptance gates; this skill does not authorize skipping them or rewriting project
-policy. Keep validation early without repeating the entire campaign per candidate.
-
-| Stage | Scope | Ownership |
-| --- | --- | --- |
-| Every candidate | Relevant tests, typecheck and applicable build/export checks; targeted device checks for runtime-sensitive behavior. | Developer validates, reports evidence and gaps, then hands off to independent review. |
-| Integration checkpoint | Affected journeys through combined changes. | Coordinator schedules a separate validation task as soon as its prerequisites are ready. |
-| Final acceptance | Remaining cross-feature, device-matrix and release obligations, plus checks invalidated by later changes. | Coordinator accounts for all required gates, reusing earlier evidence only within its proven scope. |
-
-- Name focused checks and integrated journey checkpoints in the plan before implementation,
-  with real prerequisites, an owner and observable results. Do not put all device testing
-  in the last task. Start independent ready work concurrently within device/host capacity
-  and existing ownership boundaries.
-- Choose the smallest check that proves the affected behavior. Host tests can prove logic
-  or a harness correction; native integration, navigation, keyboard, lifecycle and
-  accessibility changes need targeted owned-device evidence where host tests cannot prove
-  runtime behavior. A successful build/export alone is not device proof.
-- Use existing supported journey selectors. If the harness cannot select the affected
-  flow, report that limitation and schedule the smallest existing journey that covers it.
-  Do not invent a flag, weaken assertions or silently omit device validation. For example,
-  a filter change needs open/edit/apply/result evidence, not an unrelated payment campaign.
-- Reuse the workspace's private caches, venv and AVD configuration. Rerun setup stages only
-  when their assumptions change. Rebuild when build inputs change, using the emulator ABI
-  for focused work only where repository policy permits it. Do not require a fresh full
-  build or full journey solely because the candidate HEAD changed. APK reuse still needs
-  the source/configuration and artifact checks the repo requires; never relabel an old
-  artifact or result as current-source proof.
-- At each checkpoint, state what changed and which earlier evidence that change invalidates.
-  Reuse evidence only while source, configuration, artifact and environment remain applicable
-  to the claimed behavior. Required current-source CI still runs; evidence reuse cannot
-  replace a gate that requires a new run.
-- After a failed journey, local or a CI dispatch, enter Diagnosis mode and reproduce the
-  failing checkpoint off CI before running it again. A fake UI can reproduce a harness
-  navigation/scrolling bug; it cannot prove that the app loaded a bundle or rendered.
-  Show the fix passes at the appropriate boundary, then rerun the affected check once.
-  Never send a guessed fix to CI to see whether it passes. Use the Diagnosis continuation
-  rule for unreproduced or intermittent failures; report uncertainty until evidence
-  supports the cause.
-- Report source SHA, commands, results and remaining gaps at review handoff. For device
-  checks, include the selected scenarios, `PASS` markers and cleanup exit. For a failure,
-  name the earliest failing checkpoint and link retained evidence; preserve failed attempts.
-  Separate build duration, device-check duration and total worker time when discussing cost.
-- Broader device acceptance (all ABIs, tablet, TalkBack, physical devices, a release device
-  campaign) runs at the integration, release or campaign checkpoint the spec or repo assigns
-  it. Do not recreate it per feature or postpone affected runtime checks until release.
-  Record outstanding criteria as pending in their owning task or issue, never as passed.
-