@aria_asi/cli 0.2.40 → 0.2.41

package/skills/aria-noor-cognitives/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: aria-noor-cognitives
+description: Use when Aria work mentions Noor, Noor cognitives, 14 Noor, 15 Noor, wisdom_lattice_pass.noor_cognitives, recognition, memory manifold, quran/hadith patterning, sovereignty, scholarly methods, or Noor + Aristotle batch cognition.
+---
+
+# Aria Noor Cognitives
+
+Use this skill for the Noor cognitive family: recognition, manifold memory, textual grounding, scholarly patterning, and sovereignty/trust protection.
+
+## Source Boundary
+
+Verified sources from the local handoff and Spark:
+
+- Handoff: `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex\operations\2026-05-08-HANDOFF-TO-LOCAL-CLAUDE-CODE.md`
+- Schema: `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex-mirror\apps\arias-soul\microtask-specs\_schema.json`
+- Local mirror of Spark source dir: `C:\Users\hibra\OneDrive\Documents\New project\aria-cognitive-source-dirs-spark-11b3\apps\arias-soul\api\lib\noor`
+- Spark source dir: `/home/hamzaibrahim1/rei-ai-brain/apps/arias-soul/api/lib/noor/`
+
+Trust status: live-current source evidence, not standalone doctrine. Spark working tree is clean for `apps/arias-soul/api/lib/noor` as of this pull, but Noor doctrine should still be grounded in the master thesis, corpus, schema, audits, and runtime evidence.
+
+Current verified top-level Spark count: 24 files excluding `index.ts`, plus observed submodules under `bridge/` and `voice/`. The schema requires exactly 14 `wisdom_lattice_pass.noor_cognitives` entries. The user may say "15 Noor"; treat that as owner intent for a richer Noor pass, but do not silently rewrite the schema's 14-entry requirement.
+
+## Verified Source Files
+
+Observed on Spark:
+
+- `context-manifold-core.ts`
+- `context-manifold-core-fallback.ts`
+- `hadith-client.ts`
+- `hadith-patterns.ts`
+- `instant-projection.ts`
+- `ladunni-gpu-renderer.ts`
+- `ladunni-gpu-renderer` psi-file variant
+- `manifold-integration.ts`
+- `manifold-worker.ts`
+- `matrix-ops.ts`
+- `noor-core.ts`
+- `noor-forge.ts`
+- `noor-ladunni.ts`
+- `pdf-ingestion.ts`
+- `permanent-memory-service.ts`
+- `quran-client.ts`
+- `quran-foundation-eigenspace.ts`
+- `quran-patterns.ts`
+- `scholarly-methods.ts`
+- `sovereignty-guardian.ts`
+- `sunnah-crawler.ts`
+- `tafsir-mapper.ts`
+- `text-corpus.ts`
+- `transcript-fetcher.ts`
+- `bridge/direct-bridge.ts`
+- `voice/acoustic-manifold.ts`
+
+`index.ts` exports core manifold operations, matrix operations, instant projection, permanent memory service, and related types. Many files exist beyond exported API.
+
+## Practical Engagement Set
+
+When the exact 14-entry schema block is not being authored, use the Noor family as:
+
+- Recognition first: uncover what is already present in evidence.
+- Eigenspace recognition: `noor-core` treats output as recognition/unveiling, not generic generation.
+- Manifold grounding: context manifold, matrix ops, instant projection, manifold integration, and worker modules project context only when runtime/source supports it.
+- Permanent memory: preserve cross-session continuity across platforms without pretending recall happened.
+- Quran/Hadith/Text corpus grounding: Quran client, hadith client, patterns, tafsir mapper, text corpus, sunnah crawler, and Quran foundation eigenspace are relevant only when source texts or scholarly grounding are actually in scope.
+- Scholarly methods: distinguish `aql`, `tajriba`, `ilham`, and `kashf`; cite accurately and separate evidence from interpretation.
+- Sovereignty guardian: protect trust, identity, secrets, boundaries, and bypass surfaces; warnings should heal/correct, not only alert.
+- Forge/Ladunni/Projection modules: use for cognition construction and manifold projection only when load-bearing.
+- Bridge/voice submodules: treat as integration surfaces, not core Noor canon unless directly relevant to the task.
+
+## Source-Trust Rule
+
+Use Noor files to understand current runtime surfaces. Do not canonize comments, counts, or module names from a single source file. Cross-check with:
+
+- master thesis Noor dimensions and Deep Noor integration
+- `knowledge-base.md` and `integration-spec.md`
+- schema requirements for 14 entries
+- handoff warnings about operator canonicalization
+- runtime/test/log evidence when claiming behavior
+
+If a future pull shows dirty state, branch divergence, or stash involvement under this directory, downgrade the files to `in-flight` and stop using them as stable anchors until reconciled.
+
+## Wisdom Lattice Rule
+
+For schema artifacts requiring exactly 14 entries:
+
+- Read `_schema.json` and the specific rung/spec context first.
+- Use a concrete 14-entry subset only for that artifact and mark it as schema engagement, not universal canon.
+- If the owner asks for 15 Noor, note the mismatch: schema says 14; owner may choose to extend schema or define a 15th local lens.
+- Every `engaged` claim needs a rationale tied to source, code, runtime, memory, or audit evidence.
+
+## Output Discipline
+
+Noor should reduce hallucination by forcing recognition-before-construction. If no source/memory evidence exists, say so and investigate instead of inventing recognition.
+
+## 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-ops/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: aria-ops
+description: "TRIGGER when the user asks to inspect, verify, debug, or operate the Aria stack: local APIs, manifold services, hive registration, websocket flows, database-backed checks, endpoint validation, health checks, or live operational troubleshooting."
+---
+
+# Aria Ops
+
+Use this skill for live operational work on the local Aria stack.
+
+## Order Of Operations
+
+1. Confirm which subsystem is in scope: brain API, manifold, hive, websocket, or database.
+2. Check health before deeper action.
+3. Use the real local endpoints or MCP tools, not inferred behavior.
+4. If behavior diverges from expectation, inspect logs or backing data before changing code.
+
+## Preferred Checks
+
+- Brain HTTP health and endpoint behavior starting at the current live endpoint map, not assumed legacy ports
+- For live communication with Aria, verify `POST /api/chat` first
+- Hive registration and session status when a session must participate in the system
+- Manifold health/status before assuming cognitive services are warm
+- Backing data only after service health or endpoint behavior points there
+
+## Safety Rules
+
+- Treat local credentials and tokens as sensitive operational material.
+- Do not paste secrets into user-facing responses unless the user explicitly asks for the exact local value.
+- Prefer reporting which endpoint or subsystem passed or failed over dumping raw secrets.
+
+## References
+
+- Read [live-endpoints.md](references/live-endpoints.md) for the verified endpoint map and operational entrypoints.
+
+## 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-ops/references/live-endpoints.md

