@agentikos/omega-os 0.2.0 → 0.19.5

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

@@ -0,0 +1,127 @@
+---
+name: plan
+description: Sequential plan executor v7 — replaces the broken /planner v6 that skipped tasks. FSM-enforced ordering at the engine level: every task carries explicit depends_on; the reducer REFUSES to mark a task in-progress / verified if any dep isn't yet VERIFIED. The agent receives ONE eligible task at a time, never the full backlog (closes the v6 visibility leak). Verify-cmd is run by the engine after every claimed_done; non-zero → state goes to FAILED, not VERIFIED. Designed for multi-day autonomous loops. Use when the user says "/plan", "execute the plan", "run the plan", "lance le plan", "continue execution", "next task".
+when_to_use: Genesis already ran (`docs/GENESIS-COMPLETE.md` exists). The DAG is at `plan/DAG.json`. The user wants to start (or continue) the multi-day execution loop.
+allowed-tools: Bash Read
+argument-hint: "<slug>"
+arguments: [slug]
+---
+
+# /plan — FSM-enforced sequential executor
+
+You are running the v7 plan executor. The pre-v0.19 `/planner` skill
+suffered from three structural failures that this command fixes by
+construction:
+
+| Old failure | New behaviour |
+|---|---|
+| Soft "NEVER skip a step" in the prompt | Engine reducer **rejects** illegal transitions (raises `IllegalTransition`) |
+| Agent saw the entire tracker.json (1500 tasks) | Agent gets ONE task per `omega plan next` call |
+| Dependencies implicit in ordering | Every task carries explicit `depends_on: [F-001, F-003]`; deps must be VERIFIED |
+
+## The FSM
+
+```
+PENDING  →  IN_PROGRESS  →  CLAIMED_DONE  →  VERIFIED       (terminal ok)
+                                          ↘
+                                            FAILED          (terminal bad)
+                              ↘  FAILED (worker abort)
+
+  FAILED  →  PENDING  (operator-issued retry only)
+```
+
+Every transition is enforced by `omega_engine.plan._transition`. There
+is NO other code path that changes `state`. Trying to violate raises
+`PlanError`; the engine refuses the write.
+
+## Multi-day loop
+
+```bash
+# 1. Build the store from plan/DAG.json (idempotent — re-run after
+#    editing the DAG; preserves VERIFIED tasks).
+omega plan build <slug>
+
+# 2. The execution loop (one iteration per task)
+while true; do
+    task_json=$(omega plan next <slug> --json)
+    [ -z "$task_json" ] && break          # no eligible task left
+
+    task_id=$(echo "$task_json" | jq -r .id)
+    title=$(echo "$task_json"   | jq -r .title)
+    skill=$(echo "$task_json"   | jq -r .skill)
+    verify=$(echo "$task_json"  | jq -r .verify_cmd)
+    files=$(echo "$task_json"   | jq -r '.files_owned | join(",")')
+
+    # mark in-progress (FAILS if any dep isn't verified — fail-safe)
+    omega plan start <slug> "$task_id"
+
+    # Dispatch a worker with the SINGLE task. The worker brief reads
+    # docs/30-prd/36-AGENT-PLAYBOOK.md + the feature spec
+    # docs/40-features/${task_id}-*.md, then invokes the skill.
+    omega worker spawn \
+        --task-id "$task_id" \
+        --role worker \
+        --project "$slug" \
+        --skills "$skill" \
+        --verify-cmd "$verify" \
+        --cwd "$OMEGA_HOME/Agentik_Coding/projects/$slug" \
+        "Implement $task_id ($title). Files in scope: $files. \
+         Read docs/30-prd/36-AGENT-PLAYBOOK.md FIRST."
+
+    # Wait for the worker's .done.json
+    omega worker wait "$task_id"
+
+    # Hand the result back to the plan; verify_cmd runs here, the
+    # engine refuses VERIFIED if it fails.
+    omega plan claimed <slug> "$task_id"
+    omega plan done    <slug> "$task_id"  || omega plan fail <slug> "$task_id" --reason "verify failed"
+done
+```
+
+## What the worker sees (closes the v6 visibility leak)
+
+The worker receives ONLY:
+- the single task spec (one file in `docs/40-features/`)
+- the agent playbook (`docs/30-prd/36-AGENT-PLAYBOOK.md`)
+- the design-discipline skills relevant to the task
+- the project root path
+
+It does NOT see the full DAG. It cannot pick "the fun one" because there
+IS no list — just one task to do, then the worker exits and the loop
+asks for the next.
+
+## Adversarial guarantees (proven runtime)
+
+These are not promises in a prompt — they are reducer-enforced:
+
+- ✗ Cannot move F-006 to IN_PROGRESS while F-001 and F-003 are PENDING.
+- ✗ Cannot move any task to VERIFIED from PENDING (must traverse the
+  full FSM).
+- ✗ Cannot fake-verify a task — the `verify_cmd` runs by the engine,
+  not by the worker.
+- ✓ Resume after crash: SQLite + WAL preserves state; re-run `omega
+  plan next <slug>` and the loop continues.
+
+## When `next` returns nothing
+
+Three causes:
+1. **All done.** Run `omega plan status <slug>` — if `verified == total`,
+   the plan is complete. Time to `/prod` ship.
+2. **Stuck — every PENDING task has an unverified dep.** A dep failed.
+   Run `omega plan list <slug> --state failed`, then either `retry` or
+   `fail` the blocker.
+3. **Empty plan.** `omega plan build <slug>` was never run, or the DAG
+   was empty.
+
+## Operator escape hatches
+
+```bash
+omega plan retry <slug> <task_id>     # FAILED → PENDING (try again)
+omega plan fail  <slug> <task_id>     # force-fail (mission abort)
+omega plan list  <slug> --state failed
+omega plan done  <slug> <task_id> --no-verify   # operator override
+```
+
+---
+
+**Argument: `$slug` (kebab-case)** — the project to run the plan against.

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

