Status reference

greenline status is the one diagnosis, and it is read-only. It prints the situation the repository is in, checks the installation (the manifest, the decision book, the lock, an override file and the installed files against what the settings generate), reports the connectors, and shows the changes with their findings and notices. Errors and findings exit nonzero; warnings and notices do not. Each diagnostic names a code, severity and message, with a file when applicable. Repository files use paths relative to the Git root; GL0140 can name an installed package file outside that root. Invalid fields appear separately in the message. This page explains each code and its recovery steps.

Workspace (GL01xx)#

A missing or invalid installation payload is GL0140. Reinstall the intended CLI build. Status keeps the checks it can make without the payload and makes no writes. Sync's orphan effects classify files that are no longer generated; the same classification is printed when a successful --force-managed invocation removes them. It is not a post-run count of files still present. Verify removal from the filesystem or a later greenline status before reporting it. Empty parent directories are left in place.

Status prints each connector's state. A disabled connector raises nothing: nothing is consulted and no process starts. For an enabled one it shows its endpoint, the executable that would run and whether its key variable is set, and it checks this without starting it; the key's value is never read or printed. garden's own failures are typed in the reply of greenline connectors call garden and recorded in its receipt (the garden connector). Status does not start garden, contact a service or certify its availability.

The situation#

greenline status opens with the situation, which your agent reads once before a session's first proposal. It is read from the tree and .git alone, with git read-only and no network command, and it records no time:

• commits: how many commits HEAD reaches, and the branch it names;
• change records: how many the ledger holds; with no change record on any branch, local or remote-tracking, the first request for a change is the orientation, groundwork on an empty tree, where commits read none and languages none found, and a survey of the existing documents otherwise;
• knowledge homes: the ones found, by the names the installed .greenline/WORK.md gives them: .greenline/DECISIONS.md, the ADR folder docs/adr/, GLOSSARY.md and GLOSSARY-MAP.md, and a contributing guide, CONTRIBUTING.md at the root, in .github/ or in docs/;
• languages: each language found by file extension among the files git tracks and the untracked ones it would add, with the roots that hold it, . for the top of the tree and each top-level folder; .greenline/ and the files greenline installed are left out;
• stopped on other branches: the id of each change whose record is stopped on another local greenline/<id> branch and is not on disk here. Every stop commits the record and its folder, so your agent also finds a change stopped on a remote-tracking branch a clone brought, which this line does not read, by that commit.

Where git or the disk cannot answer, an unreadable ledger among them, the fact is shown as unknown. status --json carries the same facts under situation; --change prints none of it.

The hooks#

After the situation, status says how the hooks stand. The git hooks, under .greenline/hooks/, are registered as config-based hooks on git 2.54 or later, through core.hooksPath on an older git that holds no hooks of its own, or absent, with the reason and the line to add to your own hooks; a clone carries the scripts and runs none until greenline sync registers them, and hooks.git: false in the manifest turns them off. Then the checks the manifest declares, or "no checks declared" with the two ways to declare one: greenline check --declare -- <command>, or a run recorded with greenline check -- <command>. Then the harnesses whose adapter the workspace holds; hooks.adapters: false turns them off. status --json carries the same under hooks.

The changes view#

After the situation, greenline status shows the changes. With no flag it lists the open and stopped changes, a record that does not parse among them, then the ten finished most recently closed, newest first. A change counts as closed when its latest recorded check ended, or, while it is unfinished, when it started, a probe left out; one with no check, a dropped change most often, counts as closed at the start of the day its id names, and the newer id breaks a tie. --all lists every finished change in the same order. Each row gives the change's id, its state with its "next" line beside it, its mode and how it was chosen with each raise, the step reached, the depth the review ran at, its commits and the files they touch, whether its checks passed on the final code, and the count of its garden consultations. Then come each plan's tickets, each not started, in progress or done, with the tickets ready to start; the totals; and the commits that belong to no change.

greenline status --change <id> is the resume view of one change: its mode and how it was chosen, why, its state, its "next" line and the step reached; each raise, its floors, the review depth, its plan and ticket, and its cost, where the record states them; its commits and the files they touch; the latest run of each check, with whether it ran on the final code and, when it did not, the files that changed after it; for an open change, the commits of code since its last recorded check, a probe left out, shown when there are any, or as unknown when git cannot count them, a nudge to run the checks again and never a finding; the briefs greenline brief wrote, which the close links from this listing; its garden consultations; and its plan's tickets. It does not print the sections' text, which the record holds. A finished record read as history is marked so. The workspace's ledger guide, .greenline/ledger/README.md, defines the step reached.

Changes (GL04xx)#

greenline status reports these about the change records under .greenline/ledger/; a finding (GL040x) fails the command, and a notice (GL045x, a warning) never does.

A few things status shows are nudges: lines beside a change's row, and in its resume view, that fail nothing and carry no code, since a mechanism now holds the method or no fact of the record settles it. A change taken without waiting (choice: standing) under a mode proceed does not allow, since a standing choice applies only where proceed admits the mode, so the hooks were off or bypassed, or it is a mistake; a done planning change .greenline/DECISIONS.md does not name; a finished change whose working files remain in .greenline/tmp/<id>/, which greenline tidy --change <id> removes; a done record whose agents differs from the builder and the fresh agents its harness's events counted; and, on the history line, each commit since the first change record that touches code and belongs to no change, the first five named, with how the next commit carries the trailer, since the git hooks write it into every commit of a change's branch.

Tidy (GL047x)#

greenline tidy removes the working files of done and dropped changes, .greenline/tmp/<id>/: the one change --change <id> names, or every finished change's when it names none. It removes nothing else: never a folder a file of the ledger links into, directly or through a symbolic link, never an open or stopped change's, never one with no record or a record that does not parse, and never through a link or into another file system. It holds the writer lock, runs no git and reports each folder it removed and each it kept, with --json as the other commands. While it sweeps every change, the folder of an open or stopped change, of a change with no record and of one whose record does not parse is kept and fails nothing.

General (GL00xx)#

Status reports mechanical facts. It does not choose methods, change repository policy, refresh shared knowledge, or clear a semantic conflict. Use it when a diagnostic is useful. The agent reads it at the start of each turn, its situation line before a session's first proposal; where a harness adapter runs, greenline event prints a short mirror of it into the session at its start and at each request.