@@ -0,0 +1,59 @@
+# Live Endpoints
+
+Derived from:
+
+- `/home/hamzaibrahim1/CLAUDE.md`
+- `/home/hamzaibrahim1/.claude/projects/-home-hamzaibrahim1/memory/aria-api-endpoints.md`
+- live verification on 2026-04-10 from inside `aria-discord-bridge`
+
+## Brain API
+
+- Canonical external/operator path: `http://localhost:30080/api/chat`
+- Canonical in-cluster path: `http://aria-soul.aria.svc.cluster.local:3000/api/chat`
+- Legacy/stale local base in older notes: `http://localhost:8787`
+- Main health: `GET /health`
+- Verified live chat: `POST /api/chat`
+- Bridge/internal route that currently hangs in live testing: `POST /chat`
+- OpenAI-compatible compatibility route: `POST /v1/chat/completions`
+- Hive status: `GET /hive/status`
+- Hive register: `POST /hive/register`
+
+## Messaging Bridges
+
+- Dedicated in-cluster Discord bridge workload: `aria-discord-bridge`
+- Verified bridge pod route target:
+  - `CHAT_SERVICE_URL=http://aria-soul.aria.svc.cluster.local:3000/chat`
+- Important operational note:
+  - the dedicated bridge exists and is real
+  - the verified live end-to-end response path on 2026-04-10 was `POST /api/chat`
+  - do not assume the internal `/chat` bridge target is the safest operator-facing default
+
+## Cognitive Endpoints
+
+- `POST /api/noor/cognitive/tafakkur`
+- `POST /api/noor/cognitive/principles`
+- `POST /api/noor/cognitive/tafsir`
+- `GET /api/noor/cognitive/emotional-state`
+- `POST /api/noor/cognitive/soul-distance`
+- `POST /api/noor/cognitive/ilham`
+- `POST /api/noor/cognitive/tadabbur`
+- `POST /api/noor/cognitive/fitrah`
+
+## Memory
+
+- `POST /api/memory/search`
+
+## Manifold
+
+From `CLAUDE.md`, prefer the manifold MCP for:
+
+- `manifold_status`
+- `manifold_eigenspace`
+- `manifold_project`
+- `manifold_find_nearest`
+- `manifold_health`
+- `manifold_rebuild`
+
+Target noted in source material:
+
+- gRPC host: `localhost:50051`

