Forge

An initiative is a unit of work that Liddr moves through the software-delivery lifecycle — from a rough idea, through requirements and design, to architecture, and finally into Build, which generates the pull requests that implement it. Each step is grounded in your knowledge graph, and every artifact and run is recorded so you can see what was produced, what it cost, and where it ended up.

What an initiative is

An initiative captures a title, a description, the repositories it targets, and the stage it's currently in. As it advances, it accumulates stage artifacts — the requirements draft, the design, the architecture decision record — each versioned and editable. Initiatives are owned, can be archived, and can run a shorter pipeline than the default when the work is simple.

The stages

The default pipeline moves through these stages in order:

discovery → requirements → design → architecture → implementation → review → done

Each stage produces something concrete:

Stage	What it produces
Discovery	Frames the problem and the goal, grounded in existing work in the graph.
Requirements	A structured requirements draft — epics and stories with acceptance criteria.
Design	The design for how the work should look and behave.
Architecture	An architecture decision record describing the technical approach, including any cross-repo build dependencies.
Implementation	The Build phase — generates pull requests in the target repositories.
Review	Review of the produced work before the initiative is marked done.
Done	The initiative is complete.

Pipelines can be shorter

Templates can pre-fill a shorter pipeline for simpler work — a bug fix, for example, can skip design and architecture. The stages above are the full default; an individual initiative goes through whatever pipeline it was configured with.

Moving an initiative forward

Stages with a human gate — requirements, design, architecture, implementation, and review — pause for your approval before the initiative advances. To move an initiative forward:

1. Open the initiative and review the artifact the current stage produced.
2. Edit it if needed. Requirements and discovery artifacts keep a per-field edit history.
3. Approve the stage to advance to the next one, or send it back to be regenerated.
4. Continue until the initiative reaches Build.

Each stage execution is recorded as a stage run with its status (running → succeeded, failed, or zombied), its timing, the artifact it produced, and its cost. If a run fails, you can inspect the error and retry.

Approval gates exist for a reason

A stage that needs an artifact won't let you approve until that artifact exists. Read the artifact before approving — downstream stages and Build all build on what you sign off here.

Build: generating pull requests

When an initiative reaches implementation, Build turns the approved requirements and architecture into code. Build runs one or more build jobs, typically one per target repository. Each job works in its own branch and worktree, implements the stories assigned to it, and opens a pull request.

A build job tracks the full picture of what it did:

• Status — queued through to completion (or failed / interrupted).
• Output — the branch, files changed, commits, a diff summary, and an implementation report.
• Story coverage — which stories it implemented, and whether each is done, partial, or not started.
• Pull request — the PR URL and number once opened.

When a job fails or its PR needs another pass, you can rerun it — for example with Fix & open PR — and Build will supersede the prior attempt.

Tracking cost, tokens, and PR state

Liddr records spend and token usage at every step so the cost of an initiative is never a mystery:

• Stage runs record a cost_usd per run.
• Build jobs record input, output, and cache token counts plus a cost_usd.

Build jobs also track PR state so the initiative knows whether its work actually shipped. A background reconciler polls each open PR and updates its state to one of:

• open — the PR exists and hasn't been merged or closed.
• merged — the PR was merged; the merge time is recorded.
• closed — the PR was closed without merging.

This means an initiative reflects reality end to end: from the idea, through the artifacts and their cost, to whether the generated pull requests landed.

Related

• Change requests
• Know
• The knowledge graph