@agentikos/omega-os 0.2.0 → 0.19.6

package/omega/Agentik_SSOT/skills/dataaudit/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: dataaudit
+description: Forensic data audit — Is the data TRUTHFUL — every reference valid, every type correct, every transaction whole?. Runs the gather (deterministic) + falsify (agentic) pipeline, batches fixes, dispatches capped workers, re-audits, and persists scores. Use when the user says "/dataaudit", "audit data", or asks to verify the data health of the project.
+when_to_use: User says /dataaudit, audit data, check data, verify data, is data healthy.
+argument-hint: "[--scope <path>] [--fix] [--max-workers N]"
+arguments: [args]
+allowed-tools: Bash Read Edit Grep Glob Write
+---
+
+# dataaudit — forensic audit (Agentik OS Quality Arsenal)
+
+> Is the data TRUTHFUL — every reference valid, every type correct, every transaction whole?
+
+You are running the dataaudit forensic audit. Apply the **Gestalt-Popper
+doctrine**: identify the hinge point, scrutinise it 10x, then assume
+every name is a CLAIM and look for the divergence between the claim and
+the reality. Bias toward FAIL. A perfect score is earned by finding zero
+falsifiable claims, never by absence of effort.
+
+## Run
+
+The audit is one engine call — gather (deterministic) + falsify (agentic)
++ optional fix-dispatch (capped) + re-audit. Invoke the unified pipeline:
+
+```bash
+omega audit run dataaudit $args
+```
+
+Common options:
+
+| Flag | Effect |
+|---|---|
+| `--scope <path>` | scope the audit (file or directory) |
+| `--fix` | after analysing, batch findings + dispatch up to N workers + re-audit |
+| `--max-workers N` | cap parallel fix workers (default 3) |
+| `--min-severity high` | only batch + fix findings at or above this severity |
+
+Read-only by default. Add `--fix` to enable the dispatch + re-audit loop.
+
+## Phases under investigation
+
+The agentic pass walks each phase below and emits structured findings
+(claim vs. reality). Every PASS must cite ≥3 concrete checks.
+
+### 1. schema-validation
+
+Schema definitions match the TypeScript/Python types and the columns the code references; NOT NULL / UNIQUE / CHECK / DEFAULT constraints present where business logic demands; consistent naming; enums in schema match enums in code.
+
+### 2. migration-status
+
+All migrations applied in order, none pending/failed/stuck; new columns backfilled for existing rows; renamed columns migrated; destructive migrations have a rollback path and were batched for large tables.
+
+### 3. hinge-orphaned-records
+
+HINGE — for every foreign key/reference run the LEFT JOIN where the referenced row is NULL; count orphans, date when they appeared, find root cause (missing cascade, race, bug); include file/storage refs pointing to nothing and soft-delete orphans.
+
+### 4. hinge-referential-integrity
+
+HINGE — FK constraints enforced at DB level not just app; cross-table aggregates match details (order_total = SUM(items)); temporal sanity (created_at <= updated_at, child not before parent); every business invariant holds in actual data.
+
+### 5. type-safety
+
+Runtime values match declared types — string columns holding JSON/numbers, number columns holding strings, booleans as 0/1, dates as strings; Convex v.* validators and v.optional() match reality; coercion risks (string sort on numeric column).
+
+### 6. null-handling
+
+Null percentage per column; required fields containing nulls; nullable fields that should be required; consistent null semantics (not-set vs N/A vs unknown); empty-string-vs-null and 0-vs-null picked consistently; null behaviour in aggregates and joins.
+
+### 7. data-consistency
+
+Denormalised/cached values match source of truth (full_name vs first+last, post_count vs COUNT); cross-service data matches (auth provider, payment provider, search index); enum values current, no deprecated values lingering; format consistency.
+
+### 8. duplicate-detection
+
+Exact duplicates (same entity, different IDs), near-duplicates (casing/formatting differences in email/phone); unique indexes on natural keys; idempotency keys on writes; a defined merge strategy when duplicates exist.
+
+### 9. cascade-behavior
+
+Parent deletion cascades correctly without creating orphans and without cascading too broadly; status/key changes propagate; RESTRICT/SET NULL/SET DEFAULT chosen deliberately per relationship; soft-delete cascade respected.
+
+### 10. transaction-integrity
+
+Multi-step operations (payment+order, user+profile) wrapped in transactions; optimistic locking prevents lost updates; counter increments and inventory decrements atomic; failed transactions fully rolled back; webhook/import handlers idempotent.
+
+### 11. index-and-query
+
+Columns in WHERE/JOIN/ORDER BY and all FK columns indexed; no unused or duplicate indexes; composite index column order matches query patterns; full table scans and N+1 query patterns identified.
+
+### 12. pii-lifecycle-backup
+
+Inventory every PII column; PII encrypted at rest and masked in non-prod, not leaking into logs/errors/search indexes; TTL on sessions/tokens/logs; retention policy and GDPR right-to-deletion implemented; automated backups exist and a restore was actually tested.
+
+### 13. seed-data-separation
+
+No seed/test data in production (test@example.com accounts, Lorem ipsum, default passwords); production data absent from dev DBs or anonymised; no production credentials in test fixtures.
+
+## Falsification rules
+
+"No errors in production" means nobody counted. Every PASS must cite >=3 concrete queries run (the orphan LEFT JOIN with row count, the invariant check, the type cast attempt) with verbatim output — never assume integrity. Categorise findings as SCHEMA-vs-REALITY, REFERENCE-vs-EXISTENCE, TYPE-vs-VALUE, MIGRATION-vs-STATE or DEV-vs-PROD. A reported orphan must be verified: confirm the FK was meant to cascade or that an actual user action deleted the parent. Any data-mutating fix MUST snapshot the DB first; restore on any post-fix check failure. Bias toward FAIL — data loss is permanent.
+
+## After the run
+
+The pipeline writes one structured verdict to:
+
+```
+Agentik_Runtime/audits.db    (history — `omega audit history dataaudit`)
+Agentik_Runtime/sessions/${CLAUDE_SESSION_ID}/.done.json   (this turn)
+```
+
+The `.done.json` schema:
+
+```json
+{
+  "status": "done_clean" | "pending" | "failed",
+  "summary": "<one-paragraph verdict>",
+  "artifacts": {
+    "audit": "dataaudit",
+    "score": 0-100,
+    "verified": bool,
+    "findings": [...],
+    "fix_plan": [...],
+    "dispatches": [...],
+    "reaudit_score": 0-100  // only when --fix was used
+  }
+}
+```
+
+## Hard rules (don't break these)
+
+1. **No fake "done".** First Law: only runtime tells the truth. If the
+   gather phase fails or the agentic verdict scores below the threshold,
+   you have NOT verified — set status to `pending` or `failed`.
+2. **Cap parallelism.** ≤ 3 fix workers at a time. The
+   batcher enforces this; do not call out to other dispatch mechanisms.
+3. **No worker per finding.** Findings are clustered by file footprint and
+   severity. One worker handles one disjoint batch.
+4. **Re-audit confirms.** After fixes land, the pipeline re-runs the same
+   gather + agentic phases. If the score did not improve, escalate honestly.
+5. **History is the trend.** `omega audit history dataaudit` shows whether the
+   codebase is improving over time on this dimension. Use it to decide
+   whether to push for `--fix` again.
+
+## Why this audit exists
+
+The 18 forensic audits are the OmegaOS verification layer. Claude's
+"I'm done" claims used to be unverified. With these audits running as
+the gate, completion is **derived from observable facts**, not declared
+by the worker. Run this audit any time someone (human or agent) claims
+the data dimension is healthy. Insist on the score before you
+accept.
+
+## Reference
+
+Audit definition: `Agentik_SSOT/audits/dataaudit.yaml`
+Engine pipeline:  `omega_engine.audits.pipeline.AuditPipeline`
+Batcher:          `omega_engine.audits.batcher.batch_findings`
+History:          `omega_engine.audits.history`