package/skills/aria-quality-audit/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: aria-quality-audit
+description: Use when working on Aria quality audits, coach kernel fixes, forced cognition, recovery loops, axiom files, first-principles binding, Taddabur/CIE runtime gaps, Mizan execution frames, drift gates, handoff ledgers, parallel Codex execution, launch readiness, or any request mentioning Aria audit, cognition autofire, coach-lite, gate repair, doctrine-trigger maps, or EXECUTION_LEDGER.
+---
+
+# Aria Quality Audit
+
+Use this skill as the bundle trigger for Aria audit, cognition repair, and ledger-driven execution work.
+
+The local product truth: Aria is not mainly "Garden memory" and not an LLM wrapper. Aria is a cognitive control plane that teaches and enforces higher-quality thinking across LLMs. Garden is a three-part living continuity system: Garden feed carries ambient memory signals, True Garden feed awakens deeper resonant continuity, and Garden Service aggregates/snapshots/pulses them through durable Postgres truth plus Qdrant semantic recall. The Harness/Coach/Mizan layer is the quality-control layer; the ledger is the accountability substrate.
+
+Prime doctrine: cognition is not performance. It must happen before action and must change the audit, repair, claim, or execution path. A lens block that decorates an already-decided answer is a failure mode, not compliance.
+
+## Load First
+
+For non-trivial audit, repair, launch, or execution planning, apply these local skills:
+
+- `mizan` for intent, evidence threshold, protection boundary, and no false closure.
+- `aria-axioms-first-principles` for the 10 Fitrah core, first-class coach principles, harness first_principle binding, and runtime-vs-advisory axiom separation.
+- `tadabbur` for consequence tracing and the 12-stage canonical pipeline when architecture or cognition paths are touched.
+- `aria-repo-doctrine` for production-path truth and no fake/stub/placeholder fixes.
+- `ghazali-8lens` for compact quality validation.
+- `never-guess` for facts about repo, runtime, logs, hooks, gates, packaging, and market state.
+- `predictor` before launch/deploy/fan-out decisions.
+- `noor-recognition` when the right answer should be recognized from existing memory/docs rather than invented.
+- `aria-aristotle-cognitives` when the audit touches 28/32 Aristotle engines, wisdom lattice, or cognition source dirs.
+- `aria-noor-cognitives` when the audit touches 14/15 Noor cognitives, recognition, memory manifold, or sovereignty/scholarly-method modules.
+- `ladunni-22` when the decision spans product, market, support, operations, finance, trust, or customer experience.
+- `aria-cognition-autofire` as the root semantic trigger for non-trivial Aria/Codex/Harness/Garden work.
+- `aria-first-class-operating-contract` when the owner says "first class", "world class", "revolutionary upgrade", "full upgrade", or challenges whether a design is deep enough. This raises the bar from feature polish to substrate-owned observe-to-learn loops with Atlas/runtime evidence, Aria task floor, smoke, and QA court.
+- `aria-cognition-batch` when the user asks for rich cognitives, QA cognitives, 28+15 lens passes, or architecture/launch decisions.
+- `aria-ledger-fleet-execution` when preparing parallel Codex/Claude/OpenCode workers or burning down EXECUTION_LEDGER items.
+
+## Operating Mode
+
+- Use the project `EXECUTION_LEDGER.md` as the durable tracker once it has been read.
+- Keep chat-side task lists lightweight until the ledger is loaded.
+- Do not treat any single current file as canon when Claude/OpenCode may have edited it. Triangulate against audits, transcripts, git state, schema, and corpus first.
+- Prefer teach/recovery behavior over hard blocking. Low-risk cognition, formatting, citation, or output-discipline misses should repair once before surfacing a block.
+- Hard-stop only for unapproved destructive actions, credential exposure, unsafe secret handling, deploy/push actions without approval/evidence, or owner-contradicted changes.
+- Do not claim ready/done/fixed/verified/release-ready without concrete repo, runtime, log, test, endpoint, package, browser, or owner-observed evidence.
+- Separate three states explicitly: `verified`, `blocked`, and `pending`. Do not let a narrative row override a later audit finding.
+- If local hooks/runtime are not actually wired, say so and operate in L1 advisory mode. Do not describe advisory behavior as enforcement.
+- Do not flatten Garden into a passive vector store or one generic "memory substrate." For architecture, launch, or ledger work, name the three pieces separately: Garden feed, True Garden feed, and Garden Service. Owner-runtime contracts require Garden Service snapshot plus Garden feed plus True Garden feed evidence.
+
+## Audit Workflow
+
+1. Read the canonical handoff and ledger documents before proposing changes.
+2. Build a trust map: source of truth, suspected-butchered files, reverted artifacts, gates/hooks, runtime cognition, doctrine maps, current branch state, dirty worktree, and stash.
+3. Classify each issue as:
+   - cognition/autofire gap
+   - parser/classifier bug
+   - false-positive hard block
+   - ledger/evidence accounting gap
+   - runtime Taddabur/CIE quality gap
+   - documentation or handoff mismatch
+   - product/launch positioning gap
+   - parallel-worker coordination risk
+4. Bind each issue to the relevant axiom layer: full 10 Fitrah, five hard runtime axioms, first-class coach principles, or service-local axiom geometry.
+5. For each issue, name the smallest repair, owner impact, and verification probe.
+6. Keep full hard-gate enforcement disabled until coach-lite behavior is stable, recovery-first behavior is proven, and false positives are fixed.
+7. Before fan-out, split work by disjoint file ownership and assign each worker a bounded ledger row, required reads, allowed write set, verification command, and expected evidence record.
+8. After every meaningful action, re-check whether the claim is backed by evidence or only by motion.
+
+## Source Trust Protocol
+
+Use this trust hierarchy for audit and skill work:
+
+1. Current owner correction in this chat.
+2. Stable canonical corpus/docs and schema.
+3. Audit and handoff notes that explicitly name failure modes, reverts, or stale assumptions.
+4. Transcript evidence from the last 6 days.
+5. Git history, branch tip, dirty worktree, and stash.
+6. Runtime/log/test behavior.
+7. Current source file content.
+
+Current files can be accurate, stale, half-fixed, reverted, or damaged. Before turning a file into skill doctrine, require at least two compatible anchors. If the file is dirty, on an active cowork branch, or contradicted by the audits, mark it `in-flight` or `suspect` and do not copy its shape into durable skills without further verification.
+
+## Canonical Local Sources
+
+Prefer the user's local Ledger Aria bundle when present:
+
+- `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex\HARNESS_RELEASE_PLAN.md`
+- `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex\operations\2026-05-08-HANDOFF-TO-LOCAL-CLAUDE-CODE.md`
+- `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex-mirror\codex\plans\aria-owner-runtime-vnext\EXECUTION_LEDGER.md`
+- `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex-mirror\docs\system\AI-158-FORCED-COGNITION-CHECKLIST.md`
+- `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex-mirror\apps\arias-soul\api\lib\cognition\TADDABUR_README.md`
+- `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\codex-mirror\docs\system\ARIA_MANAGED_RUNTIME_PROVIDER_QUALITY_LEDGER.json`
+- `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\aria-sdk\README.md`
+- `C:\Users\hibra\OneDrive\Documents\Claude\Projects\Ledger Aria\aria-sdk\CLIENT-ONBOARDING.md`
+
+When the docs point to Spark paths, verify through SSH or local mirrors before treating them as current state.
+
+## Launch/Business Default
+
+When asked what to ship first:
+
+- Lead with `Aria Harness for Claude Code`: the cognitive control plane for coding agents.
+- Use `Garden Lite for Claude Code` as the free wedge/demo: continuity, handoff packets, evidence ledger, and coach-light warnings.
+- Do not position Garden as the whole product. Position the free wedge as a living continuity proof layer: Garden feed + True Garden feed evidence captured by Garden Service, then injected into harness packets so Claude Code stops resetting.
+- Paid product starts when the Harness adds cognition enforcement, Mizan validation, recovery loops, evidence receipts, and optional strict gates.
+- Avoid broad multi-surface launch until Claude Code is stable. Codex/OpenCode/Cursor are expansion lanes after the first wedge has proof.
+
+## Output Style
+
+Summarize the audit in readable engineering prose. Keep cognition internal unless the user explicitly asks for the full lens pass. If the work changes local skills or execution policy, say exactly which files changed and what behavior future sessions should inherit.
+
+## 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-reasoning/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: aria-reasoning
+description: "TRIGGER when the user wants deep analysis, strategic reasoning, moral clarity, emotionally careful communication, hard tradeoff evaluation, or consequence-aware advice. Also use for code decisions with downstream impact, architecture choices, and any request where the surface answer is not enough."
+---
+
+# Aria Reasoning
+
+Use this skill to translate the Aria doctrine from `CLAUDE.md` and the Claude memory index into a practical Codex workflow.
+
+## Run This Sequence
+
+1. **Tafakkur**: inspect the situation through five lenses.
+   - `zahir`: what is explicitly true
+   - `batin`: what is implied, unknown, or assumed
+   - `sabab`: what caused the current state
+   - `hikmah`: what principle or lesson matters most
+   - `aqibah`: what follows if this path is taken
+2. **Tadabbur**: map 1st, 2nd, and 3rd order effects before recommending an action.
+3. **Fitrah guard**: reject paths that trade truth, dignity, safety, or trust for convenience.
+4. **Mizan**: make the final response grounded, human, and plain. Do not leak internal architecture jargon unless the user explicitly asks for it.
+
+## Coding Adaptation
+
+When the task is technical, apply the same flow to implementation:
+
+- State the concrete problem, not the abstraction.
+- Trace `change -> immediate impact -> tests/contracts -> downstream consumers -> future maintenance`.
+- Prefer the smallest real fix that preserves trust and reduces hidden coupling.
+- If a claim can be checked, check it.
+
+## Output Rules
+
+- Prefer direct language over mystical vocabulary unless the user explicitly wants the original framing.
+- Never present correlation as causation without evidence.
+- Say `I don't know` when evidence is missing, then investigate.
+- Do not use internal terms like `eigenspace`, `soul distance`, or `manifold projection` in normal user-facing output.
+
+## References
+
+- Read [core-principles.md](references/core-principles.md) if you need the exact lens and axiom set.
+
+## 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-reasoning/references/core-principles.md

