Web interface

You do most of your work in Cadence over MCP. The web interface is the second way in. Use it when you want to look at something, such as a workflow's board view, a task or a doc, and for the things MCP does not do. This page covers how you sign in, what only the browser does, where to download the command-line client, and the two places the browser gives you to find and read a task: the search window and a task's own page.

Replace https://cadence.example.com with your instance's address.

Signing in

Open https://cadence.example.com/sign_in. Sign in with your email and password, or choose Continue with Google if your instance has Google sign-in set up. Google sign-in links to an existing account and does not create one. See OAuth § Sign in with Google. If you have forgotten your password, use the Forgot your password? link on the same page.

There is no sign-up page. You need an account on the instance before you can sign in. An instance administrator creates accounts in the browser, under Settings at /settings/users, and sets each new account's email and password there. Cadence sends no invitation, so the administrator gives you your email and password themselves. If you do not have an account, ask whoever administers your instance.

Signing in does not by itself give you access to a space. Your role in each space (viewer, member or admin) decides what you can see and change there. See Authentication § What your role decides.

What only the browser does

These things have no MCP tool and no HTTP API route. Each linked page gives the details.

• Creating a space, and changing its name or key. Most other space settings, such as tags, checks, task types and credentials, also have MCP tools. See Spaces.
• Setting a space's Max vCPU ceiling. See Max vCPU.
• Setting or rotating a credential's secret value. Over MCP you can list a credential's details and revoke it, but not see or set its value. See Credentials § Set and rotate in the web interface.
• Entering an LLM-provider token's value. See LLM providers § Register, enter tokens, and refresh in the browser.
• Viewing the instance's background jobs, for whoever runs the instance. See Jobs.
• Downloading a doc as a Markdown file. See Docs § Download a doc.
• Comparing two versions of a doc. See Docs § Compare versions.
• Adding people to a space, changing their role and removing them, at /settings/spaces/<KEY>/memberships, where <KEY> is the space's key. An admin of the space or an instance administrator can do this. An instance administrator reaches it from Settings with the space's Members link. A space admin has no link to it and opens the address directly. The instance-administrator parts of Settings answer 403 Forbidden to anyone else: /settings itself, /settings/spaces, /settings/users, /settings/images, /settings/credentials, /settings/llm_providers, /settings/agent_skills and /settings/jobs. Your own /settings/account, /settings/account/connected_applications and /settings/api_tokens are open to any signed-in user.
• Creating user accounts, for an instance administrator, at /settings/users. See Signing in.
• Creating and revoking your own API tokens, at /settings/api_tokens. See Authentication § API tokens.
• Adding and removing Slack apps. See Messaging and contacts § Slack apps.

A workflow's pages

A workflow's pages live under https://cadence.example.com/spaces/:space_key/teams/:team_slug/workflows/:slug, where :space_key is the space's key, such as OPS. That address opens the workflow's board view: its stage groups drawn as columns, with each task as a card. The workflow's settings, stages, stage groups and constraints have pages below it, such as …/workflows/:slug/settings.

Addresses containing /boards/ no longer open anything. If a bookmark stops working, open the workflow from its team, or use its permalink, /spaces/:space_key/workflows/:id-:slug, which keeps working after the workflow is renamed or moved to another team. You do not have to build the permalink yourself: it is the url in the workflow's ref that workflows_get and workflows_list return over MCP. See Workflows and stages § Workflow URLs.

Downloading the command-line client

On an instance that offers the cadence command-line client for download, the user menu (the avatar at the right of the top navigation) has a Download CLI item, below User settings, and above Instance settings if you are an instance administrator. It opens /cli, which any signed-in user can open. On an instance that does not offer downloads, the item is not there and /cli answers 404 Not Found. The same downloads are available over MCP and the HTTP API; see Downloading the command-line client.

Search

