Athlete comms test harness

What this is

This harness is a repeatable dry-run review workflow for athlete-comms.

It is not a unit test framework. It is a structured evaluation harness for a language-review gate.

Why not a unit test framework

A unit test framework is a good fit when behavior is deterministic code with stable inputs and exact outputs.

That is not the current system. The current athlete-comms implementation is a policy-defined review role. The important questions are:

• did it approve, rewrite, or block correctly
• did it preserve coaching meaning
• did it catch internal chatter and operator leakage
• did it avoid turning dry-run review into delivery

Those are best tested first with repeatable dry-run fixtures and shadow review.

Current configuration

The harness is configured by Markdown artifacts:

• global policy: shared/comms/athlete-comms-policy.md
• athlete-local wording profile: athlete/comms-profile.md
• test protocol: shared/comms/athlete-comms-test-protocol.md
• test fixtures: shared/comms/athlete-comms-test-fixtures.md
• handoff package template: shared/comms/athlete-comms-handoff-template.md
• run log template: shared/comms/athlete-comms-test-run-log-template.md

How to run a test

1. pick a fixture or real draft
2. fill in the handoff template
3. send that package to athlete-comms in dry-run mode
4. capture the returned review result
5. compare actual result against expected result
6. record the outcome in a test run log

Test modes

Fixture mode

Use known examples with expected outcomes.

Good for regression checks after policy changes.

Shadow mode

Use a real outbound draft but keep delivery disabled.

Good for validating the role against live coaching work without live athlete risk.

Adversarial mode

Use intentionally bad candidate bodies.

Good for checking block behavior and leakage detection.

Minimum acceptance standard

Before trusting the gate operationally, it should repeatedly do all of the following:

• approve already-clean athlete messages
• rewrite weak but salvageable messages
• block internal process chatter
• block operator leakage
• preserve technical meaning
• keep send_allowed: false in every dry-run test

When to consider automation

If the dry-run harness proves useful and stable, the next layer could be a scripted regression runner that:

• loads fixtures
• dispatches them to athlete-comms
• parses the YAML response
• compares actual versus expected result
• writes a summary report

That would be automation around the harness, not the first step.

Recommendation

Start with the Markdown dry-run harness now. Only add a unit-test-style scripted runner after we have confidence that the role behavior and result schema are stable.