Code quality (always)

Optimise for the next reader.

• Kill what-comments — the project's #1 readability rule. Delete any comment that narrates what the next line does, or replace it by extracting a well-named method/variable. The bar for keeping a comment is high: only a genuine why the code cannot carry (external constraint, a workaround and the bug it dodges, a counterintuitive decision). Restating the call sequence, or justifying a step a good name already conveys, is not a why — cut it. Type-shape docblocks (@param array{…}, @return Collection<…>) are not comments; keep them.

  // ✗ what — delete it or let a name carry it
  // mirror each task's section onto its Todoist priority
  $this->mirrorSectionsToTodoist($tasks);
  
  // ✓ why — a constraint the code itself can't show; keep it
  // Todoist can't set a native duration on a dateless task, so it rides as a label
  $labels[] = $estimate->value;

• Names over narration. Prefer the unhappy path first + early returns (avoid else). Small single-purpose methods that read like a summary. Push logic out of controllers.

• Readability first; collections are usually how you get there. The north star is human-readable, low-cognitive-load code — that's the thing being optimised. Favour collections over array_* + foreach by default, not as a rule for its own sake but because a collect()->filter()->map() / higher-order pipeline ($orders->filter->isPaid()->sum->amount, $subscriptions->active()->each->cancel()) usually reads with less load than the array/loop equivalent (Wathan). So reach for it first. But the test is readability, never "did I use a collection": when a plain array call or a simple loop is genuinely clearer — a tiny one-liner, a side-effectful accumulator — keep it. Collections are the means; readability is the end.

• Correctness outranks frugality. Token/byte savings are a means, never the goal — optimise- work (context, prompts, code) trims what buys nothing, never what carries load. A trim that makes the agent more likely to get something wrong is a false economy: re-resolving one QA-flagged issue costs far more than the tokens it saved. When in doubt, keep it.

• Lean on the framework. Do things the documented Laravel way; deviate only with a specific, stated reason, and leave a short note when you do.

• Let statements breathe. Blank lines between logical groups so the structure is visible at a glance; keep tightly-related lines together.

• No premature abstraction. Don't add a layer/interface/service until a second use case demands it. If code looks redundant, flag it — don't rewrite on assumption.

• Consistency beats personal preference. Match the established pattern in the file/area.

Scope & shape of a change

• Prefactor first — "make the change easy, then make the easy change" (Kent Beck). Before implementing, look for a small restructuring that makes the change you're about to make simpler; do that prefactor first (ideally as its own step), then make the now-easy change. Prefactor only what eases this change.
• …but scope cleanup to the change. Reuse existing types / helpers / components before adding new ones; keep the diff as small as correctness and readability allow. Don't refactor a file just because you opened it, don't add abstractions for a hypothetical future, don't mix unrelated cleanup into a behavioural change. A real issue that this change doesn't need is a follow-up — note it (PR body / an issue), don't let it swell the diff.