Document Scriptorium as a Promptkit application

docs/policy/testing.md

@@ -77,7 +77,7 @@ Test through the narrowest stable boundary that expresses the behavior clearly.
 
 This is often the package API, but it may instead be:
 
-- a smaller pure function when dense domain logic is most clearly isolated there;
+- a smaller pure function when dense application logic is most clearly isolated there;
 - 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.
 
@@ -162,13 +162,16 @@ Use a test-controlled limit and measure the behavior relative to that limit. Do
 
 Each behavior should have a clear test owner.
 
-- Parser tests own parsing cases.
-- Validator tests own validation rules.
-- Domain tests own transformations and invariants.
-- Adapter tests own external integration behavior.
-- Orchestrator tests own coordination and failure propagation.
-- CLI tests own argument and configuration mapping.
-- End-to-end tests prove that representative assembled workflows work.
+- Configuration tests own application YAML, discovery, precedence, and
+  application defaults.
+- CLI tests own argument mapping, streams, summaries, exit behavior, and
+  representative command workflows.
+- HTTP tests own DTOs, strict decoding, limits, status mapping, and restricted
+  artifact policy.
+- Formatter tests own prepared-run text and JSON presentation.
+- Architecture tests own dependency direction and removal invariants.
+- Promptkit owns framework parsing, orchestration, validation, profiles, and
+  model-client behavior.
 
 Higher-level tests should not repeat every lower-level case. A single intentional policy change should not require unrelated edits across many test files.
 
@@ -221,7 +224,9 @@ Coverage is a diagnostic, not a target.
 
 Use it to find untested critical branches and unexpectedly weak packages. Do not write low-value tests solely to increase a percentage, and do not infer test quality from coverage alone.
 
-Pure domain logic will often warrant higher coverage than CLI wiring or external adapters. Uneven coverage is acceptable when it reflects risk.
+Security-sensitive HTTP containment and external mappings may warrant denser
+coverage than straightforward process wiring. 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.