Files

T

NuklearRabbitandClaude Sonnet 5 e0c107a94a n8n: store cleaned workflow definitions as repo source of truth

Move the two live-validated workflows into n8n/workflows/ (credential-
based auth referenced by name only, no secret values), add a manifest
covering all 4 canonical workflows and a read-only drift-check script
against n8n's Public API. Retire the pre-integration root-level starter
files that still carried the literal-token pattern, and repoint the
Unraid deploy scripts, Makefile targets and runbook at the new files.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-08-04 13:34:51 +02:00

3.2 KiB

Raw Permalink Blame History

n8n integration

Role

n8n orchestrates secondary cross-system work after MobilityOps commits canonical state. It is not the domain engine.

Required live workflow: return processing

Input: vehicle.returned.v1 webhook event.

Steps:

validate event type and schema;
derive a follow-up category from the already-calculated state;
call the narrow MobilityOps callback endpoint with event ID and follow-up summary;
return a stable workflow result;
on errors, fail visibly so the outbox dispatcher can retry.

The canonical, live-validated definition is n8n/workflows/fleet-ops-vehicle-return.json (see n8n/workflows/MANIFEST.md); it authenticates via named Header Auth credentials rather than a literal token, per the live-hardening pass documented in docs/live-ai-integration/n8n-current-state.md.

Second live workflow: scheduled quality scan

RAGcore is not connected in this environment, so the originally sketched "knowledge sync" workflow below remains deferred (see "Deferred: knowledge sync"). The second implemented workflow does not depend on RAGcore or MCP Hub, so it is not blocked by them.

Input: hourly schedule trigger, or a manual trigger for on-demand testing.

Steps:

call the narrow, service-token-protected POST /api/v1/integrations/n8n/scheduled-scan endpoint;
the endpoint runs the same deterministic run_scan() domain function the manual "Run quality scan" UI action uses, and records a data_quality_scan_run audit event with actor_type=service;
return counts of newly created issues per rule type.

run_scan() only ever creates an issue for a condition that does not already have one open, so a duplicate or overlapping trigger (a manual test run firing close to the scheduled one, or a retried HTTP call) does no duplicate domain work.

The canonical, live-validated definition is n8n/workflows/fleet-ops-data-quality-scan.json (see n8n/workflows/MANIFEST.md), imported and published the same way as the return workflow (see deploy/unraid/setup-scheduled-scan.sh and docs/17-runbook.md). It is active on the live instance; a fresh import ships inactive until credentials are wired up and it is deliberately published.

RAGcore procedure sync (in progress)

RAGcore is now reachable in this environment; a live inspection of its real contract is recorded in docs/live-ai-integration/n8n-current-state.md. Workflow 3, "Fleet Ops — RAGcore Procedure Sync", is being built against that real contract (not the sketch originally in this section) — see n8n/workflows/MANIFEST.md for current status.

Workflow error handler (in progress)

Workflow 4, "Fleet Ops — Workflow Error Handler", is a central technical workflow attached to workflows 1-3 via n8n's per-workflow "Error Workflow" setting, reporting bounded, secret-free failure details to Fleet Ops. See n8n/workflows/MANIFEST.md for status.

Outbox dispatcher

polls pending records;
claims with FOR UPDATE SKIP LOCKED or equivalent;
sends event with timeout;
exponential backoff with a small maximum attempt count;
supports explicit manual retry;
preserves last error and response metadata;
does not hold a database transaction open during network I/O.

3.2 KiB Raw Permalink Blame History