fix(miner): fail fast instead of hanging when init --interactive has no TTY

[JSONbored]

Summary

• init --interactive's first prompt previously blocked forever on a stdin that can never receive a real line of input — a plain ssh host "loopover-miner init --interactive" with no allocated pty, or any other no-TTY/CI invocation, just hung until something external killed the process. Confirmed directly during Verify + document AMS's standalone usage end-to-end against a real, non-gittensor GitHub repo #6205's live verification.
• createWizardIo now exposes isInteractive (the real input stream's own isTTY), and runInteractiveInit checks it before issuing any prompt: a non-interactive io fails fast with a clear message pointing at the env-var-only setup path (GITHUB_TOKEN, MINER_CODING_AGENT_PROVIDER, ANTHROPIC_API_KEY/OPENAI_API_KEY) recommended for unattended/fleet deployments per AMS credentials: decide the recommended default (subscription OAuth vs API key) for claude-cli and codex-cli #6845, then loopover-miner doctor to verify.

Closes #6846

Test plan

• npm run test:ci — full local gate green
• New regression tests for the non-interactive fail-fast path (both the pure runInteractiveInit check and createWizardIo's real-adapter isInteractive detection)
• Updated the existing e2e test, whose own comment documented the prior hang-then-kill behavior this fix eliminates

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.70%. Comparing base (febb12a) to head (59bb7d9).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6907   +/-   ##
=======================================
  Coverage   93.70%   93.70%           
=======================================
  Files         685      685           
  Lines       68298    68306    +8     
  Branches    18719    18719           
=======================================
+ Hits        63999    64007    +8     
  Misses       3302     3302           
  Partials      997      997           

Flag	Coverage Δ
shard-1	43.62% <0.00%> (-0.07%)	⬇️
shard-2	36.80% <0.00%> (+<0.01%)	⬆️
shard-3	32.55% <0.00%> (-0.12%)	⬇️
shard-4	34.42% <0.00%> (-0.43%)	⬇️
shard-5	31.64% <0.00%> (-0.28%)	⬇️
shard-6	45.84% <100.00%> (+0.42%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
packages/loopover-miner/lib/init-wizard.js	100.00% <100.00%> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-17 12:24:54 UTC}

3 files · 1 AI reviewer · no blockers · readiness 88/100 · CI green · unknown

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This fix adds an `isInteractive` flag to `WizardIo` (real terminal check via `input.isTTY`) and short-circuits `runInteractiveInit` before any prompt when it's false, replacing an indefinite hang with a clear exit-code-3 message pointing to env-var setup. The logic traces correctly: `createWizardIo` sets `isInteractive: Boolean(input.isTTY)` from the real stream, `runInteractiveInit` checks `io.isInteractive === false` (so fake test `io` objects without the field default to interactive, preserving existing test behavior), and the new unit tests exercise both the pure check and the real adapter's TTY detection plus an updated e2e test. This is a well-targeted, narrow fix with good test coverage of both branches of the new condition.

Nits — 4 non-blocking

• packages/loopover-miner/lib/init-wizard.js:148 returns a bare exit code `3` with no named constant or comment on why `3` was chosen over other non-zero codes; a short inline note or constant would help future readers distinguish it from other wizard/doctor exit codes.
• The fail-fast check only covers the wizard's very first entry point (packages/loopover-miner/lib/init-wizard.js:139-148); worth double-checking there's no other no-TTY-dependent prompt path reachable without going through `runInteractiveInit` first (not visible in this diff, but worth a mental note).
• Consider extracting the exit code `3` as a named export (e.g. `EXIT_NON_INTERACTIVE = 3`) if other wizard callers or docs need to reference it consistently.
• PR author also opened the linked issue — Link an issue that was opened by a different contributor, or provide a rationale for why this self-authored issue represents genuine discovery work.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6846
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 33 registered-repo PR(s), 26 merged, 375 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 33 PR(s), 375 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, Ruby, Go, JavaScript, MDX, Shell, Solidity
• Official Gittensor activity: 33 PR(s), 375 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Then work through the remaining 2 steps in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.