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>

docs/11-n8n-integration.md

@@ -16,7 +16,7 @@ Steps:
 4. return a stable workflow result;
 5. on errors, fail visibly so the outbox dispatcher can retry.
 
-The starter export is `n8n/mobilityops-return-processing.json`. Claude may correct its credentials and callback route but must preserve idempotency.
+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
 
@@ -39,24 +39,24 @@ Steps:
 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 starter export is `n8n/mobilityops-scheduled-quality-scan.json`, imported and
-published the same way as the return-processing workflow (see
-`deploy/unraid/setup-scheduled-scan.sh` and `docs/17-runbook.md`). It ships with
-`"active": false` so it cannot fire against any environment until deliberately
-published with a real service token.
+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.
 
-## Deferred: knowledge sync
+## RAGcore procedure sync (in progress)
 
-Input: manual trigger or manifest-changed event.
+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.
 
-Steps:
+## Workflow error handler (in progress)
 
-1. read the fixed knowledge manifest;
-2. call RAGcore ingestion/sync API;
-3. record per-document results through MobilityOps integration status API.
-
-Deferred until RAGcore's live ingestion API is available in this environment; must not
-delay or block the core demo.
+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
 

docs/17-runbook.md

@@ -48,7 +48,7 @@ longer gates this. This is a one-time step per fresh `docker compose down -v`:
    which runs:
 
    ```bash
-   docker compose exec n8n n8n import:workflow --input=//imports/mobilityops-return-processing.json
+   docker compose exec n8n n8n import:workflow --input=//imports/workflows/fleet-ops-vehicle-return.json
    docker compose exec n8n n8n publish:workflow --id=mobilityops-return-processing
    docker compose restart n8n
    ```
@@ -56,6 +56,12 @@ longer gates this. This is a one-time step per fresh `docker compose down -v`:
    (`n8n import:workflow` always leaves the workflow deactivated regardless of its
    `"active"` field; `publish:workflow` + a restart is what actually activates it.)
 
+   Before it will actually process a return, create two Header Auth credentials in the n8n
+   UI — `Fleet Ops Webhook Trigger Token` (value: `MOBILITYOPS_WEBHOOK_TRIGGER_TOKEN` from
+   `.env`) and `Fleet Ops Service Token` (value: `MOBILITYOPS_CALLBACK_TOKEN` from `.env`) —
+   the workflow's webhook trigger and outbound HTTP call reference these credentials by
+   name; no secret value is embedded in the workflow file itself.
+
 Verify the full round trip:
 
 ```bash
@@ -77,11 +83,14 @@ make n8n-setup-scan
 which runs:
 
 ```bash
-docker compose exec n8n n8n import:workflow --input=//imports/mobilityops-scheduled-quality-scan.json
+docker compose exec n8n n8n import:workflow --input=//imports/workflows/fleet-ops-data-quality-scan.json
 docker compose exec n8n n8n publish:workflow --id=mobilityops-scheduled-quality-scan
 docker compose restart n8n
 ```
 
+This workflow also needs the `Fleet Ops Service Token` Header Auth credential created in
+the n8n UI before a run will succeed.
+
 Verify:
 
 ```bash