Halfcycle 控制台逐頁展示每個專案的資訊

Halfcycle is a module that runs a five-layer build method inside your own Claude Code (npx halfcycle).

Halfcycle's agents work in your terminal. The console is where you see what they did, and where you make the decisions that are yours to make.

Every project you run with Halfcycle gets its own private console on the web. It shows where the project stands, what is being built right now, which agents are working on it, what problems were caught along the way, and what is waiting for a decision from you. It updates in real time, so nobody has to be in the session, read the repository or ask for a status update to know where things are.

In this guide, we walk through each page of the console: what it shows, and what you can do on it.

Your projects

When you sign in, you see a list of your projects. Each one shows its current state and your access level. In this example, you are an admin on one project, a viewer on another, and your access request to a third is still pending.

From here you can:

open any project's console;
see which projects have access requests waiting for your approval;
give someone access to a project without giving them access to your terminal or your code.

To start a new project, run npx halfcycle in a new folder. It appears in this list automatically.

For the rest of this guide, we use one example project, Northwind Ledger: a payments product with two phases built so far and a third waiting for approval. Every screenshot from here on is from that project.

Overview

The Overview page is the first page you see when you open a project. It answers two questions: what needs my attention, and where does the project stand?

What is waiting on you. Anything that needs your decision appears in a banner at the top. Here, the next phase (Notifications) has been planned and needs your approval before any agent starts building it. The banner tells you what to do and links you straight to it. You can also approve from your Claude Code session by typing approve notifications.

The six stages. Every Halfcycle project moves through the same six stages, in order:

Set up: name the product and prepare the repository.
Define: agree what you are building and who it is for.
Persist: write down the architecture and the rules the system must follow.
Scope: split the work into phases small enough to finish.
Design: specify each feature in detail, with a second reviewer checking it.
Build: build each phase, then test it the way a real user would.

Each stage shows whether it is complete and how many decisions were recorded in it. Below the stages are the approvals that moved the project forward, each signed by a person and dated. Because every project uses the same stages, you can compare several projects at a glance.

Further down the page are three lists:

In flight: tasks running right now, with the agent working on each and how long it has been running.
Needs a seat: tasks only a person can do, such as answering a question the spec left open, or testing the finished phase. Agents never sit waiting silently; anything that needs a person is listed here with the reason.
Flagged: tasks that are still moving but need a closer look.

At the bottom, you can see which agents are working and on what, along with the latest entries from the Ledger (the problems that were caught, who caught them, and where).

System view

The System view draws your whole product as a diagram: clients, the edge, services, data and outside services, with a card for each part. You use it to see what each phase will change, approve it before it is built, and review it when it is done.

Each phase can be viewed at three stages, using the Stage switch at the top:

Scoped: what the phase plans to change, before anything is built.
Building: progress on each part while the phase is being built.
Closed: what actually changed, once the phase is finished.

While a phase is building, each card shows its status: built and reviewed, building, not started, waiting for a person, or blocked. Two statuses are worth watching:

Not in plan: a part that changed even though the plan did not include it.
No task builds this: a part the plan expects to change, but no task has been created for it.

Both would normally only surface at the end of a project. Here you see them as they happen.

Approve a phase before it is built

Before any agent builds a phase, you approve its scope in the System view.

The diagram shows exactly what the phase will touch. In this example, one part will be added, four will change and none will be removed.

To approve a scope:

Open the System view and select the phase.
Click each planned part to see what will change and what it connects to.
Mark each part Looks right, or click Request a change and describe what should change.
Once every part is checked, click Approve phase scope.

The approve button stays disabled until every part has been checked.

If you request a change, the phase goes back with your note, and the parts you already marked stay as they are.

Approving from Claude Code. You can also approve without opening the console. Type approve notifications in your session, and the console records the approval: who approved, that it was done in chat, and which version of the plan was approved. It is also added to the phase's Build Record. Only a person can approve; text written by an agent never counts as an approval.

When the plan changes after you approve. If the plan changes after your approval, Halfcycle does not carry your approval over. In this example, a push provider was added and the event queue now owns more code. Your approval no longer covers those two parts, and no agent will build them until you approve them again. The other four parts stay approved.

Review and close a phase

When a phase finishes building, a close review opens in the System view.

Every part is listed with what actually happened to it: added, changed, removed, not in plan, or planned but not built.

