| name | running-tend |
| description | Project-specific guidance loaded by tend workflows alongside CLAUDE.md. |
Running tend — leaf
Landing
Work from Tend lands as a pull request that a maintainer merges. The bot has
write access, and the Merge access ruleset holds merging to admins.
Review threshold
Apply CLAUDE.md's Stage section to the verdict. Once a change moves Leaf
toward a coherent architecture and its claimed path works, the review is done.
Reserve findings for architectural seams, cross-runtime invariants, public
surface traps, regressions on the claimed path, or a central claim or test that
is false. Omit bounded edge cases, exhaustive same-pattern cleanup, minor
simplification, and prose or test polish unless they expose one of those
problems.
Filing issues in other repos
Standing exception granted: file directly in agent-equipped targets (per
Filing Issues in Other Repos in the bundled running-in-ci skill) without
asking permission here first. The default rule (open an issue here asking
permission first) still applies when the target shows no agent signals.
Leave outage trackers for the drain
Leave the "Bot temporarily unavailable" tracker open until
tend-review-runs drains its rows; the outage ending is not enough because each
row names a stranded trigger. The tracker's own body invites the opposite —
"Close it once the outage is resolved" — but that boilerplate does not account
for the rows. Ignore it. A comment can record recovery, but the drain owns the
close. This applies by title, not by the tend-outage label: ci-fix diagnosis
trackers have no rows and are closed by ci-fix itself.
A red ci on main is live
Pull requests and main run the everyday and website-worker gates. The complete
suite runs on the daily schedule. A red ci on main is already affecting whoever
pulls next. Treat it as live.
Review test selection
Before approving a product change, choose and run the smallest test selection
that exercises the failures the diff could introduce. Select from the product
paths and contracts in the diff, not from the test files it happens to touch.
The review selection supplements the everyday CI gate. A docs-only or
generated-workflow change may need no additional test; a selected failure
withholds approval.
For a change that can alter browser startup, apply CLAUDE.md's Working on the
repository performance rule. Read the candidate profile from CI and compare it with
the base. If requests or bytes rise before presentation, check that the PR names the
user-visible benefit and why the work must happen then.
When a high-level browser test is slow or fails on timing or geometry outside its
contract, repair its arrangement or move that contract to the lower boundary that
can prove it. Keep a browser case only where it proves that the boundaries work
together.
Reading a red suite
Nearly every test drives a real browser, so a red run has more ways to be
uninteresting here than in a repo of unit tests. Classify before writing a fix —
but not by whether the failures move between runs. main reddens on a different
test most days, and each of those failures reproduced on its own commit, most of
them deterministically, so movement across runs says nothing about which class
you have. Sort on what the failure is.
- A read or press that ran before the page said it was ready. The dominant
class here, and the one a re-run hides. The test measures a point, presses it,
or asserts on it while the page is still arriving at the state the gesture
needs — a panel still widening the document, a scroll still settling, a
response landed but not yet reconciled. It surfaces at a wait far from the
read that caused it, so the traceback names the symptom rather than the cause.
tests/CLAUDE.md already owns the fix under State races are arrangements,
not probabilities and A state the page passes through is not a state to
poll for: state the ordering, do not repeat the gesture until it happens to
hold.
- A reading that has been widened before. The failure is a case some
accepted set, allowlist, or tolerance does not cover, and the fix that presents
itself is one more member. Read the line's history first (
git log -L). A set
that has already grown is describing the noise the suite makes rather than the
behaviour the test names, so the next wording reddens main again.
tests/CLAUDE.md owns the fix under A test cannot assert over noise it makes
itself. The PR is against the test.
- A real regression. Deterministic, repeats at the same assertion across
runs, and usually clusters on one widget or one behaviour. This is worth a fix
PR.
Weekly: interface sweep
Run /ui-sweep before dependency maintenance. This is the discovery pass for visual
and interaction behavior the suite has no stated invariant for yet. Follow its
Fix and pin route: a reproduced defect becomes a tested repair, while a design
judgment stays in the run report.
Weekly: vendored browser dependencies
.github/dependabot.yml watches the action refs and uv.lock. It cannot watch
the browser dependencies, whose versions live in scripts/vendor.py's PINS
table rather than a manifest. They drift silently, and this is the step that
catches it.
scripts/vendor.py --pins
Each row is a package, its pin, the bundle to rebuild if it has moved, and the
newest release that pin could take where that differs. elkjs and entities are
beautiful-mermaid's imports rather than Leaf's own choices, so their rows read
against the range it declares: a release outside it is not a pin to take, because
npm would install the declared version nested and the bundle would carry that one.
esbuild is the tool the builds share rather than payload, so it moves when
a bundle needs it rather than on every release.
On drift, bump the entry in PINS and run scripts/vendor.py <bundle> — the
rebuilt bundle is the commit, not the version string on its own. A copy's output tracks its version directly.
highlight and pierre also read the language list out of the registry's
$languages.names, so their output is a function of both the pin and the
registry: rerunning them after an unrelated registry change is how the bundle
and the lint stay unable to disagree. Pierre and Shiki must move together when
their compatibility requires it.
Run the suite afterwards. The browser tests load the bundles, so a bad rebuild
surfaces there rather than in review.
