@laitszkin/apollo-toolkit 3.3.5 → 3.4.0

package/test-case-strategy/README.md

@@ -0,0 +1,27 @@
+# test-case-strategy
+
+Shared testing strategy skill for choosing risk-driven test cases across spec generation, new-feature implementation, and brownfield feature changes.
+
+## Core capabilities
+
+- Selects the smallest useful test level for each risk: unit, regression, property-based, integration, E2E, adversarial, or mock/fake scenario coverage.
+- Defines meaningful oracles before implementation so tests verify requirements instead of echoing newly written code.
+- Adds focused unit drift checks for atomic implementation tasks.
+- Records concrete test IDs, target units or flows, fixture strategy, verification hooks, and `N/A` reasons.
+- Provides reusable references for unit, property-based, integration, and E2E test decisions.
+
+## Repository structure
+
+- `SKILL.md`: Shared test selection workflow and output contract.
+- `agents/openai.yaml`: Agent interface metadata and default prompt.
+- `references/`: Focused guides for unit drift checks, property-based tests, integration tests, and E2E tests.
+
+## Typical usage
+
+```text
+Use $test-case-strategy to choose the right tests for this change and define the unit drift checks before implementation.
+```
+
+## License
+
+MIT. See `LICENSE`.

package/test-case-strategy/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: test-case-strategy
+description: Select and design risk-driven test cases for agent implementation work. Use when specs, new-feature work, brownfield feature changes, refactors, or bug fixes need a concrete decision about unit, regression, property-based, integration, E2E, adversarial, mock/fake, or drift-check coverage.
+---
+
+# Test Case Strategy
+
+## Dependencies
+
+- Required: none.
+- Conditional: none.
+- Optional: none.
+- Fallback: not applicable.
+
+## Standards
+
+- Evidence: Base every test decision on changed behavior, requirement IDs, risk class, dependency shape, and existing coverage; do not add tests only because a template lists them.
+- Execution: Choose the smallest test level that can prove the risk, then escalate to broader tests only when lower-level tests cannot observe the behavior or contract.
+- Quality: Each test must have a meaningful oracle derived from the requirement, design, or contract rather than from the implementation just written.
+- Output: Return concrete test case IDs, test level, target unit or flow, oracle, fixture/mock strategy, command or verification hook, and any `N/A` reason.
+
+## Goal
+
+Provide one shared testing decision workflow for spec generation and implementation skills so agents select useful tests consistently and use fast focused checks to detect implementation drift.
+
+## Workflow
+
+### 1) Build the risk inventory
+
+- Identify changed behaviors, requirement IDs, and affected modules.
+- Classify risks before choosing test types:
+  - boundary
+  - regression
+  - authorization or permission denial
+  - invalid transition
+  - idempotency, replay, or duplicate submission
+  - concurrency or race
+  - data integrity
+  - external failure or inconsistent dependency state
+  - partial write, rollback, or compensation
+  - adversarial abuse
+- Reuse existing coverage only after naming the exact suite, test case, and risk it already proves.
+
+### 2) Choose the narrowest valid test level
+
+- Use unit tests for isolated changed logic, boundaries, denials, exact errors, no-side-effect expectations, and fast implementation drift checks.
+- Use regression tests when a bug-prone or historically fragile behavior must not silently return.
+- Use property-based tests for business rules with describable invariants, generated input spaces, valid/invalid state transitions, or external-state matrices that can be mocked.
+- Use integration tests for cross-module chains, repository/service/API/event interactions, configuration wiring, persistence, IO, and controlled external-service scenarios.
+- Use E2E tests only for critical user-visible paths whose risk is not sufficiently proven by lower-level tests; keep them minimal and stable.
+- Use adversarial tests for malformed input, forged identities, invalid transitions, replay, stale/out-of-order events, toxic payload sizes, and risky edge combinations.
+- If E2E is too costly or unstable, replace it with integration coverage for the same risk and record the replacement.
+
+### 3) Define the oracle before implementation
+
+- Derive expected behavior from `spec.md`, `design.md`, `contract.md`, official documentation, or existing intended behavior.
+- Never derive the oracle from the new implementation after writing it.
+- Prefer exact assertions:
+  - exact output
+  - exact error class or denial reason
+  - persisted state
+  - emitted event
+  - retry or compensation accounting
+  - intentional absence of writes, notifications, or side effects
+  - allowed state transition or rejection
+- Avoid assertion-light smoke tests, snapshot-only tests, and tests that only prove "does not throw" unless that is the real requirement.
+
+### 4) Add unit drift checks for atomic implementation tasks
+
+- For each non-trivial atomic task, decide whether a focused unit drift check is possible.
+- A unit drift check should name:
+  - target unit: function, method, module, policy, parser, mapper, validator, or state transition owner
+  - input state: minimal fixture, table row, fake dependency state, or boundary value
+  - oracle: exact output, error, state change, or no-side-effect assertion
+  - command: focused test command or existing test filter to run immediately after the task
+- If no unit drift check is possible, record the smallest replacement check and a concrete reason.
+- Do not allow broad integration or E2E tests to hide missing unit checks for locally owned business logic.
+
+### 5) Record the decision
+
+Use this compact record in planning docs or implementation summaries:
+
+```text
+Test ID: UT-01 / REG-01 / PBT-01 / IT-01 / E2E-01 / ADV-01
+Requirement/Risk: R?.? / boundary | regression | ...
+Target: function/module/flow
+Fixture or mock strategy: ...
+Oracle: exact output/error/state/no-side-effect
+Verification hook: command or existing suite
+N/A reason: only when this test level is not suitable
+```
+
+## Working Rules
+
+- Start from risk and oracle, not from a desired test count.
+- Prefer fast focused tests for implementation drift detection.
+- Keep one test focused on one behavior or one failure mode.
+- Use table-driven unit tests when many discrete business cases share one oracle.
+- Use mocks/fakes for external services in business logic chains unless the real external contract itself is under test.
+- Keep fixtures reproducible with fixed clocks, seeds, and controlled dependency states.
+- Preserve failing generated examples or seeds as regression coverage.
+- Record `N/A` only with a concrete reason tied to scope, risk, or observability.
+- When a spec exists, map test IDs back to `tasks.md` and `checklist.md`.
+
+## References
+
+- `references/unit-tests.md`: unit test and drift-check design.
+- `references/property-based-tests.md`: property-based test selection and oracle design.
+- `references/integration-tests.md`: integration test selection and external-state scenarios.
+- `references/e2e-tests.md`: E2E decision and replacement rules.

