diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md
index 61121ec..aaf3cbf 100644
--- a/PROJECT_STATE.md
+++ b/PROJECT_STATE.md
@@ -1531,13 +1531,29 @@ Handler — both net-new, not yet built.
     layer, which that test forbids with no allowlist. This change's new files follow the
     same established (if already-violating) pattern to reach real adapters, adding more
     instances of the same pre-existing violation rather than introducing a new kind of one.
-  - **Not done**: not pushed, not deployed to the live RAGcore instance. Per this session's
-    established pattern (test locally -> ask -> deploy -> live-verify), deployment needs
-    explicit approval before proceeding — asked separately.
+  - **Deployed to production** (`http://192.168.10.150:1237` via `ragcore-app-1`),
+    approved by the user. `scp`'d the 4 changed/new files individually to
+    `/mnt/user/appdata/ragcore/app/...`, `docker compose build app`, verified the built
+    image actually contains the new code (`docker run --rm ragcore-app grep`/`test -f`),
+    then `docker compose up -d --no-deps app` (only the `app` service touched). Startup
+    logs are clean (`ragcore_started environment=production`, no errors); `/health/ready`
+    reports `postgres`/`qdrant`/`storage` all `ok`.
+  - **Live-verified the fix itself**: `POST /v1/search` now returns `401
+    AUTHENTICATION_REQUIRED` for an unauthenticated call, not the old permanent `503
+    SEARCH_UNAVAILABLE` — proof the endpoint reaches real request handling instead of
+    hitting an absent application state, which is exactly the bug this closes. Did **not**
+    complete a full authenticated `/v1/answers` call with a real grounded-answer response
+    — the previously-issued "Fleet Ops Knowledge Assistant (production)" credential's raw
+    token was never persisted anywhere retrievable (tokens are shown once at issuance,
+    stored hashed thereafter) and issuing a fresh one requires the RAGcore admin control
+    API's own principal/session, not attempted this round to avoid another live-login
+    detour after the n8n incident above. Next session (or the user) should issue a fresh
+    scoped credential via the RAGcore admin UI and do one real `/v1/answers` call before
+    flipping `KNOWLEDGE_PROVIDER=ragcore`.
   - **Decision on `KNOWLEDGE_PROVIDER=ragcore` in Fleet Ops**: still deliberately `demo`.
-    Wiring the application in the RAGcore repo doesn't help Fleet Ops until it's actually
-    deployed to the live RAGcore instance and live-verified end-to-end; revisit once that
-    deploy happens.
+    RAGcore's application is now deployed and structurally verified, but a full
+    authenticated grounded-answer call hasn't been done yet (see above) — flip only after
+    that final live check.
 
 - **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
@@ -1575,9 +1591,9 @@ 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.
 
-- **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
+- **Exact next action**: (1) RAGcore search/answer wiring (`a2905cc`) is now deployed and
+  structurally verified — issue a fresh scoped credential via the RAGcore admin UI, do one
+  real authenticated `/v1/answers` call, and only then reconsider flipping
   `KNOWLEDGE_PROVIDER=ragcore` in Fleet Ops. (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