docs: /gitfix pass — Morgen rate limit 100→300 sweep + live-probe cost data

Morgen raised the rate ceiling from 100 → 300 points / 15 min on 2026-04-15.
Swept stale references across docs, scripts, and the example env file.

Live probe (2026-04-18) confirmed per-op costs empirically:
- POST /v3/tasks/create = 1 point  (verified: 270→269 single-call delta)
- GET  /v3/tasks/list   = 10 points (verified via list-call deltas)
- GET  /v3/tags         = 10 points (assumed from symmetry; script header)
Previous DESIGN-RATIONALE claim of '10+ points per create' was wrong; now
corrected with an explicit cost-table aligned with the script header.

Also corrected the Morgen endpoint shape in ARCHITECTURE.md — the real
endpoints are /v3/tasks/{create,update,close,list}, not REST-style
/v3/tasks/:id. Morgen exposes close semantics, not delete (there is no
/v3/tasks/delete endpoint — confirmed by 404 during probe cleanup).

Picked up during the audit:
- README Quickstart: add 'source .env' hint so steps 5+6 have MORGEN_API_KEY etc.
- README 'What's in the box': add test-helpers.js, validate-workflows.js, workflows/README.md
- sample-sync-state.json: bump _version 1→2 to clear validator warning
- ARCHITECTURE.md: call out the ratelimit-* response headers (IETF draft-style)

All syntax checks + tests still pass:
- bash -n: 2/2 shell scripts
- node --check: 7/7 JS files
- plutil -lint: plist template ok
- npm test (mock mode): 12/12 scenarios
- npm run test:helpers: 39/39 unit tests
- validate-workflows.js: 3/3 workflow JSONs
- validate-sync-state.js: sample clean

Author: fidgetcoding

README.md

@@ -153,6 +153,9 @@ npm install
 cp examples/sample-.env.example .env
 $EDITOR .env
 
+# 3b. Load .env into the current shell (steps 5 + 6 read these env vars)
+set -a; source .env; set +a
+
 # 4. Install the local daemon (wraps Node in a .app bundle + loads launchd)
 BUNDLE_ID=io.example.task-maxxing-daemon \
 WATCH_PATH="$HOME/path/to/your-vault/08-Tasks" \
@@ -161,10 +164,9 @@ SCRIPT_PATH="$(pwd)/src/auto-commit.js" \
 # Then grant Full Disk Access to the printed .app bundle in System Settings.
 
 # 5. Seed Morgen with your open tasks (one-shot backfill)
-VAULT_PATH="$HOME/path/to/your-vault/08-Tasks" \
-  node scripts/morgen-backfill.js --dry-run       # preview
-VAULT_PATH="$HOME/path/to/your-vault/08-Tasks" \
-  node scripts/morgen-backfill.js                 # live
+#    Reads MORGEN_API_KEY + VAULT_PATH from the .env you sourced in step 3b.
+node scripts/morgen-backfill.js --dry-run       # preview
+node scripts/morgen-backfill.js                 # live
 
 # 6. Import n8n workflows (DRY_RUN=1 to preview)
 ./scripts/install-workflows.sh
@@ -196,6 +198,7 @@ task-maxxing/
 │   │                      launchd template for the daemon
 │   └── README.md          FDA walkthrough + troubleshooting for the daemon
 ├── workflows/
+│   ├── README.md               Import-order notes + placeholder reference
 │   ├── W1-obsidian-git-task-sync.json     n8n export
 │   ├── W2-morgen-task-completion-sync.json
 │   └── W3-notion-done-to-obsidian-sync.json
@@ -204,8 +207,10 @@ task-maxxing/
 ├── scripts/
 │   ├── morgen-backfill.js       One-time tag/ID backfill
 │   ├── sync-e2e-tests.js        End-to-end smoke tests
+│   ├── test-helpers.js          Unit tests for src/sync-helpers.js
 │   ├── install-workflows.sh     Imports workflows via the n8n API
-│   └── validate-sync-state.js   Lints your `.sync-state.json`
+│   ├── validate-sync-state.js   Lints your `.sync-state.json`
+│   └── validate-workflows.js    Lints exported n8n workflow JSON
 └── examples/
     ├── sample-sync-state.json
     ├── sample-TASKS-URGENT.md

docs/ARCHITECTURE.md

@@ -128,8 +128,11 @@ Disk Access, loading the LaunchAgent) see `daemon/README.md`.
 5. Batches operations per service:
    - **Notion:** for each op, calls `POST /v1/pages` (create), `PATCH /v1/pages/:id`
      (update), or `PATCH` with `archived: true` (archive). Throttled to 3 req/s.
