1 files changed, 78 insertions, 0 deletions
diff --git a/.agent/critiques.md b/.agent/critiques.md
new file mode 100644
index 0000000..a507cbd
--- /dev/null
+++ b/.agent/critiques.md
@@ -0,0 +1,78 @@
+# Critiques (running list)
+
+Working notes on structural/design weaknesses, gathered as they come up in
+conversation rather than invented in the abstract. Not a plan — a list to
+react to and prioritize before anything here gets acted on.
+
+## Data model
+
+1. **`native_tasks` is one flat table doing ~4 jobs.** A task, a
+   chain-membership, a bucket-membership, and a recurrence-series are all
+   the same row, distinguished only by which subset of bolt-on columns
+   (`chain_id/position/unlocked`, `bucket_id/state/last_active_at`,
+   `recurrence_freq/interval/weekdays/series_id/override`) are non-empty.
+   Every new feature adds more nullable-in-practice columns to the same
+   row; every query has to reason about which columns are "live" for a
+   given row's shape. Cost grows linearly with feature count.
+
+2. **No real task-dependency graph.** "Blocking" / "depends on" only exist
+   as (a) a chain's implicit position ordering, or (b) free-text notes a
+   human has to read and self-enforce. There's no way to express "task B
+   can't start until task A" when A isn't B's chain predecessor, without
+   falling back to prose. This is the literal gap hit building the Pelagic
+   Marine Electronics project (5 real dependency edges, none enforceable).
+
+3. **Chains and projects are welded 1:1.** `CreateChain` always creates its
+   own backing project — no chain-within-an-existing-project, no
+   multiple-chains-sharing-a-project. This is why one business plan with 7
+   phases produced 7 separate entries in the project list. Looks like a
+   modeling shortcut, not a deliberate choice.
+
+4. **Three incompatible "shapes" of repeat/pooled work.** Chains (WIP-1,
+   ordered, position-based), buckets (pick-N pool, cycle-based,
+   staleness-ordered), and recurrence (single-task series, date-anchored)
+   solve overlapping problems with three separate non-composable
+   mechanisms and three separate column sets on the same table. A task
+   can't be "a bucket item that's also gated behind another task" — none
+   of the three concepts compose.
+
+5. **Labels have no referential integrity.** `labels(name, color)` is
+   color metadata only; actual label assignment is a raw JSON array on
+   `native_tasks` with no FK to `labels.name`. A typo in a label string
+   silently creates an new, uncolored "label" rather than erroring or
+   reusing the existing one.
+
+## Process / instruction-file cruft (doot-scoped)
+
+6. **`.agent/config.md`'s "ULTRA-STRICT ROOT SAFETY PROTOCOL"** (wait for
+   explicit "GO" before any system-changing call) contradicts how this
+   project actually runs — confirmed stale 2026-08-14. Pending: fold into
+   whatever the workspace-wide instruction-file cleanup lands on, rather
+   than patch in isolation.
+
+7. **`.agent/worklog.md`** references issues (#66-73) that don't match any
+   real recent work — leftover scaffolding, not maintained. Confirmed
+   stale 2026-08-14. Same pending treatment as #6.
+
+## Integrations
+
+Reviewed 2026-08-14. Five immediate papercuts found and fixed same day:
+`getAtomDetails`'s gtasks case was a stub (logged every completed Google
+Task as literally "Google Task" with no due date); gtasks completion via
+the web Tasks/Timeline tab and the Agent API skipped cache invalidation
+(trello had it, gtasks didn't, in two call sites); `HandleTaskDetailPage`
+hand-duplicated `loadTaskDetailData`'s lookup instead of calling it, so it
+never got the earlier gtasks-detail fix; `PlanToEatAPI.GetRecipes` was
+dead code (own comment: "for Phase 2," never called) — deleted.
+
+Long-term questions surfaced, not decided:
+- Should `GoogleTasksAPI` grow real create/due-date methods (the REST API
+  supports both; the interface just never exposed them)?
+- Should the ~13 copy-pasted `switch source` dispatch blocks collapse into
+  one shared resolver? Not urgent at 3 actionable sources.
+- The ad hoc `findGoogleTask`/`findCard` linear-scan-by-ID lookups are
+  copy-pasted inline in ~5 places instead of reused — style issue at
+  current (personal-scale) data volumes, not a performance one.
+- Read-path caching is already well-unified (generic `CacheFetcher[T]`) —
+  don't over-correct that side, the inconsistency was only ever on
+  write/invalidation.