eric/promptkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Align project policies and simplify the release workflow

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-23 16:06:33 +00:00
parent 9f69da716b
commit 6dfd6bd719
12 changed files with 584 additions and 532 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/policy/testing.md
View File

@@ -1,5 +1,9 @@
# Testing Policy
**Base Policy Version:** 1.0
**Last Updated:** 2026-09-23
## Purpose
Our tests exist to make **incorrect changes expensive and correct changes cheap**.
@@ -50,16 +54,21 @@ Examples of appropriate seams include clocks, randomness, subprocesses, remote A
## Test execution requirements
Promptkit currently uses maintainer-run validation rather than hosted CI.
Maintainers run the complete local workflow in the
[development guide](../development.md#maintainer-validation) before accepting
changes. That guide is the canonical owner of exact commands, formatting,
documentation-link validation, and repository-hygiene checks.
Ordinary work requires validation proportionate to its scope and risk. Do not
repeat successful checks for unchanged content merely to create a commit.
Release candidates require the complete local workflow in the
[development guide](../development.md#maintainer-validation). That guide routes
contributors to the executable checks for formatting, documentation links,
and repository hygiene.
Introducing hosted CI later would supplement, not silently redefine, this
documented validation model.
Maintainer validation must include ordinary and race-enabled package tests,
static analysis, a complete build, and execution of both maintained offline
consumer examples. The preparation example protects assembled preparation and
Full release-candidate validation includes race-enabled package tests, explicit
static analysis, and execution with automated semantic checks of both maintained
offline consumer examples. The test run builds the packages; the examples
also exercise ordinary compilation. Separate ordinary tests and a standalone
build are not additional release gates. Ordinary tests remain useful during
development. The preparation example protects assembled preparation and
inspection behavior. The execution example separately protects assembled
`Run`, injected-client, validation, usage, and result behavior.