-   - **Morgen:** for each op, calls `POST /v3/tasks`, `PATCH /v3/tasks/:id`, or
-     `DELETE /v3/tasks/:id`. Throttled to stay under 100 points / 15 min.
+   - **Morgen:** for each op, calls `POST /v3/tasks/create`, `POST /v3/tasks/update`,
+     or `POST /v3/tasks/close`. (Morgen exposes close semantics, not delete — there
+     is no `/v3/tasks/delete` endpoint.) Throttled to stay well under the 300 points
+     / 15 min Morgen ceiling (raised from 100 on 2026-04-15; cost per op verified
+     via live probe 2026-04-18: create = 1 pt, list = 10 pts).
 6. On success, writes the updated `{notionPageId, morgenTaskId, morgenEtag, lastSyncedAt, lastSyncedHash}`
    fields back into `.sync-state.json` via a GitHub contents API commit (with a
    `[bot:W1]` commit prefix so the daemon and W1 don't echo-loop).
@@ -431,8 +434,8 @@ This keeps us under:
 
 - Notion's 3 req/s rate limit (100 ops at 3 req/s ≈ 34s, well inside the 60s workflow
   timeout).
-- Morgen's 100 points / 15 min rate limit (100 ops × 1 point ≈ exactly at the cap —
-  which is why creates/updates are the only ops we batch).
+- Morgen's 300 points / 15 min rate limit (100 ops × 1 point ≈ one-third of the cap —
+  comfortable headroom since Morgen raised the ceiling from 100 to 300 on 2026-04-15).
 
 ### 2. Flip ratio guard
 
@@ -493,11 +496,14 @@ W1 writing.
 
 Morgen's API is functional but has sharp edges worth knowing about.
 
-### Rate limit: 100 points / 15 min
+### Rate limit: 300 points / 15 min (raised from 100 on 2026-04-15)
 
-Morgen uses a point-based rate limit. Most ops are 1 point; a couple of bulk
-endpoints are more. task-maxxing treats everything as 1 point and stays under 100
-ops per 15-min window.
+Morgen uses a point-based rate limit. Observed costs (verified via live probe
+2026-04-18): `/v3/tasks/create` = 1 pt, `/v3/tasks/list` = 10 pts, `/v3/tags` = 10 pts.
+Responses expose `ratelimit-limit`, `ratelimit-remaining`, and `ratelimit-reset`
+headers (lowercase, IETF draft-style) you can poll to stay honest. task-maxxing
+throttles W1 to ~100 ops per 15-min window — leaving ~200pt headroom against the
+300pt ceiling for parallel callers and Morgen's own background tasks.
 
 ### Task-to-calendar API is unavailable
 

docs/DESIGN-RATIONALE.md

@@ -664,16 +664,18 @@ still marked done) because the replay flows through Obsidian.
 "it's safe under pathological inputs." Here are the rails that exist to
 keep pathological runs from wrecking state.
 
-### 9.1 Morgen rate budget (100 points / 15 min)
+### 9.1 Morgen rate budget (300 points / 15 min, raised from 100 on 2026-04-15)
 
-Hard-coded into W1 and W2. If a sync run would spend more than 100
-Morgen points, it stops at 100 and lets the next run pick up the
-remainder. The rationale: better a slow sync than a throttled sync
-that leaves state half-written.
+W1 and W2 throttle to ~100 ops per 15-min window — set when Morgen's
+cap was 100 and kept as-is now that the cap is 300. The rationale:
+leave room for other callers (the Morgen app, other automations) so a
+busy sync run doesn't starve everything else. Better a conservative
+throttle than a hostile neighbor.
 
 This is why `morgen-backfill.js` exists as a separate script —
-bootstrapping an existing 200-task vault takes several 15-min windows
-and is worth doing explicitly, outside the W1 hot path.
+bootstrapping an existing 200+ task vault still takes multiple 15-min
+windows under the conservative throttle, and is worth doing explicitly,
+outside the W1 hot path.
 
 ### 9.2 Flip-ratio guard (30% max)
 
@@ -733,18 +735,34 @@ Every integration is a love letter to the API it integrates against.
 Here are the specific Morgen quirks that forced architectural
 decisions.
 
-### 10.1 Rate limit: 100 points / 15 min, variable cost per op
+### 10.1 Rate limit: 300 points / 15 min (raised from 100 on 2026-04-15), variable cost per op
 
-Creates are expensive (10+ points each). Lists are cheap (1 point).
-Updates are medium. The budget is on the aggregate, not per-endpoint.
+Per-op cost table, verified via live API probe on 2026-04-18:
+
+| Endpoint               | Cost    | Notes                                          |
+|------------------------|---------|------------------------------------------------|
+| `POST /v3/tasks/create`| **1 pt**| Confirmed by single-call remaining delta (270→269). |
+| `POST /v3/tasks/update`| 1 pt    | Assumed 1 pt per the `morgen-backfill.js` header table. |
+| `POST /v3/tasks/close` | 1 pt    | Assumed 1 pt (completion; also used for W2 write-back). |
+| `GET  /v3/tasks/list`  | 10 pts  | Confirmed by list-call deltas during probe. Expensive — cache.  |
+| `GET  /v3/tags`        | 10 pts  | Ditto — cache aggressively.                    |
+| `POST /v3/tags/create` | 1 pt    | From script header table.                       |
+
+The budget is on the aggregate, not per-endpoint. Morgen exposes **close**
+semantics, not delete — there is no `/v3/tasks/delete` endpoint.
 
 Consequences:
 