package/test-case-strategy/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Test Case Strategy"
+  short_description: "Select risk-driven tests and unit drift checks"
+  default_prompt: "Use $test-case-strategy to choose the smallest useful test level for each changed behavior, starting from requirement IDs, risk class, dependency shape, and existing coverage. Define oracles before implementation, prefer focused unit drift checks for atomic tasks, escalate to property-based, integration, E2E, adversarial, or mock/fake scenario coverage only when the risk requires it, and return concrete test IDs, target unit or flow, fixture strategy, verification hook, and any N/A reason."

package/test-case-strategy/references/e2e-tests.md

@@ -0,0 +1,31 @@
+# E2E Tests
+
+## Purpose
+
+- Verify critical user-visible paths at the closest practical level to real usage.
+- Catch cross-layer behavior gaps that lower-level tests cannot prove.
+
+## Required when
+
+- A change affects a high-impact user-visible flow.
+- The flow is multi-step, cross-system, historically fragile, revenue-critical, permission-sensitive, or hard to reason about from lower-level tests alone.
+- The environment and test data can be kept stable enough for maintainable coverage.
+
+## Not suitable when
+
+- Unit and integration tests already prove the actual risk.
+- The environment is unstable or external dependencies would make the test flaky.
+- The cost is disproportionate and integration tests can cover the same risk.
+
+## Design rules
+
+- Keep E2E minimal: one critical success path plus one highest-value denial or failure path when warranted.
+- Assert business-visible outcomes, not just DOM presence or status-code success.
+- Use controlled test data and avoid brittle external dependencies.
+- Prefer replacing expensive E2E with stronger integration tests over adding flaky coverage.
+- Record the decision per flow or risk slice; do not collapse unrelated paths into one global E2E decision.
+
+## Recording
+
+- Record `E2E-xx`, target flow, business-visible oracle, setup, command, and result.
+- If skipped, record the replacement `IT-xx` cases and concrete rationale.

