@farthershore/cli 0.8.0 → 0.9.1

package/README.md

@@ -70,9 +70,9 @@ farthershore auth logout         # Clear stored credentials
 
 ### `farthershore init`
 
-Scaffold a starter `product.yaml` from a named plan preset. Each preset
-fills in the 5-knob spec for a common shape so first-time builders skip
-the blank-page problem.
+Scaffold a starter `product/product.config.ts` from a named plan preset. Each
+preset fills in the 5-knob spec through the Product SDK so first-time builders
+skip the blank-page problem.
 
 ```bash
 # Interactive walkthrough (TTY only) — pick a preset by number/name + path
@@ -94,12 +94,30 @@ Templates (sourced from shared-types `listPlanPresets()`):
 | `prepaid` | $50 one-time signup credit, then PAYG                        |
 | `metered` | Pure pay-as-you-go at $0.001/request                         |
 
-After `init`, edit `product.name` + `product.baseUrl`, then run
-`farthershore validate` to confirm the scaffolded YAML is acceptable.
+After `init`, edit the `fs.business(...)` product name + base URL in
+`product/product.config.ts`, split the product into any imported modules you
+want, then run `farthershore build --validate` to confirm the scaffolded
+manifest compiles.
+
+### `farthershore build`
+
+Build a product-as-code `product/product.config.ts` with the repo-local
+`./node_modules/.bin/farthershore-manifest-build` binary. The command
+emits a Manifest IR envelope to `manifest-ir.json` by default.
+
+```bash
+farthershore build
+farthershore build --entry product/product.config.ts --out manifest-ir.json
+farthershore build --format json
+
+# Optional dry-run compile against core after the local build succeeds
+farthershore build --validate weather-api --format json
+farthershore build --validate weather-api --env preview --format json
+```
 
 ### `farthershore product`
 
-Product lifecycle commands — direct API, no local `product.yaml` round-trip.
+Product lifecycle commands — direct API, no local manifest upload flow.
 
 ```bash
 farthershore product list --format json
@@ -137,16 +155,17 @@ longer carries a `billingStrategy`. Omitting both meter flags gives the
 product a `requests` meter; variable-value meters (tokens, credits, spend)
 are settled from upstream `x-fs-cost-{key}` response headers.
 
-A new product starts as a DRAFT with its portal already live in template
-mode. Going live mirrors the dashboard's "Finish setting up" checklist:
+A new product starts as a DRAFT with a generated `frontend/` project ready for
+customization. Going live mirrors the dashboard's "Finish setting up" checklist:
 
 ```bash
 farthershore product create --name llm-api --meters ai-tokens   # 1. create
+farthershore connect stripe llm-api                             # 2. connect billing
 farthershore plan create llm-api --key pro --name "Pro" \
-  --recurring-fee-cents 2900                                    # 2. how you charge
+  --recurring-fee-cents 2900                                    # 3. how you charge
 farthershore product update llm-api \
-  --base-url https://api.example.com                            # 3. endpoint
-farthershore product publish llm-api                            # 4. go live
+  --base-url https://api.example.com                            # 4. endpoint
+farthershore product publish llm-api                            # 5. go live
 ```
 
 `product publish` enforces the same gates as the dashboard: at least one
@@ -168,8 +187,8 @@ farthershore env delete weather-api preview --yes --format json
 ### `farthershore plan`
 
 Plan CRUD via the management API. The body uses the unified 5-knob
-spec (see "`product.yaml` plan shape" below) — pass cents-denominated
-flags for whichever knobs the plan flavor needs.
+shape (see "Plan knobs" below) — pass cents-denominated flags for
+whichever knobs the plan flavor needs.
 
 ```bash
 # Human-readable table (default in TTY)
@@ -240,21 +259,18 @@ farthershore token create --name "ci-bot" --scope products:update products:publi
 farthershore token revoke <tokenId> --yes --format json
 ```
 
-### `farthershore validate`
+### `farthershore build --validate <product>`
 
-Validate the managed repo (`product.yaml`, `brand.yaml`, `docs/`,
-`skills/`, `.github/workflows/`) through the same backend checks the
-Farther Shore GitHub bot runs.
+`build --validate` runs a local manifest compile + server-side validation
+pass after `product/product.config.ts` is built. This is the replacement for the
+deleted `validate`/`apply` proposal flow.
 
 ```bash
-farthershore validate
-farthershore validate --format json
+farthershore build --validate weather-api --format json
+farthershore build --validate weather-api --env preview --format json
 ```
 
-Emits GitHub Actions-formatted annotations when run under `CI` /
-`GITHUB_ACTIONS`.
-
-#### `product.yaml` plan shape
+#### Plan knobs
 
 Every plan is a configuration of 5 orthogonal knobs (shared-types
 v0.53.0). Older shapes with `pricing.{model, monthlyPriceCents}` and
