[thedogwiththedataonit]

Update 2026-10-25: restacked on #53 (CLI main 9250732). Conflicts: vendored spec + generated types (re-vendored), RELEASING.md (main's contact-import SDK minimum kept beside the app email SDK gate), generated docs. The vendored spec is the brew-v2 #2169 @ 6f8ef50544 DX delta on main's spec (brew-v2 87ac2c6242), structurally merged (no conflicts; one enum union). Checks against a local SDK build of typescript-sdk#64 merged with SDK main: tsc, lint, test 962, generated types fresh, docs:commands:check, generate:skills:check, build, bin smoke, signal smoke ✓. CI typecheck/parity stay red until SDK 13.6.0 is on npm (gate in RELEASING.md).

Renumbered 10-25: main published 0.18.0 (--lang/--clear-lang, contact imports, SDK ^13.3.0), and SDK main published 13.1.0, 13.2.0 and 13.3.0 without the DX features (13.4.0 is reserved for its pending email lang release). So this chain moves up one: #54 0.19.0, #55 0.20.0, #61 0.21.0, #63 0.22.0, and the DX SDK releases are send-by-key 13.5.0, adapters/appEmails 13.6.0 (SDK_RANGE ^13.6.0, so installs can no longer resolve to the published 13.3.0), integrations.connect 13.7.0. This PR is 0.19.0; older numbers below are pre-rebase.

Spec sync 2026-10-21: restacked on CLI main 2ce7d42. The vendored spec is now brew-v2 #2169 @ 6f8ef50544 whole (main 2db5428b09 plus every DX route; spec source: brew-v2 #2169 @ 6f8ef50544), replacing the per-PR deltas; the hosted auth hook connection routes sit in the parity pending list until #63. Adapted: kit hints per refusal (APP_EMAIL_DOMAIN_PURPOSE_MISMATCH → transactional --domain or none, APP_EMAIL_TRIGGER_IN_USE → unpublish details.automationIds, APP_EMAIL_EDITED_IN_BREW → --overwrite), upsert renders DRAFT_SAVED_NOT_LIVE as "the published version keeps sending", --domain help names the purpose refusal; MSW tests for those plus DKIM_SELECTOR_IN_USE + suggestedNames on domains add. RELEASING: brew-v2 #2169 deployed. Checks: tsc, lint, test 931, generated types fresh, docs/skills freshness, build, signal smoke ✓.

Renumbered 10-21: main published 0.17.0 (canvas commands, SDK ^13.0.0), so this chain moved up one: #54 0.18.0, #55 0.19.0, #61 0.20.0, #63 0.21.0. This PR is 0.18.0; older numbers below are pre-rebase.

Stacked on #53 (→ #44 → main). CLI 0.17.0 (C2 of the DX push): send by key, app emails, trigger keys. This release also carries #44 and #53.

Depends on unpublished work. send, app-emails and the types registry call brew.send / brew.appEmails, which no published SDK has (npm 12.2.0 / 12.3.0 are other features). package.json and bun.lock stay on main's SDK git pin on purpose (never a hand-written lockfile entry), so once this targets main, CI typecheck and parity fail on these commands until the SDK release exists. RELEASING.md now has an app email SDK gate with the steps. Local checks run against the typescript-sdk#64 worktree build (SDK main + #55 + #64), linked into node_modules; nothing committed.

Publish order (nothing here is published, merged or tagged)

