How a work item flows

This page follows one work item from issue to shipped. Key concepts defines the terms it uses.

​

An item’s status at a glance

Each item shows one status on the Work page: whose turn it is. On the usual path it moves from top to bottom. The sections below follow the same path. With agent shows only while an agent holds the item. After you request changes, the item reads Queued until an agent takes the work. An open item whose issue closes with nothing merged reads Closed, not shipped. Statuses says what each one means and what the line under the title adds.

​

An item arrives

Add an issue from the Work page with Add work, or from a terminal with outerlayer work build --issue 42. Either way the item gets a number. Build, or work build alone, queues the item for a runner. Build locally, or work build --local, leaves it for you to build yourself, and no runner takes it. That is the only way an item reaches the Work page. outerlayer work remove withdraws your request for it. The item leaves the Work page once no request for it remains, and its history is kept.

​

Sessions attach

A session attaches when you start it with OUTERLAYER_WORK set to the item’s number. The item must exist first: launching never creates one. Launch a session shows the command and what to type once the session opens. The session shows up on the item’s page, with what it did and what it cost.

​

Pull requests join

A session on the item declares its pull request with outerlayer work pr 418. outerlayer work open-pr --title <text> --body-file <path> opens one and declares it in one step.

​

Checks build up

Checks are recorded on the item, so they hold across all its pull requests. A person’s own pass or fail is a review, recorded separately on the item page. Where checks come from:

• Each validator file in .outerlayer/validators/ adds one check. outerlayer init writes two: code-review, a code review result recorded, and acceptance-criteria, a criteria judge result recorded.
• The item’s recorded criteria count toward the verdict separately. An unproven criterion flags it.
• A missing criteria list flags it too, unless criteria.missing lowers that.

A repository with no policy file and no validators has nothing checked, and nothing blocks.

​

The item ships

Once its checks are green and every declared proof is present, a person can approve it and merge its pull requests from the item’s page. Merging on GitHub also ships the item. A merge made while the verdict still blocks marks it Done, unverified. When its pull requests merge, the item is shipped, and its cost and duration are kept. A session’s page shows what that session cost. The factory’s Metrics page totals cost per item, time to complete and throughput.

​

Where each piece is documented