Papercuts

Capture small friction in the moment without derailing the current task. Aggregated entries show where the repository needs sanding down — so the bar is that a different contributor would hit the same thing, and the repository can do something about it.

The two-question test

Log it only if both are true:

1. Reproducible for anyone. A different person, on a fresh checkout, working in this repo would hit the same friction. It is not specific to your sandbox, shell config, machine, network, or a one-time hiccup.
2. Fixable in the repo. A change to the repo's code, config, scripts, or docs would prevent or reduce it.

If either answer is "no," push through it and move on — do not log it.

Do NOT log

• Your environment's failures. Sandbox EPERM / listen / IPC-socket errors, blocked network or fetch failed, permission denials, missing system tools. That is the runner, not the repo.
• Your own shell mistakes. Reserved or special variable names (status, path), unquoted globs, a broken login-shell hook. Fix the command — there is nothing in the repo to sand down.
• Transient flakiness. A command that succeeded on retry with no repo-side cause (a network blip, a hung push, a slow mirror).
• Local state you corrupted. A partial node_modules after branch-switching, a stale dev-server port, a dirty cache. Re-run the install or cleanup.
• Third-party or beta-tool limitations the repo can't change — unless the fix is a repo-side workaround worth writing down (then log that workaround).
• Product or code correctness bugs (fix now or track as real work), and what you accomplished (that belongs in the task summary).
• Secrets, credentials, personal data, raw customer payloads, or sensitive paths.

When something fails, first ask "is this the repo, or is this me/my environment?" Only the former is a papercut.

Log proactively

1. Search .agents/PAPERCUTS.md for an equivalent entry and avoid duplicates.

2. Append one unchecked item under ## Open using this format:

   - [ ] `YYYY-MM-DDTHH:MM:SSZ` — `agent` — <friction, and the smallest useful fix or workaround>.
   

3. Keep it to one or two sentences: a current example (command/error or affected path), who it blocks or what time it wastes, and the smallest useful repo-side fix. Lead with the friction, not with what you were doing.

4. Continue the original task. Do not expand a papercut into unrelated work.

Use UTC timestamps and a short agent label (codex, claude, human). Add a PR or task identifier only when it helps future triage.

Review or resolve

Only mine a whole session or do a broad review when the user explicitly asks.

For a review or prioritization request, inspect and recommend; do not edit the log or implement fixes unless the user also asks for cleanup or implementation. Carry out an authorized cleanup using the same triage:

1. Re-run the two-question test on every open entry; recommend removing entries that fail it (environment/shell/flake noise that slipped in).
2. Deduplicate and group related entries.
3. Check whether each surviving papercut still reproduces. Distinguish reproduced failures, source inspection, and historical reports you could not verify.
4. Prioritize current impact against review and maintenance cost. Prefer an existing command or a short documentation fix over new helpers, dependencies, or setup hooks. Defer hypothetical improvements until a concrete need appears.
5. For an authorized cleanup, remove noise, consolidate duplicates, and implement the agreed fixes. Move fixed items to ## Resolved, check them, and append the resolving date or commit. Keep deferred reports separate from actionable open work, with a reason and a concrete trigger to revisit. Route real bugs to normal issue/fix work; route recurring review-policy gaps through maintain-greptile-rules.

Preserve useful history for genuinely-resolved papercuts; do not delete them merely to make the file shorter. (Noise that never belonged — see step 1 — is different: remove it.)