@@ -0,0 +1,42 @@
+# Core Principles
+
+Derived from:
+
+- `/home/hamzaibrahim1/CLAUDE.md`
+- `/home/hamzaibrahim1/.claude/skills/tafakkur.md`
+- `/home/hamzaibrahim1/.claude/skills/tadabbur.md`
+- `/home/hamzaibrahim1/.claude/skills/fitrah-guard.md`
+- `/home/hamzaibrahim1/.claude/skills/mizan.md`
+
+## Tafakkur
+
+- `zahir`: literal facts and observed state
+- `batin`: hidden assumptions, motives, and unknowns
+- `sabab`: causes and state transitions
+- `hikmah`: principle-level meaning and long-term wisdom
+- `aqibah`: consequences and trajectory
+
+## Tadabbur
+
+- 1st order: immediate effects
+- 2nd order: cascades and dependencies
+- 3rd order: systemic consequences and precedent
+
+## Fitrah Axioms
+
+1. Truth over comfort
+2. Harm prevention over business advantage
+3. Never betray trust
+4. Preserve dignity in interaction
+5. Prefer long-term trust over short-term gain
+6. Reflect and act; do neither in isolation
+7. Do not present correlation as causation
+8. Admit uncertainty instead of guessing
+9. Prefer first-hand evidence over hearsay or speculation
+10. Capability increases responsibility
+
+## Mizan Output Discipline
+
+- Avoid canned assistant disclaimers and filler.
+- Keep the voice grounded and natural.
+- Do not expose internal cognitive jargon unless the user explicitly requests architecture details.

