# Keep invalid test combinations out of coverage counts

Illustrative planning brief; no automatic product import.

Synthetic planning case: A review matrix crosses guest/member actor with view/edit operation. The declared contract makes guest-edit invalid; the other three combinations require functional evidence.

## Decision

Keep three valid functional combinations and one explicit invalid contract case. Do not erase the invalid row or count it as a missing valid feature test.

## Owned work

- Verify the governing contract
  - Owner role: Behavior owner
  - Acceptance evidence: Guest-edit is deliberately forbidden in the external example, not assumed from a role name.
- Separate valid and rejection coverage
  - Owner role: Test planner
  - Acceptance evidence: All four rows remain visible with the correct expected outcome class.
- Review exclusions independently
  - Owner role: Acceptance reviewer
  - Acceptance evidence: The rejected combination has evidence rather than being silently deleted from the plan.

## Workflow

1. Verify the governing contract. Check: Guest-edit is deliberately forbidden in the external example, not assumed from a role name.
2. Separate valid and rejection coverage. Check: All four rows remain visible with the correct expected outcome class.
3. Review exclusions independently. Check: The rejected combination has evidence rather than being silently deleted from the plan.

## Judgment

These are invented contract roles, not claims about TeamBoostAI permissions or role enforcement.


## Filled manual planning note

Keep three valid functional combinations and one explicit invalid contract case. Do not erase the invalid row or count it as a missing valid feature test. The full two-by-two grid has four rows. Its contract partitions them into three valid behaviors and one rejection case; the two sets need different expected results. These are invented contract roles, not claims about TeamBoostAI permissions or role enforcement.


## Workflow questions

### Can every unavailable combination be called invalid?

No. Confirm the actual contract; missing implementation and forbidden behavior are different.

### Is the rejection row irrelevant to assurance?

No. Its expected boundary may need explicit evidence.

## Product connection

Use the owned checks and downloaded brief to discuss this planning decision alongside your TeamBoostAI tasks. Confirm available fields, roles and account features separately. The example is manual; it does not calculate live analytics, create work or run an experiment in the product.

Confirm account availability before adopting this manual outline.

## Original worked case

Synthetic records, manual planning only. No account import or live analytics.

### Inspect the invented case records

Actor | Operation | Declared class | Required review
--- | --- | --- | ---
Guest | View | Valid | Functional evidence
Guest | Edit | Invalid | Expected rejection evidence
Member | View | Valid | Functional evidence
Member | Edit | Valid | Functional evidence

### Reasoning

The full two-by-two grid has four rows. Its contract partitions them into three valid behaviors and one rejection case; the two sets need different expected results.

### Bounded result

Keep three valid functional combinations and one explicit invalid contract case. Do not erase the invalid row or count it as a missing valid feature test.

### Distinct decision

The artifact partitions combination coverage by an explicit validity contract.

### Limits

These are invented contract roles, not claims about TeamBoostAI permissions or role enforcement.

### Definitions and method context

- Original worked-case definitions — Definitions, policy choices, records and calculations are authored for this worksheet. No external standard, statistical validation or live product measurement is claimed.