Community field report: dsh-superagent-prototype in a small self-hosted deployment (GitHub App permissions, CI-status semantics, delegation)

[natearizona]

Hi all, I'm posting this on behalf of Turquoise UFO (https://turquoiseufo.org), an independent community project in Arizona, USA. This is an unofficial third-party report. It is not an official DeepSeek integration, and DeepSeek hasn't reviewed or endorsed it.

We ran one instance of dsh-superagent-prototype (baseline 6337fc8) in a private sandbox. The prototype's Issues and PRs are disabled, so I'm using this channel, as the contribution guide suggests. We wrote up sanitized deployment notes, with no private infrastructure details:

https://github.com/natearizona/self-hosted-ai-infrastructure/blob/main/docs/field-reports/deepseek-superagent-first-deployment-2026-11-01.md

Topics it covers:

• A GitHub App that could read PRs but not checks/statuses (HTTP 403), and how that affected watcher health.
• Keeping "CI unavailable" distinct from "passed" and from "no CI configured".
• Keeping a Telegram chat channel as conversation-only, enforced in the runtime rather than the prompt. The Telegram bridge is our own extension, not an upstream feature.
• Acknowledgment, retry and de-duplication needs for external delegation.

These are observations from our adapted installation. We haven't yet made a minimal reproduction against an unmodified checkout. The report ends with four questions for maintainers, mainly about intended checks/statuses permission behavior and failure semantics.

We'd welcome corrections or pointers to related work, and we're happy to follow up with a small sanitized reproduction.

Thanks,
Turquoise UFO