release: ship v1.10.0 decision records

CHANGELOG.md

@@ -2,6 +2,15 @@
 
 ## [Unreleased]
 
+## [v1.10.0]
+
+- Define Architecture, Program governance, Evidence classification, and Governance decision types with a creation test that leaves ordinary maintenance in its owning guide.
+- Add Governance Decision 0005 for the shared directory and identifier sequence, policy boundary, common record shape, supersession rules, and history-preserving migration.
+- Expand the decision index with examples, counterexamples, maintainer workflow, research rationale, and the boundary between historical rationale and current operational truth.
+- Derive canonical types and index coverage from the maintained guide, then validate discovered record filenames, identifiers, titles, common sections, exact index membership, duplicate numbers, and stale links without hard-coding historical records.
+- Preserve records 0001 through 0004, every published filename and link, the runtime skill, activation and output behavior, safety contract, fixtures, and package formats.
+- Record the primary research sources and the limit that no unnamed private portfolio inventory or unrelated repository was inspected for this implementation.
+
 ## [v1.9.0]
 
 - Replace the generic founding-case landing copy with a concrete account of release knowledge reused from three repositories across two organizations.

README.md

@@ -135,7 +135,7 @@ Each release provides a standalone Agent Skill ZIP, a Codex plugin ZIP, a Claude
 
 Start with [Contributing](CONTRIBUTING.md) for the repository workflow and definition of done.
 
-Use the [Roadmap](docs/ROADMAP.md) for program direction, [Architecture](docs/ARCHITECTURE.md) for durable design, [Governance](docs/GOVERNANCE.md) for decision authority, [Testing](docs/TESTING.md) for evidence, and [Releasing](docs/RELEASING.md) for delivery. Read [Maintenance](docs/MAINTENANCE.md) for health review and [Support](SUPPORT.md) for help routes.
+Use the [Roadmap](docs/ROADMAP.md) for program direction, [Architecture](docs/ARCHITECTURE.md) for durable design, [Governance](docs/GOVERNANCE.md) for decision authority, [Decision Records](docs/decisions/README.md) for durable rationale, [Testing](docs/TESTING.md) for evidence, and [Releasing](docs/RELEASING.md) for delivery. Read [Maintenance](docs/MAINTENANCE.md) for health review and [Support](SUPPORT.md) for help routes.
 
 ### Development
 
@@ -150,6 +150,6 @@ Generated ZIP files are written to `dist/assets/`.
 
 ## Status and License
 
-Current version: `1.9.0`.
+Current version: `1.10.0`.
 
 The repository is maintained by TechSpokes and licensed under [MIT](LICENSE).

docs/ARCHITECTURE.md

@@ -161,4 +161,6 @@ Refresh `agent-capability-adapters.md` when hosts change skill paths, connector
 
 Use the [threat model](THREAT-MODEL.md), [governance contract](GOVERNANCE.md), [maintenance health](MAINTENANCE.md), [decision classification](decisions/README.md), and [Program Decision 0003](decisions/0003-separate-delivery-from-outcome-evidence.md) when a change affects privileged tools, public output, feedback, portal handoff, recommendation independence, contribution quality, roadmap claims, or release identity.
 
+Decision records use one shared directory and identifier sequence with explicit Architecture, Program governance, Evidence classification, and Governance types. Current runtime, policy, evidence, and procedure documents remain the operational sources of truth; [Governance Decision 0005](decisions/0005-use-one-typed-decision-registry.md) records the taxonomy, history-preserving migration, and validation boundary.
+
 Keep project scripts platform-neutral where Node.js provides the needed capability. Validation, checksum generation, and the dependency-free stored ZIP implementation use Node.js standard library APIs and do not depend on host archive commands or shell-specific path behavior.

docs/GOVERNANCE.md

@@ -8,7 +8,7 @@ Protect the skill's portability, safety, evidence discipline, teaching value, fr
 
 The repository maintainers may accept reversible implementation and documentation decisions that preserve the published contracts. Require an accountable human review for activation or safety contract changes, public release, security acceptance, organization access, paid conflicts, major interoperability commitments, and decision supersession.
 
-Classify durable decisions through the [decision record guide](decisions/README.md). Reserve architecture decisions for system structure and runtime boundaries, use program decisions for roadmap or governance rules, use evidence decisions for claim classification, and keep ordinary procedures in their owning guides. Preserve superseded records.
+Classify durable decisions through the [decision record guide](decisions/README.md). Reserve architecture decisions for product structure and runtime contracts, use program decisions for bounded roadmap and delivery coordination, use evidence decisions for evidence acceptance and permitted claims, and use governance decisions for durable authority or repository-wide policy. Keep ordinary procedures in their owning guides and preserve superseded records.
 
 ## Definition of Done
 

