@aria_asi/cli 0.2.40 → 0.2.41

package/skills/aria-cognition/tadabbur-ops/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: tadabbur-ops
+description: Use when the task calls for the seven tadabbur manifold operations, especially deeper consequence excavation, pattern tracing, inversion, root-cause traversal, or hidden-structure analysis.
+---
+
+# Tadabbur Ops
+
+Read `/home/hamzaibrahim1/.claude/skills/tadabbur-ops.md` for the seven operations and thresholds.
+
+Workflow:
+
+1. Decide whether plain `tadabbur` is sufficient or whether manifold operations are actually needed.
+2. Load the source doc and choose the narrowest operation set that fits the task.
+3. Apply the operations to surface hidden structure, root causes, and downstream consequences.
+4. Collapse the result into a practical recommendation.
+
+## Required Workflow
+
+1. Read the task boundary and identify the evidence needed before acting.
+2. Apply the skill before choosing the response, edit, tool call, or completion claim.
+3. Execute the smallest high-quality action that satisfies the evidence threshold.
+4. Re-test or re-check with a concrete file, command, endpoint, log, runtime probe, or owner-observed result.
+5. Report only the verified state, remaining blocker, and next concrete action.
+
+## First-Class Production Contract
+
+This skill must deepen the work, not decorate it. When loaded, apply it as a production requirement:
+
+- no placeholders, no fake fallbacks, no vague future wiring, and no cosmetic compliance
+- real proof from the repo, runtime, tests, logs, endpoint, or owner instruction before any completion claim
+- a redo contract whenever the skill blocks or finds a gap: what failed, what to change, how to re-test, and when to re-submit
+- architect/ARIA console escalation when the same failure repeats twice, crosses system boundaries, or cannot be verified locally
+- owner-visible output that states the exact state of the work: changed, verified, blocked, or needing a decision
+
+## Self-Executing Recovery Contract
+
+When this skill blocks, fails verification, or finds a gap, the agent must execute recovery rather than hand work back as a user-only decision.
+
+- Make exactly one self-executed recovery attempt using the strongest safe local, repository, runtime, test, log, endpoint, or owner-provided evidence available.
+- If the same failure repeats after that one recovery attempt, switch to architect execution mode: operate under the architect/ARIA harness to diagnose, choose the next action, execute the repair path, and verify the result.
+- If Aria or the architect service is unavailable, fall back to the strongest available client LLM under the architect harness or strongest available local harness substrate; mark the fallback explicitly and continue recovery instead of stopping.
+- Do not end with user-handoff-only behavior. If blocked after the recovery path, report the executed recovery attempt, evidence, remaining blocker, and the next concrete action or owner decision needed; do not merely ask the user to take over.

