# 2.0.1 — `tracks -H` tolerates unnamed tracks

Patch release. One **bugfix**, no API changes, no new verbs. `tracks -H` no longer
crashes on drafts containing tracks written by other tools.

## The bug it fixes

`track.name` is **optional on disk**: tracks created by `cutcli audios add` /
`cutcli videos add` (and potentially CapCut itself) carry no `name` field. The
`Track` interface declared it required (`name: string`), so the unguarded
`t.name.padEnd(…)` in the `-H` table formatter passed the compiler and crashed at
runtime on the first unnamed track:

```
$ capcut-david tracks "<draft>" -H
{"error":"Cannot read properties of undefined (reading 'padEnd')"}   # exit != 0
```

The JSON output had the same root cause in a quieter form: the `name` key was
silently absent for those tracks.

Found on a real production draft (Stickman A/B `rire-de-tout_AB-A`, 2026-07-12):
a cutcli-created SFX track and a cutcli-created video track, both unnamed.

## Highlights

- 🔧 **`cmdTracks` normalizes `name` to `""`** (`t.name ?? ""`) at the data-map level —
  one guard covers both the `-H` table and the JSON output.
- 🧬 **Type honesty:** `Track.name?: string` — the compiler now rejects any future
  unguarded string use. All other `track.name` uses in `src/` are `===` comparisons
  (undefined-safe, unchanged).
- 🧪 **499 tests** (+1 regression: unnamed track renders in `-H`, exit 0, JSON
  `name === ""`). Typecheck clean.

## Migration

**None.** Read-only inspection path; no draft output changes — the byte-identity
contract (v1.3.0) is untouched.

## Compatibility

- CapCut ≥ 5.x desktop (Windows + macOS) — unchanged.
- Node `>= 18` — unchanged.
- Runtime dependencies: zero — unchanged.