feat(setup-repo): repo-aware summaries + GH_TOKEN setup, DRY token storage

[tildesrc]

Improves the operator UX of the setup-repo shell workflow (the host-side claude setup-token flow). Started as adopting #309 and folds that in with four further improvements.

What changed

• Opening summary. The flow now opens with two bulleted lists: what we know about the repo (name + source — local checkout vs GitHub remote, classified from the repo's git URL) and what its setup entails (Claude credential always; GH_TOKEN for GitHub repos), each marked needed / already-configured / not-needed.
• GH_TOKEN setup (GitHub repos only). A new step mirroring the Claude-token step: interactive gh auth login, then capture with gh auth token and write it into the repo's env-file. Gracefully guides the operator to add GH_TOKEN manually when gh isn't installed on the host. Local repos skip it entirely.
• DRY token storage. Generalized store_oauth_token into store_env_token <VAR> <token> <file> — the single implementation both the Claude token and GH_TOKEN write through (comment out the active line, drop the placeholder stub, append the new one). store_oauth_token stays as a thin wrapper.
• Bulleted closing summary. The end-of-run summary is now a bullet per step and its outcome.
• Hint wording (Update dashboard hints for task management #309). Folded in the detach-reassurance and actionable-drop wording (and fixed its "dashbaord" typo).

Plumbing

SetupRepo runs with clone_repo = False, so the script has no checkout to inspect. To classify local vs GitHub, ShellRunner.spawn now exports PANOPTICON_REPO_NAME / PANOPTICON_REPO_GIT_URL, passed through by the spawner from the repo record. No model/DB change — Repo.git_url already exists.

[tildesrc]

Review — setup-repo onboarding, from the ICP's perspective

Reviewed from the lens of the target user: a terminal-native, review-first, security-conscious operator. The bones are strong — the upfront "This repo / To set up" status block, the detach hint that detects the actual prefix/detach keybinding (not a hardcoded C-b d), default-No on both replace prompts, and the careful store_env_token (comment-out history, atomic mv, chmod 600) are all exactly the trustworthy, legible behavior this audience rewards. Three things to fix before merge, plus copy.

Opening copy

The current opener reads as credential-harvesting: "collect persistent credentials" (this user flinches at "collect your credentials"), "persistent" raises an unanswered "persisted where?", and "hijacking yours" is alarmist and slightly inaccurate — the wrong register for calm infrastructure. It also narrates the system's goal rather than telling the user what happens and how to stay in control.

Suggested replacement:

Setting up '$repo_name'. Task containers use per-repo credentials from this repo's env-file — a Claude token, and a GH_TOKEN for GitHub repos — so the agent runs on its own tokens, not your personal session. You can skip this and set up your own secrets by editing $env_file yourself.

Other copy

• "collect" reads as harvesting throughout — "nothing collected," "Collect a new token anyway?" Swap for mint / set up / add (e.g. "Mint a new token anyway?", "…nothing set up.").
• The "use your own" path is clunky. To supply their own token the user must detach → drop the task → hand-edit → re-run, and the copy surfaces internal mechanics ("drop this task using 'x'"). This audience very likely already has a token; consider an inline "paste your own token" so BYO is a keystroke, not a cancel-and-restart.
• "so Claude can use them" hardcodes Claude — "so the agent can use them" ages better if CLI-agnosticism is on the roadmap.
• GH adoption says "the GH_TOKEN from your environment" without confirming which token (no last-4) — worth matching the masked-display consent model elsewhere.

Workflow — three to fix

1. GH adoption defaults to Yes ([Y/n]). Copying a credential from an ephemeral env var into a persisted 0600 file is a heavier commitment than the env var was, and it contradicts the per-token default-No consent posture. Recommend flipping to [y/N]. (Defensible either way — it's the operator's own token — but default-No is the more consistent, respectful choice.)

2. The Claude token isn't adopted from the environment the way GH is — and that can silently mis-report "configured" → a container that 401s. claude_configured is true whenever CLAUDE_CODE_OAUTH_TOKEN/ANTHROPIC_API_KEY is set, and the shell runner inherits the host env (that's how the GH branch finds $GH_TOKEN). So a Claude token that lives only in the operator's shell env (not the repo's env-file) is reported "already configured" — but it's never written to the env-file, and the container gets --env-file, not the host env. Setup says "done," the agent can't authenticate. Fix: either adopt a host-env Claude token into the file (symmetric with GH, with consent), or make the "configured" check env-file-specific — env_file_has_var already exists for exactly this.

3. No inline "bring your own" for either token (see copy note) — the fast path for an already-authenticated operator is missing; the flow optimizes for mint-fresh.

Net: trustworthy engineering, right structure. The gaps are tone (harvesting language), one correctness edge (#2), and consent-default consistency (#1).

🤖 Automated review via Claude Code

[tildesrc]

Addressed the review (pushed):

Workflow fixes

1. GH adoption now defaults to No ([y/N]) — consistent with the per-token consent posture.
2. "Configured" is env-file-specific. claude_configured (and the summary) now check env_file_has_var, not the sourced env. A Claude token that lives only in the operator's shell is no longer mis-reported as configured — it correctly shows "needed" and gets adopted into the env-file (the container sees --env-file, not the host env).
3. Inline BYO for both tokens. Each credential can be adopted from the environment or pasted inline; Claude still falls back to claude setup-token. No more detach → drop → hand-edit → re-run. Claude is now symmetric with GH (shared store_token).

Copy

• New opener uses your suggested register — what happens + staying in control ("per-repo credentials", "not your personal session", opt out by editing the env-file); dropped "collect persistent credentials"/"hijacking".
• "collect" → "mint / set up" throughout; agent-neutral wording where it was Claude-specific.
• Adoption now shows a masked tail (last 4, via a new mask_last4) so you confirm which token.

Only offers to adopt a var that isn't already the env-file's own, so replacing a configured token goes straight to paste/mint.