---
title: Developer
sidebar_title: Overview
description: Ysra's autonomous software engineer — what it can start from, what a session is, how a session moves from goal to verified candidate, and what you can use it for.
---

**Developer** is the part of Ysra that writes code. You give it a goal and a
repository; it works in an isolated copy, checks its own work with your
project's commands and independent review, and hands you a **candidate** — a
complete, inspectable change — to deliver when you're satisfied.

![The Build composer: "What should Ysra build?", a large brief field, the repository and branch chip, quality and budget controls, and "Start from" playbook cards](../assets/screens/home-composer.webp){ width="1600" height="1280" }
/// caption
Everything starts in the Build composer. The repository name is blurred in
this screenshot.
///

## Key ideas

Session
:   One goal worked to a result in one repository. It has a conversation, a
    plan, a live activity feed, a budget and everything Ysra produced. See
    [Start a session](start-a-session.md).

Candidate
:   The complete change Ysra produced, against the exact revision it started
    from. Every check, screenshot and review is tied to one specific version
    of the candidate. Nothing reaches your repository until it is delivered.

Checkpoint
:   A saved point in the work. Sessions checkpoint as they go, so they can
    resume after an interruption and you can rewind exactly. See
    [Steering and checkpoints](steering.md).

Project
:   A larger objective broken into an approved plan of milestones and tasks,
    each run as a session and integrated into one final candidate. See
    [Projects](projects.md).

Delivery
:   What happens to a finished candidate — kept for you, pushed as a branch, or
    opened as a pull request. Separate from "done", and governed by your
    [autonomy policy](../workspace/autonomy-policy.md). See
    [Delivery and deployment](delivery.md).

## What Ysra can start from

| Starting point | When to use it |
|---|---|
| **An existing GitHub repository** | Most work: features, fixes, migrations, investigations. Connect it once through the [GitHub integration](../integrations/github.md). |
| **A repository Ysra already prepared** | Follow-up work. Ysra already knows the repository's structure and commands. |
| **A new repository** | Greenfield products: websites, APIs, full-stack apps built from a brief. |
| **A local working copy** | Where local execution is enabled for your account, Ysra can work on a checkout on your machine inside a locked-down boundary. |

Before editing anything, Ysra gets to know the repository **without running any
of its code**: languages and frameworks, packages, monorepo layout, and the
commands your project already uses to install, lint, type-check, test, build and
preview. It refreshes that picture when the change itself edits dependencies.

## The life of a session

```mermaid
stateDiagram-v2
    [*] --> Queued
    Queued --> Working: workspace ready
    Working --> Verifying: candidate ready
    Verifying --> Working: a real defect → narrow repair
    Verifying --> Done: required checks pass
    Working --> AwaitingYou: question or budget stop
    AwaitingYou --> Working: answered / budget extended
    Verifying --> Kept: evidence gaps remain
    Working --> Stopped: no progress, or cancelled
```

1. **You create the session** — goal, repository and branch, budget, quality,
   and any files or screenshots.
2. **Ysra compiles the goal** into explicit acceptance criteria (unless you gave
   them), picks up your [rules and instructions](rules.md), and freezes your
   autonomy policy for this session.
3. **It works in an isolated workspace** at the exact revision you chose:
   inspects, edits, runs commands, and checkpoints as it goes.
4. **Your project's own checks run** against the exact candidate.
5. **Independent review** checks each criterion — with browser proof where
   behaviour is interactive. See [Review and verification](review.md).
6. **Concrete failures are repaired narrowly.** Repeated identical failures stop
   the session with an explanation instead of looping.
7. **The session ends** in one of the outcomes below, and you decide what
   happens to the candidate.

### How a session can end

| Outcome | Meaning | Typical next step |
|---|---|---|
| **Verified** | Every required check passed on this exact candidate, including the clean-build check. | Deliver. |
| **Completed** | The work is done and required checks passed; advisory findings are listed. | Read the findings, then deliver. |
| **Unverified** | The candidate is kept, but some required proof couldn't be produced. Nothing failing is hidden. | Look at what's unproven; run a follow-up with browser review, or deliver knowingly. |
| **Failed** | A required check has evidence of a real failure. | Read the failure; steer and continue. |
| **Awaiting you** | Ysra needs an answer, a decision or more budget. | Answer it. |
| **Cancelled** | You stopped it. | — |

A session that has finished is still a conversation: ask for a change and the
work continues from the same candidate.

## What people use it for

- Add a feature or fix a bug in an existing private repository.
- Build a new website, API or full-stack product from a written brief.
- Repository-wide migrations and dependency upgrades, proven with your checks.
- Investigate a failure and get an evidence-backed explanation — even with no
  code change.
- UI changes with desktop and mobile screenshots as proof.
- Build an API from an explicit contract and compare its behaviour with a
  reference.
- Generate the images a change needs, as part of the same candidate.
- Coordinate a multi-milestone product through a [Project](projects.md).

## In this section

<div class="cards" markdown>

- [**Start a session**](start-a-session.md)

    The composer, every option on it, and how to write a brief that works.

- [**The workroom**](workroom.md)

    Conversation, live canvas and the panels that show the work.

- [**Steering and checkpoints**](steering.md)

    Redirect, answer, pause, extend the budget and rewind.

- [**Review and verification**](review.md)

    What's checked, by whom, and how to read the verdict.

- [**Previews**](previews.md)

    Click through the result before anything is merged.

- [**Delivery and deployment**](delivery.md)

    Branches, pull requests and going live — each with its own permission.

</div>