# Runtime Adaptation & Resilience Mesh

Webdev Agent OS v17 adds a governed reliability layer across deployed websites, APIs, workers, queues, data stores, identity systems, and third-party dependencies.

## Mission

Preserve critical user outcomes during failure, prove recovery behavior before emergencies, and prevent autonomous adaptation from becoming an uncontrolled production risk.

## Evidence chain

```text
Service inventory
→ Dependency graph
→ Synthetic user journey
→ Runtime signal
→ SLO and error budget
→ Incident correlation
→ Fault rehearsal
→ Graceful-degradation or traffic policy
→ Independent approval
→ Recovery verification
→ Resilience campaign
```

## Core operating objects

### Services

A service records ownership, criticality, environment, health, endpoint, region, recovery-time objective, recovery-point objective, signals, dependencies, runbooks, and evidence.

### Dependencies

Dependency edges identify the calling service, downstream service, interaction type, criticality, timeout, retries, circuit-breaker behavior, and fallback policy. The mesh supports upstream impact analysis so a failing data store can be traced to every user-facing flow it may affect.

### Synthetic journeys

Journeys represent outcomes users actually care about, such as submitting a lead, booking an appointment, or signing into a scoped client portal. A journey cannot be recorded as passing unless every step has passing evidence.

### SLOs and error budgets

Each SLO contains an objective, actual measurement, window, burn rate, evidence, and automatically calculated remaining error budget. The system distinguishes meeting, at-risk, and breached objectives.

### Fault rehearsals

Rehearsals require a falsifiable hypothesis, isolated blast radius, safeguards, abort conditions, target services, expected result, independent approval, start evidence, and completion evidence. Destructive rehearsals are rejected by the local engine.

### Graceful degradation

A degradation policy states what behavior is preserved, what is temporarily sacrificed, what trigger activates it, how it was tested, and how it can be rolled back.

### Traffic controls

Failover, traffic shifting, circuit breaking, rate limiting, and load shedding are governed by explicit guardrails and rollback plans. Authors cannot approve their own traffic changes, and an unhealthy failover target blocks activation.

### Incidents and recovery

Incidents correlate services, signals, journeys, and suspected dependency edges. An incident cannot be resolved until every required recovery verification has passed with evidence.

## Autonomy boundary

The Resilience Mesh may automatically:

- Read health evidence
- Calculate SLO and error-budget state
- Correlate likely incident impact
- Identify overdue journeys and missing controls
- Recommend rehearsals and policies
- Generate reports and campaigns

It may not silently:

- Inject faults into production
- Shift traffic
- Activate failover
- Close an incident
- Approve its own rehearsal
- Claim recovery without evidence
- Modify infrastructure outside an explicitly connected adapter

## Local operation

```bash
npm run resilience-mesh:stats
npm run resilience-mesh:report
node scripts/resilience-mesh-cli.js view
node scripts/resilience-mesh-cli.js impact svc-primary-db
```

The default store is `config/resilience-mesh-store.json`. Set `RESILIENCE_MESH_STORE` to use a different working store.