Align policies with the standard and record their provenance

AGENTS.md

@@ -1,5 +1,6 @@
-Please review `docs/development.md` for initial orientation in this repository
-and follow its task-specific reading guide.
+Start with `docs/development.md` for orientation and use its policy 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.

COPYRIGHT

@@ -16,4 +16,8 @@ but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 GNU Lesser General Public License for more details.
 
-Third-party code and assets are subject to their respective license terms.
+Policy documents copied or 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.
+
+Third-party code and assets are subject to their respective license terms.

docs/development.md

@@ -1,9 +1,7 @@
 # Development
 
-This is the contributor entry point for Promptkit, a reusable Go library. All
-contributors must read the
-[architecture policy](policy/architecture.md) before making changes. Agents must
-also follow the [agent policy](policy/agents.md) before recommendations or work.
+This is the contributor entry point for Promptkit, a reusable Go library.
+Use the Policy Reading Guide below to select policies applicable to the task.
 
 ## Initial Orientation
 
@@ -16,18 +14,27 @@ Before starting work:
 4. keep documentation limited to implemented behavior unless an accepted
    decision or temporary roadmap explicitly owns future work.
 
-Start with:
+## Policy Reading Guide
 
-- the [architecture policy](policy/architecture.md) for library boundaries,
-  dependency direction, invariants, and non-goals;
-- the [internal component overview](internal/overview.md) for the current
-  package and component inventory;
-- the [documentation policy](policy/documentation.md) before changing
-  documentation;
-- the [testing policy](policy/testing.md) before adding, rewriting, or deleting
-  tests; and
-- the [release policy](policy/release.md) and [release procedure](release.md)
-  for version and publication work.
+| 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 library 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.
 
 ## Task-Specific Reading Guide
 

docs/oss/attribution.md

@@ -1,5 +1,21 @@
 # Open Source Attribution Notices
 
+## Standard Repository Policies
+
+Material: policy documents under `docs/policy/` and the Policy Reading Guide in
+`docs/development.md`, adapted for this repository; root `AGENTS.md`, copied
+without modification from upstream `agents/AGENTS.md`.
+
+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/d84a38ebab26f048cafbe59a2246700c35d29843/COPYRIGHT) |
+[LICENSE](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/LICENSE).
+
+[Source](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843).
+
 ## Promptkit OpenRouter Catalog
 
 Selected module: `gitea.maximumdirect.net/eric/promptkit-backend-openrouter/v2`

docs/policy/agents.md

@@ -1,19 +1,20 @@
 # Agent Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.3
 
-**Last Updated:** 2026-09-23
+**Last Updated**: 2026-09-27
+
+**Upstream Source:** [agents.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/agents.md)
 
 ## Purpose
 
-Agents must follow these house rules before recommending, planning, or
-implementing repository changes.
+Agents must read and follow these rules.
 
 ## Implementation Discipline
 
-Write the simplest idiomatic code that satisfies the user's request.
-Simplify the mechanism, not the user's choices. Do not implicitly strengthen
-requirements, restrictions, or guarantees.
+**KEY PRINCIPLES:** Write the simplest idiomatic code that satisfies the user's
+request. Do not implicitly strengthen requirements, restrictions, or guarantees
+beyond what the user actually requested.
 
 **Keep implementation machinery proportionate.** Use straightforward,
 idiomatic code and introduce only the machinery needed to support the requested
@@ -28,41 +29,48 @@ operator and caller choice where policy has not been established. If an
 additional restriction appears advisable, present it as a decision rather than
 silently implementing it.
 
+**Do not invent guarantees.** Do not strengthen public contracts, guarantees,
+or invariants beyond those expressly requested by the user.
+
+**Use the standard library.** For example: in almost every case, the best
+approach to copying files is to use the standard library. Writing custom code to
+implement power-loss protection at the application level, or to guard against
+bad actors with privileged and concurrent access to the host's filesystem,
+is wasteful, unnecessary, and not idiomatic. Stick to the simple, standard, and
+idiomatic approach unless another path is expressly requested by the user.
+
+**An implementation detail is not repository policy.** Tests and documentation
+must not elevate incidental behavior into a durable guarantee or restriction
+unless that behavior was expressly selected as part of the contract.
+
+## Promptkit Contract Authority
+
+The following clarification preserves Promptkit's established distinction
+between implementation choices and authorized contracts.
+
 A correctness constraint must follow from the requested behavior or an
 established invariant, not from the convenience of the chosen implementation.
 Explain the specific failure it prevents and why a less restrictive
 implementation cannot satisfy the contract.
 
-**An implementation detail is not repository policy.** Tests and documentation
-must not elevate incidental behavior into a durable guarantee or restriction
-unless that behavior was expressly selected as part of the contract. Existing
-explicit contracts remain authoritative; changing or weakening one requires a
-deliberate decision rather than being inferred from this principle.
-
-Agent-authored plans, tests, documentation, and prior implementations are not
-evidence that an additional restriction was deliberately approved. Identify the
-authorizing requirement or decision; when that authority is unclear, surface
-the ambiguity rather than treating repetition as approval.
-
-**Do not invent guarantees.** Do not strengthen public contracts, guarantees,
-or invariants beyond those expressly requested by the user.
-
-**Use the standard library.** Prefer simple, idiomatic standard-library
-implementations when they satisfy the requested behavior. Do not add custom
-power-loss protection or defenses against privileged concurrent filesystem
-actors unless expressly required. Preserve existing repository contracts.
+Existing explicit contracts remain authoritative; changing or weakening one
+requires a deliberate decision. Agent-authored plans, tests, documentation,
+and prior implementations are not evidence that an additional restriction was
+deliberately approved. Identify the authorizing requirement or decision; when
+that authority is unclear, surface the ambiguity rather than treating repetition
+as approval.
 
 ## 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:
 
@@ -70,10 +78,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
-   staged or unstaged work.
-4. Review `git diff --staged` and run appropriate checks for the change. Do not
-   repeat checks already passed for unchanged content merely to create a commit.
+   only when every included change belongs to that unit. Preserve unrelated
+   staged and unstaged work.
+4. Review `git diff --staged` and run appropriate checks for the change. Reuse
+   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,15 +1,41 @@
 # Architecture Policy
 
-**Base Policy Version:** 1.0
+**Base Policy Version:** 1.3
 
-**Last Updated:** 2026-09-23
+**Last Updated**: 2026-09-27
 
-## Purpose
+**Upstream Source:** [architecture.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/architecture.md)
 
-This document defines Promptkit's current high-level architecture and the
-durable boundaries that implementation changes must preserve. The
-[internal component overview](../internal/overview.md) inventories concrete
-implemented packages without redefining these rules.
+## Purpose And Ownership
+
+The adopted policy defines Promptkit's purpose and the architectural
+constraints contributors must follow. It owns system boundaries, responsibility
+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.
+
+## Architectural Approach
+
+Hexagonal architecture is strongly recommended, including encapsulating external
+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. Choose interfaces
+and package layout to serve the application's actual boundaries. Use adapters
+for collaborators with external integration responsibilities.
+
+## Adopted Constraints And Implemented Structure
+
+Architectural constraints govern current and future development. Record
+implemented structure accurately, proposals and implementation status in the
+roadmap, and significant decisions and rationale in ADRs. Describe a target
+structure as implemented when its changes land.
+
+Constraints must reflect deliberately selected requirements and decisions.
+Do not promote incidental implementation choices into architectural invariants.
 
 ## System Shape
 
@@ -155,3 +181,21 @@ state.
 Do not list planned packages as implemented components. When implementation
 introduces a package, update the internal inventory and the owning contract or
 subsystem document in the same change.
+
+## Trust Boundaries And Threat Scope
+
+Where useful, state the trust boundaries and threat scenarios relevant to the
+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.
+
+Threat exclusions define the scope of the adopted requirements. Base defenses
+and guarantees on those requirements and raise unsettled scope for a deliberate
+decision under the [agent policy](agents.md).
+
+Keep this discussion proportionate to the application. A separate threat
+assessment or security document is optional when adopting this template.
+For this library, the framework format and integration documents own credential
+supply and external contracts; internal documents own implementation mechanisms.
+Consumer-specific filesystem and security policy remains outside Promptkit's
+boundary as described above.

docs/policy/documentation.md

@@ -1,157 +1,139 @@
 # Documentation Policy
 
-**Base Policy Version:** 1.5
+**Base Policy Version:** 1.11
 
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-27
+
+**Upstream Source:** [documentation.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/documentation.md)
 
 ## Purpose
 