1. brew-v2: #2169 (the whole DX stack collapsed into one PR: browser sign-in, trigger keys, fire by key, team sandbox, app emails, import modes, hosted auth hooks) merged and deployed.
2. typescript-sdk: init + the brew.new / create-brew launchers (C4, 0.20.0) #55 (send, fireByKey) and Release CLI 0.17.0 with registry SDK 13 #64 (appEmails, adapter subpaths) rebased onto SDK main (which already has the canvas revocation fix this CLI's main needs) and published. Numbers are final: init + the brew.new / create-brew launchers (C4, 0.20.0) #55 ships as 13.1.0 and Release CLI 0.17.0 with registry SDK 13 #64 as 13.2.0, after the canvas fix's 13.0.0; this CLI takes ^13.2.0. Both SDK PRs are behind SDK main (init + the brew.new / create-brew launchers (C4, 0.20.0) #55 conflicts).
3. This chain: bun add @brew.new/sdk@^<that version> (regenerates bun.lock from the registry, replacing main's git pin), re-vendor openapi/public-api-v1.yaml from brew-v2 main (once #2169 merges), frozen install + full checks, then CLI 0.17.0 → 0.18.0 → 0.19.0.
4. Launchers: reserve brew.new and create-brew on npm (both still 404) for the token's account; until then the release step warns and skips them.

What

• send <key> → brew.send (POST /v1/automations/triggers/by-key/{triggerKey}/fire). --to sets payload.email (wins over --data), --data <json|->, --idempotency-key (route is fail_closed). Destructive (exit 4 without --yes). automations.triggers.fireByKey → SDK_SKIP_LIST (alias of send).
• app-emails list | get <key> | upsert <key> | kit bind GET /v1/app-emails, GET|PUT /v1/app-emails/{triggerKey}, POST /v1/app-emails/kit. upsert (starter or --source-file with --format html/mjml/jsx, --overwrite, --no-publish) and kit (--sets, --stack, --keys, --domain, --overwrite, --idempotency-key) are destructive because they publish; kit exits 1 when a key failed. Both need the automations and emails scopes (stated in help, README and the skill).
• --key on automations triggers create|update; KEY column in triggers list.
• types appends the BrewTriggerKeyRegistry augmentation for keyed triggers on top of main's contract-artifact types (brew-cli#58); a key-less workspace gets the same bytes as --no-registry. listAllTriggers, fetchContractArtifacts and buildContractsFile are exported for init.
• Vendored spec = brew-v2 claude/app-emails-setup 84cea75be5 exactly (CLI main's spec is brew-v2 main 8c7020e535 byte for byte; #2066 sits on #2013 e499465757, #2017 54a862fee0 and #2059 4792d4a323), so it carries secret on custom payloadSchema fields. Generated types regenerated.
• 10-16 sync: SDK gate text and 0.17.0 changelog name 13.1.0/13.2.0; app-emails upsert passes --input fields (incl. secret: true) through, pinned by a test and an example; a test pins send's not-started line naming DOMAIN_REQUIRED, which SDK 13.2.0 types (its spec now includes #2059).
• Version 0.17.0; CHANGELOG ## 0.17.0 (with the Project foundations + mcp install (C1) #44/Login through the browser (session flow) (C3) #53 notes and main's canvas note), README, skill, command docs.

Review round 2026-10-16

• Rebased onto the new Login through the browser (session flow) (C3) #53 (main 0.16.0). Conflicts: the vendored spec (re-vendored as above), types.ts (registry rebuilt on main's contract artifacts), package.json (main's SDK pin kept), src/lib/long-running.ts (the app-email deadlines use main's sdk.* namespace), generated docs.
• Fixes: upsert --input - always confirms (stdin could set overwrite); kit rejects an empty --keys/--sets (was "whole kit") and --keys with --sets/--stack, and its summary reads inline --input; the trigger key grammar, --format, --sets, --stack and kit keys are checked locally (exit 2, not 1), with a test pinning them to the vendored spec.

Checks (scratch SDK = SDK main + #64)

tsc ✓ · lint ✓ · test 59 files / 824 tests ✓ (parity-sdk + parity-spec green) · generated types fresh ✓ · docs:commands:check ✓ · generate:skills:check ✓. CI runs only on PRs into main.

Live validation owed (after deploy + publish)

send to an org member in sandbox and to a non-member (DOMAIN_REQUIRED), app-emails kit --stack better-auth, upsert re-run and 409 APP_EMAIL_EDITED_IN_BREW, types on a brand with kit keys.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

Confidence Score: 4/5

Do not merge yet: mixed kit selections can still publish different emails than the flags request.

Findings

1.  Selection flags get ignored ▶
2.  Recovery hides the needed IDs ▶
3.  Two flags consume stdin ▶
4.  Recovery repeats failed results ▶
5.  Setup code is hidden ▶
6.  Type checks lack compile coverage ▶

Fix with agent prompt

### Issue 1
src/commands/app-emails/kit.ts:94-100
With `app-emails kit --sets lifecycle --input '{"keys":["auth.otp"]}' --yes`, the conflict check sees only the flags and passes. `mergeInput` keeps `keys`, which takes precedence over `sets`, so the command publishes `auth.otp` instead of the lifecycle emails requested by the flag.

Check for conflicting selections after merging `--input`, before calling the SDK.

### Issue 2
src/commands/app-emails/kit.ts:194
The `APP_EMAIL_TRIGGER_IN_USE` hint tells terminal users to unpublish `error.details.automationIds`, but the output never prints those IDs. `renderKit` shows only the error code, so users cannot tell which automations to unpublish.

Print the affected IDs, or give an explicit `--json` command that retrieves them.

### Issue 3
src/commands/app-emails/upsert.ts:114-116
`upsert` accepts `--input -` and `--source-file -` together, then reads stdin twice. The first read consumes the stream; the second cannot read a separate email source and may send empty content or fail with an unrelated error. Reject this combination before reading either input.

### Issue 4
src/commands/app-emails/kit.ts:undefined-135
After a partial kit failure, this message says to rerun with the same flags. If the user supplied `--idempotency-key`, that repeats the same key and body, which returns the original failed result for 24 hours rather than retrying the failed emails.

For a completed response with failed entries, tell users to omit or replace that key. Keep same-key retries for requests whose outcome is still unknown.

### Issue 5
src/commands/app-emails/kit.ts:155-156
The human kit output prints each snippet’s title and file name but drops `snippet.code`. A terminal user setting up Better Auth sees where code belongs but not the callbacks needed to send the emails. Print the code, or give an explicit `--json` command for retrieving it.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

### Issue 6
tests/commands/types.test.ts:605-616
The new registry test only checks generated text. It would still pass if the declarations stopped connecting to `brew.send` and no longer rejected unknown keys or wrong payloads. Add a compile test against the SDK with one valid call and expected errors for an unknown key and an invalid payload, so the advertised type checks remain covered after SDK updates.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Adds sending by trigger key, app-email setup commands, trigger key flags, and the generated SDK key registry.

• Developers can send an email by its trigger key.
• Developers can set up and check app emails by key.
• Trigger keys now connect automation setup to typed send payloads.

_{Reviews (9) · Last reviewed commit: "chore(release): 0.19.0 after main's publ..." · Reviewed by Greptile}

[greptile-apps]

Two flags consume stdin

upsert accepts --input - and --source-file - together, then reads stdin twice. The first read consumes the stream; the second cannot read a separate email source and may send empty content or fail with an unrelated error. Reject this combination before reading either input.

Knowledge Base Used: CLI input, output, and error behavior

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/commands/app-emails/upsert.ts
Line: 97-99

Comment:
**Two flags consume stdin**

`upsert` accepts `--input -` and `--source-file -` together, then reads stdin twice. The first read consumes the stream; the second cannot read a separate email source and may send empty content or fail with an unrelated error. Reject this combination before reading either input.

**Knowledge Base Used:** [CLI input, output, and error behavior](https://app.greptile.com/brew-new/-/custom-context/knowledge-base/getbrew/brew-cli/-/docs/cli-input-output-and-errors.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Recovery repeats failed results

After a partial kit failure, this message says to rerun with the same flags. If the user supplied --idempotency-key, that repeats the same key and body, which returns the original failed result for 24 hours rather than retrying the failed emails.

For a completed response with failed entries, tell users to omit or replace that key. Keep same-key retries for requests whose outcome is still unknown.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/commands/app-emails/kit.ts
Line: 135

Comment:
**Recovery repeats failed results**

After a partial kit failure, this message says to rerun with the same flags. If the user supplied `--idempotency-key`, that repeats the same key and body, which returns the original failed result for 24 hours rather than retrying the failed emails.

For a completed response with failed entries, tell users to omit or replace that key. Keep same-key retries for requests whose outcome is still unknown.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Setup code is hidden

The human kit output prints each snippet’s title and file name but drops snippet.code. A terminal user setting up Better Auth sees where code belongs but not the callbacks needed to send the emails. Print the code, or give an explicit --json command for retrieving it.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/commands/app-emails/kit.ts
Line: 129-130

Comment:
**Setup code is hidden**

The human kit output prints each snippet’s title and file name but drops `snippet.code`. A terminal user setting up Better Auth sees where code belongs but not the callbacks needed to send the emails. Print the code, or give an explicit `--json` command for retrieving it.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Type checks lack compile coverage

The new registry test only checks generated text. It would still pass if the declarations stopped connecting to brew.send and no longer rejected unknown keys or wrong payloads. Add a compile test against the SDK with one valid call and expected errors for an unknown key and an invalid payload, so the advertised type checks remain covered after SDK updates.

Prompt To Fix With AI

This is a comment left during a code review.
Path: tests/commands/types.test.ts
Line: 432-443

Comment:
**Type checks lack compile coverage**

The new registry test only checks generated text. It would still pass if the declarations stopped connecting to `brew.send` and no longer rejected unknown keys or wrong payloads. Add a compile test against the SDK with one valid call and expected errors for an unknown key and an invalid payload, so the advertised type checks remain covered after SDK updates.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Selection flags get ignored

With app-emails kit --sets lifecycle --input '{"keys":["auth.otp"]}' --yes, the conflict check sees only the flags and passes. mergeInput keeps keys, which takes precedence over sets, so the command publishes auth.otp instead of the lifecycle emails requested by the flag.

Check for conflicting selections after merging --input, before calling the SDK.

Knowledge Base Used: CLI input, output, and error behavior

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/commands/app-emails/kit.ts
Line: 94-100

Comment:
**Selection flags get ignored**

With `app-emails kit --sets lifecycle --input '{"keys":["auth.otp"]}' --yes`, the conflict check sees only the flags and passes. `mergeInput` keeps `keys`, which takes precedence over `sets`, so the command publishes `auth.otp` instead of the lifecycle emails requested by the flag.

Check for conflicting selections after merging `--input`, before calling the SDK.

**Knowledge Base Used:** [CLI input, output, and error behavior](https://app.greptile.com/brew-new/-/custom-context/knowledge-base/getbrew/brew-cli/-/docs/cli-input-output-and-errors.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Recovery hides the needed IDs

The APP_EMAIL_TRIGGER_IN_USE hint tells terminal users to unpublish error.details.automationIds, but the output never prints those IDs. renderKit shows only the error code, so users cannot tell which automations to unpublish.

Print the affected IDs, or give an explicit --json command that retrieves them.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/commands/app-emails/kit.ts
Line: 194

Comment:
**Recovery hides the needed IDs**

The `APP_EMAIL_TRIGGER_IN_USE` hint tells terminal users to unpublish `error.details.automationIds`, but the output never prints those IDs. `renderKit` shows only the error code, so users cannot tell which automations to unpublish.

Print the affected IDs, or give an explicit `--json` command that retrieves them.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.