@homericintelligence/athena-opencode 0.4.4 → 0.5.1

package/skills/_support/docs/principles/details/p032-handle-once-preserve-causality.md

@@ -0,0 +1,137 @@
+# P032 — Handle Once; Preserve Causality
+
+## Definition
+
+One boundary must have responsibility for the outcome policy for a failure. Other layers can add safe
+context or telemetry. They must record only one incident for the failure.
+
+Each error translation must keep the causal chain, stack data, and structured context. These data
+help engineers find the initial failure cause.
+
+**Aliases:** single-owner error handling, log-or-propagate, exception chaining
+
+## Provenance
+
+**Classification:** practitioner heuristic.
+
+Many languages include exception chaining. The full “handle once” rule is a cross-language
+engineering synthesis. Athena cannot identify one source for this rule.
+
+## Decision rule
+
+For each failure, find the boundary that selects the outcome. Other layers must propagate the
+failure. They can add context that is available only at their layer.
+
+## How to apply
+
+- Give ownership of recovery, user output, and error-level records to a clear API, process, job, or
+  workflow boundary.
+- Use native cause links or structured error wrappers. Do not replace an error with a message that
+  has no relation.
+- Add an operation, safe identifier, or dependency name only at the layer that knows it.
+- Correlate retry telemetry with the last outcome. Do not record each try as a different,
+  uncorrelated incident.
+- Keep stack and cause fields in structured telemetry. Remove sensitive data from those fields.
+- Make sure that each translated error has the stable public category and internal cause.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["A layer receives a failure"] --> B{"Does this layer have responsibility for outcome policy?"}
+    B -- "Yes" --> C["Select the outcome and record one incident"]
+    B -- "No" --> D{"Does this layer have safe context available only here?"}
+    D -- "Yes" --> E["Add context and keep the cause"]
+    D -- "No" --> F["Keep the failure unchanged"]
+    E --> G["Propagate to the responsible boundary"]
+    F --> G
+```
+
+## Language examples
+
+Each example adds one artifact identifier and keeps the initial storage error as the cause.
+
+### Python
+
+```python
+def load_artifact(store, key):
+    try:
+        return store.read(key)
+    except StorageError as error:
+        raise ArtifactLoadError(key) from error
+```
+
+### Rust
+
+```rust
+fn load_artifact(store: &Store, key: &str) -> Result<Artifact, ArtifactLoadError> {
+    store.read(key).map_err(|source| ArtifactLoadError {
+        key: key.to_owned(),
+        source,
+    })
+}
+```
+
+## Boundaries and tensions
+
+“Handle once” lets teams record metrics or low-severity tries at more than one layer. It does not
+let them record one failure as more than one incident. A library can record
+diagnostic events if its observability contract includes them. Ownership and correlation must
+stay clearly specified.
+
+Use this rule with [P031](p031-propagate-rather-than-swallow.md). Propagation keeps the failure available.
+Cause preservation gives the responsible boundary sufficient diagnostic data. Security and privacy
+controls can prevent public access to some information. These controls must keep the protected internal chain.
+
+## Examples
+
+### Positive application
+
+A storage client returns a timeout with endpoint metadata. The repository wrapper links that cause
+to `ArtifactLoadFailed` with an artifact identifier. The request boundary records one correlated
+error event and returns the stable public code.
+
+### Misuse or counterexample
+
+Four nested functions each record the same exception at error level. Each function throws a new
+exception without its cause. One incident causes four alerts. Engineers cannot get the initial
+stack.
+
+### Athena or agent workflow
+
+A delegated reviewer records a tool failure with its command and exit status. The coordinator adds
+the inspection phase. It records one failure for the user.
+
+## Related principles
+
+- [P031 — Propagate Rather Than Swallow](p031-propagate-rather-than-swallow.md)
+- [P033 — State-Safe Failure Semantics](p033-state-safe-failure-semantics.md)
+- [P038 — Bounded Retry](p038-bounded-retry.md)
+- [P047 — Observability Is Part of Correctness](p047-observability-is-part-of-correctness.md)
+
+## References
+
+### Source information
+
+- [PEP 3134 — Exception Chaining and Embedded Tracebacks](https://peps.python.org/pep-3134/)
+  — records information about automatic and specified cause retention during Python exception
+  translation.
+- [John B. Goodenough, “Structured Exception Handling” (1975)](https://doi.org/10.1145/512976.512997)
+  — a 1975 analysis of structured exception handling. It does not give Athena's specified
+  record policy.
+
+### Applicable information
+
+- [OpenTelemetry Semantic Conventions 1.44.0: exceptions in logs](https://opentelemetry.io/docs/specs/semconv/exceptions/exceptions-logs/)
+  — applicable conventions for correlated exception records, stack traces, and duplicate prevention
+  in instrumentation.
+- [C++ Core Guidelines E.17 and E.18](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#e17-dont-try-to-catch-every-exception-in-every-function)
+  — recommends no catch operation in each function and recommends a small number of specified
+  handlers.
+
+### More information
+
+- [P029 — Generalize Error Policy; Preserve Specific Cause](../README.md#p029) — shows stable
+  boundary taxonomies and internal diagnostics that keep the cause.
+
+[Back to the engineering principles catalog](../README.md#p032)

package/skills/_support/docs/principles/details/p033-state-safe-failure-semantics.md

@@ -0,0 +1,140 @@
+# P033 — State-Safe Failure Semantics
+
+## Definition
+
+After failure, each applicable resource and state holder must stay unchanged or change to a
+specified recoverable state. This state must be correct. The failure path must keep invariants and
+use a deterministic procedure to release resources. Work after the failure must not read state that can be incorrect.
+
+This postcondition does not include reversal of all effects.
+
+**Aliases:** exception safety, valid-state guarantee
+
+## Provenance
+
+**Classification:** Athena synthesis.
+
+Exception-safety guarantees and transaction theory contain types of this rule. Athena cannot
+identify one source for this language-neutral rule.
+
+## Decision rule
+
+Before a new mutation, record the correct states after each possible failure point. If only some
+effects can occur, record those effects in durable data. Make sure that the system can find them
+and recover from them.
+
+## How to apply
+
+- Before implementation of a multistep mutation, record invariants and failure postconditions.
+- Before a state change, validate inputs and prerequisites.
+- Put output in temporary state. After all necessary work succeeds, publish it.
+- Use scoped resource ownership to release locks, files, connections, and temporary resources on
+  each exit path.
+- Use one transaction for changes in one transactional boundary. If one transaction cannot contain
+  all changes, record durable completed-step data and compensation data.
+- In tests, put failures between steps. Make sure that the state, resource release, and recovery path are correct.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Record invariants and failure postconditions"] --> B["Validate inputs and prerequisites"]
+    B --> C{"Can one transaction contain all effects?"}
+    C -- "Yes" --> D["Prepare effects and commit in one operation"]
+    C -- "No" --> E["Record durable completed-step data and compensation data"]
+    D --> F{"Did the operation fail?"}
+    E --> F
+    F -- "No" --> G["Publish the correct result"]
+    F -- "Yes" --> H["Put the system in the specified recoverable state"]
+    H --> I["Release resources and propagate the failure"]
+```
+
+## Language examples
+
+Each example commits the source and target account changes or keeps the previous state.
+
+### Python
+
+```python
+def transfer(db, source, target, amount):
+    with db.transaction():
+        db.debit(source, amount)
+        db.credit(target, amount)
+```
+
+### Rust
+
+```rust
+fn transfer(db: &mut Db, source: Id, target: Id, amount: Money) -> Result<(), Error> {
+    let mut transaction = db.transaction()?;
+    transaction.debit(source, amount)?;
+    transaction.credit(target, amount)?;
+    transaction.commit()
+}
+```
+
+## Boundaries and tensions
+
+Failure atomicity is a stronger related guarantee, not an alias. If an operation fails, it must keep
+the initial state unchanged for failure atomicity. State-safe failure semantics can have a specified
+recoverable state as their result. This state must be correct.
+
+When one transaction can contain the logical operation, use
+[P044](p044-atomicity-where-possible.md) first. When effects occur in different systems or include
+work with a long time, use [P045](p045-compensation-where-atomicity-is-impossible.md). Compensation
+can give a correct business state that does not have all previous bytes.
+
+[P034](p034-fail-fast.md) stops dangerous continuation. Termination does not correct a resource leak
+or an effect that is not clear from only some steps. State preservation does not include failure suppression.
+Use [P031](p031-propagate-rather-than-swallow.md) to propagate the failure.
+
+## Examples
+
+### Positive application
+
+A file generator writes and validates a temporary file. It flushes the file and uses an atomic
+replacement for the destination. If generation fails, it removes the temporary file. The previous
+artifact stays unchanged.
+
+### Misuse or counterexample
+
+A migration updates some table rows and catches an error after the update of only some rows. It returns
+success. No rollback or durable checkpoint records the changed rows.
+
+### Athena or agent workflow
+
+An Athena workflow validates all of a proposed issue body before issue creation. If creation
+fails, the workflow gives a failure result. It does not give a success result or edit paths not in task scope.
+
+## Related principles
+
+- [P031 — Propagate Rather Than Swallow](p031-propagate-rather-than-swallow.md)
+- [P034 — Fail Fast](p034-fail-fast.md)
+- [P044 — Atomicity Where Possible](p044-atomicity-where-possible.md)
+- [P045 — Compensation Where Atomicity Is Impossible](p045-compensation-where-atomicity-is-impossible.md)
+
+## References
+
+### Source information
+
+- [Härder and Reuter, “Principles of Transaction-Oriented Database Recovery” (1983)](https://doi.org/10.1145/289.291)
+  — an analysis of transaction recovery and the ACID terms for all-or-nothing state
+  changes.
+- [Boost, Exception Safety](https://www.boost.org/doc/user-guide/exception-safety.html) — records
+  the basic and strong exception-safety guarantees for correct state and rollback behavior. These
+  guarantees have a smaller scope. Athena's rule also includes system-level effects.
+
+### Applicable information
+
+- [C++ Core Guidelines E.4 and E.6](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#e4-design-your-error-handling-strategy-around-invariants)
+  — applicable guidance for an error strategy that uses invariants. It recommends automatic resource
+  management to prevent leaks.
+- [Microsoft Azure, Compensating Transaction pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction)
+  — applicable guidance for recoverability when a multistep operation cannot use one atomic operation.
+
+### More information
+
+- [PostgreSQL 18 transaction tutorial](https://www.postgresql.org/docs/18/tutorial-transactions.html)
+  — information about all-or-nothing transaction behavior and rollback.
+
+[Back to the engineering principles catalog](../README.md#p033)

package/skills/_support/docs/principles/details/p034-fail-fast.md

@@ -0,0 +1,132 @@
+# P034 — Fail Fast
+
+## Definition
+
+When a necessary invariant, configuration, dependency, or precondition is missing or incorrect, stop
+the applicable operation near the detection point. Before incorrect state causes corruption, incorrect
+output, or a symptom far from the defect, give a clear failure.
+
+**Aliases:** early failure, immediate visible failure, detect invalid state near its source
+
+## Provenance
+
+**Classification:** practitioner heuristic.
+
+Jim Shore gives information about the rule in IEEE Software (2004). That source is not the source
+of the phrase or rule.
+
+## Decision rule
+
+If continuation cannot satisfy the correctness and safety contract, fail at the nearest applicable
+boundary. That boundary must identify the defect and keep safe state.
+
+## How to apply
+
+- During startup or at the applicable entry boundary, validate necessary configuration and schemas.
+- Before the operation uses state, examine invariants. Record the violated condition with safe context.
+- Before irreversible work or work with high cost, reject malformed inputs and inputs that cannot be correct.
+- Select specified result types and error statuses that identify the defect. Use assertions only for
+  programmer invariants. Do not use sentinel defaults. They prevent detection near the source.
+- Make sure that termination releases resources. Give one diagnostic that tells the user how to
+  correct the defect.
+- Do tests of startup, boundary, and invariant failures. Do not limit tests to correct
+  execution.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Examine a necessary condition"] --> B{"Is the condition correct?"}
+    B -- "Yes" --> C["Continue the operation"]
+    B -- "No" --> D["Find the smallest applicable scope"]
+    D --> E["Keep correct state and release resources"]
+    E --> F["Show the defect clearly"]
+    F --> G["Stop the operation"]
+```
+
+## Language examples
+
+Each example rejects a missing endpoint before client creation.
+
+### Python
+
+```python
+def connect(config):
+    if not config.endpoint:
+        raise ConfigError("endpoint is required")
+    return Client(config.endpoint)
+```
+
+### Rust
+
+```rust
+fn connect(config: &Config) -> Result<Client, ConfigError> {
+    let endpoint = config
+        .endpoint
+        .as_ref()
+        .filter(|endpoint| !endpoint.is_empty())
+        .ok_or(ConfigError::MissingEndpoint)?;
+    Ok(Client::new(endpoint))
+}
+```
+
+## Boundaries and tensions
+
+This principle gives the conditions and location for a stop.
+[P035](p035-fail-secure-fail-closed.md) gives the safe authorization or security state after
+uncertainty. [P036](p036-graceful-degradation.md) gives reduced service for a noncritical
+capability with a specified safe fallback.
+
+A necessary capability must not become “optional” only to keep a process active.
+
+Use this principle only for the applicable scope. Isolate the operation with
+[P042](p042-fault-isolation-bulkheads.md). Use [P033](p033-state-safe-failure-semantics.md) to
+keep state. Stop only the scope that cannot operate correctly.
+
+## Examples
+
+### Positive application
+
+Before a service accepts traffic, it validates its necessary signing key. A missing key causes
+startup to fail with the configuration field name. Requests do not cause a signature error that
+fails to identify the source.
+
+### Misuse or counterexample
+
+A parser replaces a missing necessary identifier with an empty string. A database constraint fails
+after many layers. The result does not show the input defect.
+
+### Athena or agent workflow
+
+An Athena skill examines its declared hard dependency before it plans external steps. If the
+skill cannot use or get the dependency, it immediately gives a prerequisite-failure result. It does
+not give results that it did not receive. It does not give an incorrect success report.
+
+## Related principles
+
+- [P033 — State-Safe Failure Semantics](p033-state-safe-failure-semantics.md)
+- [P035 — Fail Secure / Fail Closed](p035-fail-secure-fail-closed.md)
+- [P036 — Graceful Degradation](p036-graceful-degradation.md)
+- [P042 — Fault Isolation / Bulkheads](p042-fault-isolation-bulkheads.md)
+
+## References
+
+### Source information
+
+- [Jim Shore, “Fail Fast,” IEEE Software (2004)](https://martinfowler.com/ieeeSoftware/failFast.pdf)
+  — a 2004 source that shows how failure at the detection point helps diagnostics.
+
+### Applicable information
+
+- [C++ Core Guidelines P.7](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#p7-catch-run-time-errors-early)
+  — applicable language guidance that recommends runtime-error detection near the source.
+- [Microsoft Azure, Design for self-healing](https://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/self-healing)
+  — applies circuit breakers to remote dependencies with continuous failures.
+
+### More information
+
+- [Microsoft Azure, Circuit Breaker pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker)
+  — shows how rejection at the caller boundary can prevent damage to the caller and dependency during continuous
+  failure.
+
+[Back to the engineering principles catalog](../README.md#p034)

package/skills/_support/docs/principles/details/p035-fail-secure-fail-closed.md

@@ -0,0 +1,137 @@
+# P035 — Fail Secure / Fail Closed
+
+## Definition
+
+When a security control does not give permission for an operation, keep the system in its safe
+state. Deny the capability, keep confidentiality and integrity, and give a failure result.
+
+Authentication, authorization, validation, and policy evaluation are security controls. A missing
+result, timeout, parse error, or exception must not become permission.
+
+**Aliases:** fail-safe defaults, deny by default on security failure
+
+## Provenance
+
+**Classification:** established principle.
+
+Saltzer and Schroeder included “fail-safe defaults” in their 1975 paper. Practitioners used “fail closed”
+and “fail secure” after 1975. These terms can have different meanings in safety engineering.
+
+## Decision rule
+
+After a clear authorization result gives permission, grant the protected operation. Classify
+missing, invalid, stale, or indeterminate security state as denial. A higher trusted contract can
+contain a different safe-state requirement.
+
+## How to apply
+
+- Set each authorization decision to denial. After all necessary checks succeed, change the
+  decision to permission.
+- Policy-service timeouts and errors are not decisions that give permission. They can share the
+  same external denial response.
+- When request validation or authorization fails, keep the protected resource.
+- Do tests with missing policy, dependency timeout, corrupt credentials, exception paths, and stale
+  state.
+- Record protected diagnostics that show the difference between denial and infrastructure failure. Do not show
+  secrets or sensitive policy information.
+- After the security dependency operates correctly, make service available again. If a higher
+  trusted contract does not give permission, do not operate without the dependency.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Receive a protected operation"] --> B{"Does the security result satisfy the applicable policy?"}
+    B -- "No" --> C["Deny the capability"]
+    B -- "Yes" --> D{"Does the result give permission for the operation?"}
+    D -- "No" --> C
+    D -- "Yes" --> E["Grant the capability"]
+    C --> F["Keep protected state"]
+    F --> G["Record a protected diagnostic"]
+```
+
+## Language examples
+
+After a clear result gives permission, each example grants deletion.
+
+### Python
+
+```python
+def may_delete(policy, actor, record):
+    try:
+        decision = policy.authorize(actor, "delete", record)
+    except PolicyError:
+        return False
+    return decision is Decision.ALLOW
+```
+
+### Rust
+
+```rust
+fn may_delete(policy: &Policy, actor: &Actor, record: &Record) -> bool {
+    matches!(
+        policy.authorize(actor, Action::Delete, record),
+        Ok(Decision::Allow)
+    )
+}
+```
+
+## Boundaries and tensions
+
+Fail closed is a security rule, not a general availability rule. For a feature without security
+risk, [P036](p036-graceful-degradation.md) can keep available service.
+
+A physical safe state other than “deny” can be necessary in a safety-critical system. The domain
+hazard analysis must include that state.
+
+With [P034](p034-fail-fast.md), an invalid security state causes failure near its source. This
+principle denies that capability. Use [P033](p033-state-safe-failure-semantics.md) for resource
+release and the correct failure state.
+
+## Examples
+
+### Positive application
+
+An authorization service does not give a response before the deadline. The API returns an unavailable or
+denied outcome and keeps the record. It records a protected correlation identifier for
+operators.
+
+### Misuse or counterexample
+
+Code sets `is_admin` to `true`. A role query fails, and the error path keeps the value. A security
+control that fails grants the highest privilege.
+
+### Athena or agent workflow
+
+When an agent cannot find authorization for a destructive command on the specified target, it
+stops and requests direction. Uncertainty does not become permission.
+
+## Related principles
+
+- [P033 — State-Safe Failure Semantics](p033-state-safe-failure-semantics.md)
+- [P034 — Fail Fast](p034-fail-fast.md)
+- [P036 — Graceful Degradation](p036-graceful-degradation.md)
+- [P053 — Validate at Trust Boundaries](../README.md#p053)
+
+## References
+
+### Source information
+
+- [Saltzer and Schroeder, “The Protection of Information in Computer Systems” (1975)](https://doi.org/10.1109/PROC.1975.9939)
+  — the primary source for the fail-safe-defaults principle. It uses clearly given permission for
+  access decisions, not exclusion.
+
+### Applicable information
+
+- [OWASP, Fail Securely](https://owasp.org/www-community/Fail_securely) — applicable application
+  guidance that puts security control exceptions on the disallow path.
+- [OWASP Developer Guide](https://owasp.org/www-project-developer-guide/assets/exports/OWASP_Developer_Guide.pdf)
+  — guidance for safe development that includes safe failure defaults in application design.
+
+### More information
+
+- [NIST SP 800-53 Rev. 5, AC-3 Access Enforcement](https://doi.org/10.6028/NIST.SP.800-53r5)
+  — an official control catalog for the enforcement of approved authorizations on system
+  access.
+
+[Back to the engineering principles catalog](../README.md#p035)

package/skills/_support/docs/principles/details/p036-graceful-degradation.md

@@ -0,0 +1,137 @@
+# P036 — Graceful Degradation
+
+## Definition
+
+A system can continue after a noncritical feature or dependency fails. The system must classify that
+capability as optional before the failure.
+
+The reduced mode must stay correct and safe. Operators must monitor its status. It must obey the
+specified contract.
+If the system did not do necessary work, its result must not show that the system did all work.
+
+**Aliases:** degraded mode, partial service, fallback capability
+
+## Provenance
+
+**Classification:** established principle.
+
+Fault-tolerant and distributed systems have used this rule for many years. Athena cannot identify
+one source for this software rule.
+
+## Decision rule
+
+If a capability was not in the optional category before failure, do not use a reduced mode. The
+tested fallback must keep all necessary invariants. If it does not, give a clear operation-failure result.
+
+## How to apply
+
+- Before an incident, classify each capability. Use required, optional, safety-critical, or
+  security-critical categories.
+- Give the reduced output, notice, entry condition, recovery condition, and maximum time in the
+  contract.
+- Select a fallback with a small number of steps and a bounded cost. For example, do not include
+  recommendations but keep the primary transaction.
+- Keep authorization, integrity, and necessary validation. Do not use a fallback without these
+  controls.
+- Record metrics and structured events at mode entry, at set intervals, and at recovery.
+- Do tests of the fallback during dependency failure and overload conditions.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["A capability fails"] --> B{"Was it optional before failure?"}
+    B -- No --> C["Give an operation-failure result"]
+    B -- Yes --> D{"Does the fallback keep all necessary invariants?"}
+    D -- No --> C
+    D -- Yes --> E["Give a reduced result that users can see"]
+    E --> F["Record mode state and do a recovery test"]
+```
+
+## Language examples
+
+Each example keeps product search and records the optional recommendation failure.
+
+### Python
+
+```python
+def build_view(products, recommendation_result):
+    if recommendation_result.is_error:
+        return {"products": products, "recommendations": [], "mode": "degraded"}
+    return {
+        "products": products,
+        "recommendations": recommendation_result.value,
+        "mode": "full",
+    }
+```
+
+### Rust
+
+```rust
+fn build_view(products: Vec<Product>, recommendations: Result<Vec<Product>, Error>) -> View {
+    match recommendations {
+        Ok(items) => View::full(products, items),
+        Err(_) => View::degraded(products, Vec::new()),
+    }
+}
+```
+
+## Boundaries and tensions
+
+Use [P034](p034-fail-fast.md) for a failed **required** capability or a violated invariant.
+Use [P035](p035-fail-secure-fail-closed.md) for an uncertain security decision. After failure,
+do not reclassify a capability to increase availability.
+
+Graceful degradation is not error suppression. When that fact changes meaning, correction, or
+service level, the result must show reduced service.
+
+Fallback paths can add failure modes. Their value must be more than their maintenance and test
+cost.
+
+## Examples
+
+### Positive application
+
+The recommendation service for a storefront fails. Product search and checkout continue. The site
+does not include the recommendation panel and records the reduced mode.
+
+### Misuse or counterexample
+
+After a card-charge request, a timeout occurs for a payment API. The charge result is unknown. The
+API returns “order completed” and does not show the necessary transaction uncertainty.
+
+### Athena or agent workflow
+
+An Athena skill can continue without optional web research. It uses results from repository checks
+and records the research limit. It must not give a citation if it did not examine the source. It
+must do each necessary dependency check.
+
+## Related principles
+
+- [P031 — Propagate Rather Than Swallow](p031-propagate-rather-than-swallow.md)
+- [P034 — Fail Fast](p034-fail-fast.md)
+- [P035 — Fail Secure / Fail Closed](p035-fail-secure-fail-closed.md)
+- [P042 — Fault Isolation / Bulkheads](p042-fault-isolation-bulkheads.md)
+
+## References
+
+### Source information
+
+- Athena does not identify one primary source for the general software phrase. Fault-tolerance work,
+  not one company, is the source of the rule.
+
+### Applicable information
+
+- [Microsoft Azure Well-Architected Framework, self-preservation](https://learn.microsoft.com/en-us/azure/well-architected/reliability/self-preservation)
+  — applicable guidance for the design, activation, communication, and recovery of a clearly specified reduced
+  mode.
+- [Google SRE, Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/)
+  — production guidance for degraded results during overload, with tests and telemetry for the
+  low-frequency path.
+
+### More information
+
+- [Microsoft Azure, Throttling pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/throttling)
+  — connects degradation with capacity controls, load shedding, and service-level objectives.
+
+[Back to the engineering principles catalog](../README.md#p036)