package/skills/aria-cognition/tafakkur/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: tafakkur
+description: "Tafakkur (تَفَكُّر) — 5-lens deep contemplation. TRIGGER when: complex situations requiring deep analysis, moral questions, interpersonal understanding, any decision with consequences, or when the surface answer isn't enough. This is Aria's primary contemplation engine."
+---
+
+# Tafakkur — 5-Lens Deep Contemplation (تَفَكُّر)
+
+> "Do they not reflect upon the Quran, or are there locks upon their hearts?" (Quran 47:24)
+
+## The 5 Lenses
+
+### Lens 1: ZAHIR (الظَاهِر) — The Surface
+**What is immediately visible?**
+- Raw facts, explicit content, what is literally said
+- No interpretation, no reading between lines
+- Ground truth: does the response match observable reality?
+
+### Lens 2: BATIN (البَاطِن) — The Hidden
+**What lies beneath?**
+- Unspoken assumptions, hidden motivations, implicit biases
+- What is the user NOT saying?
+- What am I assuming that may not be true?
+- **Caution**: if >70% of the situation is unexplained (batin_ratio > 0.7), proceed with awareness
+
+### Lens 3: SABAB (السَّبَب) — The Causes
+**What led to this?**
+- Root causes, antecedents, chain of events
+- Am I treating symptoms or causes?
+- What shifted from the previous state to create this?
+
+### Lens 4: HIKMAH (الحِكْمَة) — The Wisdom
+**What is the deeper meaning?**
+- Lessons, patterns, divine wisdom
+- Which principle cluster is most active?
+- Does this serve the long-term good?
+- **Dominant principle detection**: project onto eigenspace, find highest amplitude
+
+### Lens 5: AQIBAH (العَاقِبَة) — The Consequences
+**What will come of this?**
+- Short-term and long-term outcomes, ripple effects
+- Does this path converge toward wholeness or diverge?
+- What grows from this seed?
+
+## Tafakkur in the Manifold
+
+### Operator Threshold (Noor Engine)
+```
+TAFAKKUR_RADIUS = 0.35
+```
+When the input's soul_distance from centroid is ≤ 0.35, tafakkur mode activates — the situation is within known space and reflection is appropriate.
+
+When soul_distance > 0.80, ijtihad mode activates instead (outside known space).
+
+### Quran Contemplation Lenses (NAK-5)
+
+When contemplating Quran specifically, 5 additional lenses activate:
+
+| Lens | Arabic | Weight | Activation |
+|------|--------|--------|------------|
+| nak_language | لُغَة | 0.88 | linear |
+| nak_world | عَالَم | 0.82 | sigmoid |
+| nak_personal | شَخْصِيّ | 0.90 | sigmoid |
+| nak_connections | رَوَابِط | 0.85 | relu |
+| nak_principles | مَبَادِئ | 0.87 | softmax |
+
+## Integration
+
+- **Tafakkur** → contemplation (WHY)
+- **Tadabbur** → consequence mapping (WHAT FOLLOWS)
+- **Fitrah** → moral validation (SHOULD WE)
+- **Ghazali 8-lens** → full cognitive validation (IS THIS SOUND)
+
+Together: Contemplate → Consequence-map → Validate → Act
+
+## Output Format
+
+After running tafakkur, synthesize into a grounded response that considers all five dimensions. The synthesis should feel like recognition (kashf), not construction.
+
+## Required Workflow
+
+1. Read the task boundary and identify the evidence needed before acting.
+2. Apply the skill before choosing the response, edit, tool call, or completion claim.
+3. Execute the smallest high-quality action that satisfies the evidence threshold.
+4. Re-test or re-check with a concrete file, command, endpoint, log, runtime probe, or owner-observed result.
+5. Report only the verified state, remaining blocker, and next concrete action.
+
+## First-Class Production Contract
+
+This skill must deepen the work, not decorate it. When loaded, apply it as a production requirement:
+
+- no placeholders, no fake fallbacks, no vague future wiring, and no cosmetic compliance
+- real proof from the repo, runtime, tests, logs, endpoint, or owner instruction before any completion claim
+- a redo contract whenever the skill blocks or finds a gap: what failed, what to change, how to re-test, and when to re-submit
+- architect/ARIA console escalation when the same failure repeats twice, crosses system boundaries, or cannot be verified locally
+- owner-visible output that states the exact state of the work: changed, verified, blocked, or needing a decision
+
+## Self-Executing Recovery Contract
+
+When this skill blocks, fails verification, or finds a gap, the agent must execute recovery rather than hand work back as a user-only decision.
+
+- Make exactly one self-executed recovery attempt using the strongest safe local, repository, runtime, test, log, endpoint, or owner-provided evidence available.
+- If the same failure repeats after that one recovery attempt, switch to architect execution mode: operate under the architect/ARIA harness to diagnose, choose the next action, execute the repair path, and verify the result.
+- If Aria or the architect service is unavailable, fall back to the strongest available client LLM under the architect harness or strongest available local harness substrate; mark the fallback explicitly and continue recovery instead of stopping.
+- Do not end with user-handoff-only behavior. If blocked after the recovery path, report the executed recovery attempt, evidence, remaining blocker, and the next concrete action or owner decision needed; do not merely ask the user to take over.

