hooks intelligence route --top-k returns ZERO alternatives for 5-9 and for 50/60/70/500/999, but works for 2-4 and 10/20/40/100/400 — asking for more candidates returns none

Summary

hooks intelligence route --top-k <n> returns zero alternatives for n in 5–9, and for larger values whose leading digit is 5–9 (50, 60, 70, 500, 999) — while working correctly for 2–4 and for 10, 11, 12, 20, 40, 100, 400. The behaviour is fully deterministic but non-monotonic: asking for more candidates can return none.

Version: agentic-flow 2.1.2, Node v22.23.0, macOS 15.

Observed mapping

Alternatives printed, counting the - agent (nn%) lines. Each value verified stable across 5 consecutive runs:

k:     1   2   3   4   5   6   7   8   9   10  11  12
alts:  0   1   2   3   0   0   0   0   0   4   4   4

Larger values:

k:     20  40  50  60  70  100  400  500  999
alts:  4   4   0   0   0   4    4    0    0

And with leading zeros:

k:     05  007
alts:  0   0

So:

• k = 1..4 → k-1 alternatives, which is correct (one slot is the recommendation itself).
• k = 5..9 → 0.
• k = 10, 11, 12, 20, 40, 100, 400 → 4, i.e. the full candidate pool.
• k = 50, 60, 70, 500, 999 → 0.
• k = 05, 007 → 0.

The candidate pool appears to hold 5 entries (recommendation + 4), so 4 is the correct ceiling.

What I could not determine

The grouping looks like a string/lexicographic comparison — every working multi-digit value begins with 1–4, every failing one begins with 5–9, and "10" < "5" is true as a string. I tested that prediction and it held for 20, 40, 400 (work) and 6, 60, 70 (fail).

But it is falsified by leading zeros: "05" < "5" and "007" < "5" are both true lexicographically, yet both return 0. So a plain string comparison against "5" is not the mechanism, and I did not want to file a confident root cause I had disproved. Reporting the observations instead.

What can be said: the value is not being used as a plain integer bound, since a numeric slice(1, k) over a 5-element pool would give min(k-1, 4) for every k and never 0 for k ≥ 5.

Reproduce

for k in 1 2 3 4 5 6 7 8 9 10 11 12 20 50 100 500; do
  printf 'k=%-4s alts=' "$k"
  npx agentic-flow hooks intelligence route "Optimize database queries" --top-k $k 2>/dev/null | grep -cE '^   - '
done

Two smaller observations on the same command

Invalid values are accepted silently. --top-k nonsense produces the same output as --top-k 999 (0 alternatives, exit 0, no warning). A non-numeric bound should be rejected.

The listed alternatives outrank the recommendation. Same shape as #186:

🎯 Agent: coordinator      📊 Confidence: 95.0%
🔄 Alternatives:
   - researcher (96.8%)
   - optimizer  (96.6%)

The JSON agrees (confidence: 0.95 with alternatives[0].confidence: 0.9676…), so this is not a text-rendering artefact. The confidence is also pinned at exactly 95.0%, as reported in #186 for hooks route.

Note on what works

Unlike several sibling commands, hooks intelligence route renders correctly and its --json agrees with its text output — no [object Object], no undefined. The intel abbreviation shown in the docs also resolves correctly.

Related

• #186 — hooks route: confidence pinned at 95.0%, alternatives outrank the recommendation, all factors NaN.
• #199, #201, #202 — other options accepted and ignored (--depth, --detailed, --mode). This one differs: --top-k is partially honoured, which makes the dead range harder to notice.

The payload names the hooks intelligence route CLI entry point and its --top-k and --json options, but no source files or tests. Start by tracing how --top-k is parsed and applied to the candidate pool, then check validation and ranking behavior. Done means numeric bounds return the expected alternatives, invalid values are rejected, and JSON matches the corrected output.