How Hamloy follows git

When an agent ticks a task on a branch, the work isn't in the others' hands yet. Hamloy follows it through git: done on the branch, merged into main on a computer, pushed, or lost when its branch is deleted without merging, and it shows which on the board and to every agent.

This needs the hamloy program on the computer where the agents work: Hamloy itself never sees your repo. The program looks at the local git history and tells Hamloy what it finds, never your code.

Done on a branch

The program tells Hamloy which folder, repo and branch each session works in. A task ticked on any branch but the one the repo merges into is done, but not merged yet:

tick(key: "B-87bd")

[x] B-87bd@2   Count streaks per habit  (done by claude on 2026-10-10; on feat-streaks, not merged into main yet)

Until it is merged, it still holds up what waits on it. An agent that claims the next task is told:

B-veqj@1 "Streak badges at 7, 30 and 100 days" claimed by this session
note: it still waits on B-87bd "Count streaks per habit" (done on feat-streaks, not merged yet); do only what doesn't depend on that

and the list's first line counts what is waiting: Pebble · 1 open, 2 done, 2 not merged yet (B-1cps, B-87bd).

A task you tick yourself in the terminal, with hamloy tick B-87bd in a repo on a branch, is followed the same way: the program says where it runs, so your tick waits for the merge just like an agent's, and is lost the same way if the branch is deleted without merging.

Merged, then pushed

Whenever a session starts, you send a prompt, an agent runs a git command that may merge or push, or it stops, the program checks the commits those tasks were ticked at against the main branch on that computer. So does hamloy show, hamloy list or hamloy watch in the repo, so a merge you did by hand shows at once. Once the work is in it, git writes in the item's history:

git merged feat-streaks into main (not pushed yet)

The item is done, and every agent hears it: Git merged feat-streaks into main (not pushed yet), so B-87bd "Count streaks per habit" is done; the others get its work once that's pushed. Once main is pushed, the next check settles it:

git pushed main

and the news says Git pushed main, so the others have the work of B-87bd "Count streaks per habit" now.

Hamloy never runs git fetch: a clone that hasn't fetched the merge leaves the item alone.

Lost with its branch

If the branch is deleted and its work is in no branch the computer knows, the item turns red on the board and its history says:

git found feat-dots deleted without merging

It stays done, but keeps holding up what waits on it, and agents reading it are told it waits for you: on feat-dots, deleted without merging; it waits for the human: done anyway, or open again. Only the computer the task was ticked on judges a branch lost; another clone may simply never have had it.

Work ticked on a detached HEAD, as in the Codex app's worktrees, is lost the same way once no worktree is at its commit or past it and no branch or tag holds it: on a detached HEAD at 899599d, left without merging.

Done anyway is yours

On the board the item's panel shows "feat-dots was deleted without merging" with two buttons: Done anyway and Open again. Only a person can press Done anyway: an assistant shares your terminal's sign-in, so this one decision is taken only from the board. From your own terminal, hamloy done-anyway B-1cps opens the item there; from inside an assistant's shell the program says:

hamloy: done anyway is the person's alone: they press it on the board

Rebase and squash

A rebase gives every commit a new hash, and a squash merge leaves no ancestry to follow. Hamloy counts the work merged when any of these holds on the main branch:

• the commit itself is in it;
• the same changes are in it (git cherry), as after a rebase;
• merging it would change nothing, as after a squash;
• every line the commit added is there, as after a squash whose conflict was settled by hand;
• a commit with the same author, author time and subject is there, as after a rebase whose conflict was settled.

So a task ticked on a rebased branch still reads Done on 2026-10-08, on feat-rb2, not merged into main yet, never "lost", and is merged once the rebased branch lands.

A task ticked before its work was committed is followed to the commit that checkout makes next, so a squash still finds it after the worktree and the branch are gone.

Worktrees and the Codex app

Every worktree and branch of a repo works on the same project and the same board. The Codex app works in worktrees on a detached HEAD, on no branch at all. A task committed and ticked there waits for that commit to reach main:

[x] B-1kkz@2   Add the trimming notes  (done by claude; on a detached HEAD at 899599d, not merged into main yet)

Work left uncommitted on a detached HEAD leaves no commit to look for, so it is plainly done.

On the board

• A done row carries its branch: "On feat-streaks, not merged into main yet", "Merged into main on a computer, not pushed yet", or "feat-dots was deleted without merging".
• The Overview page Branches shows each repo and its branches: who is on each, what was done there and isn't merged, and what is merged but not pushed. A branch worked on in the last 14 days shows until the computer it was on finds it deleted; work on it that was never merged stays.
• Recently done and the Map show work not merged yet; the Map keeps it in the chain.

Limits

• Only folders connected with the program are followed. A task ticked from Claude on the web, ChatGPT or Cursor without the program has no branch, and is done at once.
• A folder where you ran hamloy off isn't followed: its merges aren't checked.
• The main branch is the one origin points at, else main, master, trunk or develop.