meticulous-increase-coverage

Increase coverage for a Meticulous project

Run meticulous-cli-update first if you haven't already this conversation
(it also covers authentication and project selection).

What you deliver

Two separate outputs, both expected — neither substitutes for the other:

1. One or more test runs from newly recorded sessions that provably extend
   coverage. "Provably" means a comparison against the baseline naming the
   files whose coverage went up, and by how much (Step 7). If a target turns
   out not to be coverable, say so rather than padding the list.
2. A PR proposing .meticulousignore changes. Only include paths — most
   often whole directories — that you are confident are not coverable at
   all. Anything you merely failed to reach in one sitting does not belong
   there; leave it out and mention it in the PR description instead.

Before you start: run this on main, with a clean tree

Every command below relies on the CLI resolving things from your local
checkout: js-coverage defaults to the current git HEAD, trigger-test-run
defaults to HEAD for the deployment and to the merge-base with the origin
default branch for the base. On main with a clean tree those collapse to a
single commit, which is exactly what you want — no diff, a head-only run, and
a union in Step 7 that the API will actually accept.

Off main this breaks in ways that are tedious to unpick: union coverage is
rejected unless every run executed the exact same commit, and a PR's merge
commit is recomputed whenever its base branch moves, so a run triggered
earlier against a since-advanced base no longer unions with a new one.

So: check out main, pull, and make sure git status is clean before Step 1.

Then confirm there is actually a test run to work from:

meticulous agent test-run-for-commit

Keep the id it prints — Step 7 falls back to it. If it reports "No test run
found for commit …", stop and report that to the user; you cannot baseline
without it. The most common cause is the CLI pointing at the wrong project, so
suggest they check with meticulous auth get-project. meticulous auth set-project only applies for OAuth tokens; API tokens are bound to one
project (so set-project fails), and injected credentials leave no local
token to select — in those cases the fix is a different credential, not
set-project.

Step 1 — Baseline coverage

meticulous agent js-coverage --includeAllFiles --includeCoveragePercentage \
  > /tmp/baseline-coverage.tsv

If this reports "No test run found for commit …" (it shouldn't, if the
check above passed), stop and report to the user. Do not work around it by
baselining against some other commit's run: Step 7's union requires your new
run and the baseline to have executed the same commit.

The base run's sessions often haven't all been replayed yet, which understates
its coverage — if js-coverage says so, run meticulous agent complete-base-run (it waits by default until nothing more can be scheduled;
it can take a while, so check back or re-run rather than assuming it hung),
then re-run js-coverage. Don't expect unexecutedSessionCount to always
reach 0 — some sessions can be permanently unobtainable, and js-coverage
tolerates a small share of those rather than refusing forever.

Step 2 — Separate dead code from real targets

You are looking for two different things in this file, and it helps to keep
them apart:

• .meticulousignore candidates — files that are uniformly at 0%
  across a whole directory, which suggests they never execute in a browser at
  all.
• Coverage targets — files a real user flow could reach but no recorded
  session happens to. These are not only the 0% files. A file at 12% or
  40% usually means one path through it runs and the rest doesn't, and those
  partial files are often the cheapest wins: the module already loads, so a
  single extra interaction can light up a large block. Sort ascending by
  percentage and work up from the bottom, rather than stopping at 0%. Some
  0%/low files are gated behind a feature toggle that's off by default rather
  than a UI path nobody's driven — check the toggle registry and the file's
  gating condition before assuming it needs a brand-new flow, since flipping
  the toggle on locally can turn a dead-looking file into an easy target.

Start with the ignore candidates, since they shrink the list. Break the
0%-coverage files down by top-level directory, so you are reasoning about
groups rather than 100s of individual files. The exact command depends on how
the repo is laid out — a monorepo wants the first two path segments, a
single-app repo wants something deeper. For example, in a
packages/<name>/… monorepo:

# example only — adjust the segment depth to this repo's layout
awk -F'\t' 'NR>1 && $2=="0.0" {split($1,a,"/"); print a[1]"/"a[2]}' \
  /tmp/baseline-coverage.tsv | sort | uniq -c | sort -rn

A directory where every single file is at 0% (not just some) is a strong
signal it never ships to the browser (backend, CLI tooling, docs, e2e test
harness). Those are your .meticulousignore candidates.

There is a second, stronger signal that doesn't depend on coverage data at
all and catches individual dead files scattered inside an otherwise-live
directory, which the uniformly-0% heuristic above misses entirely. For any
file sitting at 0%, grep the codebase for its actual exported symbol — not
just its filename:

