@wraps.dev/cli 2.30.3 → 3.1.0

package/README.md

@@ -363,22 +363,19 @@ wraps cdn init --provider vercel --region us-east-1 --domain cdn.myapp.com
 Run the Wraps control plane in your own AWS account instead of app.wraps.dev.
 Requires an enterprise license key.
 
+Deploy it with `pnpm selfhost:deploy` from a fork — see the
+[self-hosted guide](https://wraps.dev/docs/guides/self-hosted). These commands
+operate on a deployment that already exists:
+
 | Command | Description |
 |---------|-------------|
-| `wraps selfhost deploy` | Deploy an API-only control plane to your AWS account |
-| `wraps selfhost upgrade` | Rebuild and redeploy the self-hosted API |
 | `wraps selfhost status` | Show self-hosted deployment details |
 | `wraps selfhost env` | Print env vars for hosting `apps/web` against your control plane |
 | `wraps selfhost login` | Sign in to your self-hosted instance (not wraps.dev) |
 | `wraps selfhost logout` | Sign out of your self-hosted instance |
 | `wraps selfhost connect` | Connect your AWS account to your self-hosted instance |
 | `wraps selfhost update-role` | Refresh your self-hosted console role's permissions |
-| `wraps selfhost destroy` | Tear down the self-hosted control plane |
-
-`wraps selfhost deploy` gives you the API only — you host the dashboard
-yourself. For the full platform (API, dashboard, and workers) deployed via SST
-from a fork, see the [self-hosted guide](https://wraps.dev/docs/guides/self-hosted).
-The two variants cannot coexist in one AWS account.
+| `wraps selfhost logs` | Stream logs from your self-hosted API, dashboard, and workers |
 
 `selfhost connect` and `selfhost update-role` write
 `wraps-selfhost-console-access-role`, which trusts your own AWS account. Their
@@ -434,13 +431,12 @@ The CLI offers four presets that control which AWS resources are created:
 - Everything in Starter
 - EventBridge → SQS → Lambda pipeline
 - DynamoDB table with 90-day TTL
-- Tracks: SEND, DELIVERY, OPEN, CLICK, BOUNCE, COMPLAINT
+- Tracks all 10 registered SES event types: SEND, DELIVERY, OPEN, CLICK, BOUNCE, COMPLAINT, REJECT, RENDERING_FAILURE, DELIVERY_DELAY, SUBSCRIPTION
 
 ### Enterprise (~$50-100/mo)
 - Everything in Production
 - Dedicated IP address ($24.95/mo from AWS)
-- 1-year DynamoDB TTL
-- All 10 SES event types (adds REJECT, RENDERING_FAILURE, DELIVERY_DELAY, SUBSCRIPTION)
+- 1-year DynamoDB TTL (Production's is 90 days; event-type coverage is the same as Production)
 
 ### Custom
 Select individual features. Useful if you want event storage without a dedicated IP, or specific event types only.
@@ -690,8 +686,6 @@ packages/cli/
 │   │       ├── smtp-credentials.ts
 │   │       └── alerting.ts      # CloudWatch alerting
 │   ├── console/                  # Web dashboard (React)
-│   ├── lambda/                   # Lambda function source
-│   │   └── event-processor/     # SQS → DynamoDB processor
 │   ├── utils/                    # Utilities
 │   │   ├── shared/              # Shared utilities
 │   │   │   ├── aws.ts           # AWS SDK helpers
@@ -710,12 +704,17 @@ packages/cli/
 │       ├── shared.ts            # Shared types
 │       ├── email.ts             # Email-specific types
 │       └── sms.ts               # SMS-specific types
-├── lambda/                       # Lambda source (bundled to dist)
 └── dist/                         # Build output
     ├── console/                  # Built dashboard
     └── lambda/                   # Lambda source for deployment
 ```
 
+Lambda function source (`event-processor`, `sms-event-processor`, `inbound-processor`,
+`agent-enforcer`) lives in the sibling `packages/core/lambda/` package, not in this one.
+`scripts/build-lambda.ts` copies the built output into `dist/lambda/` above during
+`pnpm build`; `infrastructure/resources/lambda.ts` reads from there (or from `packages/core/lambda/`
+directly in local dev — see `getLambdaCode()`).
+
 ## AWS Permissions
 
 Wraps needs specific IAM permissions to deploy and manage infrastructure in your AWS account. Use the `wraps permissions` command to see exactly what's required.