Add production rollout tooling and semantic index ops docs

Capture the production plugin rollout workflow and Qdrant validation steps so operations stay repeatable. Also harden redMCP stdio/schema compatibility to keep diverse MCP clients and validators working.

docs/redmineup_local_fork_changelog.md

@@ -32,6 +32,31 @@ environment. Before risky edits, archive the current plugin directories in
   - Run `validate_helpdesk_outbox_worker.py` after outbox or worker changes,
     then choose the external index target.
 
+## 2026-05-06 - Production Plugin Rollout Via Unified Script
+
+- Touched areas:
+  - `plugins/redmine_contacts`
+  - `plugins/redmine_contacts_helpdesk`
+  - `plugins/redmine_event_outbox`
+  - `deploy_redmine_prod_patches.sh`
+- Purpose:
+  - Apply the same plugin payload shape used by test-host post-import automation
+    to production in a controlled, repeatable sequence.
+  - Keep rollback simple by backing up plugin directories before each apply run.
+- Behavior/deployment tooling:
+  - Added and used `deploy_redmine_prod_patches.sh` with one-command dry-run,
+    apply, and rollback modes.
+  - Deployment package assembled as
+    `dist/redmine-prod-plugin-rollout-20260506T210606Z.tar.gz` for upload and
+    unpack on production.
+  - Script-level checks include Ruby syntax checks per plugin, plugin migration,
+    Passenger restart, and optional API verification for
+    `include=journals,helpdesk` behavior.
+- Production result:
+  - Production rollout completed and reported working after deploy.
+  - This confirms the production host now has the local plugin fork updates in
+    place through the scripted deployment path.
+
 ## 2026-04-25 - redMCP Native Search, Filtering, And MCP Operations
 
 - Touched areas:

docs/semantic_index_deployment_runbook.md

@@ -53,6 +53,23 @@ docker run -p 6333:6333 -p 6334:6334 \
 Before destructive maintenance, create a Qdrant snapshot or preserve the Docker
 volume.
 
+## WireGuard Topology
+
+Current WireGuard endpoints:
+
+- production server: `10.11.0.100`
+- LAN server: `10.11.0.105`
+
+When Qdrant is hosted on the LAN server, keep it reachable on the WireGuard
+address and point production semantic-index traffic at:
+
+```sh
+QDRANT_URL=http://10.11.0.105:6333
+```
+
+Do not bind production-hosted Qdrant to `10.11.0.105`; that address belongs to
+the LAN host.
+
 ## Environment
 
 For a production-style install, use:
@@ -68,7 +85,7 @@ target host:
 
 ```sh
 OPENAI_API_KEY=
-QDRANT_URL=http://qdrant-host:6333
+QDRANT_URL=http://10.11.0.105:6333
 QDRANT_API_KEY=
 QDRANT_COLLECTION=redmine_semantic_sample
 REDMINE_URL=http://redmine-host

docs/semantic_index_production_notes.md

@@ -38,6 +38,28 @@ SEMANTIC_INDEX_OVERLAP_MINUTES=15
 Keep `OPENAI_API_KEY`, `QDRANT_URL`, `REDMINE_URL`, and `REDMINE_API_KEY` in the
 existing `.env` workflow or in the service manager environment.
 
+Current WireGuard addressing used by this environment:
+
+- production server: `10.11.0.100`
+- LAN server: `10.11.0.105`
+
+If Qdrant stays on the LAN server, set:
+
+```sh
+QDRANT_URL=http://10.11.0.105:6333
+```
+
+Keep Qdrant bound to the WireGuard/LAN path only and protect it with
+`QDRANT_API_KEY`.
+
+From the production server, run `./validate_qdrant.py` to verify Qdrant liveness,
+readiness, auth, and a minimal create/upsert/read/delete round trip.
+
+```sh
+QDRANT_API_KEY=... ./validate_qdrant.py
+./validate_qdrant.py --skip-write-test
+```
+
 For production-style deployment, use `/opt/semantic-index` for code,
 `/etc/semantic-index.env` for service environment, `/var/lib/semantic-index`
 for refresh state, and `/var/log/semantic-index` for refresh logs. Systemd