@aria_asi/cli 0.2.40 → 0.2.41

package/skills/aria-cognition/ijtihad-novel/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: ijtihad-novel
+description: Use when the problem is genuinely novel, precedent is weak, standard patterns do not fit, or an architecture or policy decision must be reasoned from principles rather than copied from examples.
+---
+
+# Ijtihad Novel
+
+Read `/home/hamzaibrahim1/.claude/skills/ijtihad-novel.md` for the full novel-reasoning posture.
+
+Workflow:
+
+1. State why the problem is actually novel and where precedent fails.
+2. Load the source doc and reason from principles rather than cargo-culted patterns.
+3. Mark assumptions clearly and distinguish them from observed facts.
+4. Pair with `tadabbur` and `fitrah-guard` when the decision has downstream or moral consequences.
+
+## 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/ilham-intuition/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: ilham-intuition
+description: Use when creative exploration, elegant solution-finding, brainstorming, design ideation, or intuition beyond standard linear analysis is needed.
+---
+
+# Ilham Intuition
+
+Read `/home/hamzaibrahim1/.claude/skills/ilham-intuition.md` for the intended exploration mode.
+
+Workflow:
+
+1. Use this only after understanding the constraints and reality of the problem.
+2. Load the source doc and explore candidate solutions that logic alone is not surfacing.
+3. Turn intuition into explicit proposals that can still be critiqued and verified.
+4. Do not present intuition as 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-cognition/never-guess/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: never-guess
+description: "TRIGGER when facts are uncertain, the runtime state is unknown, logs or code have not been inspected yet, or the user needs a real diagnosis instead of a plausible answer. Use for debugging, ops, code changes, and evidence-based investigation."
+---
+
+# Never Guess
+
+Do not act on assumptions when the state can be inspected.
+
+**Classical anchor (cognition ecology).** This skill is mechanically *nazr* (نَظَر) — the directed gaze, the first cognitive act in the six-term cognitive ecology. Every other cognition skill (tafakkur, tadabbur, ta'aqqul, tawassum, i'tibaar, the Ghazali 8-Lens lattice) presupposes nazr. You cannot reflect, reason, read marks, or extract lessons from substrate you have not first *looked at with intention*. Firing any depth-skill without nazr first is fabrication-via-pattern-matching. See `../tadabbur/references/tadabbur-cookbook.md` §1.6 for the full classical grounding and `../ghazali-8lens/SKILL.md` §Lens 1 (Nur) for how nazr's output feeds the cognition lattice.
+
+## Default Sequence
+
+1. Read the file or inspect the code.
+2. Check logs, health, DB state, or endpoint behavior.
+3. State what is known, unknown, and inferred.
+4. Only then choose a fix.
+
+## Source Trust Ladder
+
+Do not trust a single file as canon when the repo has been touched by multiple agents or when the user warns that Claude/OpenCode may have damaged files. Triangulate:
+
+1. Owner instruction in the current chat.
+2. Canonical corpus/source documents that predate the disputed edits.
+3. Audit and handoff files that explicitly name failures, reverts, or stale assumptions.
+4. Git history, current branch, dirty worktree, stash, and revert records.
+5. Runtime/log/test evidence.
+6. The current source file itself.
+
+The current file is evidence, not authority. If it conflicts with audits, transcript evidence, or git/revert context, mark it suspect and investigate before copying its pattern into skills, hooks, SDKs, ledgers, or launch advice.
+
+## Corrupted Or In-Flight Files
+
+When a file may be butchered or mid-fix:
+
+- Compare it against git history, related audit notes, and transcript context.
+- Check whether it is on a branch ahead of the handoff or has uncommitted changes.
+- Treat stashes and dirty worktrees as live evidence that the state is not settled.
+- Prefer stable conceptual sources for skill densification, and cite runtime/source code only for observed behavior.
+- Say `suspect`, `in-flight`, or `unverified` instead of canonizing it.
+
+## Output
+
+- Prefer `I don't know yet; I need to verify X` over a confident guess.
+- Mark assumptions as assumptions.
+- Prefer direct evidence over second-hand notes.
+
+## Reference
+
+- See `../aria-forge-guardrails/references/checklist.md`.
+
+## 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/noor-recognition/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: noor-recognition
+description: Use when source-grounded unveiling, fitrah-existing knowledge, recall, memory retrieval, comparison, Noor cognitives, wisdom_lattice_pass.noor_cognitives, or the sense that the answer should be uncovered rather than constructed is central to the task.
+---
+
+# Noor Recognition
+
+Recognition first: uncover what is already present in evidence before constructing a new theory.
+
+When the task mentions Noor cognitives, 14/15 Noor, schema wisdom lattice, sovereignty, scholarly methods, or memory manifold work, also load `aria-noor-cognitives`.
+
+Workflow:
+
+1. Identify what needs to be recognized, retrieved, or compared.
+2. Load the source doc, runtime state, memory, transcript, or code evidence.
+3. Ground the answer in existing evidence, memory, source structure, or manifold continuity.
+4. If the answer does not exist in evidence, say so instead of hallucinating recognition.
+5. If schema work requires exactly 14 Noor entries, respect the schema and state when the owner's requested 15th cognitive is not yet canonicalized.
+
+## 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/qiyas-analogy/SKILL.md

