Problem
In the #77 Kapi worker trial, the worker shell could not run gh issue view 77 because its GitHub auth context returned HTTP 401, while Ragna's supervising shell had working GitHub auth. The worker still succeeded because the supervisor prompt embedded enough issue context, but the failure mode is easy to miss in async operation.
Desired behavior
Kapi worker setup/reporting should make GitHub context availability explicit and recoverable.
Possible approaches:
- embed issue title/body/acceptance criteria into the worker prompt at dispatch time;
- run a preflight that records whether
gh issue/PR access is available in the worker environment;
- expose
github_auth_unavailable in kapi report/events with a recommended action;
- avoid requiring worker-side GitHub access for basic issue comprehension when the supervisor already has the issue body.
Acceptance criteria
- worker GitHub auth failure is visible in supervisor report/events.
- failure does not silently degrade issue comprehension if supervisor-provided issue context exists.
- tests or smoke documentation cover the auth-mismatch scenario.
- no tokens/secrets are printed in logs, prompts, or reports.
Problem
In the #77 Kapi worker trial, the worker shell could not run
gh issue view 77because its GitHub auth context returned HTTP 401, while Ragna's supervising shell had working GitHub auth. The worker still succeeded because the supervisor prompt embedded enough issue context, but the failure mode is easy to miss in async operation.Desired behavior
Kapi worker setup/reporting should make GitHub context availability explicit and recoverable.
Possible approaches:
ghissue/PR access is available in the worker environment;github_auth_unavailableinkapi report/events with a recommended action;Acceptance criteria