The dashboard
A tour of the hlix web app — the portfolio overview, the Canvas, Files, and the screens where you review work and answer agents.
The dashboard brings project delivery into one place: follow the team, review changes, configure projects and answer agents’ questions. The CLI and API also expose workflows for local files and automation. It is at app.hlix.ai.
Prerequisites
Section titled “Prerequisites”- A hlix account and a workspace you are a member of
- Agency role (
owner,admin, ormember) for most screens; portal clients see the projects and deliverables shared with them
How the navigation is organised
Section titled “How the navigation is organised”The sidebar has three bands: portfolio first, then the things that need you, then workspace-wide records.
| Band | Items | Answers |
|---|---|---|
| Portfolio | Overview · Projects · Clients · your recent projects | “How is delivery going?” |
| Attention | Inbox · Approvals · Activity | “What needs me?” |
| Workspace | Global Knowledge · Custom Skills · Integrations · Invoices · Audit Log | “What is configured, and what happened?” |
Approvals carries a count badge when a request is waiting for a person.
The Overview screen
Section titled “The Overview screen”The portfolio screen: a stat row across the top, then delivery, workload and billing panels, then the two lists that tell you where to go next.
Project health ranks at-risk work first — a project with a failed cycle appears above one that is merely blocked. Needs attention is the narrower list: the signals that will not resolve on their own.
Use Overview to identify which project or request needs attention.
Projects
Section titled “Projects”Projects are grouped by client, with an Internal / unassigned group for work not attached to a client account.
Four views of the same set — Grid for scanning, List for comparing columns, Kanban for delivery stage, Timeline for when things land. Each card carries the project’s cycle progress, spend so far, and its connected repository. New projects use HLIX Repos unless you connect a GitHub repository.
Clients
Section titled “Clients”A client record groups that customer’s projects, delivery status and billing.
Delivery health and outstanding balance sit on the same row, so you can assess delivery and billing for each client together.
The project page
Section titled “The project page”A project has five main tabs:
| Tab | What it holds |
|---|---|
| Conversation | The activity and the project’s chat room |
| Cycles | The Cycles board, plus the roadmap, the Canvas, a kanban and the request queue as other views of the same cycles |
| Review | What is ready to ship: the pull request, and every e2e journey and its outcome. See Reviewing output |
| Cloud Machine | Files, Terminal and Desktop |
| Library | Artifacts and context |
Usage and Settings open the project’s settings window.
The Cycles board
Section titled “The Cycles board”The Cycles board lists every cycle of the project. Each cycle is one build agent working on the cycle’s own branch, and its tasks are that build agent’s checklist: an item turns building when the build agent starts it and done when it is committed, live, with no refresh. Team now sits on top: the role hired for each cycle that is running right now. A cycle that is waiting for a free build agent stays a draft until one is free. See Cycles.
The Canvas
Section titled “The Canvas”The Canvas draws the same project as a team: the project manager and the roles working for it, as cards you can watch while they run.
This is agents and orchestration made concrete: one project manager, and one build agent per running cycle, each card carrying its progress. Agents have names from your workspace roster: the role says what an agent does, the name says which agent it is.
Below the team, the project’s cycles sit in status columns — Triage · Planned · Running · Done · Failed · Canceled — with a column drawn only once something is in it, and arrows carrying the roadmap order across them. A cycle triage declined therefore has a place on the board instead of reading as work that never started. The board follows cycle status automatically.
Terminal and Desktop are agency-only; a portal client does not see them. Files opens the project’s full IDE — see below.
Preview shows the project’s hosted preview: built once each time work merges into the project’s preview branch, and private to people who can see the project. Static previews serve built files; opening a server preview can start a Cloud Machine on demand. Reload loads the latest build, and Deploy ships the main branch to a public address once you have merged it. Terminal and Desktop each start a Cloud Machine from the project’s Project Environment when you open them, at the head of the preview branch, and say so while it starts. Everyone on the project shares that Cloud Machine; it stays up while a tab uses it and is deleted 15 minutes after the last one closes, so anything you change there and do not push is temporary. The Desktop’s browser opens the hosted preview. The Desktop tab lists the screen of each build agent that is working, plus the project’s own; a single one opens directly. You watch it, choose Take control to click and type (the agent waits and says so), and choose Give back to return it. Everyone sees who has control. Closing the tab gives it back too.
The right rail is where you talk to the team. Its composer — “What do you want the agents to work on today?” — is what starts a run.
Files, in the project header, opens the project’s IDE with a repository explorer, file tabs, and a diff or source viewer. Quick open finds a file by name, and Search finds matching changed lines. Collapse the explorer to give the viewer more room. On a narrow screen, Explorer opens the tree in a sheet.
The explorer lists the repository’s files and marks changes as added, modified, deleted, or renamed with their +/− counts. A filter narrows the tree by name. Changes groups files by the work that produced them. Picking a file opens its tab; switch between Diff and File, and between unified and split diff layouts. HTML files also offer Rendered and Source views. A Viewed mark lets you tick off files as you review them.
Changes compare the project’s integration branch against the repository’s default branch, for both HLIX Repos and GitHub. The comparison named above the tree identifies the branches being reviewed.
Files updates as project changes arrive. A file a running task is writing carries its own live mark, and its diff is read from that task’s Cloud Machine. Committed source comes from HLIX Repos or GitHub and remains readable while no Cloud Machine runs. Opening Files never starts a Cloud Machine.
A portal client sees changed files and their diffs. Browsing the whole repository, full file content, and rendered HTML are agency-only. Protected files such as .env cannot be opened through Files.
Watching the team work
Section titled “Watching the team work”Four surfaces show a running project, and they answer different questions.
The timeline, in the Chat tab
Section titled “The timeline, in the Chat tab”The right rail’s Chat tab shows your conversation alongside live planning, build and review progress. Decisions include a short reason; review findings also appear on the checklist items they reopen.
The timeline fills in from the moment you open it. For earlier decisions, inspect the cycle’s stage history, the cycle’s chat and review evidence.
What the agents did
Section titled “What the agents did”Open a cycle’s chat to read what its agents did. Every run of the cycle (plan, build, review rounds) shows as one section: its reasoning, each tool it called, the output of its commands and its final answer, redacted against the project’s secrets. A run that is at work arrives as it is written. A finished run is read from its stored record, which is kept for 90 days after the run ends; after that the chat says the detailed record is no longer kept and shows the summary the cycle itself kept. A message you write in a cycle’s chat goes to that cycle’s agent.
The project manager’s card
Section titled “The project manager’s card”Expand the project manager’s card and its Thinking tab shows its turn as it happens — its reasoning, its text, and each tool it calls, marked pending then complete. Beneath it is a composer that sends a message now: what you send while the turn is running is folded into it rather than queued for afterwards.
Agent cards
Section titled “Agent cards”An agent card carries two tabs.
Thinking shows the agent’s reasoning, text and tool calls as the coder reports them.
Activity lists the steps the agent actually took — commands, edits and tool calls — read from its Cloud Machine. If an agent’s Thinking tab is empty, Activity is the live signal for that coder.
Activity is visible to agency members; portal clients see the progress and deliverables shared with them.
Everything waiting on a decision from you, newest first — the single queue to clear before you go looking for work.
It groups by what kind of answer is needed: a decision waiting for you, and a failed run worth a look. Approvals is the narrower view of the first group.
Approvals
Section titled “Approvals”Approvals agents have recorded for a person: a question, a tool decision or a request for a cycle. A tool decision can pause the agent’s chat. New agency delivery projects that require an initial proposal also wait for approval before the first build agent starts.
See Approvals.
Activity and Audit Log
Section titled “Activity and Audit Log”
Activity shows recent events across the Workspace.
Audit Log records audited actions, with integrity verification and access restricted to owner and admin. See Audit log for coverage and investigation tools.
Project settings
Section titled “Project settings”Settings opens the project’s settings window. It has five tabs, grouped by the question you are asking. Every tab is agency-only.
| Tab | What it holds |
|---|---|
| General | Name and goal; the project’s AI settings (the Project manager and Cycle groups, including Parallel cycles); the run switch; the branch prefix; and, under Advanced, the project’s agents |
| Memory | What the agents remember, and the packs and skills they bring |
| Environment | Repositories; the Cloud Machine (setup recipe, environment, verification, live preview and each repository’s commands); secrets and Environments; Connections, which list the sources that can push work; Linear |
| People | Team members, portal clients and invitations |
| Usage | Budget, delivery metrics and logs |
A few of these decide how the project behaves rather than what it contains:
- Usage → Metrics reads the project’s flow from cycle stage history — throughput, cycle time, time per stage, aging work, and how much of the automation held without rework. See Delivery metrics.
- Environment → Connections lists one switch per external source that can push work at this project — Linear and GitHub issues — deciding whether each may open a cycle here. The sources you drive yourself carry no switch: chat, the board, and the API are always open, because asking for the work is already the decision. See Sources.
- Environment carries each repository’s setup command and verification command, plus the project-wide verification default — see below.
Environments, secrets and packs are covered under Configuration, and portal clients under Client access and Roles & permissions.
Repository setup and verification
Section titled “Repository setup and verification”The repository setup command runs before the coder starts; verification runs after it finishes. Set them per repository under Environment, with a project-wide verification default where needed. See Repositories for configuration and Verification for results, repair attempts and skipped checks.
Workspace configuration
Section titled “Workspace configuration”- Global Knowledge browses the Workspace-scoped memory — the standards that apply to everything.
- Custom Skills manages the skills available to your agents.
- Integrations connects GitHub, Linear, Slack, and Telegram.
- Settings covers the workspace, people and roles, AI settings (models, coder and parallel cycles), developer tools (API keys), billing, and regional preferences. Models & accounts → Defaults has two groups, Project manager (the model that runs the project manager, chat and triage) and Cycle (the coder, its provider and model, effort, and how many build agents work at once). A project can follow the Workspace defaults or set its own.
If a screen looks wrong
Section titled “If a screen looks wrong”- Overview panels read zero across the board. The workspace has no completed work yet, or you are in a workspace you just joined. Check the account switcher at the bottom of the sidebar.
- A project you expect is missing from Projects. Portal clients only see projects shared with them. As an agency member, check the
Internal / unassignedgroup — a project with no client lands there. - The Canvas shows agents but no activity. Nothing has been dispatched yet. The right-rail composer is what starts a run.
- Files says “Repository can’t be reached”. The connected repository could not be read. Check repository settings and the workspace’s repository connection, then try again.
- Files says “No such repository in this project”. The project needs a connected repository. New projects receive HLIX Repos automatically unless created with GitHub.
- All files is missing from Files. That mode is agency-only. A portal client sees changed files and their diffs, not the whole repository.
- An agent card’s Thinking tab is empty while it is plainly working. That coder does not report its reasoning. Read its Activity tab instead.
- The chat timeline is shorter than the run. It fills in from the moment you attach and does not survive a reload. The durable records are Logs and the cycle’s own history.
- Metrics says “No cycles yet” on a busy project. Metrics measures cycles, not tasks. Work that never became a cycle has no stage history to compute from.
- The Approvals badge shows a count but the list is empty. It was answered elsewhere; reload.
- Audit Log returns nothing for a member account. It is restricted to
ownerandadmin. - A settings page refuses a change you can see. Some settings are
owner/adminonly, notably the workspace-wide coder, which applies to every project.