feature-healthlisted

Rebuild [`docs/feature-health.md`](../../../docs/feature-health.md) from current evidence. ## The question this answers **Does each feature actually work?** — NOT "was it built?" `docs/ai/requirements-summary.md` already tracks built-ness (Shipped / Partial / Design only). This skill tracks **trustworthiness**. A feature can be 100% Shipped there and `Unknown` here (built, never realistically exercised). That gap is the entire point. **Enhancements are out of scope.** Every feature could do more; saying so is noise. A note earns its place ONLY if it records: - missing **core** functionality (the feature can't do its stated job), - a **known bug** or a burst of fix commits, - an **unsettled decision** the feature is resting on, - **absent verification** (no automated coverage AND no evidence of real use). A feature with nothing wrong gets **no note**. Resist the urge to fill every cell. ## Method Work from evidence, in this order of weight. Don't skip to conclusions from the docs — the docs have been wrong in both directions before. 1. **Enumerate the features.** Use `CLAUDE.md`'s requirements-doc list (§1–§N) as the spine, then merge doc numbers into coherent user-facing features. Also sweep for features with no doc (check `src/client/` modules and the settings dialog tabs). Keep the existing table's grouping unless the product has genuinely changed shape. 2. **Map automated coverage.** `ls e2e/*.spec.ts` and `find src plugins -name '*.test.ts'`. For each