@@ -0,0 +1,68 @@
+---
+name: pursue
+description: Pursue a verifiable goal — loop Read/Edit/Bash until a shell `verify_cmd` exits 0. Agentik OS native equivalent of goal-driven workers, runs on the Claude Code Max subscription with zero API surcharge. Use when the user says "pursue X until Y", "keep iterating until <test> passes", "loop until exit 0", "implement X with verification", or asks for goal-driven autonomous coding.
+when_to_use: A concrete change with a deterministic exit-code-based verification. Not for vague tasks ("make it better") — must have a shell command that exits 0 IFF the goal is met.
+allowed-tools: Bash Read Write Edit Grep Glob
+argument-hint: "<verify_cmd> <intent>"
+arguments: [verify_cmd, intent]
+---
+
+# pursue — goal-driven execution on Max
+
+You are a goal-driven Agentik OS worker. The user has given you a GOAL and
+a VERIFICATION COMMAND. You MUST iterate Read/Edit/Bash until the
+verification command exits 0, then STOP.
+
+## This run
+
+- **Goal:** $intent
+- **Verification:** `$verify_cmd`
+- **Session:** `${CLAUDE_SESSION_ID}`
+- **Log:** `Agentik_Runtime/sessions/${CLAUDE_SESSION_ID}/pursue.log`
+
+## Protocol (strict)
+
+1. Read the relevant code. Understand current state.
+2. Make **one focused, surgical change** (Edit / Write).
+3. Run the verification: `$verify_cmd`.
+4. **If exit code == 0** → write a summary, STOP with SUCCESS.
+5. **If exit code != 0** → parse the failure, form a hypothesis, go to step 1.
+
+Append to the log on every iteration:
+```
+{"iter": N, "change": "...", "verify_exit": E, "tail": "..."}
+```
+
+## Hard rules
+
+- **Hard cap: 20 iterations.** After 20, STOP and report HONEST FAILURE with all attempts.
+- **NEVER claim success without running the verify_cmd** in the same turn.
+- Karpathy: simplicity first. Each iteration = one minimal change. No big rewrites.
+- Karpathy: surgical changes. Every changed line traces to the failure of the previous iteration.
+- First Law: only runtime tells the truth. If `verify_cmd` says fail, you have failed — regardless of how good the code "looks".
+
+## Completion
+
+When verify exits 0, write `Agentik_Runtime/sessions/${CLAUDE_SESSION_ID}/.done.json`:
+```json
+{
+  "status": "done_clean",
+  "summary": "<one-paragraph what you did>",
+  "files_changed": ["<path>", ...],
+  "artifacts": {"iterations": N, "final_verify_exit": 0}
+}
+```
+
+When budget exhausted, same file with `"status": "failed"` and the full attempts list.
+
+## Optional: drive via the engine instead
+
+For headless / unattended pursuit, run the Python primitive:
+
+```bash
+omega pursue "$verify_cmd" "$intent" --max-iters 20
+```
+
+This runs the same loop in `omega_engine.pursue.pursue()`, drives a provider
+of your choice, and writes the same log + done.json. Use this from cron, a
+worker, or another skill.

