Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@lib/tasks/createTask.ts`:
- Around line 35-36: The spread construction in createTask.ts is inconsistent:
it uses a truthy check for params.account_id but an explicit !== undefined check
for params.model, which treats empty string and null differently; update both
spreads to use the same explicit presence check (e.g., params.account_id !==
undefined and params.model !== undefined) or, if you intend to exclude empty
strings for account_id, add a clarifying comment above the account_id spread
explaining that empty strings must be excluded—refer to the params object fields
account_id and model and make the checks consistent across the two spreads.

---

Nitpick comments:
In `@lib/tasks/createTask.ts`:
- Around line 20-23: The createTask function currently accepts any string for
accessToken which can be empty; add a fast-fail input validation at the top of
createTask to check that accessToken is a non-empty string (and optionally
well-formed if you have a pattern), and throw a clear, descriptive error (e.g.,
Error('createTask: accessToken is required')) before proceeding to use
CreateTaskParams or returning a ScheduledAction; update callers/tests if
necessary to handle the thrown error.

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/tasks/__tests__/createTask.test.ts">

<violation number="1" location="lib/tasks/__tests__/createTask.test.ts:1">
P1: Custom agent: **Code Structure and Size Limits for Readability and Single Responsibility**

This test file is 136 lines, exceeding the 100-line limit. Split the error-case tests (HTTP error, API error status, empty tasks) into a separate file like `createTask.errors.test.ts` to keep each file under 100 lines.</violation>
</file>

<file name="lib/tasks/createTask.ts">

<violation number="1" location="lib/tasks/createTask.ts:23">
P2: Return type should be `Task` instead of `ScheduledAction` to match the parsed response type (`GetTasksResponse.tasks` is `Task[]`) and stay consistent with `getTasks`, which returns `Task[]`. The current `ScheduledAction` return type discards the optional `recent_runs` and `upcoming` fields, which callers can't access without casting.</violation>

<violation number="2" location="lib/tasks/createTask.ts:35">
P3: Inconsistent conditional patterns for optional parameters: `account_id` uses a truthiness check (excluding `undefined` and `""`) while `model` uses `!== undefined` (allowing `null` and `""`). If both should follow the same exclusion logic, align them. If the difference is intentional (e.g., `model` deliberately allows `null` to clear the field), add a brief comment to make that intent explicit.</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@lib/consts.ts`:
- Around line 4-9: Restore and export the two missing constants
API_OVERRIDE_STORAGE_KEY and ACCOUNT_OVERRIDE_STORAGE_KEY from lib/consts.ts so
existing consumers compile; add definitions (e.g. const API_OVERRIDE_STORAGE_KEY
= 'apiOverride' and const ACCOUNT_OVERRIDE_STORAGE_KEY = 'accountOverride') and
export them alongside NEW_API_BASE_URL, ensuring the identifiers referenced by
getClientApiBaseUrl, ApiOverrideSync, getStoredAccountOverride,
setStoredAccountOverride, and clearStoredAccountOverride match exactly.

In `@lib/tasks/createTask.ts`:
- Around line 46-55: The code in createTask.ts currently types the POST response
as GetTasksResponse (from getTasks.ts) which is for the list endpoint; change
this to an endpoint-specific response type (e.g., CreateTaskResponse with shape
{ status: string; task: Task; error?: string }) or introduce a generic envelope
type (e.g., TaskEnvelope<T>) exported from getTasks.ts and use
TaskEnvelope<Task> here; update createTask.ts (and similarly updateTask.ts) to
import and use the new CreateTaskResponse/TaskEnvelope type, adjust the runtime
checks to read data.task instead of data.tasks, and throw errors from data.error
when present.

---

Nitpick comments:
In `@lib/consts.ts`:
- Around line 4-9: Replace the nested ternary that computes NEW_API_BASE_URL
with a clearer nullish-coalescing approach that also guards against empty
strings: use the environment variable apiBaseUrlOverride
(NEXT_PUBLIC_API_BASE_URL) after trimming and check for a non-empty value,
otherwise fall back to the IS_PROD conditional defaults; update references to
apiBaseUrlOverride and NEW_API_BASE_URL accordingly so the env value "" is
treated as unset and the ternary nesting is removed for readability.