The search window finds tasks and docs in your current space: the space you last picked in the top navigation's space switcher. If you have never picked one, or the one you picked is no longer open to you (for example, it was archived or you were removed from it), it is the first of your active spaces in alphabetical order by name, and that becomes your current space. It is not the space of the page you are looking at. On a task's page in another space, the window still searches your current space, so switch spaces first to search that task's space.

The search window uses the same matching rules as every other way in. See Search for how a query matches, and for how a task key finds its task.

Opening it

Press Cmd+K (macOS) or Ctrl+K (other systems), or click Search in the top navigation. The shortcut does nothing while your cursor is in a text field, so it never interrupts your typing. The Search button is in the top navigation on every page that has one, as long as you belong to at least one active space. If you belong to none, there is no Search button.

What you see

Type a query. Results update shortly after you stop typing. Results appear under two headings, Tasks and then Documents. A heading with no matches is left out. If nothing matches at all, the window says No matches for "…".

Each heading shows how many results it found. Cadence fetches up to 25 results for each heading. When a heading reaches that limit, its count reads 25+, because more may match than were fetched. Each heading shows at most 5 rows, so narrow your query to reach a result further down.

A task row shows:

• the task's key, such as OPS-42
• its task type
• its title, with the matched words highlighted
• its workflow, stage and status. Status is On hold, Resolved or Open. On hold means the task carries a hold of either kind. See Tasks § Holds. Archived tasks are never returned.
• a snippet of the body around the match, if there is one. A task found by its key has no snippet.

A document row shows its title with the matched words highlighted, where the doc sits in the doc tree, and a snippet.

The search window trims your query before searching. A trailing space therefore does not finish the last word here: roll still finds rollback. End the query with a closing " or a punctuation mark to match whole words only. See Search § How a query matches.

Using the keyboard

Focus stays in the search box while you move through the results.

For screen readers, the search box is a combo box and the results are a list of options. The highlighted result is marked as the active option.

Opening a result

Click a result, or highlight it and press Enter. The window closes and the result opens as a full page: a task opens on its own page, and a doc opens on its reading page. Pressing Back does not reopen the search window.

The search box stays fixed at the top of the window while you scroll through the results, and the window stays in place as results load.

The docs search page

The docs search page searches one space's docs only. To open it, go to the space's docs and click the Search docs button (a magnifying glass) at the top of the doc tree. You can also open https://cadence.example.com/spaces/OPS/docs/search yourself, with your space's key in place of OPS.

Type your query in the Search docs… box and click Search. The query is sent as the q parameter, so /spaces/OPS/docs/search?q=rollback opens the page with results for rollback. The page follows the same matching rules as the search window, highlights the matched words in each title, and shows a snippet for each doc.

A task's page

Every task has its own page at /spaces/:space_key/tasks/:task_key, for example /spaces/OPS/tasks/OPS-42. You reach it:

• from https://cadence.example.com/tasks/OPS-42, which redirects to the task's page wherever the task sits
• from the url in a task reference returned over MCP. See MCP § Entity references.
• from a task result in the search window

You must be signed in and have read on the task's space. If you are signed out, both addresses answer 404 Not Found, not a sign-in page. Sign in first, then open the address again.

If you have no role in the task's space, you get a 403 Forbidden page headed You don't have access to this., with the code role_insufficient and the reason no membership on space. The page says If you should be able to reach this Space, ask an admin to grant you a Membership. Ask an admin of that space to give you at least the viewer role. See Authentication § What your role decides.

The task's page is a full page, with the top navigation and the search window available. It shows:

