Files
NuklearRabbitandClaude Sonnet 5 086dfed992 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>
2026-08-05 22:05:13 +02:00
..

n8n workflows

Canonical, live-validated workflow definitions live under n8n/workflows/. Each file is a cleaned export (secret values replaced by named-credential references, never literal tokens) of the workflow actually running on https://n8n.itworx.tech. See n8n/workflows/MANIFEST.md for the authoritative list: canonical name, purpose, trigger, required credentials, live workflow ID, active status and a checksum of each file.

The two pre-integration starter files that used to live directly under n8n/ (mobilityops-return-processing.json, mobilityops-scheduled-quality-scan.json) have been retired — they predate the live n8n validation pass and embedded the service token as a literal header value instead of a Header Auth credential. Do not resurrect them; the n8n/workflows/ versions are the superseding source of truth and are what deploy/unraid/setup-existing-n8n.sh / setup-scheduled-scan.sh import.

Deploying a workflow from these files into a fresh or existing n8n instance still requires a one-time manual step: create the named Header Auth credentials in the n8n UI (see each workflow's credentials block and the manifest) before publishing. This is deliberate — credential values are never committed to the repository.