diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md
index bfc253d..3060a5b 100644
--- a/PROJECT_STATE.md
+++ b/PROJECT_STATE.md
@@ -1608,18 +1608,61 @@ Handler — both net-new, not yet built.
     blocked before any node configuration happened. The design itself (mirroring WF2/WF4's
     existing report-result pattern) is unchanged from earlier planning.
 
+- **n8n workflow 3 — root cause found and fixed; both remaining nodes now built and
+  saved.** The user pushed back on the "auth problem" framing (n8n visibly showed signed
+  in), which was the right call — dug into the live n8n container's own logs
+  (`docker logs n8n`) rather than continuing to guess from the browser side, and found the
+  real cause: `browserId check failed on /rest/workflows/:workflowId`, alongside an
+  express-rate-limit warning about `X-Forwarded-For` being present while Express `trust
+  proxy` is `false`. n8n's Unraid template
+  (`/boot/config/plugins/dockerMan/templates-user/my-n8n.xml`) had `N8N_PROXY_HOPS=0`
+  despite genuinely running behind the TLS-terminating reverse proxy at
+  `n8n.itworx.tech` — with proxy trust disabled, n8n couldn't correctly resolve the
+  request as HTTPS, which broke its CSRF-style browserId cookie check on every
+  workflow-mutating REST call (autosave, but not plain page loads, which explains why the
+  UI looked fully logged in the whole time).
+  - **Fix, approved by the user beforehand** (shared instance, brief restart): backed up
+    the template to a timestamped `.bak`, changed `N8N_PROXY_HOPS` `0` -> `1`, then
+    recreated the `n8n` container on the Unraid host (stop, rename to
+    `n8n_pre_proxyhops_fix` as an instant rollback, `docker run` with every existing env
+    var/volume/port/label preserved exactly plus the one corrected value). All 3
+    previously-active workflows (Vehicle Return Orchestration, Scheduled Data Quality
+    Scan, Workflow Error Handler) re-activated cleanly on the new container — nothing
+    lost. Verified the fix by reproducing the exact save action that used to fail
+    (adding a node via n8n's own UI): no more "Unauthorized" toast, and the added node
+    survived a full page reload. `docker logs n8n` shows zero `browserId`/401 entries
+    since the fix.
+  - **Mid-fix-verification, a real node got deleted by an errant `Ctrl+A`** (browser
+    focus landed on the canvas instead of a text field during cleanup, selecting and then
+    deleting the "List procedures" node). Caught it via a node-count check, used n8n's own
+    Version History **Restore version** to the last good save (not a manual rebuild), then
+    redid the 2 new nodes carefully (verifying focus before every `Ctrl+A` this time). No
+    data lost, just redone.
+  - **Built**: `Summarize sync result` (Code node, JS) — counts `synced`/`failed` from
+    `$input.all()` by checking each item's `json.error` (matches "Upload to RAGcore"'s own
+    `On Error: Continue` setting, confirmed by inspecting that node's Settings tab, so
+    failed uploads land in the same output stream with an `error` field rather than a
+    separate branch). `Report sync result to Fleet Ops` (HTTP Request, POST) — targets the
+    already-live `/api/v1/integrations/n8n/procedures-sync-result`, reusing the existing
+    "Fleet Ops Service Token" Header Auth credential (same one WF4 already uses against
+    this same backend), JSON body `{execution_id, synced, failed}` matching
+    `ProcedureSyncResultIn` exactly.
+  - **Saved, not published.** All 6 nodes (Schedule Trigger -> List procedures -> Prepare
+    uploads -> Upload to RAGcore -> Summarize sync result -> Report sync result to Fleet
+    Ops) confirmed present after a full page reload. The Schedule Trigger is configured
+    for once daily at midnight -- publishing activates real, live, unattended runs against
+    production RAGcore and Fleet Ops, so this was deliberately left for a separate,
+    explicit approval rather than done automatically.
+
 - **Exact next action**: (1) RAGcore search/answer wiring (`a2905cc`) is deployed and
   proven correctly wired (matches Query Lab's trusted behavior exactly) — the open item is
   now root-causing why `Fleet Ops Procedures` returns zero dense/sparse candidates for
   real questions despite having genuinely matching, correctly-scoped, correctly-embedded
   indexed content (see evidence above); this is retrieval/data, not application wiring.
   Only flip `KNOWLEDGE_PROVIDER=ragcore` once that's fixed and a real grounded answer comes
-  back. (2) task #86's remaining n8n pieces (Summarize
-  + report-result node, publish) need the live n8n instance's save/auth problem fixed
-  first — this looks like an n8n-instance-side issue (session/auth backend rejecting
-  mutating requests moments after a successful login), not something fixable from the
-  browser automation side; needs either the user's own direct n8n session or an infra
-  look at the n8n deployment before any further automated editing is attempted. (3) MCP
-  Hub: registry push + production deployment of the now-committed connector remain
-  separate, explicitly-gated checkpoints. WF4's own timeout/retry gap remains open,
-  deferred, non-blocking.
+  back. (2) n8n workflow 3 is fully built and saved (all 6 nodes) but **not published** —
+  decide whether to publish it (starts real daily runs against production) and, once
+  live-verified end to end, add its file to `n8n/workflows/` and `MANIFEST.md` as the
+  source of truth alongside the other 3 workflows. (3) MCP Hub: registry push + production
+  deployment of the now-committed connector remain separate, explicitly-gated checkpoints.
+  WF4's own timeout/retry gap remains open, deferred, non-blocking.