-This policy assigns each Promptkit documentation topic to one canonical owner.
-Its goal is to keep documentation for this reusable Go library accurate,
-concise, discoverable, and resistant to drift for consumers, contributors,
-maintainers, integrators, and coding agents.
+This policy assigns each documentation topic to one canonical owner. Its goal is
+to keep this library's documentation accurate, concise, discoverable, and resistant
+to drift for users, operators, developers, integrators, and LLM coding agents.
 
 ## Core Rules
 
 ### One Canonical Owner
 
-Each authoritative fact belongs in one document or source form. A non-owning
-document may give a short, stable summary for orientation, but it must link to
-the canonical owner instead of repeating exact contracts.
+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
+for volatile details.
 
-Volatile details include exported declarations, accepted inputs, defaults,
-schemas, file names, paths, error identities, retry behavior, and runtime
-guarantees. If readers could reasonably treat a statement as a contract,
-maintain its exact definition only in the owning source.
+Volatile details include commands, flags, configuration fields and defaults,
+module keys, schemas, file names, paths, status codes, retry behavior, and
+runtime guarantees. If readers could reasonably treat a statement as a
+contract, maintain it only in the owning document.
 
-### Current State, Decisions, And Future Work
+### Current And Future Behavior
 
 Outside `docs/roadmap/`, documentation describes implemented behavior only.
 Partial features may be described only to their implemented boundary.
 
-An accepted architecture decision may describe an approved direction before it
-is implemented, but acceptance is not evidence that the behavior exists.
-Current-state documents change when the implementation lands. Temporary
-roadmaps own future work, sequencing, and implementation status; they do not
-replace durable policies or current contracts.
+Architectural constraints may govern future changes. Describe current structure
+from implemented behavior.
+
+ADRs may record an accepted architectural decision before implementation. The
+roadmap owns implementation status and sequencing until the decision is
+implemented. Current architecture, user, operator, integration, and internal
+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. Consumer guidance should not expose incidental implementation
-detail. Contributor documentation should link to public contracts and durable
-policies instead of restating them.
+its owned topic. Keep user and operator docs focused on using and operating the
+application. Developer docs should link to user-facing and external contracts
+for their definitions.
 
-### Links
+### Examples
 
-Use descriptive link text and repository-relative links for repository
-documents. Link to the canonical owner rather than to a duplicate summary.
-Check every added or changed link and repair or remove links when their target
-moves or is retired.
+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 for complete copyable files.
 
-### Examples And Code Fences
-
-Complete copyable files belong in `examples/` when maintained examples exist.
-Documentation may use the smallest illustrative snippet needed for its owned
-topic, but should link to a maintained example instead of embedding a second
-complete copy.
-
-Examples must be valid, secret-free, and tested where practical. Commands,
-imports, and Go snippets must match the implemented library. Use a language tag
-on fenced code blocks and make clear when a fragment is illustrative rather
-than directly runnable.
+Examples must be valid, secret-free, and tested where practical. Commands and
+configuration used in documentation should match the application.
 
 ### Security And Privacy
 
 Documentation and examples must not contain real credentials, private keys,
-private environment dumps, sensitive source material, or private
-infrastructure details unless intentionally public. Document secret-handling
-mechanisms, not secret values.
+private environment dumps, sensitive source material, or private infrastructure
+details unless intentionally public. Document secret-handling mechanisms, not
+secret values.
 
 ## Canonical Ownership
 
 | Topic | Canonical owner | Owned content | Content owned elsewhere |
 | --- | --- | --- | --- |
