@homericintelligence/athena-opencode 0.5.1 → 0.5.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@homericintelligence/athena-opencode",
-  "version": "0.5.1",
+  "version": "0.5.2",
   "description": "Athena provides workflow skills as an opencode plugin.",
   "license": "BSD-3-Clause",
   "type": "module",

package/skills/_cli.py

@@ -114,11 +114,14 @@ def require_unambiguous_git_merge_base(
 
 
 def plugin_version() -> str:
-    """Return the version from the canonical Codex plugin manifest."""
-    manifest = PLUGIN_ROOT / ".codex-plugin" / "plugin.json"
+    """Return this corpus's generated version or its adjacent canonical manifest."""
+    corpus = Path(__file__).resolve().parent
+    manifest = corpus / "_plugin.json"
+    if not manifest.exists() and corpus.name == "skills":
+        manifest = PLUGIN_ROOT / ".codex-plugin" / "plugin.json"
     document = json.loads(manifest.read_text(encoding="utf-8"))
     version = document.get("version") if isinstance(document, dict) else None
-    if not isinstance(version, str):
+    if not isinstance(version, str) or not version.strip():
         raise TypeError(
             f"The plugin manifest does not contain a string version: '{manifest}'."
         )
@@ -138,7 +141,7 @@ class _PluginVersionAction(argparse.Action):
         del namespace, values, option_string
         try:
             version = plugin_version()
-        except (OSError, TypeError, json.JSONDecodeError) as error:
+        except (OSError, TypeError, UnicodeError, json.JSONDecodeError) as error:
             parser.exit(
                 1,
                 f"{parser.prog}: error: The tool cannot read the plugin version: "

package/skills/_plugin.json

@@ -0,0 +1 @@
+{"version": "0.5.2"}

package/skills/_support/docs/dependency-resolution.md

@@ -1,54 +1,64 @@
-# Required repository resolution
+# Repository resolution
 
 Apply the [ASD-STE100 technical-English policy](../../TECHNICAL_ENGLISH.md) to all English technical prose
 in this document.
 
-**Why:** Athena must use trusted and current knowledge and automation. It must not use a repository
-only because it has a similar name. It must not use a stale checkout or an unverified remote.
+**Why:** Athena must use trusted and current repositories when it changes Mnemosyne or executes
+Hephaestus. Read-only knowledge can use a validated local checkout and then try a best-effort
+refresh. Athena must not report an unverified remote or stale checkout as current.
 
 ## At a glance
 
-During normal resolution, Athena does these steps:
+During normal resolution for a write or automation execution, Athena does these steps:
 
 1. It resolves a trusted owner.
 2. It synchronizes an exact checkout.
 3. It binds use to the reported revision.
 
-A trust, authentication, checkout, or update failure stops the dependent skill.
+A trust, authentication, checkout, or update failure stops that write or automation execution.
 
-In planning mode, an explicit read-only path can use an existing checkout as a best-effort source.
-This path does not synchronize with the upstream repository. It must do these actions:
+All read-only Mnemosyne paths validate the local checkout first. If `gh`, authentication, and
+network access are available, Athena then tries a best-effort refresh. If the refresh cannot run
+or fails, Athena keeps the validated local checkout and reports the freshness limit. This path
+must do these actions:
 
 - bind use to the current `HEAD`;
-- report the current `HEAD`;
+- report the current `HEAD` or the refreshed revision;
 - report the freshness and trust limits;
 - never substitute a different repository; and
-- never make a durable write.
+- never make a durable write from that checked state.
 
-A skill can impose stricter requirements. The `learn` skill requires a usable checkout before it
-starts discovery or writes a lesson. In planning mode, its discovery path does not create a checkout.
+If local knowledge is unavailable, stop only knowledge retrieval. Continue the primary task. The
+`learn` skill can classify a candidate, but it must complete normal resolution and duplicate checks
+before a durable write.
 
 ```mermaid
 flowchart LR
-    A["Resolve dependency"] --> B{"Is there an explicit owner?"}
-    B -->|yes| C["Validate override"]
-    B -->|no| D{"Is there a trusted organization fork?"}
-    D -->|yes| E["Use maintained fork"]
-    D -->|no| F["Use canonical upstream"]
-    C --> G["Verify origin and clean checkout"]
-    E --> G
-    F --> G
-    G --> H{"Is this the read-only planning path?"}
-    H -->|yes| I["Inspect existing checkout; bind current HEAD; report limits"]
-    H -->|no| J["Fetch, fast-forward, and bind SHA"]
-    J --> K["Revalidate automatic-fork trust before use"]
+    A["Resolve dependency"] --> B{"Read-only Mnemosyne use?"}
+    B -->|yes| C{"Is a local checkout readable?"}
+    C -->|no| E["Report no local guidance; continue primary task"]
+    C -->|yes| D["Bind local HEAD and report limits"]
+    D --> F{"Can gh auth and discovery run?"}
+    F -->|yes| G["Try refresh, then report the updated revision or the local fallback"]
+    F -->|no| H["Keep the validated local revision and report the freshness limit"]
+    B -->|no| I{"Is there an explicit owner?"}
+    I -->|yes| J["Validate override"]
+    I -->|no| K{"Is there a trusted organization fork?"}
+    K -->|yes| L["Use maintained fork"]
+    K -->|no| M["Use canonical upstream"]
+    J --> N["Verify origin and clean checkout"]
+    L --> N
+    M --> N
+    N --> O["Fetch, fast-forward, and bind SHA"]
+    O --> P["Revalidate automatic-fork trust before use"]
 ```
 
 ## Component details
 
 ### Owner selection
 
-For dependency `<Repository>` with environment override `<OWNER_VARIABLE>`, use these steps:
+For a route that needs normal resolution of dependency `<Repository>` with environment override
+`<OWNER_VARIABLE>`, use these steps:
 
 1. If `<OWNER_VARIABLE>` is not empty, select `<value>/<Repository>`.
 
@@ -123,7 +133,8 @@ information:
 
 ### Checkout and revalidation
 
-Normal resolution requires these capabilities:
+Normal resolution applies to Mnemosyne delivery and Hephaestus execution. It requires these
+capabilities:
 
 - authenticated GitHub CLI (`gh`);
 - `git`; and
@@ -140,7 +151,7 @@ repository. For an existing checkout, do these checks and actions:
 - Report the resolved repository and commit SHA.
 
 For an automatically selected same-owner fork, repeat the trust checks immediately before use. Do
-this before you read knowledge or execute automation. Re-query these values:
+this before you write knowledge or execute automation. Re-query these values:
 
 - the Organization owner of the current repository;
 - the permission of the viewer;
@@ -153,15 +164,15 @@ Require these values to agree with the reported trust decision. Require the chec
 agree with the re-queried tip SHA. Stop if a value does not agree. This check closes the race between
 resolution and use.
 
-### Read-only local best effort
+### Read-only knowledge access
 
-Use this exception only for a read-only planning path or a `learn` discovery path. The path can
-inspect an existing checkout. It can bind use to the current `HEAD` without these actions:
+Use this path for all read-only Mnemosyne retrieval. Inspect the existing checkout first. Bind use
+to the current `HEAD`. If `gh`, authentication, and network access are available, try a refresh. If
+the refresh cannot run or fails, keep the validated local checkout and report the freshness limit.
 
-- clone;
-- fetch;
-- fast-forward; or
-- revalidation of an automatic fork.
+Do not require the local checkout to have the newest Mnemosyne revision. Do not require its
+revision to agree with the installed Athena revision. The installed skill supplies its own
+retrieval contract.
 
 Report this information:
 
@@ -170,11 +181,11 @@ Report this information:
 - the trust basis or trust uncertainty; and
 - the freshness limit.
 
-If the checkout is missing or inspection fails, stop the dependent knowledge retrieval. The caller
-can continue its primary plan only when its skill contract permits planning without guidance. The
-`learn` skill does not permit this fallback. It blocks without an existing usable checkout.
+If the checkout is missing or inspection fails, stop the dependent knowledge retrieval. Continue the
+primary task. `learn` can classify an undelivered candidate, but it cannot make a duplicate decision
+or publish a write until normal resolution succeeds.
 
-For normal execution and the `learn` delivery boundary, these conditions are fatal:
+For Hephaestus execution and the `learn` delivery boundary, these conditions are fatal:
 
 - an authentication failure;
 - a missing repository;
@@ -185,7 +196,7 @@ For normal execution and the `learn` delivery boundary, these conditions are fat
 - a fetch failure; or
 - a fast-forward failure.
 
-The read-only local exception never permits pull-request creation before upstream synchronization.
+Read-only local access never permits pull-request creation before upstream synchronization.
 
 Mnemosyne writes use isolated worktrees and always end in a pull request. Athena reads or executes
 Hephaestus from its canonical checkout. Athena never edits Hephaestus unless the user explicitly asks

package/skills/_support/docs/policies/development.md

@@ -25,9 +25,15 @@ or failure requirement to make text shorter.
 
 - Target `main`.
 - Keep the scope aligned with one issue or one coherent maintenance objective.
+- Before you create a pull request, run each new or changed test with a focused local command.
+  Confirm that the command selects that test and that the test passes.
+- Continuous integration and continuous delivery (CI/CD) workflows, not pre-commit, run the
+  automatic pytest tiers. Focused local validation does not replace CI/CD validation.
 - If an issue tracks the work, put `Closes #N` on its own line in the body.
 - Run required checks against the current head revision. The checks must be successful, current, and
   not incorrectly skipped.
+- Do not say that a check passed in the PR description unless the description can cite the current
+  head receipt that supports the claim.
 - Before auto-merge or merge, get an independent strict review.
 - Use a merge method that the repository supports. Do not guess or impose an organization-wide
   fallback.
@@ -90,10 +96,17 @@ or failure requirement to make text shorter.
 
 - Add such an artifact only when a current consumer requires it. The owner and update method must be
   explicit.
+- The marked development-principles block in root `AGENTS.md` is generated data that the fleet
+  agent-contract validator consumes. `docs/principles/README.md` owns its content. The
+  agent-contract renderer owns its update method. Do not edit the block manually.
+- Use this sequence for each change: remove, reuse, consolidate, simplify, then add. Add only when
+  the earlier choices cannot meet the requirement.
 - Tests must verify computable behavior, data contracts, security properties, or executable artifact
   structure.
 - Do not test prose wording, headings, paragraph presence, document counts, or duplicated text
   strings.
+- Exact machine-consumed fields are data contracts, not editorial prose. This exception includes
+  the root `CLAUDE.md` pointer and the generated development-principles block.
 - Markdown lint and link checks can verify document syntax and link resolution. They must not freeze
   editorial content.
 - Prefer stable public outcomes to these types of assertions:
@@ -113,5 +126,6 @@ or failure requirement to make text shorter.
 
 Human review and Code Owner review are optional for Athena changes. They are not required.
 `CODEOWNERS` records advisory ownership. The baseline ruleset does not require an approval count or a
-Code Owner approval. Workflow, release, dependency, and security-control changes remain subject to
-the required checks and requested-scope boundaries of the repository.
+Code Owner approval. The baseline ruleset still requires extra approval for unattributed changes.
+Workflow, release, dependency, and security-control changes remain subject to the required checks
+and requested-scope boundaries of the repository.

package/skills/_support/docs/principles/README.md

@@ -38,8 +38,45 @@ ungranted high-impact actions. A different party does an independent review. The
 qualifications sufficient for the risk. Human review is necessary only when applicable policy specifies
 a human.
 
+## Topic anchors
+
+Review contracts use these stable topic anchors to classify a surface. The numeric catalog below is
+authoritative. Each detail page describes relationships with other principles.
+
 ## Simplicity and change
 
+Use this topic for scope, change size, reversibility, deletion, and necessary complexity.
+
+## Architecture, interfaces, and state
+
+Use this topic for boundaries, dependencies, interfaces, ownership, and state.
+
+## Testing and evidence
+
+Use this topic for test design, traceability, verification, and evidence.
+
+## Error handling
+
+Use this topic for failures, diagnostics, recovery, and cleanup.
+
+## Distributed reliability
+
+Use this topic for concurrency, retries, idempotency, coordination, and operations.
+
+## Security and supply chain
+
+Use this topic for trust boundaries, validation, dependencies, provenance, and least privilege.
+
+## Agent authority
+
+Use this topic for scope, permissions, external effects, and human approval.
+
+## Stewardship and judgment
+
+Use this topic for preservation, code health, technical evidence, and delivery.
+
+## Canonical catalog
+
 ### P001
 
 [KISS — Keep It Simple, Stupid](details/p001-kiss.md) — Select the design with minimum complexity that
@@ -55,6 +92,22 @@ configuration, and infrastructure only for a specified current requirement.
 [DRY — Don't Repeat Yourself](details/p003-dry.md) — Give each authoritative rule or item of
 knowledge one canonical representation.
 
+### P004
+
+[SOLID](details/p004-solid.md) — Give each responsibility one clear owner. Connect each extension seam
+to a requirement. Make substitutions keep contracts. Make each interface applicable to its consumer.
+Keep high-level policy free from dependencies on details that can change.
+
+### P005
+
+[Modularity](details/p005-modularity.md) — Make cohesive modules with narrow interfaces and low
+coupling. Thus, local changes have local effects.
+
+### P006
+
+[POLA — Principle of Least Astonishment](details/p006-principle-of-least-astonishment.md) — Make
+interfaces, defaults, behavior, and failures agree with user expectations that evidence shows.
+
 ### P007
 
 [Subtraction Over Addition](details/p007-subtraction-over-addition.md) — Before you add a component,
@@ -97,57 +150,6 @@ show the same stable concept, generalize. When the alternative is an incorrect a
 [Preserve Unrequested Behavior](details/p014-preserve-unrequested-behavior.md) — Unless a specified
 requirement changes them, keep current observable contracts.
 
-### P021
-
-[Evolutionary and Reversible Design](details/p021-evolutionary-and-reversible-design.md) — Select
-incremental, migration-safe steps. Each step must let an author make sure that the step is correct,
-use a bounded rollback, or use a bounded roll-forward path.
-
-### P073
-
-[Optimize Only With Evidence](details/p073-optimize-only-with-evidence.md) — Measure first. When
-measurements show a constraint or bottleneck, add optimization complexity.
-
-### P074
-
-[Prefer Existing Mechanisms](details/p074-prefer-existing-mechanisms.md) — Before you make a new
-mechanism, select an applicable repository, language, framework, or standard-library mechanism.
-
-### P088
-
-[Delete Dead Code](details/p088-delete-dead-code.md) — Remove code that no execution path or consumer
-uses. Also remove unreachable, superseded, or obsolete code. First, make sure that deletion is safe.
-
-### P089
-
-[Delete Obsolete Configuration and Dependencies](details/p089-delete-obsolete-configuration-and-dependencies.md)
-— After evidence shows that no consumer uses the artifact, remove the configuration, dependencies,
-tests, documentation, and scaffolding.
-
-### P090
-
-[Prefer Negative Code](details/p090-prefer-negative-code.md) — For equally correct and clear
-solutions, select less code and maintenance. Also select less state, configuration, dependency surface,
-and conceptual complexity.
-
-## Architecture, interfaces, and state
-
-### P004
-
-[SOLID](details/p004-solid.md) — Give each responsibility one clear owner. Connect each extension seam
-to a requirement. Make substitutions keep contracts. Make each interface applicable to its consumer.
-Keep high-level policy free from dependencies on details that can change.
-
-### P005
-
-[Modularity](details/p005-modularity.md) — Make cohesive modules with narrow interfaces and low
-coupling. Thus, local changes have local effects.
-
-### P006
-
-[POLA — Principle of Least Astonishment](details/p006-principle-of-least-astonishment.md) — Make
-interfaces, defaults, behavior, and failures agree with user expectations that evidence shows.
-
 ### P015
 
 [Architecture Conformance](details/p015-architecture-conformance.md) — If the requirement does not
@@ -180,54 +182,11 @@ inputs, outputs, invariants, ownership, side effects, concurrency, and failure b
 [Executable Architecture](details/p020-executable-architecture.md) — When resources are sufficient and
 the check decreases risk, use executable checks for important architecture rules. Do not let prose be the only control.
 
-### P075
-
-[Make Invalid States Hard to Represent](details/p075-make-invalid-states-hard-to-represent.md) — Use
-types, schemas, construction boundaries, and state machines to prevent invalid combinations.
-
-### P076
-
-[Parse, Then Validate, Then Operate](details/p076-parse-then-validate-then-operate.md) — Parse
-each external representation one time. Validate all parts of the parsed structure. Let core logic use
-trusted data.
-
-### P077
-
-[Separate Policy from Mechanism](details/p077-separate-policy-from-mechanism.md) — Keep a clear
-boundary that divides policy from mechanism. Policy selects an action. The mechanism does the action.
-
-### P078
-
-[Single Source of Truth](details/p078-single-source-of-truth.md) — Give each authoritative mutable
-state or policy one explicit owner. Do not give authority to replicas that have different values.
-
-### P079
-
-[Explicit Ownership and Lifetimes](details/p079-explicit-ownership-and-lifetimes.md) — Give resources,
-tasks, locks, and temporary state a clear owner and deterministic cleanup or termination.
-
-### P084
-
-[Prefer Local Reasoning](details/p084-prefer-local-reasoning.md) — Give a reader sufficient information about a component
-without access to hidden state or control flow in other components.
-
-### P085
-
-[Explicit Is Better Than Implicit](details/p085-explicit-is-better-than-implicit.md) — Make important
-dependencies, transitions, configuration, conversions, and side effects clear.
-
-### P086
-
-[Readability Counts](details/p086-readability-counts.md) — Use clear names, simple control flow,
-cohesive functions, and clear data structures to make correct behavior and maintenance easier.
-
-### P087
-
-[Comments Explain Why, Code Explains What](details/p087-comments-explain-why-code-explains-what.md) —
-Make mechanics clear in code. Write comments only for rationale, constraints, invariants, and context
-that code cannot show.
+### P021
 
-## Testing and evidence
+[Evolutionary and Reversible Design](details/p021-evolutionary-and-reversible-design.md) — Select
+incremental, migration-safe steps. Each step must let an author make sure that the step is correct,
+use a bounded rollback, or use a bounded roll-forward path.
 
 ### P022
 
@@ -268,47 +227,6 @@ test results are the same.
 is correct for invalid input and failures that can occur in operation. Include dependency failure,
 timeout, cancellation, cleanup, and progress that stops before the end.
 
-### P063
-
-[Requirement-to-Code Traceability](details/p063-requirement-to-code-traceability.md) — For each artifact
-change, give a link to a requirement, acceptance criterion, defect, invariant, or necessary dependency.
-
-### P064
-
-[Requirement-to-Test Traceability](details/p064-requirement-to-test-traceability.md) — Give each
-changed behavior a test that is applicable to its contract and risk.
-
-### P065
-
-[Verify Before Claiming Completion](details/p065-verify-before-claiming-completion.md) — After you
-complete the work, examine the change. Before a completion statement, do the applicable repository
-checks. Give information about all coverage gaps.
-
-### P067
-
-[No Test Cheating](details/p067-no-test-cheating.md) — Do not change an applicable test to hide an
-implementation defect. Do not disable an applicable test to hide an implementation defect.
-
-### P068
-
-[No Validation Bypass](details/p068-no-validation-bypass.md) — If an applicable gate shows a problem,
-correct the problem. When an approved narrow exception applies, record the exception. Without an approved
-exception, do not disable the gate.
-
-### P069
-
-[Independent Review for High-Risk Changes](details/p069-independent-review-for-high-risk-changes.md)
-— Send work with high risk to security or availability to independent review. Reviewer qualifications must
-agree with the risk and applicable policy requirements.
-
-### P091
-
-[Test-Driven Development](details/p091-test-driven-development.md) — For behavior changes, write a
-narrow test that shows the missing behavior. Make the smallest change that gives a correct test result. Then,
-refactor while test results stay correct.
-
-## Error handling
-
 ### P029
 
 [Generalize Error Policy; Preserve Specific Cause](details/p029-generalize-error-policy-preserve-specific-cause.md)
@@ -352,8 +270,6 @@ available, select that state.
 [Graceful Degradation](details/p036-graceful-degradation.md) — When a capability has a noncritical
 failure, continue only in a mode that keeps security and correct operation. Use less functionality in that mode.
 
-## Distributed reliability
-
 ### P037
 
 [Idempotency Before Retry](details/p037-idempotency-before-retry.md) — Use idempotency, keys,
@@ -413,30 +329,6 @@ work can continue safely.
 structured evidence with a correlation identifier. Do not record sensitive data. This evidence lets
 operators find causes of operation outcomes.
 
-### P080
-
-[Make Concurrency Deliberate](details/p080-make-concurrency-deliberate.md) — When measurements show that
-concurrency helps the system, add concurrency. Give explicit definitions for shared state, synchronization,
-failure, and cancellation.
-
-### P081
-
-[Forward Progress With Safety](details/p081-forward-progress-with-safety.md) — Make bounded progress.
-If progress is not possible, stop with a clear recoverable failure. When the result is unknown, do
-not wait without a limit.
-
-### P082
-
-[Design for Cancellation](details/p082-design-for-cancellation.md) — Give rules for cancellation
-propagation and resource release after interruption. Keep state correct.
-
-### P083
-
-[Irreversible Actions Last](details/p083-irreversible-actions-last.md) — Before the known point for an
-irreversible action, complete validation and reversible work.
-
-## Security and supply chain
-
 ### P048
 
 [Secure by Design](details/p048-secure-by-design.md) — Make security controls and new trust boundaries
@@ -488,8 +380,6 @@ exception is correct only for an explicit requirement. Use the applicable protec
 [Supply-Chain Integrity](details/p057-supply-chain-integrity.md) — Keep the dependency count low.
 Examine each dependency. Use trusted sources. Keep locks, provenance, and integrity for build inputs and artifacts.
 
-## Agent authority
-
 ### P058
 
 [Bounded Agent Authority](details/p058-bounded-agent-authority.md) — Give an agent only the scope,
@@ -517,13 +407,44 @@ Give permissions with a clear decision. Output can be untrusted input. Thus, val
 — Get action-bound approval from a person. Approval is necessary when the task and applicable
 contract do not give specified authority.
 
-## Stewardship and judgment
+### P063
+
+[Requirement-to-Code Traceability](details/p063-requirement-to-code-traceability.md) — For each artifact
+change, give a link to a requirement, acceptance criterion, defect, invariant, or necessary dependency.
+
+### P064
+
+[Requirement-to-Test Traceability](details/p064-requirement-to-test-traceability.md) — Give each
+changed behavior a test that is applicable to its contract and risk.
+
+### P065
+
+[Verify Before Claiming Completion](details/p065-verify-before-claiming-completion.md) — After you
+complete the work, examine the change. Before a completion statement, do the applicable repository
+checks. Give information about all coverage gaps.
 
 ### P066
 
 [Preserve Existing Work](details/p066-preserve-existing-work.md) — Do not change existing work that
 is not in the request.
 
+### P067
+
+[No Test Cheating](details/p067-no-test-cheating.md) — Do not change an applicable test to hide an
+implementation defect. Do not disable an applicable test to hide an implementation defect.
+
+### P068
+
+[No Validation Bypass](details/p068-no-validation-bypass.md) — If an applicable gate shows a problem,
+correct the problem. When an approved narrow exception applies, record the exception. Without an approved
+exception, do not disable the gate.
+
+### P069
+
+[Independent Review for High-Risk Changes](details/p069-independent-review-for-high-risk-changes.md)
+— Send work with high risk to security or availability to independent review. Reviewer qualifications must
+agree with the risk and applicable policy requirements.
+
 ### P070
 
 [Code Health Must Not Regress](details/p070-code-health-must-not-regress.md) — A change must not
@@ -540,3 +461,105 @@ evidence shows that a change is necessary, use established repository convention
 [Technical Evidence Over Preference](details/p072-technical-evidence-over-preference.md) — Select an
 alternative with requirements, measurements, tests, specifications, architecture, and established
 principles. Do not use personal preference.
+
+### P073
+
+[Optimize Only With Evidence](details/p073-optimize-only-with-evidence.md) — Measure first. When
+measurements show a constraint or bottleneck, add optimization complexity.
+
+### P074
+
+[Prefer Existing Mechanisms](details/p074-prefer-existing-mechanisms.md) — Before you make a new
+mechanism, select an applicable repository, language, framework, or standard-library mechanism.
+
+### P075
+
+[Make Invalid States Hard to Represent](details/p075-make-invalid-states-hard-to-represent.md) — Use
+types, schemas, construction boundaries, and state machines to prevent invalid combinations.
+
+### P076
+
+[Parse, Then Validate, Then Operate](details/p076-parse-then-validate-then-operate.md) — Parse
+each external representation one time. Validate all parts of the parsed structure. Let core logic use
+trusted data.
+
+### P077
+
+[Separate Policy from Mechanism](details/p077-separate-policy-from-mechanism.md) — Keep a clear
+boundary that divides policy from mechanism. Policy selects an action. The mechanism does the action.
+
+### P078
+
+[Single Source of Truth](details/p078-single-source-of-truth.md) — Give each authoritative mutable
+state or policy one explicit owner. Do not give authority to replicas that have different values.
+
+### P079
+
+[Explicit Ownership and Lifetimes](details/p079-explicit-ownership-and-lifetimes.md) — Give resources,
+tasks, locks, and temporary state a clear owner and deterministic cleanup or termination.
+
+### P080
+
+[Make Concurrency Deliberate](details/p080-make-concurrency-deliberate.md) — When measurements show that
+concurrency helps the system, add concurrency. Give explicit definitions for shared state, synchronization,
+failure, and cancellation.
+
+### P081
+
+[Forward Progress With Safety](details/p081-forward-progress-with-safety.md) — Make bounded progress.
+If progress is not possible, stop with a clear recoverable failure. When the result is unknown, do
+not wait without a limit.
+
+### P082
+
+[Design for Cancellation](details/p082-design-for-cancellation.md) — Give rules for cancellation
+propagation and resource release after interruption. Keep state correct.
+
+### P083
+
+[Irreversible Actions Last](details/p083-irreversible-actions-last.md) — Before the known point for an
+irreversible action, complete validation and reversible work.
+
+### P084
+
+[Prefer Local Reasoning](details/p084-prefer-local-reasoning.md) — Give a reader sufficient information about a component
+without access to hidden state or control flow in other components.
+
+### P085
+
+[Explicit Is Better Than Implicit](details/p085-explicit-is-better-than-implicit.md) — Make important
+dependencies, transitions, configuration, conversions, and side effects clear.
+
+### P086
+
+[Readability Counts](details/p086-readability-counts.md) — Use clear names, simple control flow,
+cohesive functions, and clear data structures to make correct behavior and maintenance easier.
+
+### P087
+
+[Comments Explain Why, Code Explains What](details/p087-comments-explain-why-code-explains-what.md) —
+Make mechanics clear in code. Write comments only for rationale, constraints, invariants, and context
+that code cannot show.
+
+### P088
+
+[Delete Dead Code](details/p088-delete-dead-code.md) — Remove code that no execution path or consumer
+uses. Also remove unreachable, superseded, or obsolete code. First, make sure that deletion is safe.
+
+### P089
+
+[Delete Obsolete Configuration and Dependencies](details/p089-delete-obsolete-configuration-and-dependencies.md)
+— After evidence shows that no consumer uses the artifact, remove the configuration, dependencies,
+tests, documentation, and scaffolding.
+
+### P090
+
+[Prefer Negative Code](details/p090-prefer-negative-code.md) — For equally correct and clear
+solutions, select less code and maintenance. Also select less state, configuration, dependency surface,
+and conceptual complexity.
+
+### P091
+
+[Test-Driven Development](details/p091-test-driven-development.md) — For behavior changes, write a
+narrow test that shows the missing behavior. Make the smallest change that gives a correct test result. Then,
+refactor while test results stay correct.