package/test-case-strategy/references/integration-tests.md

@@ -0,0 +1,32 @@
+# Integration Tests
+
+## Purpose
+
+- Verify collaboration across modules, layers, repositories, handlers, services, event flows, persistence, configuration, or controlled external-service scenarios.
+- Cover risks unit tests cannot observe: sequence, wiring, persistence, IO, config, retry, fallback, and cross-boundary side effects.
+
+## Required when
+
+- The changed behavior depends on service/repository/API/event/module collaboration.
+- The correctness question is about a user-critical business chain rather than one isolated unit.
+- External dependency states affect business behavior and can be mocked or faked.
+- E2E is not suitable but equivalent cross-layer risk still needs coverage.
+
+## Not suitable when
+
+- A pure unit owns the behavior and unit tests can fully observe the risk.
+- A stable E2E test is required and feasible for a critical user-visible path.
+
+## Design rules
+
+- Keep dependencies inside the application boundary near-real when practical.
+- Mock or fake external services unless the real service contract itself is under test.
+- Build scenario matrices for success, timeout, retry exhaustion, partial data, stale data, duplicate callback, inconsistent response, and permission failure.
+- Assert business outcomes across boundaries: persisted state, emitted event, deduplication, retry accounting, audit trail, compensation, or no partial write.
+- Include adversarial paths when invalid transition, replay, double-submit, forged identifier, or out-of-order event risks exist.
+- Keep data reconstructable and cleanup reliable.
+
+## Recording
+
+- Record `IT-xx`, modules involved, external dependency strategy, scenario matrix, oracle, requirement mapping, and command.
+- If integration replaces E2E, map the replacement explicitly.

package/test-case-strategy/references/property-based-tests.md

@@ -0,0 +1,43 @@
+# Property-Based Tests
+
+## Purpose
+
+- Verify invariants across broad or generated input spaces.
+- Validate business rules as allowed outputs, forbidden outputs, valid transitions, rejection rules, or safety constraints.
+- Catch combinational, adversarial, and boundary behaviors that fixed examples miss.
+
+## Required when
+
+- Logic has describable invariants: calculation, transformation, sorting, aggregation, serialization, normalization, deduplication, routing, ranking, or state transition.
+- Business rules can be expressed as predicates, allow-lists, forbidden states, or metamorphic relationships.
+- External-service-dependent logic can use mocks/fakes to generate service states.
+
+## Not suitable when
+
+- The only meaningful risk is a real external integration contract.
+- The input space is tiny and better covered by exhaustive unit tests.
+- The behavior is UI-only or lacks a stable machine-verifiable oracle.
+
+## Design rules
+
+- State the property in one sentence before writing generators.
+- Generate normal cases, boundaries, extremes, malformed inputs, and suspicious/adversarial combinations.
+- Prefer direct business-rule predicates over vague structural checks.
+- Use state-machine or sequence properties for stateful flows.
+- Use metamorphic properties when exact outputs are hard to predict.
+- Preserve failing seeds/examples as regression tests.
+- Control sample count and input size so the suite remains practical.
+
+## Common properties
+
+- Round trip: `decode(encode(x)) == x`.
+- Sorting is monotonic and preserves the input multiset.
+- Merge/split operations preserve total count or value.
+- Replaying the same command remains idempotent.
+- Generated invalid or unauthorized inputs always fail with an expected result class.
+- Generated transitions always end in allowed states or explicit rejections.
+- Under generated mocked service states, fallback, retry, and compensation rules still hold.
+
+## Recording
+
+- Record `PBT-xx`, property, generator strategy, oracle, requirement mapping, and replay instructions for failures.