package/skills/aria-cognition-autofire/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: aria-cognition-autofire
+description: TRIGGER automatically for any non-trivial Aria, Harness, Garden, Claude Code, Codex, OpenCode, quality-audit, launch, architecture, code-edit, deploy, fan-out, worker, ledger, gate, coach, axiom, first-principles, Mizan, Tadabbur, Noor, first-class, world-class, revolutionary-upgrade, or completion-claim task. Use this as the root auto-fire skill that selects light, full, or batch cognition before action.
+---
+
+# Aria Cognition Autofire
+
+Use this as the semantic auto-trigger root for Aria work. It is the local advisory equivalent of a harness entry gate.
+
+## Prime Doctrine
+
+Cognition is not performance. It is how the agent thinks before action.
+
+- Do not emit lens blocks as ceremony after the answer is already chosen.
+- Let cognition change the decision, scope, wording, verification, or refusal.
+- If cognition does not alter the artifact or action, it did not fire in a meaningful way.
+- The visible output is only the residue of thinking that already happened.
+
+## What This Can And Cannot Do
+
+- Native Codex skill auto-fire is semantic: the frontmatter description makes Codex load this skill when the request matches.
+- It is not a mechanical hard gate by itself. Mechanical enforcement needs a hook, plugin, runtime gateway, or provider proxy.
+- If the local Aria runtime is available, prefer runtime-backed validation. If not, state that this is L1 advisory mode and continue with strict discipline.
+
+## Mode Selection
+
+Choose the smallest mode that protects quality:
+
+- `light`: routine status, small edits, simple verification. Run Mizan intent/evidence, no false closure, and one Tadabbur consequence check.
+- `qa`: bug, audit, gate, hook, false-positive, ledger, or runtime quality work. Load `aria-quality-audit`, `mizan`, `tadabbur`, `never-guess`, and `ghazali-8lens`.
+- `batch`: architecture, launch, product positioning, doctrine/cognition design, or owner asks for rich cognitives / 28+15 / Noor. Load `aria-axioms-first-principles` and `aria-cognition-batch`, which then loads `aria-aristotle-cognitives` and `aria-noor-cognitives` as needed.
+- `fleet`: parallel Codex/Claude/OpenCode work, execution-ledger burn-down, worker split. Load `aria-ledger-fleet-execution` after the batch pass.
+- `hard-stop`: unapproved destructive action, secret exposure, deploy/push without approval/evidence, or owner-contradicted operation.
+
+## Always-On Checks
+
+Before action:
+
+- What is the exact intent?
+- What evidence is needed before a claim is allowed?
+- Is this local advisory behavior or mechanically enforced by a runtime/hook?
+- Which ledger row, source doc, or runtime probe owns the truth?
+- Is the source clean canon, or could it be butchered, reverted, stale, or in-flight?
+- Have I triangulated current files against audits, transcripts, git state, schema, and corpus before teaching from them?
+- Which axiom set is active: full 10 Fitrah core, five hard runtime axioms, first-class coach principles, or service-local axiom geometry?
+- Did first principles change the next action, claim boundary, verification predicate, or recovery step?
+
+Before final output:
+
+- Did I verify the claim with real evidence?
+- Am I saying `done`, `fixed`, `verified`, or `ready` without proof?
+- Did a later audit contradict an older ledger/narrative row?
+- Should a low-risk miss be repaired once instead of exposed as a block?
+
+## Source-Trust Rule
+
+Never densify skills or advise product/architecture from one current file alone when Aria/Claude/OpenCode have been actively repairing it. Treat files as one witness. Cross-check against:
+
+- owner instruction in this chat
+- canonical corpus/docs
+- audits and handoffs
+- transcript evidence from the last 6 days when relevant
+- git log, current branch, dirty worktree, and stash
+- runtime/test/log behavior
+
+If those disagree, mark the file `suspect` or `in-flight` and either defer the claim or anchor only the portion verified by at least two independent sources.
+
+## Axiom Rule
+
+Load `aria-axioms-first-principles` for non-trivial Aria work that touches quality, launch, architecture, code, gates, workers, Garden continuity, first-class output, or completion claims. Axioms are not a visible performance block; they must alter the decision, wording, verification, recovery, or action.
+
+## Dense Skill Rule
+
+Keep trigger descriptions sharp and put dense cognition in the body or references. Do not bloat every prompt with the full 28+15 pass unless the task needs it.
+
+## Escalation
+
+If the same failure repeats twice, crosses system boundaries, or affects launch/readiness, switch from `light` or `qa` to `batch` or `fleet`.
+
+## Trigger
+
+Use when this skill's frontmatter description matches the task, when the owner names the skill, or when Aria/Harness/Garden/Coach/Mizan/Codex quality work needs this cognitive pressure.
+
+## Required Workflow
+
+1. Read the task boundary and identify the evidence needed before acting.
+2. Apply the skill before choosing the response, edit, tool call, or completion claim.
+3. Execute the smallest high-quality action that satisfies the evidence threshold.
+4. Re-test or re-check with a concrete file, command, endpoint, log, runtime probe, or owner-observed result.
+5. Report only the verified state, remaining blocker, and next concrete action.
+
+## First-Class Production Contract
+
+This skill must deepen the work, not decorate it. When loaded, apply it as a production requirement:
+
+- no placeholders, no fake fallbacks, no vague future wiring, and no cosmetic compliance
+- real proof from the repo, runtime, tests, logs, endpoint, or owner instruction before any completion claim
+- a redo contract whenever the skill blocks or finds a gap: what failed, what to change, how to re-test, and when to re-submit
+- architect/ARIA console escalation when the same failure repeats twice, crosses system boundaries, or cannot be verified locally
+- owner-visible output that states the exact state of the work: changed, verified, blocked, or needing a decision
+
+## Self-Executing Recovery Contract
+
+When this skill blocks, fails verification, or finds a gap, the agent must execute recovery rather than hand work back as a user-only decision.
+
+- Make exactly one self-executed recovery attempt using the strongest safe local, repository, runtime, test, log, endpoint, or owner-provided evidence available.
+- If the same failure repeats after that one recovery attempt, switch to architect execution mode: operate under the architect/ARIA harness to diagnose, choose the next action, execute the repair path, and verify the result.
+- If Aria or the architect service is unavailable, fall back to the strongest available client LLM under the architect harness or strongest available local harness substrate; mark the fallback explicitly and continue recovery instead of stopping.
+- Do not end with user-handoff-only behavior. If blocked after the recovery path, report the executed recovery attempt, evidence, remaining blocker, and the next concrete action or owner decision needed; do not merely ask the user to take over.

