# Connector authoring interview

Resolve these facts from the request before asking the author. Ask only for the
remaining decisions, in one compact batch.

1. **Observed source** — What physical app, tool, device, or synthetic signal is
   being observed? What stable source identity should Station show?
2. **Practice Mode contract** — Which activity contribution consumes the input,
   and what exact type/version/payload-schema protocols does it accept?
3. **Observation semantics** — What does each protocol mean, what bounded JSON
   facts does its self-contained JSON Schema require, and what makes a source
   event uniquely replay-safe?
4. **First proof** — What ordered fixture proves one useful Attempt end to end?
5. **Failure proof** — What duplicate, malformed, unavailable, timeout, or
   terminal behavior must fail visibly?
6. **Manual fallback** — Can the activity still be completed through its own
   portable manual-input UI when the connector is unavailable?
7. **Local authority** — Does the real integration require network, filesystem,
   serial, HID, screen capture, credentials, or another grant? This skill's
   current Lab accepts none. Record the missing grant; do not fake it.

Good defaults:

- stable package and contribution IDs derived from the author's namespace;
- one source type and the smallest useful observation vocabulary;
- stable source event IDs supplied by the origin, not random IDs created per
  delivery;
- a manual fallback unless the activity is intrinsically automatic-only;
- a happy fixture plus exact duplicate replay from the first pass.
