# 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 template examples do not require this repository to acquire
application interfaces or infrastructure.

| Task | Read |
| --- | --- |
| Change a policy | The affected policy, its related policies, and the [documentation policy](policy/documentation.md). |
| Change adoption or provenance guidance | The [adoption guide](adoption.md), [OSS policy](policy/oss.md), and root [COPYRIGHT](../COPYRIGHT). |
| Change licensing examples | The [OSS policy](policy/oss.md), [COPYRIGHT](../COPYRIGHT), and affected examples. |
| Add or update reference license texts | The [reference collection README](oss/licenses/README.md) and the selected publisher or recorded upstream source. |

## 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 so they are not copied into notices.

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, not treated as published
URLs or missing local dependencies. No application build or new test suite is
needed for prose-only changes. Retain upstream formatting in verbatim license
texts even where it would trigger whitespace warnings.

Pin upstream reference links to commits that contain the referenced files. New
assets can use local links within this repository until a containing commit is
available; do not invent a future hash or publish changes merely to obtain one.
Before publication, confirm that public reference links are accessible. This is
change validation, not a recurring downstream release gate.