English · 繁體中文

Copy Markdown

From rules to results

This page connects the complete flow: people state what correct means, an AI implements from public information, and ToppleCat rechecks the same agreement. The second half explains the technical modules and where private information stays.

To set up this flow in your project, start with Getting started.

The complete delivery flow

human selects rules and examples
    -> public Java/JUnit executable contract
    -> Reviewer checks and seals the complete contract
    -> AI agent implements with ordinary test feedback
    -> formal Verify runs fresh public and independent checks
    -> current evidence and a private Verification Report
    -> human decides what to do with the delivery

Ordinary ./gradlew test runs the public project tests and acceptance methods. It produces development feedback, not formal ToppleCat evidence.

./gradlew toppleCatVerify first checks that the complete contract and policy still match the Mechanical Seal. It then runs public acceptance and every enabled independent safeguard, writes the current evidence and reports, and returns one aggregate result.

What is authoritative

The public Java/JUnit Acceptance Methods and typed JSON or YAML case rows are the executable contract. Generated JSON and HTML explain that contract and the observed results; they never become another place to author rules.

One public @ToppleAcceptanceTest("AC-...") method owns each selected rule. Public and reviewer-controlled rows run the same method in separate modes. @ToppleProperty declarations are public invariants with their own generated evidence. Generated Property choices never become hidden case rows.

This matters because the implementation agent must be judged against the same public contract it received. ToppleCat does not reinterpret that contract in the report layer.

Four modules

Module	What it owns
topplecat-core	Case, evidence, custody, Property, and safe-feedback data models
topplecat-junit	Acceptance annotations, typed rows, Scenario/Stage execution, expected-value checking, and Properties
topplecat-report	The private Spec Review and Verification Report projections
topplecat-gradle-plugin	Commands, task order, scope, custody, integrity, and managed Mutation Testing

The public website and executable samples explain and verify the product; they are not extra runtime modules.

Independent checks

Reviewer examples, Property-Based Testing, and Mutation Testing answer different questions. They share the delivery scope, integrity check, and final report, but not evidence. Once contract integrity passes, reviewer examples and Properties can still produce results when Public Acceptance fails. Mutation Testing needs a passing public baseline before it can assess temporary production changes.

Formal Mutation Testing uses ToppleCat's fixed managed PIT profile and maps PIT observations to exact public Acceptance Methods. Project-specific PIT tasks stay outside ToppleCat evidence.

Custody and information boundary

toppleCatSeal moves reviewer-controlled source into local plaintext custody and records a content-based seal over the complete executable contract and verification policy. This detects contract changes. It is not encryption, hostile-process isolation, or an operating-system security boundary.

The Implementation Agent receives the public contract and safe Gate-level feedback. The Reviewer keeps Spec Review, Verification Report, private examples, counterexamples, producer diagnostics, and raw failures. A public site may show clearly labelled synthetic demonstrations, never material from an actual delivery.

For exact product terms, use the Glossary. For the human responsibility boundary, read When ToppleCat is useful.