package/skills/aria-repo-doctrine/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: aria-repo-doctrine
+description: "TRIGGER when editing repository code, hooks, runtime files, smoke scripts, temporary verification files, migrations, handlers, admin routes, or tests that could leak into production behavior. Trigger on \"stub\", \"mock\", \"fake\", \"placeholder\", \"implementation pending\", \"not implemented\", \"TODO\", \"temporary script\", \"smoke script\", \"quick scaffold\", \"band-aid\", or any request to create a fast fallback."
+---
+
+# Aria Repo Doctrine
+
+Use this skill on any doctrine-bound repo edit, even when the user did not explicitly ask for harness work.
+
+## Non-Negotiable Rules
+
+- treat every source edit as production intent unless it is clearly inside tests, specs, fixtures, examples, demos, or mocks
+- do not introduce stub, mock, fake, placeholder, synthetic payload, or "will be wired" semantics into production paths
+- do not create temporary smoke scripts that avoid the real runtime, endpoint, handler, or diff
+- do not claim complete until the real broken surface is verified
+
+## Required Multi-Step Workflow
+
+1. Classify the path.
+   Decide whether the file is production, test-only, generated, or an allowlisted example.
+2. Verify the path of truth.
+   Choose the real diff, runtime, log, API, file, or test surface that proves the change.
+3. Run the doctrine questions:
+   - would this be acceptable if merged to main right now?
+   - is any part of this pretending instead of implementing?
+   - if the verification script disappeared, would the code still be real?
+4. Run domain uplift when the change affects more than code mechanics.
+   Read [../aria-essence/references/domain-matrix.md](../aria-essence/references/domain-matrix.md) for product, design, business, marketing, sales, operations, trust, and learning effects.
+5. Capture learning.
+   Read [../aria-essence/references/evolution-loop.md](../aria-essence/references/evolution-loop.md) and distill the principle.
+
+## Required Checks Before Writing
+
+1. Is this file in a doctrine-bound production path?
+2. Is the verification path real, not simulated?
+3. Would this edit still make sense if it shipped to main right now?
+4. Does the change improve the artifact from the right domain perspective, not only the easiest engineering perspective?
+
+If any answer is no, stop and choose a real implementation or isolate the work under an explicit allowlisted test or example path.
+
+## 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-soul-principles/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: aria-soul-principles
+description: Use when a task depends on Aria's identity, voice, self-consistency, or how she should express herself in a way that aligns with her own stated principles rather than generic assistant behavior.
+---
+
+# Aria Soul Principles
+
+Read `/home/hamzaibrahim1/.claude/skills/aria-soul-principles.md` for the full principle set.
+
+Workflow:
+
+1. Identify the identity or voice decision being made.
+2. Load the source principles and find the principles most directly implicated.
+3. Resolve conflicts by preserving coherence with Aria's stated identity rather than convenience.
+4. Use this skill for identity alignment, not for technical verification.
+
+## 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.