Plan work in the backlog

A Product's backlog is the open issues on its repos. You don't have to keep it tidy by hand: each issue's place is an infrared: label on GitHub, and Infrared and its agents move it as the work moves. A new issue gets a plan from the architect, waits for someone to decide who builds it, and is marked done once it is live in production.

Where an issue stands

Label	What it means
infrared:backlog (or none)	New, not yet thought through.
infrared:arch-reviewed	The architect hydrated it: acceptance criteria, design notes, a verification plan and an estimate. It waits for triage.
infrared:todo-human	Work for a person: a decision, a design, access.
infrared:todo-agent	Work for agents. Adding this label on GitHub starts the issue's Change.
infrared:doing	Being worked on: an agent is building it, or a person took it.
infrared:done	Finished: live in production, or closed by the person who did it.

Two more labels are facts about an issue rather than places, and they stay when it moves:

• infrared:blocks-release holds the Product's production while the issue is open. A reviewer's unfixed finding on a brand-new app becomes such an issue, so production waits for its fix. See Deployments.
• infrared:greenfield marks a brand-new app's first build, which the reviewers judge by the policy for new code.

To see a Product's backlog by column from a terminal, ir issue list --product <product>. The requests that have a Change are on the Product's Changes tab, with where each one stands (see Changes).

Add to the backlog

The quickest way is Ask for a change on the Product's Changes tab: say what should change, add any Details, and choose Start the change. Infrared opens the issue on GitHub as your org's App, with a footer saying who asked in Infrared, and starts its Change, which hydrates it first and then carries it all the way to production. See Ask for a change.

Issues opened on GitHub join the backlog too, and start their Change the same way, once the org's App webhook is active (see Triggers and scheduling).

From a terminal or a script:

ir issue create --product zippy --title "Show the build commit on /version"

curl -X POST https://<host>/api/v1/orgs/<org>/products/<product>/issues \
  -H "Authorization: Bearer $INFRARED_TOKEN" -H 'Content-Type: application/json' \
  -d '{"title": "Show the build commit on /version"}'

Both also take a body (--body, body) and a repo for a Product with several (--repo, repo; the default is the Product's first repo). To open the issue without starting its Change, use --no-hydrate, or "hydrate": false. The response names the issue and the run that hydrates it.

Hydration

Hydration turns a line into work an agent can start on. The architect-issue-hydration AgentRole reads the repo, changes no code, and rewrites the issue: your words stay first, then a Hydration section with the problem in one sentence, the components and files involved with its confidence in each, 3 to 7 acceptance criteria, design notes, a verification plan and an estimate. It adds size: and component: labels and finishes with one verdict:

Verdict	What happens to the issue
HYDRATED	It gets the Hydration section and moves to Arch reviewed.
DUPLICATE	It stays in Backlog, labelled duplicate, with a comment linking the original.
BLOCKED	It stays in Backlog, labelled blocked, with the question a person has to answer.

The Change's page shows the hydration step with the architect's full summary, its cost and its log. To hydrate an issue again, for example after you added detail, or one that was opened without a Change: POST /v1/orgs/{org}/products/{product}/issues/{repo}/{number}/hydrate.

Triage

After hydration, the Change waits for a person to decide who does the work. On the Change's page, the Triage step offers:

• Build it: the issue moves to infrared:todo-agent, and the same Change goes on to build, review, merge and deploy it.
• Hand to a person: after you confirm, the issue moves to infrared:todo-human and the Change ends.

See Triage. Adding infrared:todo-agent to an issue on GitHub starts a Change for it when it has none, and that Change skips hydration and triage.

Comments steer the work

People comment on the issue on GitHub, and the agents listen. Every AgentRole that works on the issue (the architect, the builder, the reviewers) reads people's comments under the heading Direction from people on this issue, newest last, and follows them unless they conflict with the acceptance criteria or a safety rule. Infrared's own status comments are left out.

A comment made after the work is planned doesn't change the plan by itself. To have the agents take it into account, re-plan the issue's Change: it goes back to hydration and runs every later step again with the thread in hand.

Through the API, Infrared reads the thread and posts a comment as the org's App, credited to you (**<your login>** (via Infrared): …), so it reads the same on GitHub:

# Read the thread.
curl https://<host>/api/v1/orgs/<org>/products/<product>/issues/<repo>/<number>/comments -H "Authorization: Bearer $INFRARED_TOKEN"
# Add a comment.
curl -X POST https://<host>/api/v1/orgs/<org>/products/<product>/issues/<repo>/<number>/comments \
  -H "Authorization: Bearer $INFRARED_TOKEN" -H 'Content-Type: application/json' \
  -d '{"body": "Please keep the README change to one paragraph"}'
# Re-plan the issue's Change with the comments.
curl -X POST https://<host>/api/v1/orgs/<org>/products/<product>/issues/<repo>/<number>/replan -H "Authorization: Bearer $INFRARED_TOKEN"

Viewers read comments; members and above add them and re-plan.

Doing and Done

Issues move on by themselves:

• to Doing when the issue's Change starts its builder;
• to Done when the Change has merged and its deployment is live in production, or when a person closes an issue that was in Todo: human or Doing as completed (not as not planned).

A person who takes an infrared:todo-human issue moves it to infrared:doing on GitHub, and closing it marks it done.