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

7.2 KiB

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