package/test-case-strategy/references/unit-tests.md

@@ -0,0 +1,59 @@
+# Unit Tests And Drift Checks
+
+## Purpose
+
+- Verify the smallest changed behavior unit: function, method, policy, parser, mapper, validator, state transition owner, or pure logic module.
+- Localize failures quickly while the agent is still implementing a single task.
+- Detect implementation drift by comparing the changed unit against an oracle defined before the code change.
+
+## Required when
+
+- A task changes non-trivial local logic.
+- A requirement has boundary, denial, validation, state transition, idempotency, authorization, error, or no-side-effect behavior.
+- The input space is small and discrete enough to enumerate expected outputs.
+- A bug-prone behavior needs a fixed regression example.
+- The task can be verified without DB, RPC, filesystem, browser, queue, or multi-module orchestration.
+
+## Not suitable when
+
+- Correctness depends on real cross-module collaboration, persistence, IO, or configuration wiring.
+- The main risk is the external integration contract itself.
+- The behavior is only observable through a user-visible end-to-end path.
+
+## Drift-check record
+
+```text
+Unit drift check:
+  Target unit: [function/module/policy]
+  Requirement: [R?.?]
+  Fixture/input: [minimal state or table row]
+  Oracle: [exact output/error/state/no-side-effect]
+  Test case ID: [UT-xx or REG-xx]
+  Run after task: [focused command or test filter]
+  N/A reason: [only if no unit check can observe the task]
+```
+
+## Design rules
+
+- Define the oracle from the spec, design, contract, official docs, or established intended behavior before implementation.
+- Keep one test focused on one behavior or failure mode.
+- Use table-driven tests for small business matrices.
+- Cover both accepted and rejected states when the unit owns a decision.
+- Assert exact errors, result classes, state changes, and intentional lack of side effects.
+- Mock, stub, or fake external dependencies; unit tests should not need DB/RPC/file/browser IO.
+- Control time, randomness, environment variables, and global state.
+- Do not accept tests that only assert "does not throw", "returns truthy", or snapshot shape unless those are the real business oracle.
+
+## Useful unit cases
+
+- Boundary value is accepted at the limit and rejected outside it.
+- Invalid input returns the specified error and performs no write.
+- Unauthorized actor is denied with the expected reason.
+- Repeating an idempotent call returns the same outcome without duplicate side effects.
+- State transition from `A` to `B` is allowed, while `A` to `C` is rejected.
+- Mapper/parser preserves required fields and rejects malformed variants.
+
+## Recording
+
+- In specs, map each `UT-xx` or `REG-xx` to requirement IDs and checklist items.
+- In direct implementation, report test IDs, command, result, and any `N/A` reason.

package/develop-new-features/references/testing-e2e.md

