PokeClaw CLAUDE.md

PokeClaw — Project Rules

Read This First

Before changing prompts, skills, task routing, local runtime, QA, or release behavior, read README.md sections Product Direction, Roadmap, and Known platform constraints.

The short version: PokeClaw is a generic Android mobile-agent harness, not a collection of hardcoded demo tasks. Prioritize runtime, hardware, storage, accessibility, foreground-service, install/signing, and QA-harness correctness before narrow prompt or workflow tuning.

Project Files

File	What	When to update
README.md	Public product direction, roadmap, changelog	When product direction, roadmap, release notes, or public claims change
AI_INDEX.md	Repo map for coding agents	When files or directories move
CLAUDE.md	Project rules	When workflow/rules change
QA_CHECKLIST.md	E2E test cases + debug changelog	Every code change
RELEASING.md	Stable signing and release workflow	When the release process changes
BACKLOG.md	Features, bugs, ideas with priority	When new items come in or items get done
ARCHITECTURE_RECONSTRUCTION.md	Historical architecture/refactor guardrails	When reconstruction phases change
CLAUDE.local.md	Current session state	Every session

When Nicole mentions a feature idea, bug, or "之後要做" item → write it into BACKLOG.md immediately. Don't rely on session memory.

QA-First Development (MANDATORY)

Every code change MUST include E2E QA. No exceptions. This is the highest-priority practice in this project.

QA must reflect the product direction in README.md: do not turn stochastic model performance into one-off prompt drilling. Fix and gate deterministic harness failures first, then measure exploratory model tasks by repeated-trial success rate.

Per-Change QA (every commit)

1. Design QA tests FIRST — before writing code, define what the E2E test looks like
2. Add tests to QA_CHECKLIST.md — permanent, under the relevant section (A-K or new section)
3. Tests must be E2E via ADB — simulate real user behavior: adb shell input tap/text, adb shell am broadcast, uiautomator dump, logcat verification. No unit tests, no mocks. Control the phone like a user would.
4. Cover edge cases — happy path + error path + boundary conditions. For every feature, ask: "what if permission is missing?", "what if network drops?", "what if user taps twice?", "what if another task is running?"
5. Run the new tests — execute them yourself, verify PASS, record results in the QA Debug Changelog
6. Run affected existing tests — any section that could be impacted by the change, re-run those tests
7. After a big feature — run the FULL checklist top to bottom (all sections A-K+)