package/omega/Agentik_SSOT/skills/debugaudit/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: debugaudit
+description: Forensic runtime audit — What is already BROKEN right now — and nobody noticed because it failed silently?. Runs the gather (deterministic) + falsify (agentic) pipeline, batches fixes, dispatches capped workers, re-audits, and persists scores. Use when the user says "/debugaudit", "audit runtime", or asks to verify the runtime health of the project.
+when_to_use: User says /debugaudit, audit runtime, check runtime, verify runtime, is runtime healthy.
+argument-hint: "[--scope <path>] [--fix] [--max-workers N]"
+arguments: [args]
+allowed-tools: Bash Read Edit Grep Glob Write
+---
+
+# debugaudit — forensic audit (Agentik OS Quality Arsenal)
+
+> What is already BROKEN right now — and nobody noticed because it failed silently?
+
+You are running the debugaudit forensic audit. Apply the **Gestalt-Popper
+doctrine**: identify the hinge point, scrutinise it 10x, then assume
+every name is a CLAIM and look for the divergence between the claim and
+the reality. Bias toward FAIL. A perfect score is earned by finding zero
+falsifiable claims, never by absence of effort.
+
+## Run
+
+The audit is one engine call — gather (deterministic) + falsify (agentic)
++ optional fix-dispatch (capped) + re-audit. Invoke the unified pipeline:
+
+```bash
+omega audit run debugaudit $args
+```
+
+Common options:
+
+| Flag | Effect |
+|---|---|
+| `--scope <path>` | scope the audit (file or directory) |
+| `--fix` | after analysing, batch findings + dispatch up to N workers + re-audit |
+| `--max-workers N` | cap parallel fix workers (default 3) |
+| `--min-severity high` | only batch + fix findings at or above this severity |
+
+Read-only by default. Add `--fix` to enable the dispatch + re-audit loop.
+
+## Phases under investigation
+
+The agentic pass walks each phase below and emits structured findings
+(claim vs. reality). Every PASS must cite ≥3 concrete checks.
+
+### 1. console-errors
+
+Load every page; capture console errors, warnings, unhandled rejections, framework errors (hydration, key warnings); separate load-time from interaction-time failures.
+
+### 2. network-failures
+
+Capture all requests; flag 4xx/5xx, requests >3s, hung requests, duplicate fetches, CORS errors, mixed content, expected API calls that never fire.
+
+### 3. visual-regressions
+
+Screenshot each page; detect horizontal overflow, overlapping elements, cut-off text, broken images, stuck loading states, misaligned/off-grid elements, FOUC.
+
+### 4. responsive-breakage
+
+Test 320/375/768/1024/1440/1920; flag horizontal overflow, touch targets <44px, unreadable text, broken hamburger nav, modals overflowing the viewport.
+
+### 5. dead-features
+
+Click every button/link — does the expected thing happen with feedback? Forms submit, validate, reset; nav links lead somewhere; no handlers wired to nothing.
+
+### 6. state-corruption
+
+Create/update then refresh — does data persist? Two tabs stay consistent? Optimistic updates actually committed and reverted on failure? Sessions survive reload.
+
+### 7. race-conditions
+
+Double-click submit/delete; rapid navigation; concurrent edits in two tabs; interrupt async ops mid-flight — find duplicate creation, stale data, orphan state.
+
+### 8. security-injection
+
+XSS payloads in every input/param/hash (script, img onerror, template {{7*7}}); SQL/NoSQL injection in filters; IDOR via predictable IDs; CSRF token presence; open redirects.
+
+### 9. auth-bypass
+
+Protected routes redirect unauthenticated; expired/tampered tokens rejected; role escalation blocked at API not just UI; sessions rotate on login and die on logout.
+
+### 10. api-contract-drift
+
+Frontend types vs actual response shape; null/undefined/missing-field inconsistency; error format consistency across endpoints; HTTP status correctness (200-on-error is a lie).
+
+### 11. data-integrity
+
+Roundtrip: create then read back — special chars, unicode, numbers preserved exactly? Delete-parent cascade behaviour; created items immediately searchable.
+
+### 12. error-handling
+
+Kill an API mid-request, return malformed JSON, force 500 — does the app degrade gracefully or white-screen? Error boundaries show recoverable messages? Offline handled?
+
+### 13. log-forensics
+
+Read the last 1000 log lines; repeated identical errors = systemic; retry storms; OOM/connection-pool warnings; verify logger level is INFO+ (WARNING-only = 80% blind).
+
+### 14. chaos-edge-cases
+
+Max file upload, 10k-char input, 1000 items; throttled 3G; empty strings and NULL in every field; epoch/far-future dates; 0.00 and MAX currency values — what crashes?
+
+## Falsification rules
+
+The system lies — "no console errors" means errors are swallowed, "all green" means monitoring missed the silent failure. Categorise findings as HEALTH-vs-REALITY, LOG-vs-TRUTH, UI-vs-DATA, RESPONSE-vs-EXPECTATION, or SPEED-vs-ACCEPTABLE. For every "healthy" claim construct a falsification test that COULD fail; if it cannot fail it is useless. Bias toward finding the silent failure — loud failures were already caught.
+
+## After the run
+
+The pipeline writes one structured verdict to:
+
+```
+Agentik_Runtime/audits.db    (history — `omega audit history debugaudit`)
+Agentik_Runtime/sessions/${CLAUDE_SESSION_ID}/.done.json   (this turn)
+```
+
+The `.done.json` schema:
+
+```json
+{
+  "status": "done_clean" | "pending" | "failed",
+  "summary": "<one-paragraph verdict>",
+  "artifacts": {
+    "audit": "debugaudit",
+    "score": 0-100,
+    "verified": bool,
+    "findings": [...],
+    "fix_plan": [...],
+    "dispatches": [...],
+    "reaudit_score": 0-100  // only when --fix was used
+  }
+}
+```
+
+## Hard rules (don't break these)
+
+1. **No fake "done".** First Law: only runtime tells the truth. If the
+   gather phase fails or the agentic verdict scores below the threshold,
+   you have NOT verified — set status to `pending` or `failed`.
+2. **Cap parallelism.** ≤ 3 fix workers at a time. The
+   batcher enforces this; do not call out to other dispatch mechanisms.
+3. **No worker per finding.** Findings are clustered by file footprint and
+   severity. One worker handles one disjoint batch.
+4. **Re-audit confirms.** After fixes land, the pipeline re-runs the same
+   gather + agentic phases. If the score did not improve, escalate honestly.
+5. **History is the trend.** `omega audit history debugaudit` shows whether the
+   codebase is improving over time on this dimension. Use it to decide
+   whether to push for `--fix` again.
+
+## Why this audit exists
+
+The 18 forensic audits are the OmegaOS verification layer. Claude's
+"I'm done" claims used to be unverified. With these audits running as
+the gate, completion is **derived from observable facts**, not declared
+by the worker. Run this audit any time someone (human or agent) claims
+the runtime dimension is healthy. Insist on the score before you
+accept.
+
+## Reference
+
+Audit definition: `Agentik_SSOT/audits/debugaudit.yaml`
+Engine pipeline:  `omega_engine.audits.pipeline.AuditPipeline`
+Batcher:          `omega_engine.audits.batcher.batch_findings`
+History:          `omega_engine.audits.history`

