diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md
index 933f3d8..61121ec 100644
--- a/PROJECT_STATE.md
+++ b/PROJECT_STATE.md
@@ -1539,12 +1539,51 @@ Handler — both net-new, not yet built.
     deployed to the live RAGcore instance and live-verified end-to-end; revisit once that
     deploy happens.
 
+- **n8n workflow 3 (task #86) — incident, recovered; final 2 nodes still blocked on a
+  live n8n auth problem, not a code problem.** Returning to finish the "Summarize sync
+  result" + report-to-Fleet-Ops nodes found the live "Fleet Ops — RAGcore Procedure Sync"
+  workflow's canvas at **zero nodes** — the earlier session's abandoned attempt to call
+  n8n's REST API directly (the "unexplained 401" noted above) had gone through far enough
+  to wipe the live workflow before the 401 stopped it, leaving an empty, unsaved "Current
+  changes" draft on top of the last good save.
+  - **Recovered**: n8n's own Version History (`/workflow/.../history`) still had the last
+    good save, version `260b38b5` (Aug 4, 21:08), with all 4 real nodes intact (Schedule
+    Trigger -> List procedures -> Prepare uploads -> Upload to RAGcore) plus the build
+    sticky note. Used the history panel's own **Restore version** action (not a manual
+    rebuild) to bring the live workflow back to that exact state. Confirmed via the page's
+    DOM (`[data-test-id="canvas-node"]` count) both before (0) and after (4) — the canvas
+    itself render fully off-screen (nodes positioned at negative Y coordinates, a separate
+    display-only vue-flow pan bug worked around by directly setting the transform pane's
+    CSS transform; harmless, doesn't touch saved data).
+  - **Then blocked again attempting the 2 new nodes**: adding a Code node via the UI's own
+    "What happens next?" panel (a real, first-party n8n interaction, not the REST API)
+    immediately surfaced n8n's own autosave toast: **"Problem saving workflow — Autosave
+    failed: Unauthorized."** A full sign-out/sign-in cycle right before this (fresh
+    credentials, fresh page load) did not fix it — immediately after a successful
+    interactive "Sign in", `fetch('/rest/workflows/...')` from that same authenticated tab
+    still returned 401. This is not the ordinary "your session expired, log in again"
+    friction seen earlier in the session; it's the live n8n instance's own save path
+    rejecting a request made moments after a successful login, which is exactly the
+    failure mode that caused the wipe above. Continuing to add nodes under this condition
+    risks losing work again with no guarantee the next failure is as recoverable, so this
+    was stopped deliberately rather than retried. The workflow was left in its safely
+    restored, 4-node, unpublished state — verified via the DOM node count immediately
+    before closing the session — nothing was added or changed beyond the restore.
+  - **Not a code/workflow-design problem**: the 2 remaining nodes (a Code node
+    summarizing the sync result, and an HTTP node reporting to Fleet Ops's already-live
+    `POST /api/v1/integrations/n8n/procedures-sync-result`) were never built — this
+    blocked before any node configuration happened. The design itself (mirroring WF2/WF4's
+    existing report-result pattern) is unchanged from earlier planning.
+
 - **Exact next action**: (1) decide on deploying the RAGcore search/answer wiring
   (`a2905cc`) to the live RAGcore instance — asked, awaiting approval; once deployed,
   live-verify a real `/v1/answers` call and reconsider flipping
   `KNOWLEDGE_PROVIDER=ragcore` in Fleet Ops. (2) task #86's remaining n8n pieces (Summarize
-  + report-result node, publish) is the only open item from the earlier RAGcore/n8n work —
-  last attempt hit an unexplained 401 calling n8n's REST API directly and was abandoned to
-  prioritize task #96; needs a fresh approach. (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.
+  + 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.