running-tend

name	running-tend
description	Project-specific guidance for tend workflows running on this repo.

No project-specific tend preferences yet beyond the notes below. Add guidance here as needed — this file is loaded by tend workflows alongside AGENTS.md.

Filing issues in other repos

When asking permission to file an issue upstream (e.g. at max-sixty/tend), do not include the standing-exception offer ("I can treat this target as file-directly going forward"). nedtwigg wants to keep approving each cross-repo issue individually — keep asking each time, and skip the offer. (diffplug/dormouse#168)

The Chromatic UI Tests check is human-gated — don't wait it out in a gated-approval poll

After approving a visually-changing PR the approval is gated, so the CI Monitoring poll runs to dismiss-on-red. One status context — UI Tests (Chromatic, target_url → chromatic.com/build...) — stays PENDING for the entire poll because Chromatic holds it open until a maintainer accepts or rejects the visual diffs in the Chromatic UI; it does not auto-terminalize in-session. Its sibling Storybook Publish (also Chromatic) does terminalize normally, so this applies only to UI Tests.

When UI Tests is the only non-terminal check and every automated check is green (Build & Test, Visual Regression Tests, verify, Standalone Smoketest, Cloudflare Pages, Storybook Publish), treat it as human-gated: stop polling, confirm nothing flipped to FAILURE, and keep the approval standing — don't wait out the poll cap. Polling it to the cap wastes ~9–17 job-minutes per visually-changing PR with no added signal. (Observed on #203, #289, #317.)

The maintainer's GitHub handle is nedtwigg — never ntwigg

ntwigg is the maintainer's local shell username (it shows up in prompt fixtures like ntwigg@ntwigg-mac-2025 in terminal-prompt-shape.test.ts) and also, on GitHub, an unrelated person's account. Writing @ntwigg in a comment, PR body, or commit message pings a stranger and subscribes them to the thread, which only they can undo. Use @nedtwigg, and don't copy the shorter handle forward from a thread that already contains the typo. (diffplug/dormouse#389)

A restart starts clean — don't carry a superseded PR's findings forward

Long-running work here is often closed and reopened as a fresh PR ("Supersedes #N"), and that restart is deliberate — nedtwigg: "When I start over, I usually want to start over. The original conversation grew too unfocused and out of hand." So review the successor on its own terms: don't fetch the predecessor's bot comments and reviews in order to re-raise findings from them, and don't treat a finding dropped that way as a gap in the review machinery. Carrying the closed thread's context forward is the thing the restart was for.

Proposed as an overlay note and rejected in #421. The underlying incident (#398 → #416, where three findings written up as #398 closed mid-review went unre-raised) is easy to re-derive from session logs — a review-runs/review-reviewers sweep that rediscovers it should not re-file it here or upstream at max-sixty/tend.

Settled upstream rulings — don't re-file

Before a review-runs/review-reviewers sweep flags a tend behavior as waste or files it upstream, check this list — these were already raised and ruled on, so re-filing burns a session and spams upstream:

• tend-review silently running a full review on the bot's own PRs is intended, not waste. The diff read is the review — it catches lint failures and edge cases even though self-approval is impossible, so a silent exit means the review ran and found nothing to post. Ruled intended behavior by the upstream owner in max-sixty/tend#607 (closed as intended, same ruling as tend#212/#154). Do not treat self-review-of-bot-PRs no-ops as cost waste and do not re-file. (The companion tend-mention no-op on undirected bot comments, tend#606, was fixed upstream — that one is resolved, not rejected.)