-- W1's Morgen branch calls `list_tasks` first (cheap), diffs against
-  sync-state, and only writes deltas.
-- W2 polls via `list_tasks` (1 point) and only writes on state change.
-- Backfill is a separate script because 200 creates × 10 points = 2000
-  points, which is five full 15-min windows.
+- W1's Morgen branch calls `list_tasks` first (10 pts, not 1 — caches the
+  result across the run), diffs against sync-state, and only writes deltas.
+- W2 polls via `list_tasks` (10 pts) on its 60s cron and only writes on
+  state change. The 10-pt list is the fixed cost of every W2 tick.
+- Backfill is still a separate script: at 1 pt per create, a 200-task vault
+  fits inside a single 15-min window at the 300pt ceiling (200 creates +
+  1 list ≈ 210 pts), but anything larger (or combined with other Morgen
+  callers sharing the window) spills into a second window. The script's
+  `--max-points 85` default keeps it conservative and friendly to parallel
+  callers (the Morgen app itself, other automations).
 
 ### 10.2 No task-to-calendar linking via API
 

docs/SETUP.md

@@ -510,8 +510,8 @@ This will:
    ```
 
 **Expected runtime:** 30–90 seconds for a typical backlog of <80 tasks. The
-100 pts / 15 min ceiling is the upper bound — the default `--max-points 85` leaves
-headroom.
+300 pts / 15 min ceiling (raised from 100 on 2026-04-15) is the upper bound — the
+default `--max-points 85` leaves generous headroom.
 
 **Budget abort?** If the projected cost exceeds `--max-points`, the script exits 2
 with a suggested batch size. Split the backfill into batches (wait 15 min between)

docs/TROUBLESHOOTING.md

@@ -104,19 +104,20 @@ Morgen API: 429 Too Many Requests
 or the Morgen backfill script exits with:
 
 ```
-[ERROR] Rate limit exceeded: 100 points / 15 min
+[ERROR] Rate limit exceeded: 300 points / 15 min
 ```
 
 **Cause**
 
-Morgen's rate limit is 100 points per 15-minute rolling window. Creates, updates,
-and deletes are 1 point each. Hitting 100 in one W1 run means you had >100 Morgen
-ops queued.
+Morgen's rate limit is 300 points per 15-minute rolling window (raised from 100 on
+2026-04-15). Creates, updates, and deletes are 1 point each. Hitting 300 in one W1
+run means you had >300 Morgen ops queued.
 
 **Diagnostic**
 
 Look at the n8n execution log for W1. Count the number of Morgen ops. If you're near
-100, you're hitting the budget. If you're near 200, you're doing a full backfill.
+300, you're hitting the budget. Near 500+, you're doing a full backfill — use
+`morgen-backfill.js` for those instead of letting W1 handle it.
 
 **Fix**
 

examples/sample-.env.example

@@ -62,7 +62,7 @@ NOTION_DATABASE_ID=00000000-0000-0000-0000-000000000000
 # ---------------------------------------------------------------------------
 
 # Morgen API key from https://app.morgen.so/settings/api
-# Used as `Authorization: ApiKey <key>`. Rate limit: 100 pts / 15 min.
+# Used as `Authorization: ApiKey <key>`. Rate limit: 300 pts / 15 min.
 MORGEN_API_KEY=replace_me
 
 # Alias read by workflows/install-workflows.sh (same value).

examples/sample-sync-state.json

@@ -1,5 +1,5 @@
 {
-  "_version": 1,
+  "_version": 2,
   "_tagCache": {
     "01 URGENT": "11111111-1111-1111-1111-111111111111",
     "02 GENERAL": "22222222-2222-2222-2222-222222222222",

scripts/morgen-backfill.js

@@ -33,11 +33,14 @@
  *   1  runtime / API error
  *   2  budget-abort (would exceed --max-points)
  *
- * Rate limit (hard): 100 pts / 15 min sliding window, shared account-wide.
+ * Rate limit (hard): 300 pts / 15 min sliding window, shared account-wide
+ * (Morgen raised this from 100 → 300 on 2026-04-15).
  *   tags/list   = 10 pts
  *   tags/create = 1 pt
  *   tasks/create= 1 pt
- * Default --max-points 85 leaves a 15pt buffer for other callers in-window.
+ * Default --max-points 85 is conservative — leaves ~215pt headroom for
+ * other callers in-window. You can safely raise it to ~280 if you know
+ * nothing else is hammering Morgen during the backfill.
  *
  * NOTE: This script does NOT commit .sync-state.json. It writes the file
  * to disk only. Review the diff and commit manually when ready.

scripts/sync-e2e-tests.js

@@ -243,7 +243,7 @@ function simulateW1({ vaultDir, stateFile, notion, morgen }) {
   // 2. Diff vs state
   const newTasks = allTasks.filter((t) => !state.entries[t.hash]);
 
-  // 3. Morgen rate budget (100pt / 15min window, reserve 85 for W1)
+  // 3. Morgen rate budget (300pt / 15min window as of 2026-04-15, reserve 85 for W1)
   //    Formula per task: ~2 pts (tag work included). Plus 10 for tags/list.
   const projectedCost = 10 + newTasks.length * 2;
   if (projectedCost > 85) {