# Review Checklist

Use this checklist for every milestone. Mark an item complete only when supported by inspected code, tests, or recorded verification.

## Architecture

- [ ] The implementation matches the approved architecture and production flow.
- [ ] Every class and layer has a single coherent responsibility.
- [ ] New boundaries use explicit, minimal contracts.
- [ ] Stable components were preserved unless explicitly targeted.
- [ ] No valid category or state can fall through unexpectedly.

## Correctness

- [ ] All acceptance criteria are implemented.
- [ ] Success, ambiguity, conflict, and failure behavior are deterministic.
- [ ] Exactly-once requirements are enforced where applicable.
- [ ] Identity and ordering requirements are preserved.
- [ ] No partial state can escape a failed operation.

## Scope

- [ ] Only approved functionality was implemented.
- [ ] No future capability or speculative abstraction was introduced.
- [ ] No unrelated refactoring or file modification is present.
- [ ] Explicit exclusions remain absent.

## Dependencies

- [ ] Dependency direction follows the architecture principles.
- [ ] Pure layers have no application, domain-service, framework, database, queue, or network dependencies.
- [ ] Injected contracts are narrow and necessary.
- [ ] No service locator, hidden global state, or dependency cycle was introduced.

## Runtime Safety

- [ ] Protected runtime components are unchanged unless explicitly targeted.
- [ ] Read, decode, dispatch, route, handle, encode, write, and acknowledgement counts remain correct.
- [ ] No hidden loop, retry, reconnect, or duplicate acknowledgement exists.
- [ ] State transitions and cleanup follow established policy.
- [ ] Failure handling cannot return a false success.

## Protocol Correctness

- [ ] Command identifiers, direction, status, sequence, length, and field order are correct.
- [ ] Raw binary and encoded payloads are preserved where required.
- [ ] Unknown protocol data is preserved or rejected according to approved policy.
- [ ] Ambiguous and conflicting evidence is handled conservatively.
- [ ] Protocol authorities are reused rather than duplicated.

## Immutability

- [ ] Protocol, route, handling, and result objects are immutable where required.
- [ ] Exact original values are retained when required.
- [ ] No mutable collection or internal state is exposed unexpectedly.
- [ ] Readonly objects also enforce valid construction.

## Validation

- [ ] Constructors and factories reject impossible states.
- [ ] Length, range, termination, collection, and relationship boundaries are validated.
- [ ] Existing validators and limits are reused.
- [ ] Duplicate or contradictory validation logic was not added.

## Error Handling

- [ ] Errors use the correct typed or fixed boundary category.
- [ ] Failures pass through unchanged where required.
- [ ] Cleanup is deterministic and appropriately tested.
- [ ] Logs and errors expose no credentials, secrets, sensitive payloads, or unsafe internals.

## Testing

- [ ] Focused tests cover all new behavior.
- [ ] Invariant and wrong-category construction tests exist.
- [ ] Boundary and malformed-input tests cover meaningful limits.
- [ ] Production-path tests exercise real composition.
- [ ] Failure paths cover every meaningful family.
- [ ] Invocation, I/O, identity, state, and cleanup assertions are present where required.
- [ ] Stable neighboring behavior has regression coverage.

## Documentation

- [ ] Architecture, roadmap, changelog, and other affected documents are updated.
- [ ] Documentation describes implemented behavior and explicit exclusions accurately.
- [ ] Historical and current behavior are not contradictory.
- [ ] No malformed, duplicated, truncated, or speculative text remains.

## Verification

- [ ] Focused PHPUnit completed successfully.
- [ ] Relevant regression PHPUnit completed successfully.
- [ ] Full PHPUnit produced a passing final summary.
- [ ] Pint passed across the project.
- [ ] `git diff --check` passed.
- [ ] Required protected-file and scope comparisons passed.
- [ ] Test, assertion, skip, failure, formatter, and diff results are recorded.

## Regression Risk

- [ ] Changed public return types and contracts have all callers covered.
- [ ] Existing state, I/O, failure, and acknowledgement behavior remains intact.
- [ ] No vendor, configuration, migration, or operational behavior changed unintentionally.
- [ ] The working tree contains only approved milestone changes.

## Readiness for Commit

- [ ] Self-review is complete.
- [ ] Independent review returned an approving verdict.
- [ ] Required corrections were completed and reverified.
- [ ] Known limitations and exclusions are recorded.
- [ ] No production or documentation work remains.
- [ ] Commit is explicitly authorized under the master protocol.