[baldurpan]

Closes #330

What changed

ClickUp answers HTTP 401 both for a rejected token and for a task or List it will not hand over (an id it never allocated, another Workspace's task). rejectFailedResponse read every 401 as Authentication failed, which sent people to regenerate a token that was fine.

• src/integrations/clickup.ts: a read that names what it asked for (Get Task in fetchClickUpTask, startClickUpTask and assignClickUpTask, and Get List) now looks at a 401's body:
  • ECODE OAUTH_019 or OAUTH_025 (the token-side codes from the issue's table) → the authentication message, as before.
  • any other ECODE with a non-empty err → ClickUp: could not find task <id>, or this token cannot see it: <err> (list <id> for the List read).
  • a body with no code or text → the authentication message, since nothing tells the two apart.
  • Only the token-side codes are listed, because the task-side codes are observed, not documented.
• 403, the /user read and both writes (move, assign) are unchanged: every 401 there is still authentication.
• src/integrations/clickup.test.ts: covers the four observed task-side codes, the two token codes, the List read, and the assign read against /user and the write.
• docs/.../guides/clickup-integration.mdx: the passage that called the status a guess now describes the split, and the write passage says a 401 there is always authentication.
• .changeset/quiet-tasks-unseen.md: patch (level confirmed by the maintainer).

No message holds the token: the new text is built from the typed id or List id and ClickUp's err, and the output layer still runs redactSecrets and escapes control characters (src/lib/base-command.ts:1538-1542, src/commands/branch.ts:839, :962).

Gates

Run through /orchestrate --pr #330.

Gate 1 (context/verify.md, every section, exit 0 each): pnpm check, pnpm typecheck, pnpm --filter docs typecheck, pnpm build, pnpm docs:build, pnpm --filter docs worker:bundle-check, pnpm docs:audit-dist, pnpm test (3817 passed), pnpm docs:test (748 passed), and the test-marker grep.

Gate 2 (the reviewer subagent): PASS WITH NOTES after one loop. Loop 1 failed on two items, both fixed: the guide's "any other 401" claimed more than the code does, and the start-flow test's regex could not tell the task and List wording apart.

The reviewer also left these non-blocking notes, not acted on:

• the quoted err has no length cap (control characters are already escaped on output);
• no test covers a 401 that has an ECODE but an empty err, or an err but no ECODE; both fall back to authentication by design;
• in the guide's start section, "A 401 or 403 reads as the authentication message" could say "On the update," so it is not read as covering the reads;
• the new message suggests no next step, such as checking the id or the Workspace.

[baldurs-reviewer]

code-reviewer: looks good

The change makes a 401 on the three Get Task reads and the Get List read look at ClickUp's ECODE and err. The two token codes, or a body without both fields, still report authentication; any other coded 401 reports the task or List as not found or not visible, quoting ClickUp's text. The /user read, the two writes and 403 are unchanged. The logic, tests and changeset hold together, and I found nothing that needs fixing. One small documentation nit, outside the diff's hunks: in the guide's start section (lines 134–136), "A 401 or 403 reads as the authentication message" sits after a sentence about the write but is not scoped to it, so it can be read as covering the two reads that now behave differently; "On the update, a 401 or 403…" would remove the ambiguity.

---

Reviewed cc00712 for baldurpan · claude-opus-5-5 · 4 files · $0.26

[baldurpan]

Re the documentation nit in the review of cc00712 (guide lines 134–136): right, and it was this change that made the sentence ambiguous. Fixed in a9c8685. The sentence now starts "On the update," and points to the section that describes a 401 on the two reads. Gate 2 had flagged the same line as non-blocking.

[baldurs-reviewer]

code-reviewer follow-up: looks good

Since the last review, only the ClickUp guide changed. The start section now scopes its 401/403/404/429 sentence to the update and links the two reads to the section that describes how a 401 is split. The wording is accurate: the start flow does make two reads, the task and the List, and the anchor matches the heading. I found nothing further, and no earlier comments remain open.

---

Reviewed a9c8685 (changes since cc00712) for baldurpan · claude-opus-5-5 · 1 file · $0.06

[baldurs-reviewer]

code-reviewer follow-up: looks good

Since the last review, the branch picked up three small changes, which look like they came in from merging main (#331). The ClickUp guide's token-settings path now reads Settings -> ClickUp API -> API Token. getClickUpBranchNaming now passes shared and dryRun separately to evaluateBranchTypeRules, so a dry run no longer warns about the portable Type field, and a new test pins that down. I could not see src/lib/branch-type.ts; I assumed its options type accepts dryRun and keeps the old behaviour of warning on a misspelt shared field in a dry run, which the existing test at line 883 still checks. The #330 changes themselves are unchanged, and I have nothing new to raise.

---

Reviewed a9c339b (changes since a9c8685) for baldurpan · claude-opus-5-5 · 3 files · $0.22