> ## Documentation Index > Fetch the complete documentation index at: https://docs.outerlayer.ai/llms.txt > Use this file to discover all available pages before exploring further. # Changelog > What's new in OuterLayer: the dashboard, the CLI and self-hosted runners. ## What OuterLayer does today OuterLayer is an open-source software factory. You add an issue to the Work page of your factory. A coding agent builds the issue into a pull request in your repository. The agent runs on your machine or on a host that you control. From issue to shipped: an issue is added as a work item. Build sends it to a host, Build locally leaves it for your own session. Either way an agent session runs, declares a pull request, and checks are recorded on the item. A person reviews; a request for changes goes back to the agent, an approval leads to merge and the item ships with its cost and time.

From issue to shipped: an issue is added as a work item. Build sends it to a host, Build locally leaves it for your own session. Either way an agent session runs, declares a pull request, and checks are recorded on the item. A person reviews; a request for changes goes back to the agent, an approval leads to merge and the item ships with its cost and time.

### Work page and review * Add a GitHub, Linear or Jira issue to the Work page. The issue becomes a work item with its own number. * Each row on the Work page shows who must do the next step. It also shows the issue state, the pull request state, the review comments and the session cost. * Use the search box to filter the Work page. * Review an item on one page. The **Criteria** tab shows each acceptance criterion with its proof and its comment thread. * Screenshots and videos show in a **Proofs** strip. You can open them full screen. * When you write a note in the thread of a criterion, the agent gets the note. The agent then changes the same pull request. * **Approve** and **Merge** are two different steps. The **Merge** button is disabled until a person approves. * If a build stops, you can start it again from the item page. * See [Review and merge](/review-the-work). ### Evidence and checks * Use `outerlayer emit criteria` to record the acceptance criteria of an item. * Each criterion can name the proof that it needs: a test, a screenshot, a video or a report. * Use `outerlayer emit artifact` to attach proof. JUnit test results can also prove a criterion. * A validator file in `.outerlayer/validators/` declares each check. * In `.outerlayer/policy.yaml`, you set if a failed check stops the merge. * A host can run the check commands of your repository after each build. Only the result from a host satisfies these checks. * Each pull request has an [evidence page](/share-evidence) with its criteria, proof and cost. You can let all persons with the link read this page. * See [Policy and validators](/policy-and-validators) and [Attach evidence](/attach-evidence). ### Cost * The gateway calculates the cost of each session, including the cost of subagents. It also records the price list that it used. * If OuterLayer cannot find a price, it shows the cost as unknown, not as \$0. ### Findings * Agents record the problems that slow their work, for example a flaky test or an incorrect instruction. These records are findings. * The **Findings** tab shows one row for each problem, even when many agents report it. A drawer shows each report and the time that it cost. * See [Findings](/findings). ### Self-hosted runners * `outerlayer runner init` sets up a machine as a host. It installs the runner as a service on Linux, macOS and Windows. * Each build runs in isolation. On a Linux host with KVM, each build gets its own Firecracker microVM. * On other hosts, each build runs in a hardened container. On a Mac, this container runs in a Linux VM. * A build can connect to the network only through the runner. You can limit the public hosts that builds can connect to. * A build never gets the runner key or your Claude credential. It gets a key for its own item only, and a short-lived GitHub token. * The GitHub App of your factory writes the commits of the build and opens its pull request. The commits show the member who requested the build. * The build image of each repository comes from its devcontainer file. * The runner updates itself to the version that the gateway specifies. If its checks fail after the update, it goes back to the previous version. * The owner of a factory can pause runner updates or keep runners at one version. * The runner removes the files of its old builds. It stops taking work when the disk is almost full. * `outerlayer doctor` shows what a host does not have, for example GitHub App permissions or protection on the default branch. * See [Run work on your machines](/run-work-on-your-machines). ### CLI and agent setup * `outerlayer login` signs you in through your browser. * `outerlayer init` connects your repository. It also sets up Claude Code with starter skills, configuration and the OuterLayer MCP server. * `outerlayer work build` starts work on an item. The work runs on a host or in a session that you start. * A session uploads only when you start it with `OUTERLAYER_WORK` set to the item number. All other sessions stay on your machine. * One control plane repository can supply agent instructions and policy to the other repositories in the factory. * A build can check out all repositories in the factory. It opens a pull request in each repository that it changes. * See the [quickstart](/quickstart) and the [CLI reference](/reference/cli). ### Teams and the API * Invite persons to your organization. They can sign up with GitHub, Google, or an email and password. * Use the organization API to manage the control plane of a factory, and to read and export the audit log. * The gateway API reference is on this site. * See [Invite your team](/invite-your-team) and [Organization API](/organization-api). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.