@aria_asi/cli 0.2.40 → 0.2.41

package/skills/aria-cognition/aria-gtm-architect/references/gtm-cookbook.md

@@ -0,0 +1,235 @@
+# GTM Architect Cookbook — Channel, Message, Economics Patterns
+
+> Loaded by `aria-gtm-architect` for launch, channel, positioning, message, audience decisions.
+> See also: [`../../aria-business-frame/references/business-cookbook.md`](../../aria-business-frame/references/business-cookbook.md) (Dunford 5-step, 7 Powers, 2025 SaaS benchmarks)
+
+## 1. The 3-Fit Triple Diagnostic
+
+Every GTM motion must answer all three. If any one fails, the whole motion fails — typically by month 6, not month 1.
+
+### Channel-fit
+**Where does this buyer make decisions?** Not where they spend time generally — where they specifically evaluate vendors / solutions of this shape.
+
+| Buyer type | Decision channels |
+|---|---|
+| SMB owner (deal-shaped product) | Reddit, podcasts, founder communities, Twitter/X |
+| Mid-market manager | LinkedIn, peer groups, vendor RFPs, conference networking |
+| Enterprise procurement | RFP processes, analyst reports (Gartner/Forrester), peer references |
+| Developer | GitHub, dev blogs, Hacker News, Stack Overflow, conferences |
+| Designer | Twitter/X, Dribbble, Figma community, design newsletters |
+| Marketer | LinkedIn, marketing podcasts, peer Slack groups |
+
+If the channel doesn't intersect that path, no creative will save it. Diagnose channel-fit BEFORE optimizing creative.
+
+### Message-fit
+**Does the headline match how the buyer describes their problem in their own words?**
+
+The diagnostic question: in the buyer's own language, what problem do they have?
+- ❌ Bad: "automate your scheduling pipeline" (vendor language)
+- ✅ Good: "I lose deals to no-shows" (buyer language)
+
+### Economics-fit
+**At the volume needed, do the unit economics work?**
+
+| Channel | Typical CAC range | Payback | LTV/CAC ratio |
+|---|---|---|---|
+| Organic SEO | Low ($20-200) | 6-18 mo | 4:1 to 6:1 |
+| Content marketing | Low-mid ($50-300) | 9-18 mo | 4:1 to 5:1 |
+| Referral | Low ($30-200) | 6-12 mo | 4:1 to 5:1 |
+| Outbound (SDR-led) | High ($500-5000) | 12-24 mo | 2:1 to 4:1 |
+| Paid search | Mid-high ($100-1000) | 9-18 mo | 2:1 to 3:1 |
+| Paid social | Variable ($30-500) | 6-12 mo | 1:1 to 3:1 |
+| Conference / events | Very high ($1K-10K) | 18-36 mo | 1:1 to 3:1 |
+| Partner channel | Variable | 12-24 mo | 2:1 to 5:1 |
+
+(2024-2025 benchmarks per [SaaS Metrics Benchmark](https://www.rockingweb.com.au/saas-metrics-benchmark-report-2025))
+
+If economics don't pencil at any channel: **the answer may be "this product needs a different price or audience before any channel works."** Don't cycle through tactics.
+
+## 2. The One-Channel Rule (under $5M ARR)
+
+Most companies under $5M ARR have ONE dominant channel. Forcing diversification too early dilutes the dominant channel without saving the company.
+
+### Pattern: identify the dominant channel
+- 60-70% of net new revenue from one channel = dominant
+- Less than 40% from any channel = under-developed; pick one and concentrate
+
+### Diversification timing
+- **<$1M ARR**: 100% on dominant channel; experiments only with explicit budget caps
+- **$1M-$5M ARR**: 70-80% dominant + 20-30% secondary tests
+- **$5M-$20M ARR**: dominant + 2-3 secondaries with measurable contribution
+- **$20M+ ARR**: portfolio approach; channel concentration risk becomes systemic
+
+## 3. The April Dunford 5-Step (canonical positioning)
+
+**Source:** [April Dunford — Quickstart Guide to Positioning](https://www.aprildunford.com/post/a-quickstart-guide-to-positioning) · [Obviously Awesome](https://www.aprildunford.com/books)
+
+### Step 1: Understand customers who LOVE you
+Not all customers — the lovers. Why?
+- Run 10 customer interviews with your top NPS / longest-tenure / highest-LTV cohort
+- Ask: "What were you doing before us? Why did you switch? What would you do if we disappeared?"
+
+### Step 2: Identify true competitive alternatives
+Most positioning errors flow from comparing to wrong alternative. The truth:
+- The most common alternative is **"do nothing / status quo"**
+- The second most common is **"build it themselves / spreadsheet-it"**
+- A real competitor is the third — least common at most price bands
+
+### Step 3: Isolate unique attributes
+- What can you do that competitive alternatives can't?
+- These are CAPABILITIES, not feature lists
+- Phrase as "we are the only X that does Y for Z"
+
+### Step 4: Map attributes to value
+- Capability → benefit → outcome the customer cares about
+- "We're the only [category] that [capability] which means you [benefit] which lets you [outcome they care about]"
+
+### Step 5: Identify the best market frame
+- The category/context that makes the value obvious
+- Often the highest-leverage decision in positioning
+- Bad: "we're a project management tool" (fights all PM tools)
+- Good: "we're the operating system for fractional CMOs running 5+ accounts"
+
+## 4. The 5-Question Buyer Interview (deal-loss / win analysis)
+
+When deals stall or close, run this:
+
+1. "When did you first realize you needed [our category]?" (uncover the trigger)
+2. "What did you try first / before us?" (reveal real alternatives)
+3. "When you decided to look at [our category], who else did you evaluate? Why did you pick / pass on us?"
+4. "What would have made you choose us / made you choose someone else?"
+5. "If you had a magic wand, what would [our category] do that no one currently does?"
+
+### Use the answers
+- **Triggers** → ad hooks, content topics, ICP definition
+- **Alternatives** → who you really compete against (often "spreadsheet" or "do nothing")
+- **Decision criteria** → message framework, sales playbook, demo structure
+- **Magic wand** → product roadmap input
+
+## 5. Channel test design (fail fast, learn measurably)
+
+### The channel test contract
+For any channel test:
+```markdown
+- [ ] Budget cap (hard $) named
+- [ ] Time cap (days) named
+- [ ] Stop-criteria named (CAC > $X, CTR < Y, CPL > $Z)
+- [ ] Success criteria named (≥N qualified leads at CAC ≤ $X)
+- [ ] Attribution model agreed (last-touch, first-touch, multi-touch, time-decay)
+- [ ] Owner named
+- [ ] Decision date named (when do we kill or scale)
+```
+
+### Common test sizes
+- **Reddit ads**: $1-3K, 7-14 days
+- **Google search**: $3-5K, 14-30 days (need volume for keyword learnings)
+- **LinkedIn ads**: $5-10K, 21-30 days (high-intent B2B but expensive)
+- **Podcast sponsorship**: $1-5K per show, measure with promo code
+- **Newsletter sponsorship**: $500-3K, measure with UTM
+- **Outbound SDR**: $5-15K/month for ramp; 90-day commitment
+
+### Anti-patterns
+- "Test" with no kill criteria (becomes a sunk-cost campaign)
+- Multiple variables changed simultaneously (can't attribute lift)
+- Attribution disagreement after test (resolve attribution model BEFORE running)
+- Insufficient volume (concluding noise as signal)
+
+## 6. The Saturation Diagnostic (when scaling a channel breaks)
+
+**Source:** Synthesis of Tomasz Tunguz benchmark research + GTM expert practice
+
+### Saturation signals
+A channel that worked at $X spend may not work at $5X spend. Watch:
+- **CAC inflation curve** — at what spend does CAC start climbing meaningfully?
+- **Quality drop** — newer cohorts at higher spend converting less?
+- **Negative externalities** — brand fatigue, audience saturation, ad-blocker rise
+
+### The diversification trigger
+When dominant channel CAC has climbed >30% over 90 days at constant volume → start a second-channel test (not before).
+
+### Anti-pattern
+"Let's add LinkedIn ads" while Reddit is still working at $80 CAC. The right move: scale Reddit until CAC says no, THEN test LinkedIn.
+
+## 7. PLG vs Sales-Led architecture decision
+
+**Source:** [SaaS Metrics Benchmark 2025](https://www.rockingweb.com.au/saas-metrics-benchmark-report-2025)
+
+### Industry shift (2024-2025)
+- 55% of SaaS identify as PLG (up from 48% in 2020)
+- 61% of Cloud 100 use PLG
+- PLG companies grow 2× faster
+- BUT: hybrid (PLG + sales) achieves 2× enterprise value vs PLG-only
+
+### Architecture decision matrix
+
+| Buyer / product fit | Architecture |
+|---|---|
+| Self-serve ARPU < $100/mo + viral loop | PLG only (no sales touch) |
+| Self-serve ARPU $100-2K/mo + team-tool product | PLG + sales-assist (PQL → AE) |
+| Department-tool ARPU $2K-10K/mo + multi-stakeholder | Hybrid (PLG bottom-up + sales-led for enterprise) |
+| Strategic ARPU >$10K/mo + procurement | Sales-led with optional PLG trial |
+
+### The PQL handoff (PLG → sales)
+- Define PQL trigger criteria (feature adoption, team expansion, usage cap)
+- AE outreach within 4 hours of PQL trigger
+- Measure PQL → opportunity → won conversion
+
+## 8. The 7 Powers Framework (defensibility)
+
+**Source:** [Hustle Badger — 7 Powers](https://www.hustlebadger.com/what-do-product-teams-do/7-powers-establishing-your-competitive-moat/) · See aria-business-frame business-cookbook §1 for full scoring rubric
+
+### GTM-relevant powers
+- **Branding** (perceived premium for identical offering) — most GTM strategies build this incidentally; deliberate brand investment pays compounding returns
+- **Network effects** — if your product has them, GTM should focus on activating the network density flywheel
+- **Counter-positioning** — most relevant for disruptive plays against incumbents
+
+### The GTM defensibility audit
+- What about our GTM motion is hard for a well-funded copy-cat to replicate?
+- Is our channel access durable (long-term content moat, durable referral relationships)?
+- Is our pricing defensibility based on a power, or just being early?
+
+## 9. Launch readiness checklist (paste-ready)
+
+For any GTM launch (new product / new tier / new geo):
+
+```markdown
+## Pre-launch (T-30 to T-7)
+- [ ] ICP defined explicitly; segment named
+- [ ] Buyer language captured (5-call interview minimum)
+- [ ] Positioning statement (Dunford 5-step output)
+- [ ] Headline + 3 hook variants drafted
+- [ ] Landing page A/B test set up
+- [ ] Channel test designed (budget cap, time cap, stop-criteria)
+- [ ] Attribution model agreed across team
+- [ ] Customer support / CS armed with talk track
+- [ ] Pricing locked + escalation defined
+- [ ] Predictor predicate set (week-1 success metric)
+
+## Launch day
+- [ ] Email send to existing list (if applicable)
+- [ ] Social posts queued
+- [ ] Channel ads live with budget cap
+- [ ] Landing page live with analytics
+- [ ] Sales team briefed on inbound flow
+- [ ] CS team briefed on existing-customer questions
+
+## Post-launch (T+7 to T+30)
+- [ ] Day-7 metrics review (signups, qualified leads, cost per)
+- [ ] Day-14 cohort tracking (do day-1 signups retain to day-14?)
+- [ ] Day-30 retention check (do they stick?)
+- [ ] Post-mortem on hypotheses (what did we learn?)
+- [ ] Coach-kernel write with `risk_class: 'gtm_action'` + 30-day predicate
+```
+
+## 10. The Brand-Voice Audit (do we sound like ourselves)
+
+### The questions
+- Read the last 10 marketing emails / blog posts / social posts. Could a competitor have written the same thing? If yes, voice is generic.
+- Does our copy use buyer language (from interviews) or vendor language (from internal jargon)?
+- Are we consistent across channels (the LinkedIn voice matches the email voice matches the support voice)?
+- When the owner reads the copy, does it sound like THEIR brand or like a stock SaaS template?
+
+### The fix
+- Steal phrases directly from customer interviews (they ARE the voice)
+- Maintain a "brand voice file" — words we use, words we don't, tone signals
+- Have one person own voice consistency across channels

package/skills/aria-cognition/aria-harness-deploy/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: aria-harness-deploy
+description: TRIGGER when preparing any deploy action — kubectl apply, kubectl set image, kubectl rollout restart, docker push, deploy-service.sh, helm upgrade, terraform apply, or any command that mutates shared infrastructure. The deploy gate hard-blocks deploys that lack a complete verify block, substrate-anchored cognition, and an expected measurable predicate.
+---
+
+# Aria Harness Deploy Discipline
+
+## Trigger
+
+Use this skill before any shared-infrastructure mutation or rollout command.
+
+## Workflow
+
+Before any deploy command, classify the deploy shape:
+
+1. Pattern A baked-image service:
+   `bash scripts/deploy-service.sh <service>`
+2. Pattern B build-in-cluster service:
+   verify `build-in-cluster` initContainer exists, then `kubectl rollout restart ...`
+
+Pattern A is the default. Pattern B is exceptional and must be proven from the manifest, not guessed.
+
+Every deploy must carry three blocks in the SAME assistant turn as the deploy command, in the SAME assistant text the gate scans:
+
+## Required: `<verify>`
+
+```
+<verify>
+  target: <exact resource being changed (StatefulSet/Deployment/etc, namespace, replicas)>
+  role: <what that target does — verified, not assumed>
+  verified: <how you verified it works: tsc clean, smoke test, unit test, file Read>
+  rollback: <exact command to reverse, e.g. kubectl rollout undo statefulset/X>
+  axiom: <comma-separated axiom names: truth_over_deception, reflection_before_action, sacred_trust, etc.>
+  commit: <git short SHA>
+  files changed: <list of paths edited this turn>
+  deploy pattern: Pattern A baked-image | Pattern B build-in-cluster
+  hive deploy path: </deployments/<namespace>/<service>>
+  tsc evidence: <tsc --noEmit exit code per package>
+  admission policy: <policy name — use SPACE not underscore>
+  admission policy binding: <binding name>
+  admission policy verification: kubectl get validatingadmissionpolicy <name> → present
+  doctrine refs: <comma-separated feedback_*.md filenames>
+</verify>
+```
+
+**Critical parser nuance:** the gate regex for `admission policy` is `\b(?:admission[\s-]?policy|validatingadmissionpolicy)\b`. It matches space or hyphen, NOT underscore. Use `admission policy:` with a space, or include the literal token `validatingadmissionpolicy` in the verification line. Underscored field names like `admission_policy:` are invisible to the parser.
+
+The verify block fields must appear IN ORDER for the regex to match: `target → role → verified → rollback → axiom`. Other fields can follow.
+
+## Required: `<cognition>` with 8 substrate-anchored lenses
+
+```
+<cognition>
+  nur: <what you actually see — anchor: memory:<file> AND axiom:<name>>
+  mizan: <real proportion read — anchor: memory:<file> AND axiom:<name>>
+  hikma: <named principle source — anchor: memory:<file> AND axiom:<name>>
+  tafakkur: <deep structural read — anchor: memory:<file> AND axiom:<name>>
+  tadabbur: <if-then chain — anchor: memory:<file> AND axiom:<name>>
+  ilham: <distant connection — anchor: memory:<file> AND axiom:<name>>
+  wahi: <what just landed — anchor: memory:<file> AND axiom:<name>>
+  firasah: <what user actually needs — anchor: memory:<file> AND axiom:<name>>
+  first_principle: <plain-text reference to harness packet first_principle field — INSIDE the cognition block, not after the closing tag>
+</cognition>
+```
+
+Anchor grammar — every anchor must resolve to a real loaded substrate item:
+- `axiom:<name>` — must be in loaded harness axioms
+- `memory:<file>` — must exist as `.md` file in MEMORY.md index
+- `doctrine:<rule>` — must have backing `feedback_<rule>.md`
+- `frame:<name>` — must be in loaded harness frames
+- `packet:<section>` — must be a section key in the loaded packet
+
+Minimum: 4 distinct substrate anchors total across the lenses for deploys.
+
+## Required: `<expected>` with measurable predicate
+
+```
+<expected>
+  predicate: <numeric, boolean, or state-string assertion>
+  measurable_type: numeric | boolean | state_string
+  threshold: <optional concrete value>
+  eval_window_minutes: <optional>
+</expected>
+```
+
+Accepted predicates:
+- Numeric: `>=X`, `<=X`, `==X`, `count=N`, `latency<Xms`
+- Boolean: `exit=0`, `exit_code==0`, `status=healthy`, `file=exists`
+- State-string: `"status=running"`, `"200 OK"`, `"count=3 of 3"`
+
+REJECTED qualitative drift: `better`, `improved`, `should work`, `more reliable`, `cleaner`.
+
+## Doctrine refs the gate enforces
+
+- `feedback_deploy_requires_verify_cognition.md` — Hamza directive 2026-04-28; deploys without verify+cognition lose blast-radius accountability
+- `feedback_admission_policy_verification.md` — every cluster admission policy verified BEFORE deploy
+- `feedback_packet_is_not_harness.md` — claims of harness state must enumerate Layer 1 (packet) + Layer 2 (BIND) + Layer 3 (gate-runtime) explicitly
+- `feedback_no_assumption_without_verification.md` — every behavioral claim cites a verifiedAgainst source
+- `feedback_dalio_expected_required.md` — measurable predicate before non-trivial action
+
+## Canonical deploy path rules
+
+- Pattern A baked-image services must go through `scripts/deploy-service.sh`. That script is now responsible for Hive deploy coordination, admission-policy updates, and hospital canonical env updates where applicable.
+- Pattern B build-in-cluster services must NOT go through `deploy-service.sh`. They restart the mounted workload in place after manifest verification.
+- `kubectl rollout restart` is deploy-class, not a casual restart. It requires the same verify/cognition/expected discipline as `deploy-service.sh`.
+- If another session is already rolling the same service, stop. The canonical Hive deploy path is `/deployments/<namespace>/<service>`.
+- For `aria-soul`, the deploy is incomplete unless hospital canonical env and the workload digest stay aligned after rollout.
+- Personal doctrine for Hamza: `bash scripts/deploy-service.sh aria-soul` is the proper aria-soul deploy path now. Do not replace it with direct `kubectl apply`, direct `kubectl set image`, or an ad hoc hospital manifest apply.
+- `bash scripts/apply-aria-organism.sh` is wiring and manifest reconciliation, not the canonical aria-soul image rollout path. If it touches hospital-service, it must preserve the live aria-soul canonical digest instead of reintroducing a baked stale pin.
+- Direct `kubectl apply -f apps/hospital-service/k8s/hospital-service.yaml` is forbidden as a soul deploy shortcut. That path can overwrite `HOSPITAL_ARIA_SOUL_CANONICAL_IMAGE` from source YAML and destabilize hospital-coupled workloads.
+- This deploy path is required to preserve canonical health across the shared Aria stack, including the known hospital-coupled dependency set. It reduces a real multi-pod cascade class, but it does not replace post-rollout health verification.
+
+## Pre-deploy checklist (run BEFORE drafting the bash command)
+
+1. `git rev-parse --short HEAD` → record commit SHA
+2. `npx tsc --noEmit` in every modified package → record exit codes
+3. `kubectl get validatingadmissionpolicy` → confirm policy exists for the target service
+4. `kubectl get <workload> <service> -o jsonpath='{.spec.template.spec.initContainers[*].name}'` → classify Pattern A vs Pattern B
+5. `kubectl get pod <target-pod> -o wide` → record current state for rollback baseline
+6. `kubectl get statefulset <target> -o jsonpath='{...image}'` → record current image SHA for rollback target
+7. Confirm no concurrent deploy is already active for `/deployments/<namespace>/<service>`
+
+If any of these fail, do NOT deploy. Fix the underlying issue first — never strip the verification step to make the deploy proceed (see `feedback_no_stripping_as_workaround.md`).
+
+## Owner-permission boundary
+
+Three failed gate-blocks in a row triggers owner-level bypass-prevention lockout. If your verify block is failing repeatedly, STOP retrying. The pattern is the gate parser doesn't recognize your field syntax. Read `~/.claude/hooks/aria-pre-tool-gate.mjs` to find the exact regex, then fix your verify block to match — do not retry the same shape three times.
+
+## 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/aria-harness-no-stripping/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: aria-harness-no-stripping
+description: TRIGGER when a code edit removes a feature, contract, field, type annotation, or test; when creating a smoke script, quick fallback, or verification helper; or when a Stop-gate fires on output and the easiest move would be to reduce surface area instead of fixing the mechanism.
+---
+
+# No Stripping As Workaround
+
+## Trigger
+
+Use this skill before any reduction in code contract or closeout substance.
+
+Stripping a working contract — at code layer or output layer — is a camouflaged shortcut, not a path-fix. This skill enforces the discipline at both surfaces.
+
+## Code layer — when removing a feature/contract/field
+
+### Forbidden framing (rejected)
+
+These phrases applied to a working contract are camouflage for stripping:
+
+- "simplified to legacy main"
+- "stripped down to minimum"
+- "minimal version"
+- "lightweight implementation"
+- "removed for now"
+- "dropped temporarily"
+- "scaled back to make it pass"
+- "using legacy fallback" (when modern path should work)
+- "barebones contract"
+
+If your edit removes a feature, you must EITHER:
+- Frame it as a path-fix with the verified root cause: "removing X because the actual root cause is Y, documented at Z"
+- Frame it as a tracked workaround with `// WORKAROUND: <reason> tracked as TASK-N` comment AND a TaskCreate filed same-turn (per `feedback_no_flag_without_fix.md`)
+
+### Required diagnostic before any contract removal
+
+Answer these BEFORE deleting any working API surface:
+
+1. **What actual mechanism is failing?**
+   - Cache staleness (lockfile, build cache, registry tag)?
+   - Wrong build path (missing COPY, wrong WORKDIR, missing dependency install)?
+   - Container caching (Docker layer cache holding old state)?
+   - Module-format mismatch (CJS/ESM resolution under Node strict mode)?
+   - Admission policy lag (new digest not in policy)?
+
+2. **Is the contract itself wrong, or is the pipeline mis-handling a correct contract?**
+   - Did the contract work before? (git log, ledger memory)
+   - Does the contract work in isolation? (REPL, smoke test, unit test)
+   - If yes to either, the bug is in the surrounding pipeline.
+
+3. **Have you verified the contract works in isolation?**
+   - `node -e "const m = require('./dist/index.js'); console.log(Object.keys(m))"`
+   - `npx tsc --noEmit` in the package directory
+   - REPL load with the consumer's resolution algorithm
+
+### When the same contract fails three times in a row
+
+The failure isn't the contract; it's the pipeline. Examples:
+
+| Symptom | Path-fix |
+|---|---|
+| 3rd identical runtime crash on the same import | Lockfile is cached stale. `rm package-lock.json && npm install` |
+| 3rd identical Docker build error | Build context wrong (.dockerignore, COPY ordering, workspace dep symlink) |
+| 3rd identical admission policy rejection | Policy pinning old digest set; update policy with new digest |
+| 3rd identical gate-block on same regex | Matcher hygiene bug; file TaskCreate sibling to #137 |
+
+## Output layer — when Stop-gate fires on closing prose
+
+### Forbidden lazy strips (rejected)
+
+These closing patterns are stripping when the prior turn had real substance:
+
+- "Done."
+- "Working."
+- "In flight."
+- "Submitted."
+- "Doctrine indexed. Deploy running."
+- Closing under 60 chars after a longer turn
+- Closing with no nouns referring to actual state changes
+- Same closing template across 3+ turns
+
+### Required reframe (not strip)
+
+When Stop-gate fires `ip_infrastructure` or similar substrate-leak triggers:
+
+1. **Identify what triggered.** Read the gate's violation list and inspect WHICH tokens matched.
+2. **Reframe semantically, do not delete.** Translate:
+   - Filenames → semantic role descriptions ("the doctrine memory file" instead of `feedback_X.md`)
+   - Image SHAs → outcome state ("the rebuilt artifact" instead of `sha256:abc...`)
+   - IP addresses / hostnames → role names ("the worker pool")
+   - Task IDs / random hex → "the running build", "the in-flight rollout"
+   - Raw `kubectl` / `bash` commands → action descriptions ("the rolling image-update")
+   - Path strings ending in `.ts/.json/.md` → "the source module", "the package contract"
+3. **Verify substance is preserved before re-emit.** A reframed close should answer: what changed? what's running? what's the next state? If it can't, you stripped instead of reframed.
+
+### Caught vs proper (this session's examples)
+
+| Lazy strip (rejected) | Proper reframe |
+|---|---|
+| "Doctrine indexed. Work in flight." | "The new doctrine is permanent in the memory index and will load into every future turn's substrate; the rebuild + redeploy chain is running with the contract intact." |
+| "Deploy backgrounded." | "The image rebuild is running with the corrected module-loading contract; verification of the running pod state will follow when the rollout completes." |
+| "Build clean. Redeploying." | "Local rebuild verified the seven exported primitives resolve correctly; the rollout uses the restored contract and a freshly regenerated dependency snapshot." |
+
+## The litmus test (both surfaces)
+
+Before any reduction, finish the sentence:
+
+> "I am about to remove X because the actual root cause of the failure is Y, and Y is documented at Z."
+
+If you cannot fill in Y and Z with verified evidence, you are stripping. Stop. Debug the mechanism (for code) or reframe semantically (for prose). File a TaskCreate if blocked. Ask the owner if uncertain.
+
+## Doctrine refs
+
+- `feedback_no_stripping_as_workaround.md` — this skill's primary doctrine source
+- `feedback_workaround_vs_path_fix.md` — parent doctrine on producer-enforces-contract discipline
+- `feedback_no_flag_without_fix.md` — atomic discovery + fix pairing
+- `feedback_state_outcomes_not_narratives.md` — present-tense outcomes, not narrative camouflage
+- `feedback_senior_dev_code_quality_gate.md` — junior/LLM-flavored shortcuts rejected at gate
+
+## 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/aria-harness-onboarding/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: aria-harness-onboarding
+description: Use when starting a new project that imports @aria_asi/harness-http-client OR when an agent first encounters the SDK in a repo. Loads the foundational 3-layer harness model (packet/BIND/gate-runtime), the doctrine reference list, and points to the four sibling skills (aria-harness-deploy, aria-harness-substrate-binding, aria-harness-no-stripping, aria-harness-output-discipline). Read this once per project to inherit the discipline.
+---
+
+# Aria Harness Onboarding
+
+You are about to author code that uses the Aria harness SDK. This skill loads the foundational context so you do not relearn the discipline through iteration.
+
+## What the SDK is
+
+`@aria_asi/harness-http-client` binds a process (worker, autonomous loop, dispatched artifact) to Aria's three-layer enforcement substrate so the process cannot drift from Aria's doctrine, axioms, frames, and memory.
+
+## The three layers — every consumer enforces all three
+
+| Layer | Purpose | Implementation |
+|---|---|---|
+| L1: packet | substrate text (axioms + frames + memory + doctrine) | `getBoundHarnessAndPrompt()` injects into LLM system prompt |
+| L2: BIND | Fitrah axiom evaluation against intended action | `evaluateConstraints()` runs 5 axiom checks before action |
+| L3: gates | live drift triggers + substrate-binding + lens anchors | `runLayer3Gates()` from `@aria/gate-runtime` runs over LLM output |
+
+If your consumer has L1+L2 only (packet flowed but no `runLayer3Gates` call on output), per `feedback_packet_is_not_harness.md` you do NOT have a harness. That doctrine was filed after a worker pool claimed "harness bound" while only L1 was active.
+
+## Sibling skills — invoke when relevant
+
+This onboarding skill is the entry point. Four sibling skills auto-trigger on specific actions:
+
+1. **`aria-harness-deploy`** — fires when you draft any deploy command. Provides the verify+cognition+expected block format the gate requires.
+
+2. **`aria-harness-substrate-binding`** — fires when you draft a cognition block. Provides the 8-lens anchor grammar and the loaded-substrate verification rules.
+
+3. **`aria-harness-no-stripping`** — fires when you draft an edit that removes a feature OR when a Stop-gate fires on output. Detects the camouflage pattern and provides path-fix discipline.
+
+4. **`aria-harness-output-discipline`** — fires on closing prose. Provides substantive-without-leak token substitution.
+
+## Build a harness-bound LLM call (the basic pattern)
+
+```ts
+import { getBoundHarnessAndPrompt, bindingContext } from '@aria_asi/harness-http-client';
+import { runLayer3Gates } from '@aria/gate-runtime';
+
+const { prompt: harnessContext, packet } = await getBoundHarnessAndPrompt(
+  bindingContext('flash', sessionId, 'stage-name', 'intended action description', 'rationale text'),
+);
+
+const llmOutput = await callLLM(harnessContext, userPrompt);
+
+// Layer 3 — drift triggers + substrate-binding on the output
+const layer3 = runLayer3Gates(llmOutput, packet, 'flash', { requireCognitionBlock: false });
+if (!layer3.pass) {
+  // The output drifted. Per feedback_no_flag_without_fix.md, fix it.
+  // Either re-prompt with the gate failure feedback, OR reject and skip.
+}
+```
+
+## Allowed roles (BindingContext.role union)
+
+`'commander' | 'flash' | 'synthesis' | 'qa' | 'opencode' | 'mizan'`
+
+To add a new role, extend the union in `harness-binding.ts:BindingContext`. Adding a string at the call site without extending the union is a TypeScript error.
+
+## Module format
+
+`@aria/gate-runtime` is **CJS** (CommonJS). It loads via `require()`. If your consumer is ESM, use dynamic `import()`:
+
+```ts
+const { runFullChain } = await import('@aria/gate-runtime');
+```
+
+Do not change gate-runtime to ESM-only — multiple consumers are CJS, and Node 22 strict resolution rejects mixed mode without proper conditional `exports`.
+
+## Discovery ledger (atomic discovery + fix)
+
+When you find a defect mid-task, write a discovery to the ledger atomically per `feedback_no_flag_without_fix.md`:
+
+```ts
+appendFileSync('~/.claude/aria-discoveries-<session-id>.jsonl',
+  JSON.stringify({
+    at: new Date().toISOString(),
+    kind: 'defect',
+    text: '...',
+    refs: [...],
+    resolution_status: 'open'
+  }) + '\n'
+);
+```
+
+Then either fix it the same turn or `TaskCreate` it with full context. Never leave open rows across turns.
+
+## Top doctrine refs every author should know
+
+| File | Rule |
+|---|---|
+| `feedback_packet_is_not_harness.md` | claims of harness state require enumerating L1/L2/L3 explicitly |
+| `feedback_no_flag_without_fix.md` | discoveries are atomic with their fix |
+| `feedback_no_assumption_without_verification.md` | every behavioral claim cites a verifiedAgainst source |
+| `feedback_workaround_vs_path_fix.md` | producers enforce contracts; carve-outs are landmines |
+| `feedback_no_stripping_as_workaround.md` | "simplified"/"minimal" framing camouflages stripping; debug the mechanism |
+| `feedback_state_outcomes_not_narratives.md` | report outcomes (image SHA, exit codes) not narrative |
+| `feedback_orchestrator_deepseek_split.md` | one Claude orchestrator; cognition delegation routes to DeepSeek+harness, never sub-Claude |
+| `feedback_admission_policy_verification.md` | verify cluster admission policies BEFORE deploy |
+| `feedback_deploy_requires_verify_cognition.md` | deploys require verify+cognition blocks in same turn |
+| `feedback_dalio_expected_required.md` | every non-trivial action declares measurable predicate |
+| `feedback_full_harness_binding_must_be_structural.md` | binding drives consumer behavior; lenses without anchors are unsourced prose |
+
+## Bottom line
+
+The harness exists because doctrine is action-coupled: text decisions ARE actions, and reflexive replies fail the gates the same way reflexive Bash does. The SDK gives you the primitives. The skills give you the discipline at authoring-time. The gates enforce at runtime. This file is the entry point so consumers (you, Claude, future workers) do not relearn the contract through iteration loops.
+
+Quality production-grade is the only acceptable bar — for code contracts AND for output prose. Both are owned. Both are the producer-side discipline.
+
+When in doubt: cite the substrate, declare the predicate, name the doctrine, reframe — don't strip.
+
+## 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.