The three required config gaps (docs.target, oracle.backend, repo.visibility) say 'ahoy install prompts for the value', but the flags --docs-target/--oracle-backend/--visibility exist and are the only reliable way to answer in a piped run. The fix_hint should name the flag; and a --yes run that still has to prompt for a free-text config value should say so up front rather than blocking on stdin.

The three required config gaps (docs.target, oracle.backend, repo.visibility) say 'ahoy install prompts for the value', but the flags --docs-target/--oracle-backend/--visibility exist and are the only reliable way to answer in a piped run. The fix_hint should name the flag; and a --yes run that still has to prompt for a free-text config value should say so up front rather than blocking on stdin.

Relocated from another repository's ledger on 2026-09-15. It was captured by an ahoy install onboarding session whose working directory was a teaching-materials repository, so the finding landed where nothing could resolve or detect it: that tree has no installer, no plugin root and no ~/.local/bin surface. The id, the found_during stamp and the body are unchanged; only the ledger it sits in has moved. The store resolved correctly — it wrote to the repository it was standing in — and the reason nothing refused the write is recorded as iss-2609120511058115.

Grounds

• pursued: a piped or --yes install reader learns the flag from the gap and the question before any stdin read; a config value gap or value question without its flag, or a --yes run asking a value with no notice above it, would show it wrong