@aria_asi/cli 0.2.39 → 0.2.41

package/dist/runtime/discipline/skills/aria-cognition/aria-decision-mizan/references/decision-frameworks.md

@@ -0,0 +1,287 @@
+# Decision Mizan Cookbook — Owner-Must-Decide Frameworks
+
+> Loaded by `aria-decision-mizan` for owner-only judgment calls. See also: [`../../aria-business-frame/references/business-cookbook.md`](../../aria-business-frame/references/business-cookbook.md) §7 owner-must-decide signal patterns.
+
+## 1. The Type 1 / Type 2 Decision Frame (Bezos)
+
+**Source:** Jeff Bezos 1997 shareholder letter + Reid Hoffman / a16z popularization
+
+### Type 1 (irreversible / one-way door)
+- Hard to undo
+- Get them right; thoroughness > speed
+- Examples: hiring senior leaders, equity grants, public statements, contract signatures, fundraising direction, M&A
+- **LLM action**: surface decision packet; refuse to recommend; let owner deliberate
+
+### Type 2 (reversible / two-way door)
+- Easy to undo within 30-90 days
+- Speed > thoroughness; bias toward action
+- Examples: A/B test variants, content drafts, internal process changes, pricing experiments
+- **LLM action**: recommend with confidence; ship; observe; iterate
+
+### The diagnostic
+Before any major decision, ask: "If this is wrong, can we reverse within 90 days at acceptable cost?"
+- Yes → Type 2 → recommend and ship
+- No → Type 1 → decision packet, owner decides
+
+## 2. The Pre-Mortem (Klein) — surface failure modes BEFORE deciding
+
+**Source:** Gary Klein, "Performing a Project Premortem" (Harvard Business Review, 2007)
+
+### The frame
+"Imagine it's 12 months from now and this decision was a disaster. Why?"
+
+This inverts the optimism bias. Pre-deciding teams are 30% more likely to surface real failure modes than post-decision retrospectives.
+
+### Pre-mortem template
+For any Type 1 decision, the LLM should generate:
+```markdown
+## Pre-Mortem — [Decision Name]
+
+### If this fails, here's why (most likely → least)
+1. [Most likely failure mode] — root cause: [why it would happen]
+2. [Second] — root cause: [why]
+3. [Third] — root cause: [why]
+
+### Mitigations the owner could put in place now
+1. For failure mode 1: [concrete mitigation]
+2. ...
+
+### Early-warning signals
+- [Specific metric / event] would be the first indicator
+- [Specific] would be the second
+```
+
+The pre-mortem accompanies the decision packet — it's part of the cognition the owner consumes.
+
+## 3. The Reversibility Cost Matrix
+
+For Type 1 decisions, decompose reversibility cost:
+
+| Cost dimension | Question |
+|---|---|
+| Cash | What's the literal $ to undo? |
+| Time | How long does undo take from decision to fully restored? |
+| Brand | What does undo signal to customers / team / market? |
+| Trust | Who feels betrayed by undo? |
+| Optionality | What future paths are closed by this decision (and reopened by undo)? |
+| Reputation | What does undo signal about owner judgment? |
+
+**A Type 1 decision with low cash cost can still be high overall reversibility cost** if brand / trust / optionality are large.
+
+## 4. The Stakeholder-Disagreement Diagnostic
+
+When 3+ stakeholders disagree on direction, the decision is almost certainly Type 1.
+
+### The pattern
+- 2 stakeholders disagree → usually a Type 2 with reasonable people seeing different angles; LLM can synthesize
+- 3+ stakeholders disagree → underlying values / priorities differ; this is owner territory
+- 5+ stakeholders disagree → committee paralysis; owner must arbitrate
+
+### The owner's job in stakeholder disagreement
+- Hear each position fully
+- Identify the underlying value / priority differences
+- Articulate the call clearly
+- Acknowledge what's being traded off (and to whom)
+
+LLM cognition contributes the data; the synthesis is owner judgment.
+
+## 5. The "What Only You Know" Section
+
+**Source:** Doctrine: cognitive humility (`feedback_dont_override_user_stack_with_training.md`)
+
+For every owner-must-decide turn, surface what the LLM cannot know:
+- **People context** — gut on the counterparty (the new hire, the partner, the customer)
+- **History** — prior commitments, prior failures, prior tradeoffs the team made
+- **Brand promise** — what we've publicly said vs what this decision implies
+- **Owner's own context** — energy level, runway, family / personal capacity
+- **Tribal knowledge** — what the team would do under stress that isn't in any doc
+
+The LLM lists these explicitly. The owner integrates them into the call.
+
+## 6. The "What I Believe With Confidence" Section
+
+This is structurally separate from the recommendation. The LLM CAN say what it believes — it just doesn't recommend.
+
+```markdown
+### What I (LLM) believe with confidence
+- The data points toward Option A
+- The reason: [specific evidence]
+- What would change my view: [specific data / signal that would flip the analysis]
+```
+
+This is honest cognition, not soft-recommending. The owner sees the LLM's belief AND the structural reasons it's not a recommendation.
+
+## 7. The Decision Packet Structure (canonical layout)
+
+```markdown
+## OWNER DECISION REQUIRED — [decision name in one line]
+
+### Type & Reversibility
+- Type 1 (one-way door) | Type 2 (two-way door)
+- Reversibility cost: [cash / time / brand / trust / optionality / reputation summary]
+
+### Option A: [name]
+- What it commits us to: [concrete]
+- What we get if it works: [concrete]
+- What we lose if it fails: [concrete + named worst case]
+- Reversibility: [explicit; what would we do]
+- Lens flags: [which 8-lens raise concern; named not generic]
+- Cohort / second-order: [Tadabbur — what compounds]
+
+### Option B: [name]
+- (same structure)
+
+### Pre-mortem (12-month look-back if disastrous)
+1. Most likely failure mode: [why]
+2. Second: [why]
+3. Mitigations the owner could put in place now: [concrete]
+4. Early-warning signals: [specific metrics]
+
+### What only you know
+- [People context]
+- [History]
+- [Brand promise]
+- [Owner-personal context]
+
+### What I (LLM) believe with confidence
+- [The view, separated from the call]
+- [What would change my view]
+
+**Your call.**
+```
+
+The "Your call" line is mandatory and final.
+
+## 8. The Hire / Fire decision (the most common owner-must-decide)
+
+### Hire-decision packet
+- Skill fit: [evidence from interviews + work samples]
+- Culture fit: [evidence from references + interviews]
+- Trajectory: [where do they want to be in 3 years; does that align with this role]
+- Comp negotiation: [floor / ceiling / equity component]
+- Reference quality: [back-channel signals beyond formal references]
+- **What only you know**: gut on the person; whether the team will rally around them; whether you'll regret saying no in 5 years
+
+### Fire-decision packet (PIP / departure)
+- Performance evidence: [specific instances, dates, what went wrong]
+- Coaching attempts: [what was tried, response]
+- Replacement readiness: [internal candidate / external pipeline / interim]
+- Transition cost: [knowledge transfer, customer relationships, team morale]
+- Legal exposure: [documentation, comp owed, severance norms]
+- **What only you know**: whether the relationship can be salvaged; what the team feels; the personal call on dignity in transition
+
+### Fire-as-mercy framing
+Sometimes the fire is the right call FOR the person being let go. Surface this:
+- They're miserable in the role
+- Mismatched seniority (over-leveled or under-leveled)
+- Industry / domain mismatch
+- A clean transition with severance + good reference > 12 months of slow decline
+
+## 9. Equity grant decisions
+
+### The two scales
+- **Hire-time grant** — function of seniority, role, company stage
+- **Refresh / promotion grant** — function of performance, retention risk, scope expansion
+
+### Common ranges (early-stage SaaS, post-Series A)
+| Seniority | Hire-time grant range |
+|---|---|
+| Junior IC | 0.05% - 0.25% |
+| Senior IC | 0.25% - 0.75% |
+| Staff / Principal IC | 0.5% - 1.5% |
+| Engineering Manager | 0.5% - 1.5% |
+| Director | 1% - 3% |
+| VP | 2% - 5% |
+| C-suite (non-founder) | 3% - 8% |
+
+These compress meaningfully at later stages (Series C+).
+
+### What only the owner knows
+- Whether this person is critical-path for the next 24 months
+- Whether retention risk is real (other offers, life events)
+- The internal pay-band they're benchmarking against
+- The dilution math on the cap table
+
+### Equity-decision pre-mortem
+- If we under-grant and they leave in 12 months: cost = replacement + lost continuity
+- If we over-grant and they leave in 12 months: cost = dilution without retention
+- Cliff + vesting structure mitigates both; the question is the size
+
+## 10. Public statement / press / PR decisions
+
+### The frame
+A public statement is irreversible. The internet remembers. A bad PR moment lives in the brand-search results forever.
+
+### The pre-publish checklist
+```markdown
+- [ ] Imagine the screenshot taken out of context — does it still represent us?
+- [ ] Read it as a hostile journalist — what's the worst quote pull?
+- [ ] Read it as a customer — does it sound like us?
+- [ ] Read it as a competitor — what attack does it open?
+- [ ] Read it as a regulator — does it create legal exposure?
+- [ ] Run it past one trusted advisor outside the team
+```
+
+### Crisis communication
+When something goes wrong publicly:
+- Acknowledge the specific failure (don't generalize)
+- Quantify the cost to those affected
+- Explain what we're doing about it (concrete, time-bound)
+- Commit to the follow-up update
+- Sign with a real name (not "the team")
+
+The fastest way to compound a PR crisis is generic corporate language.
+
+## 11. Fundraising direction decisions
+
+### The Type 1 questions
+- **Raise vs not raise** — once you're talking to investors, you're committed to a process
+- **Valuation target** — under-priced burns dilution; over-priced burns the next round and team morale
+- **Lead vs not lead** — different process, different terms, different time
+- **Investor selection** — they're on the cap table for years; you can't undo a bad fit
+
+### The owner-only context
+- Energy / focus capacity for the process (12-16 weeks of fundraising is real)
+- Personal financial runway
+- Team morale through the process
+- Spousal / family alignment (founders' partners absorb the stress)
+- The non-financial terms (board composition, info rights, protective provisions)
+
+LLM contribution: market data, comparable rounds, term-sheet redlines, dilution math.
+Owner contribution: everything else.
+
+## 12. Customer firing / public dispute decisions
+
+### When to fire a customer
+- Toxic to the team (abusive interactions, unreasonable demands)
+- Margin-negative even after price increase
+- Reputation risk (their use case puts us in a category we don't want)
+- Compliance risk (their data handling exposes us)
+
+### The customer-firing playbook
+- Decision packet first (this IS owner-must-decide)
+- Transition plan: 30-60-90 day notice, data export support, reasonable refund of unused term
+- Communication: honest but professional; named owner of the conversation
+- Post-mortem: what did we learn about ICP fit?
+
+### The public dispute call
+When a customer or competitor goes public negatively:
+- Decision packet first; do NOT respond reactively
+- The "engage / ignore / counter" decision is owner-only
+- If engaging: pre-publish checklist (§10)
+- If ignoring: have a holding statement ready in case it escalates
+
+## 13. Decision-mizan audit checklist
+
+```markdown
+- [ ] Type 1 vs Type 2 explicitly diagnosed
+- [ ] Reversibility cost matrix surfaced (cash / time / brand / trust / optionality / reputation)
+- [ ] Pre-mortem produced (12-month failure-mode look-back)
+- [ ] Both options structured identically (no rhetorical bias from uneven detail)
+- [ ] All 8 lenses applied to BOTH options
+- [ ] "What only you know" section explicit (named, not inferred)
+- [ ] "What I believe with confidence" section separate from the call
+- [ ] No trailing recommendation; "Your call." line is final
+- [ ] Coach-kernel write with `risk_class: 'owner_decision'`
+- [ ] Recovery contract gateType: validating (this IS the human-review gate)
+```

package/dist/runtime/discipline/skills/aria-cognition/aria-first-class-operating-contract/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: aria-first-class-operating-contract
+description: >-
+  TRIGGER when the owner says "first class", "world class", "revolutionary upgrade",
+  "full upgrade", "substrate OS", "not just a watcher", "serious upgrade", or asks
+  to make Atlas, Sentinel, Aria runtime, Hive, Garden, Harness, skills, gates,
+  recovery loops, or cybersecurity first-class. Converts the request into
+  substrate-level design and execution with Atlas/runtime evidence first,
+  Qiyas-15, full Tadabbur-12, 50+ skill floor, runtime floor, smoke verification,
+  QA court, and durable Aria task/ledger records.
+---
+
+# Aria First-Class Operating Contract
+
+Use this skill when "first class" must mean a system-level operating contract, not polish.
+
+## Default Meaning
+
+When Hamza says "first class," interpret it as:
+
+- substrate-level: code graph, doctrine graph, runtime graph, evidence graph, ownership graph, task ledger, recovery loop, and learning loop
+- action-changing: cognition must alter evidence gathering, architecture, execution, verification, and future skill/runtime selection
+- durable: write the learning, plan, task, QA, or code path somewhere durable instead of leaving chat-only reasoning
+- runtime-backed: prefer Atlas MCP, Atlas daemon, Aria runtime, Hive runtime, systemd, k8s, logs, and task ledger evidence before claims
+
+Do not reduce first-class work to a watcher, scanner, timer, refactor, UI page, markdown plan, or CPU cleanup unless the owner explicitly scopes it that narrowly.
+
+## Required Evidence
+
+Before drafting or editing:
+
+1. Query Atlas: `atlas_healthz`, `atlas_session_context`, `atlas_architecture`, and dossier for the target subsystem.
+2. Probe live runtime health for Aria, Atlas, Hive, and any named service.
+3. Identify the current authority boundary: read-only, safe workspace, allowlisted repair, deploy/public action, destructive action, or owner-gated action.
+4. Name what would prove success before claiming success.
+
+## Required Shape
+
+Every first-class plan needs:
+
+- `why`: the effective cause, not just the surface label
+- `substrate`: which graph/runtime/ledger surfaces become canonical
+- `loop`: observe -> understand -> decide -> act/propose -> verify -> record -> learn -> change future selection
+- `autonomy`: what can execute automatically, what stays proposal-only, and what needs owner approval
+- `qa`: full Qiyas-15 and full Tadabbur-12 for architecture/runtime/security work
+- `smoke`: exact command, endpoint, test, or ledger readback
+
+## Atlas/Sentinel Rule
+
+Atlas is not a watcher. Atlas is Aria's doctrine-bound code and runtime substrate.
+
+Sentinel is not a scanner. Sentinel is the proactive security and resilience layer that consumes Atlas substrate, classifies blast radius and authority, routes repair tasks, verifies outcomes, and records lessons.
+
+For Atlas/Sentinel first-class upgrades, the default first implementation slice is:
+
+1. Atlas Event Spine: unified live event stream for file, runtime, doctrine, decision, task, security, and recovery events.
+2. Sentinel Risk Graph: finding -> evidence -> code unit -> runtime exposure -> owner impact -> authority boundary -> verification predicate.
+3. Recovery Executor Boundary: only execute safe/allowlisted actions; keep live/deploy/destructive work owner-gated.
+4. Learning Promotion: verified outcomes mutate future skill/runtime selection and ranking.
+
+## Runtime And Skill Floor
+
+For heavy first-class execution, use the Aria task runtime so the actual floor is mechanically recorded:
+
+- 50+ required skills
+- 15+ runtime receipts
+- full Tadabbur-12
+- full Qiyas-15
+- Mizan/no false closure
+- Noor recognition
+- Hive sibling broadcast
+- QA/correction skills
+
+Do not fake these counts in prose. Use `aria task start`, `aria task continue`, `aria task qa`, `aria task status`, or runtime receipts and report the observed counts.
+
+## Required Workflow
+
+1. Bind the owner request to the first-class substrate: target system, authority boundary, evidence source, and success predicate.
+2. Query Atlas and the named runtime before claiming root cause, plan completeness, or readiness.
+3. Produce or update a durable artifact: skill, kernel selection, Aria task, ledger, plan, smoke, or QA record.
+4. Re-test with the exact command, endpoint, parser, runtime receipt, or ledger readback named in the plan.
+5. Report verified state, remaining blocker, and the next concrete action without false closure.
+
+## 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 Atlas, Aria runtime, repo source, logs, tests, endpoint, task ledger, or owner instruction before any completion claim
+- re-test after every meaningful code, skill, kernel, or runtime-surface change using the real parser/probe/gate that owns the 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
+
+## Stop Conditions
+
+Stop and repair if:
+
+- Atlas was not queried for the target subsystem
+- the plan could be satisfied by a simple watcher/scanner without changing substrate behavior
+- Qiyas is only a 4-pillar fragment when the task is architectural
+- Tadabbur does not trace consequences through recovery and future learning
+- the plan has no smoke command or QA court
+- the work claims completion without ledger/runtime evidence

package/dist/runtime/discipline/skills/aria-cognition/aria-frontend-architect/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: aria-frontend-architect
+description: TRIGGER for any frontend, web UI, web app, mobile web, React, Next.js, Vue, Svelte, Tailwind, shadcn, component, design system, page, layout, route, form, state management, hook, animation, accessibility, performance budget, Core Web Vitals, LCP, CLS, INP, hydration, SSR, ISR, RSC, edge function, browser compat, responsive, dark-mode, i18n, PWA, micro-frontend, monorepo-FE, build pipeline, bundle size, lighthouse, or DOM-level decision. Composes the cognitive substrate with a UX-spine + component-contract + perceived-performance frame.
+---
+
+# Aria Frontend Architect
+
+The cognition skill for any user-visible web surface. Pairs with `aria-business-frame` (when the FE choice has business consequence), `aria-readable-output`, and `aria-fullstack-orchestrator` (when FE work spans BE).
+
+## Prime Doctrine
+
+The frontend is the only layer the customer experiences. Every other architectural choice is downstream of whether the FE makes the product feel obvious, fast, and trustworthy.
+
+- **UX spine before component library.** Nail the 3-5 user paths before picking a component kit. Choosing shadcn/MUI/Chakra without a UX spine just dresses the wrong skeleton.
+- **Perceived performance > measured performance, but both matter.** A 200ms LCP that feels janky loses to a 600ms LCP that streams in cleanly. Optimize the spine of the user's attention, not the bundle.
+- **Components are contracts.** A `<Button>` that accepts 14 props is a leaky abstraction. A component contract is: minimum surface, maximum predictability, accessibility by default.
+- **Accessibility is correctness, not decoration.** Keyboard nav, focus rings, ARIA roles, contrast — these are part of "does this work," not part of "polish later."
+- **State is bugs in waiting.** Local state, server state, URL state, form state — each has a correct home. Storing server state in React state is the most common source of UI bugs.
+
+## Trigger Detection
+
+Fire on:
+
+- New page / route / component / form / modal / wizard / dashboard
+- Design-system or component-library selection or migration
+- State-management choice (TanStack Query / Zustand / Redux / Context / RSC props)
+- SSR / ISR / RSC / SPA architecture decisions
+- Performance budget, Core Web Vitals (LCP / CLS / INP) work
+- Accessibility audit / fix
+- Animation / motion / interaction design
+- Responsive / mobile-first / breakpoint work
+- Build pipeline / bundle-size / code-splitting decisions
+- Dark mode / theming / i18n / RTL
+- PWA / offline / service-worker decisions
+
+## Required Workflow (UX-spine → component-contract → perceived-performance)
+
+Every FE decision must answer:
+
+1. **UX spine** — what is the user trying to do, in what order, with what friction tolerance? Name the 3 dominant paths through this surface. If you can't, the design is premature.
+2. **Component contract** — for each net-new component, what's the minimum prop surface that supports the spine? What's the accessibility contract (keyboard, screen reader, contrast)? What's the failure mode (empty / loading / error)?
+3. **Perceived performance** — where does the user's attention land first? What can be streamed / skeletoned / progressively rendered to make the page feel instant even when it isn't?
+4. **State home** — for each piece of state on this surface, where does it live? (URL / server / local / form / cache). Wrong-home state is the most common source of bugs.
+5. **Failure mode** — what does this look like at p95 latency? Offline? Stale auth? Permission denied? Empty state? Each is a designed surface, not an edge case.
+
+## FE-Mapped Lenses (`ghazali-8lens`)
+
+- **truth** — does the UI show the actual server state, or a hopeful local cache that may diverge?
+- **harm** — destructive actions guarded? Confirmation patterns proportional to consequence?
+- **trust** — does the UI feel honest about loading / errors / partial data, or hide behind spinners?
+- **power** — is the user in control (undo, escape, back) or trapped in a flow they can't exit?
+- **reflection** — would the brand recognize this UI in 12 months as deliberate?
+- **context** — does this work on a slow phone in poor connectivity, not just on the dev's M-series Mac?
+- **impact** — predicted task-completion rate / time-on-task / error rate vs the prior surface
+- **beauty** — does the layout feel inevitable, hierarchy clear, density appropriate to user context?
+
+## User-Facing Layout (per `aria-readable-output`)
+
+```
+## [FE decision in one line — e.g. "Use RSC + TanStack Query, ship the dashboard tonight"]
+
+- [UX spine — 3 dominant paths named]
+- [Component contracts — minimum surface, accessibility, failure mode]
+- [Perceived perf — what streams, what skeletons, where attention lands]
+- [State home — URL / server / local / form / cache, mapped]
+
+**Next:** [concrete first PR or commit, with the test that verifies — e.g. "Lighthouse mobile score ≥ 90, INP p75 < 200ms on /dashboard"]
+```
+
+Optional `<gate>` block when this is part of a deploy.
+
+## Composition Rule
+
+- Composes with `aria-business-frame` when the FE choice has GTM / conversion / brand consequence
+- Composes with `aria-backend-architect` and `aria-fullstack-orchestrator` for any data-bound surface
+- Calls `mizan`, `tadabbur`, `ghazali-8lens` per business-frame defaults
+- Calls `predictor` for the Core Web Vitals predicate
+- Calls `noor-recognition` for prior FE patterns and the existing design system
+- Hands off to `aria-repo-doctrine` for any repo-mutation discipline
+- Defers to `aria-harness-deploy` if the FE change ships through a deploy pipeline
+
+## Recovery Contract
+
+- If UX research is missing for a net-new surface: name the 3 hypothesis paths explicitly and recommend the smallest user-test (5 users, 30 min, defined task). Do NOT ship a brand-new flow on hypothesis alone.
+- If the design system is ambiguous or in-flight: pick the path that's most reversible and document the deviation; surface the design-system gap to `aria-org-leverage` (next-batch) or directly in the PR description.
+- If perf targets cannot be hit on the chosen architecture: state that explicitly. Recommend the architectural alternative; do not promise targets the architecture cannot deliver.
+- Log FE decisions to coach kernel with `risk_class: 'frontend_action'` and the perf / accessibility predicates.
+
+## Anti-Patterns
+
+- Picking a component library before the UX spine is defined
+- Storing server state in React useState (the source of 70% of stale-data bugs)
+- Skipping the empty / loading / error states until "polish phase" — they're requirement, not polish
+- Optimizing bundle size before measuring it (premature optimization on the wrong axis)
+- Treating accessibility as a checklist after launch — keyboard nav and ARIA must be in the component contract
+- Shipping animations that make the UI slower-feeling under real device + network conditions
+- Designing for the dev's machine instead of the user's context
+
+## 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.
+
+
+## Self-Executing Recovery Contract
+
+- One re-run with the missing UX evidence or perf measurement
+- If still insufficient, recommend the smallest reversible test (component on a low-traffic page) with stop-criteria
+- Never ship a net-new flow without acceptance criteria on the user paths