-| Project orientation | `README.md` | What Promptkit is, its current usability, module identity, license summary, a minimal successful quickstart, and links onward. | Exact API contracts, contributor procedures, architecture detail, and release steps. |
-| Contributor workflow | `docs/development.md` | Task-oriented reading guide, local workflow, validation commands, and repository hygiene. | Architecture rules, API semantics, subsystem behavior, and release procedure. |
-| Current architecture | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, package boundaries, invariants, and non-goals. | Concrete component inventory, implementation mechanics, contributor procedures, decision history, and future work. |
-| Agent policy | `docs/policy/agents.md` | Agent implementation discipline, proportionality, idiomatic simplicity, local commit authorization and discipline, and rules against inventing restrictions, guarantees, or repository policy. | Public contracts, architecture, testing, and contributor procedures. |
-| Documentation organization | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and document lifecycle. | Library architecture or runtime behavior. |
-| Testing policy | `docs/policy/testing.md` | Test philosophy, risk-based sufficiency, test boundaries, doubles, coverage guidance, regression policy, and test maintenance. | Subsystem behavior, exact public contracts, subsystem-specific test inventories, and implementation plans. |
-| Release policy | `docs/policy/release.md` | Versioning, compatibility, release-note requirements, validation obligations, immutability, recovery, and adoption scope. | Executable commands, publication mechanics, and historical release summaries. |
-| Licensing and attribution policy | `docs/policy/oss.md` | Project licensing conventions, attribution format, text and notice-link rules, discoverability, maintenance, and concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
-| Project grant | `COPYRIGHT` | Project identity, holders and years, SPDX expression, grant, warranty disclaimer, and third-party statement. | Complete license texts and component attribution. |
-| Project license texts | `LICENSE` | Complete project license and incorporated companion texts. | General licensing policy and dependency attribution. |
-| Upstream attribution | `docs/oss/attribution.md` | Component names, copyright statements, license identification, and license, notice, and source links. | General policy and complete standard texts. |
-| Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim texts shared by attribution entries. | Project-specific notices, attribution prose, and policy interpretation. |
-| Release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, concrete publication guards and commands, verification, and recovery steps. | Release-policy requirements, public API semantics, and historical summaries. |
+| 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, 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, boundaries, invariants, safety properties, and non-goals. | Concrete package inventory, implementation mechanics, contributor procedures, decision history, future work. |
+| 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 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, 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` | 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, grant, warranty disclaimer, and third-party statement. | Complete license texts 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` | 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 applicable entries. | Project-specific upstream notices, attribution prose, and policy interpretation. |
+| 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. |
+| 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 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` | 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, 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. |
+| 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 copyable or runnable files. | Field-by-field reference, command reference, prose explanation. |
 | Exact exported Go API | Go declarations and GoDoc, as APIs are implemented | Exported names, signatures, types, values, errors, and exact behavioral contracts. | Task-oriented consumer walkthroughs, implementation details, and future API proposals. |
 | Framework file formats | `docs/formats.md` | Prompt-definition and profile YAML fields, schema references, defaults, validation modes, built-in profiles, credentials, and file-to-request precedence. | Exported Go declarations, outbound wire behavior, internal parsing mechanics, and application configuration. |
-| Consumer guidance | `docs/consumers/`, when consumer workflows require dedicated guidance | Task-oriented use of implemented public APIs, minimal examples, and consumer responsibilities. | Exact exported declarations and internal mechanics. |
-| Durable integration contracts | `docs/integrations/`, when integrations exist | External formats and protocols, compatibility behavior, and upstream or downstream responsibilities. | Internal transformations and public Go declarations. |
-| Release-note history | `docs/releases/` | Mandatory version-matched historical summaries for releases made under the adopted release policy; the note at the immutable tag records that release. | Current APIs, behavior, formats, compatibility contracts, and release procedures. |
-| Implemented component inventory | `docs/internal/overview.md` | Current packages and components, their implemented responsibilities, and links to focused internal documents. | Normative architecture, contributor workflow, external contracts, and proposed components. |
-| Internal subsystem behavior | Other files under `docs/internal/`, when a subsystem needs durable detail | Implementation flow, internal collaborators and state transitions, package-local guarantees and failures, and relevant tests. | Global architecture invariants, public API definitions, and future package plans. |
-| Architectural decision history | `docs/adr/`, when repository-local decisions require records | Significant decisions, context, alternatives, rationale, consequences, and supersession history. | Current behavior reference, implementation status, and task sequencing. |
-| Temporary feature roadmaps | `docs/roadmap/`, while planned work needs coordination | Proposed or accepted scope, sequencing, gates, and implementation status. | Implemented behavior reference and durable decision rationale. |
-| Complete copyable artifacts | `examples/` | Valid inputs, Go programs, and other files intended to be copied or run. | Field-by-field reference, exact API declarations, and prose explanation. |
 
-Conditional owners do not require placeholder files or directories. Create a
-consumer, integration, release, subsystem, ADR, roadmap, or example document
-only when the corresponding implemented interface, release, decision, planned
-effort, or maintained artifact exists.
+Create supporting documents for existing interfaces and responsibilities when
+substantive content is available.
 
 ## Boundary Rules
 
 ### Orientation
 
-The README owns project orientation. The development guide routes
-contributors. Architecture owns normative structure. The internal overview
-owns the current concrete component map. These documents may link to one
-another but must not maintain parallel package or behavior descriptions.
+Link among orientation, architecture, and internal documents; maintain each
+package or behavior description in its canonical owner.
 
 ### Public Contracts And Implementation
 
-Go declarations and GoDoc own exact exported API contracts once those APIs
-exist. Consumer and integration documents explain how to use those contracts
-for a task. Internal documents explain how Promptkit implements them. Internal
-documentation may identify a public type or external format as a dependency,
-but must link to its canonical definition rather than restate it.
+Go declarations and GoDoc own exact exported Go API contracts. The
+[framework format reference](../formats.md) owns prompt, profile, and schema
+formats; integration documents own external wire behavior. Consumer and
+internal documents link to those owners for exact definitions.
 
-The [framework format reference](../formats.md) owns exact prompt, profile, and
-schema-file contracts. Integration documents own external wire formats.
+### Releases
 
-### Release Documentation
+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 record history
+at immutable tags. Maintain current behavior in its canonical documentation,
+update it with the corresponding behavior changes, and keep release procedures
+consistent with adopted policy.
 
-The [release policy](release.md) owns release requirements; the
-[repository release procedure](../release.md) owns their concrete execution.
-Version-matched checked-in notes are required for future releases under that
-policy. The source tag is the release identity, and the note in its immutable
-tree is the historical summary; annotated tag messages complement that record.
+### Project Licensing And Upstream Attribution
 
-Release notes do not own current API or behavior contracts. Link to the
-canonical owners for details instead of reproducing those contracts. Published
-notes are not disposable guidance and must not be replaced under the same
-version. Corrections belong in a subsequent release.
+README and release documents link to the canonical licensing and attribution
+materials under the [OSS policy](oss.md). The release procedure owns URL
+construction and publication mechanics.
 
-Adoption is prospective. Previously published tags and historical notes retain
-their original records and are not reformatted or rewritten to satisfy the new
-requirements.
+### Contracts And Implementation
 
-### Project Licensing And Attribution
-
-The [OSS policy](oss.md) owns licensing conventions, the attribution House
-Format, and README/release navigation. COPYRIGHT owns the project grant;
-LICENSE supplies complete texts. Component-specific information belongs in
-attribution entries, not parallel README or release-note notice lists. The
-release procedure owns concrete footer URLs and publication mechanics.
+Integration and API documents define externally observable shapes and
+semantics. Internal documents explain how this application implements or consumes those
+contracts. Internal docs may name a field, file, or protocol to identify a
+dependency, but must link to its canonical contract for the definition.
 
 ### Security Topics
 
 This policy owns what documentation and examples may contain. Architecture owns
-library security boundaries and invariants. Public declarations and integration
-documents own consumer-visible security contracts. Internal documents own
-implementation mechanisms only.
+library security boundaries. Public declarations and integration documents own
+consumer-visible contracts; internal documents own implementation mechanisms.
 
 ## Architecture Decision Records
 
@@ -166,31 +148,35 @@ Use sequentially numbered ADR filenames such as
 6. alternatives considered;
 7. consequences.
 
-Use one of these statuses:
+Treat the decision content of an accepted ADR as immutable. When a decision
+changes, create a new ADR and update the earlier ADR's status to superseded.
+Rejected architectural alternatives belong in the ADR; rejected product ideas
+belong in the roadmap.
 
-- **Proposed:** the decision is under consideration and may change;
-- **Accepted:** the decision is approved, whether or not implementation is
-  complete;
-- **Rejected:** the proposed decision was considered and not adopted;
-- **Superseded:** a later accepted ADR replaces the accepted decision.
+## Maintenance
 
-A proposed ADR transitions to Accepted or Rejected. An Accepted ADR transitions
-to Superseded only when a later Accepted ADR replaces it. An ADR may be created
-as Accepted when the decision has already been made.
+When behavior changes, update its canonical owner in the same change. If
+ownership moves, remove the old definition and replace it with a link where
+navigation remains useful.
 
-Treat the decision content of an Accepted ADR as immutable. A changed decision
-requires a later ADR rather than a rewrite of the accepted record. A Superseded
-ADR must link to its replacement, and the replacement must link back. Rejected
-architectural alternatives belong in the ADR; rejected feature ideas belong in
-a roadmap when they need to be retained.
+Before completing documentation work:
+
+- verify affected behavior and examples;
+- check commands, flags, fields, defaults, schemas, and paths against their
+  implementation;
+- keep unimplemented behavior in the roadmap, subject to the ADR exception;
+- remove stale references and validate links;
+- confirm that non-owning documents summarize and link rather than redefine;
+- confirm that no secrets or sensitive private data were added.
+
+## Promptkit Documentation Scope
+
+Promptkit is a Go library, so exported GoDoc and framework formats replace
+application CLI, configuration, operations, and HTTP-service owners. Reading
+triggers belong in the development guide, not this topic map.
 
 ## Document Lifecycle
 
-Create durable current-state documentation with the implementation it
-describes. Update its canonical owner in the same change when behavior changes.
-If ownership moves, remove the old definition and leave a link where navigation
-remains useful.
-
 Roadmaps are temporary coordination documents. When their work is complete,
 record completion, move any still-useful decisions or contracts to their
 durable owners, update incoming links, and archive or remove the roadmap
@@ -200,13 +186,9 @@ second current-state reference.
 Retain release notes as historical records under the release policy. Do not
 apply temporary-roadmap retirement rules to published release notes.
 
-Before completing documentation work:
-
-- verify affected behavior and examples;
-- check commands, imports, declarations, defaults, schemas, and paths against
-  their implementation;
-- keep unimplemented behavior in a roadmap, subject to the ADR exception;
-- validate links and fenced examples;
-- confirm non-owning documents summarize and link rather than redefine;
-- remove stale or unsupported claims; and
-- confirm that no secrets or sensitive private data were added.
+For Promptkit ADRs, retain the existing Proposed, Accepted, Rejected, and
+Superseded statuses. Proposed records may become Accepted or Rejected;
+Accepted records may become Superseded, with links between the earlier record
+and its replacement. Records may be created as Accepted when the decision has
+already been made. These lifecycle rules preserve existing local document
+semantics.

docs/policy/meta.md

@@ -0,0 +1,37 @@
+# Policy Set Provenance
+
+**Base Policy Version:** 1.0
+
+**Last Updated**: 2026-09-27
+
+**Upstream Source:** [meta.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/meta.md)
+
+## 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).
+
+## Adoption Record
+
+The Upstream Source links record the adoption performed on 2026-09-27, not the
+original provenance of older manually copied files. Historical roadmap evidence
+in Promptkit commit `5843cee` records upstream
+`dafa823981004d4d58a5eb1b59a84ffebbd979da` for the previous OSS, documentation,
+and release-policy comparison. Exact original baselines for agents,
+architecture, and testing remain uncertain. Git retains the earlier local
+customizations and their history.

docs/policy/oss.md

@@ -1,135 +1,227 @@
 # Open Source Licensing And Attribution Policy
 
-**Base Policy Version:** 1.2
+**Base Policy Version:** 1.8
 
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-27
 
-Adapted from the standard policy; see [provenance and licensing](../oss/attribution.md#standard-repository-policies).
+**Upstream Source:** [oss.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md)
 
 ## Purpose And Scope
 
-This policy defines Promptkit's project licensing conventions and House Format
-for upstream attribution. It covers relevant incorporated or distributed
-components, including transitive dependencies and copied code, documentation,
-or assets. Treatment follows the component's terms and actual use, not merely
-its direct-dependency status or common ownership. Development tools do not
-automatically require attribution.
+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,
+documentation, or assets.
+Determine treatment from the component's terms and actual use.
 
-Promptkit is a Go library with an author-selected LGPL-3.0-or-later grant in
-[COPYRIGHT](../../COPYRIGHT). Its public source repository is
-`https://gitea.maximumdirect.net/eric/promptkit`; it publishes source-only Go
-module releases through annotated tags, not binaries or separate hosted release
-pages. The [release procedure](../release.md) owns publication mechanics.
+Consulting development guidance or using tooling alone does not require an
+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 House Format does not establish license compatibility or resolve every
-obligation arising from use or distribution. Adoption does not relicense
-existing material or override third-party terms.
+The baseline is a publicly available source repository with releases published
+alongside it. The format is independent of language, forge, and build system.
+It does not require attribution for every development tool, establish license
+compatibility, or resolve every obligation arising from use or distribution.
 
 ## Canonical Locations
 
 The [documentation policy](documentation.md) assigns ownership:
 
