fix: publish RAGcore Procedure Sync and derive its evidence for real

MCP_HUB_BASE_URL had the same wrong-hostname bug as RAGCORE_BASE_URL earlier
this session (itworx-mcp-hub:8000 doesn't resolve; the real container is
reachable at the host's own 192.168.10.150:1100) -- fixed live, resolving the
Automation page showing "Operationeel" and "Hub Onbereikbaar" simultaneously.

Went on to actually publish the "Fleet Ops -- RAGcore Procedure Sync" n8n
workflow now that RAGcore is reachable: its own RAGcore Sync Token credential
had gone stale from the same rotation as the earlier one, so minted a fresh,
dedicated, minimally-scoped (sources:sync only) credential, verified a real
manual run (33 synced, 0 failed, result registered) before publishing.

That exposed a real, now-stale bug: derive_n8n_status() hardcoded this
workflow's evidence to None with a comment explaining it was unpublished --
true when written, false now. The workflow's own result-report callback
already writes a real n8n_procedures_synced audit event; wired that in as its
evidence source, the same pattern the scheduled scan and error handler already
use, instead of a value that could never update itself once the workflow went
live.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
NuklearRabbit
2026-08-05 22:05:13 +02:00
co-authored by Claude Sonnet 5
parent 64cc96fa4b
commit 086dfed992
4 changed files with 32 additions and 10 deletions
+10 -5
View File
@@ -38,10 +38,15 @@ credential values are never embedded; nodes reference named n8n credentials inst
## 3. Fleet Ops — RAGcore Procedure Sync
Fully built and saved live (6 real nodes: Schedule Trigger → List procedures → Prepare
uploads → Upload to RAGcore → Summarize sync result → Report sync result to Fleet Ops),
but **deliberately not published/active** — the Schedule Trigger runs daily at midnight,
so activating it starts real, unattended runs against production RAGcore and Fleet Ops;
that is a separate, explicit go-live decision, not something to flip silently.
uploads → Upload to RAGcore → Summarize sync result → Report sync result to Fleet Ops).
**Published/active as of 2026-08-05**, once RAGcore itself went live (see
`PROJECT_STATE.md`'s "RAGcore actually went live" entry): the workflow's `RAGcore Sync
Token` credential had also gone stale from the same credential rotation, so a fresh,
dedicated, minimally-scoped (`sources:sync` only) credential was minted before
publishing. Verified with a real manual execution first — 33 procedures synced, 0
failed, Fleet Ops registered the result (`execution_id` 159) — before flipping it to
run unattended on its daily schedule.
While validating this workflow (2026-08-05), found and fixed a real defect: the "Report
sync result to Fleet Ops" node's three body-parameter expressions each had a stray
@@ -62,7 +67,7 @@ the same way via the same CLI import path, re-verified.
| Event contract | N/A — HTTP-triggered sync. Reads `GET /api/v1/integrations/n8n/procedures`, uploads via RAGcore's `POST /v1/uploads`, reports via `POST /api/v1/integrations/n8n/procedures-sync-result`. |
| Required credentials | `Fleet Ops Service Token` (Header Auth, on the procedures-list and result-report calls); `RAGcore Sync Token` (Header Auth, `sources:sync` scope, on the upload call) |
| Live workflow ID | `6wbkc4d1AouGpmWT` |
| Active status (as of 2026-08-05) | Built / Saved / **Inactive** (not published — daily unattended runs require a separate explicit go-live decision) |
| Active status (as of 2026-08-05) | **Active / Published** |
| Error Workflow | `Fleet Ops — Workflow Error Handler` (wired) |
| Checksum (sha256) | `643c0515a50fed3d35e28f0b8cb17841f6f8d91699944980b5c56e619d5bf2a6` |