Clarify release toolchains and Go compatibility requirements

AGENTS.md

@@ -0,0 +1,8 @@
+For work on this repository, start with [docs/development.md](docs/development.md)
+and use its policy reading guide to select the policies applicable to the task.
+Do not read the entire suite by default. Read and follow the
+[agent policy](docs/policy/agents.md) before recommending, planning, or implementing
+changes.
+
+For adopting these policies into another repository, follow
+[docs/adoption.md](docs/adoption.md).

COPYRIGHT

@@ -0,0 +1,24 @@
+Standard Repository Policies
+
+Copyright (C) 2026 Eric Rakestraw
+
+SPDX-License-Identifier: CC-BY-SA-4.0
+
+Except for the materials identified below, the original policy documents and
+explanatory documentation in this repository are licensed under the Creative
+Commons Attribution-ShareAlike 4.0 International Public License. You may share
+and adapt them under that license, whose complete text is provided in LICENSE.
+
+Original format examples under examples/licensing/ are dedicated to the public
+domain under CC0 1.0 Universal, to the extent copyright or related rights apply
+and are held by Eric Rakestraw. Their SPDX identifier is CC0-1.0. The complete
+CC0 text is provided in docs/oss/licenses/CC0-1.0.txt. Reusing this original
+formatting requires no attribution to this project.
+
+Reproduced license texts, third-party notices, and other upstream material
+retain their respective terms. Neither the CC-BY-SA grant nor the CC0 dedication
+relicenses those materials.
+
+These materials are provided as-is, without warranties, to the extent permitted
+by law. See the applicable license or dedication for its disclaimer of warranties
+and limitation of liability.

README.md

@@ -1,3 +1,40 @@
-# policy
+# Standard Repository Policies
 
