openprose__prose/packages/std/ops/compose/tests.prose.md

name, kind, version

name	kind	version
test-intent-designer	function	0.16.0

Test Intent Designer

Turn the desired render into an outside-in testing intent before internal decomposition hardens. The first test constrains the package promise, not its implementation.

Parameters

• current: current program package and prior test evidence
• request: current design request
• elicitation: resolved purpose, requirements, exclusions, and assumptions
• topology: proposed system and regional topology profiles
• landscape: existing test source, kind: test guidance, harnesses, and run evidence

Returns

• test_intent: containing:
  • public subject: the package-root Contract from index.prose.md
  • representative fixtures derived from real intended use
  • observable desired outcomes
  • important prohibited outcomes
  • unresolved assertions that still require architect judgment
  • topology and harness behaviors that must become observable later

Invariants

• Start with the package promise: given representative inputs, what observable result or maintained truth proves that the program did its job?
• Assert semantics, not exact wording or a preferred internal decomposition.
• Include Expects Not for the most important forms of plausible but wrong behavior.
• Do not invent fixtures that hide an unresolved product decision.
• Do not require every internal Contract to exist before the public test can be drafted.

Strategies

• Derive the first fixture from the ordinary success scenario, then add the smallest fixture that distinguishes a dangerous near-miss.
• Keep architectural quality claims observable: isolation becomes prohibited leakage; bounded work becomes a termination or budget assertion; durable state becomes an assertion over the maintained projection.
• Mark the test provisional when its public promise is still provisional. A provisional test guides composition but does not falsely certify readiness.

---

test-suite-projector

Refine package test intent into an ordered suite that guides implementation and iteration without freezing internal details too early.

Parameters

• candidate: proposed program architecture and Contract inventory
• test_intent: outside-in public test intent
• current: existing package tests and prior run evidence
• landscape: current kind: test semantics and available harnesses

Returns

• test_strategy: an ordered ladder containing:
  1. Package promise — root index.prose.md behavior under ordinary and distinguishing fixtures
  2. Contract boundaries — each stable child promise, inputs, Returns or maintained truth, invariants, and prohibited context or authority
  3. Interaction topology — fan-out/fan-in, ordering, subscription, settlement, and state-ownership behavior visible through the root
  4. Failure and recovery — child failure, partial results, timeout, retries, budget exhaustion, resume, and side-effect safety where relevant
  5. Harness portability — the same semantic test corpus under each supported harness adapter, without provider-specific assertions
  6. Performance and cost — tracked only after semantic behavior has a stable baseline
• test_sources: complete or provisional kind: test files using subject, ### Fixtures, ### Expects, and ### Expects Not
• readiness: first failing or missing rung, evidence, and the smallest next change that can advance it

Invariants

• Iterate in ladder order. A later performance improvement never outranks a failing public promise or unsafe failure path.
• Package tests target the root Contract. Contract tests target a child only after its boundary is stable enough to be meaningful.
• Prefer the smallest test that rules out the largest incorrect region of the design space.
• A test failure is evidence about the program first. Classify framework pressure separately and publish it through the feedback obligation.
• Do not encode topology as an implementation snapshot when the same promise can be tested through observable behavior.
• Do not claim cross-harness portability until the same test sources have run through each selected adapter.

Strategies

• Preserve useful failing tests. They are unresolved constraints, not clutter.
• After each material architecture change, run the earliest affected rung before widening the test scope.
• When a test is flaky, separate ambiguity in the assertion from model variability and harness nondeterminism before weakening it.
• Use semantic assertions for agent outputs and deterministic checks for file shape, schemas, bounds, receipts, and side-effect limits.
• Track performance and cost over comparable passing runs; never trade away a semantic assertion merely to improve the metric.