docs/PROVENANCE.md

@@ -56,6 +56,14 @@ GitHub's dependency graph defines structural evidence from manifests, lock files
 
 The runtime adopts the smaller design conclusion: preserve only the evidence and uncertainty needed for the current decision. It does not implement the external vocabularies, claim standards conformance, impose a relationship taxonomy, or require a graph.
 
+## Decision Record Sources
+
+Decision-record research for issue #19 was checked on 2026-07-19 against the current repository records, procedure and governance guides, validator, Git history, and related roadmap issues. Public primary sources included [Michael Nygard's original ADR description](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions), [MADR 4.0](https://adr.github.io/madr/), the [UK Government ADR Framework](https://www.gov.uk/government/publications/architectural-decision-record-framework/architectural-decision-record-framework), the [ISO/IEC/IEEE 42010 conceptual model](http://www.iso-architecture.org/42010/cm), [Python PEP 1](https://peps.python.org/pep-0001/), the [Open Decision Framework](https://github.com/open-organization/open-decision-framework/blob/master/ODF-community.md), and the [GRADE Working Group](https://www.gradeworkinggroup.org/).
+
+The sources support a narrow architecture category, short records with explicit status and rationale, preserved supersession history, a shared typed registry, a threshold that excludes ordinary fixes, transparent governance context, and separation of evidence certainty from the resulting decision. [Governance Decision 0005](decisions/0005-use-one-typed-decision-registry.md) applies those precedents to this repository without claiming conformance to an external format.
+
+No exact private portfolio inventory or additional portfolio repository was named as an authorized evidence source for this implementation. Existing public portfolio summaries support concern separation, but the release does not claim that the complete portfolio uses the same taxonomy.
+
 ## Writing Quality Sources
 
 The writing quality decision was reviewed on 2026-07-19 against the repository corpus, issue #15 maintainer feedback, professional edit research, empirical studies of generated prose and model preference, and authoritative technical style guidance. The public source hierarchy and limits are recorded in [Writing Quality](WRITING.md).

docs/TESTING.md

