# Coordinating a connector with a Practice Mode

The two projects stay separate and use separate skills:

- The `build-chasing-mastery-package` skill owns the Practice Mode engine, portable manual
  UI, measurements, progression, Story Events, overlays, and deterministic
  activity scenarios.
- The `build-chasing-mastery-connector` skill owns local source discovery, translation,
  lifecycle, source-event identity, and connector fixtures.

They meet at one narrow declaration: the connector's `observationProtocols`
must exactly intersect the selected activity contribution's
`acceptedObservationProtocols` after both projects independently canonicalize
their package-owned payload schemas. Equality means semantic type, positive
contract version, and RFC 8785 payload-schema digest all match. The digest is
SHA-256 over the canonical UTF-8 JSON plus one trailing newline. A matching name
alone is intentionally incompatible. The Practice Mode engine still
validates current state and may reject an otherwise valid observation (for
example, a finish before a start). That rejection is the expected,
authoritative receipt.

For an end-to-end local proof:

1. Start the activity package's `.chasing-mastery/run.sh dev` and select the
   intended Practice Mode and initial fixture state.
2. Pass its loopback Workbench URL to the connector project's `dev` launcher.
3. Watch Connector Lab show Station lifecycle and receipts while Workbench shows
   the real Attempt transition.
4. Confirm manual input still works through the package UI when declared.
5. Send an undeclared type, version drift, schema drift, or schema-invalid
   payload and confirm the relevant surface reports incompatibility visibly.

Workbench does not grant connector authority and Connector Lab does not run the
activity engine itself. The loopback bridge exists only to prove both real
runtimes agree on the public boundary.
