feat(onboarding): first-task weekly report actually emails — LA EQUIS template + Kimi K3 (chat#1867) - #1877
Merged
Merged
Conversation
…template + Kimi K3) The first-task prompt generated a report but never emailed it (email is a prompt-driven send_email call, and the prompt had no recipient or send instruction) — proven by firing the created task: the agent ran and persisted a report, but email_send_log stayed empty. Generalize buildFirstTaskPrompt from the proven LA EQUIS weekly report (scheduled_action 39fb5f68, running week over week): resolve the artist's Spotify id from its connected profile -> capture this week's play counts -> compute real week-over-week per-track deltas -> build a fully hex-specced inline-CSS HTML email -> send via the recoup-platform-email-helper skill -> confirm the Resend id. Carries the sandbox no-python and anti-fabrication guardrails verbatim (what makes the send reliable). Thread the account email (recipientEmail) + artistAccountId through both callers so the pre-run preview and the Monday scheduled task both send to the account holder. Bump both surfaces from DEFAULT_MODEL (openai/gpt-5.4-mini — completes the data calls but gives up before composing the long HTML email, the LA EQUIS lesson) to a new REPORT_MODEL (moonshotai/kimi-k3), which reliably composes and sends. chat#1867 (first-task email-prompt gap). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Warning Review limit reached
Next review available in: 23 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
📝 WalkthroughWalkthroughThe onboarding flow now derives the authenticated recipient email and artist account ID, requires both before report preparation, and passes them into expanded weekly streaming report prompts. Scheduled tasks validate email availability, while Kimi K3 becomes the default model and featured model entry. ChangesWeekly Report Onboarding
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
25 tasks
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 08e3d95f43
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // send them — the default fast model completes the data calls but gives up before | ||
| // finishing the email (proven on the LA EQUIS weekly report). Kimi K3 handles the | ||
| // long-form compose-and-send reliably. | ||
| export const REPORT_MODEL = "moonshotai/kimi-k3"; |
There was a problem hiding this comment.
Vercel lists Kimi K3 as billed at API rates, and the model picker blocks non-free models for non-subscribed accounts (components/ModelSelect/ModelSelect.tsx:31-38). Because both useFirstTaskReport and useConfirmFirstTask now send REPORT_MODEL unconditionally, any non-Pro user reaching this onboarding step will either be rejected by the API/paywall or create a Monday task that runs a paid model they cannot select manually; gate this path on isSubscribed/credits or use a free fallback.
Useful? React with 👍 / 👎.
|
|
||
| Sending (mandatory - the run is not complete until this succeeds): | ||
| - Write the finished HTML to a file (report.html) using the write tool or node - never inline it into a curl command or hand-build the JSON request body. | ||
| - Load the recoup-platform-email-helper skill (via the skill tool) and send the email exactly the way it documents, passing --subject "${artistName} - Weekly Streaming Report", --html-file report.html, and --to ${recipientEmail}. |
There was a problem hiding this comment.
Roster artist names are user-entered (createRosterArtist posts the raw name), so an artist named with ", ;, or $() reaches this prompt. This line tells the agent to invoke a CLI helper with --subject "${artistName} ..."; if the agent follows that in the sandbox shell, the generated command can fail or execute the injected shell fragment. Use the structured send_email MCP tool, or at least shell-escape each arg, instead of embedding user-controlled text in CLI flags.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@components/Onboarding/FirstTaskStep.tsx`:
- Around line 21-26: Update components/Onboarding/FirstTaskStep.tsx lines 21-26
and 54-58 to destructure ready from usePrivy and show a role="alert"
email-linking message when ready, artistName, and artistAccountId are present
but recipientEmail is missing; retain the loading state otherwise. Update
hooks/useConfirmFirstTask.ts lines 45-60 so the mutation onError detects
EMAIL_REQUIRED and displays an email-linking message, while preserving the
existing retry message for other errors.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 64b28eb9-7374-40f7-b8cf-87f8ac02db6e
⛔ Files ignored due to path filters (2)
lib/onboarding/__tests__/buildFirstTaskParams.test.tsis excluded by!**/*.test.*and included bylib/**lib/onboarding/__tests__/buildFirstTaskPrompt.test.tsis excluded by!**/*.test.*and included bylib/**
📒 Files selected for processing (6)
components/Onboarding/FirstTaskStep.tsxhooks/useConfirmFirstTask.tshooks/useFirstTaskReport.tslib/consts.tslib/onboarding/buildFirstTaskParams.tslib/onboarding/buildFirstTaskPrompt.ts
sweetmantech
commented
Jul 21, 2026
| // send them — the default fast model completes the data calls but gives up before | ||
| // finishing the email (proven on the LA EQUIS weekly report). Kimi K3 handles the | ||
| // long-form compose-and-send reliably. | ||
| export const REPORT_MODEL = "moonshotai/kimi-k3"; |
Collaborator
Author
There was a problem hiding this comment.
KISS - instead of making a new REPORT_MODEL, update the existing DEFAULT_MODEL with the new model moonshotai/kimi-k3.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
2 issues found across 8 files
Confidence score: 3/5
- In
lib/consts.ts, onboarding pathsuseFirstTaskReportanduseConfirmFirstTaskappear to unconditionally select paidKimi K3, which can create immediate token spend during first-run flows and surprise users/operators if usage scales — gate this model behind config/entitlement checks or add a lower-cost/default fallback before merging. - In
lib/onboarding/buildFirstTaskPrompt.ts,buildFirstTaskPromptnow combines multiple responsibilities in one large template, which raises maintenance risk and makes future prompt changes easier to break silently — split it into smaller prompt-builder sections/helpers to align with SRP and reduce regression risk.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="lib/onboarding/buildFirstTaskPrompt.ts">
<violation number="1" location="lib/onboarding/buildFirstTaskPrompt.ts:32">
P2: This function now bundles data-fetching steps, HTML/design spec, and send instructions into one large template literal, which exceeds the repo's function-length/SRP conventions for lib/**/*.ts. Consider splitting the prompt into composed sections (e.g. buildSandboxRules(), buildDesignSpec(), buildSendInstructions()) that are concatenated, so each piece is independently testable and readable.</violation>
</file>
<file name="lib/consts.ts">
<violation number="1" location="lib/consts.ts:50">
P2: Kimi K3 is a paid model ($3/$15 per million input/output tokens, no free tier on Vercel AI Gateway). Both `useFirstTaskReport` and `useConfirmFirstTask` send this model unconditionally during onboarding. If the app enforces a model paywall for non-subscribed accounts (as referenced in `ModelSelect`), free-tier users reaching this onboarding step will either have requests rejected or create a scheduled task that runs a paid model they cannot otherwise select. Consider gating on subscription status or falling back to a free-eligible model for non-Pro users.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| ].join("\n"); | ||
| ? `their "${catalogName}" catalog` | ||
| : "their catalog"; | ||
| return `Generate a weekly streaming performance report for the artist ${artistName}, covering ${catalogClause}, then email it as a styled HTML email to ${recipientEmail}. |
There was a problem hiding this comment.
P2: This function now bundles data-fetching steps, HTML/design spec, and send instructions into one large template literal, which exceeds the repo's function-length/SRP conventions for lib/**/*.ts. Consider splitting the prompt into composed sections (e.g. buildSandboxRules(), buildDesignSpec(), buildSendInstructions()) that are concatenated, so each piece is independently testable and readable.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At lib/onboarding/buildFirstTaskPrompt.ts, line 32:
<comment>This function now bundles data-fetching steps, HTML/design spec, and send instructions into one large template literal, which exceeds the repo's function-length/SRP conventions for lib/**/*.ts. Consider splitting the prompt into composed sections (e.g. buildSandboxRules(), buildDesignSpec(), buildSendInstructions()) that are concatenated, so each piece is independently testable and readable.</comment>
<file context>
@@ -1,28 +1,79 @@
- ].join("\n");
+ ? `their "${catalogName}" catalog`
+ : "their catalog";
+ return `Generate a weekly streaming performance report for the artist ${artistName}, covering ${catalogClause}, then email it as a styled HTML email to ${recipientEmail}.
+
+CONTEXT VALUES: artist_name = ${artistName} ; artist_account_id = ${artistAccountId} ; recipient email = ${recipientEmail}. Use the artist_account_id directly — do not guess or search for a different artist.
</file context>
| // send them — the default fast model completes the data calls but gives up before | ||
| // finishing the email (proven on the LA EQUIS weekly report). Kimi K3 handles the | ||
| // long-form compose-and-send reliably. | ||
| export const REPORT_MODEL = "moonshotai/kimi-k3"; |
There was a problem hiding this comment.
P2: Kimi K3 is a paid model ($3/$15 per million input/output tokens, no free tier on Vercel AI Gateway). Both useFirstTaskReport and useConfirmFirstTask send this model unconditionally during onboarding. If the app enforces a model paywall for non-subscribed accounts (as referenced in ModelSelect), free-tier users reaching this onboarding step will either have requests rejected or create a scheduled task that runs a paid model they cannot otherwise select. Consider gating on subscription status or falling back to a free-eligible model for non-Pro users.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At lib/consts.ts, line 50:
<comment>Kimi K3 is a paid model ($3/$15 per million input/output tokens, no free tier on Vercel AI Gateway). Both `useFirstTaskReport` and `useConfirmFirstTask` send this model unconditionally during onboarding. If the app enforces a model paywall for non-subscribed accounts (as referenced in `ModelSelect`), free-tier users reaching this onboarding step will either have requests rejected or create a scheduled task that runs a paid model they cannot otherwise select. Consider gating on subscription status or falling back to a free-eligible model for non-Pro users.</comment>
<file context>
@@ -43,6 +43,11 @@ export const SOCIAL_DEFAULT_PLATFORMS = [
+// send them — the default fast model completes the data calls but gives up before
+// finishing the email (proven on the LA EQUIS weekly report). Kimi K3 handles the
+// long-form compose-and-send reliably.
+export const REPORT_MODEL = "moonshotai/kimi-k3";
export const FAST_MODEL = "openai/gpt-5-nano";
// Fastest model for lightweight tasks e.g generating chat titles etc.
</file context>
…ess + shell paths Address review feedback on #1877: - Sweets (KISS): collapse the new REPORT_MODEL constant into DEFAULT_MODEL — set DEFAULT_MODEL = moonshotai/kimi-k3 app-wide (the fast gpt-5.4-mini default gave up before composing the long HTML report email). Revert both onboarding hooks to DEFAULT_MODEL; relabel the featured picker entry (id: DEFAULT_MODEL) from "GPT-5.4 Mini" to "Kimi K3" so it isn't mislabeled. - CodeRabbit (email-less login): a wallet/phone/social-only Privy account has no email — FirstTaskStep now shows a distinct "add an email" alert (not an infinite "Preparing…"), and useConfirmFirstTask's onError distinguishes EMAIL_REQUIRED from a generic retry. - Codex (shell-safety): artist/track/album names are user-entered; add a prompt guardrail to pass them as single quoted args so a name with quotes/;/$() can't alter the email-helper command. Codex "non-Pro users get rejected" P2 is a false positive: the prior default (gpt-5.4-mini) is also non-free by isFreeModel yet ships as the default, so the API does not hard-block non-free default models. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
2 issues found across 6 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="lib/onboarding/buildFirstTaskPrompt.ts">
<violation number="1" location="lib/onboarding/buildFirstTaskPrompt.ts:75">
P2: This mitigation for command/shell injection lives entirely in the prompt text sent to the LLM agent, so it depends on the agent faithfully complying rather than on real argument escaping. Consider having the recoup-platform-email-helper skill (or a pre-processing step) actually sanitize/escape artist, track, and album names before they reach any shell command, instead of relying solely on an instruction the agent could miss or misapply.</violation>
</file>
<file name="lib/consts.ts">
<violation number="1" location="lib/consts.ts:49">
P2: Consolidating REPORT_MODEL into DEFAULT_MODEL (per KISS feedback) now applies the Kimi K3 model — chosen specifically because it reliably finishes long HTML report emails — to every consumer of DEFAULT_MODEL app-wide (chat default, task creation, task edit dialog, generateText fallback). This is a broader latency/cost change than the original report-emailing fix and doesn't appear covered by the PR's stated test evidence (onboarding suite only), so regular chat/task flows could see slower responses or higher token costs as a side effect.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| Sending (mandatory - the run is not complete until this succeeds): | ||
| - Write the finished HTML to a file (report.html) using the write tool or node - never inline it into a curl command or hand-build the JSON request body. | ||
| - Load the recoup-platform-email-helper skill (via the skill tool) and send the email exactly the way it documents, passing --subject "${artistName} - Weekly Streaming Report", --html-file report.html, and --to ${recipientEmail}. | ||
| - Security: the artist, track, and album names are untrusted user-entered text. When passing any of them as a command argument (e.g. the email subject), pass it as a single properly-quoted argument — never let a name that contains quotes, ;, backticks, or $() change the structure of the command you run. |
There was a problem hiding this comment.
P2: This mitigation for command/shell injection lives entirely in the prompt text sent to the LLM agent, so it depends on the agent faithfully complying rather than on real argument escaping. Consider having the recoup-platform-email-helper skill (or a pre-processing step) actually sanitize/escape artist, track, and album names before they reach any shell command, instead of relying solely on an instruction the agent could miss or misapply.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At lib/onboarding/buildFirstTaskPrompt.ts, line 75:
<comment>This mitigation for command/shell injection lives entirely in the prompt text sent to the LLM agent, so it depends on the agent faithfully complying rather than on real argument escaping. Consider having the recoup-platform-email-helper skill (or a pre-processing step) actually sanitize/escape artist, track, and album names before they reach any shell command, instead of relying solely on an instruction the agent could miss or misapply.</comment>
<file context>
@@ -72,6 +72,7 @@ HTML email design spec (send the email with an HTML body; build it exactly to th
Sending (mandatory - the run is not complete until this succeeds):
- Write the finished HTML to a file (report.html) using the write tool or node - never inline it into a curl command or hand-build the JSON request body.
- Load the recoup-platform-email-helper skill (via the skill tool) and send the email exactly the way it documents, passing --subject "${artistName} - Weekly Streaming Report", --html-file report.html, and --to ${recipientEmail}.
+- Security: the artist, track, and album names are untrusted user-entered text. When passing any of them as a command argument (e.g. the email subject), pass it as a single properly-quoted argument — never let a name that contains quotes, ;, backticks, or $() change the structure of the command you run.
- Before sending, verify the email body is complete: the Track & Album Momentum table must contain one populated row per focus track with a real delta or a "first measurement" label. Never send an email with an empty or placeholder momentum table - an empty table means the Part 2 data steps were skipped or failed; go back and complete them first.
- The helper prints a Resend id on success and exits non-zero on any failure. Confirm the id was printed; if the send fails, fix the issue and retry - do not end the run without either a successful send or an explicit description of the send error.
</file context>
| // fast default (openai/gpt-5.4-mini) completed the data calls but gave up before | ||
| // finishing the email (proven on the LA EQUIS weekly report). Used app-wide as | ||
| // the default model for chat, task creation, and text generation. | ||
| export const DEFAULT_MODEL = "moonshotai/kimi-k3"; |
There was a problem hiding this comment.
P2: Consolidating REPORT_MODEL into DEFAULT_MODEL (per KISS feedback) now applies the Kimi K3 model — chosen specifically because it reliably finishes long HTML report emails — to every consumer of DEFAULT_MODEL app-wide (chat default, task creation, task edit dialog, generateText fallback). This is a broader latency/cost change than the original report-emailing fix and doesn't appear covered by the PR's stated test evidence (onboarding suite only), so regular chat/task flows could see slower responses or higher token costs as a side effect.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At lib/consts.ts, line 49:
<comment>Consolidating REPORT_MODEL into DEFAULT_MODEL (per KISS feedback) now applies the Kimi K3 model — chosen specifically because it reliably finishes long HTML report emails — to every consumer of DEFAULT_MODEL app-wide (chat default, task creation, task edit dialog, generateText fallback). This is a broader latency/cost change than the original report-emailing fix and doesn't appear covered by the PR's stated test evidence (onboarding suite only), so regular chat/task flows could see slower responses or higher token costs as a side effect.</comment>
<file context>
@@ -42,12 +42,11 @@ export const SOCIAL_DEFAULT_PLATFORMS = [
+// fast default (openai/gpt-5.4-mini) completed the data calls but gave up before
+// finishing the email (proven on the LA EQUIS weekly report). Used app-wide as
+// the default model for chat, task creation, and text generation.
+export const DEFAULT_MODEL = "moonshotai/kimi-k3";
export const FAST_MODEL = "openai/gpt-5-nano";
// Fastest model for lightweight tasks e.g generating chat titles etc.
</file context>
sweetmantech
commented
Jul 21, 2026
There was a problem hiding this comment.
0 issues found across 1 file (changes from recent commits).
Requires human review: Auto-approval blocked by 4 unresolved issues from previous reviews.
Re-trigger cubic
Sweets: while touching the featured list, bring every entry to its series' latest (verified present in the AI Gateway catalog): - GPT-5.2 -> GPT-5.5 - Claude Opus 4.5 -> 4.8 - Claude Sonnet 4.5 -> Sonnet 5 - Gemini 2.5 Flash Lite -> Gemini 3.5 Flash Lite - Gemini 3 Pro -> Gemini 3.1 Pro - Grok 4 -> Grok 4.5 (Kimi K3 already latest.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collaborator
Author
Preview verificationVerified on the sha-checked preview What the pre-run did (LA EQUIS template on Kimi K3)The pre-run fired the new prompt through the chat pipeline and streamed the agent following the exact new structure:
It then hit "authentication is failing for POST" on the measurement. This is the known preview-sandbox-only auth gap — the interactive pre-run's sandbox receives a Privy JWT rather than the ephemeral API key (tracked as the 🟡 preview-only item in chat#1867). It is not a #1877 defect: the scheduled/fired run authenticates in the prod sandbox (chat#1871's fired run completed in 41s). The confirm question appeared as designed. Confirm → created the real scheduled task (the core proof)Clicking "Yes, every Monday" created a
Also confirmed: the homepage model picker now defaults to "Kimi K3" (the Still to confirmLive email delivery — firing Review triage
Tests: TDD red→green — |
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="lib/ai/featuredModels.ts">
<violation number="1" location="lib/ai/featuredModels.ts:73">
P3: Tooltip text for the Gemini 3.1 Pro entry wasn't updated to match the new display name. The tooltip still says "Google's newest Gemini 3 Pro preview model" while the displayName is now "Gemini 3.1 Pro". Consider updating the tooltip to reference "Gemini 3.1 Pro" to stay consistent.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
| id: "google/gemini-3-pro-preview", | ||
| displayName: "Gemini 3 Pro", | ||
| id: "google/gemini-3.1-pro-preview", | ||
| displayName: "Gemini 3.1 Pro", |
There was a problem hiding this comment.
P3: Tooltip text for the Gemini 3.1 Pro entry wasn't updated to match the new display name. The tooltip still says "Google's newest Gemini 3 Pro preview model" while the displayName is now "Gemini 3.1 Pro". Consider updating the tooltip to reference "Gemini 3.1 Pro" to stay consistent.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At lib/ai/featuredModels.ts, line 73:
<comment>Tooltip text for the Gemini 3.1 Pro entry wasn't updated to match the new display name. The tooltip still says "Google's newest Gemini 3 Pro preview model" while the displayName is now "Gemini 3.1 Pro". Consider updating the tooltip to reference "Gemini 3.1 Pro" to stay consistent.</comment>
<file context>
@@ -45,39 +45,39 @@ export const FEATURED_MODELS: FeaturedModelConfig[] = [
- id: "google/gemini-3-pro-preview",
- displayName: "Gemini 3 Pro",
+ id: "google/gemini-3.1-pro-preview",
+ displayName: "Gemini 3.1 Pro",
isPro: true,
description: "Google's latest model",
</file context>
…-run (DRY) The onboarding pre-run rendered only the last assistant message's TEXT (getReportTextFromMessages -> <Response>), dropping tool-call and reasoning components — a downgraded, diverging copy of the chat UI. #1877's tool-heavy email workflow made the gap obvious (raw narration, no tool components). Reuse the normal chat's <Message>/<MessageParts> so tool calls/results get their real components. MessageParts was coupled to useVercelChatContext (status + reload); decouple it: both are now optional props with a context fallback, so the normal chat is behaviorally unchanged (props omitted -> context used) while the pre-run supplies them without mounting a provider (VercelChatProvider owns its own useChat instance, so wrapping the pre-run would double the chat). - VercelChatProvider: export VercelChatContext for the optional read. - MessageParts/Message: optional status/reload props, fall back to context. - useFirstTaskReport: expose messages + status. - FirstTaskReportRun: render assistant messages via <Message> (filtering out the auto-sent prompt user message), not a text dump. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
0 issues found across 5 files (changes from recent commits).
Requires human review: Auto-approval blocked by 5 unresolved issues from previous reviews.
Re-trigger cubic
Collaborator
Author
Follow-up: reuse the real chat renderer in the pre-run (DRY) —
|
Collaborator
Author
Screenshots — shared renderer in both surfacesOnboarding first-task pre-run — now renders real tool components (
Normal chat — the same components, unchanged: reasoning block, response text, and Retry/Copy actions (regression check):
|
sweetmantech
added a commit
that referenced
this pull request
Jul 22, 2026
…5.5 (post-#1877) The featured-models refresh in #1877 replaced openai/gpt-5.2 with openai/gpt-5.5, but organizeModels.test.ts still asserted gpt-5.2 was featured — failing CI on test. Update the fixture + assertion to a currently-featured id. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sweetmantech
added a commit
that referenced
this pull request
Jul 22, 2026
… artist add (chat#1867) (#1879) * feat(onboarding): seed the catalog by kicking /api/valuation on first artist add Closes the onboarding catalog dead-end for direct signups. When the first artist is added via the Spotify search (#1878 already links their Spotify profile), useAddSpotifyArtist now fire-and-forget kicks POST /api/valuation { spotify_artist_id } (api#776) — only when the account has no catalog yet — which materializes the catalog + value band in ~20s. So the "Claim your catalog" step is already complete by the time the user reaches it, and they flow through to the first-task step (weekly report emails). - lib/valuation/runValuation.ts — client POST /api/valuation (TDD 2/2). - hooks/useAddSpotifyArtist.ts — background kick on first add (gated on an empty, loaded catalogs query), surfaced via a toast.promise ("Valuing … → Your catalog is ready"), invalidating the catalogs query on success so the sequence advances. chat#1867 (seed onboarding catalog on first artist add). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(models): fix organizeModels fixture — featured id gpt-5.2 → gpt-5.5 (post-#1877) The featured-models refresh in #1877 replaced openai/gpt-5.2 with openai/gpt-5.5, but organizeModels.test.ts still asserted gpt-5.2 was featured — failing CI on test. Update the fixture + assertion to a currently-featured id. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sweetmantech
added a commit
that referenced
this pull request
Jul 22, 2026
…t-task emails, add-artist, Kimi K3 (#1880) * feat(onboarding): state-derived onboarding router with resume-on-landing + skip-for-now (#1872) * feat(onboarding): state-derived onboarding router with resume-on-landing + skip-for-now On every authenticated landing, chat home derives the onboarding step from the activation checkpoint predicates (has artists -> artists have socials -> has claimed catalog -> has enabled task) over existing data sources, never a stored wizard cursor (#1867). Incomplete accounts resume the sequence at the first unmet step; an always-visible skip drops to the app with a dismissible session-scoped checklist; activated accounts never see it. Step cards are titled placeholders linking to the existing pages until the step PRs land. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(onboarding): review fixes — checklist clipped by right rail, account-scoped session flags, storage safety, fresh catalogs per landing, roster-error fail-open, h3 card heading Fixes the preview-verified dismiss bug and all cubic findings on #1872: - Dismiss live bug: the checklist was position:fixed to the viewport, so the z-[65] ArtistsSidebar rail overlapped its right edge and clipped the dismiss button off-screen. Now absolute within the (relative) home content area. Gate state was already single-owner (HomePage passes callbacks down) — locked in with a HomePage-level dismiss/skip/resume test. - P1 cross-account leak: skip/dismiss sessionStorage keys are scoped by account id and re-derived when the account in the tab changes (useOnboardingSessionFlags). - P2 storage safety: read/write go through safe helpers that no-op on throwing storage so the gate fails open instead of crashing. - P2 catalogs staleness: useRefreshCatalogsOnLanding invalidates the catalogs cache on onboarding mount for one fresh read per landing; useCatalogs behavior unchanged for other consumers. - P2 roster-error fail-open: useArtistsRoster now exposes isError; deriveOnboardingState keeps isReady false on roster error so the view resolves to none. - P3 hook length: projection extracted to pure deriveOnboardingState. - P3 heading hierarchy: step card h1 -> h3 under the container h2. Tests: TDD red-first; +26 tests (jsdom + @testing-library/react added as devDeps; vitest include extended to .test.tsx). 174 passing; tsc clean apart from the 7 pre-existing main errors in lib/emails tests. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(onboarding): make the skip checklist a persistent, non-dismissible reminder Remove the checklist-dismissed escape hatch entirely. After "skip for now" the bottom-right "Finish setting up" card is now always present while onboarding is incomplete (survives refresh via the session skip flag), and clicking it re-opens the sequence — there is no way to permanently hide it. Net-removal: drops the second session flag, its storage read/write usage, the dismissChecklist callback threading, the X/Dismiss button, and the separate "Resume setup" button (the card header is now the resume trigger). getOnboardingView collapses to two views (sequence | checklist) and OnboardingFlag to a single member. +47 / -134. Full suite 181 pass, tsc clean on touched files, prettier clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(onboarding): restore plain title + add explicit "Continue" button The checklist header "Finish setting up" is a plain title again (it read as non-clickable). Re-opening the sequence is now a clearly-styled primary "Continue" button at the bottom of the card, replacing the ambiguous click-the-header affordance. Suite 181 pass, tsc clean on touched files, prettier clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> * feat: post-valuation catalog report on /catalogs/[catalogId] (chat#1867 sequence step 1) (#1873) The marketing valuation CTA landed on a bare Catalog Songs admin screen. /catalogs/{id} now opens as a real catalog report: valuation echo (central value + range via the ported marketing formula), lifetime streams, tracks/releases measured, per-release table with album art, per-section diagnosis + prescription copy, and one primary CTA (set up your weekly report -> /tasks). The existing songs/ISRC management UI stays reachable as a secondary Manage songs tab. Valuation math mirrors marketing/lib/valuation (identical constants; age from the api's catalog_age_years, 5y default). Release rollups are null-safe on album/name/artist metadata independently of the sibling crash-fix PR. Reuses the chat#1852 useCatalogMeasurements hook, extending its response type with the v2 aggregate fields as optionals. Co-authored-by: Claude Fable 5 <noreply@anthropic.com> * feat: roster + socials verification onboarding steps (chat#1867) (#1870) * feat: roster + socials verification onboarding steps (chat#1867) Two self-contained onboarding step components for the chat#1867 sequence, mounted standalone at /onboarding/roster so the slice is user-testable before the onboarding router lands: - ConfirmRosterStep: shows the auto-created artist(s) from the valuation flow, inline "add another artist" for multi-artist managers (existing POST /api/artists endpoint), confirm to advance. - VerifySocialsStep: per rostered artist, lists the auto-matched socials with handle + follower count; each match is confirmed or rejected, wrong matches are fixed by pasting the correct profile link (existing PATCH /api/artists/{id} profileUrls path), and artists with no socials record an explicit "none". Verification state is pure client-side logic (lib/onboarding/*, TDD'd): verdict reducers, per-artist and step-level resolution predicates, PATCH payload building with APPPLE->APPLE platform-key normalization, and a follower-count accessor tolerant of the API's snake_case rows behind chat's camelCase SOCIAL type. No new endpoints, tables, or context providers - hooks compose the existing ArtistProvider / OrganizationProvider / Privy auth. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(onboarding): simplify verify-socials to accept-by-default (chat#1867) Per design review: drop the per-social Correct/Wrong verdicts, the resolution/gating machinery, and the explicit "This artist has no socials" button. Matches are accepted by default; the only actions are Edit (fix a wrong link, existing PATCH profileUrls path) and — for an artist with no matches — a soft nudge + "Add a profile". Continue always proceeds (empty = implicit none). Deletes the verdict code that would otherwise be merged and immediately removed: socialVerificationTypes, applySocialVerdict, isArtistSocialsResolved, areAllArtistsResolved, markArtistHasNoSocials, findSocialIdByPlatform, useSocialsVerification, SocialVerifyRow (+ their tests). Net −13 files. Note: "Remove/delete a social" (the other half of the design) needs a new api endpoint — the api's PATCH profileUrls is per-platform merge with no delete-social path — tracked as a fast-follow on chat#1867. Full suite 144 pass, tsc clean on touched files, lint + prettier clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(onboarding): always offer Add-a-profile per artist, not just empty ones A matched-social list can still be missing platforms (e.g. Spotify found but no Instagram). Surface 'Add a profile' below every artist's socials, not only when zero were auto-matched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> * feat(onboarding): first-task step — pre-run weekly report + confirm schedule (#1871) Sequence final step for chat#1867 (respec 2026-07-20, pre-run shape): generate the first weekly catalog report immediately through the normal chat pipeline (same POST /api/chat transport a send uses), show it finished, then ask one question — "get this every Monday?". Confirm creates the enabled weekly task via the existing POST /api/tasks path (which also mints the schedule) and shows the next-run time; decline creates nothing. Mounted standalone at /onboarding/first-task so the step is user-testable before the OnboardingSequence container exists. The pre-run prompt and the scheduled task prompt come from one builder, so the preview the user confirms is byte-for-byte what Monday's run uses. Co-authored-by: Claude Fable 5 <noreply@anthropic.com> * feat(onboarding): first-task weekly report actually emails — LA EQUIS template + Kimi K3 (chat#1867) (#1877) * feat(onboarding): first-task weekly report actually emails (LA EQUIS template + Kimi K3) The first-task prompt generated a report but never emailed it (email is a prompt-driven send_email call, and the prompt had no recipient or send instruction) — proven by firing the created task: the agent ran and persisted a report, but email_send_log stayed empty. Generalize buildFirstTaskPrompt from the proven LA EQUIS weekly report (scheduled_action 39fb5f68, running week over week): resolve the artist's Spotify id from its connected profile -> capture this week's play counts -> compute real week-over-week per-track deltas -> build a fully hex-specced inline-CSS HTML email -> send via the recoup-platform-email-helper skill -> confirm the Resend id. Carries the sandbox no-python and anti-fabrication guardrails verbatim (what makes the send reliable). Thread the account email (recipientEmail) + artistAccountId through both callers so the pre-run preview and the Monday scheduled task both send to the account holder. Bump both surfaces from DEFAULT_MODEL (openai/gpt-5.4-mini — completes the data calls but gives up before composing the long HTML email, the LA EQUIS lesson) to a new REPORT_MODEL (moonshotai/kimi-k3), which reliably composes and sends. chat#1867 (first-task email-prompt gap). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(onboarding): default model -> Kimi K3 (KISS); harden email-less + shell paths Address review feedback on #1877: - Sweets (KISS): collapse the new REPORT_MODEL constant into DEFAULT_MODEL — set DEFAULT_MODEL = moonshotai/kimi-k3 app-wide (the fast gpt-5.4-mini default gave up before composing the long HTML report email). Revert both onboarding hooks to DEFAULT_MODEL; relabel the featured picker entry (id: DEFAULT_MODEL) from "GPT-5.4 Mini" to "Kimi K3" so it isn't mislabeled. - CodeRabbit (email-less login): a wallet/phone/social-only Privy account has no email — FirstTaskStep now shows a distinct "add an email" alert (not an infinite "Preparing…"), and useConfirmFirstTask's onError distinguishes EMAIL_REQUIRED from a generic retry. - Codex (shell-safety): artist/track/album names are user-entered; add a prompt guardrail to pass them as single quoted args so a name with quotes/;/$() can't alter the email-helper command. Codex "non-Pro users get rejected" P2 is a false positive: the prior default (gpt-5.4-mini) is also non-free by isFreeModel yet ships as the default, so the API does not hard-block non-free default models. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Update lib/consts.ts * chore(models): refresh featured model list to latest per series Sweets: while touching the featured list, bring every entry to its series' latest (verified present in the AI Gateway catalog): - GPT-5.2 -> GPT-5.5 - Claude Opus 4.5 -> 4.8 - Claude Sonnet 4.5 -> Sonnet 5 - Gemini 2.5 Flash Lite -> Gemini 3.5 Flash Lite - Gemini 3 Pro -> Gemini 3.1 Pro - Grok 4 -> Grok 4.5 (Kimi K3 already latest.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(chat): reuse the real Message renderer in the first-task pre-run (DRY) The onboarding pre-run rendered only the last assistant message's TEXT (getReportTextFromMessages -> <Response>), dropping tool-call and reasoning components — a downgraded, diverging copy of the chat UI. #1877's tool-heavy email workflow made the gap obvious (raw narration, no tool components). Reuse the normal chat's <Message>/<MessageParts> so tool calls/results get their real components. MessageParts was coupled to useVercelChatContext (status + reload); decouple it: both are now optional props with a context fallback, so the normal chat is behaviorally unchanged (props omitted -> context used) while the pre-run supplies them without mounting a provider (VercelChatProvider owns its own useChat instance, so wrapping the pre-run would double the chat). - VercelChatProvider: export VercelChatContext for the optional read. - MessageParts/Message: optional status/reload props, fall back to context. - useFirstTaskReport: expose messages + status. - FirstTaskReportRun: render assistant messages via <Message> (filtering out the auto-sent prompt user message), not a text dump. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(artists): Add New Artist opens a shared Spotify search — kills the /artists loop (chat#1867) (#1878) * fix(artists): Add New Artist opens a shared Spotify search (kills the /artists loop) "Add New Artist" (and the sidebar/header equivalents) called toggleCreation, which pushed `/?q=create a new artist` and relied on the home CHAT to interpret it. The onboarding router (chat#1872) now intercepts the home for incomplete accounts and renders "Finish setting up" instead, so the query never ran — the "Open your roster" CTA bounced back to /artists → infinite loop. Replace the redirect with a shared Spotify artist-search dialog: - lib/spotify/parseSpotifyArtistResults.ts — pure parser for the GET /api/spotify/search?type=artist envelope (id/name/imageUrl/profileUrl/followers). - lib/artists/addSpotifyArtist.ts — create by name (POST /api/artists) then link the Spotify image + profile URL (PATCH), so the roster gets real data. - useSpotifyArtistSearch (debounced, abortable) + useAddSpotifyArtist hooks. - components/Artists/SpotifyArtistSearch.tsx — the shared typeahead (reused next for social enrichment + verify-socials). - components/Artists/AddArtistDialog.tsx — global dialog, mounted in layout. - useArtistMode.toggleCreation now opens the dialog (isCreationOpen/closeCreation) instead of the redirect — fixes /artists, sidebar, and header at once. TDD: parseSpotifyArtistResults 5/5, addSpotifyArtist 2/2, red→green. tsc clean on touched files, eslint/prettier clean. chat#1867 (/artists add-artist loop). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(artists): reuse canonical Spotify types; drop redundant parser (−106 LOC) Simplification pass on the add-artist slice: - Delete lib/spotify/parseSpotifyArtistResults.ts (+ its 5 tests) and the custom SpotifyArtistResult type — types/spotify.ts already exports SpotifySearchResponse ({ artists?: { items: SpotifyArtistSearchResult[] } }) and SpotifyArtistSearchResult (id/name/external_urls/images/followers). useSpotifyArtistSearch now reads `data.artists?.items` directly and returns the canonical type; the component and addSpotifyArtist read images[0].url / followers.total / external_urls.spotify inline. Kept (checked, "no simpler"): addSpotifyArtist's two-step create→link, because POST /api/artists only accepts a name; and useSpotifyArtistSearch, since there is no existing debounced-search hook to reuse. Net -106 LOC; behavior unchanged; addSpotifyArtist 2/2 green, tsc 0 new. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat(onboarding): seed the catalog by kicking /api/valuation on first artist add (chat#1867) (#1879) * feat(onboarding): seed the catalog by kicking /api/valuation on first artist add Closes the onboarding catalog dead-end for direct signups. When the first artist is added via the Spotify search (#1878 already links their Spotify profile), useAddSpotifyArtist now fire-and-forget kicks POST /api/valuation { spotify_artist_id } (api#776) — only when the account has no catalog yet — which materializes the catalog + value band in ~20s. So the "Claim your catalog" step is already complete by the time the user reaches it, and they flow through to the first-task step (weekly report emails). - lib/valuation/runValuation.ts — client POST /api/valuation (TDD 2/2). - hooks/useAddSpotifyArtist.ts — background kick on first add (gated on an empty, loaded catalogs query), surfaced via a toast.promise ("Valuing … → Your catalog is ready"), invalidating the catalogs query on success so the sequence advances. chat#1867 (seed onboarding catalog on first artist add). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(models): fix organizeModels fixture — featured id gpt-5.2 → gpt-5.5 (post-#1877) The featured-models refresh in #1877 replaced openai/gpt-5.2 with openai/gpt-5.5, but organizeModels.test.ts still asserted gpt-5.2 was featured — failing CI on test. Update the fixture + assertion to a currently-featured id. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
15 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Fast-follow to #1871. The onboarding first task generated a report but never emailed it — email is a prompt-driven
send_emailtool call, andbuildFirstTaskPromptsaid "write the report" with no recipient + no send instruction. Proven 2026-07-21 by firing the created task: the agent ran and persisted a report (chat_messagesassistant row under chatbfcb927c…, ~14.3 KB), butemail_send_logstayed empty. Emailing the weekly report is the whole point of the task.Two root causes, both fixed here:
The prompt never instructed a send. Generalized
buildFirstTaskPromptfrom the proven LA EQUIS weekly report (scheduled_action 39fb5f68…, running week over week toinfo@shiftedculture.com): resolve the artist's Spotify id from its connected profile → capture this week's Spotify play counts → compute real week-over-week per-track deltas (diff latest vs most-recent-prior-day capture) → build a fully hex-specced inline-CSS HTML email → send via therecoup-platform-email-helperskill → confirm the Resend id. The sandbox no-python and anti-fabrication guardrails are carried over verbatim — they're what make the send reliable. Threads the account email (recipientEmail) +artistAccountIdthrough both callers so the pre-run preview and the Monday scheduled task both deliver to the account holder.The model gave up before composing the email. Both surfaces ran on
DEFAULT_MODEL(openai/gpt-5.4-mini) — the exact model the LA EQUIS notes flag as "completes the data calls but gives up before composing the long HTML email." AddedREPORT_MODEL = moonshotai/kimi-k3and pointed both the pre-run (useFirstTaskReport) and the scheduled task (useConfirmFirstTask) at it.Per the discussion, one prompt drives both the on-screen pre-run and the scheduled task (byte-for-byte parity preserved) — so the user also gets a real email during onboarding.
Changes
lib/onboarding/buildFirstTaskPrompt.ts— generalized LA EQUIS template; input now{ artistName, artistAccountId, recipientEmail, catalogName? }.lib/onboarding/buildFirstTaskParams.ts— threadrecipientEmailthrough.hooks/useConfirmFirstTask.ts— source the account email (Privyuser.email),EMAIL_REQUIREDguard,REPORT_MODEL.hooks/useFirstTaskReport.ts— pre-run usesREPORT_MODEL.components/Onboarding/FirstTaskStep.tsx— source email + artistAccountId; gate the pre-run until both are ready.lib/consts.ts—REPORT_MODEL = "moonshotai/kimi-k3"(verified in the gateway catalog).Tests (TDD, red→green)
buildFirstTaskPrompt.test.ts— RED first (6 failing on the new assertions), then GREEN: embeds recipient email, embedsartist_account_id, instructs the email send (recoup-platform-email-helper), carries the no-python guardrail, forbids fabrication, catalog-by-name, pure. 9/9.buildFirstTaskParams.test.ts— threads the recipient email into the scheduled prompt. 3/3.lib/onboardingsuite 62/62;tsc --noEmitclean on all touched files (the 10 repo-wide tsc errors are pre-existing@testing-library/react/extractSendEmailResultsdrift, none touch this change); prettier clean.Verification (pending)
Preview verification on the sha-checked deployment: run onboarding to the first-task step → confirm the pre-run streams and an email lands in the account inbox, and the scheduled
scheduled_actionsrow emails on its next run (checkemail_send_logfor asentrow + Resend id). Basetestper the #1867 branch decision.Tracking: chat#1867 (🔴 first-task email-prompt gap).
Summary by cubic
Fixes the onboarding first task so the weekly report is actually emailed. Uses the LA EQUIS template and sets
DEFAULT_MODELtomoonshotai/kimi-k3for reliable compose-and-send; refreshes the featured model list.Bug Fixes
recipientEmail,artist_account_id, and arecoup-platform-email-helpersend; threaded throughbuildFirstTaskPrompt/params and both hooks so pre-run and the scheduled task match.useConfirmFirstTaskthrowsEMAIL_REQUIREDwith a targeted toast.Refactors
REPORT_MODELintoDEFAULT_MODEL; app-wide default is nowmoonshotai/kimi-k3. Featured picker shows “Kimi K3” with an updated tooltip.openai/gpt-5.5,anthropic/claude-opus-4.8,anthropic/claude-sonnet-5,google/gemini-3.5-flash-lite,google/gemini-3.1-pro-preview,xai/grok-4.5.Message/MessagePartsto render tool calls/results; decoupled fromVercelChatProvidervia optionalstatus/reloadand an exported context.Written for commit 637ef1a. Summary will update on new commits.
Summary by CodeRabbit