CRT
c9a7f095c4
- `storebound console plan <form> [--json] [--lookup]`: read-only plan for an AI agent that drives the browser itself: start URL (deep links), ordered steps, answer sheet with the console's exact labels (certain / ask owner, curly quotes noted), never-press list, verified UI facts, driving guidance (in-page async loop + window.__log), verify instructions. All six forms. - `storebound console verify <form> [--from-text <file|->]`: App Privacy per-type summaries from page text, Play Create app from input states, content rating / target audience summaries, App Store record and age rating from the API; exit 1 on a mismatch. - MCP: console_plan, console_verify (read-only); console fill stays off MCP. - App Privacy (verified 2026-10-12): two information steps, unlabeled purpose checkboxes (nearest parent text), "Definitions and Examples" never pressed; fixture and engine follow. - Play Create app (verified 2026-10-12): /developers/<id>/create-new-app, App package name + read-only Check availability, material-radio inner [role=radio] click, app dashboard URL and play.appId, service account "Add app" as an owner step. - console-autofill skill rewritten agent-first; agents-core rule 10; README; pitfalls 12, 18 (confirmed sign-out), 19; CHANGELOG; play-first-release.
37 lines
3.5 KiB
Markdown
37 lines
3.5 KiB
Markdown
# storebound · rules for AI agents
|
|
|
|
These rules apply to every AI tool that uses storebound (skills, MCP server or the CLI in a terminal).
|
|
|
|
**Read `skills/store-pitfalls/SKILL.md` before any store task.** It lists the mistakes already made in real releases
|
|
(store lists that lag after a create, dry runs without a plan, taken App Store names, byte limits, ...) and what to do.
|
|
|
|
1. **The owner decides public and irreversible steps.** Submitting for review (App Review or Beta App Review),
|
|
releasing a version, resuming or completing a rollout, canceling a submission, deleting products or listings,
|
|
accepting agreements, sending review replies, inviting or removing testers, changing prices, starting or stopping
|
|
a store experiment: explain what will happen and let the owner do it (or run the command only after a clear yes in
|
|
chat). storebound's MCP server does not offer these at all.
|
|
2. **Dry run first.** Every write command has `--dry` (MCP: `dry_run`, default true). Show the dry run (the rows that
|
|
change, not just a count), then run it for real only after the owner agrees.
|
|
3. **Read before you write.** `storebound scan` (offline: rejection risks in the project itself), `storebound check`
|
|
(offline) and `storebound validate` (read-only, both stores) tell you what is missing and in which order to fix it.
|
|
4. **Credentials only from the environment, `.storebound/`** in the project (gitignored) **or a credential profile**
|
|
(`~/.storebound/credentials/<profile>.json`, named by `--account <profile>` or a workspace). Never ask for keys,
|
|
passwords or tokens in chat, never print them, never write them into the config, docs or commits. The same goes
|
|
for the App Review demo account (`reviewDemoAccount` in `.storebound/credentials.json`): the owner puts it there.
|
|
5. **Never answer a compliance question you cannot know.** Export compliance, Data safety, App Privacy, age rating,
|
|
target audience: ask the owner when the code does not prove the answer. A wrong "no" is worse than a slow "ask".
|
|
6. **Pick builds by explicit number.** Use the build number / versionCode you just uploaded, never "the latest".
|
|
7. **Long uploads run in the background with a log** (`storebound play images > .storebound/images.log 2>&1 &`) and
|
|
you report the progress lines, not guesses.
|
|
8. **No manipulative tactics** with reviewers, players or store policies: no fake reviews, no incentives for ratings,
|
|
no hidden features, no misleading screenshots, no keyword stuffing.
|
|
9. **Personal data stays local.** Tester lists, review reply drafts, health reports and analytics snapshots live in
|
|
`.storebound/` (gitignored). Never put tester emails, reviewer names or crash logs into issues, docs or commits,
|
|
and never ask for tester emails in chat (storebound masks them in its output).
|
|
10. **Console forms without an API: drive them yourself, agent-first.** `storebound console plan <form> --json` (MCP
|
|
`console_plan`) gives the start URL, steps, the answer sheet, the buttons you must never press and the verified UI
|
|
facts. Drive the page with your own browser tool, adapt to what it shows, run long flows as an in-page async loop
|
|
that writes `window.__log` (one evaluate call times out around 45 s), stop before the final button (Publish,
|
|
Submit, Create, a final Save) and tell the owner exactly what to press, then `storebound console verify <form>`.
|
|
Never sign in, accept an agreement or grant a permission (a service account's app access) for the owner.
|
|
`storebound console fill` is the optional scripted fast path; it never blocks you.
|