-A collection of standard repository policy documents that should be applied across each of my personal projects.
+Reusable policies for application and library repositories, written for human
+maintainers and coding agents. They emphasize proportionate implementation,
+classical behavioral testing, clear documentation ownership, simple releases,
+and consistent licensing notices. The policies are language-independent, with
+Go-specific testing guidance where useful.
+
+## Adopt The Policies
+
+Start with the [adoption and update guide](docs/adoption.md). Select an upstream
+commit, copy the policies that apply, customize them locally, and add the supplied
+attribution entry. Downstream repositories own their adopted rules; upstream
+updates are incorporated deliberately.
+
+| Policy | Purpose |
+| --- | --- |
+| [Policy set provenance](docs/policy/meta.md) | Local policy authority and upstream adoption and update navigation. |
+| [Agents](docs/policy/agents.md) | Implementation discipline and local commit practices. |
+| [Testing](docs/policy/testing.md) | Meaningful behavioral coverage with proportionate maintenance cost. |
+| [Architecture](docs/policy/architecture.md) | A framework for application-specific boundaries and constraints. |
+| [Documentation](docs/policy/documentation.md) | Canonical ownership and document lifecycle. |
+| [Releases](docs/policy/release.md) | Minimal justified gates and a clear publication completion point. |
+| [Open source licensing and attribution](docs/policy/oss.md) | Project grants and factual upstream notices. |
+
+Use the upstream [licensing examples](examples/licensing/) to create actual
+project notices, and copy applicable texts from the
+[license collection](docs/oss/licenses/README.md) locally.
+
+## Work On This Project
+
+Read the [contributor guide](docs/development.md) before editing templates or
+reference assets. The [public repository](https://gitea.maximumdirect.net/eric/policy)
+is the upstream source; commit-specific links identify adoption baselines.
+
+Standard Repository Policies is licensed under [CC-BY-SA 4.0](COPYRIGHT), with
+original format examples dedicated under CC0 as specified there.
+
+Sources and terms for reproduced license texts are documented in the
+[reference collection](docs/oss/licenses/README.md).

agents/AGENTS.md

@@ -1,4 +1,6 @@
-Please review `docs/development.md` for initial orientation in this repository
+Start with `docs/development.md` for orientation and use its policy reading guide
-and follow its task-specific reading guide.
+to select the policies applicable to the task. Do not read the entire suite by
+default.
 
-Review and follow `docs/policy/agents.md` before recommending, planning, or implementing any changes to this repository.
+Read and follow `docs/policy/agents.md` before recommending, planning, or
+implementing repository changes.

docs/adoption.md

@@ -0,0 +1,181 @@
+# Adopting And Updating The Policies
+
+This guide is for agents and maintainers incorporating policies from
+[Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy)
+into another repository. This guide lives in the upstream repository; downstream
+projects link to it from their adopted `docs/policy/meta.md`. To edit the upstream
+templates themselves, use the [contributor guide](development.md).
+
+## Downstream Files And Upstream References
+
+| Material | Downstream treatment |
+| --- | --- |
+| Applicable `docs/policy/*.md`, including `meta.md` | Copy and customize, retaining each document's upstream provenance. |
+| `agents/AGENTS.md` | Adapt into the downstream root `AGENTS.md`. |
+| Downstream `docs/development.md` | Create or update for that project using the reading guidance below. |
+| This repository's README, root AGENTS.md, developer guide, and adoption guide | Keep upstream and consult through links as needed. |
+| Licensing examples | Reference upstream and use them to create actual project notices. |
+| Applicable standard license texts | Copy locally as specified below and in the OSS policy. |
+
+## Select A Baseline
+
+Select an upstream commit and read the policies relevant to the requested work.
+Use a revision containing the [project grant](../COPYRIGHT) and the reference
+assets you intend to use. Record its full commit identifier as the adoption
+baseline. Git records are sufficient to maintain adoption provenance.
+
+Preserve existing downstream decisions and unrelated changes. Customize selected
+policies to existing project responsibilities and the author's requested scope.
+
+## Copy And Customize
+
+1. Copy `docs/policy/meta.md` and the applicable policy documents to the same
+   downstream locations.
+   Follow each template's adoption instructions and remove its `Base Policy
+   Template` section afterward. Create supporting documents when they have useful
+   content for an existing responsibility.
+2. Tailor architecture to the actual project. Preserve the author's selected
+   license and existing application contracts.
+3. Retain each document's `Base Policy Version` and set `Last Updated` to the
+   local adoption date. Add `Upstream Source` metadata linking to that specific
+   document at the selected commit. Retain this provenance in future edits.
+4. Create or update the downstream `docs/development.md` reading guide, including
+   the [policy reading guide](#set-up-selective-policy-reading) below, which routes
+   adoption and update tasks to `policy/meta.md`.
+   Use [agents/AGENTS.md](../agents/AGENTS.md) as the basis for the downstream root
+   `AGENTS.md`, merging its orientation links with existing instructions.
+5. Add the attribution and document-license scope described below. Review the
+   resulting local rules for consistency with the project's actual workflows.
+
+A source link has this shape; substitute the selected full commit and filename:
+
+```text
+https://gitea.maximumdirect.net/eric/policy/src/commit/UPSTREAM_COMMIT/docs/policy/testing.md
+```
+
+## Set Up Selective Policy Reading
+
+Include the following in the downstream `docs/development.md`, merging it with
+existing reading guidance and retaining rows for the policies adopted locally.
+The links are relative to that downstream document. Keep policy reading triggers
+there; the documentation policy remains the owner of the documentation topic map.
+
+```markdown
+## Policy Reading Guide
+
+| Policy | Read before… |
+| --- | --- |
+| [Policy set provenance](policy/meta.md) | Adopting policies, checking upstream revisions, or updating the adopted policy set. |
+| [Agents](policy/agents.md) | Recommending, planning, or implementing repository changes. |
+| [Architecture](policy/architecture.md) | Planning or changing application code or its structure. |
+| [Testing](policy/testing.md) | Selecting validation for code changes, or adding, changing, removing, or evaluating tests. |
+| [Documentation](policy/documentation.md) | Writing, revising, or reorganizing documentation. |
+| [OSS](policy/oss.md) | Adding or updating dependencies or incorporated third-party material, or changing licensing or attribution. |
+| [Release](policy/release.md) | Preparing or publishing a release, changing release procedures, or making versioning and compatibility decisions. |
+
+- Read applicable policies before making decisions they govern; multiple policies
+  may apply.
+- Select policies using the task triggers above. Follow cross-references to
+  relevant sections when needed to resolve a concrete question.
+- Reuse policies already available in context; reread when changed or no longer
+  available.
+- Expand reading when the task's scope expands.
+- When revising a policy itself, read that policy and any provisions elsewhere
+  affected by the revision.
+```
+
+## Attribute Copied Policies
+
+Use the [canonical attribution entry](../examples/licensing/policy-attribution.md)
+by inserting it beneath the existing title in the downstream
+`docs/oss/attribution.md`.
+
+- Replace `UPSTREAM_COMMIT` with the selected full commit in all three URLs.
+- Adjust the `Material:` sentence to identify the files actually copied. Keep
+  “adapted for this repository” for customized documents; use “copied without
+  modification” for unchanged copies. For a mixture, identify which are adapted.
+- Preserve supplied creator, copyright, license, and warranty-disclaimer notices,
+  including the link to upstream `COPYRIGHT`. Retain indications of prior
+  modifications as the documents evolve.
+- Copy [CC-BY-SA-4.0.txt](oss/licenses/CC-BY-SA-4.0.txt) into the downstream
+  `docs/oss/licenses/`. The entry's relative license link assumes that location.
+
+This entry is the project's recommended attribution arrangement for copied or
+adapted policies. Its short material statement identifies scope and modification
+status; do not add research narratives or compliance commentary.
+
+Keep customized policy documents under CC-BY-SA 4.0 in this standard adoption
+workflow. Identify that scope in the downstream `COPYRIGHT`, for example:
+
+```text
+Policy documents adapted from Standard Repository Policies remain licensed
+under CC-BY-SA-4.0. See docs/oss/attribution.md for the affected material,
+upstream credit, and license links.
+```
+
+The application's own code retains its selected license. Copying a policy does
+not select a new license for unrelated code or documentation. These instructions
+implement the [project grant](../COPYRIGHT); they do not add a requirement to
+publish private work or send modifications upstream. Other arrangements
+permitted by the license remain available.
+
+## Use Reference Assets
+
+Create actual `COPYRIGHT` and attribution files using the upstream
+[application](../examples/licensing/application/COPYRIGHT),
+[library](../examples/licensing/library/COPYRIGHT), and
+[attribution](../examples/licensing/attribution.md) examples. Read the
+[OSS policy](policy/oss.md) for their format and placeholder substitution rules.
+Original example formatting is available under CC0 as specified in
+[COPYRIGHT](../COPYRIGHT); using that formatting alone does not require an
+attribution entry for this project.
+
+Keep links to these examples in the adopted policy pointed at upstream commits.
+Keep the example collection upstream and use it to create actual project notices.
+Copy the applicable standard license texts into the actual local license files;
+retain their wording and their own terms. Those copies remain necessary under
+the House Format even though example documents stay upstream.
+
+## Check For Upstream Revisions
+
+When asked to check the policy set and recommend updates:
+
+1. Read the local policies and identify each document's `Upstream Source` commit,
+   `Base Policy Version`, and local customizations. Different documents may have
+   different adoption baselines.
+2. Inspect upstream `main` and record its full commit identifier. Use that fixed
+   revision throughout the comparison.
+3. Compare each recorded upstream file with its counterpart at the review
+   revision, then assess the upstream changes against the locally customized
+   policy. Version labels help orientation; inspect the actual differences.
+   Note new, renamed, or removed upstream policies where relevant to the project.
+4. Recommend applicable changes with their reasons, identify conflicts with
+   deliberate local choices, and name policies that need no update. Include the
+   baseline and review revisions so the comparison can be reproduced. Ground
+   recommendations in the local project's needs.
+5. Base provenance claims on available evidence. Report missing or unavailable
+   baselines explicitly and qualify comparisons accordingly. Report upstream
+   access failures and the resulting limits on the review.
+
+For a recommendation-only request, preserve the current files and adoption
+metadata. Apply the following procedure when implementation is requested.
+
+## Update Deliberately
+
+Compare the previously recorded upstream files with a selected newer revision.
+Apply relevant changes while preserving local decisions and selecting updates
+that serve the project.
+
+Update `Base Policy Version` when adopting a newer template version and update
+`Upstream Source` to the revision actually incorporated. Change `Last Updated`
+when revising the local document. Keep the material description, modification
+status, and attribution links accurate. If documents use different upstream
+revisions, retain each file's exact source metadata and include the necessary
+commit-specific source and notice links in the single project attribution entry.
+
+Ordinary review should check the resulting rules, attribution facts, and affected
+links. A commit-based adoption record is sufficient; no recurring synchronization
+check, release gate, or separate license approval is required. Agents following
+this documented arrangement need additional clarification only for a concrete
+circumstance it does not cover. User instructions govern whether changes are
+committed or published.

docs/development.md

@@ -0,0 +1,57 @@
+# Developing Standard Repository Policies
+
+This repository maintains reusable policy templates and reference materials.
+For adopting them into another project, use the [adoption guide](adoption.md).
+
+## Orientation
+
+Read the [agent policy](policy/agents.md) and inspect the working tree before
+editing. Preserve unrelated work. Follow explicit task instructions, including
+requests to leave changes uncommitted. This repository's policy files retain
+their template adoption sections because they are distributed as templates.
+Application-specific examples illustrate downstream adoption.
+
+## Policy Reading Guide
+
+| Policy | Read before… |
+| --- | --- |
+| [Adoption and update guide](adoption.md) | Adopting policies, checking upstream revisions, or updating the adopted policy set. |
+| [Agents](policy/agents.md) | Recommending, planning, or implementing repository changes. |
+| [Architecture](policy/architecture.md) | Planning or changing application code or its structure. |
+| [Testing](policy/testing.md) | Selecting validation for code changes, or adding, changing, removing, or evaluating tests. |
+| [Documentation](policy/documentation.md) | Writing, revising, or reorganizing documentation. |
+| [OSS](policy/oss.md) | Adding or updating dependencies or incorporated third-party material, or changing licensing or attribution. |
+| [Release](policy/release.md) | Preparing or publishing a release, changing release procedures, or making versioning and compatibility decisions. |
+
+- Read applicable policies before making decisions they govern; multiple policies
+  may apply.
+- Select policies using the task triggers above. Follow cross-references to
+  relevant sections when needed to resolve a concrete question.
+- Reuse policies already available in context; reread when changed or no longer
+  available.
+- Expand reading when the task's scope expands.
+- When revising a policy itself, read that policy and any provisions elsewhere
+  affected by the revision.
+
+## Editing And Validation
+
+Keep reusable instructions portable. Put adoption instructions in template
+sections and project-specific contributor procedures here. Original licensing
+examples belong under `examples/licensing/`; explanatory instructions belong in
+their guide or policy.
+
+Increment the affected template's `Base Policy Version` and update its date when
+changing its substantive rules or adoption instructions. Preserve the licensing
+scope defined in `COPYRIGHT`; reproduced license texts must remain verbatim.
+
+Review the diff, run `git diff --check` for changed prose, and check affected links
+and examples. Example placeholders and destination-relative links should be
+validated against the documented downstream layout. Diff, link, and example
+review suffice for prose-only changes. Retain upstream formatting in verbatim
+license texts even where it would trigger whitespace warnings.
+
+Pin adopted-source and example links to commits that contain the referenced
+files. Discovery links to the upstream project and current adoption guide may
+track `main` so downstream agents can find updates. Use local links for new
+assets until a containing commit is available. Confirm public reference links
+are accessible when preparing publication of the reference changes.

docs/oss/licenses/CC-BY-SA-4.0.txt

@@ -0,0 +1,170 @@
+Creative Commons Attribution-ShareAlike 4.0 International
+
+ Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.
+
+Using Creative Commons Public Licenses
+
+Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.
+
+Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. More considerations for licensors.
+
+Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described.
+
+Although not required by our licenses, you are encouraged to respect those requests where reasonable. More considerations for the public.
+
+Creative Commons Attribution-ShareAlike 4.0 International Public License
+
+By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.
+
+Section 1 – Definitions.
+
+     a.	Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
+
+     b.	Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
+
+     c.	BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License.
+
+     d.	Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
+
+     e.	Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
+
+     f.	Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
+
+     g.	License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.
+
+     h.	Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
+
+     i.	Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
+
+     j.	Licensor means the individual(s) or entity(ies) granting rights under this Public License.
+
+     k.	Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
+
+     l.	Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
+
+     m.	You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.
+
+Section 2 – Scope.
+
+     a.	License grant.
+
+          1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
+
+               A. reproduce and Share the Licensed Material, in whole or in part; and
+
+               B. produce, reproduce, and Share Adapted Material.
+
+          2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
+
+          3. Term. The term of this Public License is specified in Section 6(a).
+
+          4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
+
+          5. Downstream recipients.
+
+               A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
+
+               B. Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply.
+
+               C. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
+
+          6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
+
+     b.	Other rights.
+
+          1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
+
+          2. Patent and trademark rights are not licensed under this Public License.
+
+          3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.
+
+Section 3 – License Conditions.
+
+Your exercise of the Licensed Rights is expressly made subject to the following conditions.
+
+     a.	Attribution.
+
+          1. If You Share the Licensed Material (including in modified form), You must:
+
+               A. retain the following if it is supplied by the Licensor with the Licensed Material:
+
+                    i.	identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
+
+                    ii.	a copyright notice;
+
+                    iii. a notice that refers to this Public License;
+
+                    iv.	a notice that refers to the disclaimer of warranties;
+
+                    v.	a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
+
+               B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
+
+               C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
+
+          2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
+
+          3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
+
+     b.	ShareAlike.In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.
+
+          1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
+
+          2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
+
+          3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.
+
+Section 4 – Sui Generis Database Rights.
+
+Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:
+
+     a.	for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
+
+     b.	if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and
+
+     c.	You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.
+For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.
+
+Section 5 – Disclaimer of Warranties and Limitation of Liability.
+
+     a.	Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.
+
+     b.	To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.
+
+     c.	The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.
+
+Section 6 – Term and Termination.
+
+     a.	This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
+
+     b.	Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
+
+          1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
+
+          2. upon express reinstatement by the Licensor.
+
+     c.	For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
+
+     d.	For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
+
+     e.	Sections 1, 5, 6, 7, and 8 survive termination of this Public License.
+
+Section 7 – Other Terms and Conditions.
+
+     a.	The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
+
+     b.	Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.
+
+Section 8 – Interpretation.
+
+     a.	For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
+
+     b.	To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
+
+     c.	No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
+
+     d.	Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.
+
+Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.
+
+Creative Commons may be contacted at creativecommons.org.

docs/oss/licenses/CC0-1.0.txt

@@ -0,0 +1,121 @@
+Creative Commons Legal Code
+
+CC0 1.0 Universal
+
+    CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+    LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
+    ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+    INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+    REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
+    PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
+    THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
+    HEREUNDER.
+
+Statement of Purpose
+
+The laws of most jurisdictions throughout the world automatically confer
+exclusive Copyright and Related Rights (defined below) upon the creator
+and subsequent owner(s) (each and all, an "owner") of an original work of
+authorship and/or a database (each, a "Work").
+
+Certain owners wish to permanently relinquish those rights to a Work for
+the purpose of contributing to a commons of creative, cultural and
+scientific works ("Commons") that the public can reliably and without fear
+of later claims of infringement build upon, modify, incorporate in other
+works, reuse and redistribute as freely as possible in any form whatsoever
+and for any purposes, including without limitation commercial purposes.
+These owners may contribute to the Commons to promote the ideal of a free
+culture and the further production of creative, cultural and scientific
+works, or to gain reputation or greater distribution for their Work in
+part through the use and efforts of others.
+
+For these and/or other purposes and motivations, and without any
+expectation of additional consideration or compensation, the person
+associating CC0 with a Work (the "Affirmer"), to the extent that he or she
+is an owner of Copyright and Related Rights in the Work, voluntarily
+elects to apply CC0 to the Work and publicly distribute the Work under its
+terms, with knowledge of his or her Copyright and Related Rights in the
+Work and the meaning and intended legal effect of CC0 on those rights.
+
+1. Copyright and Related Rights. A Work made available under CC0 may be
+protected by copyright and related or neighboring rights ("Copyright and
+Related Rights"). Copyright and Related Rights include, but are not
+limited to, the following:
+
+  i. the right to reproduce, adapt, distribute, perform, display,
+     communicate, and translate a Work;
+ ii. moral rights retained by the original author(s) and/or performer(s);
+iii. publicity and privacy rights pertaining to a person's image or
+     likeness depicted in a Work;
+ iv. rights protecting against unfair competition in regards to a Work,
+     subject to the limitations in paragraph 4(a), below;
+  v. rights protecting the extraction, dissemination, use and reuse of data
+     in a Work;
+ vi. database rights (such as those arising under Directive 96/9/EC of the
+     European Parliament and of the Council of 11 March 1996 on the legal
+     protection of databases, and under any national implementation
+     thereof, including any amended or successor version of such
+     directive); and
+vii. other similar, equivalent or corresponding rights throughout the
+     world based on applicable law or treaty, and any national
+     implementations thereof.
+
+2. Waiver. To the greatest extent permitted by, but not in contravention
+of, applicable law, Affirmer hereby overtly, fully, permanently,
+irrevocably and unconditionally waives, abandons, and surrenders all of
+Affirmer's Copyright and Related Rights and associated claims and causes
+of action, whether now known or unknown (including existing as well as
+future claims and causes of action), in the Work (i) in all territories
+worldwide, (ii) for the maximum duration provided by applicable law or
+treaty (including future time extensions), (iii) in any current or future
+medium and for any number of copies, and (iv) for any purpose whatsoever,
+including without limitation commercial, advertising or promotional
+purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
+member of the public at large and to the detriment of Affirmer's heirs and
+successors, fully intending that such Waiver shall not be subject to
+revocation, rescission, cancellation, termination, or any other legal or
+equitable action to disrupt the quiet enjoyment of the Work by the public
+as contemplated by Affirmer's express Statement of Purpose.
+
+3. Public License Fallback. Should any part of the Waiver for any reason
+be judged legally invalid or ineffective under applicable law, then the
+Waiver shall be preserved to the maximum extent permitted taking into
+account Affirmer's express Statement of Purpose. In addition, to the
+extent the Waiver is so judged Affirmer hereby grants to each affected
+person a royalty-free, non transferable, non sublicensable, non exclusive,
+irrevocable and unconditional license to exercise Affirmer's Copyright and
+Related Rights in the Work (i) in all territories worldwide, (ii) for the
+maximum duration provided by applicable law or treaty (including future
+time extensions), (iii) in any current or future medium and for any number
+of copies, and (iv) for any purpose whatsoever, including without
+limitation commercial, advertising or promotional purposes (the
+"License"). The License shall be deemed effective as of the date CC0 was
+applied by Affirmer to the Work. Should any part of the License for any
+reason be judged legally invalid or ineffective under applicable law, such
+partial invalidity or ineffectiveness shall not invalidate the remainder
+of the License, and in such case Affirmer hereby affirms that he or she
+will not (i) exercise any of his or her remaining Copyright and Related
+Rights in the Work or (ii) assert any associated claims and causes of
+action with respect to the Work, in either case contrary to Affirmer's
+express Statement of Purpose.
+
+4. Limitations and Disclaimers.
+
+ a. No trademark or patent rights held by Affirmer are waived, abandoned,
+    surrendered, licensed or otherwise affected by this document.
+ b. Affirmer offers the Work as-is and makes no representations or
+    warranties of any kind concerning the Work, express, implied,
+    statutory or otherwise, including without limitation warranties of
+    title, merchantability, fitness for a particular purpose, non
+    infringement, or the absence of latent or other defects, accuracy, or
+    the present or absence of errors, whether or not discoverable, all to
+    the greatest extent permissible under applicable law.
+ c. Affirmer disclaims responsibility for clearing rights of other persons
+    that may apply to the Work or any use thereof, including without
+    limitation any person's Copyright and Related Rights in the Work.
+    Further, Affirmer disclaims responsibility for obtaining any necessary
+    consents, permissions or other rights required for any use of the
+    Work.
+ d. Affirmer understands and acknowledges that Creative Commons is not a
+    party to this document and has no duty or obligation with respect to
+    this CC0 or use of the Work.

docs/oss/licenses/README.md

@@ -2,20 +2,24 @@
 
 This collection supplies reusable reference texts for repositories adopting the
 [Open Source Licensing And Attribution Policy](../../policy/oss.md). Copy the
-texts your dependencies use into your repository's `docs/oss/licenses/`, together
+texts your incorporated code, documentation, or assets use into your repository's
-with applicable companion texts. The collection is not exhaustive, and adopting
+`docs/oss/licenses/`, together with applicable companion texts. Select the texts
-projects need not copy every file.
+applicable to incorporated material.
 
-These files are reference material. Their presence does not license this
+These files are reference material. Each project's grant is stated in COPYRIGHT;
-repository or an adopting project under every listed license.
+each component's grant is identified in its attribution entry.
 
 ## Sources
 
-The texts were retrieved on 2026-09-26 and are preserved byte-for-byte from the
+The original nine texts were retrieved on 2026-09-26 and are preserved byte-for-byte from the
 sources below. GNU and Apache texts come directly from their publishers. MIT and
 BSD texts come from the SPDX License List data at commit
 `31ba1a50e5397e00a304dbadc76531740e89ee48`.
 
+CC-BY-SA 4.0 and CC0 1.0 were retrieved on 2026-09-27 from that same SPDX
+revision and are also preserved byte-for-byte. They support policy attribution
+and the example-format dedication described in the root [COPYRIGHT](../../../COPYRIGHT).
+
 | Local text | Source |
 | --- | --- |
 | [GPL-2.0.txt](GPL-2.0.txt) | [Free Software Foundation](https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt) |
@@ -27,6 +31,8 @@ BSD texts come from the SPDX License List data at commit
 | [BSD-3-Clause.txt](BSD-3-Clause.txt) | [SPDX](https://github.com/spdx/license-list-data/blob/31ba1a50e5397e00a304dbadc76531740e89ee48/text/BSD-3-Clause.txt) |
 | [MIT.txt](MIT.txt) | [SPDX](https://github.com/spdx/license-list-data/blob/31ba1a50e5397e00a304dbadc76531740e89ee48/text/MIT.txt) |
 | [Apache-2.0.txt](Apache-2.0.txt) | [Apache Software Foundation](https://www.apache.org/licenses/LICENSE-2.0.txt) |
+| [CC-BY-SA-4.0.txt](CC-BY-SA-4.0.txt) | [SPDX](https://github.com/spdx/license-list-data/blob/31ba1a50e5397e00a304dbadc76531740e89ee48/text/CC-BY-SA-4.0.txt) |
+| [CC0-1.0.txt](CC0-1.0.txt) | [SPDX](https://github.com/spdx/license-list-data/blob/31ba1a50e5397e00a304dbadc76531740e89ee48/text/CC0-1.0.txt) |
 
 ## Using The Texts
 
@@ -34,14 +40,13 @@ BSD texts come from the SPDX License List data at commit
   Put actual upstream copyright statements in the component's attribution entry.
   Link project-specific notices and exceptions to the imported upstream commit.
 - GNU filenames identify the text version. The attribution entry's SPDX
-  expression specifies `-only` or `-or-later` according to the upstream grant;
+  expression specifies `-only` or `-or-later` according to the upstream grant.
-  a shared text does not select that grant for the component.
 - LGPL 2.0 is the GNU Library General Public License. LGPL 2.1 and 3.0 are the
   GNU Lesser General Public License; these versions are distinct.
 - When copying LGPL 3.0, also copy GPL 3.0, whose terms it incorporates, and make
   both texts reachable from the attribution entry. Include other companion texts
   or exceptions when the component's applicable terms require them.
 
-Record any intentional source refresh here and preserve the retrieved text
+Record intentional source refreshes here and preserve retrieved texts verbatim.
-without editorial changes. No synchronization service or recurring release check
+Synchronization services and recurring release checks are optional for this
-is required for this reference collection.
+reference collection.

docs/policy/agents.md

@@ -1,22 +1,22 @@
 # Agent Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
 
-**Last Updated**: 2026-09-23
+**Last Updated**: 2026-09-27
 
 ## Base Policy Template
 
-This document is the base template for the canonical house rules that agents must follow while working in this repository. Repositories that implement this policy should:
+When adopting this policy:
 
-1. Review the policy, remove any rules that must not apply to the current project, and add any additional rules that are required by the current project;
+1. Retain applicable rules and add project-specific requirements;
 2. Update the `Last Updated` field to the current date; and
 3. Remove this heading (`Base Policy Template`) and the associated text. 
 
-Most projects will not require any revisions to the substantive policy rules as written below.
+Most projects can adopt the substantive rules as written.
 
 ## Purpose
 
-Agents working in this repository must read and adhere to the following house rules.
+Agents must read and follow these rules.
 
 ## Implementation Discipline
 
@@ -53,15 +53,15 @@ unless that behavior was expressly selected as part of the contract.
 
 ## Git Commit Policy
 
-By default, create a commit after completing each coherent unit of work, using a
+By default, commit each completed, nonempty unit of work using a
 concise, plain-English message describing what changed. This policy is standing
 authorization to create those local commits; a separate user request is not
 required. An explicit user instruction to leave work uncommitted takes precedence.
 
 A unit of work is a focused, reviewable outcome, including its relevant tests and
-documentation. Do not commit after every intermediate edit or create empty commits.
+documentation.
 Complete the appropriate validation before committing. If work is incomplete or
-validation is blocked, report that state rather than presenting it as completed.
+validation is blocked, report that state accurately.
 
 Before committing:
 
@@ -69,10 +69,10 @@ Before committing:
    changes. Identify changes that predate the current unit of work.
 2. Exclude secrets, local environment files, generated junk, and unrelated changes.
 3. Stage only the files or hunks belonging to the completed unit. Use `git add .`
-   only when every included change belongs to that unit. Do not disturb unrelated
+   only when every included change belongs to that unit. Preserve unrelated
-   staged or unstaged work.
+   staged and unstaged work.
-4. Review `git diff --staged` and run appropriate checks for the change. Do not
+4. Review `git diff --staged` and run appropriate checks for the change. Reuse
-   repeat checks already passed for unchanged content merely to create a commit.
+   successful checks for unchanged content.
 5. Review `git log --oneline -n 10` and use
    `git commit -m "<concise plain-English commit message>"`.
 6. Report the commit identifier and any remaining uncommitted work.

docs/policy/architecture.md

@@ -1,27 +1,24 @@
 # Architecture Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
 
-**Last Updated**: 2026-09-25
+**Last Updated**: 2026-09-27
 
 ## Base Policy Template
 
-This document is the base template for the canonical architecture policy.
+When adopting this policy:
-Repositories that implement this policy should:
 
 1. Replace the application-specific guidance below with the repository's
    purpose, adopted architectural constraints, and relevant non-goals;
 2. Distinguish rules governing development from descriptions of implemented
    structure. Keep proposed changes and implementation status in their canonical
    documents under the [documentation policy](documentation.md);
-3. Reference supporting documents only when they contain useful information.
+3. Reference supporting documents when they contain useful information;
-   Do not create `TODO` documents solely to populate an architectural outline;
 4. Update the `Last Updated` field to the current date; and
 5. Remove this heading (`Base Policy Template`) and the associated text.
 
-This template requires substantial customization. Select topics that matter to
+This template requires substantial customization. Select topics relevant to
-the application; the examples below are not a checklist of required subsystems,
+the application from the examples below.
-interfaces, or supporting documents.
 
 ## Purpose And Ownership
 
@@ -31,7 +28,7 @@ and dependency rules, established invariants, and explicit non-goals.
 
 Describe the concrete package inventory and implementation mechanics in internal
 documentation. Link to canonical public contracts for their exact behavior and
-to ADRs for decision rationale rather than repeating those definitions here.
+to ADRs for decision rationale.
 
 ## Architectural Approach
 
@@ -40,23 +37,16 @@ integrations and APIs within internal adapters. Keep domain and application
 logic independent of external integration details, and make dependency direction
 clear in the adopted policy.
 
-Implement that separation with proportionate, idiomatic code. The preference
+Implement that separation with proportionate, idiomatic code. Choose interfaces
-does not by itself require an interface for every type, a fixed directory tree,
+and package layout to serve the application's actual boundaries. Use adapters
-or adapters for collaborators that have no external integration responsibility.
+for collaborators with external integration responsibilities.
 
 ## Adopted Constraints And Implemented Structure
 
-An adopted architectural constraint governs development. It is not evidence
+Architectural constraints govern current and future development. Record
-that every component or capability to which it could apply already exists.
+implemented structure accurately, proposals and implementation status in the
-For example, a rule that external integrations belong behind adapters can
+roadmap, and significant decisions and rationale in ADRs. Describe a target
-apply to future integrations without implying that those integrations are
+structure as implemented when its changes land.
-implemented or planned.
-
-Describe implemented structure accurately. Keep proposals and implementation
-status in the roadmap, and significant decisions and their rationale in ADRs.
-When an accepted decision requires changing existing structure, identify that
-transition through those documents; do not describe the target structure as
-already implemented or treat acceptance as proof of compliance.
 
 Constraints must reflect deliberately selected requirements and decisions.
 Do not promote incidental implementation choices into architectural invariants.
@@ -81,12 +71,11 @@ application's adopted requirements, along with scenarios it explicitly excludes.
 For example, distinguish handling untrusted application input from defending
 against a privileged actor concurrently modifying the host filesystem.
 
-These statements should explain the scope of the adopted architectural constraints. Excluding a scenario is not a claim that it cannot occur. Do not
+Threat exclusions define the scope of the adopted requirements. Base defenses
-infer additional defenses or guarantees merely because a hypothetical threat
+and guarantees on those requirements and raise unsettled scope for a deliberate
-can be described. Unsettled scope decisions should be raised for a deliberate
 decision under the [agent policy](agents.md).
 
-Keep this discussion proportionate. A separate threat assessment or security
+Keep this discussion proportionate to the application. A separate threat
-document is not required merely to adopt this template. Configuration,
+assessment or security document is optional when adopting this template.
-operations, and internal documents retain ownership of credential supply,
+Configuration, operations, and internal documents retain ownership of credential supply,
 runtime handling, and implementation mechanisms under the documentation policy.

docs/policy/documentation.md

@@ -1,15 +1,15 @@
 # Documentation Policy
 
-**Base Policy Version:** 1.6
+**Base Policy Version:** 1.11
 
 **Last Updated**: 2026-09-27
 
 ## Base Policy Template
 
-This document is the base template for the canonical documentation policy. Repositories that implement this policy should:
+When adopting this policy:
 
 1. Review the list of documents under the `Canonical Ownership` heading, remove any entries that do not currently apply and are not expected to apply to the current project, and add any additional entries that may be required by the current project;
-2. Ensure that each referenced document is present on the filesystem, even if the initial content is simply `TODO`;
+2. Create documents for applicable responsibilities when substantive content is available;
 3. Update the `Last Updated` field to the current date; and
 4. Remove this heading (`Base Policy Template`) and the associated text.
 
@@ -25,7 +25,7 @@ to drift for users, operators, developers, integrators, and LLM coding agents.
 
 Each authoritative fact belongs in one document. A non-owning document may give
 a short, stable summary for orientation, but it must link to the canonical owner
-instead of repeating volatile details.
+for volatile details.
 
 Volatile details include commands, flags, configuration fields and defaults,
 module keys, schemas, file names, paths, status codes, retry behavior, and
@@ -37,27 +37,26 @@ contract, maintain it only in the owning document.
 Outside `docs/roadmap/`, documentation describes implemented behavior only.
 Partial features may be described only to their implemented boundary.
 
-Architectural constraints may govern future changes without implying that the
+Architectural constraints may govern future changes. Describe current structure
-components or capabilities they would govern already exist. This does not permit
+from implemented behavior.
-describing a proposed system structure as implemented.
 
-ADRs may record an accepted architectural decision before implementation, but
+ADRs may record an accepted architectural decision before implementation. The
-acceptance must not be presented as proof that the behavior exists. The roadmap owns implementation status and sequencing
+roadmap owns implementation status and sequencing until the decision is
-until the decision is implemented. Current architecture, user, operator,
+implemented. Current architecture, user, operator, integration, and internal
-integration, and internal documentation are updated when the behavior lands.
+documentation are updated when the behavior lands.
 
 ### Audience And Detail
 
 Write for the document's stated audience and include only the detail needed for
-its owned topic. User and operator docs should not expose implementation detail.
+its owned topic. Keep user and operator docs focused on using and operating the
-Developer docs should link to user-facing and external contracts rather than
+application. Developer docs should link to user-facing and external contracts
-restate them.
+for their definitions.
 
 ### Examples
 
 Complete copyable files belong in `examples/`. Documentation may use the
 smallest illustrative snippet needed to explain its owned topic, but should link
-to maintained examples instead of embedding a second complete copy.
+to maintained examples for complete copyable files.
 
 Examples must be valid, secret-free, and tested where practical. Commands and
 configuration used in documentation should match the application.
@@ -73,44 +72,42 @@ secret values.
 
 | Topic | Canonical owner | Owned content | Content owned elsewhere |
 | --- | --- | --- | --- |
-| Product orientation and minimal end-to-end quickstart | `README.md` | What this application is, why it is useful, one shortest successful invocation, and links onward, including license and attribution navigation. | Complete command reference, configuration reference, operational procedures, implementation detail. |
+| Product orientation and minimal end-to-end quickstart | `README.md` | Purpose, value, shortest successful invocation, and navigation, including licensing and attribution. | Complete command reference, configuration reference, operational procedures, implementation detail. |
-| Contributor entry point | `docs/development.md` | Task-oriented reading guide, minimal contributor orientation, baseline validation commands, and links to canonical docs. | Package inventory, architecture rules, subsystem behavior, detailed change recipes. |
+| Contributor entry point | `docs/development.md` | Task-oriented reading guide, contributor orientation, baseline validation commands, and canonical links. | Package inventory, architecture rules, subsystem behavior, detailed change recipes. |
-| Application architecture policy | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, architectural boundaries, invariants, safety properties, and non-goals. | Concrete package inventory, implementation mechanics, contributor procedures, decision history, future work. |
+| Application architecture policy | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, boundaries, invariants, safety properties, and non-goals. | Concrete package inventory, implementation mechanics, contributor procedures, decision history, future work. |
-| Agent policy | `docs/policy/agents.md` | Implementation discipline for coding agents, including proportionality, idiomatic simplicity, and rules against inventing requirements, restrictions, guarantees, or repository policy. | Application contracts, architecture, testing policy, and contributor procedures. |
+| Policy-set provenance and upstream navigation | `docs/policy/meta.md` | Policy-set origin, local authority, adoption baselines, and upstream adoption and update links. | Task-specific reading triggers, detailed adoption procedures, and formal attribution notices. |
+| Agent policy | `docs/policy/agents.md` | Proportionate, idiomatic implementation; rules against inventing requirements, restrictions, guarantees, or policy. | Application contracts, architecture, testing policy, and contributor procedures. |
 | Documentation policy | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and ADR/document lifecycle. | Application architecture or product behavior. |
-| Testing policy | `docs/policy/testing.md` | Test philosophy, risk-based sufficiency, test boundaries, doubles, coverage guidance, regression-test policy, and criteria for adding, rewriting, or deleting tests. | Subsystem behavior, application contracts, subsystem-specific test inventories, and implementation plans. |
+| Testing policy | `docs/policy/testing.md` | Test philosophy, risk sufficiency, boundaries, doubles, coverage, regressions, and test maintenance. | Subsystem behavior, application contracts, subsystem-specific test inventories, and implementation plans. |
-| Release policy | `docs/policy/release.md` | Versioning and compatibility rules, release integrity and immutability requirements, release-documentation policy, proportionate gate selection, publication controls, release completion, and the boundary between required checks and optional verification. | Repository-specific commands, product installation guidance, CLI version semantics, historical release summaries, and CI implementation detail. |
+| Release policy | `docs/policy/release.md` | Versioning, compatibility, release integrity and immutability, release documentation, proportionate gates, publication controls, completion, and required versus optional checks. | Repository-specific commands, product installation guidance, CLI version semantics, historical release summaries, and CI implementation detail. |
-| Open source licensing and attribution policy | `docs/policy/oss.md` | Project licensing defaults and author choices, COPYRIGHT conventions, upstream attribution format, license-text and notice-link conventions, discoverability, maintenance, and handling of concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
+| Open source licensing and attribution policy | `docs/policy/oss.md` | License defaults and author choices, COPYRIGHT and attribution formats, license/notice links, discoverability, maintenance, and concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
-| Project copyright and license grant | `COPYRIGHT` | Project identity, copyright holders and years, SPDX expression, license grant, warranty disclaimer, and statement about third-party material. | Complete license texts and upstream component attribution. |
+| Project copyright and license grant | `COPYRIGHT` | Project identity, copyright holders and years, SPDX expression, grant, warranty disclaimer, and third-party statement. | Complete license texts and upstream component attribution. |
-| Project license texts | `LICENSE` | Complete project license text and incorporated companion text, with project-specific fields where required by the selected license. | General licensing policy and upstream component attribution. |
+| Project license texts | `LICENSE` | Complete project and incorporated companion license texts, with required project-specific fields. | General licensing policy and upstream component attribution. |
-| Upstream component attribution | `docs/oss/attribution.md` | Factual component identification, copyright statements, license identification, required upstream notices, and license, notice, and source links in the House Format. | General attribution policy, exception reasoning, research narratives, compliance commentary, and complete standard license texts. |
+| Upstream component attribution | `docs/oss/attribution.md` | House Format component entries: identity, material scope and modifications where applicable, copyright, license, required notices, and license, notice, and source links. | General attribution policy, exception reasoning, research narratives, compliance commentary, and complete standard license texts. |
-| Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim standard license texts shared by attribution entries where applicable. | Project-specific upstream notices, attribution prose, and policy interpretation. |
+| Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim standard license texts shared by applicable entries. | Project-specific upstream notices, attribution prose, and policy interpretation. |
-| Repository-specific release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, concrete validation and publication commands, automated publication guards, asynchronous deliverable publication, separate delivery status, optional consumer-facing verification, and failure recovery. | General release requirements, product installation guidance, historical release summaries, and current compatibility contracts. |
+| Repository-specific release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, validation and publication commands and automated guards, asynchronous deliverables, delivery status, optional consumer verification, and recovery. | General release requirements, product installation guidance, historical release summaries, and current compatibility contracts. |
 | CLI contract (if applicable) | `docs/cli.md` | Commands, arguments, flags, invocation semantics, and exit codes. | End-to-end operating procedures, configuration field definitions, runtime filesystem layout, module implementation details. |
-| Configuration contract (if applicable) | `docs/config.md` | Discovery and precedence, file schema, fields, defaults, environment overrides, validation rules, and user-selectable module or validator keys. | Complete example files, CLI syntax, runtime state lifecycle, module implementation details. |
+| Configuration contract (if applicable) | `docs/config.md` | Discovery, precedence, schema, fields, defaults, environment overrides, validation, and selectable module and validator keys. | Complete example files, CLI syntax, runtime state lifecycle, module implementation details. |
-| Operations (if applicable) | `docs/operations.md` | Runtime workflows, physical filesystem and state layout, output, cache, and debug handling, resume, cleanup, permissions, recovery, and operational limits. | CLI flag syntax, configuration field definitions, logical output schemas, implementation mechanics. |
+| Operations (if applicable) | `docs/operations.md` | Runtime workflows, physical filesystem and state layout, output, cache and debug handling, resume, cleanup, permissions, recovery, and limits. | CLI flag syntax, configuration field definitions, logical output schemas, implementation mechanics. |
 | Public HTTP contract (if applicable) | `docs/api.md` | Routes, authentication, media types, request and response schemas, status codes, pagination, caching, idempotency, rate limits, and HTTP retry semantics. | Client walkthroughs, upstream or downstream integration internals, implementation detail. |
-| Consumer guidance for the public Go API (if applicable) | `docs/consumers/` | Task-oriented use of the public interface, minimal client examples, and consumer responsibilities. | HTTP wire semantics, external protocol contracts, internal implementation detail. |
+| Consumer guidance for the public Go API (if applicable) | `docs/consumers/` | Task-oriented public Go API usage, minimal examples, and consumer responsibilities. | HTTP wire semantics, external protocol contracts, internal implementation detail. |
-| Integration contracts for external components (if applicable) | `docs/integrations/` | External file formats and protocols, upstream and downstream contracts, logical output bundle paths and schemas, media types, and compatibility behavior. | Physical runtime placement and lifecycle, internal transformations, CLI syntax, configuration defaults. |
+| Integration contracts for external components (if applicable) | `docs/integrations/` | External formats and protocols, upstream and downstream contracts, logical output paths and schemas, media types, and compatibility. | Physical runtime placement and lifecycle, internal transformations, CLI syntax, configuration defaults. |
-| Inventory of implemented internal packages | `docs/internal/overview.md` | Current packages and components, their implemented responsibilities, and links to focused internal docs. | Normative architecture, contributor reading policy, external contracts. |
+| Inventory of implemented internal packages | `docs/internal/overview.md` | Implemented packages and components, responsibilities, and links to focused internal docs. | Normative architecture, contributor reading policy, external contracts. |
-| Behavior and architecture of internal packages | Other files under `docs/internal/` | Implementation flow, internal collaborators and state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, configuration definitions and defaults, external schemas, operator procedures. |
+| Behavior and architecture of internal packages | Other files under `docs/internal/` | Implementation flow, collaborators, state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, configuration definitions and defaults, external schemas, operator procedures. |
 | Architectural decision records | `docs/adr/` | Significant decisions, context, alternatives, rationale, consequences, and supersession history. | Current behavior reference, implementation status, task sequencing. |
-| Future work and implementation status | `docs/roadmap/` | Proposed, accepted, deferred, or rejected work; implementation status; sequencing; and task breakdowns. | Implemented behavior reference and architectural decision rationale. |
+| Future work and implementation status | `docs/roadmap/` | Proposed, accepted, deferred, or rejected work; implementation status, sequencing, and task breakdowns. | Implemented behavior reference and architectural decision rationale. |
-| Release-note history | `docs/releases/` | One checked-in historical summary for each source release made under the procedure. The note at the immutable tag is that release's record. | Current commands, behavior, contracts, and compatibility definitions. |
+| Release-note history | `docs/releases/` | One checked-in summary per source release under the procedure; the note at its immutable tag is the release record. | Current commands, behavior, contracts, and compatibility definitions. |
-| Complete copyable artifacts | `examples/` | Maintained configuration, inputs, and other files intended to be copied or run. | Field-by-field reference, command reference, prose explanation. |
+| Complete copyable artifacts | `examples/` | Maintained configuration, inputs, and other copyable or runnable files. | Field-by-field reference, command reference, prose explanation. |
 
-Documents that do not exist are required only when the corresponding interface
+Create supporting documents for existing interfaces and responsibilities when
-or responsibility exists. Do not create placeholder API, consumer, integration,
+substantive content is available.
-or operations documents for behavior the application does not have.
 
 ## Boundary Rules
 
 ### Orientation
 
-The README owns product orientation. The developer guide routes contributors.
+Link among orientation, architecture, and internal documents; maintain each
-Architecture owns normative structure. Internal overview owns the current
+package or behavior description in its canonical owner.
-concrete component map. These documents may link to one another but should not
-maintain parallel package or behavior descriptions.
 
 ### Commands, Configuration, And Operations
 
@@ -124,20 +121,16 @@ other contracts.
 
 The release policy defines requirements and invariants that every release must
 satisfy. The repository-specific release procedure defines the commands and
-workflow maintainers use to satisfy that policy. Release notes are immutable
+workflow maintainers use to satisfy that policy. Release notes record history
-historical summaries, not current-state contract owners: the checked-in note at
+at immutable tags. Maintain current behavior in its canonical documentation,
-an immutable tag records that release, while current canonical documentation
+update it with the corresponding behavior changes, and keep release procedures
-must change with the behavior it describes. Do not use a release procedure or
+consistent with adopted policy.
-release note to weaken policy, redefine current behavior, or defer required
-documentation updates.
 
 ### Project Licensing And Upstream Attribution
 
-The [OSS policy](oss.md) defines project licensing conventions, the upstream
+README and release documents link to the canonical licensing and attribution
-House Format, and README and release-link conventions. `COPYRIGHT` states the
+materials under the [OSS policy](oss.md). The release procedure owns URL
-project grant; `LICENSE` supplies its complete license texts. Attribution entries
+construction and publication mechanics.
-own component-specific information. README and release documents provide navigation to those canonical materials; the
-release procedure owns URL construction and publication mechanics.
 
 ### Contracts And Implementation
 

docs/policy/meta.md

@@ -0,0 +1,33 @@
+# Policy Set Provenance
+
+**Base Policy Version:** 1.0
+
+**Last Updated**: 2026-09-27
+
+## Base Policy Template
+
+Repositories adopting this policy should copy it alongside their selected
+policies, retain its version, set `Last Updated` to the adoption date, and add
+`Upstream Source` linking to this file at the adopted commit. Confirm the local
+attribution link, then remove this section. The text below describes the
+resulting downstream policy set.
+
+## Origin And Local Authority
+
+This repository's policy set is adapted from
+[Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy).
+The adopted local policies govern work in this repository. Upstream revisions
+become local policy through deliberate adoption, preserving local decisions.
+Each policy's `Upstream Source` identifies its adopted baseline.
+
+## Adoption And Updates
+
+For policy adoption, upstream revision reviews, and updates, consult the
+[upstream adoption and update guide](https://gitea.maximumdirect.net/eric/policy/src/branch/main/docs/adoption.md).
+That guide and the reference example collection are maintained upstream and
+accessed through links. Keep discovery links pointed at the current upstream
+project and guide; keep adopted-source and example links pinned to commits.
+
+The local [developer guide](../development.md) routes tasks to applicable
+policies. Formal credit and licensing notices for the copied policy material
+belong in the local [attribution document](../oss/attribution.md).

docs/policy/oss.md

@@ -1,6 +1,6 @@
 # Open Source Licensing And Attribution Policy
 
-**Base Policy Version:** 1.5
+**Base Policy Version:** 1.8
 
 **Last Updated**: 2026-09-27
 
@@ -21,21 +21,23 @@ Repositories adopting this policy should:
 
 Selected standard license texts are available in this template repository's
 [reference collection](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/docs/oss/licenses/README.md). Copy the applicable texts,
-including companion licenses, into the adopting repository. The collection is a
+including companion licenses, into the adopting repository. Maintain the
-convenience, not an exhaustive catalog or a required bundle; maintain the project's
+project's own attribution entries and upstream notice links under this policy.
-own attribution entries and upstream notice links under this policy.
 
 ## Purpose And Scope
 
 This policy defines project licensing conventions and a repeatable House Format
 for upstream attribution and license notices. It covers the project's own code
 and upstream components incorporated into or distributed with the application
-or library, including relevant transitive dependencies and copied code or assets.
+or library, including relevant transitive dependencies and copied code,
-Treatment follows the component's terms and actual use, rather than its
+documentation, or assets.
-classification as a direct dependency.
+Determine treatment from the component's terms and actual use.
 
-Do not add attribution entries merely because a repository supplied development
+Consulting development guidance or using tooling alone does not require an
-guidance or tooling.
+attribution entry. Copying or adapting documentation for inclusion in the
+repository is different: preserve its applicable attribution and license terms.
+A material's role as development guidance does not exempt copied documents.
+Apply any express permissions for attribution-free reuse of example formatting.
 
 The baseline is a publicly available source repository with releases published
 alongside it. The format is independent of language, forge, and build system.
@@ -46,13 +48,12 @@ compatibility, or resolve every obligation arising from use or distribution.
 
 The [documentation policy](documentation.md) assigns ownership:
 
-- `COPYRIGHT` contains the project name, copyright statements, SPDX expression,
+- `COPYRIGHT`: project name, copyright statements, SPDX expression, grant,
-  license grant, warranty disclaimer, and statement about third-party material.
+  warranty disclaimer, and third-party statement.
 - `LICENSE` contains the complete, unmodified project license text, including
   incorporated companion text. Dependency attribution does not relicense the project.
-- `docs/oss/attribution.md` contains the canonical component entries.
+- `docs/oss/attribution.md`: canonical component entries.
-- `docs/oss/licenses/` contains complete, verbatim standard license texts,
+- `docs/oss/licenses/`: complete, verbatim standard and applicable companion texts.
-  including companion texts where applicable.
 
 Use recognizable license filenames, such as `Apache-2.0.txt` or `LGPL-3.0.txt`.
 A shared standard text may serve multiple entries. Keep explanations outside
@@ -60,12 +61,9 @@ license texts and preserve distinct versions and exceptions.
 
 ## Upstream Reference Examples
 
-The linked examples are reference material hosted in the public policy
+Use the commit-pinned upstream examples to create actual project notices.
-repository at a fixed commit. Retain these upstream links when adopting this
+Retain their links and keep the example collection upstream; keep applicable
-policy; do not copy the example collection into the application's or library's
+license texts locally as specified above.
-`examples/` directory. Create the project's actual `COPYRIGHT` and attribution
-files using the examples. Applicable license texts still belong locally in
-`LICENSE` and `docs/oss/licenses/` as specified here.
 
 ## Project Licensing
 
@@ -84,10 +82,9 @@ individual packages.
 Use the upstream [application COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/application/COPYRIGHT)
 or [library COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/library/COPYRIGHT)
 to create the project’s root `COPYRIGHT` file.
-Replace the project name, years, and holders with accurate information; do not
+Use verified project names, contribution years, and copyright holders.
-assume the maintainer owns every contribution or advance years automatically.
 For another selected license, adapt the grant, SPDX expression, disclaimer, and
-text references together. The examples do not constrain the author's choice.
+text references together to reflect the author's selected grant.
 
 For GPLv3 projects, copy the complete GPLv3 text into `LICENSE`. For LGPLv3
 projects, place the complete LGPLv3 text followed by the complete GPLv3 text in
@@ -102,35 +99,38 @@ fields; the standard reference collection remains unchanged. Keep `COPYRIGHT`,
 grant. This convention introduces no blanket requirement for per-file headers;
 preserve notices or add them where the applicable terms require them.
 
+Identify separately licensed documentation or assets in the project grant, with
+links to their attribution and license information. An application's default
+code license does not override the terms of incorporated documentation.
+
 ## Upstream Attribution House Format
 
 Begin `docs/oss/attribution.md` with `# Open Source Attribution Notices`,
-followed directly by component entries. Do not add an introductory summary,
+followed directly by component entries. These comprise the complete document.
-policy links, audit narrative, disclaimer, or concluding explanation.
 
 Each entry presents these five fields in order, with blank lines between them:
 
 1. **Project name** as a level-two heading. An optional identification paragraph
    may follow, such as `Selected module: MODULE at VERSION.` with the module and
-   version in backticks. A factual qualifier such as `(transitive dependency)`
+   version in backticks. For copied documentation, a concise `Material:` sentence
-   is permitted; do not describe dependency-discovery methods.
+   may identify the affected files and whether they were adapted or copied
+   without modification. A factual qualifier such as `(transitive dependency)`
+   is permitted. Limit optional identification prose to factual component and
+   material scope.
 2. **Upstream copyright statement or statements**, preserving their wording.
-   Put multiple statements in separate paragraphs. If the selected upstream
+   Put multiple statements in separate paragraphs. Include this field when the
-   source supplies no applicable statement, omit this field without inventing
+   selected upstream source supplies an applicable statement; otherwise, omit it.
-   one or adding an explanation of its absence.
 3. **SPDX license identifier or expression**, when applicable, using
    `SPDX-License-Identifier: EXPRESSION`.
 4. **License and notice links**, beginning `License and notices:`, separated
    by ` | `, and ending with a period. Label local standard texts by license
    name, such as `MIT` or `Apache 2.0`. Label upstream files by their actual
    filenames, such as `COPYRIGHT`, `LICENSE`, `NOTICE`, or `PATENTS`.
-5. **Source repository link**, using `[Source](COMMIT_URL).` with no `Source:`
+5. **Source repository link**, rendered exactly as `[Source](COMMIT_URL).`.
-   prefix or additional description.
 
 Use the upstream [attribution example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/attribution.md)
 to create the project’s `docs/oss/attribution.md`.
-Its three illustrative entries demonstrate a normal entry, omission of an
+The example illustrates omitted fields and multiple copyrights and licenses.
-unavailable copyright statement, and multiple copyrights and license texts.
 Replace the uppercase placeholders and illustrative URLs with actual component
 information. Local license links are relative to the destination
 `docs/oss/attribution.md`; copy the applicable texts into its `licenses/`
@@ -154,16 +154,15 @@ appropriate decision record, not the attribution document.
 ## License Texts And Upstream Links
 
 Link standard license texts to their local copies. Link project-specific
-notices to the upstream copies instead of storing them locally. Every upstream
+notices to their upstream copies. Every upstream repository or notice link must
-repository or notice link must identify the exact commit corresponding to the
+identify the exact commit corresponding to the
 imported version, including the selected source revision for copied material.
-Do not use moving branches or version tags as substitutes for that commit.
 
-Classify material by its contents, not its filename. An upstream `LICENSE`,
+Classify material according to its contents. An upstream `LICENSE`,
 `COPYING`, or similar file may contain project-specific notices or exceptions
 in addition to standard wording. Link both the local standard text and the
 commit-specific upstream file when needed. Make companion license texts directly
-reachable from the entry rather than leaving readers to infer their location.
+reachable from the entry.
 
 For project-specific license and attribution material, this policy accepts
 direct links to the applicable upstream texts as satisfying reproduction,

docs/policy/release.md

@@ -1,18 +1,18 @@
 # Release Policy
 
-**Base Policy Version:** 1.2
+**Base Policy Version:** 1.6
 
-**Last Updated**: 2026-09-26
+**Last Updated**: 2026-10-08
 
 ## Base Policy Template
 
-This document is the base template for the canonical release policy.
+When adopting this policy:
-Repositories that implement this policy should:
 
 1. Adapt its requirements to the application's release needs, keeping gates
    minimal and proportionate;
-2. Define the repository-specific commands, authoritative remote, primary
+2. Define the repository-specific commands, release toolchain, authoritative
-   branch, supported deliverables, and required build targets in `docs/release.md`;
+   remote, primary branch, supported deliverables, and required build targets in
+   `docs/release.md`;
 3. Add a gate only when it addresses a concrete risk that existing checks do
    not adequately cover, and record that reason in the adopted policy;
 4. Update the `Last Updated` field to the current date; and
@@ -30,6 +30,9 @@ This policy defines a proportionate workflow for validating and publishing an
 intended source revision under a fresh version. Releases should require little
 routine intervention, avoid repeated work, and preserve published contents.
 
+Adopt stronger verification or reproducibility requirements through an explicit
+project-specific decision justified by the intended audience and support needs.
+
 The repository-specific commands belong in `docs/release.md`. Historical release
 summaries belong in `docs/releases/`. The procedure must agree with the adopted
 policy and link to it rather than introduce additional release requirements.
@@ -59,9 +62,8 @@ the tagged source. The procedure must identify those deliverables and the
 responsibility of their automation. Published deliverables must be traceable
 to that source and identify the same version.
 
-Artifact delivery is a separate status. A successful tag push is not evidence
+Track source-release completion and artifact delivery separately. Report delivery
-that artifacts are available. Delivery failures do not reverse source-release
+failures and optional investigations under artifact-delivery status.
-success, and optional investigation must not delay release completion.
 
 ## Versioning And Compatibility
 
@@ -78,7 +80,8 @@ requires a deliberate update to the policy and procedure where needed.
 For releases at or after `v1.0.0`:
 
 - a major release may make intentional incompatible changes;
-- a minor release may add backward-compatible behavior; and
+- a minor release may add backward-compatible behavior or raise the Go consumer
+  minimum as described below; and
 - a patch release may make backward-compatible fixes.
 
 Before `v1.0.0`, a minor release may change a documented public, operational,
@@ -90,6 +93,36 @@ Additional compatibility promises and deliberate exceptions belong in the
 adopted policy or canonical contract documentation. Release notes explain
 changes; they do not redefine current compatibility contracts.
 
+## Consumer Minimum And Release Toolchain
+
+Distinguish the minimum toolchain supported for consumers from the toolchain
+maintainers use to build and validate a release. Record the consumer minimum in
+the language's standard metadata and explain its support meaning in canonical
+documentation. Define the selected release toolchain and its setup commands in
+`docs/release.md`. Toolchain selection and upgrade cadence are repository-specific
+choices.
+
+For Go repositories, normally declare the initial stable release of the selected
+series as the consumer minimum, such as `go 1.26.0`. Use a higher patch minimum
+when a dependency or an identified correctness fix requires it, and document
+the reason.
+
+For release-policy purposes, successful build and release validation on the
+selected Go patch release are sufficient to presume support across that Go
+series, subject to the declared consumer minimum and concrete evidence of
+incompatibility. Investigate specific compatibility concerns as they arise.
+
+Use the selected release toolchain for candidate validation and release builds,
+including CI jobs performing those tasks. A newer validation patch version alone
+leaves the consumer minimum unchanged.
+
+A minor release may raise the Go consumer minimum, including from one Go series
+to the next, both before and after `v1.0.0`. This is an explicit exception to the
+backward-compatibility requirement for minor releases. Patch releases preserve
+the consumer minimum. Explain an increase's impact and required consumer action
+in the release note. Other incompatible changes remain subject to the versioning
+rules above.
+
 ## Release Documentation And Preparation
 
 Every new release must include `docs/releases/<version>.md` in the tagged
@@ -97,15 +130,13 @@ source tree. Use the complete version tag as the filename and begin with a
 title containing the product name and that exact version.
 
 Include a short summary and any relevant compatibility impact or upgrade
-instructions. Keep the note proportionate to the change. Fixed sections and
+instructions. Choose sections suited to the release and keep the note
-explicit no-action boilerplate are not required. Existing historical notes
+proportionate to the change.
-need not be rewritten to adopt this format.
 
 Keep exact current contracts in their canonical documents and update affected
 documentation with the behavior change. Link to those documents from the note
-where useful. A release note must not substitute for current documentation.
+where useful. If annotated tags are used, derive their summary from the
-If annotated tags are used, derive their summary from the checked-in note
+checked-in note.
-rather than requiring a separately authored account of the same release.
 
 Include the release footer defined by the [OSS policy](oss.md#discoverability)
 in each new release document and preserve it on the hosted download page. The
@@ -113,12 +144,11 @@ release procedure defines the concrete URLs and publication mechanics. Prepare
 these links with the release note; they do not add a network check or approval
 gate.
 
-Version selection, release-note content, and retirement of completed roadmaps
+Handle version selection, release-note content, and retirement of completed
-are preparation responsibilities, not separate human approval gates. Preserve
+roadmaps during preparation. Preserve planned and deferred work and repair
-planned and deferred work and repair affected links when retiring roadmaps.
+affected links when retiring roadmaps. Reuse ordinary change review for
-Ordinary change review covers unintended files, credentials, and private data;
+unintended files, credentials, and private data. Scope release-content review
-do not repeat it as a release-specific sign-off. Ignored local files are not
+to the tagged source.
-prohibited merely because they exist: they are not included in the tagged source.
 
 ## Candidate Validation
 
@@ -208,7 +238,8 @@ release without replacing its contents or reusing its version.
 Maintain `docs/release.md` as a short, executable maintainer runbook. It must
 identify:
 
-1. prerequisites, primary branch, and authoritative remote;
+1. prerequisites, selected release toolchain, primary branch, and authoritative
+   remote;
 2. version and release-note preparation;
 3. one publication command with its selected local checks and automated guards;
 4. declared deliverables, required build targets, and automation responsibilities;

docs/policy/testing.md

@@ -1,24 +1,24 @@
 # Testing Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
 
-**Last Updated**: 2026-09-25
+**Last Updated**: 2026-09-27
 
 ## Base Policy Template
 
-This document is the base template for the canonical testing policy. Repositories that implement this policy should:
+When adopting this policy:
 
-1. Review the policy, remove any rules that must not apply to the current project, and add any additional rules that are required by the current project;
+1. Retain applicable rules and add project-specific requirements;
 2. Update the `Last Updated` field to the current date; and
 3. Remove this heading (`Base Policy Template`) and the associated text. 
 
-Most projects will not require any revisions to the substantive testing policy rules as written below.
+Most projects can adopt the substantive rules as written.
 
 ## Purpose
 
 Our tests exist to make **incorrect changes expensive and correct changes cheap**.
 
-We do not optimize for test count, line coverage, exhaustive isolation, or the fewest possible tests. We optimize for sufficient confidence in important behavior while imposing as little unnecessary friction as possible on future development.
+We optimize for sufficient confidence in important behavior while minimizing friction on future development.
 
 ## Every test has a cost
 
@@ -32,9 +32,9 @@ Evaluate that tradeoff at two levels:
 1. **Per test:** What realistic defect does this test detect, how consequential would that defect be, and is that protection worth the test's lifetime cost?
 2. **Across the suite:** Does this collection provide materially more confidence than a smaller, simpler suite would?
 
-Some friction is intentional. Tests should make dangerous changes—such as breaking compatibility, corrupting data, violating security boundaries, or reintroducing subtle bugs—require deliberate review. They should not make ordinary internal changes needlessly expensive.
+Some friction is intentional. Tests should make dangerous changes—such as breaking compatibility, corrupting data, violating security boundaries, or reintroducing subtle bugs—require deliberate review. Keep ordinary internal changes inexpensive.
 
-The cost of a test is not a reason to omit testing by default. Do not cite maintenance cost abstractly. When omitting a plausible test, be able to state why the protected failure is low-risk, already covered, obvious, reversible, or cheaper to detect elsewhere. For consequential, subtle, or difficult-to-observe behavior, the presumption should favor testing.
+Evaluate maintenance cost against the specific failure being protected. When omitting a plausible test, be able to state why the protected failure is low-risk, already covered, obvious, reversible, or cheaper to detect elsewhere. For consequential, subtle, or difficult-to-observe behavior, the presumption should favor testing.
 
 ## Default testing style
 
@@ -66,7 +66,7 @@ To the extent the following features are present in the application, prioritize
 6. Previously observed or plausible regressions.
 7. Representative integration and end-to-end workflows.
 
-A package-level contract is behavior relied upon by another package or major collaborator, not every observable detail of a package implementation.
+A package-level contract comprises behavior relied upon by another package or major collaborator.
 
 Choose tests for requested behavior and established contracts. Tests must not
 introduce new restrictions, guarantees, or threat scenarios merely because they
@@ -85,7 +85,8 @@ Do not add tests merely because a function, branch, or line exists. Do not add a
 
 ## Choose the right test boundary
 
-Test through the narrowest stable boundary that expresses the behavior clearly.
+Choose the narrowest stable boundary that expresses the behavior clearly and
+provides durable confidence with minimal incidental coupling.
 
 This is often the package API, but it may instead be:
 
@@ -93,22 +94,15 @@ This is often the package API, but it may instead be:
 - a package-level operation when several internal collaborators jointly produce the behavior; or
 - a larger integration boundary when correctness emerges from interaction with a real dependency.
 
-Do not force all behavior through oversized end-to-end tests. Do not test every private helper merely because it exists. Choose the boundary that gives durable confidence with the least incidental coupling.
-
 ## Test behavior, not implementation
 
-A test should protect a decision, contract, or invariant. A test must not memorialize the current implementation.
+A test should protect a selected decision, contract, or invariant.
 
-A test is suspect when its main purpose is to detect that someone:
+A test is suspect when it primarily detects changes to private constants or
+helpers, equivalent operation ordering, incidental formatting, equivalent
+algorithms, or internal structure that preserves behavior.
 
-- changed an internal constant;
+Behavioral tests should normally remain stable through internal refactoring that preserves the contract.
-- renamed or split a private helper;
-- reordered equivalent internal operations;
-- changed incidental formatting;
-- replaced one correct algorithm with another; or
-- refactored internal object structure without changing behavior.
-
-Refactoring should normally require no test edits unless the refactored structure is itself part of the contract.
 
 ## Expected effects of different changes
 
@@ -125,7 +119,7 @@ A test failing is not the same as a test needing to be edited. Many tests may co
 
 ## Separate mechanism from policy
 
-Configurable thresholds and defaults must not be duplicated throughout the test suite.
+Derive expectations from test-controlled configuration and relationships.
 
 For this example, assume the selected contract rejects a request to start more
 processes than a configured limit. Do not encode its production default indirectly:
@@ -161,18 +155,18 @@ limit solely to reproduce this example.
 
 The production default should be tested exactly only when its literal value is itself a public, operational, safety, protocol, or compatibility requirement.
 
-Apply the same rule to limits, timeouts, capacities, retry counts, and ranges: test relationships and behavior, not duplicated literals.
+Apply the same rule to limits, timeouts, capacities, retry counts, and ranges: test relationships and behavior.
 
 For established concurrency limits, distinguish these behaviors where the contract requires them:
 
 1. **Configuration handling:** values are accepted or rejected according to the selected contract.
 2. **Runtime enforcement:** observed peak concurrency never exceeds the configured limit.
 
-Use a test-controlled limit and measure the behavior relative to that limit. Do not merely assert today's default value.
+Use a test-controlled limit and measure the behavior relative to that limit.
 
-## Avoid semantic duplication across layers
+## Assign each behavior a test owner
 
-Each behavior should have a clear test owner. Where these layers exist:
+Where these layers exist, assign ownership as follows:
 
 - Parser tests own parsing cases.
 - Validator tests own validation rules.
@@ -182,7 +176,7 @@ Each behavior should have a clear test owner. Where these layers exist:
 - CLI tests own argument and configuration mapping.
 - End-to-end tests prove that representative assembled workflows work.
 
-Higher-level tests should not repeat every lower-level case. A single intentional policy change should not require unrelated edits across many test files.
+Give each layer its distinct responsibility and keep expectation updates localized to the contract being changed.
 
 ## Use test doubles deliberately
 
@@ -203,12 +197,9 @@ Mocks are appropriate when the contract includes facts such as:
 - an expensive API is called no more than once; or
 - a security audit event is emitted.
 
-Do not use mocks merely to isolate every object or reproduce the implementation's call graph.
-
 ## Go-specific guidance
 
-Select techniques according to the behavior and risk being tested. The following
+Select techniques by behavior and risk:
-are options, not a checklist that every package or application must satisfy:
 
 - table-driven tests for meaningful behavioral categories and boundaries;
 - `t.TempDir()` for real filesystem behavior;
@@ -218,19 +209,17 @@ are options, not a checklist that every package or application must satisfy:
 - integration tests where correctness depends on component interaction; and
 - a small number of representative end-to-end tests when assembled workflows expose meaningful risks not adequately covered at narrower boundaries.
 
-Avoid exact error-string assertions unless the wording is itself contractual. Prefer `errors.Is`, `errors.As`, typed errors, or structured error fields.
+Prefer `errors.Is`, `errors.As`, typed errors, or structured error fields. Use exact error-wording assertions only when the wording is contractual.
 
-At CLI boundaries, prefer exit classifications, structured output, and the smallest stable semantic fragment needed to identify the error. Do not snapshot complete diagnostic wording unless it is contractual.
+At CLI boundaries, prefer exit classifications, structured output, and the smallest stable semantic fragment needed to identify the error. Use complete diagnostic snapshots only when the wording is contractual.
 
 Golden-file updates must require an explicit local flag. CI must not update golden files automatically, and reviewers must inspect the semantic diff before accepting an update.
 
-Keep tests readable and direct. Test helpers and fixture frameworks must earn their own maintenance cost; do not build elaborate test infrastructure for small or isolated needs.
+Keep tests readable and direct. Size test helpers and fixture frameworks to the maintenance benefit they provide.
 
 ## Coverage
 
-Coverage is a diagnostic, not a target.
+Use coverage to locate untested critical branches and unexpectedly weak packages. Evaluate test quality through meaningful behavioral protection and choose coverage according to risk.
-
-Use it to find untested critical branches and unexpectedly weak packages. Do not write low-value tests solely to increase a percentage, and do not infer test quality from coverage alone.
 
 Pure domain logic will often warrant higher coverage than CLI wiring or external adapters. Uneven coverage is acceptable when it reflects risk.
 
@@ -238,33 +227,30 @@ Pure domain logic will often warrant higher coverage than CLI wiring or external
 
 A bug fix should normally include a regression test that fails before the fix and passes afterward.
 
-Retain the test when the defect could realistically recur and its consequences justify the ongoing cost. Prefer the narrowest durable test of the violated contract or invariant; do not preserve accidental implementation details from the original bug.
+Retain the test when the defect could realistically recur and its consequences justify the ongoing cost. Prefer the narrowest durable test of the violated contract or invariant.
 
-Not every historical bug requires a permanent test. If the underlying design has made recurrence impossible, the test has become redundant, or a stronger invariant test now subsumes it, remove or consolidate it.
+Remove or consolidate a test when the underlying design has made recurrence impossible, its protection is redundant, or a stronger invariant test subsumes it.
 
 ## Deleting or rewriting tests
 
-Tests are maintained code, not permanent historical artifacts.
+Delete or rewrite tests when maintenance cost exceeds their continuing
-
+protective value.
-Delete or rewrite a test when its maintenance cost exceeds the confidence it provides.
 
 Strong candidates include tests that:
 
 - require updates after harmless internal changes;
-- directly assert private constants without protecting a real contract;
+- assert incidental private constants or snapshot large amounts of incidental output;
-- duplicate the same policy across several layers;
 - verify mock choreography rather than outcomes;
-- snapshot large amounts of incidental output;
+- duplicate policy across layers, retest trivial helpers covered by package
-- test trivial private helpers already exercised through stable package behavior;
+  behavior, or protect risks covered more effectively elsewhere;
-- protect risks already covered more effectively elsewhere;
 - are flaky, misleading, obsolete, or disproportionately expensive to diagnose; or
 - no longer correspond to a plausible failure mode.
 
-Several brittle tests may encode one genuine requirement. Replace them with one durable behavior-level or invariant test rather than preserving all of them.
+Several brittle tests may encode one genuine requirement. Consolidate them into one durable behavior-level or invariant test.
 
 ## Reviewing a proposed test
 
-Use the following questions when the value, boundary, or durability of a proposed test is not self-evident. Significant test additions should be reviewable against them, but written answers are not required for every routine test.
+Use the following questions when a proposed test needs closer evaluation. Significant test additions should be reviewable against them; written answers are optional for routine tests.
 
 1. Which requested behavior or established contract does it protect, and what realistic defect would violate it?
 2. How likely and consequential is that defect, and is it already protected elsewhere?
@@ -278,10 +264,9 @@ A test suite is sufficient when:
 
 - important requested behavior and established contracts are protected against realistic, consequential failures;
 - boundaries and component interactions have coverage where they introduce meaningful risks not protected elsewhere;
-- failures provide useful signal rather than redundant noise;
+- failures provide useful, distinct signals;
-- legitimate internal changes usually do not require test edits; and
+- tests usually remain stable through legitimate internal changes; and
 - additional tests would mostly repeat existing protection or preserve inconsequential implementation details.
 
-Sufficiency is a risk judgment, not a coverage percentage, test count, or required
+Reassess sufficiency as the application, its users, and the consequences of
-mix of testing techniques. Reassess it as the application, its users, and the
+failure evolve.
-consequences of failure evolve.

examples/licensing/policy-attribution.md

@@ -0,0 +1,13 @@
+## Standard Repository Policies
+
+Material: policy documents under `docs/policy/`, adapted for this repository.
+
+Copyright (C) 2026 Eric Rakestraw
+
+SPDX-License-Identifier: CC-BY-SA-4.0
+
+License and notices: [CC BY-SA 4.0](licenses/CC-BY-SA-4.0.txt) |
+[COPYRIGHT](https://gitea.maximumdirect.net/eric/policy/src/commit/UPSTREAM_COMMIT/COPYRIGHT) |
+[LICENSE](https://gitea.maximumdirect.net/eric/policy/src/commit/UPSTREAM_COMMIT/LICENSE).
+
+[Source](https://gitea.maximumdirect.net/eric/policy/src/commit/UPSTREAM_COMMIT).