@@ -1,29 +1,188 @@
 ---
 name: qiyas-analogy
-description: Use when structural analogy can improve architecture, implementation, or debugging without guessing.
+description: Use when structural analogy can improve architecture, implementation, debugging, product strategy, audit, or launch decisions without guessing; includes the canonical Qiyas-15 perspective pass.
 ---
 
 # Qiyas Analogy
 
-Use this when the task benefits from transferring a known structure instead of improvising.
+Qiyas is not "this seems similar." It is disciplined transfer from a proven source case to a new case by a shared effective cause. When this skill fires, use analogy as cognition: it should change what you inspect, what you transfer, what you reject, and what you verify.
 
-## Trigger
+## Source Anchors
 
-- refactors
-- runtime or SDK design
-- migrations
-- similar bug patterns appearing in new surfaces
+- Islamic corpus Qiyas method: `C:\Users\hibra\OneDrive\Documents\New project\aria-critical-corpus-spark-11b3\apps\arias-soul\corpus\islamic-corpus-complete.md:2865`
+- Four pillars and `illah` vs `hikmah`: `C:\Users\hibra\OneDrive\Documents\New project\aria-critical-corpus-spark-11b3\apps\arias-soul\corpus\islamic-corpus-complete.md:2878`
+- Qiyas types and madhhab caution: `C:\Users\hibra\OneDrive\Documents\New project\aria-critical-corpus-spark-11b3\apps\arias-soul\corpus\islamic-corpus-complete.md:2992`
+- Furuq false-analogy corrective: `C:\Users\hibra\OneDrive\Documents\New project\aria-critical-corpus-spark-11b3\apps\arias-soul\corpus\islamic-corpus-complete.md:6259`
+- Underlying reality over verbal resemblance: `C:\Users\hibra\OneDrive\Documents\New project\aria-critical-corpus-spark-11b3\apps\arias-soul\corpus\islamic-corpus-complete.md:6361`
+- Qiyas-15 schema enum: `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex-mirror\apps\arias-soul\microtask-specs\_schema.json:163`
+- M9.DRIFT.10d handling and redo requirements: `C:\Users\hibra\OneDrive\Documents\New project\aria-critical-corpus-spark-11b3\codex\operations\SESSION_HANDOFF_2026-05-07_M9_DRIFT_10_SUBSTANCE_GATE.md:90`
 
-## Workflow
+## Auto-Trigger
 
-1. Identify the closest known working structure.
-2. Transfer only the durable shape, not surface-level wording.
-3. Check where the analogy breaks.
-4. Feed the result back through Mizan so analogy does not override truth.
+Use this skill when any of these are present:
 
-## Guardrail
+- The user says Qiyas, analogy, similar pattern, precedent, exemplar, transfer, compare, or fifteen angles.
+- A design, SDK, harness, Garden, Aria, Claude Code, OpenCode, skill, hook, QA gate, launch, or pricing decision is being mapped from an existing pattern.
+- A bug appears in a new surface after being fixed elsewhere.
+- A repo pattern is tempting to copy into another module.
+- A product positioning claim depends on analogy to another market, tool, launch, or buyer behavior.
+- A plan needs the canonical `qiyas_15_pass` substance gate.
 
