Six bugs found during a fresh 7.1.1 install (TELOS parser, Doctor.ts, hook wiring, timezone default)

[waveman2020-sudo]

Bug report: multiple issues found during a fresh LifeOS 7.1.1 install

1. GenerateTelosSummary.ts — YAML frontmatter swallowed as a bogus first entry

readTelosFile() reads raw file content including leading YAML frontmatter. When a source file (e.g. MISSION.md) has no bullet/heading-ID items, parseItems() falls back to paragraphItems(), which splits on blank lines. The frontmatter block (---\nkey: value\n...\n---) forms one contiguous paragraph that doesn't start with # and isn't a bare --- line, so it survives the filter and becomes a garbage first item — e.g. M0: --- provenance: interview last_updated: ....

Fix applied locally: strip a leading ^---\n[\s\S]*?\n---\n block in readTelosFile() before any parsing.

2. GenerateTelosSummary.ts — parseGoals() silently drops all goals under time-horizon headings

bucketOf() only recognizes headings containing "active", "deferred"/"ongoing", or "completed"/"done". A GOALS.md organized by time horizon ("## Long-Term (5+ years)", "## Medium-Term", "## Short-Term") matches none of these, so current becomes null after the first heading and every subsequent bullet is silently dropped from the summary. This was previously masked because bug #1's frontmatter-garbage item kept the goals count non-zero, so the fail-loud zero-item guard never fired.

Fix applied locally: treat any heading containing "term" as active (in addition to the existing checks), since Long-/Medium-/Short-Term are all currently-pursued goals.

3. Doctor.ts — Linux browser detection never checks for Brave

chromeBinary()'s candidate list includes the macOS Brave path but only google-chrome/chromium/chromium-browser on Linux — no Linux Brave path at all. A Linux user running only Brave gets a false "no Chrome/Brave/Chromium binary found" even with Brave installed and working.

Fix applied locally: added /usr/bin/brave-browser and /usr/bin/brave-browser-stable to the candidates list.

4. Doctor.ts — ElevenLabs 402 errors misdiagnosed as generic quota exhaustion

The network probe for the voice capability checked for famous_voice_not_permitted in the error body but treated every other 402 as generic "quota/credits exhausted." A free-tier account hitting paid_plan_required ("Free users cannot use library voices via the API") gets told to swap voices or wait for quota reset — neither fixes the actual cause, which is a plan-tier restriction on ANY library voice via the API, not a specific voice or a quota count.

Fix applied locally: detect paid_plan_required in the error body and report the real cause; fall back to including the raw error detail for any other 402 rather than assuming quota.

5. MemoryHealthGate.hook.ts — registered under the wrong lifecycle event

The hook's own header comment says "runs the autonomic-memory health check on every turn end" (i.e. Stop), and its output (a cached health snapshot read by the statusline every render) only has value if refreshed frequently. But in the shipped settings.json, it's registered under SessionEnd — which fires once, only when the whole session finally closes. In a single long-running session, this means the health cache never refreshes, and the statusline can show a stale "NEEDS ATTENTION" warning for hours/overnight after the underlying issue is already resolved, with no way to tell the display is stale.

Fix applied locally: added the hook to the Stop array too (kept the existing SessionEnd registration as a redundant safety net for edge-case session exits that might skip Stop).

6. settings.json — default principal.timezone ships as America/Los_Angeles

On a fresh install, settings.json's principal.timezone defaults to America/Los_Angeles rather than being left unset or forcing interview input. Since LIFEOS_StatusLine.sh uses this value to render rate-limit reset times, anyone outside Pacific time gets a silently wrong reset-time display — off by however many hours separate their real zone from Pacific — with no error, warning, or indication the value was never actually set for them. In our case this made a reset time that was still ~20-25 minutes in the future read as already 30+ minutes in the past.

Suggested fix: ship with no default (force an explicit interview answer), or at minimum default to the system's detected $TZ//etc/timezone rather than a hardcoded US zone.

---

All fixes were applied locally and verified working. Happy to submit as a PR if that's preferred over an issue — let me know the contribution process.