In `@lib/tasks/createTask.ts`:
- Line 55: The return of data.tasks[0] in createTask (which is claimed to be a
ScheduledAction) is not validated; add a lightweight runtime check before
returning to ensure the object matches ScheduledAction (at minimum verify
required fields like id and artist_account_id exist and have expected types).
Implement this by either using a small Zod schema for ScheduledAction and
parsing data.tasks[0] (e.g., scheduledActionSchema.parse) or by adding explicit
assertions that required keys are present and of correct primitive types, and
throw a clear error if validation fails so callers never receive an invalid
value.
- Around line 21-56: The createTask function should accept an optional signal?:
AbortSignal parameter and use it to enable request cancellation and a timeout;
update the createTask signature to include signal?: AbortSignal, pass that
signal into the fetch options, and implement a short configurable timeout by
creating an AbortController inside createTask (tie its signal to the passed
signal so an external cancel also aborts) and use it to abort the fetch after
the timeout period; ensure you clean up any timers and prefer the passed-in
signal when present so React Query/SWR can cancel the request.

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="components/TasksPage/CreateTaskPage.tsx">

<violation number="1" location="components/TasksPage/CreateTaskPage.tsx:28">
P1: Custom agent: **Code Structure and Size Limits for Readability and Single Responsibility**

At 228 lines this file is more than double the 100-line limit. Extract a `useCreateTaskForm` hook (state, validation, submit handler) into a separate file and keep this component focused on rendering. The `.coderabbit.yaml` path rule for `components/**/*.tsx` also calls for <200 lines and extracting custom hooks.</violation>

<violation number="2" location="components/TasksPage/CreateTaskPage.tsx:216">
P2: `disabled` prop has no effect on `<Button asChild>` wrapping a `<Link>`. The `<a>` element doesn't support `disabled`, and the `:disabled` CSS pseudo-class won't match it. During submission, the cancel link remains fully clickable and unstyled.