@@ -25,7 +25,7 @@ npm run package -- vX.Y.Z
 npm run release:verify-assets -- vX.Y.Z
 ```
 
-The validator checks metadata, direct links, required maintenance files, versions, manifests, release notes, workflow mode, Markdown structure, runtime path leakage, placeholders, installation-version synchronization, feedback, decisions, writing-corpus structure, and the 500-line core limit. It also runs `scripts/validate-evaluations.mjs`, which requires every activation row and scenario heading to have a stable registry entry and every required segment to retain coverage.
+The validator checks metadata, direct links, required maintenance files, versions, manifests, release notes, workflow mode, Markdown structure, runtime path leakage, placeholders, installation-version synchronization, feedback, decisions, writing-corpus structure, and the 500-line core limit. Decision validation derives canonical types and index coverage from marked blocks in `docs/decisions/README.md`, discovers records dynamically, and checks stable filenames, unique identifiers, matching titles, common sections, exact index membership, and stale links without hard-coding historical record names. The validator also runs `scripts/validate-evaluations.mjs`, which requires every activation row and scenario heading to have a stable registry entry and every required segment to retain coverage.
 
 For a release cut, `npm run release:preflight -- vX.Y.Z` snapshots every tracked and nonignored untracked candidate file, runs the complete final-tree gate, builds the assets twice, requires stable checksums, and verifies that the gate does not change the candidate tree.
 

docs/VERSION.md

@@ -1,6 +1,6 @@
 # Version
 
-Current version: `1.9.0`.
+Current version: `1.10.0`.
 
 ## Source of Truth
 

docs/decisions/0005-use-one-typed-decision-registry.md

@@ -0,0 +1,73 @@
+# Governance Decision 0005: Use One Typed Decision Registry
+
+Decision type: Governance.
+
+## Status
+
+Accepted on 2026-07-19 through [issue #19](https://github.com/TechSpokes/skill-github-repositories-coordination/issues/19) and the v1.10.0 implementation.
+
+## Context
+
+The repository originally numbered roadmap sequencing and evidence acceptance records as architecture decisions even though they did not change system structure. Version 1.2.0 corrected the labels and added a small index, but issue #19 intentionally deferred the full taxonomy, procedure boundary, migration, and validation design.
+
+The current record set shares one directory and four-digit sequence. Published documentation and GitHub history link to those filenames, so reorganizing or renumbering the files would create broken references and obscure why earlier choices were made.
+
+The validator discovers all record files, but its recognized type list is hard-coded and it checks only whether each file declares a type and appears somewhere in the index. It does not verify stable identifiers, title and type agreement, the common record shape, exact index coverage, or stale index entries.
+
+Primary architecture guidance favors short records with status, context, decision, consequences, rationale, stable identifiers, and preserved supersession history. Python's PEP registry demonstrates that different decision types can share one numbered index. Open governance and evidence-to-decision guidance support explicit authority, stakeholder, evidence, limitation, and review information for decisions outside architecture.
+
+## Options
+
+- Keep the minimal three-type guide and hard-coded validator.
+- Keep one directory and sequence, define four explicit types, and make the index the maintained type and discovery registry.
+- Split architecture, program, evidence, and governance records into separate directories and identifier sequences.
+- Rename or renumber the existing files around the new taxonomy.
+- Remove separate records and keep every rationale in its owning guide.
+
+## Decision
+
+Keep one `docs/decisions/` directory and one monotonically increasing four-digit identifier sequence for Architecture, Program governance, Evidence classification, and Governance records. Use Governance as the repository term for durable policy decisions about authority, ownership, approval, security acceptance, contribution, release, recommendation independence, or another repository-wide obligation.
+
+Keep routine testing, release, feedback, maintenance, security, and other operational steps in their owning guides. Create a separate record only when the procedure embodies a durable tradeoff, authority rule, cross-cutting invariant, or recovery constraint whose rationale future maintainers need before changing it.
+
+Require every record to declare a canonical type and matching title identifier. Require Status, Context, Decision, Consequences, Links, and Review Trigger sections. Include options, rationale, decision makers, consulted stakeholders, evidence, confirmation, and supersession information when they affect the decision.
+
+Preserve historical filenames and identifiers. Never reuse a number. Keep superseded records, link both directions, and create a new record for a material replacement while maintaining current operating truth in the owning guide.
+
+Make `docs/decisions/README.md` the maintained type registry, creation guide, migration note, and record index. Validation derives allowed types and index coverage from marked blocks in that guide, discovers record files dynamically, and rejects malformed identifiers, mismatched headings, missing common sections, duplicate identifiers, missing index entries, duplicate index entries, and stale index links.
+
+## Rationale
+
+One typed registry preserves every existing URL and keeps the collection easy to scan at its current scale. Explicit types prevent architecture from becoming a generic label while allowing all records to reuse one small format and sequence.
+
+The creation test keeps ordinary maintenance in the document that owns current behavior. Dynamic validation protects the system's shape without making today's five records permanent dependencies of future releases.
+
+## Consequences
+
+Maintainers receive a concrete test, examples, counterexamples, format, status model, supersession rule, migration plan, and creation workflow in one discovery surface. Governance decisions become a supported record type rather than an unused validator value.
+
+The validator becomes stricter, so a new record must follow the naming, heading, section, and index contracts. It still does not judge whether the decision was wise, whether a body of evidence is true, or whether human approval exists.
+
+All existing records remain valid without renaming or content migration. Separate type directories remain available as a later change if scale, ownership, access, or lifecycle evidence justifies the additional structure.
+
+The research did not inspect an unnamed private portfolio inventory or unrelated repositories. The selected taxonomy is justified for this repository and does not claim portfolio-wide adoption.
+
+## Links
+
+- [Decision record guide](README.md)
+- [Issue #19](https://github.com/TechSpokes/skill-github-repositories-coordination/issues/19)
+- [Architecture](../ARCHITECTURE.md)
+- [Governance](../GOVERNANCE.md)
+- [Testing](../TESTING.md)
+- [Releasing](../RELEASING.md)
+- [Program Evidence](../PROGRAM-EVIDENCE.md)
+- [Michael Nygard's ADR description](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)
+- [MADR 4.0](https://adr.github.io/madr/)
+- [UK Government ADR Framework](https://www.gov.uk/government/publications/architectural-decision-record-framework/architectural-decision-record-framework)
+- [Python PEP 1](https://peps.python.org/pep-0001/)
+- [Open Decision Framework](https://github.com/open-organization/open-decision-framework/blob/master/ODF-community.md)
+- [GRADE Working Group](https://www.gradeworkinggroup.org/)
+
+## Review Triggers
+
+Review this decision when the record index becomes difficult to maintain, one type develops a distinct owner or access boundary, records need different lifecycles, routine changes create excessive record ceremony, validation blocks valid historical forms, a stable redirect mechanism makes reorganization beneficial, or observed maintenance contradicts the four-type boundary.