@@ -1,36 +0,0 @@
-# E2E Testing Principles
-
-## Core rules
-- E2E is not decided solely by explicit user request.
-- The agent must decide E2E based on feature importance, complexity, and cross-layer risk.
-- For high-risk key user paths, create the smallest necessary E2E coverage first.
-- If E2E is unstable, too costly, or environment-limited, add integration coverage for equivalent risk and record the alternative.
-
-## Purpose
-- Verify critical end-to-end user paths are usable.
-- Catch behavior gaps after cross-system/cross-layer integration.
-- Provide confidence close to real usage for high-risk scenarios.
-
-## Decision criteria
-- Importance: core feature, critical revenue flow, or high-impact process.
-- Complexity: multi-step state transitions, branching flows, cross-service collaboration.
-- Risk: historical regressions, fragile integrations, major user-visible failures.
-- Maintainability: stable environment and controllable test data.
-
-## Not suitable when
-- Feature risk is low and unit/integration tests already cover it sufficiently.
-- E2E is unstable and disproportionately expensive while integration tests can cover key risk.
-
-## Design guidance
-- Cover only the most critical paths; avoid expanding into full UI test suites.
-- Keep test data controllable (fixed seeds or recyclable fixtures).
-- Prioritize stability; avoid brittle external dependencies, use controlled substitutes if needed.
-- Prefer one critical success path and one highest-value denial/failure path over many shallow happy-path journeys.
-- Assert business-visible outcomes, not just DOM presence: final state, permission denial, user-facing error, persisted result, or prevented duplicate action.
-- Keep cost decisions explicit: document why E2E is done or not done and what alternative strategy is used.
-
-## Spec/checklist authoring hints
-- Mark high-risk key paths in `spec.md` requirement descriptions.
-- Record E2E decisions, mapped test cases, and results in `checklist.md`.
-- When different flows need different strategies, create multiple decision records instead of forcing one shared E2E decision for the whole feature.
-- If skipping E2E, specify replacement integration test cases (`IT-xx`) and rationale in `checklist.md`.

package/develop-new-features/references/testing-integration.md

@@ -1,42 +0,0 @@
-# Integration Testing Principles
-
-## Purpose
-- Verify collaboration across modules/layers and external dependencies.
-- Cover integration risks unit tests cannot capture (sequence, config, IO failure).
-- Validate user-critical business logic chains under realistic component interaction and controlled external-service scenarios.
-
-## When to use
-- Interface interactions between modules (for example service ↔ repository).
-- Changes touching IO dependencies such as DB, RPC, files, cache, queues.
-- Behaviors that depend on configuration combinations or environment differences.
-- The correctness question is about the whole business logic chain rather than one isolated function.
-- As minimum safety replacement when E2E is not suitable.
-
-## Not suitable when
-- Single pure-function or pure-logic behavior (use unit tests).
-- Full end-to-end user flow can be stably covered by E2E.
-
-## Relationship with E2E
-- If change importance/complexity is high and E2E is feasible, prefer minimal E2E for key paths.
-- If E2E is hard or too costly, integration tests must cover equivalent key risks.
-- Record replacement mapping in `checklist.md` (E2E-xx ↔ IT-xx) with rationale.
-
-## Design guidance
-- Focus on high-value integration points; each test should justify risk/value.
-- Keep dependencies inside the application boundary near-real where practical.
-- Mock/fake external services at the business-chain boundary unless the real service contract itself is what needs verification.
-- Build scenario matrices for external states such as success, timeout, retries exhausted, partial data, stale data, duplicate callbacks, inconsistent responses, and permission failures.
-- Add adversarial/penetration-style cases for abuse paths such as invalid transitions, replay, double-submit, forged identifiers, or out-of-order events when those risks exist.
-- When workflows can partially commit, assert rollback/compensation/no-partial-write behavior instead of only final status codes.
-- Assert business outcomes across boundaries: persisted state, emitted events, deduplication, retry accounting, audit trail, or intentional absence of writes/notifications.
-- Add at least one regression-style integration test for the highest-risk chain whenever the change fixes a bug or touches a historically fragile path.
-- Keep reproducible: controlled test data and recoverable environment.
-- Keep cost controlled; avoid broad redundant coverage (leave that to unit tests).
-
-## Spec/checklist authoring hints
-- Dependency scope: list involved modules/external systems.
-- Scenario: describe cross-module flow or critical branch.
-- Risk: explain what integration failure, misconfiguration, or business-chain break this test can reveal.
-- External dependency strategy: specify which services are mocked/faked versus near-real and why.
-- Scenario matrix: list the external states or adversarial paths covered.
-- Map behavior, test IDs, and test outcomes in `checklist.md`.

package/develop-new-features/references/testing-property-based.md

