@1aboveio/skills 1.0.13 → 1.0.15

package/README.md

@@ -52,7 +52,7 @@ See https://github.com/1aboveio/ai/blob/main/docs/native-codex.md for prerequisi
 | `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 |
+| `app-dev` | `@1aboveio/app-dev-skills` | airflow, android-development, 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-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 |
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@1aboveio/skills",
-  "version": "1.0.13",
+  "version": "1.0.15",
   "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": "c7b02c7a0b1255b4c35d2a8975fe235aa5e3ec4e5ae5f052de1ef0a04075323e",
-    "releaseIdentity": "2282acb3b428dfcfe863d5bf3c9963662594d3a79f62156ea165a56a6f6556ad"
+    "metadataDigest": "2bdb58dba1de073baf79efe2c5118ad75c996710344a3cde581976921c1b23ec",
+    "releaseIdentity": "a8975fa459ebba2a3e2661d861bdb9d43c072c1b01adaf41def9a93523782800"
   },
   "pi": {
     "skills": [
@@ -104,7 +104,7 @@
         "needsCore": false,
         "skills": [
           "airflow",
-          "android-foundation",
+          "android-development",
           "app-debug",
           "better-auth",
           "data-catalog",
@@ -260,7 +260,7 @@
         ]
       }
     ],
-    "digest": "90c1d31a13f202af015fbe2c9b15e5e563685e78a4a6daabd6da6e952f64fce0"
+    "digest": "6ad0dafe4a400162776b1bf6d7c9e5ab31bf37a86d18b035fcadc4c11d06f799"
   },
   "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.45.2
+release-version: 0.47.0
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Airflow DAG Development Patterns

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

@@ -0,0 +1,127 @@
+---
+name: android-development
+description: "Prove and debug Expo / React Native apps on an owned Android emulator. Use for Android startup/rendering failures, Metro or ADB problems, UiAutomator/harness failures, APK builds, SDK/NDK/JDK workspace setup, native journey validation, and choosing Kotlin/Compose versus React Native for Android flows. Reproduce failed Android CI checkpoints off CI before fixing and redispatching. Standalone invocation offers Project or Session; init persists repo conventions. NOT for workflow YAML, CI speed or runners (github-actions), browser tests (e2e-test), iOS (ios-foundation), plain Jest tests, or signing/store release."
+release-version: 0.47.0
+---
+**Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
+# Android development
+
+Use the repo's existing native project, build scripts, launcher and journey harness.
+Read its `AGENTS.md`, `CONTRIBUTING.md` Android development section and relevant ADRs.
+Project rules and required CI remain binding; this skill does not add acceptance gates.
+
+## Invocation and persistence
+
+- **Standalone `/android-development`**, without a task or explicit scope: ask once,
+  "Where should the Android workflow apply?" Offer **Project** (persist repo conventions)
+  and **Session** (apply here without writing files). Wait for the answer; cancellation
+  leaves files unchanged. Do not offer global persistence.
+- **Project**, `/android-development init`, or an explicit request to save repo conventions:
+  follow [initialization](references/init.md). Preview, then apply the authorized missing
+  `CONTRIBUTING.md` section and `AGENTS.md` task-entry loader and guide pointer. Check
+  the skill loader separately from an existing guide link. No second approval is needed unless
+  existing policy conflicts. Initialization is not a policy refresh or delivery permission.
+- **Session:** apply this workflow without writing guidance or agent settings. Retain the
+  choice through reload/compaction in this session; a new session makes its own choice.
+- **An actual Android task or automatic skill load:** read and apply the workflow without
+  a scope question or writes. Quoted invocations are not setup requests. If repo guidance
+  is absent, use these defaults and offer init once without blocking the task. An existing
+  guide alone does not authorize persistence. Do not treat unreadable guidance as absent.
+
+## Work loop
+
+Choose the task, not a fresh environment for every attempt:
+
+- **Feature:** implement, then follow the applicable validation levels below.
+- **Debug:** reproduce the failing screen/action/build/harness checkpoint, inspect its
+  evidence, fix the cause, and confirm that the original reproduction passes. Then follow
+  the same validation ladder. Read [diagnosis](references/diagnosis.md) before debugging.
+  For CI failures, reproduce the checkpoint off CI before fixing and redispatching;
+  never send a guessed correction to CI to discover whether it works.
+- **Setup proof:** only for a new environment or invalidated setup assumptions. Read
+  [workspace](references/workspace.md) and [setup](references/setup.md), run all applicable
+  repo-specific stages in order and record proof. Do not add Expo or a new harness merely
+  to match the examples, or repeat cold setup for ordinary fixes.
+
+## Validation ladder
+
+Read [feature work](references/feature-work.md) for selection, ownership and handoff.
+These feedback times are targets, not promises or automatic command deadlines.
+
+| Level | Trigger | Verification | Target feedback |
+| --- | --- | --- | --- |
+| L0: Fast | Each code edit | Focused tests, relevant typecheck, and Fast Refresh on the owned app for applicable JS/UI behavior | 5-60 sec |
+| L1: Native | Native code, SDK/dependency or native configuration changes | Incremental emulator-ABI build, install/update, and exercise affected native behavior | 1-4 min |
+| L2: Integration | PR or meaningful feature checkpoint | Candidate APK, fresh-install startup smoke on disposable owned state, and selected real journeys | 5-15 min |
+| L3: Acceptance | Assigned merge/release checkpoint | Required regression, security, backend, device and ABI matrix | As required |
+
+Skip L1 when native inputs did not change. Do not defer affected runtime checks to L2
+just because L0 is fast. Fast Refresh and build success are not packaged-app proof.
+If a level fails, debug and fix that failure, confirm its reproduction, then repeat the
+checks the correction invalidated. Preserve applicable evidence and required current-source
+CI; do not restart the whole campaign. Finish at the assignment's checkpoint and report
+higher levels still pending rather than claiming acceptance.
+
+## Principles
+
+- **Minimize coordination cost.** Choose the smallest design that preserves the required
+  behavior and reduces demonstrated coordination cost.
+- **Reuse valid state; invalidate only what changed.** A source edit does not automatically
+  invalidate the environment or every artifact.
+- **Match proof to the claim.** Focused development feedback and release acceptance prove
+  different things. Use provenance to qualify evidence, not postpone runnable tests;
+  speed does not waive correctness or explicit identity gates.
+- **Make ownership explicit.** State transitions and resources need an authoritative owner;
+  shared access does not imply permission to reset or modify them.
+
+## DOs
+
+- Resolve the [owned workspace](references/workspace.md) and actual candidate HEAD. Classify
+  changed inputs; verify the [command/task graph](references/feature-work.md#verify-command-expansion)
+  before adopting a native build route, not as a prerequisite for independent source tests.
+- Run independent source tests against the working changes immediately. Record HEAD and
+  dirty state, verify the code loaded by each relevant test, and report artifact checks separately;
+  read [test-first provenance](references/feature-work.md#run-tests-before-chasing-commit-labels).
+- Start Metro once per owned development session for a Metro-backed debug app. Reuse its
+  server/port, installed app and booted emulator across edits and focused checks.
+- Assign separate Metro servers/ports and device mappings to independently changing source
+  trees/configurations. Share only the same intentional source/config under one runtime owner;
+  follow [parallel runtime ownership](references/workspace.md#parallel-development-sessions).
+- Use Fast Refresh or reload for refreshable JS/TS edits. Do not run Gradle, reinstall,
+  reboot or restart the backend solely because HEAD changed.
+- Incrementally build/install the actual device ABI when native inputs change and exercise
+  the affected behavior. Retain compatible Metro, emulator, Gradle daemon and private outputs.
+- Restart only the resource invalidated by configuration, incompatibility or demonstrated
+  failure. Stop owned resources or explicitly hand them off at session completion; finishing
+  one check is not session completion. Read [runtime and cleanup](references/setup.md#owned-development-session) first.
+- Use repo-pinned tools, frozen installs and installed SDK components. Bound commands/child
+  waits with cleanup time; preserve the original failure separately from cleanup errors.
+- Keep writable caches and fixture data private; never use shared/production data or
+  signal unverified stale PIDs. Follow the existing resource owner's cleanup rules.
+- Record native artifact and served-JS identities, variant/API/ABI and sanitized evidence.
+  Preserve all configured ABI setup/release proof and distinguish local, CI and post-deploy results.
+
+## Avoids
+
+- Do not routinely rebuild, reinstall or restart the emulator for JS edits the app can load.
+- Do not automatically run cold setup, clean, prebuild or shared SDK upgrades for an ordinary correction.
+- Do not hide test-APK packaging or all-ABI builds in development commands without a relevant
+  requirement. Keep required instrumentation and all-ABI acceptance explicit and intact.
+- Do not borrow writable caches, reset peer runtimes, reuse invalid native artifacts or invent flags.
+- Do not treat a fast local pass as release acceptance or add pools/metrics systems by default.
+- Do not commit, publish, tag or rebuild unrelated artifacts just to match SHA labels before
+  testing. Do not count tests loading an unchanged package as proof of its correction.
+
+## Read when needed
+
+| Topic | Required reference |
+| --- | --- |
+| Repo convention persistence | [init.md](references/init.md) |
+| Kotlin/Compose vs React Native selection | [Kotlin/Compose vs React Native](references/framework-choice.md) |
+| Workspace selection and retention | [workspace.md](references/workspace.md) |
+| Development-session lifecycle and resource ownership | [Owned development session](references/setup.md#owned-development-session) and [runtime ownership](references/workspace.md#development-workspace-owned-session-runtime-and-disposable-runs) |
+| Parallel warm servers and test-first provenance | [Parallel sessions](references/workspace.md#parallel-development-sessions) and [test-first provenance](references/feature-work.md#run-tests-before-chasing-commit-labels) |
+| Builds, provisioning, device execution, cleanup and setup proof | [setup.md](references/setup.md); use [device-run.sh](scripts/device-run.sh) only without an existing resource owner |
+| Feature/fix validation and handoff | [feature-work.md](references/feature-work.md) |
+| Failure reproduction and correction | [diagnosis.md](references/diagnosis.md), then the relevant [gotcha](references/gotchas.md) |
+| CI integration | [ci.md](references/ci.md), [template](assets/android-ci-job.yml), and `github-actions` |

package/skills/app-dev/android-development/references/android-conventions.md

@@ -0,0 +1,117 @@
+## Android development
+
+This section records validation order, proof limits and this repo's verified command map.
+Before a selected check, resolve only the commands and inputs it needs from the repo's scripts,
+CI configuration and native project. Do not delay a verified source test while resolving an
+unrelated native build, journey or CI command. Report unresolved commands for their affected
+checks instead of guessing them. Add verified bindings during explicit initialization;
+do not restate or contradict existing project policy.
+
+Required CI, release gates, safety rules and cleanup ownership stay binding at every rung. The
+ladder validates the corrected candidate; it never waives a gate the repository requires.
+
+### Principles
+
+- **Minimize coordination cost.** Choose the smallest design that preserves the required
+  behavior and reduces demonstrated coordination cost.
+- **Reuse valid state; invalidate only what changed.** A source edit does not automatically
+  invalidate the environment or every artifact.
+- **Match proof to the claim.** Focused development feedback and release acceptance prove
+  different things. Use provenance to qualify evidence, not postpone runnable tests;
+  preserve explicit source/artifact identity gates.
+- **Make ownership explicit.** State transitions and resources need an authoritative owner;
+  shared access does not imply permission to reset or modify them.
+
+### DOs
+
+- Classify changes and verify actual command expansion: app assembly/install, test APK
+  packaging and test execution are different work. Inspect native build routes when needed;
+  do not make that a precondition for independent source tests. Retain required CI and consumers.
+- Run independent source tests against the working changes immediately. Record actual HEAD
+  and dirty state once, verify the source/module/output loaded by the relevant test, and
+  report missing integration artifacts separately. Build affected package output only when
+  the test needs it; retain exact identity requirements for assigned workspaces, CI and releases.
+- Start Metro once per owned development session for a Metro-backed debug app and reuse the
+  same server/port, installed app and booted emulator across edits and focused checks.
+- Assign separate warm Metro servers, host ports and device mappings to independently
+  changing workspaces/configurations. Share one only for intentional same-source/config
+  work under one owner, with coordinated writes and exclusive mutating device checks.
+  Schedule device conflicts within host capacity; keep caches and test data isolated and
+  stop shared services only after every user releases them or an explicit handoff.
+- Use Fast Refresh or reload for refreshable JS/TS edits; do not run Gradle, reinstall,
+  reboot or restart the backend solely because the source HEAD changed.
+- Incrementally build/install the actual device ABI when native inputs change and check
+  the affected behavior. Retain compatible Metro, emulator, Gradle daemon and private outputs;
+  preserve the configured ABI matrix for setup/release acceptance.
+- Restart only a resource invalidated by configuration, incompatibility or demonstrated
+  failure. Stop owned services or explicitly hand them off at session completion, not after
+  each check. Use the owner's bounded shutdown and verify exit; never reset peer resources.
+- Track native artifact and served-JS identities separately. Invalidate shell reuse when
+  native inputs change; never relabel an older APK as a current-source build.
+- Prefer shared RN UI for cross-platform forms/lists and Kotlin/Compose for new Android-only
+  native-heavy flows when making an explicit framework decision supported by product requirements.
+  Keep the existing stack for ordinary fixes; migration needs separate authorization.
+
+### Avoids
+
+- Do not routinely build/install APKs, reboot the emulator, clean or prebuild for refreshable JS edits.
+- Do not hide test packaging, all-ABI builds or acceptance campaigns inside a supposedly fast lane.
+  Preserve intentional test consumers and full required validation when separating commands.
+- Do not share writable caches, reset peer runtimes, reuse invalid native artifacts or invent selectors.
+- Do not guarantee timings, introduce emulator pools by default or add metrics infrastructure.
+- Do not delay runnable tests while chasing matching package/commit labels, or publish/tag/
+  commit unrelated work to obtain them. Do not count an unchanged installed package as fix proof.
+- Do not switch one Metro between candidate trees or alter another session's device mapping.
+  Do not let one blocked artifact prevent independent source checks or waive explicit CI gates.
+
+### Repository command map
+
+During explicit initialization, record the verified working directory, command, native/JS
+inputs, produced app/test artifacts and resource owner for L0-L3. Inspect effective Gradle
+task expansion before calling a route app-only; keep unverified commands or graphs unresolved.
+Prefer existing Expo/React Native scripts. Distinguish source inspection from an observed run;
+init does not require provisioning, a cold build or a full acceptance campaign. Later init
+runs preserve this section and its manual command bindings rather than refreshing them.
+
+### Debug, fix, validate
+
+1. Record the failed checkpoint, source SHA and the actual checkout, build variant, device or
+   ABI, and the evidence already kept. Name the earliest failing stage: build/install, launch,
+   load code and assets, initialize, render, interact.
+2. Reproduce the actual failing screen, action, build task or harness checkpoint. Reproduce a
+   failed CI checkpoint off CI before fixing and redispatching. Inspect the relevant compiler,
+   process/runtime log, app request or UI state; change one relevant variable at a time.
+3. Correct the cause and confirm that the original reproduction passes. Add a focused regression
+   test where it can expose the defect, then follow the applicable L0-L3 levels below. A passing
+   reproduction alone is not acceptance. If validation finds another defect, fix it and repeat
+   checks the correction invalidated rather than restarting the whole campaign.
+4. Report the commands used, their results, remaining gaps and any level still owed. Keep failed
+   attempts; a later pass does not erase them.
+
+### Validation ladder
+
+Run L0 after code edits, L1 when native inputs change, and L2/L3 at their assigned project
+checkpoints. Do not defer affected runtime checks merely to keep L0 fast. Feedback times are
+targets, not deadlines, measured results or promises.
+
+| Rung | Scope | Target feedback |
+| --- | --- | --- |
+| L0 | Edits to app code: affected fast tests, typecheck, Fast Refresh on the running app | 5–60 s |
+| L1 | Native code, SDK/dependency or native configuration change: incremental emulator-ABI build, install/update, affected runtime check | 1–4 min |
+| L2 | PR or feature checkpoint: candidate APK from current source, fresh-install smoke on disposable owned device and backend state, selected real journeys | 5–15 min |
+| L3 | Merge and release: the repository-required regression, security, backend, device and ABI matrix | as required by the repository |
+
+- L0 and Fast Refresh prove a source change in a running app, not a packaged artifact. A claim
+  about installed, packaged or distributed behavior needs L2 or L3 evidence from the same source
+  and configuration.
+- Skip L1 when native inputs did not change. Retain required additional ABI checks for native
+  or ABI configuration changes. Setup proof and release acceptance build every configured ABI;
+  an emulator-ABI build proves only the emulator ABI. Compilation alone is not runtime proof.
+- L2 installs on disposable state this run owns and records the identity of the APK it installed.
+  Reuse earlier evidence only while its source, configuration, artifact and environment still
+  apply to the behavior being claimed.
+- Fresh-install proof does not cover upgrades or authorize clearing a borrowed device; preserve
+  upgrade-state checks when relevant. Reuse the existing resource owner, keep writable state
+  private, bound waits with cleanup time and never use shared/production fixture data.
+- The developer owns focused validation and independent review checks the correction. The
+  coordinator schedules broader L2/L3 checks; keep remaining required levels explicitly pending.

package/skills/app-dev/{android-foundation → android-development}/references/ci.md

@@ -19,8 +19,10 @@ trigger and required-check contract unless changing it is part of the task.
    never run on the self-hosted Android runners.
 3. Add `android` to `gate`'s `needs:` and a `check android "$ANDROID_RESULT" "$ANDROID"`
    line. Require only `gate`.
-4. Before merging, open one Android-only PR and one docs-only PR. Confirm the job runs on
-   the first, is skipped on the second, and `gate` passes on both.
+4. Verify both Android-only and docs-only changed-path cases: the job runs for the former,
+   skips for the latter, and the required gate handles both correctly. Reuse sufficient
+   existing run evidence or the repo's supported validation method. Open dedicated PRs
+   only when explicitly authorized and needed; this check does not grant delivery permission.
 
 ## Runner
 
@@ -50,8 +52,9 @@ trigger and required-check contract unless changing it is part of the task.
 - Build `x86_64` only (`-PreactNativeArchitectures=x86_64`), with `--no-daemon` and
   `-Pandroid.builder.sdkDownload=false`. Report
   this APK as emulator evidence only. The all-ABI build stays a local or release step.
-- Bundle the JavaScript with `expo export --platform android` before the native build so
-  bundling errors fail fast.
+- Bundle/export JavaScript with the repo's supported tooling before the native build so
+  bundling errors fail fast; use `expo export --platform android` only for Expo projects.
+  Preserve an existing bundle/build dependency order when it already provides this proof.
 - Give the job `timeout-minutes: 60`, the install step its own short timeout, and the
   APK build `timeout-minutes: 30`.
 
@@ -64,8 +67,9 @@ trigger and required-check contract unless changing it is part of the task.
 - Run the native auth/integration tests against that service before the device journey.
 - Unit-test the device orchestration scripts (journey wrapper, slot allocator, code
   lookup) before booting the emulator.
-- Pin the UI automation package in a venv at the path the journey wrapper reads; use the
-  Python version the harness supports (3.12 on CI).
+- If the existing harness uses Python UI automation, pin its package in the venv the
+  wrapper reads and use its supported Python version (3.12 in the example). Do not add
+  Python or replace an instrumentation harness solely to match the template.
 - Boot the emulator with the SHA-pinned `reactivecircus/android-emulator-runner`, or the
   runner's preinstalled emulator under an owned process group. Use the API level, target
   and ABI of the preinstalled image, `disable-animations: true`, `ram-size: 4096M` (or

package/skills/app-dev/{android-foundation → android-development}/references/diagnosis.md

@@ -1,8 +1,31 @@
 # Diagnose an existing Android failure
 
-Use the smallest investigation that can distinguish the remaining explanations. Reuse
-established resources and caches; do not build a second test platform to explain one
-failure. This procedure works without another diagnosis skill.
+Get to a correction of the reported failure, then validate the corrected candidate through
+the [L0-L3 ladder](../SKILL.md#validation-ladder). Reuse established resources and caches;
+do not build a second test platform to explain one failure.
+
+## Reproduce, diagnose, fix
+
+1. Reproduce the actual failing screen, action, build task or harness checkpoint. For a
+   failed CI journey, reproduce that checkpoint off CI before fixing and redispatching.
+   Record the failed source, variant and environment; retain the original failure evidence.
+2. Inspect the first relevant error and the actual operation: compiler output for build
+   failures, process/crash logs for launch, app requests for loading, and screenshots,
+   hierarchy or state transitions for UI failures. Use the stage table below to narrow it.
+3. Find and correct the cause. Test one explanation at a time and add a focused regression
+   test at the boundary that exposes the defect where feasible. Do not substitute a
+   passing fake UI or readiness probe for the missing real app observation.
+4. Repeat the original reproduction and confirm the correction works. Then follow L0,
+   applicable L1, and the assigned L2/L3 checkpoints in [feature work](feature-work.md).
+   If validation exposes another defect, debug and fix it, then repeat invalidated checks.
+
+The developer owns technical diagnosis and focused validation. The coordinator owns
+scope and broader acceptance scheduling. After review handoff or a broader acceptance
+failure, assign a bounded investigation with the failed checkpoint, evidence, next
+question and return condition; the same developer may do it. Independent review checks
+the fix. Return scope growth, missing access or inconclusive evidence to the coordinator,
+not an unlimited campaign. Report local reproduction, source CI and post-deploy results
+separately; another API/ABI or copied APK does not prove the original CI artifact.
 
 ## Locate the failing stage
 
@@ -80,6 +103,11 @@ worker's "running" status does not impose a timeout or demonstrate progress. The
 whole journey. Set a positive value for unattended runs; its backward-compatible
 zero default disables that deadline. Allow time for the owner to finish cleanup.
 
+Use the harness's background-task mechanism when a journey can exceed the foreground
+command limit. Budget for the selected journey and owned cleanup; feedback-time targets
+are not kill deadlines. Continue independent work and inspect the terminal result when
+notified, rather than waiting or polling in the foreground. Do not add another watcher.
+
 For a hung test, identify the actual outstanding command and last completed assertion.
 If the test waits for a child to exit, check whether its input actually requires exit.
 Reduce that question to a bounded host test before launching another emulator.
@@ -90,6 +118,12 @@ purpose and cost bound first. When no available experiment distinguishes the rem
 explanations, report the missing evidence/access. Do not restart an unchanged campaign
 or impose an arbitrary fixed number of retries on every kind of failure.
 
+Carry the failed checkpoint and prior attempts across worker changes. Before adding a
+service, transport or test abstraction, name the existing criterion it enables and why
+the current path cannot answer the question. Use an existing known-working comparison
+when available, but do not launch a baseline campaign or count it as candidate proof.
+Report delivered behavior and remaining gaps first; a diagnostic helper is not acceptance.
+
 Choose the environment the assertion requires: local test resources for ordinary
 functional diagnosis, isolated deployed HTTPS when that behavior requires it, or an
 existing shared deployment for explicitly non-destructive smoke checks. Create only the
@@ -118,19 +152,14 @@ Do not kill another worker's server if the app accidentally connects to it.
 - Bundle succeeds, expected screen absent: inspect runtime exceptions, actual screen
   and selector.
 
-In fmm-express #2001, a local API36 ARM64 comparison failed without the preference,
-rendered Login after setting it, and failed again after removing it. The original API35
-x86_64 CI response was not retained; the local HTTP 500 was not claimed as that response.
-The corrected post-deploy CI subsequently passed on its deployed SHA. Ports, package,
-cloud infrastructure and issue identifiers are case-study details, not requirements.
+Use any controlled comparison only for the source, API and ABI actually observed. A local
+failure or correction does not reconstruct a missing CI response. Retain that evidence gap
+and prove the corrected deployed artifact separately when the checkpoint requires it.
 
-Another repo-specific example was a Node first-login fixture with an empty Organization
-list consumed by Python. Passing the actual producer output through the real reader
-and journey seed selection exposed the mismatch before another cloud/device run. The
-general lesson is to test the composed contract, regardless of language or domain.
+For a fixture consumed by another language or process, pass the real producer output
+through the actual reader and journey selection. Empty collections or missing context
+can expose a contract mismatch before another cloud/device run; handwritten fixtures on
+each side cannot establish that the composed path works.
 
-- [Case study: issue #2001](https://github.com/1aboveio/fmm-express/issues/2001)
-- [Correction PR #2010](https://github.com/1aboveio/fmm-express/pull/2010)
-- [Passing post-deploy run](https://github.com/1aboveio/fmm-express/actions/runs/40329312705)
 - [RN 0.81.5 preference handling](https://raw.githubusercontent.com/facebook/react-native/v0.81.5/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/packagerconnection/PackagerConnectionSettings.kt)
 - [RN 0.81.5 host selection](https://raw.githubusercontent.com/facebook/react-native/v0.81.5/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/modules/systeminfo/AndroidInfoHelpers.kt)

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

@@ -0,0 +1,186 @@
+# 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. Follow the [L0-L3 ladder](../SKILL.md#validation-ladder); do not duplicate setup
+or full acceptance per edit. Name the immediate existing acceptance checkpoint, such as
+opening the app and rendering the expected screen. Setup success is not that outcome.
+
+| Stage | Scope | Ownership |
+| --- | --- | --- |
+| L0 and applicable L1 | Focused checks and affected runtime behavior during implementation. | Developer validates, reports evidence and gaps, then hands off to independent review. |
+| L2 | Packaged-app startup and affected journeys through combined changes. | Coordinator schedules validation as soon as its prerequisites are ready, including before PR/merge when repo policy requires it. |
+| L3 | Remaining cross-feature, device-matrix and release obligations, plus invalidated checks. | Coordinator accounts for required gates and reuses evidence only within its proven scope. |
+
+## Choose the work before building
+
+Classify the changed inputs and affected behavior before selecting a command. Keep required
+CI and assigned acceptance checks; fast feedback supplements them rather than replacing them.
+
+| Changed input | Development response |
+| --- | --- |
+| JS/TS logic or styling loaded by the existing Metro-backed app | Keep the owned runtime; focused tests/typecheck and Fast Refresh or reload. Do not invoke Gradle, reinstall or reboot solely for this edit. |
+| Native code, native dependency resolution, code generation, manifest/configuration or native resources | Incremental L1 build/install for the owned device ABI, then the affected runtime check. |
+| Assets | Determine their delivery path: Metro-served assets may reload; packaged resources/embedded bundles need repackaging and affected install/runtime proof. Do not classify every asset as native or every JS edit as refreshable. |
+| Authentication, payments, security or lifecycle contracts | Add the affected contract/device/integration checks at the assigned checkpoint; neither the filename nor a small diff justifies omitting them or automatically running every acceptance test. |
+
+Use the repo's existing Expo/React Native development route before proposing a new wrapper.
+An already installed compatible debug shell can load updated JS through the owned Metro.
+Native/build-input changes invalidate that reuse; unknown compatibility calls for a scoped
+rebuild, not an assertion that the old APK is current. Do not run `expo prebuild` routinely
+against tracked native projects.
+
+### Check journey admission before reserving devices
+
+Before an expensive native journey, verify the exact selected case and supported arguments
+against the existing runner, required installation/resource owners, effective test flags,
+and device settings. Use existing help, parser tests or preflight commands when available;
+do not invent a selector or build another preflight framework. Missing admission support
+is a harness limitation to resolve, not a reason to allocate devices and discover it later.
+Continue independent source tests while device prerequisites are checked.
+
+Apply lifecycle-changing display size, density and other required presentation settings
+before app launch when the journey relies on retaining that Activity or observation scope.
+Read back the effective settings through the existing owner. A later setting change may
+recreate the Activity; do not hide scope retirement with registration retries or relaxed
+identity checks. Keep this check scoped to the selected case, not every possible device cell.
+
+### Verify command expansion
+
+Before adopting a native fast path, trace its package script, wrapper, Gradle tasks and
+consumed artifacts. Inspect the effective task graph in the owned, prepared environment
+with the repo's wrapper and a bounded `--dry-run` when available; this still configures the
+project and may resolve plugins, so it is not an L0 check or permission to provision tools.
+If it cannot be inspected, report the unverified expansion rather than calling it app-only.
+
+Distinguish app assembly/install, instrumentation-test APK packaging, test execution and
+broader journeys. For example, an `assembleDebug` dependency on `assembleDebugAndroidTest`
+adds test packaging to that task, but does not prove every other debug/install route does
+so. A task name such as `installDebug` is not proof of its dependency graph either.
+Preserve an intentional separate-UID consumer or required test artifact. If separation is
+needed, route the authorized build/CI change through `github-actions`, explicitly retain
+the required test tasks/artifacts in validation, and verify both paths. Do not hide the
+cost or bypass obligations with arbitrary task exclusions.
+
+### Run tests before chasing commit labels
+
+Verify the code under test, not matching labels across every package and artifact. Record
+the actual workspace, HEAD and uncommitted changes once, then run independent source tests
+against those working changes. Do not require a clean tree or a new commit merely to start
+L0 checks. Revisit identity when relevant inputs, resolution or the runtime change, not as
+a repeated search for matching SHAs before every test.
+
+For a changed package, verify the actual module path or build output loaded by its consumer.
+Use the repo's supported workspace dependency, local build or package-install route to load
+the correction. A package version, common Git label or passing test against an unchanged
+installed copy does not prove the fix. If an integration check needs new compiled output,
+build that affected output; do not hunt for an older artifact with a matching commit label.
+Keep package lookup and identity checks bounded by the question they answer.
+
+| Check | Identity needed before claiming the result |
+| --- | --- |
+| Focused source test | The actual changed source loaded by the test, including working changes |
+| Package integration | The actual changed package output loaded by the real consumer |
+| Metro-backed app behavior | Compatible native shell plus the actual JS source/endpoint served |
+| Required CI, release or published-artifact verification | The exact identity mandated by that checkpoint |
+
+Do not publish, tag, commit or rebuild unrelated components solely to manufacture matching
+labels. If changed package output cannot yet be loaded, mark that integration check pending
+or blocked and run other ready source checks. Report "source tests passed; installed-package
+integration pending" when that is what the evidence proves; do not relabel a source pass as
+integration success or substitute mocks for the changed first-party path.
+
+Retain explicit current-source CI/release identity requirements. A wrong assigned checkout
+or candidate revision is a real scope problem: follow [workspace precedence](workspace.md#precedence),
+report it and do not silently reset, test a substitute revision or search indefinitely for
+an equivalent package. Local test execution does not authorize waiving that assignment.
+
+### Track native and JS provenance separately
+
+For a development session, record the installed native artifact's source/build inputs,
+package, variant and ABI separately from the JS source and actual Metro endpoint serving
+the current candidate. Compare native sources, resolved native dependencies, build/config
+inputs and packaged resources before reusing that shell. A changed Git HEAD alone is not
+a reason to rebuild if only Metro-served JS changed and policy allows shell reuse.
+
+An APK built at A and JS served from B are valid scoped development evidence only when
+those identities and native compatibility are known. Do not call the APK a build of B or
+claim packaged/release proof from it. L2/L3 still use the artifact/source checks their
+checkpoint requires. No new fingerprint service or cross-checkout artifact copying is implied.
+
+## Apply the levels
+
+- At L0, use Fast Refresh only when the selected debug build supports it and the owned app
+  is running. It helps check JS/UI edits, but does not prove a fresh launch, install or
+  embedded release bundle. Use the repo's focused tests and relevant typecheck commands.
+- At L1, changed Kotlin/Java/C++/Compose code, native SDKs/dependencies or native build
+  configuration require an incremental build, install/update and the affected device
+  interaction. Use the emulator ABI where repo policy permits; retain required additional
+  ABI checks. A successful compile is not native runtime proof.
+  Use the actual owned device ABI and a per-invocation override, not an assumed x86_64
+  target or a change to the shared all-ABI default; see [setup](setup.md).
+- At L2, use the candidate APK and its actual bundle/asset-loading mechanism, not just a
+  development session. Fresh-install smoke uses disposable owned app state; it does not
+  prove upgrades or authorize clearing a borrowed device. Run upgrade-state coverage when
+  required. Exercise the changed journey using supported selectors.
+- At L3, run the matrix and regression/security/backend checks the repo/spec assigns to
+  that checkpoint. This is not a new requirement to run every conceivable test per PR.
+- Treat feedback times as targets to measure, not evidence of achieved speed. Set real
+  command deadlines for the selected work and leave time for owned cleanup.
+
+## Debug, fix, then validate
+
+Reproduce the failure, inspect the relevant evidence, correct the cause and confirm that
+the original reproduction passes. Then run L0, applicable L1, and L2/L3 at their assigned
+checkpoints. The original reproduction passing does not replace the ladder. If a level
+finds another defect, fix it and repeat the checks that correction invalidated; do not
+restart unchanged setup or the entire campaign.
+
+For example, a JS filter fix needs its focused regression test and open/edit/apply/result
+check at L0, no L1 if native inputs are unchanged, and that journey in the candidate APK
+at L2. Required CI and L3 obligations remain assigned, not silently waived or marked done.
+
+## Plan and hand off
+
+- 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 original reproduction passes, then follow the applicable ladder and rerun
+  the affected check once at its assigned checkpoint.
+  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.
+  Reuse existing logs to distinguish cold/warm builds, build count, ABI, test packaging,
+  runtime startup and edit-to-feedback time. Do not infer a task's cost from total job time,
+  claim measured savings from a flag change, or add a metrics pipeline for this purpose.
+- 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.
+