## A legal Markdown sub-entry turned this guard red
```
AssertionError: Invalid TOC line: - [Theming & Overlay Layering for Dashboard Views](#theming--overlay-layering-for-dashboard-views)
```
That line is an ordinary nested TOC entry, indented under item 8 of
`docs/PLUGIN_AUTHORING.md`. The parser did `.map(line => line.trim())`
**first** and then required every line to match the top-level `N.
[title](#anchor)` shape — so indentation, the one thing distinguishing a
sub-entry from a malformed top-level one, was destroyed before it could
be used.
**The doc was never wrong.** Only the parser was, and it has been red on
`main` since the entry was added.
Indentation is now read before trimming. Sub-entries are still required
to be well-formed links; they just do not participate in the numbering
or the count.
## Both guard directions verified by breaking them
A looser parser that skipped anything unrecognised would have made the
failure go away while quietly ending the guard's usefulness — so I
checked it still fails in both directions:
| mutation | result |
| --- | --- |
| top-level `9.` rewritten as a bullet | still fails (`Invalid TOC
line`) |
| nested entry replaced with un-linked prose | still fails (`Invalid
nested TOC line`) |
## The wider finding, which matters more than this fix
I found it by sweeping `scripts/__tests__` against clean `main`: **688
passing, 7 failing test files.**
| suite | failing assertion |
| --- | --- |
| `ci-test-shard-timings` | committed timing snapshot references live
test files |
| `dependency-security-floor` | pnpm overrides pin transitive protobufjs
to a safe floor |
| `engine-vitest-gate-policy` | pg gate canaries remain a subset of the
enabled suite |
| `plugin-authoring-docs` | **this PR** |
| `release-prompt-gate` | release dry-run exits before proceed
confirmation |
| `verify-fast` | defaults to every canonical pretest validator |
| `workflow-reliability-release-check` | manifest references existing
seam files |
All sit **outside the merge gate**. That is now the third instance of
this pattern I have hit — #2969's 15 red agent-action tests and #3033's
stale ratchet list were the others — and it is clearly systemic rather
than incidental.
I fixed only the one in plugin territory. The rest span CI sharding,
**dependency security** (that protobufjs floor is a security assertion
currently not holding), release gating and workflow manifests. Each
needs its owner's judgement about whether the assertion or the world is
wrong, and a drive-by "make it green" is exactly how a real signal gets
erased — `dependency-security-floor` especially.
## Verification (measured)
- this suite — **4 passed / 0 failed** (was 1 failed)
- `eslint` — clean
Test-only; the doc is untouched. No changeset.
f411d55591