parseGoals buckets by section heading, so on the shipped TELOS template no goal can ever leave "Active Goals"

---

**Version:** 7.40.4 (`skills/LifeOS/install`, the shipped payload)

## What's broken

`parseGoals()` decides whether a goal is active, deferred or completed from the **heading of the section it sits under** — never from what the goal says about itself.

`LIFEOS/TOOLS/GenerateTelosSummary.ts:305-316`:

```ts
const bucketOf = (heading: string): Bucket | null => {
const h = heading.toLowerCase();
if (h.includes('active')) return 'active';
if (h.includes('deferred') || h.includes('ongoing')) return 'deferred';
if (h.includes('completed') || h.includes('done')) return 'completed';
if (h.includes('note')) return null;
// Any other unrecognized heading (e.g. "## Detail") is treated as active
// goal content — never silently discarded (issue #1473).
return 'active';
};
```

The shipped template has exactly one goals heading, and it contains none of those words —
`USER/TELOS/TELOS.md:33`:

```
## GOALS (measurable milestones toward the problems)
```

So every goal a template-following user writes falls through to `return 'active'`. The `deferred`
and `completed` buckets — both consumed downstream at `GenerateTelosSummary.ts:706` and `:715` —
are **unreachable by construction** for anyone who keeps the shipped structure. A goal marked
`✅ COMPLETED` in its own body still renders under `## Active Goals (2026)`.

This is not the same defect as #1473. That one is about content under an unrecognized heading being
*dropped*; the `return 'active'` fallback is its correct fix and should stay. This is that the
per-goal status is never consulted at all.

## Why it matters

`PRINCIPAL_TELOS.md` is `@`-imported into every session, so the assistant starts each session
believing finished goals are current priorities. Worse, `WorkSweep.ts:579` opens a `[Goal]` issue
for every goal the summary lists as active with no matching open issue — so the mis-bucketing
manufactures board items on a schedule.

Observed on a real install: three stale goal cards were closed by hand and the hourly sweep
recreated two of them twenty minutes later. The one that stayed closed was the goal that had been
*deleted* from the source; the two that came back were the ones merely *marked done*. Deleting
works, marking completed does nothing.

## Repro against a clean tree

```bash
git clone --depth 1 --branch v7.40.4 https://github.com/danielmiessler/LifeOS.git /tmp/lifeos-clean
cd /tmp/lifeos-clean

# Use the shipped template as-is and mark one shipped sample goal completed:
sed -i 's/^- \*\*G1:\*\* (sample).*/- **G1:** ✅ COMPLETED 2026-06-08 — shipped sample, marked done./' \
LifeOS/install/USER/TELOS/TELOS.md

bun LifeOS/install/LIFEOS/TOOLS/GenerateTelosSummary.ts
sed -n '/## Active Goals/,/^## /p' LifeOS/install/USER/TELOS/PRINCIPAL_TELOS.md
```

**Expected:** `G1` under a Completed line.
**Actual:** `G1` listed under `## Active Goals`, and the Completed section is absent because the
bucket is empty.

## Negative control

Rename the section (nothing else) and the same goal moves:

```bash
sed -i 's/^## GOALS (measurable milestones toward the problems)/## Completed Goals/' \
LifeOS/install/USER/TELOS/TELOS.md
bun LifeOS/install/LIFEOS/TOOLS/GenerateTelosSummary.ts
```

Now **every** goal renders as completed — including the ones that are not. That is the proof the
heading decides and the goal's own text never does.

## Suggested fix

Let the item's own body override the heading, keeping `bucketOf` and its `return 'active'` default
exactly as they are:

- parse each goal's body (the lines under its `### Gn:` heading — `parseItems` currently keeps only
the heading line, which is why a status written in the body is invisible);
- if the body declares completion or retirement, move it to that bucket; otherwise keep the
heading's verdict.

A file with no status markers then behaves byte-identically to today.

Happy to send a PR if the approach looks right — and happy to be told the heading-based design is
deliberate, in which case the shipped template probably wants `## Active Goals` as its heading so
the other two buckets are at least reachable.

Start in LIFEOS/TOOLS/GenerateTelosSummary.ts around parseItems and lines 305-316, then inspect the goal data passed to the bucket selection used at lines 706 and 715. Run the clean-tree reproduction against USER/TELOS/TELOS.md and verify that a completed goal appears under Completed while goals without status markers retain today's heading-based behavior.

Written by the indexing model from the issue text.