@1aboveio/skills 1.0.10 → 1.0.12

package/README.md

@@ -49,11 +49,11 @@ See https://github.com/1aboveio/ai/blob/main/docs/native-codex.md for prerequisi
 
 | Package | Also published as | Skills |
 |---|---|---|
-| `core` | `@1aboveio/core-skills` | distill-writing, doc-to-md, editorial-review, house-style, plain-language, polish-cn, reg-parser, terminology, write-doc |
-| `engineering` | `@1aboveio/engineering-skills` | better-review, contributing, e2e-test, engineering-runtime, ensure-coverage, golden-path, harness-runtime, resolve-issues, resolve-release, rush-issues, rush-release, test-quality |
+| `core` | `@1aboveio/core-skills` | distill-writing, doc-to-md, editorial-review, house-style, plain-language, polish-cn, reg-parser, terminology, write-doc, write-report |
+| `engineering` | `@1aboveio/engineering-skills` | better-review, e2e-test, engineering, engineering-runtime, ensure-coverage, golden-path, harness-runtime, resolve-issues, resolve-release, rush-issues, rush-release, test-quality |
 | `cicd` | `@1aboveio/cicd-skills` | cloud-build, cloud-debug, cloud-deploy, docker, github-actions, github-flow, google-cloud, mergify, podman |
 | `app-dev` | `@1aboveio/app-dev-skills` | airflow, android-foundation, app-debug, better-auth, data-catalog, data-quality, ios-foundation, monorepo, nextjs-fullstack, prisma-setup, pyspark, python-backend, shadcn, zod-v4 |
