fix: stop the daily KPI run hanging when no manual activities are given

[DamengRandom]

Closes #32

The bug

promptUser (src/tools/manual-kpi.tool.ts) only resolved from rl.question's answer callback. On a stdin that is already at EOF, readline emits close and that callback never fires, so the promise never settles.

Dispatching daily-kpi with its optional activities input left blank sets MANUAL_ACTIVITIES='' — falsy — so collectActivities takes the interactive readline path on a runner with no keyboard. src/agent/index.ts:132 awaits it, so the job stops there: no KPI record, and no alert either, since a hang is not an exception. Node then drains the event loop and exits 0, so the workflow goes green having saved nothing.

The change

Resolve on readline's close event with an empty answer — which the existing loop already treats as "done". The answer is resolved before rl.close(), so the first settle always wins and the interactive path is unchanged.

Observed vs reasoned

Observed (run from the repo root with npx tsx, stdin from /dev/null, MANUAL_ACTIVITIES=''):

• Before: the promise is still unsettled at beforeExit, and the process exits with code 0 — full probe output in Daily KPI run hangs then exits 0 when the activities input is left blank — nothing is saved, no alert #32.
• After: RESOLVED: {"activities":[],...}.
• The three new tests fail on all three cases without the source change and pass with it.

Reasoned, not observed: that a real GitHub Actions runner gives the step a /dev/null stdin. I reproduced that shape locally rather than on a runner. The rest of the pipeline consequence (that runDailyJobs therefore never saves a record and never alerts) follows from src/agent/index.ts:132 and the try/catch at :41-47; I could not execute it here as it needs a database and an LLM key.

Tests

src/tools/manual-kpi.test.ts runs the tool in a child process — readline writes its prompt to stdout, which corrupts the test runner's own reporting channel if run in-process. This mirrors the existing src/fatal-error.test.ts pattern.

• closed stdin ⇒ zero activities instead of a hang (fails without the fix)
• an activity typed before stdin ends is still recorded
• a blank line still ends input

Noted, out of scope

With a piped (non-TTY) stdin, only the first line is ever collected: each prompt builds a fresh readline interface, and closing the first one discards whatever it had already buffered from the pipe. That is pre-existing and unchanged by this PR — before it, the second prompt hung instead. Interactive TTY use and the MANUAL_ACTIVITIES path are unaffected.

Checks

pnpm test (79 pass), pnpm tsc, pnpm format:check all pass.

---

Generated by Claude Code