claude-ops:morning-brief: 3 minor test-coverage/maintenance nits (no-lanes telemetry case, rec-maxlen=0 case, usage() header extraction fragility)

[kyle-sexton]

Lane: work · Category: improvement

Triggering example

claude[bot] PR review on #569 (feat for #507 — claude-ops morning-brief dashboard skill) surfaced four minor findings, all explicitly assessed as non-blocking. One (numeric-flag validation) was fixed inline; these three are deferred here.

Observed vs expected

1. Missing test: any=0 telemetry path with no lane-tagged comments. morning-brief.sh's "(no per-lane comments found on the telemetry issue)" branch (line ~389) is reached only when the telemetry JSON is a non-empty array where no comment contains a lane: field (e.g., only scope-note comments) — this specific case isn't covered; existing tests only cover null and a populated-with-lanes array.
2. Missing test: --rec-maxlen 0 (no-truncate) mode. The documented 0 = full semantics are exercised only via the != "0" branch check in source, with no test asserting a long recommendation tail survives untruncated when --rec-maxlen 0 is passed.
3. usage() self-extraction is fragile to header growth. sed -n '2,35p' "${BASH_SOURCE[0]}" hardcodes the header's line range; adding/removing a line from the file-level comment silently truncates or over-runs --help output. Correct today, but a sentinel-based extraction (e.g. matching from the header start to the first blank line) would be more durable.

Notes

All three are cosmetic/coverage-scoped; no correctness, security, or architectural concern per the full bot review on PR #569.

[kyle-sexton]

This was generated by AI during triage.

T1 — routing status: ready. Three independent, well-scoped test/maintenance nits in morning-brief.sh and its test file, all explicitly assessed non-blocking by the source bot review, no design decision.

[kyle-sexton]

Folded into the rolling paper-cut sweep #657 per the v11 intake throttle (paper-cuts batch as sweep lines, consequence findings stay standalone). Content preserved as a checklist line there; this closure is the fold, not a wontfix. [Control tower, triage-audit execution 2026-07-20; operator veto window]

[kyle-sexton]

This was generated by AI during triage.

Reactivated (triage lane — #657 sweep-conversion, rule 8h). This issue was administratively FOLDED-closed into #657 under the v11 intake throttle — not fixed: it still carries status: ready, and no PR closed it (closedByPullRequestsReferences: []). Restoring it to the ready frontier as its own dispatchable work-item, rather than filing a duplicate (its fully-specified content already lives here). Its #657 fold-line is checked off with a pointer back to this issue.

[kyle-sexton]