# Let initialization start

The user ran `co wiki init` and reached two questions before seeing a map: may it read Gmail correspondent metadata, then may it read Outlook? Both accounts were already connected. The feedback was direct: start the work, and put authentication instructions in tips.

Our earlier design used a terminal prompt to choose mail sources. That made the same command behave differently in a terminal and a script. It also put a setup decision ahead of the local project and skill maps, which need neither mailbox.

The revised default discovers connected mailboxes and maps their correspondent metadata. A missing connection produces a tip after the local work: run `co auth google` or `co auth microsoft`, then rerun initialization. Explicit `--mail` arguments restrict the selection. Authentication itself stays a separate user action; initialization does not launch a login or install a background schedule.

We kept a distinction that matters when this runs unattended: disconnected is different from failed. A connected or explicitly selected mailbox that fails still produces a partial-failure result, with completed maps preserved. Otherwise a network failure could look like a successful search that found no people.

While checking the new flow, we found another small trap: a setup tip could send someone back to the default notebook instead of the one they had just initialized. Carrying the selected directory into the suggested command makes the tip a continuation of their work. It should not quietly begin a different task.

The feedback changed where setup belongs. The map can already provide value before every source is available. Showing that partial result first gives the person a reason to connect another source, and the remaining setup becomes a next step rather than an entrance exam. The command still has to tell the truth about what it could not read. Starting promptly and reporting incomplete evidence are compatible choices.