[aliasunder]

What does this PR do?

The parser timing tests (tasks-linear, tasks-clear-linear, headings-linear, tasks-tag-dedup) fail CI at random with no change to the parsers. The timed child processes asserted two things about their medians:

• every median under a fixed millisecond ceiling (250 to 2,000 ms), and
• the median at the largest size within a bounded multiple of the one at the smallest (the growth check).

A slow runner breaks the first with no regression in the code, and a fixed per-test child deadline (10 to 30 s) breaks the same way. Failures seen on CI: status stamp clear exceeded ceiling 259, 559, 1176 (while that ceiling was 1,000 ms, before #755 raised it to 2,000 ms) and packed hashtag edits exceeded ceiling 64, 226, 1025, and the status-stamp child killed at its 15 s deadline.

This PR keeps the growth check as the speed test:

• The fixed ceilings go wherever a growth check already exists. The growth check compares a run against itself, so a slower runner scales every median together.
• The packed-hashtag test had only a ceiling. It gains a growth check scaled by the line's length, because its size sets both the hashtag count and each hashtag's length.
• Every timing child in these four files shares one 60 s deadline (__tests__/helpers/linear-timing.ts), with the vitest timeout 10 s above it so a child that finishes inside its deadline never fails as a vitest timeout. The slowest child takes about 7 s on a fast laptop.
• The 110,000-case Dataview corpus test gets an explicit 30 s timeout like its sibling corpus test; the 5 s default ran out under local load.
• LINEAR_GROWTH_ALLOWANCE, copied in four files, moves to the same helper. The two files that passed a bare 10 as the growth check's noise floor name it, with the same value.
• The heading and field-grammar timing tests assert their whole output, and the status-stamp test prints its medians like the other eight.

Type of change

• New feature (a tool, a prompt, a setting, a parameter, or a change to what a tool does)
• Bug fix
• Refactoring
• Documentation
• CI / workflow change
• Infrastructure (SST, Docker)
• Other: tests only

Verification

• The four files pass locally: 28 tests. On a passing CI run tasks-clear-linear took 27.6 s against 11.5 s on a fast laptop, which is the margin the old fixed deadlines lacked.
• Mutation check: with tasks.ts and headings.ts from before fix(parsers): keep task, heading, link, frontmatter and canvas parsing linear #753 (995118e^), all nine timing tests fail.
  • The dense-edits test fails its growth check (126 → 2,466 ms over a 5× size range).
  • The two field-clear tests crash in the old recursive removal (a stack overflow, or running out of memory).
  • Five fail at the 60 s deadline.
  • The field-grammar test compiles a table the old file lacks, so it was run with the old recursive removal swapped in instead; its growth check fails.

Checklist

• The pre-commit hook passed: typecheck, knip, and ESLint, Prettier, markdownlint and ShellCheck on the staged files
• npm test passes (CI)
• npm run build succeeds (CI)
• If this adds a feature, the description links the feature request it came from
• New MCP tools follow the naming and description conventions in AGENTS.md
• README or ARCHITECTURE.md updated (if user-facing behavior changed)

🤖 Generated with Claude Code

[umm-actually]

umm-actually re-reviewed at 90a2246

1 new finding(s) posted (8 tracked finding(s) across all runs).

---

umm-actually · z-ai/glm-5.3-flash

[umm-actually]

Give the corpus regression test an explicit timeout like its siblings
Low severity · tests · medium confidence

src/vault-mcp/obsidian-markdown/__tests__/headings-linear.test.ts:68 — beyond the diff's line ranges, in code the changes touch or depend on.

This PR gives the 110,000-case Dataview corpus test an explicit 30 s timeout because 'the 5 s default ran out under local load', but the 10,000-case fixed-seed traversal corpus test in this same file still rides vitest's 5 s default. Its per-case work (a legacy-oracle parse, the current parse, a deep equality check, and per-task re-extraction over up to 24 lines) is far heavier than the regex execs the raised test runs, so a loaded runner can push it past 5 s and fail it spuriously with no parser change — the failure class this PR removes from the timing children.

Failure scenario: A CI runner under load — the condition this PR exists for, where the old children 'fail CI at random with no change to the parsers' — runs the 10,000-case corpus test slowly enough to exceed vitest's 5 s default; the test red-balls with a timeout although the parsers are correct, the same '5 s default ran out under local load' failure the PR fixes for the sibling Dataview corpus test, and a local deep run with PARSER_CORPUS_CASES raised hits it sooner.

Suggested fix

Add an explicit timeout matching the sibling corpus tests (e.g. close the test with `}, 30_000)`), or hoist a shared CORPUS_TEST_TIMEOUT_MS into helpers/linear-timing.ts beside the other timing constants.

---

umm-actually · z-ai/glm-5.3-flash

[aliasunder]

Issue comment 6840872688 (umm-actually, corpus test timeout): fixed in 32339fc. Every fixed-seed corpus test in the four timing files now carries an explicit 30 s timeout, the heading ranges test it named and the trailing-tag, emoji-recurrence and tag-removal-order corpora with it.

---

🔍 ship-check · pr-monitor · claude-opus-5-5