-- `COPYRIGHT`: project name, holders and years, SPDX expression, grant,
-  warranty disclaimer, and statement about third-party material.
-- `LICENSE`: complete, unmodified project license texts, including incorporated
-  companion text. Promptkit includes LGPLv3 followed by GPLv3.
+- `COPYRIGHT`: project name, copyright statements, SPDX expression, grant,
+  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`: canonical component entries.
-- `docs/oss/licenses/`: complete, verbatim standard dependency texts, including
-  companions where applicable. Shared texts can serve multiple entries.
+- `docs/oss/licenses/`: complete, verbatim standard and applicable companion texts.
 
-Keep explanations and project-specific notices outside standard texts. Preserve
-distinct versions and exceptions, using recognizable filenames.
+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
+license texts and preserve distinct versions and exceptions.
+
+## Upstream Reference Examples
+
+Use the commit-pinned upstream examples to create actual project notices.
+Retain their links and keep the example collection upstream; keep applicable
+license texts locally as specified above.
 
 ## Project Licensing
 
-The house defaults for new projects are GPL-3.0-or-later for applications and
-LGPL-3.0-or-later for libraries. An author's explicit choice takes precedence
-without an exception rationale, extra approval, or compensating controls.
-Promptkit retains its selected library grant; do not infer different licenses
-for individual packages or relicense existing code by adopting this policy.
+Unless the author specifies otherwise, use **GPL version 3 or later**
+(`GPL-3.0-or-later`) for applications and **LGPL version 3 or later**
+(`LGPL-3.0-or-later`) for libraries. An author's explicit choice takes precedence:
+for example, a one-off script may use MIT. Such a choice requires no exception
+rationale, additional approval, or compensating controls under this policy.
 
-Keep COPYRIGHT, LICENSE, SPDX expressions, and README descriptions consistent.
-Use accurate holders and years; do not assume the maintainer owns every
-contribution or advance years automatically. Update grant, disclaimer, and text
-references together when the author deliberately changes licensing. Preserve
-third-party terms and required existing notices. No blanket per-file header
-requirement is introduced.
+These defaults guide new license selection. Adopting this policy does not
+relicense existing code or override third-party terms. Preserve an existing
+license unless the author deliberately changes it. For mixed-purpose projects,
+follow the author's selected scope rather than inferring different licenses for
+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.
+Use verified project names, contribution years, and copyright holders.
+For another selected license, adapt the grant, SPDX expression, disclaimer, and
+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
+`LICENSE`; the LGPL incorporates the GPL terms. Keep the texts unmodified and
+place project-specific statements in `COPYRIGHT`. For the default grants, the
+grant and SPDX expression in `COPYRIGHT` must expressly identify `or-later`;
+follow the author’s choice if a different grant is selected.
+
+For other licenses, provide their complete text and any required project-specific
+fields; the standard reference collection remains unchanged. Keep `COPYRIGHT`,
+`LICENSE`, SPDX expressions, and README descriptions consistent with the actual
+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
 
-Each component entry contains five fields:
+Begin `docs/oss/attribution.md` with `# Open Source Attribution Notices`,
+followed directly by component entries. These comprise the complete document.
 
-1. Project name, normally as the heading.
-2. Upstream copyright statements, preserving their wording.
-3. Applicable SPDX license identifier or expression.
-4. License and notice links.
-5. Source repository link at the exact imported commit.
+Each entry presents these five fields in order, with blank lines between them:
 
-These are fields, not a line limit. Include multiple statements or links where
-needed. Do not invent absent copyright statements or SPDX identifiers. Describe
-nonstandard terms through their linked text, preserve alternatives and
-exceptions, and record a selected option when relevant. Do not silently resolve
-an unsettled licensing choice.
+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. For copied documentation, a concise `Material:` sentence
+   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. Include this field when the
+   selected upstream source supplies an applicable statement; otherwise, omit it.
+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**, rendered exactly as:
+
+   ```markdown
+   [Source](COMMIT_URL).
+   ```
+
+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`.
+The example illustrates omitted fields and multiple copyrights and licenses.
+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/`
+directory. Do not copy example entries for components the project does not use.
+
+These are five fields, not a line limit. Omit the SPDX field when no applicable
+identifier exists; identify nonstandard terms through the linked text. Preserve
+licensing alternatives and exceptions, and record a selected option when
+relevant through the factual license identification. Do not invent an identifier
+or silently resolve an unsettled licensing choice.
+
+Keep entries factual. Do not add agent-authored explanations of license
+expressions, file-level license scope, research performed, retained source
+notices, or compliance conclusions. Avoid filler such as "none is invented
+here" and embellished link labels such as "upstream LICENSE", "additional
+patent grant", or "at the imported commit". Preserve actual required upstream
+content; this rule excludes editorial additions, not required notices. Policy
+interpretation and exception reasoning belong in the adopted OSS policy or an
+appropriate decision record, not the attribution document.
 
 ## License Texts And Upstream Links
 
-Link standard texts to local copies. Link project-specific notices to the
-upstream copies at the exact commit corresponding to the imported version or
-copied material. Moving branches and version tags are not substitutes for
-commit-specific component links.
+Link standard license texts to their local copies. Link project-specific
+notices to their upstream copies. Every upstream repository or notice link must
+identify the exact commit corresponding to the
+imported version, including the selected source revision for copied material.
 
-Classify material by content, not filename: an upstream LICENSE or COPYING can
-mix standard text with project-specific notices or exceptions. Link both when
-needed. Make incorporated companion texts directly reachable from each entry.
+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.
 
-For project-specific license and attribution material, direct upstream links
-are accepted as satisfying reproduction, inclusion, or copy requirements under
-the adopted house interpretation. Do not add local-copy requirements or request
-repeated approval solely because a license uses those terms. This concerns
-notice reproduction, not other concrete obligations such as marking modified
-files or supplying corresponding source. Central entries do not authorize
-stripping required notices from incorporated source.
+For project-specific license and attribution material, this policy accepts
+direct links to the applicable upstream texts as satisfying reproduction,
+inclusion, or copy requirements. This is the adopted house interpretation.
+Agents must apply it without adding local-copy requirements or seeking repeated
+approval solely because a license uses those terms.
+
+This interpretation concerns notice reproduction. Concrete obligations such as
+marking modified files or supplying corresponding source receive their own
+applicable treatment. Preserve required notices already present in incorporated
+source files; the central attribution entry does not authorize stripping them.
 
 ## Discoverability
 
-End README with friendly statements linking to the actual grant in COPYRIGHT
-and to the attribution document. Each new checked-in release note ends with
-links whose visible text is `COPYRIGHT | LICENSE | ATTRIBUTION`, using absolute
-URLs at the release's immutable tag or corresponding immutable source revision.
-These release links differ from imported-component links, which use commits.
+End the project's README with two friendly statements linking to its actual
+grant in `COPYRIGHT` and the attribution document. For example, for a project
+with the stated license:
 
-The release procedure owns concrete URL construction. If a hosted download page
-is deliberately introduced, reuse the checked-in note and preserve its footer
-there. This convention does not require a new hosted page, downloadable license
-assets, source bundles, or another packaging format. Do not maintain duplicate
-notice lists.
+```markdown
+PROJECT_NAME is licensed under the [LGPL v3.0 or later](COPYRIGHT).
+
+[Open Source attribution notices](docs/oss/attribution.md) are available.
+```
+
+Each new checked-in release document and its hosted download page must end
+with links whose visible text is `COPYRIGHT | LICENSE | ATTRIBUTION`. Use absolute
+URLs to those files at the release's immutable tag or corresponding immutable source
+revision so the links work in both locations. This release navigation is distinct
+from upstream component links, which must use the imported commit.
+
+Reuse the checked-in release document as the hosted release body where supported.
+The release procedure owns concrete URLs and publication mechanics for delivering
+the links through the selected channel. Do not maintain duplicate notice lists.
+These conventions do not by themselves require separate downloadable license
+assets, source bundles, or a different binary package format.
 
 ## Maintenance And Exceptions
 
-Update attribution in the change that adds, removes, upgrades, copies, or changes
-distribution of a relevant component. Inspect the selected source's actual
-licenses/notices rather than assuming they are unchanged. Update entries,
-commit links, and texts together; retain history through Git.
+Update project licensing statements together when the author changes the grant
+or its scope. Update upstream notices in the change that adds, removes, upgrades,
+copies, or changes the distribution of a relevant component. Check the selected source's license
+and notices rather than assuming they are unchanged. Update affected entries,
+commit links, and texts; retain historical versions through Git.
 
-Review affected statements, standard-text fidelity, and link destinations during
-ordinary change review. Future-release URLs can be checked against candidate
-paths before the tag exists remotely. Do not add publication-time network checks,
-CI polling, recurring legal sign-offs, mandatory scanners, or an SBOM just to
-implement this policy. Attribution maintenance is preparation, not a release gate.
+Check affected statements, faithful standard-text copies, and link destinations
+as part of ordinary change review. For a future release tag, check intended file
+paths against the candidate source; the tag need not resolve remotely before
+publication. Do not add publication-time network checks, CI polling, recurring
+legal sign-offs, mandatory scanners, or a full software bill of materials merely
+to implement this policy.
 
