/running-tend

name: running-tend
description: Worktrunk-specific guidance for tend CI workflows. Adds codecov polling, Rust test commands, labels, and review criteria on top of the bundled tend-ci-runner skills. Use when operating in CI.
metadata:
  internal: true

Worktrunk Tend CI

Project-specific guidance for tend workflows running on worktrunk (a Rust CLI for managing git worktrees). The bundled `run-tend`, `review`, and `triage` skills provide the workflow framework; this skill adds worktrunk conventions.

Filing issues in other repos

Standing exception granted: file directly in agent-equipped targets (per **Filing issues** in the bundled `act-in-other-repos` 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.

Codecov Monitoring

After required CI checks pass, poll `codecov/patch` — it is mandatory despite being marked non-required:

for i in $(seq 1 5); do
  CODECOV=$(gh pr checks <number> 2>&1 | grep 'codecov/patch' || true)
  if echo "$CODECOV" | grep -q 'pass'; then
    echo "codecov/patch passed"; exit 0
  elif echo "$CODECOV" | grep -q 'fail'; then
    echo "codecov/patch FAILED"; exit 1
  fi
  sleep 60
done

If codecov fails **locally**, investigate with `task coverage` and `cargo llvm-cov report --show-missing-lines | grep <file>`.

Investigating codecov failures in CI

`task` and `cargo-llvm-cov` are not installed in the `tend-setup` action. Don't try to `cargo install` them in the sandbox — past attempts at source-compiling installs cascaded into bash-tool interrupts that blocked even `pwd` and `echo`. Instead, query Codecov directly, following `tests/AGENTS.md` → **Coverage Investigation** for the endpoints and their traps. The scratch paths there and below go to `${TMPDIR:-/tmp}` — write new ones the same way.

If the Codecov API markers aren't enough, download the `code-coverage-report` artifact from the PR head's `coverage` workflow run — it contains a `cobertura.xml` with per-line hit counts:

REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
# Find the coverage run on the PR head SHA:
CI_RUN=$(gh api "repos/$REPO/commits/<sha>/check-runs" --jq '.check_runs[] | select(.name == "code-coverage") | .details_url | capture("runs/(?<id>[0-9]+)") | .id')
# List artifacts, then download the coverage one:
gh api "repos/$REPO/actions/runs/$CI_RUN/artifacts" --jq '.artifacts[] | {name, id}'
gh api "repos/$REPO/actions/artifacts/<id>/zip" > "${TMPDIR:-/tmp}/coverage.zip"
unzip -q "${TMPDIR:-/tmp}/coverage.zip" -d "${TMPDIR:-/tmp}/coverage"

Test Commands

cargo run -- hook pre-merge --yes   # full suite + lints
cargo test --lib --bins             # unit tests only
cargo test --test integration       # integration tests only

CI runs on Linux, Windows, and macOS.

Rework a test that reaches for its environment

A test that leans on inherited state — the process CWD, an ambient env var — sets up its own instead, via `TestRepo::with_initial_commit()` plus a tempdir, the way most worktrunk tests already do. Guarding it with an early return (**Don't "fix" tests by adding skip guards** in the bundled `fix-a-bug` skill) drops the coverage rather than restoring it. This governs every workflow that fixes a test here, not just issue triage.

Session Log Paths

The artifact directory is named after the agent's working directory, which moves between tend releases — 0.2.5–0.2.13 used a per-run `tend-agent-workspace-*/checkout`, and from 0.2.14 the agent works in the runner's own checkout, so `-home-runner-work-worktrunk-worktrunk/` is the prefix again. Match on neither literal: use the bundled `find "$DEST" -name '*.jsonl'` recipe, which holds across all of them — every shape is one `<session-id>.jsonl` under a single slugified directory.

Labels

• `automated-fix` — fix PRs from triage
• `nightly-cleanup` — nightly sweep issues and PRs

CI Failure Triage: Prefer Rerun for Transient Infrastructure Failures

Before opening a PR for a CI failure, classify it:

• **Transient infrastructure** (link-check timeouts, apt-get flakes, GitHub

outages, runner disk issues, codecov upload blips) — do **not** create a PR. The maintainer will rerun CI. Comment on the run or exit silently; a permanent config change for a one-off timeout is churn the maintainer will close.

• **Flaky test** (known-flaky or first-seen PTY/shell test) — try to fix it.
• **Real regression** — proceed with a fix PR.

**Non-required ≠ transient.** A non-required job (e.g. `collect affected coverage`, `affected tests (linux, advisory)`) can fail from a real regression. The required/non-required distinction is about merge-blocking, not about how the failure is classified. If a deterministic build error (`error[E...]`, "binary not found", "ambiguous candidates", missing target) repeats across consecutive runs of the same shape, it's a real regression even when the job is advisory. Reserve "transient" for non-deterministic causes: `BrokenPipe`, `connection reset`, runner disk full, GitHub API timeouts, host-availability blips.

**Lychee link-check timeouts are always transient** unless the same URL has failed on at least two separate runs within the last few days. The check runs as the `link-check` job in the `nightly` workflow. `.config/lychee.toml` already sets `max_retries = 6` and lists known-unreliable hosts; one timeout is not enough evidence to extend that list. Signals you have a transient failure, not a broken link:

• The previous run on the same or a nearby commit passed.
• Only `[TIMEOUT]` is reported (not `404`/`403`/`410`).
• The URL is reachable from a local `curl`.

When in doubt, post the diagnosis on the failure cause issue and wait — don't open a PR.

Applying GitHub Suggestions

Apply the literal suggestion only — change the lines it covers, nothing more. If surrounding lines also need updating, note that in your reply.

P