Document public policy adoption and licensing

docs/adoption.md

@@ -0,0 +1,116 @@
+# 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. To edit the upstream templates themselves, use the
+[contributor guide](development.md).
+
+## 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; a moving branch
+name is not an adoption baseline. No package manager or automatic update service
+is required.
+
+Preserve existing downstream decisions and unrelated changes. Adoption is a
+local customization task, not authorization to add every capability, document,
+restriction, or release gate mentioned in the templates.
+
+## Copy And Customize
+
+1. Copy applicable documents from `docs/policy/` to the same downstream location.
+   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, rather than filling an empty outline.
+2. Tailor architecture to the actual project. Preserve the author's selected
+   license and existing application contracts. Do not infer new product behavior
+   from policy examples.
+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. 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
+```
+
+## Attribute Copied Policies
+
+Use the [canonical attribution entry](../examples/licensing/policy-attribution.md)
+in the downstream `docs/oss/attribution.md`. It is an entry fragment to insert
+beneath that document's existing title, not an additional document title.
+
+- 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.
+Do not populate the downstream `examples/` directory with this collection.
+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.
+
+## Update Deliberately
+
+Compare the previously recorded upstream files with a selected newer revision.
+Apply relevant changes while preserving local decisions; do not overwrite
+customized documents wholesale or treat every upstream recommendation as a new
+local requirement.
+
+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.
+Do not change a source reference to a version that was merely reviewed.
+
+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.