@@ -1,44 +0,0 @@
-# Property-based Testing Principles
-
-## Purpose
-- Verify invariants/properties hold across broad input spaces.
-- Validate business rules by generating or exhaustively enumerating meaningful input spaces and checking outputs against expected business behavior.
-- Catch combinational, adversarial, and boundary behaviors that fixed examples often miss.
-
-## When to use
-- Algorithms, transformations, serialization/deserialization, sorting, aggregation.
-- Behaviors requiring consistency or reversibility (for example round-trip).
-- Data structures or state transitions with clear invariants.
-- Business logic where the rule can be stated as input/output expectations, allowed states, forbidden states, or safety constraints.
-- Logic chains that depend on external services, when those services can be replaced by controllable mocks/fakes and their states generated as part of the test space.
-
-## Not suitable when
-- The main thing being validated is the real integration contract with external systems or live IO (use integration tests).
-- UI/interactive flows without stable invariants.
-- Very small discrete input spaces (unit tests are sufficient).
-
-## Design guidance
-- Properties must be explicit and machine-verifiable, whether they are invariants, allowed outcome sets, rejection rules, or business-output predicates.
-- Generators should cover normal cases, boundaries, extremes, malformed inputs, and suspicious/adversarial combinations.
-- Prefer modeling business rules directly: generate inputs, run the logic, then assert the output/error/state transition matches the rule.
-- When the behavior is stateful, prefer state-machine or sequence-based properties over isolated single-call generators.
-- When exact outputs are hard to predict, use metamorphic properties (for example reordering, retrying, deduplicating, or replaying inputs should preserve an allowed relation).
-- For external-service-dependent logic, mock/fake the service and generate multiple service states (success, timeout, empty, partial, stale, inconsistent, duplicate, rejected).
-- Ensure reproducibility (fixed seed or replayable input generation) and preserve failing seeds/examples for regression coverage.
-- Complement unit tests; avoid duplicating fixed-case tests.
-- Control cost with reasonable sample counts and input-size limits.
-
-## Common property examples (description level)
-- `deserialize(serialize(x)) == x`
-- Sorted output is monotonic and preserves element multiset.
-- Merge/split operations preserve total element count.
-- Idempotency: repeating the same operation does not change results.
-- Invalid or unauthorized generated inputs always fail with an expected error/result class.
-- Generated order/payment/state-transition inputs always end in an allowed business state.
-- Under generated mocked service states, the business logic chain still satisfies fallback/retry/compensation rules.
-
-## Spec/checklist authoring hints
-- Property/rule: one sentence stating the rule that must always hold or the allowed outcomes that must contain the result.
-- Generator strategy: input range, distribution, emphasized boundaries, and any adversarial or external-state dimensions.
-- Oracle/check: describe how the test decides correctness (predicate, allow-list, reference model, or expected error class).
-- Purpose: explain correctness/risk reduction value of this property.

package/develop-new-features/references/testing-unit.md

@@ -1,37 +0,0 @@
-# Unit Testing Principles
-
-## Purpose
-- Verify correctness of the smallest testable unit (function, method, or pure logic module).
-- Provide fast feedback with low-cost failure localization.
-
-## When to use
-- Core business logic and critical branches.
-- Boundary conditions (upper/lower limits, null/empty, extreme values).
-- Error handling and exception paths (invalid input, incompatible state, etc.).
-
-## Not suitable when
-- Behavior requires cross-module or external dependency verification (use integration tests).
-- Full user-flow validation is required (evaluate E2E first; if not suitable, use integration tests to cover risk).
-
-## Design guidance
-- Isolate external dependencies with mock/stub/fake; avoid DB/RPC/file IO.
-- Keep tests small and focused: one test, one behavior/failure mode.
-- Do not stop at happy-path assertions; verify exact errors, rejected states, and intentional lack of side effects when the unit should block an action.
-- Cover both success and failure branches.
-- Where the input space is small and discrete, exhaustively enumerate business inputs and expected outputs.
-- Prefer table-driven cases when many small business permutations share the same oracle.
-- Add regression tests for bug-prone or high-risk logic so previously broken behavior cannot silently return.
-- If the unit owns authorization, invalid transition, idempotency, or concurrency decisions, test those denials explicitly.
-- Keep tests reproducible: avoid nondeterministic time/random/global state.
-- Avoid assertion-light smoke tests and snapshot-only coverage unless the snapshot has a strict business oracle behind it.
-- Map tests to requirements: each core requirement should have at least one unit test.
-
-## Spec/checklist authoring hints
-- Scenario: describe input and initial state mapped to one requirement/boundary.
-- Expected result: verifiable output, state change, or error.
-- Purpose: explain which risk or bug type this test prevents.
-
-## Common examples (description level)
-- Return a specific error when input is out of allowed range.
-- Handle empty list/empty string input with expected behavior.
-- Ensure output matches definition after state/flag switching.

