@homericintelligence/athena-opencode 0.5.0 → 0.5.1

package/skills/_support/docs/principles/details/p002-yagni.md

@@ -0,0 +1,109 @@
+# P002 — YAGNI
+
+## Definition
+
+**YAGNI** (*You Aren't Going to Need It* or *You Ain't Gonna Need It*) does not let authors add elements
+with no current requirement. These elements include functionality, extension points,
+configuration, abstraction, and infrastructure. Do only the work that evidence shows is necessary
+for the current requirement. Keep paths for change.
+
+## Provenance
+
+**Classification:** established principle.
+
+Extreme Programming is the source of YAGNI. Martin Fowler gives Chet Hendrickson as the
+source of the phrase after a conversation with Kent Beck. Sources give different expansions. Each expansion
+gives the principle the same meaning.
+
+## Decision rule
+
+If a proposed element is only for a future condition with no evidence, do not add it. Add the element
+for an accepted requirement, a condition that occurs more than one time, or a measured constraint.
+
+## How to apply
+
+- Keep current acceptance criteria isolated from future requests with no evidence.
+- Delete flags, hooks, providers, compatibility paths, and configuration that have no current requirement.
+- Use clear contracts and tests to make future change easy. Do not add extension points with no purpose.
+- When plan information has value and has an owner or trigger, record an idea for future work.
+- When evidence changes, examine the decision again.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Find a proposed element"] --> B{"Is it necessary for a current requirement?"}
+    B -->|No| C["Do not add the element"]
+    B -->|Yes| D["Do the minimum necessary implementation"]
+    C --> E["After new evidence, examine again"]
+    D --> E
+```
+
+## Language examples
+
+The two examples contain only the necessary delivery modes.
+
+```python
+def shipping_cost(express: bool) -> int:
+    if express:
+        return 20
+    return 5
+```
+
+```rust
+fn shipping_cost(express: bool) -> u32 {
+    if express {
+        20
+    } else {
+        5
+    }
+}
+```
+
+## Boundaries and tensions
+
+YAGNI does not let authors ignore explicit quality requirements, specified migrations, security
+controls, or protocol duties in the current scope. It rejects implementation with no evidence, not
+design necessary for the current requirement. [P004 SOLID](p004-solid.md) and
+[P005 Modularity](p005-modularity.md) can make a boundary necessary for a current requirement. They do
+not make a framework necessary when it has no current purpose.
+[P013 AHA](p013-avoid-hasty-abstractions.md) gives the related rule for abstraction time.
+
+## Examples
+
+**Positive:** A service uses the current repository interface for the one necessary authentication
+provider. It does not add a provider marketplace until approval of a second provider.
+
+**Misuse:** Although an alternative is necessary for a deployment requirement, a contributor does
+not add a configuration option for the value. This decision does not agree with the requirement.
+
+**Athena/agent workflow:** Evidence must show a product consumer for each artifact in a plan. The plan
+does not add a changelog, generator, registry, or compatibility layer for unknown requests.
+
+## Related principles
+
+- [P001 KISS](p001-kiss.md)
+- [P010 Scope Fidelity](p010-scope-fidelity.md)
+- [P013 AHA](p013-avoid-hasty-abstractions.md)
+- [P073 Optimize Only With Evidence](p073-optimize-only-with-evidence.md)
+
+## References
+
+### Source information
+
+- [Martin Fowler: Yagni](https://martinfowler.com/bliki/Yagni.html) gives Extreme Programming and Chet
+  Hendrickson as sources of the term. It also shows the economic basis.
+- [Extreme Programming Explained, second edition](https://www.pearson.com/en-us/subject-catalog/p/extreme-programming-explained-embrace-change/P200000000118/9780321278654)
+  is the publisher's record for the Extreme Programming book from Kent Beck and Cynthia Andres.
+
+### Applicable information
+
+- [Google Engineering Practices: What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)
+  tells reviewers to reject functionality with no current requirement.
+
+### More information
+
+- [Martin Fowler: Design Stamina Hypothesis](https://martinfowler.com/bliki/DesignStaminaHypothesis.html)
+  gives information about design work that has value without features that have no current requirement.
+
+[Back to the engineering principles catalog](../README.md#p002)

package/skills/_support/docs/principles/details/p003-dry.md

@@ -0,0 +1,126 @@
+# P003 — DRY
+
+## Definition
+
+**DRY** (*Don't Repeat Yourself*) gives each authoritative item of knowledge one canonical
+representation. DRY is for duplicate rules, schemas, calculations, and policies. It is not for
+each syntax sequence that occurs more than one time.
+
+## Provenance
+
+**Classification:** established principle.
+
+Andrew Hunt and David Thomas gave DRY its name and definition in *The Pragmatic Programmer*. Their definition
+is about duplicate knowledge in a system. Some authors do not keep this distinction and
+include all code that has almost the same text in DRY.
+
+## Decision rule
+
+When two representations must change together, select one authority. Derive the other representations
+from that authority. Connect each other representation to that authority with a derived form or a
+link. When code has only text that is almost the same, do not put it together.
+
+## How to apply
+
+- Find the fact or rule that must stay the same after one isolated edit.
+- Give one owner.
+- Connect each consumer to that authority with derivation or reference.
+- When different formats are necessary for consumers, use links and derived views. Do not use
+  manual copies.
+- When the same text does not show the same stable concept, do not put the logic together.
+- Do a test of the canonical behavior. Do not write one test for each text representation.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Find representations that must agree"] --> B["Select one authority"]
+    B --> C["Connect each consumer to the authority"]
+    C --> D{"Can one edit cause inconsistency?"}
+    D -->|Yes| B
+    D -->|No| E["Keep one clear authority"]
+```
+
+## Language examples
+
+The two examples accept cents in the unsigned 64-bit domain. Each example uses one 20-percent
+tax-rate authority and rounds half up to the nearest cent.
+
+```python
+TAX_BPS = 2_000
+BASIS_POINTS = 10_000
+
+def tax_cents(subtotal_cents: int) -> int:
+    if type(subtotal_cents) is not int:
+        raise TypeError("subtotal must be an integer")
+    if not 0 <= subtotal_cents <= 2**64 - 1:
+        raise ValueError("subtotal is not in the unsigned 64-bit domain")
+    return (subtotal_cents * TAX_BPS + BASIS_POINTS // 2) // BASIS_POINTS
+
+def total_cents(subtotal_cents: int) -> int:
+    return subtotal_cents + tax_cents(subtotal_cents)
+```
+
+```rust
+const TAX_BPS: u128 = 2_000;
+const BASIS_POINTS: u128 = 10_000;
+
+fn tax_cents(subtotal_cents: u64) -> u128 {
+    let subtotal = u128::from(subtotal_cents);
+    (subtotal * TAX_BPS + BASIS_POINTS / 2) / BASIS_POINTS
+}
+
+fn total_cents(subtotal_cents: u64) -> u128 {
+    u128::from(subtotal_cents) + tax_cents(subtotal_cents)
+}
+```
+
+## Boundaries and tensions
+
+Some duplication can help local analysis or keep unrelated domains isolated. Centralization
+before sufficient evidence can make an incorrect abstraction and tighter coupling. Before you
+extract shared code, use [P013 AHA](p013-avoid-hasty-abstractions.md). Before you add shared mutable
+state, use [P005 Modularity](p005-modularity.md). A registry or generator is not
+necessary for DRY when repository discovery supplies the answer. Evidence for a product consumer
+must show that each artifact is necessary.
+
+## Examples
+
+**Positive:** One schema is the authority. API documentation and validators derive from it or have links to it.
+They do not use a manual restatement of field constraints.
+
+**Misuse:** Two domain workflows contain the same three steps. A generic engine puts them together,
+although their policies and causes of change are different.
+
+**Athena/agent workflow:** The principles catalog has authority for IDs and definitions. Skills have links to the
+applicable principles and show only the workflow effects of those principles.
+
+## Related principles
+
+- [P005 Modularity](p005-modularity.md)
+- [P013 AHA](p013-avoid-hasty-abstractions.md)
+- [P074 Prefer Existing Mechanisms](p074-prefer-existing-mechanisms.md)
+- [P078 Single Source of Truth](p078-single-source-of-truth.md)
+- [P084 Prefer Local Reasoning](p084-prefer-local-reasoning.md)
+
+## References
+
+### Source information
+
+- [The Pragmatic Programmer DRY excerpt](https://media.pragprog.com/titles/tpp20/dry.pdf) gives
+  the authors' definition and examples of duplicate knowledge.
+- [The Pragmatic Programmer, 20th Anniversary Edition](https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/)
+  is the publisher's current book record.
+
+### Applicable information
+
+- [Google Engineering Practices: What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html).
+  The guidance tells reviewers to find if a change belongs in the codebase or a library. It
+  also tells reviewers to find complexity that is not necessary.
+
+### More information
+
+- [Sandi Metz: The Wrong Abstraction](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction)
+  shows that duplicate removal before sufficient evidence can have more cost than a temporary duplicate.
+
+[Back to the engineering principles catalog](../README.md#p003)

package/skills/_support/docs/principles/details/p004-solid.md

@@ -0,0 +1,165 @@
+# P004 — SOLID
+
+## Definition
+
+**SOLID** is a family of five object-oriented design principles. The family contains Single
+Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.
+Use these principles to give clear responsibilities. Make dependencies agree with stable behavioral
+contracts. Classes and interfaces are not necessary for SOLID.
+
+### The five principles
+
+#### Single Responsibility Principle (SRP)
+
+A module or component must have one primary responsibility and one cause of change.
+Responsibility is about policy ownership, not the number of functions or lines in a file.
+
+#### Open/Closed Principle (OCP)
+
+A stable component must have a specified extension mechanism for necessary variation.
+For each new variation, the mechanism must not change core policy. Abstractions for unknown
+variations are not necessary for OCP.
+
+#### Liskov Substitution Principle (LSP)
+
+A subtype or implementation must keep the observable contract of its abstraction. This
+contract includes applicable inputs, promised outputs, invariants, and failure semantics.
+
+#### Interface Segregation Principle (ISP)
+
+Clients must have dependencies only on capabilities that they use. Select cohesive, role-oriented
+interfaces. Consumers of interfaces with many responsibilities must accept methods or permissions
+with no purpose.
+
+#### Dependency Inversion Principle (DIP)
+
+High-level policy must have no dependency on low-level details that can change. High-level
+policy and low-level details must have dependencies on a stable contract at the correct boundary.
+Dependency injection is one method, not the principle.
+
+## Provenance
+
+**Classification:** established principle.
+
+Robert C. Martin wrote separate papers about the five principles. One paper describes Single
+Responsibility. A second paper includes the other four principles. Bertrand Meyer was the first
+source for Open/Closed. Barbara Liskov and Jeannette Wing give Liskov Substitution a formal basis.
+
+## Decision rule
+
+When evidence shows a responsibility, variation point, or substitution contract, use an applicable
+SOLID principle to make it clear. Do not add abstraction only for the SOLID name.
+
+## How to apply
+
+- Before you divide responsibilities, find actors, policy owners, and causes of change.
+- Only when evidence shows a variation, add an extension seam for that variation.
+- Before a substitution claim, give the behavioral contracts.
+- Give consumers the narrowest capability surface for one role.
+- Make dependencies point to stable policy. Keep system connections clear.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Find a responsibility or contract"] --> B{"Which SOLID principle is applicable?"}
+    B --> C["Give one responsibility"]
+    B --> D["Specify necessary variation"]
+    B --> E["Keep substitution behavior"]
+    B --> F["Give each client only necessary capability"]
+    B --> G["Make dependencies point to stable policy"]
+    C --> H["Make sure there is a clear design benefit"]
+    D --> H
+    E --> H
+    F --> H
+    G --> H
+```
+
+## Language examples
+
+The two examples use signed 32-bit amounts and give invoice policy a dependency on a narrow tax contract.
+
+```python
+from collections.abc import Callable
+
+I32_MIN, I32_MAX = -(2**31), 2**31 - 1
+
+def invoice_total(subtotal: int, tax: Callable[[int], int]) -> int:
+    if type(subtotal) is not int or not I32_MIN <= subtotal <= I32_MAX:
+        raise OverflowError("amount is not in the i32 range")
+    tax_value = tax(subtotal)
+    if type(tax_value) is not int or not I32_MIN <= tax_value <= I32_MAX:
+        raise OverflowError("amount is not in the i32 range")
+    total = subtotal + tax_value
+    if not I32_MIN <= total <= I32_MAX:
+        raise OverflowError("amount is not in the i32 range")
+    return total
+```
+
+```rust
+trait Tax {
+    fn for_subtotal(&self, subtotal: i32) -> i32;
+}
+
+fn invoice_total<T: Tax>(subtotal: i32, tax: &T) -> Result<i32, &'static str> {
+    subtotal
+        .checked_add(tax.for_subtotal(subtotal))
+        .ok_or("amount is not in the i32 range")
+}
+```
+
+## Boundaries and tensions
+
+Object-oriented design is the source of SOLID. Keep its behavioral intent in functional,
+data-oriented, or procedural systems. If evidence shows no requirement for an interface, class, or
+dependency injection mechanism, that addition does not obey [P001 KISS](p001-kiss.md),
+[P002 YAGNI](p002-yagni.md), and [P013 AHA](p013-avoid-hasty-abstractions.md). Current architecture and repository contracts are
+more important than a SOLID interpretation with no evidence.
+
+## Examples
+
+**Positive:** Business policy has a dependency on a narrow storage capability. Production and test
+adapters obey the same error and transaction contract.
+
+**Misuse:** Each function receives a one-method interface, although there is only one stable
+implementation. No necessary substitution makes the added indirection necessary.
+
+**Athena/agent workflow:** A skill has responsibility for its workflow policy and uses an explicit capability boundary
+to delegate execution. It records behavior for a missing capability.
+
+## Related principles
+
+- [P005 Modularity](p005-modularity.md)
+- [P013 AHA](p013-avoid-hasty-abstractions.md)
+- [P016 Separation of Concerns](p016-separation-of-concerns.md)
+- [P017 High Cohesion, Low Coupling](p017-high-cohesion-low-coupling.md)
+- [P018 Information Hiding](p018-information-hiding.md)
+- [P019 Explicit Contracts](p019-explicit-contracts.md)
+
+## References
+
+### Source information
+
+- [Robert C. Martin: The Single Responsibility Principle](https://objectmentor.com/resources/articles/srp.pdf)
+  shows that responsibility is a cause of change. The paper shows that a class must have only one such
+  cause.
+- [Robert C. Martin: Design Principles and Design Patterns](https://objectmentor.com/resources/articles/Principles_and_Patterns.pdf)
+  includes Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion in one
+  primary paper.
+- [Bertrand Meyer: Object-Oriented Software Construction](https://bertrandmeyer.com/OOSC2/)
+  is the author's page for the work that is the source of the Open/Closed Principle.
+- [Liskov and Wing: A Behavioral Notion of Subtyping](https://doi.org/10.1145/197320.197383)
+  gives the formal basis for behavioral substitution.
+
+### Applicable information
+
+- [Microsoft: Architectural principles](https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles)
+  gives separation of concerns, explicit dependencies, single responsibility, and dependency
+  inversion as application-architecture principles.
+
+### More information
+
+- [Bertrand Meyer: Applying Design by Contract](https://www.kth.se/social/files/59526bfb56be5b4f17000807/meyer-92-contracts.pdf)
+  gives the precondition, postcondition, and invariant model for LSP analysis.
+
+[Back to the engineering principles catalog](../README.md#p004)

package/skills/_support/docs/principles/details/p005-modularity.md

@@ -0,0 +1,123 @@
+# P005 — Modularity
+
+## Definition
+
+**Modularity** divides a system into cohesive components with clear interfaces and a small number
+of dependencies. A change in one module must have a small number of effects on unrelated
+modules.
+
+## Provenance
+
+**Classification:** established principle.
+
+Modular design was in engineering before modern software. David Parnas's 1972 paper is an important
+source for software modularity. The paper tells designers to put decisions that can change in modules
+with clear boundaries. An operation sequence is not sufficient to specify the boundaries.
+
+## Decision rule
+
+When a module boundary gives one responsibility a clear owner, select that boundary. A
+boundary can also hide a decision that can change or contain change and failure. Do not divide a system
+only to increase its module count.
+
+## How to apply
+
+- When behavior and data share policy and causes of change, keep them together.
+- Give a small contract.
+- Hide implementation decisions.
+- Make dependency direction clear. Find boundary crossings that are not necessary.
+- When product independence is necessary, use the same boundary for deployment, failure, and ownership.
+- Do a test of each module's behavior and the contracts that connect modules.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Find one responsibility"] --> B["Give one module owner"]
+    B --> C["Give a small contract"]
+    C --> D["Hide decisions that can change"]
+    D --> E{"Does the boundary contain the change?"}
+    E -->|No| B
+    E -->|Yes| F["Keep the boundary"]
+```
+
+## Language examples
+
+The two examples accept only ASCII decimal digits for ports from 1 to 65,535.
+
+```python
+def parse_port(text: str) -> int:
+    if not text.isascii() or not text.isdigit():
+        raise ValueError("port is not correct")
+    try:
+        port = int(text)
+    except ValueError as error:
+        raise ValueError("port is not correct") from error
+    if not 1 <= port <= 65_535:
+        raise ValueError("port is not correct")
+    return port
+```
+
+```rust
+fn parse_port(text: &str) -> Result<u16, &'static str> {
+    if text.is_empty() || !text.bytes().all(|byte| byte.is_ascii_digit()) {
+        return Err("port is not correct");
+    }
+    let port = text.parse::<u16>().map_err(|_| "port is not correct")?;
+    if port == 0 {
+        return Err("port is not correct");
+    }
+    Ok(port)
+}
+```
+
+## Boundaries and tensions
+
+Physical separation is not sufficient for modularity. Small packages can make calls at all
+boundaries and can share mutable state or cyclic dependencies. Such packages can have less
+modularity than one cohesive component.
+
+Distributed services add boundaries in operation. Do not add them only for code organization.
+When you use [P003 DRY](p003-dry.md), keep local ownership. Before you change an established
+boundary, use [P012 Evidence Before Modification](p012-evidence-before-modification.md).
+
+## Examples
+
+**Positive:** A parser has responsibility for external syntax and returns a stable internal value. Business policy
+has a dependency on that value, not on parser details.
+
+**Misuse:** A small application uses services that must deploy together and share one database.
+This design adds network failure without a specified owner or evolution path.
+
+**Athena/agent workflow:** Canonical skills are in `skills/`. Host manifests have links to those
+skills and do not contain skill copies for one host.
+
+## Related principles
+
+- [P004 SOLID](p004-solid.md)
+- [P015 Architecture Conformance](p015-architecture-conformance.md)
+- [P016 Separation of Concerns](p016-separation-of-concerns.md)
+- [P017 High Cohesion, Low Coupling](p017-high-cohesion-low-coupling.md)
+- [P018 Information Hiding](p018-information-hiding.md)
+- [P077 Separate Policy from Mechanism](p077-separate-policy-from-mechanism.md)
+
+## References
+
+### Source information
+
+- [David Parnas: On the Criteria To Be Used in Decomposing Systems into Modules](https://doi.org/10.1145/361598.361623).
+  The paper connects modular boundaries to hidden design decisions.
+
+### Applicable information
+
+- [Microsoft: Architectural principles](https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles)
+  shows that separation of concerns and encapsulation are architecture practices.
+- [SEI: Quality Attribute Workshops](https://www.sei.cmu.edu/library/quality-attribute-workshops/)
+  gives a method that connects architecture decisions to specified quality requirements.
+
+### More information
+
+- [Liskov and Wing: A Behavioral Notion of Subtyping](https://doi.org/10.1145/197320.197383)
+  gives information for analysis of module contracts with substitutable implementations.
+
+[Back to the engineering principles catalog](../README.md#p005)

package/skills/_support/docs/principles/details/p006-principle-of-least-astonishment.md

@@ -0,0 +1,115 @@
+# P006 — Principle of Least Astonishment
+
+## Definition
+
+For the **Principle of Least Astonishment** (**POLA**, also the principle of least surprise),
+behavior must agree with user expectations that evidence shows. POLA is applicable to interfaces, defaults,
+state changes, and failures. The system context and specified contract give evidence for those
+expectations.
+
+## Provenance
+
+**Classification:** practitioner heuristic.
+
+The phrase has a long history in language and interface design. No source supplies sufficient
+evidence for the source of the phrase. Context also changes POLA. User expectations are not the
+same for all audiences.
+Repository precedent and research with users have more value as evidence than a design that personnel select without evidence.
+
+## Decision rule
+
+When there are two or more correct designs, examine the public contract, local conventions, and evidence
+about user expectations. Select the design that agrees with this evidence. Make each necessary
+difference clear. Give a safe migration.
+
+## How to apply
+
+- Find the intended audience and its conventions that evidence shows.
+- Make sure names, defaults, units, mutability, side effects, and errors agree with related conventions.
+- Use clear confirmation or clear names for destructive behavior and behavior not in user expectations.
+- Keep expectations that evidence shows for related CLI, API, and configuration operations.
+- Do a test of defaults and failure behavior in the public contract.
+
+## Diagram
+
+```mermaid
+flowchart TD
+    A["Find the intended audience"] --> B["Examine contracts and conventions"]
+    B --> C["Select a design that agrees with conventions"]
+    C --> D{"Does behavior agree with user expectations?"}
+    D -->|No| E["Make the difference clear"]
+    E --> C
+    D -->|Yes| F["Do a test of defaults and failures"]
+```
+
+## Language examples
+
+Explicit confirmation is necessary before the destructive step in the two examples.
+
+```python
+def delete_user(user_id: str, confirmed: bool) -> None:
+    if not confirmed:
+        raise ValueError("confirmation is necessary")
+    database.delete(user_id)
+```
+
+```rust
+fn delete_user(user_id: &str, confirmed: bool) -> Result<(), &'static str> {
+    if !confirmed {
+        return Err("confirmation is necessary");
+    }
+    database_delete(user_id);
+    Ok(())
+}
+```
+
+## Boundaries and tensions
+
+POLA is not applicable when personnel know that behavior is dangerous. Security controls, correct behavior, accessibility, or an
+explicit specification can make an explicit change from precedent necessary. Make the difference clear.
+Give a migration that is safe.
+[P014 Preserve Unrequested Behavior](p014-preserve-unrequested-behavior.md) gives protection to established
+contracts. [P019 Explicit Contracts](p019-explicit-contracts.md) decreases ambiguity when expectations
+are not the same.
+
+## Examples
+
+**Positive:** A `--dry-run` flag does no external writes and gives the planned actions for a
+usual operation.
+
+**Misuse:** A command with the name `list` repairs and deletes stale resources without notice because cleanup
+is easy during enumeration.
+
+**Athena/agent workflow:** A skill uses its documented fallback when a necessary capability is
+missing. It does not select a workflow with more authority without notice.
+
+## Related principles
+
+- [P014 Preserve Unrequested Behavior](p014-preserve-unrequested-behavior.md)
+- [P019 Explicit Contracts](p019-explicit-contracts.md)
+- [P049 Secure by Default](p049-secure-by-default.md)
+- [P071 Consistency Over Personal Preference](p071-consistency-over-personal-preference.md)
+- [P085 Explicit Is Better Than Implicit](p085-explicit-is-better-than-implicit.md)
+
+## References
+
+### Source information
+
+- [The Open Group Base Specifications, Utility Syntax Guidelines](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html)
+  give established consistency rules for command interfaces. They show POLA but do not
+  give a source for the phrase.
+
+### Applicable information
+
+- [Google Cloud API Design Guide](https://cloud.google.com/apis/design) shows that resource-oriented
+  conventions are important properties of API design. Related APIs that use the conventions have
+  the same behavior.
+- [Google API Improvement Proposals: General principles](https://google.aip.dev/general) gives
+  conventions that agree for related APIs.
+
+### More information
+
+- [PEP 20 — The Zen of Python](https://peps.python.org/pep-0020/) gives a short example of how
+  a language community records expectations for clear design in which related properties agree.
+
+[Back to the engineering principles catalog](../README.md#p006)