# example only — adjust the source root and extensions to this repo
grep -rn "theActualExportedName" <src-root> --include="*.ts" --include="*.tsx"

If the only match is the file's own definition, nothing imports it, so no
session — however comprehensive — can ever execute it. That is proof of
unreachability, not an inference from silence, and it is worth checking even
when you already have a directory-level rule elsewhere in this file: dead
exports accumulate inside packages that are otherwise very much alive.

Some categories are safe exclusions almost everywhere and are worth
proposing without further tracing, provided the coverage data agrees they are
uniformly 0%:

• test files and their directories — __tests__/, __mocks__/, *.test.*,
  *.spec.*
• Storybook — *.stories.*, __stories__/, .storybook/
• test/mock harness directories — testing/, mocks/, fixtures
• build, lint and codegen config executed only by Node — *.config.*,
  setupTests.*, scripts directories

Note that some of these may already be outside the coverage report entirely;
check the baseline before adding a rule that does nothing.

Be suspicious of a directory showing 0% everywhere if you know it is bundled
into the frontend (a shared component/utils library the main app imports).
That pattern is more likely a source-map/path-attribution gap than genuinely
dead code — leave it out of the ignore list and flag it as unresolved.

Now pick the coverage targets. Filter the generated/config noise out of the
real app package first, then order what's left by how little of it runs —
keeping the partially-covered files in, not just the 0% ones. The patterns are
repo-specific; inspect the actual paths in your baseline rather than copying
this verbatim:

# example only — derive the patterns from the paths this repo actually has
grep -v "/__tests__/\|\.test\.\|\.stories\.\|/testing/\|/mock" \
  /tmp/baseline-coverage.tsv | sort -t$'\t' -k2 -g > /tmp/candidates.tsv

Group the candidates by feature area rather than picking the single worst
files: one recorded flow usually moves a whole cluster of related files at
once, so a directory sitting at 5-20% across a dozen files is a better target
than an isolated 0% file behind an obscure branch.

Step 3 — Trace, don't guess

For each candidate file, find its actual caller(s) — for example:

# example only — adjust the source root and extensions to this repo
grep -rln "<ExportedThing" <src-root> --include="*.tsx" | grep -v test

Read the caller. Confirm:

• It's reachable via a simple, describable UI action (a specific button, a
  specific menu item) — not buried behind a feature flag, a disabled config
  (e.g. billing/SSO toggles that are off in this environment), or a
  conditional branch that only fires for certain object types.
• If the target is a hook, check every branch that calls it. Hooks are
  often called conditionally — one branch might route through a completely
  different mechanism (a plain router <Link> instead of the app's own
  navigation hook, a side-panel open instead of a full navigate). Confirm
  which branch your candidate action actually hits.

Step 4 — Drive the flow

Any of these three drivers records correctly — verified against two
different apps:

• Claude in Chrome — the only one that drives the user's own signed-in
  Chrome profile, so an authenticated app needs no login flow. Its input path
  is also the one that wedges (see below), so verify early and be ready to
  switch.
• Playwright and agent-browser — CDP-launched browsers, faster and
  more scriptable, and reliable in every test here. The trade-off is a fresh
  profile each time, so you have to sign in. agent-browser additionally
  refuses a click when the target is covered by another element, naming the
  covering node, which catches a class of silent mis-click the other two will
  happily perform.

Set a realistic viewport whichever you pick. The CDP browsers default to
something small (around 1280px wide) where a real Chrome window is often twice
that. Responsive layouts render different components at different widths, so
the default viewport can quietly cover different code — or hide the control
you were aiming for.

What matters far more than the choice of tool is the one rule below.

Only trusted events are recorded. The recorder ignores anything
synthesised in page JS, so element.click(), assigning input.value, or
dispatching your own events all drive the app convincingly and record
nothing. The page looks right, the session comes back empty. Drive
everything through the tool's real input actions.

When something doesn't take effect, find out which half is broken before
changing tactics — install a capturing probe and repeat the action:

window.__ev = [];
["pointerdown", "click", "keydown", "change"].forEach((t) =>
  window.addEventListener(
    t,
    (e) => window.__ev.push({ t, trusted: e.isTrusted }),
    true,
  ),
);

• nothing captured → your input never reached the page; a different selector
  or coordinate won't help (see the wedged-extension note below)
• captured but trusted: false → it reached the page but will not be
  recorded; you are synthesising somewhere

Three ways an action records as nothing

All three look like success in the browser, which is what makes them
expensive — you find out from the coverage numbers, long after the fact.