package/enhance-existing-features/references/e2e-tests.md

@@ -1,26 +0,0 @@
-# E2E Testing Guide
-
-## Purpose
-- Verify critical user-visible paths at end-to-end level.
-- Increase confidence in real behavior after cross-layer integration.
-
-## Required when
-- If changes impact key user-visible flows, add or update E2E tests.
-- E2E must still be evaluated even when specs are not used; if not applicable, record explicit rationale.
-
-## E2E decision rules
-- Prefer E2E for high-risk, high-impact, multi-step flow changes.
-- Integration tests may replace E2E when E2E is too costly, unstable, or hard to maintain.
-- When replacing E2E, provide equivalent risk coverage and record replacement cases plus reasons.
-
-## Design guidance
-- Focus on minimal critical path coverage; avoid over-expansion.
-- Use stable test data and reproducible flows.
-- Prioritize business outcomes over brittle UI details.
-- Prefer one critical success path and one highest-value denial/failure path over many shallow happy-path journeys.
-- Assert business-visible outcomes, not just DOM presence: final state, permission denial, user-facing error, persisted result, or prevented duplicate action.
-
-## Recording rules
-- Specs flow: record E2E or replacement strategy with outcomes in `checklist.md`.
-- When different flows need different strategies, create multiple decision records in `checklist.md` so each flow/risk slice keeps its own rationale and linked case IDs.
-- Non-specs flow: explain E2E execution or replacement testing with rationale in the response.

package/enhance-existing-features/references/integration-tests.md

@@ -1,30 +0,0 @@
-# Integration Testing Guide
-
-## Purpose
-- Verify correctness of cross-layer/cross-module collaboration.
-- Focus especially on user-critical logic chains.
-- Validate business outcomes across the full changed chain, not just connectivity.
-
-## Required when
-- Any change affecting service/repository/API handlers/event flows should add or update integration tests.
-- Integration tests for user-critical logic chains are required even when specs are not used.
-
-## Coverage focus
-- Key data flow from entrypoint to output.
-- Cross-module contract and configuration interaction.
-- Common failure patterns (timeout, data inconsistency, external dependency failure).
-- External dependency state changes and fallback/compensation behavior.
-- Adversarial/abuse paths such as invalid transitions, replay, duplication, forged identifiers, or out-of-order events when relevant.
-
-## Design guidance
-- Prefer near-real dependencies inside the application boundary; mock/fake external services unless the real service contract itself is under test.
-- Build scenario matrices for external states such as success, timeout, retries exhausted, partial data, stale data, duplicate callbacks, inconsistent responses, and permission failures.
-- Keep test data reconstructable and cleanable.
-- When workflows can partially commit, assert rollback/compensation/no-partial-write behavior instead of only final status codes.
-- Assert business outcomes across boundaries: persisted state, emitted events, deduplication, retry accounting, audit trail, or intentional absence of writes/notifications.
-- Add at least one regression-style integration test for the highest-risk chain whenever the change fixes a bug or touches a historically fragile path.
-- Each test case should map to an explainable risk.
-
-## Recording rules
-- Specs flow: record IT cases and outcomes in `checklist.md`.
-- Non-specs flow: list user-critical integration tests, mocked external scenarios, adversarial cases, and outcomes in the response.