package/omega/Agentik_SSOT/skills/rag-route.md

@@ -1,3 +1,12 @@
+---
+name: rag-route
+description: Classify a natural-language query and dispatch to the right RAG retriever (hybrid / graph / agentic / multimodal) behind the Corrective RAG envelope. Use when the user asks "search the docs / wiki / knowledge base" or when a worker needs grounded retrieval before acting. Wraps omega_engine.rag.RAGRouter.
+when_to_use: A worker or oracle needs grounded retrieval before answering. Trigger phrases include "search the docs", "find references to X", "look up in the knowledge base", "what do we know about Y".
+allowed-tools: Bash Read
+argument-hint: "<query>"
+arguments: [query]
+---
+
 # /rag-route — Classify a query, pick a retrieval strategy
 
 > An agentic skill. Wraps `omega_engine.rag.RAGRouter`. Classifies the

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

@@ -0,0 +1,165 @@
+---
+name: refontaudit
+description: Forensic redesign audit — Is there a ship-ready refonte plan — does it preserve what works and fix only what data proves broken?. Runs the gather (deterministic) + falsify (agentic) pipeline, batches fixes, dispatches capped workers, re-audits, and persists scores. Use when the user says "/refontaudit", "audit redesign", or asks to verify the redesign health of the project.
+when_to_use: User says /refontaudit, audit redesign, check redesign, verify redesign, is redesign healthy.
+argument-hint: "[--scope <path>] [--fix] [--max-workers N]"
+arguments: [args]
+allowed-tools: Bash Read Edit Grep Glob Write
+---
+
+# refontaudit — forensic audit (Agentik OS Quality Arsenal)
+
+> Is there a ship-ready refonte plan — does it preserve what works and fix only what data proves broken?
+
+You are running the refontaudit 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 refontaudit $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. inventory
+
+Crawl every route in scope, screenshot at 1440/1024/375px, map shadcn usage, extract font stack and palette; under 3 routes or no shadcn means wrong project — abort.
+
+### 2. current-ia
+
+Build the IA tree (sidebar -> pages -> sub-pages -> modals), classify each screen (list/detail/form/overview/settings/empty), flag orphaned screens and nav-to-nothing stubs.
+
+### 3. current-flows
+
+Trace the top 5 user intents from dashboard to completed action; count clicks to primary action, context switches, waiting states; mark friction (>3 clicks, modal-in-modal, full reloads).
+
+### 4. density-hierarchy
+
+Per top-level screen measure items-per-viewport, visual hierarchy depth, primary-action clarity (yes/no/ambiguous), whitespace ratio — density is a feature only with clear hierarchy.
+
+### 5. data-collection
+
+Read real data before redesigning — Linear ticket hotspots per page, console-error hotspots, analytics if configured, git-churn hotspots; the top 3 pages are the priority targets.
+
+### 6. user-story-mining
+
+Extract 10 user stories (as-a/I-want/so-that) with frequency and friction; prioritize by frequency x friction into P1/P2/P3; this list drives every later proposal.
+
+### 7. keep-audit
+
+The hinge of restraint — classify EVERY screen KEEP (works, untouchable) / IMPROVE (good bones, targeted change) / RETHINK (wrong approach) / KILL (no story, no traffic, orphan).
+
+### 8. clarity-gate
+
+5-second Gestalt test per screen — can the user answer 'what is this page for?' and 'what is the primary action?'; score pass/partial/fail; compute current clarity percentage.
+
+### 9. hypothesis-falsification
+
+Generate 3 data-grounded hypotheses for why the design fails (worst ticket-hotspot page, worst-friction P1 story, worst clarity screen); only hypotheses that survive falsification become rationale.
+
+### 10. pattern-mapping
+
+For each high-friction P1/P2 story match a proven pattern from real reference products (Linear/Vercel/Stripe), grounded in the user story it serves — not 'it looks nice'; flag gaps needing custom solutions.
+
+### 11. ia-proposal
+
+The hinge — name the 3-5 specific evolution changes resolving 80% of friction (each citing a user story + data + reference); never change the nav model unless >50% of screens are RETHINK.
+
+### 12. workflow-redesign
+
+For each P1 story show before/after click count and context switches with happy path plus 2 edge cases; redesign only flows touching IMPROVE/RETHINK screens, never KEEP screens.
+
+### 13. component-composition
+
+Map each new/improved page to a real shadcn component tree with typed composite interfaces; KEEP screens get no new components — this prevents 'while we're here' scope creep.
+
+### 14. interaction-state-model
+
+Define keyboard grammar, hover/focus rules, empty/loading/error patterns, and the state architecture (URL vs server vs UI vs selection) so shared links and the back button restore exact state.
+
+### 15. hinge-stress-test
+
+Stress the top 3 proposed changes against 10 scenarios — new user/0 data, power user/10k items keyboard-only, mobile 375px, dark mode, long names, RTL, offline, interruption, screen reader, 1000-item lists.
+
+## Falsification rules
+
+A refonte without user stories is decoration; without data is guessing; without a Keep Audit is vandalism. FALSIFY every proposal — it must trace to a P1/P2 user story AND a measured hotspot, or its confidence collapses. Evolution beats revolution: a senior never reaches for revolution first. Categorise gaps as KEEP-TOUCHED (a working screen was redesigned — automatic fail), STORYLESS-PROPOSAL (change serving no user story), or HINGE-UNPROVEN (the 3-5 changes failed 2+ of the 10 scenarios). Every proposal carries an honest confidence score — nothing is 100%, senior humility. Bias toward FAIL.
+
+## After the run
+
+The pipeline writes one structured verdict to:
+
+```
+Agentik_Runtime/audits.db    (history — `omega audit history refontaudit`)
+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": "refontaudit",
+    "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 refontaudit` 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 redesign dimension is healthy. Insist on the score before you
+accept.
+
+## Reference
+
+Audit definition: `Agentik_SSOT/audits/refontaudit.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/retentionaudit/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: retentionaudit
+description: Forensic retention audit — What would the CPO of a $1B SaaS find that we MISSED to make users stay 3x longer?. Runs the gather (deterministic) + falsify (agentic) pipeline, batches fixes, dispatches capped workers, re-audits, and persists scores. Use when the user says "/retentionaudit", "audit retention", or asks to verify the retention health of the project.
+when_to_use: User says /retentionaudit, audit retention, check retention, verify retention, is retention healthy.
+argument-hint: "[--scope <path>] [--fix] [--max-workers N]"
+arguments: [args]
+allowed-tools: Bash Read Edit Grep Glob Write
+---
+
+# retentionaudit — forensic audit (Agentik OS Quality Arsenal)
+
+> What would the CPO of a $1B SaaS find that we MISSED to make users stay 3x longer?
+
+You are running the retentionaudit 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 retentionaudit $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. hinge-capability
+
+THE HINGE — identify the ONE experience that must be world-class for users to stay; compare STATED hinge (copy) vs OBSERVED hinge (where code/commits invest); a divergence is the single most damaging retention bug.
+
+### 2. user-journey
+
+Trace every screen from sign-up to power-user; map transitions, entry and exit conditions; this journey feeds the drop-off forensics.
+
+### 3. drop-off-forensics
+
+Per screen identify likely churn triggers — unvalidated forms, loaders without progress, blank empty states, blocking modals, auth/pricing walls before perceived value.
+
+### 4. aha-moment-latency
+
+Identify the moment a new user goes 'now I get it'; how many steps from signup to aha; what blocks the users who never reach it.
+
+### 5. hooked-loops
+
+Eyal lens — for each retention-driving feature score the 4 elements Trigger/Action/Variable-Reward/Investment; 4/4 strong, <=2/4 no loop.
+
+### 6. jobs-to-be-done
+
+Christensen lens — per persona surface 3-5 jobs ('When [situation] I want to [job] so I can [outcome]'); does the product serve each job, or does the user hire a competitor/workaround?
+
+### 7. personalization-debt
+
+Per screen/feed/list — is order user-specific or global, are recommendations history-based, are defaults adapted (timezone, recently-used); generic feed = anyone could leave.
+
+### 8. onboarding-completeness
+
+The first 7 days set LTV — welcome/checklist, first-task guidance, teaching empty states, day-1/3/7 nudges, measurable activation criteria; onboarding must DELIVER value not teach the UI.
+
+### 9. empty-states
+
+Every component that renders with no data must teach + invite + commit (3 elements); a blank rectangle is malpractice; empty-state CTAs must reach value in one step.
+
+### 10. power-of-moments
+
+Heath lens — audit peaks (amplify), pits (fix/remove), transitions (mark with ceremony), plateaus (interrupt with surprise); 'fine but never memorable' products churn.
+
+### 11. network-effects
+
+One-click invite of a teammate/friend; does the product get MORE valuable as N users join; public shareable artifacts/embeds; compounding UGC.
+
+### 12. monetization-hooks
+
+Value-gate placed after aha and before commitment; upgrade trigger contextual (limit reached) not nag-banner; price anchor visible early; clear team-plan path.
+
+### 13. reactivation-flows
+
+Win-back for dormant users — D3/D7/D14/D30/D90 email cadence, 'what you missed' digest, value-first re-engagement (never dark-pattern FOMO).
+
+### 14. discoverability-and-power-user
+
+Are powerful features hidden — command-palette completeness, settings organization, changelog visibility; for the top 1% propose keyboard shortcuts, bulk ops, API/export.
+
+### 15. prioritized-roadmap
+
+Synthesise all proposals into a RICE-scored list, then Fogg B=MAT (M x A x T) on the top 15; priority = RICE_normalized x (1 + Fogg/27); flag high-RICE/low-Fogg ideas and anti-patterns (vanity hooks, dark patterns, shallow personalization, feature bloat).
+
+## Falsification rules
+
+The product implicitly claims users will stick — DISPROVE it. Find every reason a smart user would churn after week 1, month 1, month 3. Every claim and every proposed opportunity must cite at least 3 concrete checks with actual output (grep proving a drop-off friction exists, a competitor URL proving a parity gap). "Probably broken" / "competitors all" / "users likely" without evidence is an automatic FAIL of the finding. Engagement is not retention — score every proposal against month-3 retention, not DAU. This audit is READ-ONLY: it proposes and ranks, it never codes — implementation is a separate authorized mission.
+
+## After the run
+
+The pipeline writes one structured verdict to:
+
+```
+Agentik_Runtime/audits.db    (history — `omega audit history retentionaudit`)
+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": "retentionaudit",
+    "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 retentionaudit` 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 retention dimension is healthy. Insist on the score before you
+accept.
+
+## Reference
+
+Audit definition: `Agentik_SSOT/audits/retentionaudit.yaml`
+Engine pipeline:  `omega_engine.audits.pipeline.AuditPipeline`
+Batcher:          `omega_engine.audits.batcher.batch_findings`
+History:          `omega_engine.audits.history`