For each part, you can accept it, ask a question, or send it back. Any planned part that was not built must be either carried over to the next phase or dropped, with a reason. Once every part has a decision, you close the phase.

Closed phases keep their diagram. Click any part to compare what the plan said with what Halfcycle actually found in the code. In this example, the audit trail was planned but not built, so it was carried over to phase 2, and the reason is recorded on the card.

This gives you a written record of every phase: what was agreed, what was delivered, and what moved to the next phase and why.

Live build

The Live build page shows the current phase as it is being built.

Tasks are arranged in waves, in the order their dependencies allow. Each card shows the task, the agent working on it, the reviewer who will check it, and how long it has been running. The bar across the top shows tasks completed, in flight, waiting for a person and blocked, along with time elapsed and overall progress.

Task details. Click any task to open its details beside the graph.

The panel shows:

time spent against the estimate, and whether it is on time;
the agent building it and a different agent reviewing it;
which tasks it is waiting on, and which tasks are waiting on it;
whether it is on the critical path.

Critical path. Click Critical path to highlight the chain of tasks that determines when the phase will finish. A delay on any of these tasks delays the whole phase.

Crew

The Crew page shows the team of agents working on your project.

The team is grouped by role:

Analysts and architects question the idea and design the system before anything is built.
Builders write the code and the specs.
Reviewers check what the builders produced.
Leads run the team and watch every change.
You approve the scope, answer the questions only you can, and accept each phase.

Below the team, a grid shows which roles lead and which help at each of the six stages, with the current stage highlighted.

Each agent is listed with its role and current status: working on a task, idle, waiting for a person, or stood down because its part of the work is finished.

The assignment rules are shown in plain language:

A task only goes to an agent with the right skills for it.
A builder never reviews its own work.
Each agent works on one task at a time.
The final acceptance test is done by a person, and that person cannot be the builder.

Layers

The Layers page lists every step in every stage, with its status and the evidence behind it.

Evidence can be a document, an answered question, a code change, or the reason a step was put on hold. Steps that need a person are marked, and steps that cannot run yet explain why. Below the list are the documents each stage produced and the approvals that closed it.

Use this page when you need to check whether something was decided, and where. Every answer links to its source, so you do not have to search through chat history.

Ledger

The Ledger records every problem Halfcycle caught on your project, newest first.

Each entry shows:

what happened: blocked in the code, fixed automatically, corrected in the spec, corrected in the scope, prevented by a question, raised for a person, or approved in the System view;
when and where: the stage it happened at, and a link to the evidence;
who caught it: the agent or person;
what changed as a result.

Checks in force lists the automatic checks running on this project, what each one looks for, and whether it blocks a change or only warns. Most checks apply to every Halfcycle project: when an implementation goes wrong anywhere, the cause and the fix reach every project automatically. Some checks are specific to this project.

Machines lists every computer working on the project and whether Halfcycle's checks are running correctly on it. If a check is missing on a machine, this section tells you which one.

The Ledger is a record of the problems that never reached your product, and exactly where each one was stopped.

Phases

The Phases page shows the history of the project, one row per phase.

For each phase, you can see its dates and duration, its approvals, the defects found when a person tested the finished phase, and the outcome. In this example, one phase was accepted after a second round of testing with three defects fixed, and another was accepted first time with its Build Record delivered.

Each phase is locked when it closes, so its history cannot change afterwards.

On mobile

The console works fully on a phone.

When something needs your decision, the console opens on your to-do list. Otherwise, it opens on the project diagram.

Summary

With the Halfcycle console, you can:

see what needs your decision as soon as you open a project;
review every phase as a diagram and approve it part by part before anything is built;
rely on approvals that stop counting for any part of the plan that changes afterwards;
compare what was delivered with what was agreed when each phase closes;
see the critical path, so you know when a phase will finish and what could delay it;
manage all your projects from one screen;
share a live page instead of writing status updates;
keep a record of what was agreed, built, carried over and dropped, phase by phase;
see every problem that was caught before it reached your product.

Get started

npx halfcycle

Run this command in the folder you want to work in, then open the folder in Claude Code and describe what you are building. When the install finishes, it shows the address of your project's console.

Rolling Halfcycle out across a team or a company? Talk to us about fitting it to your process.

halfcycle.ai