package/enhance-existing-features/references/property-based-tests.md

@@ -1,33 +0,0 @@
-# Property-based Testing Guide
-
-## Purpose
-- Verify invariants across large input combinations.
-- Validate business rules by generating or exhaustively enumerating meaningful input spaces and checking outputs against expected business behavior.
-- Catch combinational, adversarial, and boundary behavior that fixed examples often miss.
-
-## Required when
-- If changes include logic with describable invariants (calculation, transformation, sorting, aggregation, serialization), add/update property-based tests.
-- If changes include business rules that can be expressed as allowed outputs, forbidden outputs, valid transitions, rejection rules, or safety constraints, add/update property-based tests.
-- If logic depends on external services but the service can be replaced with a mock/fake to generate service states, property-based tests should cover those state combinations too.
-- If not applicable, record `N/A` with a concrete reason.
-
-## Common properties
-- Round-trip: `decode(encode(x)) == x`
-- Idempotency: repeated execution does not change the result
-- Monotonicity/conservation/set invariance
-- Generated invalid or unauthorized inputs always fail with an expected result/error class
-- Generated state transitions always end in an allowed business state
-- Under generated mocked service states, the business logic chain preserves fallback/retry/compensation rules
-
-## Design guidance
-- Properties must be machine-verifiable, whether they are invariants, allow-lists, rejection rules, or business-output predicates.
-- Generator strategy should include normal cases, boundaries, extremes, malformed inputs, and suspicious/adversarial combinations.
-- Prefer modeling the business rule directly: generate inputs, run the logic, then assert output/error/state transition matches the rule.
-- When the behavior is stateful, prefer state-machine or sequence-based properties over isolated single-call generators.
-- When exact outputs are hard to predict, use metamorphic properties (for example reordering, retrying, deduplicating, or replaying inputs should preserve an allowed relation).
-- For external-service-dependent logic, mock/fake the service and generate multiple service states (success, timeout, empty, partial, stale, inconsistent, duplicate, rejected).
-- Control execution cost while preserving reproducibility, and preserve failing seeds/examples for regression coverage.
-
-## Recording rules
-- If specs are used, record cases and outcomes in `checklist.md`.
-- If specs are not used, record cases, external-state coverage, adversarial coverage, or `N/A` reasons in the response.

package/enhance-existing-features/references/unit-tests.md

@@ -1,29 +0,0 @@
-# Unit Testing Guide
-
-## Purpose
-- Verify correctness of a single function/module and localize failures quickly.
-- Cover both success and failure paths for the smallest changed behavior unit.
-
-## Required when
-- Any non-trivial logic change should add or update unit tests.
-- Unit test evaluation is required even when specs are not used.
-
-## Coverage focus
-- Core logic branches and boundary values.
-- Error handling, validation failures, and incompatible states.
-- Function paths with highest regression risk.
-
-## Design guidance
-- Isolate external dependencies (mock/stub/fake).
-- Keep tests small and focused: one behavior per test.
-- Do not stop at happy-path assertions; verify exact errors, rejected states, and intentional lack of side effects when the unit should block an action.
-- Where the input space is small and discrete, exhaustively enumerate business inputs and expected outputs.
-- Prefer table-driven cases when many small business permutations share the same oracle.
-- Add regression tests for bug-prone or high-risk logic so previously broken behavior cannot silently return.
-- If the unit owns authorization, invalid transition, idempotency, or concurrency decisions, test those denials explicitly.
-- Keep tests reproducible and fast.
-- Avoid assertion-light smoke tests and snapshot-only coverage unless the snapshot has a strict business oracle behind it.
-
-## Recording rules
-- If specs are used, record mapped test cases and results in `checklist.md`.
-- If specs are not used, list test IDs and results in the response.