@homericintelligence/athena-opencode 0.5.0 → 0.5.2

package/skills/_support/docs/review/issue-planning.md

@@ -0,0 +1,247 @@
+# Issue planning and issue review
+
+**Why:** Use one current plan that the authenticated actor owns. This prevents a stale, foreign, or
+ambiguous issue comment from controlling implementation. The issue remains the requirements source.
+A plan proposes work. It does not authorize implementation, merge, or another forge change.
+
+Use the [ASD-STE100 technical-English policy](../../../TECHNICAL_ENGLISH.md) for all technical prose and review
+output.
+
+## Principle routing
+
+For plan scope and architecture, apply [P001](../principles/README.md#p001),
+[P002](../principles/README.md#p002), [P008](../principles/README.md#p008),
+[P010](../principles/README.md#p010), [P012](../principles/README.md#p012),
+[P015](../principles/README.md#p015), [P063](../principles/README.md#p063),
+[P064](../principles/README.md#p064), and [P074](../principles/README.md#p074).
+
+For artifact identity, publication, and cleanup, apply [P019](../principles/README.md#p019),
+[P033](../principles/README.md#p033), [P044](../principles/README.md#p044),
+[P059](../principles/README.md#p059), [P061](../principles/README.md#p061),
+[P062](../principles/README.md#p062), [P065](../principles/README.md#p065),
+[P066](../principles/README.md#p066), and [P083](../principles/README.md#p083).
+
+For plan review, also apply [P069](../principles/README.md#p069),
+[P071](../principles/README.md#p071), and
+[P072](../principles/README.md#p072) for proportionate independence and evidence-based disposition.
+
+## At a glance
+
+| Artifact | Owner and purpose | Write boundary |
+| --- | --- | --- |
+| Canonical plan | One authenticated actor-owned `<!-- HomericIntelligence:plan-issue -->` comment. | When requested, `plan-issue` can create or update it. |
+| Plan review | One authenticated actor-owned `<!-- HomericIntelligence:issue-review -->` comment. | When requested without `--report-only`, `issue-review` can publish it. |
+| Finalized epoch | One sealed `R`, `P`, and `V` identity in the issue body. | `finalize-plan` can replace that body once. After exact readback, it can remove its two sealed comments. |
+| Missing or ambiguous plan | A coverage gap or identity conflict, never a favorable plan. | Withhold the write and return the prepared artifact. |
+
+## Canonical plan identity
+
+Before you plan, review, or publish, use this sequence:
+
+1. Enumerate each current issue comment.
+2. Apply the semantic-marker rule to the plan and review markers.
+3. Apply this rule before a decision about count, ownership, absence, digest, drift, creation, update,
+   or publication.
+4. Accept the plan marker only if it occurs exactly once in one comment that the authenticated actor
+   wrote.
+
+If a marker is foreign, repeated, or has an unverifiable author, treat it as an ownership conflict.
+In an ownership conflict:
+
+- Do not create a second marker.
+- Do not adopt or overwrite foreign content.
+- Do not publish from ambiguous content.
+- Preserve issue bodies and comments from other authors.
+- Request human direction.
+
+### Shared marker migration
+
+New planning artifacts use the `HomericIntelligence` markers in the table above. During migration,
+resolve one existing actor-owned artifact through exactly one marker from its role's alias set:
+
+| Role | Current marker | Read-only legacy aliases |
+| --- | --- | --- |
+| Plan | `<!-- HomericIntelligence:plan-issue -->` | `<!-- hephaestus-plan:canonical -->`, `<!-- athena:plan-issue -->` |
+| Review | `<!-- HomericIntelligence:issue-review -->` | `<!-- hephaestus-plan-review:canonical -->`, `<!-- athena:issue-review -->` |
+
+Count all aliases for one role together. More than one qualifying alias in one comment or across
+comments is an identity conflict, even when the aliases differ. An unambiguous actor-owned legacy
+artifact can be updated in place, but its replacement must use only the current marker. Do not
+publish a legacy marker. Do not put current and legacy aliases in the same comment.
+
+A comment with a qualifying plan marker and a qualifying review marker is an identity conflict. Do
+not select, update, delete, or finalize that comment.
+
+### Semantic-marker rule
+
+Treat a marker as an artifact identity only when its exact Hypertext Markup Language (HTML) comment
+is the complete top-level Markdown line in a comment. Use
+`<!-- HomericIntelligence:plan-issue -->` for a plan. Use
+`<!-- HomericIntelligence:issue-review -->` for a review. The marker can occur after a heading, prose,
+or blank line when it remains a complete top-level Markdown line. Accept a line feed (LF) or carriage
+return and line feed (CRLF) line ending. Do not trim, normalize, or move surrounding prose or Markdown
+syntax to create a match. Do not treat marker text as an artifact when it occurs in one of these
+locations:
+
+- prose;
+- inline code;
+- a blockquote;
+- a list item;
+- fenced code; or
+- indented code.
+
+Treat two qualifying lines in one comment as a repeated-marker conflict. Treat qualifying lines in
+different comments as a multiple-comment conflict. Apply this rule each time you resolve or publish
+an artifact identity. Do not let an ignored text reference change absence, ownership, content digest,
+or a pre-write drift comparison.
+
+If the marker is absent, `plan-issue` can create one after its scope and identity checks. If
+`issue-review` verifies that the marker is absent, record a coverage gap. Do not invent a plan. Do not
+treat a foreign or multiple marker as an absent marker.
+
+For a valid plan, record these items:
+
+- the resolved issue identifier (ID) or uniform resource locator (URL);
+- the digest of the title, body, and acceptance criteria;
+- the authenticated actor;
+- the plan-comment ID or URL; and
+- the plan-content digest.
+
+For an absent plan, record the issue identity and requirements digest. Also record the verified
+`plan: absent` value. Immediately before an update or review publication, resolve the applicable
+identity again. Compare each field, including absence. Use the failure actions below if one of these
+conditions occurs:
+
+- The requirements or plan content changed.
+- The marker became foreign or multiple.
+- You cannot verify the identity.
+
+Failure actions:
+
+1. Stop the write.
+2. Return the prepared draft or review.
+
+## Plan content
+
+Use this content in a canonical plan:
+
+1. Record architecture alignment and relevant guidance or ADRs.
+2. Map each acceptance criterion to a step.
+3. Record concrete module, file, interface, and ownership changes.
+4. Specify behavior-first tests and runnable validation commands.
+5. Record applicable error, boundary, security, migration, rollout, and rollback considerations.
+6. Record unresolved decisions, assumptions, and dependencies.
+
+Run `advise` before you draft the plan. In planning mode, `advise` can use the existing checkout as
+best-effort evidence without upstream synchronization. Report its revision, trust limits, and freshness
+limits. If it returns no guidance, report that explicit result. Continue the planning work. Include
+only current requirements. Do not add speculative features, unrelated refactors, or generic framework
+layers without a demonstrated consumer. If the plan adds a new module, abstraction, public interface,
+dependency, configuration path, or state owner, identify its consumer. Explain why reuse, deletion,
+consolidation, or a direct local change is not the simpler complete option.
+
+## Issue review
+
+Review the current canonical plan against the current issue. Use earlier plans and reviews only as
+bounded context. Do not use them as a replacement for the current identity. First, report architecture
+alignment. Then, verify that each acceptance criterion has all these items:
+
+- a concrete and safe implementation step;
+- an architecture boundary; and
+- behavior-first validation.
+
+Identify missing requirements, unsafe work, work outside the scope, incorrect paths or boundaries,
+unverified assumptions, nondeterministic tests, and unresolved dependencies.
+
+Publish exactly one actor-owned structured review comment only if all these conditions are true:
+
+- The user requested publication.
+- The invocation does not use `--report-only`.
+- The pre-publication identity comparison succeeded.
+- A safe forge capability is available.
+
+Publish the comment also when no actionable finding remains. Record these items in the comment:
+
+- the reviewed plan identity or verified absence;
+- the architecture decision;
+- requirement coverage;
+- findings;
+- not-applicable (N/A) sections;
+- coverage gaps;
+- a concise status; and
+- unresolved assumptions.
+
+Treat the review as evidence only. Forge labels, approvals, and human policy remain authoritative. If
+the identity is stale or a safe capability is not available:
+
+1. Do not publish.
+2. Return the prepared result.
+
+## Bounded revision loop
+
+If a plan changes, review the new canonical plan. Do not collect the complete historical transcript.
+Keep only the prior findings and unresolved decisions that you need to verify the new plan. Treat a
+missing or malformed plan as a coverage gap. Do not treat it as favorable evidence. Treat a foreign,
+multiple, or unverifiable marker as an identity conflict. Do not treat it as a coverage gap.
+
+## Finalized planning epochs
+
+After one reviewed planning epoch, use `finalize-plan` as the bounded terminal materialization step. It
+does not plan, review, implement, change labels, or change the issue workflow state. The issue
+requirements remain the source of intent. The actor-owned canonical plan supplies architecture and
+implementation detail. The actor-owned review supplies the exact disposition and residual risk.
+
+Accept exactly one current plan and one current review. The authenticated actor must own both
+artifacts. The plan and review must be different comments. `P` and `V` must identify different
+comment IDs. Bind both artifacts to the same issue-requirements identity. Require an exact `GO`.
+Reject an unresolved `critical`, `major`, or other `required` finding.
+
+Before you draft the finalized body, record these values:
+
+- `R`: the canonical digest of the issue ID, title, original body, and acceptance criteria;
+- `P`: the plan-comment ID and canonical plan-content digest; and
+- `V`: the review-comment ID and review-content digest.
+
+The review must embed and exactly agree with the issue, `R`, plan-comment ID, and `P`. Reject an input
+that is missing, foreign, repeated, malformed, stale, mismatched, unverified, conditional, or
+`NO-GO`. Fail closed. Do not create or adopt replacement comments.
+
+Use this order in the finalized issue body:
+
+1. Explain why the work is necessary.
+2. Give the original requirements.
+3. If it is useful, give one compact system diagram.
+4. Give the architecture and implementation information.
+5. Give operations information about validation, rollout, rollback, dependencies, residual risks, and
+   decisions outside the scope.
+6. Give the provenance.
+
+Preserve the requirements and accepted plan details. Do not create new scope. Do not make a review
+suggestion a requirement. After verified publication and cleanup, keep the sealed provenance in the
+finalized body.
+
+After verified publication, treat the plan and review comments as intermediate artifacts. Remove them
+only with the deletion procedure below.
+
+Put exactly one machine-readable marker in the body:
+`<!-- HomericIntelligence:finalize-plan R=<R> P=<P> V=<V> F=<F> -->`. Compute `F` from a
+canonical body representation. In that representation, use the literal `<F>` placeholder as the
+marker's `F` value. This prevents self-reference. Immediately before publication, resolve each source
+identity, actor, marker, and `GO` binding again. Update the issue body exactly once. Then, read the body
+again and verify its exact content. Only after successful readback, re-read the exact actor-owned plan
+and review comments recorded in `P` and `V`. Verify each comment's ID, actor, marker, and digest. Only
+then, delete those comments. If a value changes, do not delete the comment. If a timeout, indeterminate
+response, or body readback mismatch occurs, treat the outcome as unknown. Do not retry. If a deletion
+result is uncertain, leave the finalized body in place. Report partial cleanup. Do not retry or
+compensate.
+
+For read-only migration, an exact legacy
+`<!-- athena:finalize-plan R=<R> P=<P> V=<V> F=<F> -->` marker identifies an existing sealed epoch.
+New finalizations write only the `HomericIntelligence` marker. Do not write both marker versions in one
+body.
+
+If an intact marker has a valid `F`, valid source identities, and no sealed comments, treat a second
+finalization as idempotent. Report no-change. Do not duplicate the content. If a sealed comment remains,
+report partial cleanup. Do not delete it again. If a person later makes a material edit, invalidate
+that epoch. Start a new requirements state. Complete `plan-issue` and `issue-review` again. Do not let
+`plan-issue` or `issue-review` treat generated plan text or sealed provenance as a new requirement.

package/skills/_support/docs/review/language-routing.md

@@ -0,0 +1,141 @@
+# Language and toolchain routing
+
+**Why:** An architecture-first review also needs language-specific evidence. Use language routing so
+that a generic checklist does not replace the conventions, failure modes, and tools of the changed
+code.
+
+Use the [ASD-STE100 technical-English policy](../../../TECHNICAL_ENGLISH.md) for all technical prose and review
+output.
+
+Follow repository guidance and repository-selected tools first. These instructions override the
+defaults in this document. If the repository has no local rule, use the current primary language or
+framework documentation. If that documentation is not available, use repository evidence. Report the
+documentation coverage gap. If the executable language is unknown, report a coverage gap. Do not
+report a generic-checklist pass.
+
+## Select a profile
+
+After the shared architecture gate and surface classification, apply every relevant deep or routed
+profile. If a language is intentionally excluded, do not create a generic language overlay. Apply the
+shared architecture, surface, security, and behavior review.
+
+## Deep profiles
+
+### Python
+
+Review these items:
+
+- public type and data contracts;
+- exception boundaries;
+- resource lifetime;
+- asynchronous operations or concurrency;
+- import and packaging effects; and
+- test isolation.
+
+Use repository-selected formatters, linters, type checkers, and test tools. Use runtime validation at
+untyped boundaries. Use mocks only at genuine external boundaries. If local rules do not define a
+stricter public-type contract, use the current
+[Python typing documentation](https://docs.python.org/3/library/typing.html).
+
+### C++
+
+Review these items:
+
+- interfaces and application binary interface (ABI) effects;
+- ownership and lifetime;
+- resource acquisition is initialization (RAII);
+- error conventions;
+- constness;
+- value and reference semantics;
+- concurrency and data races;
+- exception safety; and
+- measured performance claims.
+
+Use configured warnings, formatters, static analysis, sanitizers, and test targets. Accept a C++ test
+as evidence only when a real build target includes it. If local guidance does not supersede them, use
+the [C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines).
+
+### Go
+
+Review these items:
+
+- package and application programming interface (API) design;
+- `context.Context` propagation and cancellation;
+- goroutine lifetime;
+- error wrapping and error handling;
+- zero-value behavior;
+- data-race risks; and
+- public documentation.
+
+Use `gofmt`, configured static analysis, race tests, and package tests when they apply. Accept a
+filtered `go test -run` command as evidence only after you verify that it selects at least one test.
+If local guidance does not supersede it, use
+[Go Code Review Comments](https://go.dev/wiki/CodeReviewComments).
+
+### Mojo
+
+Review these items:
+
+- ownership;
+- lifetime;
+- argument conventions;
+- resource destructors;
+- error contracts; and
+- `fn` and `def` semantics.
+
+For accelerator code, inspect central processing unit (CPU) and graphics processing unit (GPU)
+boundaries. Also inspect data movement, launch assumptions, and performance evidence. For Python
+interoperability, review both sides of the boundary. Review the runtime type and ownership contracts.
+Use repository tooling and current official Modular guidance. Give special attention to
+[modular/skills](https://github.com/modular/skills): `mojo-syntax`, `mojo-gpu-fundamentals`, and
+`mojo-python-interop`. Use native Mojo tests when they are available.
+
+## Routed profiles
+
+| Surface | Review focus |
+| --- | --- |
+| C, CUDA (`Cuda` in GitHub Linguist), HIP | Ownership, bounds, undefined behavior, host/device boundary, synchronization, portability, compiler and sanitizer evidence, and measured performance claims. |
+| Batchfile | Quoting and delayed expansion, `%ERRORLEVEL%` propagation, `%` escaping, path-with-space handling, filesystem-destructive command scope, `cmd.exe` portability, and change-discard boundaries. |
+| COBOL | Record and copybook contracts, fixed or free source format, numeric precision and rounding, file/status handling, batch and transaction boundaries, compiler dialect, and mainframe job or deployment wiring. |
+| MLIR | Dialect interfaces and verifier invariants, SSA/value ownership, operation and attribute semantics, conversion legality, pass-pipeline ordering, generated artifacts, and end-to-end compiler-test coverage. |
+| Procfile | Process type ownership, executable command and argument boundaries, configuration and secrets, port binding, signal handling and graceful shutdown, worker/web concurrency, and platform deployment evidence. |
+| RenderScript | Allocation and kernel data contracts, host/device synchronization, bounds and numeric behavior, lifecycle and resource release, API deprecation or compatibility constraints, and device-level functional evidence. |
+| Rust | Ownership and borrowing, `Result` and error propagation, unsafe boundaries, trait/API contracts, concurrency, feature flags, and configured `cargo` checks. |
+| TypeScript, JavaScript | Runtime validation at untyped boundaries, strictness and nullability, promise/error paths, browser/server boundaries, dependency and bundling effects, and configured tests/lint. |
+| Java, C#, Swift | Public API and nullability contracts, ownership or resource lifetime, concurrency, error semantics, framework lifecycle, package/build configuration, and configured analyzers. |
+| Ruby, Lua, Julia, R, Scheme | Dynamic boundary validation, error and resource behavior, numerical or reproducibility assumptions where relevant, package/runtime isolation, and repository test tooling. |
+| Shell | Quoting, word splitting, globbing, exit-status propagation, temporary-file safety, command injection, filesystem-destructive scope, portability, and change-discard boundaries. |
+| CMake, Makefile, Just | Target graph, dependency ordering, reproducibility, quoted paths, generated artifacts, and whether validation commands invoke the intended target. |
+| Dockerfile | Pinned bases, least privilege, build context, secrets, layers, entrypoint behavior, exposed ports, and reproducible build/run evidence. |
+| Jinja, Go Template, templ, HTML | Escaping and injection boundaries, template data contracts, rendering or accessibility behavior where applicable, generated-output ownership, and executable example or render checks. |
+| Vim Script | Script-local versus global state, quoting and escaping, mappings and autocommands, command injection, option restoration, editor-version compatibility, and repeatable headless editor tests when available. |
+
+## Intentionally excluded dedicated profiles
+
+Treat these languages as intentionally not applicable (N/A) for a dedicated language profile. Do not
+treat them as unknown-language coverage gaps:
+
+- Cython;
+- PowerShell;
+- SQL, PLpgSQL, and PLSQL;
+- HCL;
+- Nix;
+- Starlark;
+- Jsonnet;
+- CSS;
+- SCSS;
+- MDX;
+- Liquid;
+- XSLT;
+- Jupyter Notebook;
+- TeX;
+- BibTeX, including BibTeX Style;
+- Roff;
+- ANTLR;
+- Tree-sitter Query;
+- Rocq, including Rocq Prover;
+- Red; and
+- POV-Ray SDL.
+
+Apply the shared architecture, surface, security, and behavior review when the artifact requires it.
+Do not create a generic or dedicated overlay without a demonstrated product need.

package/skills/_support/docs/review/repository-scorecard.md

@@ -0,0 +1,170 @@
+# Repository review scorecard
+
+**Why:** A repository review needs a complete, architecture-first inventory so a strong area cannot hide
+an unsafe boundary or an unreviewed surface.
+
+Use the [ASD-STE100 technical-English policy](../../../TECHNICAL_ENGLISH.md) for all technical prose and review
+output.
+
+Use these prerequisites before you calculate the score:
+
+1. Apply the [shared review contract](common.md).
+2. Complete the architecture pre-score gate.
+3. Treat a material architecture violation as a blocker.
+4. Follow repository guidance and applicable language routing before generic criteria.
+5. Review every in-scope file.
+6. Include every scorecard section, even when the input is a diff.
+7. Mark a section not applicable (N/A) only when a repository-surface reason supports that result.
+8. Retain the inventory evidence for each N/A result.
+9. Exclude an N/A weight from the applicable-weight denominator.
+10. Keep a coverage-gap weight in the denominator.
+11. Give a coverage gap no unsupported credit.
+12. Calculate the score with the shared applicable-weight formula.
+
+Use the linked application profiles in the shared contract for each section. Apply only the catalog
+entries that the repository surface activates. If an omitted entry could cause a material coverage
+gap, record why that entry is not applicable.
+
+The abbreviation `CI/CD` means continuous integration and continuous delivery. The abbreviation
+`API/CLI` means application programming interface and command-line interface.
+
+1. **Structure:**
+
+   - Inspect boundaries, layering, separation of source, tests, documents, and configuration, naming,
+     nesting, discoverability, generated content, and duplication.
+   - Apply the [architecture and simplicity profile](common.md#architecture-and-simplicity).
+
+2. **Documentation:**
+
+   - Inspect purpose, prerequisites, installation, use, updates, removal, examples, architecture,
+     contributing, security, release, rollback, links, ownership, and consistency between code and
+     documents.
+   - Apply the [architecture and simplicity](common.md#architecture-and-simplicity),
+     [errors and reliability](common.md#errors-and-reliability),
+     [security, authority, and external writes](common.md#security-authority-and-external-writes), and
+     [execution and integrity](common.md#execution-and-integrity) profiles.
+
+3. **Architecture:**
+
+   - Inspect dependency direction, interfaces, configuration, error strategy, state ownership,
+     extensibility, architecture decision record (ADR) coverage, KISS, SOLID, modularity, and failure
+     boundaries.
+   - Treat a material unexplained violation as a blocking finding before you calculate the score.
+   - Apply the [architecture and simplicity](common.md#architecture-and-simplicity) and
+     [errors and reliability](common.md#errors-and-reliability) profiles.
+
+4. **Source quality:**
+
+   - Inspect readability, cohesion, typing, errors, logging, dead code, magic values, concurrency,
+     performance hotspots, complexity, lint and format scope, DRY, and applicable language idioms.
+   - Apply the [architecture and simplicity](common.md#architecture-and-simplicity),
+     [errors and reliability](common.md#errors-and-reliability), and
+     [execution and integrity](common.md#execution-and-integrity) profiles.
+
+5. **Testing:**
+
+   - Inspect observable unit, integration, and end-to-end behavior. Also inspect error paths, boundary
+     paths, isolation, concurrency, test-target wiring, regression proof, and proportionate performance
+     and load evidence.
+   - Apply [behavior-first testing](behavior-first-testing.md).
+   - Reject tests of prose, counts, implementation layout, or unstable ambient conditions.
+   - Apply the [testing and evidence](common.md#testing-and-evidence) and
+     [errors and reliability](common.md#errors-and-reliability) profiles.
+
+6. **CI/CD:**
+
+   - Inspect required pull request and main-branch gates, reproducible builds,
+     installation, test, security, and package stages, immutable actions, permissions, caching, artifacts,
+     environments, promotion, deployment strategy, release provenance, tested rollback, and live
+     ruleset enforcement.
+   - Apply the [testing and evidence](common.md#testing-and-evidence),
+     [errors and reliability](common.md#errors-and-reliability),
+     [security, authority, and external writes](common.md#security-authority-and-external-writes), and
+     [execution and integrity](common.md#execution-and-integrity) profiles.
+
+7. **Dependencies:**
+
+   - Inspect correct identities, bounded versions, lock integrity, separation of development and runtime,
+     licenses, vulnerability analysis, software bill of materials (SBOM), update automation, and
+     unused-dependency removal.
+   - Apply the [architecture and simplicity](common.md#architecture-and-simplicity),
+     [security, authority, and external writes](common.md#security-authority-and-external-writes), and
+     [execution and integrity](common.md#execution-and-integrity) profiles.
+
+8. **Security:**
+
+   - Inspect secrets and personally identifiable information (PII), validation,
+     injection and deserialization, authentication and authorization, transport layer security (TLS),
+     encryption, rate limits, audit logging, least privilege, containers, and the supply chain.
+   - Apply the [errors and reliability](common.md#errors-and-reliability),
+     [security, authority, and external writes](common.md#security-authority-and-external-writes), and
+     [execution and integrity](common.md#execution-and-integrity) profiles.
+
+9. **Reliability:**
+
+   - Inspect fail-closed behavior, partial failure, retries, timeouts, idempotency, health checks,
+     readiness checks, graceful shutdown, backup and restore, disaster recovery, failure injection,
+     rollback, resource bounds, observability, service level objectives (SLOs), and error budgets when
+     they apply.
+   - Apply the [testing and evidence](common.md#testing-and-evidence),
+     [errors and reliability](common.md#errors-and-reliability), and
+     [execution and integrity](common.md#execution-and-integrity) profiles.
+
+10. **Planning:**
+
+    - Inspect issue and pull request templates, roadmap, priorities, definition of done, review rules,
+      branch and release process, ownership, debt tracking, and evidence of maintained plans.
+    - Apply the [execution and integrity profile](common.md#execution-and-integrity) and the applicable
+      [architecture and simplicity](common.md#architecture-and-simplicity) entries.
+
+11. **Agent tooling:**
+
+    - Inspect AGENTS and host pointers, skills, model context protocol (MCP) tools, hooks, configuration,
+      prompt templates, portability, permission and external-write boundaries, human gates,
+      context and memory, and fallbacks.
+    - Apply the [architecture and simplicity](common.md#architecture-and-simplicity),
+      [errors and reliability](common.md#errors-and-reliability),
+      [security, authority, and external writes](common.md#security-authority-and-external-writes), and
+      [execution and integrity](common.md#execution-and-integrity) profiles.
+
+12. **Packaging:**
+
+    - Inspect the artifact allowlist, deterministic output, installation, upgrade, removal, versioning,
+      signatures, checksums, release automation, artifact tests, and applicable compatibility.
+    - Apply the [architecture and simplicity](common.md#architecture-and-simplicity),
+      [testing and evidence](common.md#testing-and-evidence),
+      [errors and reliability](common.md#errors-and-reliability),
+      [security, authority, and external writes](common.md#security-authority-and-external-writes), and
+      [execution and integrity](common.md#execution-and-integrity) profiles.
+
+13. **Developer experience:**
+
+    - Inspect one-command bootstrap, one-command checks, locked tools, the task runner, fast feedback,
+      editor support, debug support, hot-reload support, scaffolding, local and CI parity, and actionable
+      failures.
+    - Apply the [architecture and simplicity](common.md#architecture-and-simplicity),
+      [errors and reliability](common.md#errors-and-reliability), and
+      [execution and integrity](common.md#execution-and-integrity) profiles.
+
+14. **API/CLI:**
+
+    - Inspect naming, schemas, validation, error contracts, versioning, authentication, idempotency,
+      pagination, protocol semantics, examples, and discoverability.
+    - Apply the [architecture and simplicity](common.md#architecture-and-simplicity),
+      [errors and reliability](common.md#errors-and-reliability), and
+      [security, authority, and external writes](common.md#security-authority-and-external-writes)
+      profiles.
+
+15. **Governance:**
+
+    - Inspect license, attribution, conduct, security disclosure, ownership, audit trail,
+      accessibility, internationalization, privacy, retention, and third-party service level agreement
+      (SLA) obligations.
+    - Apply the [architecture and simplicity](common.md#architecture-and-simplicity),
+      [errors and reliability](common.md#errors-and-reliability),
+      [security, authority, and external writes](common.md#security-authority-and-external-writes), and
+      [execution and integrity](common.md#execution-and-integrity) profiles.
+
+For each section, record the inventory evidence, commands that you ran, earned points, findings, N/A
+reasons, and coverage gaps. If a failed or sampled section is available, run it again. Do not mark it
+complete before that run.