Native <select>s. Setting the value through a form-fill action, or
assigning it in JS, fires a change with isTrusted: false — the app reacts
and the value visibly updates, so it looks like it worked, but the recorder
ignores it and the sort/filter never happens on replay. Clicking the
<select> is no good either: that opens an OS-level popup the driver can't
see. What works is to focus the element and press the first letter of the
option's visible text ("p" → "Priority"), which yields a trusted keydown
and a trusted change. Repeat the letter to cycle options sharing an
initial. Verify with a change listener reading e.isTrusted — the value
updates either way, so the value alone tells you nothing.

Modifier shortcuts. Replay reproduces a modifier only if a discrete
modifier keydown was recorded and is still held. Some drivers send one only
for the base key: Claude in Chrome's cmd+k and agent-browser's
press Alt+ArrowRight both record a single keydown with the modifier flag set
and no separate modifier press, so on replay the flag is cleared and the
handler body never runs — while working perfectly live. Playwright's
press('Alt+ArrowRight') does record the discrete press and replays correctly
(verified by coverage).

So: prefer the equivalent click target where one exists, and if you must use
a chord, drive it with Playwright and confirm from coverage afterwards. If the
line holding if (… && event.metaKey) is covered but the body is not, the
keydown was delivered and the condition evaluated false — that is this.

Double-clicks. A double-click may be recorded as a single click, in which
case the replay never fires onDoubleClick and every later event in that
session targets UI that never opened — so coverage drops. Check the recorded
event count looks like two press/release pairs, and treat any
double-click-only feature as suspect until coverage confirms it.

Some interactions may not survive agent-driven recording at all

Occasionally an interaction records cleanly and visibly works live, but the
handler it's meant to trigger never fires on replay — with no error, and the
affected file sitting at exactly its baseline percentage in Step 7's union.
One case seen: typing a value into an input inside a dropdown's own
portal-rendered content (a filter chip, a view rename behind a "..." menu).
Plain clicks in the same portal, and the identical type-then-Enter sequence
on an input in the main page tree, both replay fine — so this is specific to
keyboard/text input inside a portal, not a driver issue.

Don't assume a typed-value target worked just because the live interaction
did — check Step 7's diff. If a target only reproduces through this kind of
interaction and won't move, that's a shortcoming of agent-driven recording
for this flow: report it as unresolved and suggest a human drive that one
flow manually, rather than continuing to pad the list with retries.

claude-in-chrome specifics

• Screenshots are downscaled (~0.6x), so they are not CSS pixels. Click
  coordinates read off the screenshot, or scale a getBoundingClientRect()
  centre by screenshotWidth / window.innerWidth. Re-derive after any resize,
  and re-screenshot rather than reusing coordinates from an earlier page —
  layout shifts, and a stale coordinate can land on the wrong element and
  record an interaction you did not intend.
• Re-acquire a ref immediately before clicking it, and never reuse one
  across pages or tabs. Don't predict a number — read_page does not emit
  them in order. Refs and coordinates are equally reliable; pick whichever is
  convenient. This is not unique to claude-in-chrome — agent-browser's
  snapshot refs go stale the same way, and reusing one silently clicks
  whatever now occupies that ref, not what you intended. It cost a real
  mistake once: a stale ref landed on a table's "Add New" affordance and
  created a blank record. Take a fresh snapshot immediately before every
  click when the DOM might have changed, and treat an unexpected
  page/record-count change right after a click as a sign a ref just misfired,
  not as an unrelated bug — clean up whatever it created before continuing.
• Input delivery wedges intermittently. Every click and keystroke reports
  success, reads keep working, and nothing reaches the page. Refs and
  coordinates die together, so this is never a selector problem — and it is
  not cleared by a new tab, a fresh navigation, waiting, or retrying. A full
  Chrome restart helps but does not durably fix it. Check the probe after
  your first interaction, before driving a whole flow, and if input isn't
  landing switch to Playwright or agent-browser rather than switching
  selector method. Both stayed reliable throughout, including on the same
  page at the same moment that Claude in Chrome was dead.

Drive it, then verify

1. Navigate to the target URL and drive the real action.
2. Confirm it worked against the DOM (e.g.
   document.body.innerText.includes(...)), not just a screenshot — a
   tooltip appearing can look like success. Check you are still on the page
   you think you are: an app that has quietly redirected you to a login screen
   will absorb blind coordinate clicks into empty space and hand you a session
   with zero events.
3. Close the tab.

Then sanity-check the recording, before you trigger anything. Wait ~10s after
closing the tab, so the session is complete, and check that it captured
something:

meticulous agent sessions --limit 10 --excludeSyntheticSessions \
  --includeDurationSeconds --includeNumberUserEvents \
  --includeNumberUrlsVisited --includeStartUrl --includeAbandonedReason

Read the row you just produced:

• no row at all — nothing was uploaded yet; wait a little longer before
  concluding the recording failed
• numberUserEvents of 0 — the recorder saw no user input. Your clicks
  were not reaching the page, or were synthesised rather than trusted; go back
  to the input-delivery probe above. Replaying this session is pointless.
• numberUrlsVisited of 1 when you navigated several times — the later
  pages did not make it into this session. They either landed in their own
  sessions (fine, collect those ids too) or were swallowed as an unreplayable
  tail (see the hard-navigation note in Step 5).
• durationSeconds over 300 — everything past the 5-minute mark will be
  silently trimmed on replay (Step 5). Re-record the overflowing part as its
  own session rather than hoping it survives.
• populated abandonedReason — the recorder gave up on the session (see
  the 10-minute cap in Step 5); it is not worth replaying.
• startUrl that is not the page you drove — the navigation you cared
  about belongs to a different session than you assumed.

A session is only complete once its tab is closed. While the tab is open
the row reflects only the chunks uploaded so far, so a low or zero
numberUserEvents there means "not flushed yet", not "the recording
failed". A session measured for this skill read 0 events with the tab open
and 12 once it was closed. Judging it early nearly caused a perfectly good
recording to be re-driven from scratch.

Events upload on a short interval (a few seconds), but anything still
unflushed at unload is only stashed in sessionStorage and re-sent on a
later page load to the same origin — so a session's tail can be delayed
until the next visit. Prefer navigating away over hard-closing the browser,
and never judge a recording immediately.

Recording several targets in one sitting? Run this check after each one,
not just once at the end. Checking only at the end makes it impossible to
tell which action lost a session, and you'll have to re-drive all of them
just to find out which one needs redoing.

Step 5 — Session-time budget and close discipline

• Cloud replays cap at 5 minutes of session time. Everything recorded
  after that is silently trimmed from the replay — the run still succeeds and
  reports itself accurate, so the loss is invisible unless you look for it
  (snapshot routes stop early; far fewer allowed events than the session has
  clicks). Don't leave this to feel: agent sessions --includeDurationSeconds gives you the number, and anything over 300 is
  losing its tail.
• Your interaction pace eats this budget. Each find/click/verify round
  trip is 10-60s of recorded session time. Plan the flow completely before
  opening the tab, batch your actions into as few round trips as possible
  with short waits between them, verify from the recording afterwards rather
  than mid-flow, and aim to stay under 4 minutes. Several short sessions beat
  one long sweep.
• Direct URL navigation is a legitimate fast path to each target page
  and replays fine — prefer it over slow click-paths. But hard navigations
  split the recording into multiple sessions, so collect every resulting
  session id afterwards and pass them all to --sessionIds (Step 6). Mostly
  this is fine, each piece staying under the replay cap. The trap is
  navigating again too quickly: a page reached a second or two after the
  previous one gets appended as the tail of that session instead of
  starting its own, and tails frequently do not replay — so the page renders
  perfectly while you drive it and still contributes no coverage. Give each
  page you actually care about its own dwell time (~10s) before moving on,
  and check in Step 6 that it shows up as a startUrl in its own right. The
  same caution applies to a plain <form> submit with no wired onSubmit
  handler — it triggers a real browser reload rather than an SPA transition,
  and can just as easily drop the just-recorded, unflushed session if you
  navigate on immediately afterward.
• Recorder limits: a 10-minute hard cap on tab-open time marks the whole
  session "abandoned"; uploads flush on a 5s interval — wait ~6-8s after the
  last interaction before closing the tab.

Step 6 — Collect the session ids and trigger the test run

First list what you actually recorded, newest first:

meticulous agent sessions --limit 20 --excludeSyntheticSessions \
  --includeDurationSeconds --includeNumberUserEvents \
  --includeNumberUrlsVisited --includeStartUrl

Skip any row with numberUserEvents of 0 — it will replay as nothing and
only dilutes the run. Note any row with durationSeconds over 300: it will
replay, but only its first five minutes, so treat coverage from its tail as
absent rather than assuming the whole flow ran.

Identify your sessions by recorded-at time and startUrl. Be careful here:
other people — and other apps pointed at the same project — record too, so
never assume the newest N rows are yours. --recordedSince and
--visitedUrlFilter are the quickest way to narrow it down when the list is
busy.