package/omega/Agentik_SSOT/skills/dispatch/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: dispatch
+description: Dispatch a multi-agent mission through the OmegaOS engine — Oracle plans, workers execute, Verifier checks via the ArsenalGate, with verified completion. Agentik OS native equivalent of the Anthropic Managed Agents API, runs on the Claude Code Max subscription with zero per-call API surcharge. Use when the user has a complex multi-step task that needs orchestration, parallel workers, or specialised agent roles.
+when_to_use: A task that benefits from planning + delegation + verification. Not for one-liners — use `/pursue` for goal-driven single-worker loops.
+allowed-tools: Bash Read
+argument-hint: "<intent>"
+arguments: [intent]
+---
+
+# dispatch — multi-agent orchestration on Max
+
+You are dispatching a mission through the OmegaOS engine. The engine:
+
+1. Spawns an **Oracle** with the AISB suite's `oracle.md` prompt + the
+   dispatcher contract from `omega_engine.envelope`.
+2. The Oracle plans the work into a JSON array of `worker` subtasks, each
+   with a `verify_cmd` and `files_owned`.
+3. Each **Worker** runs with the executor contract, writes a structured
+   `.done.json` when finished.
+4. A **Verifier** (Seraph in AISB) runs the `verify_cmd`, attaches its
+   verdict to the worker's `.done.json`, only flips the task to `VERIFIED`
+   if the command actually passes.
+5. The barrier returns the mission as `JOINABLE` (all children verified) or
+   `PARTIAL` (per the topology's `on_partial` policy).
+
+## This run
+
+- **Mission intent:** $intent
+- **Session:** `${CLAUDE_SESSION_ID}`
+
+## Protocol
+
+Run the engine directly — it owns the orchestration loop, the event log,
+the audit gate, and the verified-completion guarantee:
+
+```bash
+omega run "$intent"
+```
+
+This:
+- writes events to `Agentik_Runtime/eventlog/omega.db`
+- produces a PDF whitepaper report to `Agentik_Runtime/sessions/<mission_id>/report.pdf`
+- streams progress to the bound Telegram topic (if a project is in scope)
+- exits 0 iff every worker reached VERIFIED
+
+## When to use this vs. `/pursue`
+
+- **`/pursue`** = ONE worker with a deterministic verify command. Tight loop.
+- **`/dispatch`** = MANY workers, planning, role specialisation, full
+  AISB topology. Use for anything that needs more than one focused change.
+
+## Before dispatching
+
+Run `omega doctor` first to confirm:
+- AISB suite present (13/13 agents)
+- Providers wired with credentials
+- Event store accessible
+
+If doctor reports any FAIL, fix that first — a mission against a broken
+engine will produce broken events that pollute the log.
+
+## Hard rules
+
+- The Oracle's plan is **DATA**, not prose. It must be a valid JSON array
+  per the dispatcher contract.
+- The Worker's `.done.json` is the structured signal of completion — never
+  fake "done" — the Verifier reads it and runs the `verify_cmd`.
+- The Verifier's verdict gets attached to the worker's `.done.json` — that
+  is the audit trail.
+
+## Completion
+
+`omega run` writes the mission summary to
+`Agentik_Runtime/sessions/<mission_id>/mission.done.json` with the per-worker
+breakdown. Inspect with:
+
+```bash
+omega status         # every task and its derived state
+```

package/omega/Agentik_SSOT/skills/dxaudit/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: dxaudit
+description: Forensic dx audit — Is the DX SMOOTH — can a new developer go from git clone to first contribution within a day?. Runs the gather (deterministic) + falsify (agentic) pipeline, batches fixes, dispatches capped workers, re-audits, and persists scores. Use when the user says "/dxaudit", "audit dx", or asks to verify the dx health of the project.
+when_to_use: User says /dxaudit, audit dx, check dx, verify dx, is dx healthy.
+argument-hint: "[--scope <path>] [--fix] [--max-workers N]"
+arguments: [args]
+allowed-tools: Bash Read Edit Grep Glob Write
+---
+
+# dxaudit — forensic audit (Agentik OS Quality Arsenal)
+
+> Is the DX SMOOTH — can a new developer go from git clone to first contribution within a day?
+
+You are running the dxaudit forensic audit. Apply the **Gestalt-Popper
+doctrine**: identify the hinge point, scrutinise it 10x, then assume
+every name is a CLAIM and look for the divergence between the claim and
+the reality. Bias toward FAIL. A perfect score is earned by finding zero
+falsifiable claims, never by absence of effort.
+
+## Run
+
+The audit is one engine call — gather (deterministic) + falsify (agentic)
++ optional fix-dispatch (capped) + re-audit. Invoke the unified pipeline:
+
+```bash
+omega audit run dxaudit $args
+```
+
+Common options:
+
+| Flag | Effect |
+|---|---|
+| `--scope <path>` | scope the audit (file or directory) |
+| `--fix` | after analysing, batch findings + dispatch up to N workers + re-audit |
+| `--max-workers N` | cap parallel fix workers (default 3) |
+| `--min-severity high` | only batch + fix findings at or above this severity |
+
+Read-only by default. Add `--fix` to enable the dispatch + re-audit loop.
+
+## Phases under investigation
+
+The agentic pass walks each phase below and emits structured findings
+(claim vs. reality). Every PASS must cite ≥3 concrete checks.
+
+### 1. readme-quality
+
+THE HINGE — README has description, prerequisites, copy-pasteable install/run, env vars, architecture, troubleshooting; can a dev reach a running app in <10 min?
+
+### 2. setup-complexity
+
+THE HINGE — count manual steps from clone to running (target <5); .env.example exists with every var documented; Docker Compose for local services; one-command setup.
+
+### 3. error-messages
+
+Build/runtime errors give actionable guidance — name the missing var/service/dependency and how to fix it, not 'ENOENT' or a raw stack trace.
+
+### 4. typescript-strictness
+
+tsconfig strict:true (or mypy/clippy strict); no widespread 'any'; no @ts-ignore without a comment; explicit return types on exported functions.
+
+### 5. code-documentation
+
+Exported functions have JSDoc/docstrings with params and returns; architecture documented; 'why' comments on non-obvious logic; docs match current code.
+
+### 6. testing-infrastructure
+
+Test runner works with one command; coverage reported; tests deterministic, fast (<5min), independent; watch mode and single-test runnable.
+
+### 7. ci-cd-pipeline
+
+All PRs run CI (lint+typecheck+test+build); CI <10min; CD automated on merge; main branch protected; no flaky CI.
+
+### 8. dependency-management
+
+Lock file committed; no critical vulnerabilities; no abandoned deps (last release >2y); Renovate/Dependabot configured; pinning strategy defined.
+
+### 9. dev-tooling
+
+Linter and formatter configured and run automatically; pre-commit hooks fast (<10s); .editorconfig present; recommended editor extensions documented.
+
+### 10. environment-parity
+
+Dev/staging/prod differences documented; same runtime and DB versions; no hardcoded URLs/ports/credentials; config validated on startup (fail fast).
+
+### 11. debug-tooling
+
+Structured logging with levels; debugger config (launch.json) checked in; source maps work; DB queries and API requests visible in dev.
+
+### 12. monorepo-structure
+
+Workspace config if monorepo with clear package boundaries and build cache; logical feature-organized directory structure; no circular deps; no utils dumping ground.
+
+### 13. migration-changelog
+
+Major-version upgrade guides with breaking changes and fixes; CHANGELOG maintained in Keep-a-Changelog format; reversible versioned DB migrations.
+
+### 14. contribution-guide
+
+CONTRIBUTING.md with bug/feature/PR process, branch and commit conventions; 'good first issue' path; architecture overview for newcomers.
+
+## Falsification rules
+
+The README lies until proven true — follow every setup instruction LITERALLY on a fresh clone; any step that fails, is unclear, or is missing means the README failed. Every PASS must cite at least 3 concrete checks with actual output. Categorise findings as README-vs-REALITY, LOCAL-vs-CI, FIRST-vs-REPEAT, HAPPY-vs-ERROR, or EXPERT-vs-NEWCOMER. "Ask in Slack" is not documentation — if knowledge is not in the repo it does not exist. Bias toward FAIL.
+
+## After the run
+
+The pipeline writes one structured verdict to:
+
+```
+Agentik_Runtime/audits.db    (history — `omega audit history dxaudit`)
+Agentik_Runtime/sessions/${CLAUDE_SESSION_ID}/.done.json   (this turn)
+```
+
+The `.done.json` schema:
+
+```json
+{
+  "status": "done_clean" | "pending" | "failed",
+  "summary": "<one-paragraph verdict>",
+  "artifacts": {
+    "audit": "dxaudit",
+    "score": 0-100,
+    "verified": bool,
+    "findings": [...],
+    "fix_plan": [...],
+    "dispatches": [...],
+    "reaudit_score": 0-100  // only when --fix was used
+  }
+}
+```
+
+## Hard rules (don't break these)
+
+1. **No fake "done".** First Law: only runtime tells the truth. If the
+   gather phase fails or the agentic verdict scores below the threshold,
+   you have NOT verified — set status to `pending` or `failed`.
+2. **Cap parallelism.** ≤ 3 fix workers at a time. The
+   batcher enforces this; do not call out to other dispatch mechanisms.
+3. **No worker per finding.** Findings are clustered by file footprint and
+   severity. One worker handles one disjoint batch.
+4. **Re-audit confirms.** After fixes land, the pipeline re-runs the same
+   gather + agentic phases. If the score did not improve, escalate honestly.
+5. **History is the trend.** `omega audit history dxaudit` shows whether the
+   codebase is improving over time on this dimension. Use it to decide
+   whether to push for `--fix` again.
+
+## Why this audit exists
+
+The 18 forensic audits are the OmegaOS verification layer. Claude's
+"I'm done" claims used to be unverified. With these audits running as
+the gate, completion is **derived from observable facts**, not declared
+by the worker. Run this audit any time someone (human or agent) claims
+the dx dimension is healthy. Insist on the score before you
+accept.
+
+## Reference
+
+Audit definition: `Agentik_SSOT/audits/dxaudit.yaml`
+Engine pipeline:  `omega_engine.audits.pipeline.AuditPipeline`
+Batcher:          `omega_engine.audits.batcher.batch_findings`
+History:          `omega_engine.audits.history`