Fix the v0.3.0 launch crash: attach the input node before prepare()

[missingbulb]

Closes #72.

v0.3.0 crashes about a second after every launch — menu-bar icon appears, then vanishes. Regression from #59. Reported from the owner's Mac mini, crash report LaughCounter-2026-07-29-111329.ips.

EXC_CRASH (SIGABRT)
required condition is false: inputNode != nullptr || outputNode != nullptr
  AVAudioEngineGraph::Initialize → -[AVAudioEngine prepare]
  AudioHub.prepareFormat() → AppDelegate.finishListening(generation:)

Cause

AVAudioEngine initializes its graph inside prepare() and asserts that at least one node is attached. A freshly constructed engine has none — inputNode is created lazily on first access, and touching the property is what attaches it.

#59's per-start rebuild replaced the engine and called prepare() with nothing in between. The single-engine code had satisfied the precondition by accident: requestListening() calls audio.stop(), which reaches engine.inputNode.removeTap(onBus: 0) and materialized the node on the long-lived engine well before any prepare() ran. Rebuilding the engine after that call removed the accident without replacing it with anything deliberate — so it failed on the very first start, every time.

Fix

• makeEngine() materializes the input node as part of building an engine, and both init() and renewEngine() go through it. The precondition is satisfied by construction rather than by a call order somewhere else that a later edit can quietly break.
• engine.prepare() is now trapped too. Fix the installTap crash on every audio device change, and reactivate the counter on return from standby #59 wrapped only installTapOnBus, which is why the trap was not in this path at all. This crash proves prepare() raises as well, and a raise there is equally fatal.
• Version → 0.3.1 so the crashing build stays distinguishable.

The trap remains unexercised: nothing has yet demonstrated it catching an NSException that unwinds through the intervening Swift closure frame, which is not guaranteed to work. It is a hoped-for backstop, not a proven one — the two structural fixes (#61's fresh engine, this one's attached node) are what actually keep these paths off the exception route.

Testing

CI compiles it. That is not a meaningful gate for this file — compile-green passed two crash-on-launch builds in a row, because every raise-vs-throw bug in AudioHub is invisible to the compiler and reachable in the first second of a run. The real check is launching 0.3.1 on the Mac mini and seeing the icon stay up, then listening started in the activity log.

A unit-test target calling AudioHub().prepareFormat() would have caught this exact class of bug — it either throws or returns, and must never raise. Noted as follow-up in #72 rather than bundled here, since it needs a test target and a swift test step in both DMG workflows, and this fix should ship on its own.

dev/procedures/mac-audio-lifecycle.md records both the node-attachment rule and the "compile-green is not a gate for this file" lesson.

---

Generated by Claude Code