@drip-apex/apex-cli 0.5.0 → 0.6.1

package/AGENTS.md

@@ -4,7 +4,7 @@ Use `apex` as the canonical command name. `drip` is a compatibility alias.
 
 ## Canonical Loop
 
-1. `apex experiments pull <id-or-slug> --dir <folder>`
+1. `apex experiments pull <id-or-slug> --out <folder>`
 2. Edit only supported files in the pulled folder.
 3. `apex experiments plan <folder> --json`
 4. `apex experiments apply <folder> --json`
@@ -47,8 +47,8 @@ the first writes: `apex experiments create`, `apex goals create`,
 
 ## Recovery
 
-- Missing auth: run `apex login` interactively, or set `DRIP_API_KEY`.
-- Headless login: pass `--api-key` or set `DRIP_API_KEY`; do not wait for prompts.
+- Missing auth: run `apex login` interactively, or set `APEX_API_KEY`.
+- Headless login: pass `--api-key` or set `APEX_API_KEY`; `DRIP_API_KEY` remains a compatibility fallback.
 - Do not wait for prompts in CI or agent runs. If a command returns exit `4`, rerun with the exact flag named in the JSON error details only after checking the plan or destructive action.
 - Apply invalidates QA: inspect `apex experiments plan`, then rerun apply with `--force` if intended.
 - Stale workspace or filesystem: pull fresh files, reapply your edits, and plan again.
@@ -56,6 +56,7 @@ the first writes: `apex experiments create`, `apex goals create`,
 
 ## Filesystem Rules
 
+- Formatting is enforced by Biome (`npm run format`); do not hand-wrap code.
 - Treat `.apex/` as CLI-owned metadata.
 - Edit experiment files, variation code, metrics, and targeting only through supported paths.
 - Do not bypass the variation artifact persistence path with direct API writes.

package/README.md

@@ -1,5 +1,20 @@
 # Apex CLI
 
+## Purchase-capture verification
+
+The CLI exposes a read-only, publication-anchored purchase verification battery:
+
+```bash
+apex shops doctor --check purchase_capture
+apex tracking verify --event-type goal,conversion,purchase,checkout_completed,order_created --minutes 10080
+apex install check --shop-id "$APEX_SHOP_ID"
+```
+
+`purchase_capture` reports `OK`, `DARK`, or `NO_DATA`; a young window or unknown historical cadence
+is `NO_DATA`, never a healthy result. Tracking verification renders compact event-property previews
+in human mode and preserves complete properties in `--json`. Install checks report the served
+`dataLayerTriggers` count and whether an enabled revenue trigger exists.
+
 ## Authentication and context
 
 Run `apex login` once to authenticate your account. Interactive login opens
@@ -16,7 +31,7 @@ stdout. Flags and environment variables are explicit choices and stay silent.
 JSON envelopes echo the effective org, shop, and credential kind.
 
 Automation should continue injecting a narrow shop key per process with
-`DRIP_API_KEY`; it takes precedence over a stored user credential and does not
+`APEX_API_KEY`; it takes precedence over a stored user credential and does not
 change the stored login. Use `apex login --api-key apx_uk_...` for a headless
 account login or `apex login --api-key apx_...` to store a shop key. The old
 `apex login --user` spelling is a deprecated alias for `apex login`.
@@ -42,7 +57,7 @@ headless environments, use an existing API key:
 
 ```bash
 apex login --api-key apx_your_key_here
-DRIP_API_KEY=apx_your_key_here apex experiments list --json
+APEX_API_KEY=apx_your_key_here apex experiments list --json
 ```
 
 ## Common usage
@@ -83,13 +98,28 @@ including every subcommand, argument, option, and alias.
 - `apex login` — authenticate with a shop or user API key.
 - `apex logout` — remove stored credentials.
 - `apex whoami` — inspect the current credential and its validity.
+- `apex use` — select the current organization and shop context.
 - `apex account` — manage the current user profile.
 - `apex keys` — manage shop API keys.
 - `apex org` — inspect and manage the organization.
-- `apex team` — manage organization members and invitations.
+- `apex team` — manage shop-scoped members and invitations.
 
 ### Experiments and delivery
 
+- `apex consent` — manage consent gating.
+- `apex triggers` — manage data-layer triggers and temporary setup capture.
+- `apex triggers get --shop <domain-or-id>` — read the identified shop's runtime triggers.
+- `apex triggers set` — replace the shop's runtime triggers from a JSON file.
+- `apex triggers propose` — propose candidate triggers from a discovery report.
+- `apex triggers apply-recipe` — apply a server-owned trigger recipe.
+- `apex triggers enable-capture` — enable temporary setup capture.
+- `apex triggers disable-capture` — disable setup capture and clear its expiry.
+- `apex domains` — manage install domains.
+- `apex handover` — manage cross-domain identity handover.
+- `apex install` — generate storefront installation snippets.
+- `apex funnels` — manage analytics funnels.
+- `apex webhooks` — manage shop webhooks.
+- `apex simulate` — simulate data-layer triggers without emitting events.
 - `apex experiments` — create, inspect, operate, and synchronize experiments.
   Use `apex experiments screenshots <id-or-slug>` to force-assign every capture, including control, to its variation server-side for deterministic screenshots; choose devices with `--devices`, filter treatments with `--variations`, and use `--json` for the signed result payload.
 - `apex push` — synchronize `.drip.config.ts` with Apex.
@@ -121,11 +151,10 @@ including every subcommand, argument, option, and alias.
 - `apex assets` — manage uploaded assets.
 - `apex landing-pages` — discover landing pages.
 - `apex brand` — manage brand context.
-- `apex sos` — run operational diagnostics.
 - `apex shops` — manage shops and active-shop context.
 - `apex skills` — inspect agent skill guidance.
-- `apex admin` — run authorized administrative operations.
 - `apex schema` — emit the machine-readable CLI schema.
+- `apex discover` — read observed tracking shapes or mine a public GTM container.
 
 ## Which local format am I in?