Test::FitNesse::Slim documentation

This index separates user instructions, fixture contracts, implementation design, compatibility limits, and recorded acceptance evidence. The README is the short installation path; the documents below are the authoritative source for their named topics.

Install and use

• README — installation, pipe and TCP startup, external fixture discovery, and the first FitNesse test.
• Test::FitNesse::Slim POD — installed module purpose and executable overview.
• perl-slim POD — options, invocation, exit status, and FitNesse configuration.
• CLI runner configuration — verified FitNesse v20251025 command-line variable overrides.
• Pipe transport — v0.5 child-process lifecycle, framing, and diagnostic tunneling.
• License terms — choose either GPL version 1 or later, or Artistic License 1.0 for Test::FitNesse::Slim's original code. The full texts are GPL and Artistic; scoped fixture notices and the separate CPL text are in THIRD-PARTY-NOTICES.md.

Fixture authoring

• Fixture conversion — constructor and method signatures, scalar and sequence converters, enums, names, and examples.
• Standalone counter fixture and FitNesse page — the independent packaging example.
• Order-management acceptance suite — a business-readable suite running against the installed distribution, with business rules, test-author guidance, developer guidance, and a usability audit.

Architecture and development

• DESIGN — server layers, executor state, dispatch, and acceptance-infrastructure boundaries.
• Development and verification — local commands, CI gates, packaging smoke test, and generated diagnostics.
• AGENTS.md — repository-specific contributor workflow.

Protocol and compatibility

• Protocol conformance matrix — audited requirements, implementation locations, evidence, and gaps.
• Malformed input policy — framing, deserialization, defensive limits, and failure isolation.
• SLiM expressions — Java-only FitNesse table expressions and the Perl compatibility boundary.
• Comparator and rendering context — verified nested FitNesse context limitations.

Acceptance evidence and inventories

• Acceptance coverage — exact isolated and native-suite set comparison, with its machine-readable inventory.
• Individual-page baseline and JSON baseline.
• Native-suite audit and machine-readable audit.
• Native-suite baseline.
• Fixture gap triage and machine-readable triage.
• Pipe migration findings — reviewed transport-specific cases and acceptance behavior.

The inventories and JSON files retain historical reference evidence and reviewed expected behavior. They are not regenerated automatically. A baseline match means no unreviewed change against those expectations; it does not mean every upstream assertion is conformant.