@@ -382,7 +398,7 @@ plans:
         refill_cents: 5000
 ```
 
-The validator surfaces:
+Validation surfaces:
 
 - **error** — invalid `kind` is rewritten to `Unknown grant kind. Valid kinds: …`
 - **warning** — `grants[]` declares `recurring`/`one_time` _and_ the matching legacy knob is also non-zero (legacy is silently ignored)
@@ -392,7 +408,7 @@ The validator surfaces:
 #### Deprecation window (Phase 3b)
 
 The product top-level `lifecycle.breaking_changes` block declares the
-breaking-change governance policy enforced on `apply`:
+breaking-change governance policy validated during `build --validate`:
 
 ```yaml
 lifecycle:
@@ -403,52 +419,16 @@ lifecycle:
 
 When the policy is set:
 
-- `farthershore validate` emits an informational warning so the builder
+- `build --validate` emits an informational warning so the builder
   sees the active policy locally.
-- `farthershore apply` (which compares the proposed spec against the
-  accepted spec) emits a `route_removed` change for every route
-  dropped from `features.<x>.routes[]` and warns that the server-side
-  `breaking-change-safety-check` cron will gate the publish via
+- It emits a `route_removed` change for every route dropped from
+  `features.<x>.routes[]` and warns when the server-side
+  `breaking-change-safety-check` cron will gate publish via
   `ConsumerActivity` lookup. When `require_successor_route` is true,
-  the apply path additionally surfaces a successor-required warning.
+  it also adds a successor-required warning.
 
 The CLI never blocks on the window itself — the per-consumer lookup
 lives server-side (Phase 1c `ConsumerActivity` table + Phase 3b cron).
-The CLI's job is to surface the policy and the route delta locally so
-the builder knows what the gate will see.
-
-### `farthershore apply [product]`
-
-Publish the shared server draft as one product release. Core accepts the
-release only after schema validation, transition-safety validation, and
-a compiler dry-run all pass.
-
-```bash
-# Publish the current shared draft
-farthershore apply
-
-# Or pass the product slug/UUID explicitly
-farthershore apply weather-api
-
-# Validate and compile without publishing
-farthershore apply --dry-run --format json
-farthershore apply --env preview --dry-run --format json
-
-# Submit a local product.yaml as a one-off proposal
-farthershore apply --to product.yaml --dry-run --format json
-farthershore apply --to product.yaml --format json
-
-# Also stage that file as the shared draft before publishing
-farthershore apply --to product.yaml --save-draft --format json
-
-# Pin compilation to a specific branch
-farthershore apply weather-api --branch feature/billing-change --dry-run --format json
-```
-
-JSON output is stable: `{ ok, success, errors, warnings, lifecyclePlan,
-nextActions, ... }`. `lifecyclePlan` is always present (or `null` on
-first deploys / older core builds) and surfaces ADR-0010 per-domain
-subscriber-migration actions.
 
 ## Agent workflow
 
@@ -466,27 +446,23 @@ farthershore plan create weather-api --key free --name "Free" --free --format js
 farthershore plan create weather-api \
   --key pro --name "Pro" --recurring-fee-cents 2900 --format json
 
-farthershore apply weather-api --dry-run --format json
-farthershore apply weather-api --format json
+farthershore build --validate weather-api --format json
 farthershore product show weather-api --format json
 ```
 
-For a YAML-driven flow, edit `product.yaml` in the managed repo, then:
+For product updates, edit `product/product.config.ts` or any modules it imports
+and validate with:
 
 ```bash
-farthershore validate --format json
-farthershore apply --to product.yaml --dry-run --format json
-farthershore apply --to product.yaml --format json
+farthershore build --validate weather-api --format json
 ```
 
 ## MCP server
 
-The MCP server (`farthershore-mcp`) exposes two tools:
+The MCP server (`farthershore-mcp`) exposes one tool:
 
-- `farthershore_draft_validate` — run server-side validation on the shared
-  draft.
-- `farthershore_apply` — apply the draft, optionally with a `product.yaml`
-  proposal via `toFile`. Defaults to `dryRun: true`.
+- `farthershore_status` — return product list context and selected product
+  metadata.
 
 Both accept optional `product` and `env` fields and return JSON.
 
@@ -512,5 +488,5 @@ for CI scripts.
 The CLI is non-interactive whenever a token is available via the
 `--token` flag or `FARTHERSHORE_TOKEN` env var — `auth login` only
 prompts when stdin is a TTY and no token argument was passed, so it's
-safe to script. `validate` and `apply` emit GitHub Actions-formatted
-annotations when run under `CI` / `GITHUB_ACTIONS`.
+safe to script. `farthershore build --validate` is CI-safe and can be
+run under `CI` / `GITHUB_ACTIONS` for automation.