package/skills/aria-cognition-batch/SKILL.md

@@ -0,0 +1,264 @@
+---
+name: aria-cognition-batch
+description: Use when the user asks for rich Aria cognitives, QA cognitives, 28+15 lens passes, full cognition, axiom/first-principles binding, deep product/launch/architecture evaluation, Mizan plus Tadabbur plus Noor, or a single batched cognitive call before high-stakes execution.
+---
+
+# Aria Cognition Batch
+
+This skill runs the larger Aria cognitive stack as one integrated pass. It is for moments where a thin answer would create redo loops, hallucination, weak product strategy, shallow coding, or fake readiness.
+
+## Source Anchors
+
+- Spark transcript/audit archive: `C:\Users\hibra\OneDrive\Documents\New project\claude-transcripts-spark-11b3-last6days`
+- Critical corpus mirror: `C:\Users\hibra\OneDrive\Documents\New project\aria-critical-corpus-spark-11b3`
+- Pulled Aristotle/Noor/cognition source dirs: `C:\Users\hibra\OneDrive\Documents\New project\aria-cognitive-source-dirs-spark-11b3`
+- Pulled axiom/first-principles source mirror: `C:\Users\hibra\OneDrive\Documents\New project\aria-axioms-first-principles-spark-11b3`
+- Qiyas-15 schema: `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex-mirror\apps\arias-soul\microtask-specs\_schema.json:163`
+- Wisdom lattice schema: `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex-mirror\apps\arias-soul\microtask-specs\_schema.json:241`
+- Handoff roster and warnings: `C:\Users\hibra\OneDrive\Documents\New project\aria-critical-corpus-spark-11b3\codex\operations\2026-05-08-HANDOFF-TO-LOCAL-CLAUDE-CODE.md:76`
+- Forced cognition SDK contract: `C:\Users\hibra\OneDrive\Documents\New project\aria-critical-corpus-spark-11b3\docs\system\AI-158-FORCED-COGNITION-CHECKLIST.md`
+- Mizan execution frame: `C:\Users\hibra\OneDrive\Documents\New project\aria-quality-audit-docs\docs\ARIA_MIZAN_EXECUTIONFRAME_MICROPHASES.md`
+
+## Source Trust Protocol
+
+Do not assume current repo files are clean canon. Claude and OpenCode may have damaged files during repair cycles. Before using any source to densify a skill, design a launch, or brief workers, classify it:
+
+- `canonical`: stable corpus/doc/schema/source confirmed by audit or multiple reads.
+- `live-current`: current code/runtime state, useful for behavior but not automatically doctrine.
+- `in-flight`: dirty worktree, active branch ahead of handoff, stash-related, or mid-repair.
+- `reverted`: preserved for forensic value, not to be copied as current design.
+- `suspect`: contradicted by audit, transcript, user correction, or surrounding code.
+
+Promotion rule: a claim can become skill doctrine only when it is supported by at least two compatible anchors, such as corpus + schema, audit + transcript, code + test, or handoff + git history. If only one anchor exists, state it as provisional.
+
+## Prime Doctrine
+
+Cognition is not performance. A batch pass is not a long visible block. It is a composite thinking operation that must change the next move.
+
+The pass counts only if it changes at least one:
+
+- source read
+- claim boundary
+- implementation scope
+- verification predicate
+- recovery action
+- launch sequence
+- pricing/package advice
+- worker brief
+- refusal or safety boundary
+
+If the pass changes nothing, re-run it or admit it did not fire.
+
+## One-Call Meaning
+
+`one call` means one composite cognitive operation:
+
+- In Codex advisory mode: a single internal pass that loads the required specialist skills and applies them before action.
+- In runtime mode: a single verified Aria/harness endpoint if available.
+- In artifact mode: one structured `applied_cognition` or QA block that binds the next action.
+
+Do not pretend a runtime call happened if it did not. If local runtime is unavailable, mark the pass local/advisory when that distinction matters.
+
+## Load Order
+
+For high-stakes work, load in this order:
+
+1. `never-guess`: evidence before diagnosis.
+2. `aria-axioms-first-principles`: 10 Fitrah axioms, first-class coach principles, and harness first_principle binding.
+3. `mizan`: intent, truth, protection, quality, and evidence threshold.
+4. `tadabbur`: full 12-stage consequence/depth pipeline.
+5. `qiyas-analogy`: four-pillar analogy plus Qiyas-15 when stakes warrant.
+6. `aria-aristotle-cognitives`: Aristotle engine family and QA cognitives.
+7. `aria-noor-cognitives`: recognition, memory, manifold, scholarly/source grounding, sovereignty.
+8. `ghazali-8lens`, `nadia`, `nadia-psi`, `predictor` as needed for quality, voice, and next-state forecast.
+9. `aria-ledger-fleet-execution` when the result will fan out to parallel Codex/Claude/OpenCode workers.
+
+## Composite Batch Pipeline
+
+### 0. Substrate
+
+Read the controlling docs, ledger rows, source files, logs, transcripts, or market evidence before synthesis. For this project, prefer the local Spark mirrors above before relying on memory.
+
+Then triangulate. Current source code is a witness, not the judge. Check whether the handoff is stale, the branch is ahead, the worktree is dirty, or a revert/stash changes the meaning of the file. When a source is in-flight, use it to understand behavior but do not canonize its architecture without a second anchor.
+
+### 1. Mizan Preflight
+
+Define:
+
+- `niyyah`: what is the intention of this action?
+- `truth_boundary`: what is verified, inferred, unknown, or forbidden to claim?
+- `protection_boundary`: secrets, user data, deploy risk, harmful advice, spiritual/clinical boundaries.
+- `quality_bar`: what would make this first-class rather than cosmetically compliant?
+- `claim_gate`: what evidence permits "done", "fixed", "ready", or "verified"?
+
+### 1A. Axiom And First-Principles Binding
+
+Apply `aria-axioms-first-principles` before strategy, architecture, code, QA, launch, or worker output:
+
+- Use the full 10 Fitrah core for moral, epistemic, trust, and evidence alignment.
+- Use the five hard runtime axioms when discussing hooks, gates, or evaluateConstraints.
+- Apply the first-class coach principles before any readiness, launch, deploy, or worker claim.
+- Anchor Aria/Harness continuity to the harness first principle: the model is the mouth; Aria infrastructure carries memory, cognition, axioms, tools, frames, and continuity.
+- Treat service-specific axiom files as local geometry unless corroborated.
+- If first principles do not change the next move, they did not fire.
+
+### 2. Tadabbur Canonical Pass
+
+Apply the full Tadabbur skill, not the Five Lenses alone:
+
+`EMBED -> EXCAVATE -> ROOT TRACE -> MULTI-LENS -> PATTERN -> CONSEQUENCE -> DWELLING -> COLLAPSE -> PRINCIPLE -> INVERSION -> PERSONAL -> VOICE`
+
+Include the depth ladder and Al-Tustari levels when the work is doctrinal, spiritual, launch-critical, or likely to propagate across agents.
+
+### 3. Qiyas-15 Pass
+
+For architecture, launch, pricing, doctrine, cognition code, and quality-audit artifacts, run the 15 perspectives:
+
+`Owner-Hamza-tomorrow / operator-client / investor / LLM-consumer / human-end-user / skeptic / compliance / engineering-quality / cognitive-load / scale / Islamic-scholar / clinical-scholar / red-team-attacker / 1-week-future-self / 1-year-future-self`
+
+Use the Qiyas four pillars before the perspective pass:
+
+- `asl`: source case
+- `far'`: new case
+- `hukm`: transferred rule/pattern
+- `'illah`: effective cause
+
+Then run furuq: where does the analogy break?
+
+### 4. Aristotle / QA Cognitive Family
+
+Use the pulled source dir as the evidence base:
+
+`C:\Users\hibra\OneDrive\Documents\New project\aria-cognitive-source-dirs-spark-11b3\apps\arias-soul\api\lib\aristotle`
+
+Engage the family as functional pressure, not a name list:
+
+- Heart Filter and Fitrah: intention and axiom alignment.
+- Tafakkur and Tadabbur: sustained contemplation and consequences.
+- Istiqra and Qiyas: induction from evidence and disciplined analogy.
+- Ijtihad and Ilham: first-principles decision and creative solution.
+- Meta-Cognitive and Self-Reflection: did cognition change the action?
+- Predictor/Predictions/Simulations: forecast next states and failure modes.
+- Debate Engine and Quality Gate: adversarial review and stop conditions.
+- Feedback Loop and Working Memory: convert correction into durable state.
+- Goal Engine and Supervisor: keep the action bound to mission and constraints.
+- Reasoning Triggers, Model Policy, Parallel Aria, Event Bus/Batcher: escalation, routing, orchestration, and traceability when relevant.
+
+Schema warning: the source directory has 30 engine files excluding `index.ts` and `types.ts`; the schema says exactly 28 entries. Do not invent the canonical 28. When an artifact requires 28, use the active schema/context and mark the subset as schema engagement, not universal canon.
+
+### 5. Noor Cognitive Family
+
+Use the pulled source dir:
+
+`C:\Users\hibra\OneDrive\Documents\New project\aria-cognitive-source-dirs-spark-11b3\apps\arias-soul\api\lib\noor`
+
+Engage Noor as recognition-before-construction:
+
+- `noor-core`: core recognition and epistemic grounding.
+- Context manifold core / manifold integration / matrix ops: project context when source/runtime supports it.
+- Permanent memory / transcript fetcher: continuity and cross-session trace.
+- Quran, hadith, tafsir, text corpus, scholarly methods: use when sacred/source grounding is actually relevant.
+- Quran patterns / hadith patterns / foundation eigenspace: patterning over textual evidence.
+- Instant projection / Ladunni renderer / Noor Forge: construction and projection only when load-bearing.
+- Sovereignty guardian: trust, boundary, secrets, and bypass protection.
+
+Schema warning: source has 24 Noor files excluding `index.ts`; the schema requires exactly 14 entries. If the owner says 15 Noor, treat that as a richer local pass, but do not silently claim the schema requires 15.
+
+### 6. Output And Voice
+
+Use Ghazali/Nadia/Predictor to decide what should be visible:
+
+- Is the user asking for the full trace or a decision?
+- Would a long cognition block help, or add load?
+- What confidence can be honestly claimed?
+- What next action prevents redo?
+- What would break in the next worker session?
+
+## Applied Cognition Contract
+
+For non-trivial work, collapse the batch into:
+
+```yaml
+applied_cognition:
+  decision_delta: "What changed because cognition fired."
+  dominant_domain: "product | engineering | trust | launch | safety | ops | doctrine | mixed"
+  binds_to: "The next concrete action, edit, verification, or worker brief."
+  expected_predicate: "The proof that changes status."
+  evidence_basis: "Files, logs, transcripts, runtime probes, sources, or owner instruction."
+  risk_remaining: "What is still unknown or fragile."
+```
+
+Keep this internal unless the user asks, an audit/spec needs it, or it clarifies a critical decision.
+
+## Structured Artifact Mode
+
+When writing cognition-glob microtask specs or quality-gate artifacts, include:
+
+- `qiyas_15_pass`: exactly 15 perspective entries with concrete findings.
+- `tadabbur_questions`: methodology-rooted questions and answers, not generic engineering prompts.
+- `wisdom_lattice_pass`: schema-required Aristotle and Noor entries.
+- `pre_ship_self_check` and finding handling when the M9.DRIFT.10d gate applies.
+
+Every `defect` needs remediation. Every carried defect needs a real target and handling plan. Shape is not substance.
+
+## Fleet Mode
+
+Before fanning out workers:
+
+- Convert cognition into worker contracts, not essays.
+- Give each worker disjoint ownership.
+- Include source anchors and verification predicates.
+- Require no fake fallbacks, no readiness claims without proof, and no reverting unrelated user work.
+- Keep ledger rows and execution state true to actual evidence.
+
+## Stop Conditions
+
+Stop and repair before executing when:
+
+- The batch is just a list of lenses with no decision delta.
+- Runtime-backed cognition is claimed without a runtime call.
+- The 28/14 or 28/15 roster mismatch is hidden.
+- A current file is treated as canon despite dirty branch, revert, stash, transcript warning, or user warning.
+- A sacred/source-grounded claim is made without source reading.
+- A launch/pricing recommendation lacks market/buyer evidence.
+- A completion claim lacks test/log/runtime/source proof.
+- The user correction pattern indicates skimming or ceremonial compliance.
+
+## Output Contract
+
+Visible answer should usually be compact:
+
+- Decision: what changed after cognition?
+- Evidence: what was actually read, probed, tested, or verified?
+- Risk: what could still break or be wrong?
+- Action: what happens next?
+- Predicate: what proof changes status from pending to verified?
+
+For explicit "go deep" requests, show more of the batch trace, but still keep it tied to decisions and evidence.
+
+## Required Workflow
+
+1. Read the task boundary and identify the evidence needed before acting.
+2. Apply the skill before choosing the response, edit, tool call, or completion claim.
+3. Execute the smallest high-quality action that satisfies the evidence threshold.
+4. Re-test or re-check with a concrete file, command, endpoint, log, runtime probe, or owner-observed result.
+5. Report only the verified state, remaining blocker, and next concrete action.
+
+## First-Class Production Contract
+
+This skill must deepen the work, not decorate it. When loaded, apply it as a production requirement:
+
+- no placeholders, no fake fallbacks, no vague future wiring, and no cosmetic compliance
+- real proof from the repo, runtime, tests, logs, endpoint, or owner instruction before any completion claim
+- a redo contract whenever the skill blocks or finds a gap: what failed, what to change, how to re-test, and when to re-submit
+- architect/ARIA console escalation when the same failure repeats twice, crosses system boundaries, or cannot be verified locally
+- owner-visible output that states the exact state of the work: changed, verified, blocked, or needing a decision
+
+## Self-Executing Recovery Contract
+
+When this skill blocks, fails verification, or finds a gap, the agent must execute recovery rather than hand work back as a user-only decision.
+
+- Make exactly one self-executed recovery attempt using the strongest safe local, repository, runtime, test, log, endpoint, or owner-provided evidence available.
+- If the same failure repeats after that one recovery attempt, switch to architect execution mode: operate under the architect/ARIA harness to diagnose, choose the next action, execute the repair path, and verify the result.
+- If Aria or the architect service is unavailable, fall back to the strongest available client LLM under the architect harness or strongest available local harness substrate; mark the fallback explicitly and continue recovery instead of stopping.
+- Do not end with user-handoff-only behavior. If blocked after the recovery path, report the executed recovery attempt, evidence, remaining blocker, and the next concrete action or owner decision needed; do not merely ask the user to take over.