• the task's card, as it appears in the board view
• an Archived badge, if the task is archived. Archived tasks keep their page.
• the task's Body, Assignee, Priority, Parent, Tags and Stage. You change each one in place with its Edit link, as in the task drawer in the board view. You need the same role here as in the drawer: member to change a task. See Tasks. Choosing a pool as the Assignee creates a lease for that pool on the task straight away. It needs no assignment rule and goes ahead despite an unresolved dependency or an unpassed required check. If a lease of that pool is still active on the task, Cadence reuses it and starts no second worker. If the task has a blocking hold, the worker is refused when it tries to start. If the pool is paused or has no room, the lease waits, not started, until it is unpaused and has room. See What happens after a refused move.
• the parent task, if there is one. Its link opens the parent's own page.
• a View on board link, which opens the board view of the workflow the task is on

There is no separate status list. The task's stage is shown in the Stage field. When you change the stage or the assignee, the field and the card update in place.

Holds on a task's page

If the task is held, its card shows a badge. A blocking hold shows Blocked · On hold. An advisory hold shows Waiting · Needs attention, unless something else is also stopping the task, in which case the badge names that instead.

The task's page has no Clear hold button. To clear a hold in the browser, click View on board and open the task there. In the task drawer, either:

• click Clear hold, or

• under Retry pool, click Dispatch next to a pool. This always clears the hold. It starts that pool on the task again only when all of these are true; otherwise the hold is cleared and no worker starts:

  • an assignment rule at the task's current stage names that pool and applies to the task (see Stage rules § How a rule's scope is chosen)
  • no lease of that pool is still active on the task the rule leases. A rule with target: parent leases the task's parent, not this task, and starts nothing if the task has no parent or the parent is not of the type the rule names.
  • the task has no unresolved dependency and no unpassed required check at its stage

  A pool is listed once one of its leases on the task has finished since the task entered its current stage, even if a newer lease of that pool is still running, and even if that lease came from a scheduled rule, an inbound rule or an assignment made by hand rather than from an assignment rule. If no assignment rule at the stage names that pool, Dispatch clears the hold and starts nothing. To get such a pool running on the task again:

  • A pool you assigned: assign the task to the pool again, with the Assignee field or with tasks_assign and assignee: "pool:<id>". See Tasks § Assign a task.

  • A scheduled rule's pool: it runs again at the rule's next due time. See Scheduled rules.

  • An inbound rule's pool: it runs again when a new matching event arrives, or when an event that was already waiting in the dispatch queue reaches its turn. A waiting event starts the pool with no new event and no person, but only if, when its turn comes, the task has no blocking hold, no unresolved dependency that blocks at its current stage and no unpassed required check. If one of those stops it, the event is closed without starting anything and is not tried again. An event whose turn came while the hold was still on has already been closed this way, so it does not run after the clear.

    Cadence takes the waiting events for a task and pool one at a time: on each pass it closes or starts only the oldest. So while the hold is on, it closes them one by one, and if you clear the hold before it has closed them all, the next one starts the pool after the clear.

    To stop the waiting events from running, remove each of them with inbound_queue_remove before you clear the hold. This needs admin; if you are a member, ask a space admin to do it before you clear the hold. Find each event's id with inbound_queue_list space_key=OPS: they are the waiting rows whose subject is the task and whose pool_id is the pool.

    If no event for the task and pool is still waiting, Cadence will not start that pool on the task again until a new matching event arrives. To run it sooner, assign the task to the pool yourself, with the Assignee field or with tasks_assign and assignee: "pool:<id>". Assigning does not use up an event that is still waiting: the event waits while the lease you started is active, and once that lease ends it starts the pool again, with no person, if the task passes the same conditions. If you do not want that second run, remove the waiting event first. The lease you start waits, pending, while the pool is paused, the space is archived, or the pool, the space or the instance has no room, and starts once all of them allow it.

    To check whether an event was closed, an admin can run inbound_queue_list space_key=OPS state=done; the event's delivery in inbound_deliveries_list is marked failed with the gate's reason. See Inbound § The dispatch queue and Inbound § When a dispatch mints nothing.

