What was seen of the work

An agent ticks a task and writes "all tests pass". Hamloy puts beside that what was seen while it worked: the tests and checks it ran and how each ended, the files it changed, and the pull request with its checks. You read it on To review and in the task's panel, and say it looks good or open it again.

This needs the hamloy program on the computer where the agents work. Hamloy runs nothing itself and never sees your code: every line is what the program reported.

To review
4 finished tasks to look over · 1 with no test run seen

NO TEST RUN SEEN  1
[x] Fill in the README's Usage section with one example per function
    Done by claude 4m ago
    No test or check run seen while it was worked on.
    1 file changed: README.md

CHECKS PASSED  3
[x] titleOf gives Untitled for a note that starts with a blank line
    Done by codex 2m ago
    npm run lint  ran · 2m ago
    npm test  passed after 1 failed run · 10 tests, 10 passed, 0 failed · 2m ago
    2 files changed: test/words.test.js, src/words.js
    Pull request #7, merged, its checks passed
[x] wordCount counts a double space or a line break as an extra word
    Done by claude 4m ago
    npm test && npm run lint  passed · 4 passed, 0 failed · 4m ago
    npm test  failed earlier · 4 tests, 3 passed, 1 failed · 4m ago
    1 file changed: src/words.js

What is kept

While an agent holds a task, the program notes three things, and the tick puts them on the task:

• Tests and checks. A command that runs tests, a linter, a type check or a build: npm test, bin/rails test, pytest, go test ./..., cargo clippy, make check and the like. Hamloy keeps the command, how it ended, the one line that counts its results (12 runs, 0 failures), and how often it ran and failed. It never keeps the rest of the output, and no other command is sent at all.
• Files changed. Their names, never what is in them.
• The pull request. For a task finished on a branch, the program asks GitHub's gh on that computer for the branch's pull request: its number, whether it is open, a draft, merged or closed, and whether its checks passed, failed or are still running, with the names of the ones that failed. Without gh, or with it not signed in, there is no pull request line.

A command is cut down to the part that checks: cd app && API_KEY=… npm test 2>&1 | tail -5 is kept as npm test. Variables set before it are dropped, and a word that looks like a token or a password is masked.

How a run ended

Each command shows its last run: passed, failed, or ran when the program couldn't tell.

• The same command run again takes the place of its earlier run and says so: passed after 1 failed run.
• A run of more takes the place of its parts: npm test that failed, then npm test && npm run lint that passed, is one line.
• A check that failed before a later one passed is still shown, drawn quietly, as failed earlier. One file's tests failing before the whole suite passes isn't held against the work.
• A task is under A check failed when a check was still failing at the end, with nothing passing after it, or when the pull request's checks failed.

Claude Code and Codex

Both report the same things, read a little differently.

• Claude Code tells the program whether a command ended well, with its exit code. When the agent pipes the output on (npm test | tail -5) the exit code is the pipe's, so the line that counts the results decides instead.
• Codex hands the program a command's output and not how it ended. There the counting line always decides, and a check that prints none shows as ran. Codex asks you once to approve the program's hooks.
• An agent without the program (Cursor, Claude on the web, any client that has only the tools) reports nothing. Its finished tasks are under Nothing reported, which is not the same as nothing run.

Looking it over

Looks good takes the task off To review and writes it in the task's history. Its agent hears it with its next news:

- The human looked over the work of B-l94y "titleOf gives Untitled for a note that starts with a blank line": it stays done

A note says it was looked over, with Undo for a tap that wasn't meant: the task is back on To review.

Open again asks what is wrong first. What you write goes on the task as a note its agent reads, the task opens for the work to be done over, and what was seen of the earlier try is dropped.

A task you tick yourself needs no looking over, and neither do requests, questions or work brought in already done. To review is one of the overview's pages; a task merged later keeps following git as before.