storebound/docs/growth.md
CRT 710c3a53d0 README, docs and site: one story (the whole job, no avoidable rejections, the desktop app, your AI, install)
README is a short front page (about 120 lines) with one real visual per section; every former section moved
unchanged into docs/*.md with a docs/README.md index (journey, rejections, getting-started, commands, growth,
studios, store-art, listing-languages, api, skills, mcp, safety, faq, project). The site tells the same story on one
page: the teaser in the hero, real CLI output as text, the desktop app as a section with light/dark captures of eight
screens and the per-system downloads (desktop/latest.json); /desktop/ redirects to /#download. New capture tools:
tools/site-desktop-shots.ts (fixture-mode desktop frames) and tools/site-term-shots.ts (real CLI output as text and
WebP). tests/docs-links.test.ts checks README, docs and site links resolve.
2026-10-13 03:29:59 +08:00

77 lines
7.2 KiB
Markdown

# Growth extras and console forms
Optional commands for after (or around) the first release. Each has `--dry` and `--json`; store and API writes ask in
a terminal first and are never offered over MCP.
- **Purchasing power prices:** `storebound prices ppp [--base 4.99] [--source worldbank|bigmac|file]` proposes a price
per region from the bundled World Bank ICP PPP conversion factors (`cli/data/ppp-worldbank.json`, CC BY 4.0, dated
and cited; refresh with `bun tools/update-ppp.ts`), clamped to `prices.ppp.floor`..`ceiling` of the US price and
snapped to each store's price points. It writes a sheet in the `prices import` format (default
`store/prices-ppp.csv`) and shows the diff; `storebound prices import --csv store/prices-ppp.csv --dry` applies it.
Skill: `ppp-pricing`.
- **Apple Ads:** `storebound ads apple status | campaigns | report [--by campaign|keyword] [--csv out.csv]`: spend,
taps, installs, CPA, read-only (OAuth client credentials from env / `.storebound/`, never printed). `bid`, `budget`
and `pause` print old -> new and ask first. Skill: `apple-ads`.
- **Web presence:** `storebound web init [--landing]` writes `apple-app-site-association`,
`.well-known/assetlinks.json` (Play app signing SHA-256), the Smart App Banner tag and an optional minimal landing
page (store marks from simple-icons, privacy / support links from the config). `storebound web check <domain>`
verifies the live files: 200 without redirects, JSON content type, valid JSON, ids match the config. Skill: `web-presence`.
- **Ad-hoc and internal sharing:** `storebound apple adhoc devices | register | profile | options | export` (UDIDs
masked; registering asks first) and `storebound play share --aab app.aab` (Play internal app sharing; asks first,
prints the install link). Skill: `adhoc-distribution`.
- **RevenueCat (optional):** `storebound revenuecat diff | sync` mirrors products, subscriptions, entitlements and a
default offering into a RevenueCat project (REST API v2, secret key from env / `.storebound/`). sync only creates and
attaches, never deletes. Runtime entitlements, receipts and paywalls stay RevenueCat's job. Skill: `revenuecat-sync`.
- **Console forms without an API, agent-first:** `storebound console plan <form> [--json]` gives your AI agent the
start URL (deep links when the ids are known), the steps, the answer sheet from the config (each answer certain or
"ask owner", with the console's exact labels), the buttons it must never press and the UI facts verified on the real
consoles; the agent drives the page with its own browser tool (Claude in Chrome, a built-in browser, Playwright),
stops before the final button and tells you what to press. `storebound console verify <form> [--from-text -]` then
checks the page against the config (App Privacy per-type summaries, Play Create app input states, summaries, or the
App Store Connect API) and exits 1 on a mismatch. Both are read-only MCP tools (`console_plan`, `console_verify`).
Besides the forms of `console fill`, plans cover the Play pages an agent drives alone: `play-store-settings` (the
App category, which the Play API cannot set), `play-app-content` (every App content card in order with one batch
of owner questions) and its cards (`play-privacy-policy`, `play-ads`, `play-sign-in-details`,
`play-advertising-id`, `play-government-apps`, `play-financial-features`, `play-health-apps`), and the first
production release (`play-production-countries`, `play-production-release`). Each plan ships a ready-made in-page
helper (`inPageLoop`) for long flows.
- **Scripted fast path:** `storebound console fill <form>` (`apple-app-record`,
`apple-age-rating`, `apple-app-privacy`, `play-app-record`, `play-content-rating`, `play-target-audience`) opens a
visible browser, goes to the form by itself (Apps > + > New App, the app's App Privacy, Play All apps > Create app,
Play app list > App content > Start / Manage;
navigation clicks only, never Save / Submit / Publish / Create / Next), fills what the config proves, highlights the
rest and stops before the final button: you press it. **Sign-in:** storebound's own profile
(one per store, `~/.storebound/console-profile/<store>`): you sign in there once, it is kept between runs
(session restore on launch, graceful close; tick "Keep me signed in" / "Stay signed in"). storebound starts that
Chrome itself as a normal window (no `--enable-automation`, `navigator.webdriver` false) so Google accepts the
sign-in; if Google still answers `/signin/rejected` it says so. A Chrome running with remote debugging is used in
place. **It never copies your Google cookies by default:** Google binds them to your device (Chrome's Device Bound
Session Credentials) and signs out sessions whose cookies look copied, which can sign you out of your real Chrome.
`--use-chrome-session google|apple` is an explicit opt-in (a temporary copy of only that store's cookies, deleted at
the end) that prints this warning; see the console-autofill skill. It detects sign-in pages by URL, frame and text (Apple's starts with no password field),
waits while you sign in and then opens the form from step 1; after printing manual steps it keeps watching and picks
up where you are. **One login, many studios:** it finds the Play developer account (by `play.packageName`, or
`play.developerId`) and the App Store Connect team (account menu; `apple.teamId`, or by bundle id) that has the
app and remembers it in `~/.storebound/console-accounts.json` (ids only).
**Play Create app** (`play-app-record`, the Play Developer API cannot create apps): the developer account comes from
`play.developerId`, the workspace account, or `play.developerAccount` (its name on "Choose a developer account");
with several accounts and none set it stops and lists them. It fills App name (`play.name` or `app.name`, 30
characters), Default language, App or game (the profile) and Free or paid (`play.free`, else Free for IAP / ads:
an owner check, a free app can never become paid). It never ticks the Developer Program Policies or US export laws
declarations and never presses the form's Create app: you do. With `play.developerId` it opens the form's own URL
(`/console/u/0/developers/<id>/create-new-app`); it fills App package name from `play.packageName` and presses the
read-only "Check availability", and clicks the inner `[role=radio]` of Play's material radios (the native input
does not update the form). After Create app, grant your service account access to the new app (Users and
permissions > the service account > Add app; a permission grant, so it is yours): app-level permissions do not
cover apps created later. When a page has changed, your agent drives that part with its browser tool from
`storebound console plan`. **Console pages change; this is AI-assisted: review every field before you press the
final button.** Desktop: "Fill in
console" on the App info tab. Never over MCP. Skill: `console-autofill`.
MCP gets only the safe parts: `prices_ppp`, `web_init`, `apple_adhoc_options` (local files, dry run by default) and
the reads `ads_apple_status`, `ads_apple_campaigns`, `ads_apple_report`, `web_check`, `apple_adhoc_devices`,
`revenuecat_diff`.
---
[All docs](README.md) · [README](../README.md)