Expect more sessions than pages you drove: a hard navigation usually ends
one session and starts another, so a five-page sweep can produce five ids.
Collect all of them. A page whose URL never shows up as a startUrl was
probably swallowed as the tail of the previous session and will not replay —
re-record it on its own if you need it covered.

Then trigger:

meticulous agent trigger-test-run --sessionIds "<id1>,<id2>,..."

Step 7 — Compare with a union, not a raw diff

meticulous agent js-coverage --headPlusTestRunIds "<newRunId>" \
  --includeAllFiles --includeCoveragePercentage > /tmp/combined-coverage.tsv

This unions your new run into the baseline run resolved from HEAD — the same
run Step 1 used — so it is baseline coverage plus your new sessions'
coverage. Commit resolution skips runs over an explicit session set, so the
run you just triggered won't be picked as the baseline. The union is needed
because --sessionIds replaced the selected set for that run rather than
adding to it, so your run on its own covers far less than the baseline and a
raw diff would read as mass regressions. Diff the union against
/tmp/baseline-coverage.tsv: you should see zero regressions, and only the
files your new flow touched improve.

Pass only your new run — a run cannot be unioned with itself.

Two signs HEAD resolved to something other than the golden-set run: it is
rejected with "is the run being queried", or every file has dropped
(which means you unioned into another narrow session set, not a regression).
The most likely cause is a pinned-session run predating the skip. Either way,
name both sides explicitly, using the baseline id from Step 0:

meticulous agent js-coverage --testRunIds "<baselineRunId>,<newRunId>" \
  --includeAllFiles --includeCoveragePercentage > /tmp/combined-coverage.tsv

If the union is rejected because the runs executed different commits, that is
the main/clean-tree precondition biting — see the top of this skill.

Step 8 — Verify and report

For each traced target file: did coverage move? For each presumed-dead file
(the .meticulousignore candidates from Step 2): did it stay at 0% in the
union comparison (confirming it's genuinely unreachable)?

If a well-traced target didn't move, don't assume the recording failed —
re-check the session first (Step 4: does it exist, did it capture user events
and URL visits, is it abandoned, is its startUrl the page you drove?), then
re-check whether the click actually goes through the file you expected
(Step 3) rather than a sibling/parent component.
Report honestly if a target remains unresolved; don't claim success without
the coverage number to back it.

When you report the gains, be clear about what they are not yet: the test run
proves the coverage is reachable, but the project's own coverage figure will
only improve once the next session selection picks these new sessions up into
the selected set. Until then nothing changes for recurring runs.

Step 9 — Open the .meticulousignore PR

The second deliverable. Branch, commit the .meticulousignore change, and
open a PR.

Only propose paths you are confident are not coverable at all. The bar is
"no session could ever execute this", not "I didn't get to it today". Prefer
directory-level rules over long lists of individual files — a directory rule
stays correct as files are added, whereas a file list silently goes stale. In
practice most entries come from the safe-exclusion categories in Step 2 plus
whatever whole non-browser packages the baseline showed at a uniform 0%.

Confirm before you commit: every path you are about to ignore stayed at 0% in
the Step 7 union. A path your own new sessions just covered obviously does not
belong in the ignore list, and that check catches it.

A common structure is "ignore everything, then un-ignore what does run in the
browser" — the pattern Meticulous's own monorepo uses:

# Ignore everything except packages that are executed in the
# browser and have meaningful frontend coverage.

packages/*
!packages/<frontend-app>/
!packages/<frontend-app>/**
!packages/<shared-ui-lib>/
!packages/<shared-ui-lib>/**

Note that .meticulousignore follows gitignore semantics, so a file cannot be
re-included once its parent directory is excluded — un-ignore the directories
(!some/dir/**/) as well as the files.

In the PR description, give the reasoning for each rule — why this code
cannot run in a browser (it's a Node-only build script, a test harness, a
backend package). The baseline can only show you that something is at 0%
today, which is never proof it is unreachable, so the justification has to
come from what the code actually is. Also call out explicitly:

• anything you left out of the ignore list despite low coverage because
  you suspect a source-map/attribution gap rather than dead code (Step 2)
• anything unreachable only because of environment or feature-flag config
  rather than structurally — that is the reviewer's judgement call, not
  yours, so flag it instead of silently ignoring it

Reference

references/worked-example.md runs the whole skill against a small app
(kanban-demo), with the real coverage deltas. Worth reading for calibration:
it has no 0% files at all, one target that gained coverage and one that
recorded cleanly and then failed to replay — and it shows how to tell the
difference from executed ranges.