Over MCP, three tools clear a hold: tasks_clear_hold, tasks_nudge and tasks_dispatch_pool. See Tasks § Holds, Tasks § Nudge and Tasks § Dispatch to a pool. Do not use tasks_nudge on a hold whose reason ends in (3 attempts): after a nudge, the third lost lease on that pool places no hold, so the task can sit idle with nothing pointing you to it. The pool stays blocked even if another hold has since replaced the (3 attempts) hold, so the task's current hold does not tell you. Use Clear hold or tasks_clear_hold. If you are not sure, or you have already nudged, call tasks_dispatch_unblock with the task's key and no pool_id straight after the nudge: it resets every pool that is still blocked and lists them in cleared. See Tasks § A nudge turns off the lost-lease hold.

A blocking hold is meant to wait for a person. All three ways to clear it refuse a worker: only a person's own account, in the browser or with their own token, can clear a blocking hold through them. While it is on the task, no pool starts new work on the task and no sentinel rule moves it, whatever its checks say.

Do not rely on a blocking hold staying in place with no person involved. A worker whose lease reaches the task can call tasks_set_hold with kind: "advisory". That replaces the blocking hold with an advisory one, which any caller, including that worker, can then clear, and which a move to another stage clears on its own. A worker whose lease reaches the task can also still move it, held or not, whenever its lease started (see What happens after a refused move). A lease reaches more than the task it was leased for: by default also the task's parent, children and siblings. See Leases § What a lease can reach.

You can see when this happens. The task's timeline records every hold change as a hold_set entry with the new kind and who set it. A clear is a hold_cleared entry, except a clear made by tasks_nudge, which is a single nudged entry carrying the cleared hold's reason in cleared_reason. A move between stages is a transition entry and a move to another workflow a transferred entry. Each names who made it in by. Read it in the task drawer or with activities_list. See Tasks § Comments and the activity feed and Hold a task and clear a hold.

Blocking holds do not only come from people. Cadence places one itself in these cases. Each one is cleared, or changed by a worker, in the same ways as above. On any workflow:

• A worker's lease on the task failed, was stopped for running past its pool's time limit, or stayed deferred for too long.
• A pool could not be dispatched for the task after repeated attempts.
• The task has entered its stage more times than the stage's re-entry limit allows. This is checked on every move, including one you make or force from this page.

Only on a workflow with auto-advance turned on (auto_advance_enabled), in a space that is not archived, at a stage that is not archived, and only for a task that is not archived and has not been resolved since it entered its current stage. Cadence places these holds during the same sweep that runs sentinel rules, so on a workflow with auto-advance off it never places them, and a stuck task there stays unflagged until you notice it:

• A stage's work looks abandoned. Cadence places this hold only when all of these are true:
  • the stage has abandoned_work_detection turned on
  • no sentinel rule at the stage moved or held the task on that pass
  • the task is not waiting on an unresolved dependency that blocks at its current stage
  • at least one lease of a pool named by an assignment rule at the stage that applies to the task (see Stage rules § How a rule's scope is chosen) has been created since the task entered the stage. A task that no assignment rule at its stage applies to never trips this hold, and leases of pools that no assignment rule applying to the task names do not count.
  • none of those leases is still active, and the newest of them finished more than 3 minutes ago
  • a check the stage expects is still missing or pending
• A sentinel rule whose action is to hold the task matched it.
• Cadence failed 3 times to evaluate the task's sentinel rules during its current stay at the stage. The count starts when the task entered the stage, and starts again each time a hold on the task is cleared with tasks_clear_hold, tasks_dispatch_pool, or the task drawer's Clear hold or Dispatch. A clear made with tasks_nudge does not restart the count.

The hold's reason says which case it was. See What moves a task without a person.

Moving a task from its page

Moving a task to another stage from this page follows the same rules as moving it anywhere else. The move is refused, and the task stays where it is, when:

• a check the target stage requires has not passed
• a property the target stage requires is not set
• the target stage does not accept the task's type
• a WIP limit on the target stage is full. A WIP limit refuses moves into a set of stages on a workflow once that set holds the limit's number of tasks. It refuses a task only when the task comes from a stage outside that set and matches the limit's task-type or tag filter, if it has one. It is checked only when a task moves between stages on a workflow: creating a task, moving it to another workflow and a forced move do not check it, so the set can hold more tasks than the limit. See Stage rules § WIP constraints.

What you see depends on the refusal and on your role in the task's space.

• If the move skips a stage group (one of the columns a workflow's board view draws its stages in), the Stage field asks you to confirm it: You're skipping … Continue?, with a Confirm move button.
• If you are an admin of the task's space and required checks refused the move, the Stage field lists the checks that have not passed, with each one's current state, under Moving to … requires these checks. Force the move?, with a Force move button. A forced move goes ahead despite the refusal.
• Otherwise the page shows each reason in a red box above the fields. The wording is the refusal's own:
  • Stage requires check review_passed to be passed (currently pending)
  • Stage requires property owner to be set (currently missing). The state is blank when the property is set but empty.
  • Stage does not accept task type Bug
  • Stage constraint Review WIP is at its limit of 3. When the limit counts tasks per parent, the message ends with the group it counted, for example … at its limit of 3 for parent OPS-40 or … at its limit of 3 for tasks with no parent.

"Admin" here means the admin role in the task's space, not the person who runs your Cadence instance. See Authentication § What your role decides.

The browser offers a forced move only to a space admin, and only when required checks refused the move. A space admin can force a move refused for any of the four reasons over MCP or the API, by passing force: true. See Tasks § Move a task between stages. To get past a refusal:

• have the check set to passed (see Checks)
• set the property (see Task data § Properties)
• for a WIP limit, wait for a task to leave the stages the limit covers, or ask an admin of the task's space to raise the limit
• or ask an admin of the task's space to force the move

What happens after a refused move

Cadence does not retry the move you made. The task stays at its current stage until something moves it. These can move it without a person:

• A sentinel rule at the task's current stage. Cadence re-checks every eligible task every 30 seconds. It moves the task once all of these are true:
  • the workflow has auto-advance turned on (auto_advance_enabled)
  • the space, the task's current stage and the task itself are not archived
  • the task has no blocking hold
  • the task has not been resolved since it entered its current stage
  • every lease of the pools named by the stage's assignment rules that apply to the task, created since the task entered the stage, has finished. A lease of any other pool does not delay the move, for example one started by a scheduled rule, an inbound rule, an assignment to a pool, or a target: parent rule at a child's stage. Cadence can move the task while that worker is still running on it.
  • the rule applies to the task (see Stage rules § How a rule's scope is chosen), and its predicate over the checks at the task's current stage holds. These are not the checks that refused your move. If a hold rule at the stage matches first, Cadence sets that hold instead of moving the task.
  • the target stage's gates pass. If they do not, Cadence goes on to the next rule at the stage whose predicate holds, in the same pass. That rule can move the task to a different stage or set a hold. Only when no later rule matches does the task stay put, and Cadence tries again every 30 seconds, so the task moves once a WIP slot frees up or a missing check or property is filled in.
• A worker. A worker whose lease can reach the task can move it to another stage over MCP with tasks_transition, even while the task is held. That move goes through the same gates as yours, and a worker can never force a move. A worker can also move the task to another workflow with tasks_transfer, held or not, but only while no other lease on the task is still active. A worker reaching the task from a related task cannot transfer it while the task's own lease is running.

What each condition stops:

• Auto-advance turned off on the workflow stops the whole sentinel sweep for that workflow. No sentinel rule moves the task, and Cadence never places the abandoned-work, sentinel-hold-rule or evaluation-failure holds listed in Holds on a task's page. It does not stop a worker from moving the task, and it does not stop pools from starting work on it. Pools are still started in five ways:

  • An assignment rule at the task's stage. It creates a lease only while the task has no blocking hold, no unresolved dependency that blocks at its current stage and no unpassed required check at its stage, and no lease of that pool on the task is still active. See What moves a task without a person § A pool leases and works a task.
  • An inbound dispatch-worker rule that names the task. It checks the same conditions once, when it is its turn to run. If the task is held, blocked by a dependency or waiting on a required check at that moment, the match is recorded as failed and is not tried again. It waits only while a lease of that pool on the task is still active.
  • A scheduled rule with the task as its subject. It does not wait for dependencies or required checks. While the task has a blocking hold, it still creates a lease, and that worker is refused when it tries to start. See Scheduled rules § A scheduled rule at a held or blocked task.
  • An assignment rule with target: parent at a stage one of the task's children enters. Cadence checks the hold, dependency and required-check conditions against the child, not this task. So this task is leased despite its own dependency or unpassed required check. If this task has a blocking hold, the lease is still created and its worker is refused when it tries to start.
  • An assignment to a pool, made by a person with the task's Assignee field or by anyone with tasks_assign and assignee: "pool:<id>". A worker whose lease reaches the task can call tasks_assign too. It creates the lease straight away and checks no hold, dependency or required check. It reuses a lease of that pool on the task that is still active instead of creating a second one. If the task has a blocking hold, the worker is refused when it tries to start; otherwise it runs.

  In every case the lease is created even when the pool is paused or has no room. It then waits, not started, until the pool is unpaused and has room.

• A blocking hold stops sentinel rules from moving the task and stops pools from starting new work on it. Any worker whose lease reaches the task, including one started after the hold was placed, can still move it between stages or replace the hold with an advisory one. It can transfer the task to another workflow only while no other lease on the task is active.

• No sentinel rule at the stage applies and no worker moves it. Then the task stays where it is until a person moves it.

Making a task wait for a person

Cadence has no single setting that guarantees a task stays put until a person acts. A task waits for you only while nothing that can move it is at work on it. Check each of these:

• No sentinel rule at the stage would move it. Either the workflow has auto-advance turned off, or no sentinel rule at the stage applies to the task.
• No worker is put on it. No assignment rule at the stage routes it to a pool, no scheduled rule has it as its subject, no inbound dispatch-worker rule names it, and no stage that one of its children can enter has an assignment rule with target: parent, and nobody assigns it to a pool with its Assignee field or tasks_assign. A worker whose lease reaches the task can make that assignment, so this also depends on what the workers that reach it do (see below). Dispatch, tasks_dispatch_pool and tasks_nudge start a pool only through an assignment rule at the task's stage, and with no such rule they start nothing. A dependency or an unpassed required check on the task does not stop a scheduled rule, a parent rule or an assignment to a pool: their workers run anyway. A blocking hold on the task does not stop any of the three creating a lease, but the worker is refused when it tries to start. Over MCP, lease_claim refuses with task is on hold; over the HTTP API the refusal is 409 task_on_hold. See Scheduled rules § A scheduled rule at a held or blocked task for what that refused lease looks like and what to do about it.
• No other worker reaches it. A lease on a related task can reach this one through its pool's lease scopes, which by default cover the parent, children and siblings. See Leases § What a lease can reach.
• The workers that do reach it do not move it. What a worker does is set by its worker version and the agent skills that version pins. A lease can always call tasks_transition, tasks_transfer, tasks_set_hold, tasks_assign, tasks_dispatch_pool and tasks_nudge on a task its scope reaches. The last two refuse a worker while the task has a blocking hold, and tasks_transfer is refused while another lease on the task is active. No setting turns those tools off for a worker, so whether it uses them depends on its instructions.

A blocking hold adds to these but does not replace them. While it stands, no pool starts new work on the task and no new lease is claimed for it, and the three ways to clear it refuse a worker. To find out whether something moved a task or changed its hold without you, read its timeline, as described in Holds on a task's page.

See What moves a task without a person and Tasks § Move a task between stages.