connect: chat lines in Pings (Circles) are never handed off — blocked as read_unresolved #903

Summary

Thanks for connect, it's working great for project @mentions (sub-second pickup from the feed socket). One gap: a message sent to the agent in a Ping (1:1 or group Circle, outside any project) is seen on the feed instantly, but admission blocks it with state=blocked reason=read_unresolved and it is never handed off. There's also no way to serve Pings: connect setup --serve <circle bucket id> returns 404 because a Circle isn't a project.

For a personal/team agent, Pings are the most natural way people ask it for things, so it would be great if connect could handle them (opt-in is fine).

Environment

• basecamp-cli v0.13.2 (basecamp-sdk/go v0.24.0), Linux
• Agent identity: a regular Basecamp user account used as a bot (agent accounts aren't available on our account yet)

Steps to reproduce

1. basecamp connect setup -P bot --serve <project id> and run basecamp connect -P bot.
2. From a trusted person, send the bot a Ping (1:1 or group).
3. Watch connect's log / ledger.
4. Optionally: basecamp connect setup -P bot --serve <circle bucket id>.

Expected

The Ping line from a trusted person is admitted as a request (or at least there is a documented opt-in to serve Pings).

Actual

• The chat.line.created row arrives on the live feed immediately.
• Admission records state=blocked reason=read_unresolved (retried every 10 min for a day, never resolves).
• Step 4 fails with 404 — the Circle can't be served.

Why (code refs at v0.13.2 / sdk go/v0.24.0)

• Admission reads every pointer through Summarize; a chat line must be located under a Campfire, and an unresolved one maps to read_unresolved:
  • https://github.com/basecamp/basecamp-cli/blob/v0.13.2/internal/connector/admission/verdict.go#L341-L368 (incl. chat.line.created && summary.CampfireID <= 0)
  • https://github.com/basecamp/basecamp-cli/blob/v0.13.2/internal/connector/admission/verdict.go#L727-L728
  • https://github.com/basecamp/basecamp-cli/blob/v0.13.2/internal/connector/admission/matrix.go#L131-L132 — "a chat line found under no visible Campfire"
• The SDK discovers the Campfire from (1) the bucket's project dock and (2) the account-wide Campfire listing filtered by bucket. A Circle has no project dock, and (as far as we can tell) Ping Campfires aren't in that listing, so no candidate exists:
  • https://github.com/basecamp/basecamp-sdk/blob/go/v0.24.0/go/pkg/basecamp/recording_summary.go#L628-L639
  • https://github.com/basecamp/basecamp-sdk/blob/go/v0.24.0/go/pkg/basecamp/recording_summary.go#L1019-L1030
• Even if the read resolved, routing is per served project; a record in an unserved bucket is no_route:
  • https://github.com/basecamp/basecamp-cli/blob/v0.13.2/internal/connector/admission/matrix.go#L150-L161
• README/skill describe serving only in terms of projects (--serve 12345 # ... which projects); Pings aren't mentioned as unsupported or supported.

Proposed approach

1. SDK: let chat-line discovery resolve Ping lines — e.g. add Circles/Pings as a third candidate source (the API's ping/circle Campfire listing), or resolve a line by bucket id when the bucket is a Circle.
2. CLI: add an opt-in serve target, e.g. connect setup --serve pings (or --serve-pings), treated like a served project with these rules:
   • a Ping line is a request only if the agent is a participant of that Circle and the author is on the trust list (1:1 Pings are inherently addressed to the agent; group Pings could additionally require an @mention);
   • routed to a default/ping work directory.
3. Docs: until then, a line in the README/skill saying connect serves project content only and Ping lines will block as read_unresolved would save people some debugging.

Happy to help test, or to attempt a PR if you'd be open to one and can say which direction you prefer.