dsh-superagent-prototype: two more findings (notification delivery is never checked; the test suite fails under a non-English locale)

[xxxxkkkqq]

I installed deepseek-ai/dsh-superagent-prototype from a fresh clone following its SETUP.md (Ubuntu, Node.js 24.14.0, dsh 0.2.1-rc.5, gh 2.103.3), ran it against a private repository, and took a request from an issue through to a pull request. Two of the defects we hit are not covered by #11700 (which I can confirm: we hit the Node 24 process-name defect too, and a one-line form of that fix is on fix/node24-and-locale in our fork — taking the name from the command line, as described there, is the better fix).

1. Notification delivery is never checked, so a deployment can look healthy and receive nothing

After setup reported no problem, a mention of the agent account in an issue produced no Ticket, and nothing anywhere said why. The GitHub Source stayed ready with the detail

0 notifications; next poll ≥ 60s

and stats: {"received": 0, "filtered": 0, "lastAt": ""} — the same state it reports for a repository where nothing has happened. Every other part was ready, so the hourly check in docs/006-deployment.md reported success as well.

What we could measure:

• GET /notifications?all=true as the agent account returns [];
• the issue timeline (GET /repos/{owner}/{repo}/issues/N/timeline) records mentioned events for it, and the issue was assigned to it;
• an operator account holding the same token scopes receives notifications for the same repository, including a mention generated by a comment the agent account posted — so notifications are produced here;
• after gh auth refresh -h github.com -s notifications and updateSubscription(state: SUBSCRIBED) (viewerSubscription moved UNSUBSCRIBED → SUBSCRIBED, GET repos/…/subscription then {"subscribed": true, "ignored": false}), the agent's list is still [].

We could not find a defect in the polling request itself, so this is not a claim about pollNotifications. It is about the absence of a check: resolveDeployment already verifies that the agent account can push to the watched repository, and it could verify notification access just as cheaply — GET /repos/{owner}/{repo}/subscription fails with an explicit scope error when the notifications scope is missing, and gh auth login does not request that scope by default. Turning that into a SetupError with its own place/code, and naming the scope in the Accounts section of docs/006-deployment.md, would have saved us the afternoon. Reporting something other than ready when the notifications call itself fails would also distinguish "nothing happened" from "notifications do not reach this account".

The fallback we used works and is worth a sentence in docs/006-deployment.md: with the Source's observeIssues and observeComments switched on, the Source reads the repository directly, and an allowed sender who addresses the agent is admitted as explicit regardless, so requests arrive without depending on the account's notifications.

2. The test suite fails under a non-English locale

pnpm vitest run fails on a clean clone with LANG=zh_CN.UTF-8 (1196 passed, 1 failed):

FAIL  tests/environment.spec.ts > ticket directory check > fails when git cannot read the repository's configuration, instead of passing it
AssertionError: expected [Function] to throw error matching /bad config/ but got 'fatal: 文件 .git/config 中错误的配置行 1'

The behaviour under test is right — the ticket-directory check must fail, not pass — but the assertion reads a message git localizes, so it holds only in an English locale. Running the test's subprocess helper with LC_ALL=C makes it deterministic; that file then passes 13/13 in both locales.

(Our full suite still shows one other failure, the Feishu event-consumer health expectation in tests/sources.spec.ts — expected { state: 'ready' } to match { state: 'error', detail: StringContaining "JSON" }. Your run passing 1200/1200 suggests it is environment- or timing-sensitive rather than a product gap, so we did not touch it. Feishu is not configured here.)

3. An operator note: a second gh config directory can leave an older gh acting as the agent

docs/006-deployment.md has operators create a wrapper that signs the agent account in under its own GH_CONFIG_DIR. On this machine that left the distribution's older gh 2.45.0 (which resolves its token from the shared keyring, not from the wrapper's directory) presenting the agent's token while gh auth status still named the operator's account. The credential.helper shipped in ~/.gitconfig points at that binary, so the operator's own git over HTTPS began authenticating as the agent account and could no longer reach their private repositories:

$ git ls-remote https://github.com/<operator>/<private>.git HEAD
remote: Repository not found.

# the two binaries' tokens, compared by hash: /usr/bin/gh and the agent wrapper share one token

Pointing the credential helper at the same gh binary the operator uses interactively (/home/<user>/.local/bin/gh, 2.103.3) restored pushes, with the wrapper still acting as the agent. If this is reproducible elsewhere, a warning beside the wrapper instructions — or a check that gh auth status resolves to the intended account — would prevent it; the symptom appears far from its cause, as a permissions failure in an unrelated repository.

Where the code is

Both fixes are on fix/node24-and-locale in our fork, ready to become pull requests if the repository is opened for contributions: https://github.com/xxxxkkkqq/dsh-superagent-prototype/tree/fix/node24-and-locale