-Raise exceptions only for concrete obligations or unresolved rights questions
-the House Format does not address, including distribution-specific issues.
-Record their selected treatment here or in the affected entry and resolve them
-before the affected use/distribution, without reopening settled choices.
-Common ownership is not a blanket exception. Adapted standard policy documents
-retain their upstream documentation license and identify modifications in their
-provenance entry; this does not change Promptkit's library grant.
+Use the House Format routinely. Raise an exception only for a concrete obligation
+or unresolved rights question it does not address, including any arising from a
+particular distribution channel. Record the issue and selected treatment in the
+adopted OSS policy or an appropriate decision record. Attribution entries
+contain the resulting factual identification and required material, without
+repeating that reasoning. Resolve the issue before the affected use or
+distribution without reopening settled choices.
+Common ownership of projects is neither required nor a blanket exception.
 
-The maintainer-provided standard policy templates are internal and non-public.
-Their attribution entry identifies that source in prose and retains the
-applicable license locally; do not link to or require publication of the
-internal repository.
+Apply the formatting convention prospectively. Do not rewrite published tags,
+notes, binaries, or checksums to retrofit it. Address actual omissions deliberately
+under the applicable terms and the [release correction policy](release.md#immutability-and-failure-recovery).
+Ordinary attribution maintenance and release links are preparation work, not new
+release approval gates.
 
-Apply conventions prospectively. Do not rewrite published tags, notes, binaries,
-or checksums to retrofit formatting. Handle actual omissions deliberately under
-applicable terms and the [release correction policy](release.md#immutability-and-failure-recovery).
+## Promptkit Adoption
+
+Promptkit retains its LGPL-3.0-or-later library grant in
+[COPYRIGHT](../../COPYRIGHT). Adapted policy documentation has the separate
+scope identified there and in [attribution](../oss/attribution.md).
+
+Promptkit publishes source-only Go module tags on Gitea, with no binaries or
+separate hosted download page. The [release procedure](../release.md) owns
+publication and concrete footer URLs. The hosted-page guidance applies if such
+a channel is deliberately introduced; it does not require creating one.

docs/policy/release.md

@@ -1,30 +1,229 @@
 # Release Policy
 
-**Base Policy Version:** 1.2
+**Base Policy Version:** 1.4
 
-**Last Updated:** 2026-09-26
+**Last Updated**: 2026-09-27
 
-## Purpose And Adoption Scope
+**Upstream Source:** [release.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md)
 
-This policy owns Promptkit's release requirements and compatibility rules.
-The [release procedure](../release.md) owns the commands used to satisfy them.
-This scoped adoption applies to releases prepared after its adoption on
-2026-09-23. Published tags and historical notes are not rewritten to retrofit
-the new note format.
+## Purpose
 
-## Release Model And Compatibility
+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.
 
-Promptkit publishes source-only Go module releases from committed, pushed
-`main` candidates through annotated `vMAJOR.MINOR.PATCH` tags. It publishes
-no binaries, hosted releases, or other artifacts and uses maintainer-run
-validation rather than hosted CI. Versions must be unused locally and on
-`origin`; the existing procedure accepts stable version tags only.
+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.
 
-Before v1, minor releases may change the public API and patches preserve
-compatibility within their minor line, subject to the catalog-data provision
-below. Release notes must identify compatibility impact, public API changes,
-and required consumer action. The source tag identifies the exact release;
-the checked-in note at that tag records its historical summary.
+## Release Model And Completion
+
+A source release identifies one exact committed source revision through an
+immutable version tag and a version-matched, checked-in release note. The
+primary release branch is `main` unless the adopted policy specifies otherwise.
+The procedure must name the authoritative publication remote.
+
+A successful push of the intended tag, with its source commit available on the
+authoritative primary branch, completes the release. The source commit may be
+pushed before the tag or published together with it through an atomic push.
+The procedure must choose and document the supported approach.
+
+Release commands must finish at successful publication. They must not wait for
+or poll CI, require successful CI status, inspect downloadable artifacts, or
+check consumer installation or Go module availability as completion gates.
+A failed or ambiguous push requires resolving the authoritative remote state
+before declaring success or retrying; successful pushes do not require a
+separate remote read-back gate.
+
+Repositories may publish source only. Additional binaries, images, packages,
+checksums, or other declared deliverables may be published asynchronously from
+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.
+
+Track source-release completion and artifact delivery separately. Report delivery
+failures and optional investigations under artifact-delivery status.
+
+## Versioning And Compatibility
+
+Stable releases use Semantic Versioning in the form `vMAJOR.MINOR.PATCH`, with
+no leading zeroes. Prereleases require an explicit adopted policy defining
+their format and use.
+
+The selected version must be unused locally and on the authoritative remote.
+Do not require queries to every configured remote or publication service.
+A version known to have already been published must not be reused, even if the
+normal guards do not inspect that channel. Adding a distribution channel
+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 patch release may make backward-compatible fixes.
+
+Before `v1.0.0`, a minor release may change a documented public, operational,
+configuration, data, integration, or compatibility contract when the release
+note explains the impact and required consumer action. A patch release must
+not intentionally break those contracts within its minor line.
+
+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.
+
+## Release Documentation
+
+Every new release must include `docs/releases/<version>.md` in the tagged
+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. Use the Promptkit section structure below and keep the note
+proportionate to the change.
+
+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. If annotated tags are used, derive their summary from the
+checked-in note.
+
+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
+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.
+
+Handle version selection, release-note content, and retirement of completed
+roadmaps during preparation. Preserve planned and deferred work and repair
+affected links when retiring roadmaps. Reuse ordinary change review for
+unintended files, credentials, and private data. Scope release-content review
+to the tagged source.
+
+## Candidate Validation
+
+Provide one publication command that validates the final committed candidate,
+checks publication state, and publishes the intended refs. A validation-only
+mode or command may be provided for diagnosis, but must not be a required step
+before publication repeats the same checks.
+
+Run the complete deterministic, offline default test suite once for the final
+candidate, following the [testing policy](testing.md). For repositories that
+publish builds, verify the required build targets. Select those targets for
+the application's actual support commitments; native testing on each platform
+and access to particular hardware are not default release prerequisites.
+
+Additional gates must address a concrete risk that the existing checks do not
+adequately cover. Do not automatically require linting, race testing, module
+hygiene audits, documentation audits, credential scans, example validation, or
+expanded platform matrices solely because they are possible. Retain such
+checks when their distinct protection justifies their cost. A one-time migration
+check must not silently become a permanent release requirement.
+
+Release tests must not require real credentials, mutable application services,
+paid APIs, provider probes, or inference calls. The procedure may describe dependency
+preparation separately from offline validation.
+
+Avoid duplicate validation across release phases. Successful checks for the
+same final candidate need not be repeated solely to satisfy another phase;
+any reuse must clearly apply to that exact candidate. Persistent validation
+caches are not required. If the candidate changes, validate the new candidate.
+Cheap publication-state checks may be repeated immediately before pushing
+because local or remote state may have changed during validation.
+
+Automate mechanical guards. Human review gates are strongly disfavored: add one
+only through an explicit project-specific policy decision explaining the
+concrete risk and why ordinary change review or automation is insufficient.
+Do not add routine confirmations for checks the command can perform itself.
+
+## Publication Guards
+
+Automate the checks needed to publish the intended source under a fresh version:
+
+- the version has the adopted format and is unused locally and on the
+  authoritative remote;
+- the worktree and index are clean on the primary release branch;
+- the source being published is the exact candidate that passed validation,
+  including its matching release note;
+- the remote primary branch already identifies that candidate, or an atomic
+  source/tag push will advance it to that candidate without discarding remote
+  history; and
+- the tag identifies the validated candidate and only the intended refs are
+  published.
+
+Fetch the authoritative branch and tag state as needed for these checks.
+Do not force branch or tag updates to bypass a failed guard. Publish explicit
+refs rather than all local tags. Do not require CI success, publication-service
+availability checks, or a separate manual confirmation for each guard.
+
+## Immutability And Failure Recovery
+
+Published version tags and published contents are immutable. Do not move,
+overwrite, recreate, or delete a published tag, or replace a published artifact,
+checksum, signature, provenance statement, or release note under that version.
+The checked-in note at the immutable tag is that release's historical record.
+
+If validation fails before publication, correct and commit the candidate and
+rerun the publication command. If a push fails or its outcome is ambiguous,
+inspect the authoritative remote before retrying. Remove an unpublished local
+tag only after confirming it was never published or used by a release channel.
+An unavailable remote leaves publication status unknown; do not overwrite a tag
+to resolve uncertainty.
+
+Transient network, authentication, CI, or consumer-availability failures do not
+by themselves require a new version. Asynchronous delivery may be retried from
+the same immutable tag. Missing artifacts may be published later, provided
+existing published contents are not replaced and the additions remain consistent
+with the tagged source and any already-published checksum manifest. If that
+cannot be achieved, publish a new version.
+
+A defect requiring changes to published source or contents requires a corrected
+commit, a new semantically appropriate version, a matching release note, and
+the release procedure again. Leave the original release intact. A channel's
+yank, deprecation, or advisory mechanism may warn consumers away from a defective
+release without replacing its contents or reusing its version.
+
+## Repository Release Procedure
+
+Maintain `docs/release.md` as a short, executable maintainer runbook. It must
+identify:
+
+1. prerequisites, 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;
+5. the successful-push completion point and separately reported delivery status;
+   and
+6. failure handling, ambiguous-push recovery, and asynchronous delivery retries.
+
+Use copyable commands where practical. Keep optional diagnostics and consumer
+verification clearly optional. The procedure must not turn preparation work,
+ordinary change review, or post-publication investigation into additional
+release gates.
+
+## Promptkit Release Configuration
+
+The release-note requirements were adopted on 2026-09-23 and licensing
+navigation on 2026-09-26. Apply them prospectively; previously published notes
+and tags retain their original records.
+
+Promptkit publishes source-only Go modules from main to origin on Gitea, using
+annotated stable SemVer tags. It has no binaries, hosted download pages, or
+asynchronous deliverables. The source commit is pushed through main before the
+tag. The [release procedure](../release.md) owns commands and recovery.
+
+The existing publication script requires Summary, Compatibility, Upgrade, and
+Changes headings beneath a title of `# Promptkit vMAJOR.MINOR.PATCH`. State
+“No action required” or “None” where appropriate. This retained local structure
+matches the automated release-note guard; changing it is separate work.
+
+The [publication script](../../scripts/release.sh) runs the
+[local checks](../../scripts/release-check.sh) once for the final committed
+candidate: race-enabled tests, vet, three offline consumer examples, tracked
+Go formatting, Markdown links, module/workspace hygiene, whitespace, and a
+credential-pattern scan. These protect concurrency, assembled library use,
+source distribution, and documentation integrity. A separate ordinary test run
+or standalone build is not an additional release gate. Candidate, tag, and
+synchronized-main checks remain automated. No CI or module-availability wait
+is required. Licensing footer URLs are preparation work, not a network gate.
 
 ## Catalog Profile Compatibility
 
@@ -51,101 +250,3 @@ migrations.
 
 Catalog adoption and release validation remain local and offline. They do not
 probe provider endpoints, request model lists, or make inference calls.
-
-## Release Documentation
-
-Every new release must include `docs/releases/<version>.md` in the tagged
-source, using the complete tag as the filename. Its title contains Promptkit
-and that exact version. Use this structure:
-
-```markdown
-# Promptkit vMAJOR.MINOR.PATCH
-
-This release ...
-
-## Summary
-
-## Compatibility
-
-## Upgrade
-
-## Changes
-```
-
-State “No action required” or “None” where appropriate rather than omitting a
-section. Keep exact current contracts in their canonical documents and link
-to them. Update affected canonical documentation in the same candidate.
-
-These notes are historical records, not optional disposable guidance. Published
-release-note contents must not be replaced under the same version. Corrections
-belong in a subsequent release. Annotated-tag messages complement the checked-in
-note: generate the annotation from that note and the validated commit rather
-than maintaining a second summary.
-
-## Validation And Publication
-
-New release notes prepared after the 2026-09-26 OSS-policy adoption end with
-the [licensing footer](oss.md#discoverability). The release procedure owns
-absolute, release-pinned URLs. This is prospective preparation work, not a new
-approval or network-validation gate; historical notes and tags are not reformatted.
-
-The [publication script](../../scripts/release.sh) runs the
-[local checks](../../scripts/release-check.sh) once for the final candidate.
-Retain clean-candidate, synchronized-main, unused-version, module-hygiene,
-release-note structure, and tag-target checks. Publish only the selected tag
-ref. Changing the candidate requires fresh validation. No provider endpoint
-probes or inference calls are release checks.
-
-Release-note content and retirement of completed roadmaps are preparation
-responsibilities, not separate human sign-off gates. Preserve planned and
-deferred work and repair links. Ordinary change review covers unintended files,
-secrets, and private data; do not repeat it as a release-specific approval.
-
-A successful tag push to origin completes the release. Never wait for CI to
-finish or succeed. CI results, remote read-back, and Go module availability
-are informational follow-ups, not completion gates. An ambiguous push result
-requires confirming publication on origin, not waiting for CI.
-
-## Immutability And Failure Recovery
-
-Never move, replace, recreate, or delete a published tag or replace published
-release contents. If validation fails before publication, correct the candidate,
-rerun the complete checks, and repeat the publication guards. Remove an
-unpublished local tag only after confirming it was not published.
-
-If publication or subsequent investigation reveals a defect, leave the
-published release intact. Correct the defect on main, select a new patch or
-other semantically appropriate version, write its matching release note, and
-repeat the complete procedure. If publication status is uncertain, inspect
-the authoritative remote before deciding whether a tag is unpublished; do not
-overwrite it to retry.
-
-Transient network, authentication, CI, or module-availability failures do not
-by themselves warrant a new version. Investigate separately and publish a
-corrective release only when published contents actually need changing.
-
-## Policy Exceptions And Deliberate Scope
-
-This adoption follows the maintainer-approved lean workflow rather than every
-base-policy guard:
-
-- Collision checks concern origin, the authoritative publication destination,
-  rather than every configured remote. Local and origin tag checks, synchronized
-  main, and an explicit selected-ref push protect the actual release channel.
-- Automated local validation and publication-state checks replace manual
-  mechanical inspections and separate human sign-offs. Ordinary change review,
-  editorial responsibility for release notes, and roadmap housekeeping remain;
-  repeating them as approvals would add friction without distinct protection.
-- Successful tag publication completes this source-only release. CI can be slow
-  or unreliable, and module availability depends on external services. Neither
-  is a completion gate. Local candidate validation and explicit tag-target
-  checks protect publication; ambiguous push results are resolved against origin.
-  Actual defects are corrected in a new release, never by replacing a tag.
-
-Ignored local files are not prohibited merely because they exist: they are not
-included in the tagged commit. The clean-candidate guard and ordinary review of
-tracked changes protect the published contents.
-
-The catalog profile provision preserves an already approved compatibility
-boundary; it does not extend volatility to backend definitions or runtime
-contracts. Further release-governance changes require deliberate approval.

docs/policy/testing.md

@@ -1,43 +1,32 @@
 # Testing Policy
 
-**Base Policy Version:** 1.0
+**Base Policy Version:** 1.3
 
-**Last Updated:** 2026-09-23
+**Last Updated**: 2026-09-27
+
+**Upstream Source:** [testing.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/testing.md)
 
 ## 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
 
-Testing is not an unqualified good. Every test imposes both an immediate cost and a continuing lifetime cost.
-
-A test must be:
-
-- written and reviewed;
-- understood by future maintainers and coding agents;
-- executed in maintainer-run validation;
-- diagnosed when it fails;
-- updated when legitimate behavior changes;
-- maintained as fixtures, APIs, and dependencies evolve; and
-- removed or rewritten when it becomes redundant, brittle, misleading, or obsolete.
-
-Tests also create cognitive and architectural friction. They can constrain refactoring, duplicate policy, slow feedback loops, add noise to failures, and cause harmless implementation changes to require unrelated edits across the suite.
+Every test has an immediate and continuing cost: writing, review, execution,
+diagnosis, fixture maintenance, and updates when legitimate behavior changes.
+Tests can also constrain refactoring, duplicate policy, and add failure noise.
 
 A test is warranted only when the confidence it provides justifies these costs.
-
-Apply this cost-benefit analysis at two levels:
+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?
 
-The preferred test suite is a **lean suite that provides sufficient confidence in the risks that matter, without redundant or low-value tests**. We seek sufficient confidence with the least unnecessary testing friction, not the fewest possible tests.
+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.
 
-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.
-
-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
 
@@ -51,6 +40,12 @@ Use a **classical/Detroit-style** approach:
 
 Examples of appropriate seams include clocks, randomness, subprocesses, remote APIs, object storage, email, and paid LLM calls.
 
+## Promptkit Test Boundaries
+
+Promptkit is a library without a CLI or hosted CI. The execution requirements,
+facade test ownership, public error guidance, and offline consumer examples
+below tailor the standard to that boundary.
+
 ## Test execution requirements
 
 Promptkit currently uses maintainer-run validation rather than hosted CI.
@@ -110,7 +105,7 @@ Use each test type where it protects a distinct risk:
 
 ## What deserves tests
 
-Prioritize tests for:
+To the extent the following features are present in the application, prioritize tests for:
 
 1. Public and package-level contracts.
 2. Domain rules and important invariants.
@@ -118,17 +113,29 @@ Prioritize tests for:
 4. Failure handling, cancellation, retries, recovery, and partial success.
 5. Serialization, schemas, compatibility, and round trips.
 6. Previously observed or plausible regressions.
-7. Representative integration and consumer workflows.
+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.
 
-For behavior involving **data integrity, destructive operations, compatibility, security, concurrency, idempotency, or recovery**, presume that durable tests are required unless the behavior is already credibly protected at another layer.
+Choose tests for requested behavior and established contracts. Tests must not
+introduce new restrictions, guarantees, or threat scenarios merely because they
+could be asserted. Follow the [agent policy](agents.md) when deciding whether a
+behavior belongs to the contract; current implementation behavior alone is not
+sufficient authority.
+
+For established behavior involving **data integrity, destructive operations,
+compatibility, security, concurrency, idempotency, or recovery**, favor durable
+tests for realistic failures whose consequences warrant protection. Identify
+the failure and the existing contract it would violate. These categories call
+for attention, not an automatic test inventory or permission to strengthen the
+application's guarantees. Account for protection already provided at other layers.
 
 Do not add tests merely because a function, branch, or line exists. Do not add a test when the same meaningful risk is already adequately protected elsewhere.
 
 ## 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:
 
@@ -136,30 +143,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 consumer-workflow 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—not memorialize the current implementation.
+A test should protect a selected decision, contract, or invariant.
 
-Before adding or retaining a test, ask:
+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.
 
-> What realistic defect would this test catch?
-
-A test is suspect when its main purpose is to detect that someone:
-
-- changed an internal constant;
-- 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.
-
-A test can be factually correct and still have negative value. Accurately describing current behavior is not enough; the protected behavior must be important enough to justify the future friction.
+Behavioral tests should normally remain stable through internal refactoring that preserves the contract.
 
 ## Expected effects of different changes
 
@@ -176,13 +168,13 @@ 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.
 
-The following fragments are illustrative rather than standalone Go programs.
-Do not encode an internal concurrency limit indirectly:
+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:
 
 ```go
-// Production policy:
+// Production default:
 const maxConcurrency = 4
 
 // Brittle test:
@@ -200,37 +192,40 @@ require.NoError(t, runner.Start(limit))
 require.ErrorIs(t, runner.Start(limit+1), ErrTooMuchConcurrency)
 ```
 
-The test should prove:
+For this selected contract, the test should prove:
 
 - the configured limit is accepted; and
 - one beyond the configured limit is rejected.
 
+Rejection is not a general requirement for concurrency control. If the selected
+contract queues excess work or limits active workers while accepting larger
+batches, test that behavior instead. Do not add rejection or a configurable
+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 concurrency limits, test both kinds of behavior when relevant:
+For established concurrency limits, distinguish these behaviors where the contract requires them:
 
-1. **Configuration enforcement:** invalid or excessive requested values are handled correctly.
+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, assign ownership as follows:
 
 - Parser tests own parsing cases.
 - Validator tests own validation rules.
 - Domain tests own transformations and invariants.
-- Boundary tests own external integration behavior.
+- Adapter tests own external integration behavior.
 - Orchestrator tests own coordination and failure propagation.
-- Consumer-workflow tests prove that representative assembled library use
-  works.
+- External-package root tests own the public Go facade contract.
+- Consumer-workflow tests prove that representative assembled library use works.
 
-Higher-level tests should not repeat every lower-level case. A single intentional policy change should not require unrelated edits across many test files.
-
-Tests that are individually reasonable may still be collectively redundant. Evaluate the marginal value of each additional test in light of the protection already provided by the rest of the suite.
+Give each layer its distinct responsibility and keep expectation updates localized to the contract being changed.
 
 ## Use test doubles deliberately
 
@@ -251,111 +246,78 @@ 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
 
-Use:
+Select techniques by behavior and risk:
 
 - table-driven tests for meaningful behavioral categories and boundaries;
 - `t.TempDir()` for real filesystem behavior;
 - `httptest.Server` for realistic HTTP interactions;
-- fuzz tests for parsers, normalization, path handling, and broad input spaces;
+- fuzz tests when exploring broad input spaces, such as parsers or path handling, adds useful protection beyond representative cases;
 - golden files only when the complete output is intentionally stable;
 - integration tests where correctness depends on component interaction; and
-- a small number of representative consumer-workflow tests.
+- 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 public API boundaries, prefer stable error identity, structured values, and
-the smallest semantic fragment needed to identify the failure. Do not snapshot
-complete diagnostic wording unless it is contractual.
+the smallest semantic fragment needed to identify the failure. Use complete
+diagnostic snapshots only when the wording is contractual.
 
-Golden-file updates must require an explicit local flag. Ordinary validation
-runs must never update golden files automatically, and maintainers must inspect
-the semantic diff before accepting an update.
+Golden-file updates must require an explicit local flag. Ordinary validation runs must never 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 facade wiring or
-external adapters. Uneven coverage is acceptable when it reflects risk.
-
-Increasing coverage is valuable only when the newly covered behavior protects a meaningful risk at an acceptable cost.
+Pure domain logic will often warrant higher coverage than facade wiring or external adapters. Uneven coverage is acceptable when it reflects risk.
 
 ## Regression tests
 
 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 a test when its maintenance cost exceeds the confidence it provides.
+Delete or rewrite tests when maintenance cost exceeds their continuing
+protective value.
 
 Strong candidates include tests that:
 
 - require updates after harmless internal changes;
-- directly assert private constants without protecting a real contract;
-- duplicate the same policy across several layers;
+- assert incidental private constants or snapshot large amounts of incidental output;
 - verify mock choreography rather than outcomes;
-- snapshot large amounts of incidental output;
-- test trivial private helpers already exercised through stable package behavior;
-- protect risks already covered more effectively elsewhere;
+- duplicate policy across layers, retest trivial helpers covered by package
+  behavior, or protect risks 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.
-
-Deleting a low-value test can improve the quality of the suite by reducing noise, maintenance burden, and friction around legitimate change.
+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. What realistic defect would it catch?
-2. How likely is that defect?
-3. How consequential would it be?
-4. Is the behavior already protected elsewhere?
-5. At which layer should this behavior be owned?
-6. Does the test assert a durable contract or an incidental implementation detail?
-7. Could the implementation be refactored without changing the behavior and without editing this test?
-8. What should cause this test to fail?
-9. What legitimate changes should not cause this test to fail?
-10. What ongoing maintenance, execution, and diagnostic cost will the test impose?
-11. Is there a smaller or more direct test that protects the same risk?
-
-Do not add the test when its expected lifetime cost exceeds its expected protective value.
-
-When deciding not to test plausible behavior, record or be able to explain why the risk is low, already protected, obvious, reversible, or cheaper to detect elsewhere.
+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?
+3. What is the narrowest stable boundary that can test it clearly?
+4. Would a correct internal refactor or a change to an incidental default require test edits?
+5. Does its confidence justify its maintenance, execution, and diagnostic cost, or would a smaller test suffice?
 
 ## Definition of sufficient
 
 A test suite is sufficient when:
 
-- important contracts and invariants are protected;
-- meaningful boundaries and failure modes are exercised;
-- realistic and consequential regressions are credibly protected against silent recurrence;
-- behavior involving data integrity, destructive operations, compatibility, security, concurrency, idempotency, and recovery is credibly protected;
-- important external boundaries have realistic integration coverage;
-- representative complete workflows are tested;
-- failures provide useful signal rather than redundant noise;
-- legitimate internal changes usually do not require test edits; and
+- 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, distinct signals;
+- 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 or test count.
-Reassess it as the library, its consumers, and the consequences of failure
-evolve.
-
-The governing rule is:
-
-> Test heavily where failure is consequential, subtle, or difficult to detect after the fact. Test lightly where failure is obvious, reversible, and inexpensive—and retain no test whose lifetime cost exceeds the confidence it provides.
+Reassess sufficiency as the application, its users, and the consequences of
+failure evolve.

docs/roadmap/future.md

@@ -38,13 +38,8 @@ consumers.
 
 ## Ideas
 
-### Remaining Standard Policy Alignment
-
-Review the internal standard's architecture and testing clarifications about
-adopted constraints, threat scope, and tests that must not invent contracts.
-Adapt relevant guidance to Promptkit's library boundaries without introducing
-new runtime restrictions or release gates. This is separate from the completed
-licensing-documentation alignment.
+No ideas are currently awaiting selection. Active feature work belongs in its
+focused roadmap rather than this catalog.
 
 ## Entry Format
 

docs/roadmap/policy.md

@@ -1,162 +0,0 @@
-# Standard Policy Alignment
-
-**Status:** Accepted scope; not yet implemented.
-
-## Purpose
-
-Align Promptkit's adopted policies with Standard Repository Policies, establish
-reproducible adoption provenance, and make future updates straightforward.
-Use upstream language verbatim wherever differences are non-substantive.
-Retain local differences only for a substantive project-specific reason.
-
-This roadmap defines the target and required changes. A separate implementation
-plan may divide the work into stages; this document does not implement policy.
-
-## Comparison Baselines
-
-The reviewed Promptkit baseline is
-`dc6fd2752dfa3f4e49e97af26681e5f2ee8fc2e2`, including the maintainer's factual
-attribution cleanup.
-
-The selected upstream revision is
-`d84a38ebab26f048cafbe59a2246700c35d29843`.
-Use its [adoption and update guide](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/adoption.md)
-and policy documents as the fixed implementation reference. Do not silently
-switch to a newer upstream revision during this work.
-
-No current local policy has `Upstream Source` metadata. Historical roadmap
-evidence in Promptkit commit `5843cee` identifies upstream
-`dafa823981004d4d58a5eb1b59a84ffebbd979da` as the comparison baseline for the
-last OSS, documentation, and release-policy alignment. Exact original adoption
-baselines for agents, architecture, and testing cannot be established from the
-reviewed records. Version labels are not proof of an exact source revision.
-
-The new adoption records must identify the revision actually incorporated by
-this update, not claim to reconstruct uncertain historical provenance.
-
-## Target End State
-
-### Common Wording And Local Authority
-
-Adopt applicable upstream text verbatim, removing template instructions and
-substituting required project metadata. Do not retain local paraphrases,
-formatting preferences, or redundant explanations merely because they already
-exist. This applies to agent and release policies even where their substantive
-requirements need no change.
-
-Preserve deliberate local decisions and project-specific requirements. Keep
-necessary customizations localized and their reasons identifiable in the
-relevant policy; no separate exception registry or approval mechanism is needed.
-Architecture requires substantial customization for Promptkit's actual library
-boundaries. A shorter upstream formulation is not permission to weaken an
-established local contract, nor is existing wording alone proof of a deliberate
-exception.
-
-Local adopted policies remain authoritative. Future upstream revisions become
-local policy only through deliberate adoption.
-
-### Policy Inventory And Changes
-
-| File under `docs/policy/` | Current → selected base version | Target |
-| --- | --- | --- |
-| `meta.md` | Absent → 1.0 | Add upstream origin, local authority, adoption provenance, and discovery links. Keep detailed adoption procedure upstream. |
-| `agents.md` | 1.1 → 1.3 | Use upstream wording for equivalent rules. Preserve substantive local safeguards concerning established contracts, authority for restrictions, and unrelated work only where the upstream text does not already express them. |
-| `architecture.md` | 1.0 → 1.3 | Incorporate the distinction between adopted constraints and implemented structure, proportionate boundaries, and requirement-grounded threat scope. Retain the public facade, internal dependency direction, and consumer/library separation. |
-| `testing.md` | 1.0 → 1.3 | Adopt risk-based selection, contract-grounded tests, and the clarified concurrency example. Preserve Promptkit's offline suite, public/internal test ownership, and established validation workflow. |
-| `documentation.md` | 1.5 → 1.11 | Add meta-policy ownership and factual attribution scope. Preserve GoDoc ownership of exact exported contracts and the library's format, integration, consumer, and internal-document owners. |
-| `oss.md` | 1.2 → 1.8 | Adopt the precise House Format, copied-document treatment, upstream reference links, and separate document-license scope. Remove obsolete private-repository treatment and stale attribution instructions. |
-| `release.md` | 1.2 → 1.4 | Normalize equivalent language and add provenance while preserving the existing source-only process and compatibility decisions. No release-mechanics change is required. |
-
-Every adopted policy, including `meta.md`, records its actual Base Policy
-Version, local adoption date as Last Updated, and an Upstream Source link to
-that exact upstream document at the selected full commit.
-
-Agent and release policies require no new substantive restrictions. Retain
-Promptkit's successful-tag-push completion point, no CI or module-availability
-wait, selected automated checks, fixed release-note structure, immutable
-published records, and catalog-profile compatibility exception. Do not replace
-these decisions with upstream options intended for other projects.
-
-### Orientation And Selective Reading
-
-Adapt upstream `agents/AGENTS.md` into the root `AGENTS.md`, preserving any
-unrelated repository instructions. Route orientation through
-`docs/development.md` and require agent-policy reading before recommendations,
-planning, or implementation.
-
-Merge the adoption guide's Policy Reading Guide into `docs/development.md`.
-Include the meta-policy trigger for adoption and update work, and retain useful
-project-specific task routing. Remove the blanket requirement to read
-architecture before every change. Read policies by task, reuse unchanged
-material already in context, follow relevant cross-references, and expand
-reading when scope expands. The documentation policy owns topic ownership,
-not a duplicate reading-trigger table.
-
-### Discovery And Provenance Links
-
-In `meta.md`, retain the upstream project URL and the current
-`docs/adoption.md` URL as discovery links. Keep per-document adopted-source
-links, formal attribution links, and reference-example links pinned to commits.
-Existing example links may identify an earlier upstream commit that contains
-the referenced asset; discovery and imported-source links have different roles.
-
-The reviewed adoption guide is publicly accessible. This approved update
-supersedes the earlier local prohibition on policy-repository links. Do not
-require publishing another repository or introduce a network-availability gate.
-
-### Attribution And Document Licensing
-
-Preserve the existing factual dependency entries in
-`docs/oss/attribution.md`. Add the selected upstream revision's canonical
-`examples/licensing/policy-attribution.md` entry beneath the title, substituting
-the full commit in its URLs and accurately identifying copied/adapted material.
-Include the adapted root agent instructions if used; do not label all unrelated
-documentation as copied policy material.
-
-Retain the supplied creator, copyright, license, and notice links, including
-upstream COPYRIGHT, and identify adaptation in the concise Material statement.
-Do not restore research narratives, compliance commentary, or an introductory
-essay. Merely consulting upstream guidance is distinct from copying or adapting
-its documents.
-
-Add a scoped statement to Promptkit's root `COPYRIGHT` that policy documents
-adapted from Standard Repository Policies remain CC-BY-SA-4.0, pointing to the
-attribution entry for affected material and license information. Keep the
-library's LGPL-3.0-or-later grant unchanged. Retain the existing
-`docs/oss/licenses/CC-BY-SA-4.0.txt`, which matches the selected upstream text.
-The project `LICENSE` requires no change.
-
-Original licensing-example formatting is CC0 under the selected upstream grant.
-Using that formatting alone does not require a policy attribution entry or a
-new local example collection. Standard license texts retain their own terms.
-
-### Local Materials And Upstream References
-
-Keep customized policies, project orientation, actual COPYRIGHT and attribution
-notices, and applicable standard license texts locally. Keep the upstream
-README, root AGENTS, contributor guide, adoption guide, and example collection
-upstream. Adapt `agents/AGENTS.md`, not the upstream repository's own root
-agent instructions. Link to reference examples from the adopted OSS policy;
-do not copy their collection into Promptkit's runnable `examples/`.
-
-## Scope And Completion
-
-This is documentation work only. No runtime, API, dependency, test-suite, release
-script, publication-channel, or library-license changes are needed. Do not add
-scanners, recurring synchronization, approval gates, or new threat guarantees.
-Do not rewrite published releases to retrofit adoption metadata.
-
-The [future roadmap](future.md)'s remaining standard-policy-alignment idea is
-covered by this scope. Remove that entry when implementation is complete,
-preserving unrelated future and deferred work.
-
-Completion means the selected upstream wording is used wherever applicable,
-substantive Promptkit exceptions are preserved and identifiable, all adopted
-policies have accurate provenance, reading guidance is selective, and copied
-policy licensing and attribution follow the selected guide. Validate affected
-local links and anchors, source/example destinations, license-text fidelity,
-metadata, and whitespace proportionately. No full code audit or new permanent
-validation gate is required.
-
-Retire this roadmap after completion, leaving durable rules and provenance in
-their canonical owners. No significant design decisions remain open.