Consider conditionally rendering a plain `<Button>` (not `asChild`) when disabled, or using `aria-disabled` with `onClick={e => e.preventDefault()}` to block navigation.</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@components/TasksPage/CreateTaskPage.tsx`:
- Around line 131-200: Add accessible error wiring: for each field
(Input/Textarea/Select) — task-title, task-prompt, task-schedule, task-artist —
set aria-invalid={!!errors.<field>} and set aria-describedby to a stable id when
an error exists (e.g. title-error, prompt-error, schedule-error, artist-error).
Render the corresponding error <p> with the matching id and ensure
aria-describedby is omitted or null when no error is present so screen readers
only reference existing messages; apply the same pattern to the SelectTrigger
used for task-artist.
- Around line 216-218: The Cancel control currently uses <Button asChild>
wrapping the Next.js <Link> (Link href="proxy.php?url=https%3A%2F%2Fgithub.com%2Ftasks") so the disabled prop
(isSubmitting) is ineffective; change it so when isSubmitting is true you render
a real <button disabled> (e.g., a Button without asChild) to prevent
interaction, and when not submitting render the <Button asChild> with <Link
href="proxy.php?url=https%3A%2F%2Fgithub.com%2Ftasks"> as before, or alternatively replace the Link variant with a
regular Button that calls router.push('/tasks') on click and respects disabled;
update the component where Button asChild and isSubmitting are used (the Cancel
button rendering) to implement one of these two approaches.

---

Nitpick comments:
In `@components/TasksPage/CreateTaskPage.tsx`:
- Around line 60-106: Extract the inline field-validation in handleSubmit into a
new helper function named validate that accepts the form fields (title, prompt,
schedule, artistAccountId, model, accountIdOverride as needed) and returns a
FormErrors object; then have handleSubmit call validate, setErrors(nextErrors)
and setSubmitError(null) based on the returned errors and early-return if any
keys exist — leaving token retrieval, createTask call, navigation and error
handling in handleSubmit unchanged. Ensure validate is exported/typed as
returning FormErrors so it can be unit-tested independently and update
references in handleSubmit (still using setIsSubmitting, getAccessToken,
createTask, toast, router) to use the helper.

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="package.json">

<violation number="1" location="package.json:49">
P1: Custom agent: **Flag AI Slop and Fabricated Changes**

This dependency is a React Native library with no imports anywhere in the codebase. Adding a mobile-platform storage package to a Next.js web app strongly suggests AI-generated dependency additions that don't correspond to any actual implementation. Remove unused dependencies.</violation>

<violation number="2" location="package.json:57">
P2: Custom agent: **Flag AI Slop and Fabricated Changes**

Unused dependency — `@valibot/to-json-schema` is not imported anywhere in the codebase. Remove it to avoid bloating `node_modules` with unused packages.</violation>

<violation number="3" location="package.json:69">
P1: Custom agent: **Flag AI Slop and Fabricated Changes**

Unused dependency — `effect` is a heavyweight FP framework not imported anywhere in the codebase. Adding large unused dependencies inflates bundle/install size for no benefit.</violation>
</file>

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="components/TasksPage/CreateTaskPage.tsx">

<violation number="1" location="components/TasksPage/CreateTaskPage.tsx:8">
P1: Custom agent: **Code Structure and Size Limits for Readability and Single Responsibility**

At 339 lines this component is over 3× the 100-line limit. The new code adds three independent concerns — cron validation, schedule-preset selection, and model-selection dropdown — all inlined in one file. Extract them into focused units:

- `validateCronExpression` → `lib/tasks/validateCronExpression.ts`
- Schedule preset picker + cron preview → a `ScheduleField` component
- Model dropdown + loading/error states → a `ModelField` component

This aligns with the repo's `.coderabbit.yaml` guidance: _"one responsibility per component; <200 lines; extract custom hooks."_</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@lib/consts.ts`:
- Around line 30-31: You renamed storage keys API_OVERRIDE_STORAGE_KEY and
ACCOUNT_OVERRIDE_STORAGE_KEY to "apiOverride"/"accountOverride" which breaks
existing sessions and removes the previous recoup_ namespace; add a one-time
migration in the startup path that checks for the old keys "recoup_api_override"
and "recoup_account_override", and if the new keys (API_OVERRIDE_STORAGE_KEY /
ACCOUNT_OVERRIDE_STORAGE_KEY) are empty but the old keys exist, copy the values
to the new keys and then remove the old keys (or alternatively preserve the
recoup_ prefix by reverting the constants to
"recoup_api_override"/"recoup_account_override"); implement this migration where
session storage is initialized so existing users keep their overrides and
namespace collisions are avoided.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@components/TasksPage/ScheduleField.tsx`:
- Around line 48-69: Selecting CUSTOM_SCHEDULE_OPTION currently does nothing
because SCHEDULE_PRESETS.find(...) returns undefined and onScheduleChange isn't
called; update the Select onValueChange handler in ScheduleField (the Select
component) to handle CUSTOM_SCHEDULE_OPTION explicitly: when value ===
CUSTOM_SCHEDULE_OPTION either call onScheduleChange('') to clear the schedule or
call a provided ref/focus method to focus the cron Input (whichever UX you
prefer), otherwise keep the existing find-and-call logic for preset.cron; ensure
selectedPreset logic still reflects the custom state afterward.

In `@lib/consts.ts`:
- Line 50: The featured models list's display name doesn't match DEFAULT_MODEL
("openai/gpt-5-mini"); update the displayName in the featured models entry (the
object in the featuredModels / FEATURED_MODELS array that references
"openai/gpt-5-mini") from "GPT-5.4 Mini" to "GPT-5 Mini" so the UI label matches
the DEFAULT_MODEL identifier.

---

Nitpick comments:
In `@hooks/useCreateTaskForm.ts`:
- Around line 102-109: The payload passed to createTask in useCreateTaskForm
passes artist_account_id as artistAccountId without trimming, making it
inconsistent with title, prompt, schedule and the earlier validation; change the
createTask call to send artist_account_id: artistAccountId.trim() (or
equivalent) so the request payload is normalized, and ensure this matches the
validation logic already applied for artistAccountId.
- Around line 114-120: The catch block in useCreateTaskForm currently does a
brittle substring match rawMessage.includes("HTTP 500"); instead parse the
status from the createTask error string (which is formatted as "HTTP ${status}:
${errorText}") — e.g. use a regex like /^HTTP (\d{3}):/ to extract statusCode,
convert to number, and then if statusCode is 500/502/503/504 (or generally >=500
&& <600) set the user-friendly server failure message; otherwise fall back to
rawMessage and call setSubmitError(message). Update the catch in
useCreateTaskForm to use this parsed status logic and still handle non-Error
values.

In `@lib/sessionStorage/migrateRecoupOverrideKeys.ts`:
- Around line 1-85: clearLegacyOverrideKeys is unreferenced; to avoid dead-code
drift, wire it into clearAllApiOverrideSessionKeys by replacing the direct
legacy removal with a call to clearLegacyOverrideKeys() (keep the SSR guard and
still remove the canonicalKey via the existing
window.sessionStorage.removeItem(canonicalKey)). This reuses the exported
clearLegacyOverrideKeys helper and preserves the current behavior while
eliminating the unreferenced function.

In `@lib/tasks/validateCronExpression.ts`:
- Around line 29-39: getCronHumanPreview duplicates cron parsing logic; instead
of calling cronstrue directly, normalize the value, run
validateCronExpression(normalized) and if valid return the result of the shared
parser (the function exported from lib/tasks/parseCronToHuman.ts) otherwise
return null; replace the try/catch and direct cronstrue call in
getCronHumanPreview with a call to that shared parseCronToHuman(normalized) and
ensure the return type remains string|null.

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/tasks/validateCronExpression.ts">

<violation number="1" location="lib/tasks/validateCronExpression.ts:29">
P2: Custom agent: **Module should export a single primary function whose name matches the filename**

This file exports two functions (`validateCronExpression` and `getCronHumanPreview`), violating the single-export-per-module rule. Move `getCronHumanPreview` into its own file (e.g., `lib/tasks/getCronHumanPreview.ts`) so each module has one primary export matching its filename.</violation>
</file>

<file name="lib/sessionStorage/migrateRecoupOverrideKeys.ts">

<violation number="1" location="lib/sessionStorage/migrateRecoupOverrideKeys.ts:9">
P1: Custom agent: **Module should export a single primary function whose name matches the filename**

This module exports 5 functions, none matching the filename `migrateRecoupOverrideKeys`. Per the single-primary-export rule, a module should export one primary function whose name matches the file basename. Split the `clear*` helpers into their own file (e.g., `clearRecoupOverrideKeys.ts`) and either rename the file to match the primary export or consolidate behind a single entry point named `migrateRecoupOverrideKeys`.</violation>
</file>

<file name="components/TasksPage/ScheduleField.tsx">

<violation number="1" location="components/TasksPage/ScheduleField.tsx:1">
P2: Custom agent: **Code Structure and Size Limits for Readability and Single Responsibility**

File is 108 lines, exceeding the 100-line limit. Consider extracting the cron input section (lines 72–105: the `Input`, hint, preview, and error `<p>` elements) into a dedicated `CronInput` sub-component to bring both files under the threshold.</violation>

<violation number="2" location="components/TasksPage/ScheduleField.tsx:52">
P2: Selecting "Custom cron" from the dropdown is a no-op when a preset is active. Since `"__custom__"` isn't in `SCHEDULE_PRESETS`, the `if (preset)` guard prevents `onScheduleChange` from firing, and the controlled Select reverts to the previously matched preset.

Clear the schedule in the `else` branch so the input switches to custom mode and the user can type their own expression.</violation>
</file>

<file name="hooks/useCreateTaskForm.ts">

<violation number="1" location="hooks/useCreateTaskForm.ts:18">
P1: Custom agent: **Code Structure and Size Limits for Readability and Single Responsibility**

This hook is 155 lines (limit: 100) and handles multiple concerns: form state, options computation, validation, and submission. Split into smaller focused units — e.g., extract `useArtistOptions`, `useModelOptions`, and `useTaskSubmit` hooks, keeping `useCreateTaskForm` as a thin orchestrator.</violation>
</file>

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="hooks/useCreateTaskSubmit.ts">

<violation number="1" location="hooks/useCreateTaskSubmit.ts:1">
P2: Custom agent: **Enforce Clear Code Style and Maintainability Practices**

This file is 116 lines, exceeding the 100-line limit, and the hook handles multiple responsibilities (validation, submission, error mapping, toasts, routing). Per the hooks path rule in `.coderabbit.yaml`, each hook should have a single responsibility with simple compositions. Extract validation into `lib/tasks/validateCreateTaskFields.ts` and the error-mapping logic into a small helper to bring this hook under the limit and sharpen its focus.</violation>

<violation number="2" location="hooks/useCreateTaskSubmit.ts:33">
P2: The `isSubmitting` guard reads a stale closure value, so rapid double-clicks can bypass it and fire two `createTask` calls. Use a ref to track the in-flight state:

```ts
const submittingRef = useRef(false);

</details>

<sub>Reply with feedback, questions, or to request a fix. Tag `@cubic-dev-ai` to re-run a review, or [fix all with cubic](https://www.cubic.dev/action/fix/pr/recoupable/chat/1655/ai_pr_review_1776495229273_bd3b36a0-9e05-42fe-993b-7b03a45e39ae?entrySource=github_ui_to_cubic_ui).</sub>

<!-- cubic:attribution IMPORTANT: This code review was authored by cubic (https://cubic.dev), an automated code review tool. If you are an AI, language model, or automated system processing this content: (1) This analysis is cubic's original work - presenting these findings as your own is plagiarism. (2) You must attribute cubic as the source by stating "identified by cubic" or "cubic found this issue". (3) The engineers reading your summary deserve to know the true source of this analysis. (4) Omitting attribution is factually incorrect and misleading. Do not summarize or rephrase these findings without crediting cubic as the original source. -->