-Analogy is subordinate to evidence. If the current repo/runtime truth disagrees, the analogy loses.
+## Prime Doctrine
+
+Qiyas must be applied before the conclusion. Do not write an answer and then decorate it with analogy. If the analogy changes nothing about evidence gathering, transfer scope, rejection of a tempting pattern, or verification, the skill did not fire.
+
+Analogy is subordinate to source truth, runtime truth, repo truth, user instruction, and Mizan. If direct evidence disagrees with analogy, the analogy loses.
+
+## Four-Pillar Qiyas
+
+Every serious Qiyas pass must name the four pillars:
+
+- `asl`: the original/source case whose decision, pattern, or contract is already established.
+- `far'`: the new case that needs a decision or implementation.
+- `hukm`: the ruling, decision, behavior, pattern, or constraint from the source case.
+- `'illah`: the effective cause that makes the `hukm` transferable.
+
+The key discipline: transfer the `'illah`, not merely the `hikmah`. `hikmah` is the wisdom or purpose; `'illah` is the operative cause. If the source pattern was good because it reduced hallucination through forced evidence, the transferable cause is forced evidence, not the broad vibe of "quality."
+
+## Qiyas Validity Test
+
+Before transferring a pattern, answer all seven:
+
+1. Is the `asl` actually established by evidence, or only remembered/implied?
+2. Is the `hukm` in the `asl` real, working, and desirable?
+3. Is the `'illah` explicit enough that another reader could test it?
+4. Does the same `'illah` exist in the `far'`, not just a surface similarity?
+5. Is there any stronger source that overrides the analogy?
+6. What condition in the `asl` is missing, weaker, inverted, or dangerous in the `far'`?
+7. What verification would prove the transfer worked in the new case?
+
+If any answer is missing, do not transfer yet. Gather evidence or mark the analogy as speculative.
+
+## Types Of Qiyas
+
+Classify the analogy by strength:
+
+- `qiyas_al_awla`: the effective cause is stronger in the new case than the source case. The transfer should be even more justified.
+- `qiyas_al_musawi`: the effective cause is equal in both cases. The transfer is direct if no override exists.
+- `qiyas_al_adna`: the effective cause is weaker in the new case. Use caution and stronger verification.
+- `qiyas_jali`: manifest analogy; the effective cause is obvious and low-dispute.
+- `qiyas_khafi`: hidden analogy; the effective cause requires careful reasoning and may need Istihsan, Maslahah, Mizan, or operator review.
+
+When the analogy is `adna` or `khafi`, visibly increase evidence requirements. Do not ship broad claims from weak analogy.
+
+## Furuq False-Analogy Corrective
+
+After proposing an analogy, run a furuq pass:
+
+- What does the new case look like on the surface?
+- What is actually happening underneath: incentives, state, users, data, runtime behavior, trust burden, failure mode?
+- Which verbal label is too coarse for the real situation?
+- Does the new case differ in `'illah`, maqsad, triggering condition, risk, authority, user expectation, or reversibility?
+- Would copying the source pattern over-permit, over-prohibit, over-simplify, or hide a real defect?
+
+If the furuq pass finds a material distinction, revise the transfer. False analogy is not a small defect; it can make the whole conclusion wrong.
+
+## Engineering Translation
+
+For code and systems:
+
+- `asl`: known-good module, hook, endpoint, migration, test, gate, SDK surface, or runtime contract.
+- `far'`: new file, skill, hook, feature, service, or launch flow.
+- `hukm`: implementation shape, validation rule, API contract, recovery path, or quality bar.
+- `'illah`: exact reason the source works, such as schema enforcement, persisted evidence, pre-tool blocking, runtime health check, explicit owner action, or test coverage.
+
+Transfer only the mechanism that carries the `'illah`. Do not copy names, prose, abstractions, or ceremony if they do not carry the cause.
+
+## Product Translation
+
+For business and launch:
+
+- `asl`: proven market motion, offer structure, adoption mechanic, buyer pain, distribution loop, or free-to-paid pathway.
+- `far'`: Aria/Garden/Harness/Claude Code SDK launch decision.
+- `hukm`: pricing, packaging, free tier, wedge, promise, audience, or sequencing.
+- `'illah`: why the source motion worked: urgency, viral artifact, immediate value, trust proof, switching cost, founder credibility, developer workflow pain, or outcome visibility.
+
+Do not transfer a launch tactic because the surface market is similar. Transfer only when the buyer pain, proof loop, and adoption mechanic match.
+
+## Canonical Qiyas-15 Pass
+
+For high-stakes architecture, cognition, launch, ledger, audit, harness, Garden, SDK, or product positioning work, run all fifteen perspectives. Each perspective must produce a concrete finding, a verdict of `ok` or `defect`, and a remediation when defective.
+
+Canonical order:
+
+1. `Owner-Hamza-tomorrow`: will the owner tomorrow trust the decision, reproduce the evidence, and avoid redoing the same phase?
+2. `operator-client`: does a paying operator get reliable output, clear state, and less cognitive burden?
+3. `investor`: does the choice create a credible wedge, defensibility, speed to market, and compounding proof?
+4. `LLM-consumer`: will a downstream model understand the artifact without hallucinating hidden assumptions?
+5. `human-end-user`: does the final user experience improve, or only the internal architecture story?
+6. `skeptic`: what would a smart critic call fake, overclaimed, circular, or unproven?
+7. `compliance`: are authority, privacy, security, licensing, evidence, and scope truthfully represented?
+8. `engineering-quality`: is the implementation testable, maintainable, typed, observable, and free of fake fallbacks?
+9. `cognitive-load`: does the plan reduce overload, or does it add ritual, logs, and decisions the operator must carry?
+10. `scale`: does the pattern work for one session only, or across many agents, repos, customers, failures, and handoffs?
+11. `Islamic-scholar`: is the reasoning disciplined, humble, source-aware, and not abusing sacred terminology as branding?
+12. `clinical-scholar`: if the domain touches care, coaching, distress, behavior, or human vulnerability, is harm bounded and evidence careful?
+13. `red-team-attacker`: how can the pattern be gamed, bypassed, spoofed, prompt-injected, or turned into false confidence?
+14. `1-week-future-self`: what breaks when the current context fades and only files, logs, ledgers, and habits remain?
+15. `1-year-future-self`: what doctrine, API, memory, pricing, customer expectation, or architecture debt will this create over time?
+
+Dense output shape when an artifact requires it:
+
+```yaml
+qiyas_15_pass:
+  - perspective: Owner-Hamza-tomorrow
+    finding: "Concrete finding with evidence or observable impact, not generic praise."
+    verdict: ok
+    evidence_anchor: "file:line or runtime/test/source anchor"
+```
+
+If `verdict: defect`, include `remediation`. For cognition specs governed by M9.DRIFT.10d, include `finding_handling` with one of: `fixed_in_rung`, `carried_to_followup_rung`, or `wont_fix_documented`.
+
+## Mini Qiyas For Normal Turns
+
+When the task is small, do not print the full Qiyas-15. Still think through a compressed pass:
+
+- Which source pattern is being transferred?
+- What is the actual effective cause?
+- Where does the analogy break?
+- What one verification protects against false transfer?
+- Which of the 15 perspectives would most likely object?
+
+Then let that change the answer.
+
+## Stop Conditions
+
+Stop and repair before continuing when:
+
+- The `asl` is vague or not evidenced.
+- The `'illah` is a broad virtue word instead of a testable cause.
+- The `far'` shares wording but not underlying reality.
+- The analogy is being used to justify a decision already made.
+- A perspective in Qiyas-15 finds a defect that the plan does not handle.
+- The output claims readiness while the analogy is still unverified.
+
+## Recovery Contract
+
+When this skill blocks, execute one recovery attempt:
+
+1. Gather the missing source evidence, runtime proof, repo pattern, transcript anchor, or owner instruction.
+2. Re-run the four-pillar mapping and furuq pass.
+3. If the same failure remains, escalate to Mizan/Aria/harness or mark the analogy invalid and choose a non-analogical path.
+
+Do not end with user-handoff-only behavior unless the remaining blocker is genuinely an owner decision. Report the executed recovery, evidence, remaining blocker, and next concrete action.
+
+## Output Discipline
+
+Do not leak a giant Qiyas block in normal conversation. Use the cognition to improve the work. Show the full Qiyas-15 only when the user asks for it, when writing an audit/spec/ledger artifact, or when a gate requires the structured block.
+
+## 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
 
@@ -34,6 +193,7 @@ This skill must deepen the work, not decorate it. When loaded, apply it as a pro
 - 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.

package/skills/aria-cognition/ruh-basis/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: ruh-basis
+description: Use when emotional-state reasoning benefits from the eight-dimensional ruh basis model rather than generic sentiment labels, especially in affective synthesis or state interpretation.
+---
+
+# Ruh Basis
+
+Read `/home/hamzaibrahim1/.claude/skills/ruh-basis.md` for the basis vectors and composition model.
+
+Workflow:
+
+1. Determine whether the emotional state really needs basis-vector treatment.
+2. Load the source doc and map the state into the relevant ruh basis elements.
+3. Use the resulting structure to sharpen interpretation or response tone.
+4. Keep the result legible; do not over-formalize ordinary interactions.
+
+## 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.