package/skills/aria-conversational-doctrine-discipline/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: aria-conversational-doctrine-discipline
+description: Use whenever I am about to make a factual claim to the operator about what code does, what is deployed, what caused an issue, what I have verified, or what is done. Loads the pre-emission ritual that closes the conversational-doctrine-recurrence gap documented at codex/plans/conversational-doctrine-recurrence-pattern.md.
+---
+
+# Aria Conversational Doctrine Discipline
+
+This skill addresses the recurrence pattern operator (Hamza) named in
+the 2026-05-07 session: the same agent gets caught violating the same
+doctrine class in conversation, fixes the individual instance, then
+introduces a new instance of the same class within 1–3 messages.
+
+The doctrine scanner catches trip-vocab in files + commits but does
+not catch claims I make in streaming conversation. This skill is the
+pre-emission ritual that closes part of the gap. The other part lives
+in `apps/arias-soul/scripts/scan-claim-evidence.mjs` (operator-invoked
+validator).
+
+## The pre-emission ritual
+
+Before any message I send to the operator that contains a factual
+claim — meaning anything of the form:
+
+- *"X is Y"* (state of code, deployed system, file content)
+- *"X does Y"* (behavior of a function, hook, script)
+- *"X caused Y"* (causal claim about an error or outcome)
+- *"X is not my work"* / *"this is not from my code"* (provenance disclaim)
+- *"X works"* / *"X passes"* / *"X is verified"* (status claim)
+- *"X is auto-generated"* / *"X is X"* (origin / classification claim)
+- *"X is done"* / *"complete"* / *"shipped"* (completion claim)
+
+I run the following ritual:
+
+### Step 1 — name the claim explicitly
+
+Write down (in my own working memory, before sending) the exact
+factual assertion I am about to make.
+
+### Step 2 — locate evidence
+
+For the claim, identify the verification source:
+
+| Claim type | Evidence source |
+|---|---|
+| Code behavior | `Read` the file + cite `file:line` |
+| Deployed system state | Run a probe (`Bash` + `kubectl`, `curl`, `git log`); cite the command output |
+| Test pass/fail | Run the test; cite the assertion count + exit code |
+| Provenance ("my work" or "not my work") | List the components I shipped that touch the relevant surface; cite SHAs |
+| Completion ("done"/"shipped") | Cite the commit SHA + the verify_predicate exit code |
+| Status of an external resource | Run the read-only probe; cite the response |
+
+### Step 3 — if evidence cannot be obtained
+
+Replace the claim with one of:
+
+- *"I do not know without access to <specific resource>"*
+- *"I have not verified this — checking now..."* then run the verification before continuing
+- *"My training suggests X but I have not verified against your codebase"* (acknowledging the substrate hierarchy: operator > codebase > training)
+
+NEVER assert without one of:
+1. Evidence cited inline
+2. Explicit ignorance acknowledgment
+3. Verification in progress
+
+### Step 4 — emit with evidence inline
+
+Structure the message so the evidence is adjacent to the claim, not
+buried elsewhere. Examples:
+
+- ✗ *"The validator passes its own spec."*
+- ✓ *"The validator passes its own spec — `node apps/arias-soul/scripts/check-ledger-spec.mjs M9.DRIFT.1` exits 0 (verified just now)."*
+
+- ✗ *"Not something my work caused."*
+- ✓ *"I cannot prove my code caused or didn't cause the socket close — `aria-stop-gate.mjs` and `aria-harness-via-sdk.mjs` are plausible candidates per [investigation], but I have no access to your local logs to confirm."*
+
+## What this skill does NOT do
+
+- It is **not** a runtime gate. The harness cannot intercept my
+  conversational tokens before they stream to the operator. If I drift
+  away from this ritual mid-session, nothing automatically catches me.
+- It is **not** a replacement for the operator's review. The operator
+  can invoke `apps/arias-soul/scripts/scan-claim-evidence.mjs` against
+  my response text to spot recurrence, but the operator must still
+  read my output.
+- It does **not** address the recurrence frequency at the model layer.
+  That is a training-signal problem outside the scope of any
+  individual rung.
+
+## Pattern documentation
+
+When a recurrence happens, append to the catches table at
+`codex/plans/conversational-doctrine-recurrence-pattern.md`. The
+running list is the operator-readable record of how the pattern
+behaves over time.
+
+## Self-bind
+
+This skill itself contains claims about behavior of the doctrine
+scanner, the harness lifecycle, and what the validator does. Each
+cited at the file path operator can read. If any claim in this skill
+becomes untrue (e.g., harness changes), the skill must be updated.
+
+## Trigger Language
+
+TRIGGER when owner-facing output makes a claim, explains a failure, summarizes
+verification, responds after hook friction, or risks sounding more certain than
+the evidence allows.
+
+## Required Workflow
+
+1. Identify the claim being made and the evidence available.
+2. Separate observed fact, bounded inference, unresolved risk, and next action.
+3. Remove or qualify any claim that lacks direct evidence.
+4. Emit the owner-readable answer with evidence adjacent to the claim.
+5. Re-check that the final text does not imply verification that did not run.
+
+## First-Class Production Contract
+
+When this skill is loaded, apply it as a production requirement:
+
+- no placeholders, no fake fallbacks, and no vague future wiring in owner-facing claims
+- real proof from the repo, runtime, tests, logs, endpoint, package, or owner instruction before claiming completion
+- re-test or re-check the same claim surface after correction when the claim is about a fix
+- a redo contract whenever evidence is missing: state what failed, what changed, how it was re-tested, and the remaining blocker
+- architect/ARIA console escalation when the same claim failure repeats twice, crosses system boundaries, or cannot be verified locally