-| `risk-compliance` | `@1aboveio/risk-compliance-skills` | compliance-audit, contract-compare, contract-review, doc-authenticity, fraud-analysis, payment-analysis, similar-domain, tld-detection |
+| `risk-compliance` | `@1aboveio/risk-compliance-skills` | compliance-audit, contract-compare, contract-review, doc-authenticity, fraud-detection, payment-analysis, portfolio-payment-analysis, similar-domain, tld-detection |
 | `content` | `@1aboveio/content-skills` | article-review, article-to-image, flowchart-svg, image-gen, mermaid, wechat-article-writer, wechat-publisher, wechat-search, xai-search |
 
 ## Third-party sources

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@1aboveio/skills",
-  "version": "1.0.10",
+  "version": "1.0.12",
   "description": "Every 1aboveio skill package in one: install once, then choose which packages Pi loads with npx @1aboveio/skills select.",
   "license": "MIT",
   "repository": {
@@ -28,8 +28,8 @@
   "nativeCodex": {
     "schemaVersion": 1,
     "metadataPath": ".codex-plugin/resources.json",
-    "metadataDigest": "5de5945c65e7ea8159f742d38230ce1bbce1d4e50da856395ba1a6688c291f38",
-    "releaseIdentity": "143a823442fb39994c04339e9deeb9433557c39afc5350a83e940f426f7941e4"
+    "metadataDigest": "cfec0dbb2a45072ce16f0733139e1730ba67f7fe064f1da5d68182068eaaac95",
+    "releaseIdentity": "ce2cf9ba70959f8293367fbeacc76aae45340883cc856a0a16e3c85009eb506c"
   },
   "pi": {
     "skills": [
@@ -45,7 +45,7 @@
       {
         "id": "core",
         "packageName": "@1aboveio/core-skills",
-        "description": "Shared writing and document foundation: house style, plain-language replies, editorial review, Chinese polish, terminology, write-doc, distill-writing, doc-to-md and reg-parser.",
+        "description": "Shared writing and document foundation: house style, plain-language replies, editorial review, Chinese polish, terminology, write-doc, write-report, distill-writing, doc-to-md and reg-parser.",
         "needsCore": false,
         "skills": [
           "distill-writing",
@@ -56,7 +56,8 @@
           "polish-cn",
           "reg-parser",
           "terminology",
-          "write-doc"
+          "write-doc",
+          "write-report"
         ]
       },
       {
@@ -66,8 +67,8 @@
         "needsCore": false,
         "skills": [
           "better-review",
-          "contributing",
           "e2e-test",
+          "engineering",
           "engineering-runtime",
           "ensure-coverage",
           "golden-path",
@@ -128,8 +129,9 @@
           "contract-compare",
           "contract-review",
           "doc-authenticity",
-          "fraud-analysis",
+          "fraud-detection",
           "payment-analysis",
+          "portfolio-payment-analysis",
           "similar-domain",
           "tld-detection"
         ]
@@ -258,7 +260,7 @@
         ]
       }
     ],
-    "digest": "bde7adaa8c5b8816941b0d8cd0345642df3ed9f238c90170882c892f0add3c42"
+    "digest": "5253ec62b19b6f208d90dc8ccc9002ede0fbef6488803ddd8ac678a2a73aff58"
   },
   "publishConfig": {
     "registry": "https://registry.npmjs.org/",

package/skills/app-dev/airflow/SKILL.md

@@ -2,7 +2,7 @@
 name: airflow
 description: Airflow DAG architecture and conventions. Use when designing, writing, reviewing, testing, or debugging Airflow DAGs and tasks, including TaskGroups, data intervals, timezone-aware date parameters, CLI validation, environment-based scheduling, and pytest integrity tests.
 user-invocable: true
-release-version: 0.44.1
+release-version: 0.45.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Airflow DAG Development Patterns

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

@@ -1,7 +1,7 @@
 ---
 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, fresh SDK/NDK/JDK workspaces, 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.44.1
+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.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Android foundation
@@ -18,14 +18,15 @@ Pick the mode first:
 - **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:** proving a product change on the emulator in a workspace already set
-  up. Follow [Feature work](#feature-work) and report only the journey result.
+- **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 |
 | --- | --- |
-| Shell snippets for every stage below | [references/setup.md](references/setup.md) |
+| 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) |
@@ -34,10 +35,11 @@ Pick the mode first:
 
 ## Rules
 
-- Use an isolated checkout. For new work, branch from `origin/main`; for diagnosis,
-  pin the failed source SHA or the reviewed correction. Confirm the checkout actually
-  contains the failing code: the repo root may lag active workspaces. Never mutate a
-  peer's checkout or symlink its writable `node_modules`.
+- 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
@@ -66,9 +68,12 @@ Pick the mode first:
 
 ## Stages
 
-Run them in this order. Stop at the first failure and triage it.
+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. **Checkout and environment.** Add the worktree and export the private cache paths,
+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:
@@ -113,9 +118,10 @@ Run them in this order. Stop at the first failure and triage it.
 ## 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. 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.
+  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.
@@ -148,6 +154,14 @@ 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
@@ -164,7 +178,9 @@ required to use this skill.
 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 applicable acceptance once.
+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.
 
@@ -208,33 +224,15 @@ build is reliable.
 
 ## Feature work
 
-- Reuse the workspace's caches, venv and AVD configuration. Rerun a setup stage only when
-  the change touches what it proves (toolchain, dependencies, native code, harness).
-- Build the emulator ABI when its inputs changed and run the repo's owned journey
-  command once per candidate HEAD. A reused APK needs the source/configuration checks
-  the repo requires; record its hash and any provenance gap during diagnosis.
-- 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 seam, then run the journey once to confirm.
-  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.
-- For a passing feature run, report the source SHA, journey command, `PASS` markers and
-  cleanup exit. For a failure, also name the earliest failing checkpoint, link retained
-  evidence and state what remains unproved; use the diagnosis report instead of hiding
-  the failed attempts.
-- Integrated device acceptance (all ABIs, tablet, TalkBack, physical devices, a release
-  device campaign) runs at the release or campaign gate the spec or repo assigns it. Do
-  not recreate it per feature. Record it once, as pending, in its owning issue, never as
-  passed.
+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, host OS and architecture, the Expo SDK, and the node, pnpm, JDK, Python and
-  emulator versions.
+- 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.

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

@@ -9,8 +9,10 @@ its own checkpoint, so this does not serialize unrelated work.
   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,
-  run affected acceptance and required CI; do not repeatedly rebuild the full campaign
-  to discover the next local defect.
+  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

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

@@ -0,0 +1,50 @@
+# 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.
+

package/skills/app-dev/android-foundation/references/setup.md

@@ -1,20 +1,30 @@
 # Android foundation: shell snippets
 
 Replace each `<placeholder>` with the repo's real value. Tool shells do not keep variables,
-functions or traps between calls: step 1 writes `.cache/android-env.sh`, which also `cd`s
-into the worktree, and every later block starts by sourcing it by absolute path, and steps 6–8 run as one command through the bundled
-`scripts/device-run.sh`.
+functions or traps between calls: step 1 resolves the workspace and writes
+`.cache/android-env.sh`, which also `cd`s into it; every later block starts by sourcing it by
+absolute path, and steps 6–8 run as one command through the bundled `scripts/device-run.sh`.
 
-## 1. Checkout and environment
+## 1. Workspace and environment
+
+Workspace precedence is owned by [workspace.md](workspace.md). Do not create a worktree,
+switch branch, fetch or reset when the caller supplied an isolated workspace.
 
 ```bash
 set -euo pipefail
-git fetch origin main
-git worktree add -b <new-branch> ../<repo>-android-setup origin/main
-cd ../<repo>-android-setup
-git rev-parse HEAD
+ASSIGNED_WORKSPACE=<assigned-workspace-or-empty>
+CANDIDATE_HEAD=<candidate-head-or-empty>
+WORKSPACE="${ASSIGNED_WORKSPACE:?use the caller assignment or native-start result from workspace.md}"
+test -d "$WORKSPACE"
+git -C "$WORKSPACE" rev-parse --is-inside-work-tree >/dev/null
+cd "$WORKSPACE"
+actual_head="$(git rev-parse HEAD)"
+test -z "$CANDIDATE_HEAD" || test "$actual_head" = "$(git rev-parse "$CANDIDATE_HEAD^{commit}")" || {
+  echo "workspace HEAD $actual_head != candidate $CANDIDATE_HEAD; report it; do not switch" >&2
+  exit 1
+}
 mkdir -p .cache
-{ echo 'set -euo pipefail'; printf 'cd %q\n' "$PWD"; } > .cache/android-env.sh
+{ echo 'set -euo pipefail'; printf 'cd %q\n' "$PWD"; printf 'export ANDROID_SOURCE_HEAD=%q\n' "$actual_head"; } > .cache/android-env.sh
 cat >> .cache/android-env.sh <<'ENV'
 
 # Repo-specific names, read from the repo's journey wrapper and device harness.
@@ -65,6 +75,11 @@ for component in platforms/android-<api> build-tools/<build-tools> ndk/<ndk> cma
 done
 ```
 
+The recorded standalone path is reused on retries; verify its lifecycle record names this
+run, branch and base. If an assigned path is missing, is not a Git worktree, or is at another
+revision, stop and report instead of creating another checkout. Never fall back to
+`../<repo>-android-setup`.
+
 If the wrapper reads ports or Python under other names, export aliases in
 `android-env.sh` **as well as** the bundled runner's required names. For example,
 `export APP_METRO_PORT="$ANDROID_METRO_PORT"`; both must select the same port. Adapt

package/skills/app-dev/android-foundation/references/workspace.md

@@ -0,0 +1,81 @@
+# Android workspace lifecycle
+
+The coordinator or caller owns workspace selection. Resolve it once, before any setup stage,
+and record the result. This reference owns only that lifecycle: private caches, SDK isolation,
+emulator ownership and process cleanup stay in [setup.md](setup.md) and
+[Owned-resource cleanup](../SKILL.md#owned-resource-cleanup).
+
+## Precedence
+
+1. **Assigned workspace and candidate HEAD.** When the caller supplies an isolated workspace
+   and a candidate HEAD, use that workspace and that revision. Do not create a worktree or
+   branch, fetch, reset or switch revisions. Read `git rev-parse HEAD` and report it as the
+   source SHA. If it differs from the candidate HEAD, stop and report the mismatch; never
+   switch the workspace to match.
+2. **Existing owned workspace.** Feature work, fixes and diagnosis reuse the workspace this
+   run or unit already owns, with its private caches, venv and AVD profile. Do not make a
+   second workspace for a retry, a correction or a read-only investigation.
+3. **Standalone fresh setup.** Only when the coordinator reports no usable assignment. Create
+   one managed workspace at
+   `<repo>/.resolve-issues/rush/<run-id>/units/native`. Never create a sibling checkout such
+   as `../<repo>-android-setup`, and never add a second managed path for a retry.
+
+Android and iOS setup in the same run share that one managed workspace; their private cache
+subdirectories and short-lived processes stay separate.
+
+An assigned path that is missing, is not a Git worktree, or is at another revision is not an
+invitation to substitute a fresh checkout: stop and report it. For diagnosis, name the actual
+checkout and HEAD and confirm it contains the failing code; the repository root or another
+checkout may lag the candidate.
+
+## Record before creating
+
+The bundled `scripts/workspace-runtime` is generated from the shared lifecycle
+engine and ships with this skill. Only for standalone fresh setup, run:
+
+```bash
+node <skill-base-dir>/scripts/workspace-runtime/bin/workspaces.mjs native-start --repo <canonical-root> \
+  --platform android --target <verified-target-branch> --base <candidate-SHA> --json
+```
+
+The command records root, owner, exact base, branch, workspace and disposable cache
+paths before creating anything. Use its returned `workspace` as `ASSIGNED_WORKSPACE`
+and `sourceSha` as `CANDIDATE_HEAD` in setup. Keep `run` and `runId`; repeat with
+`--run-id <returned-run-id>` and the same base, target and kind for retries. Never
+invoke it inside a coordinator-assigned unit. It never substitutes `origin/main`
+for the requested source or resets an existing workspace.
+For a package below the root, pass `--native-dir <package-root-containing-android>`.
+Declare other installs or build directories before use with repeated
+`--disposable <exact-workspace-relative-path>`, including package-local `node_modules`.
+
+## Development workspace vs short-lived processes
+
+The workspace, its private caches under `.cache/`, its venv and its AVD profile are
+development resources: retain them across retries and fixes, and keep them private to this
+workspace. Never relocate them to a global cache or share them with a concurrent owner.
+
+Emulators, containers, databases, Metro and ADB endpoints are short-lived: start only those
+the selected checks need and stop only the ones this run started, under the existing
+[cleanup rules](../SKILL.md#owned-resource-cleanup). Never delete a worktree, remove a cache
+with a chmod or `rm` pattern, or use a broad kill to end a process.
+
+A read-only diagnosis does not require a clean environment. Reuse the owned workspace and its
+caches, create only the services the observation needs, and preserve the failed environment's
+evidence. Do not rebuild, reinstall or re-provision merely because the failure is being
+investigated.
+
+## Completion
+
+At the end of the assignment, return the workspace, its cache paths and any retained process
+records to the coordinator for final cleanup. The coordinator owns deletion and retention.
+Register the path with the run's cleanup owner so final cleanup can tell a delivered
+standalone run from unfinished or unpublished work.
+
+- A successful, delivered standalone run must not retain an unbounded cache: mark the
+  workspace and its disposable caches for final cleanup. After stopping its owned
+  services, run `node <skill-base-dir>/scripts/workspace-runtime/bin/workspaces.mjs native-finish --run <run> --json`
+  from the owner checkout. This uses the same cleanup engine as issue workflows.
+- Unfinished or unpublished standalone work keeps the workspace and caches for the next
+  attempt; report what is retained and why.
+
+The parent lifecycle record is authoritative for ownership, retention and final cleanup.

package/skills/app-dev/android-foundation/scripts/workspace-runtime/bin/workspaces.mjs

@@ -0,0 +1,52 @@
+#!/usr/bin/env node
+import { execFileSync } from 'node:child_process'
+import { prepare, cleanup, recover, inventory } from '../workspace-lifecycle.mjs'
+import { nativeStart, nativeFinish } from '../native-workspace.mjs'
+
+const allowed = {
+  prepare: ['run', 'unit', 'revision', 'apply', 'json'],
+  cleanup: ['run', 'unit', 'revision', 'apply', 'json'],
+  recover: ['repo', 'json'],
+  inventory: ['repo', 'root', 'max-entries', 'max-depth', 'json'],
+  'native-start': ['repo', 'run-id', 'base', 'branch', 'target', 'platform', 'kind', 'native-dir', 'disposable', 'json'],
+  'native-finish': ['run', 'json'],
+}
+
+function options(command, args) {
+  if (!Object.hasOwn(allowed, command)) throw new Error('expected prepare, cleanup, recover, inventory, native-start or native-finish')
+  const out = {}
+  for (let index = 0; index < args.length; index++) {
+    const name = args[index].replace(/^--/, '')
+    if (!args[index].startsWith('--') || !allowed[command].includes(name)) throw new Error(`invalid ${command} option: ${args[index]}`)
+    const key = name.replace(/-([a-z])/g, (_, value) => value.toUpperCase())
+    if (Object.hasOwn(out, key) && name !== 'disposable') throw new Error(`duplicate option: --${name}`)
+    if (name === 'apply' || name === 'json') { out[key] = true; continue }
+    const value = args[++index]
+    if (value === undefined || value.startsWith('--')) throw new Error(`--${name} needs a value`)
+    if (name === 'disposable') (out[key] ??= []).push(value)
+    else out[key] = value
+  }
+  for (const key of ['revision', 'maxEntries', 'maxDepth']) {
+    if (out[key] === undefined) continue
+    if (!/^\d+$/.test(out[key]) || !Number.isSafeInteger(Number(out[key]))) throw new Error(`invalid ${key}`)
+    out[key] = Number(out[key])
+  }
+  return out
+}
+
+try {
+  const [command, ...args] = process.argv.slice(2)
+  const opts = options(command, args)
+  let result
+  if (command === 'native-start') result = nativeStart(opts)
+  else if (command === 'native-finish') result = nativeFinish(opts)
+  else if (command === 'prepare') result = prepare(opts)
+  else if (command === 'cleanup') result = cleanup({ ...opts, runGh: (argv) => execFileSync('gh', argv, { encoding: 'utf8', timeout: 30_000, maxBuffer: 4 * 1024 * 1024, stdio: ['ignore', 'pipe', 'pipe'] }) })
+  else if (command === 'recover') result = recover(opts)
+  else result = inventory(opts)
+  process.stdout.write(`${JSON.stringify(result, null, 2)}\n`)
+  process.exitCode = result.ok === false ? 1 : 0
+} catch (error) {
+  process.stderr.write(`${error.message}\n`)
+  process.exitCode = 2
+}