Platform UI

The surfaces a full deployment adds on top of the product UI. Everything in the user guide — boards, tasks, links, search, My Work, inbox, activity, members, export — is present on every deployment; everything here needs the agent-operations planes, so it is absent from a deployment running STACKS_SURFACE=mvp (see MVP surface).

Split out for one reason: a guide that describes a Control Tower to an operator whose deployment has no Control Tower is worse than no guide. The user guide stays true everywhere; the plane-shaped half lives here.

Contents

• The full workspace rail
• The execution lifecycle view
• The Decision Register
• Contacts (People)
• Dashboards
• Releases and rollbacks
• Harnesses
• Import

The full workspace rail

• Desktop rail: destinations are grouped by operator intent — Operate (Control Tower, Work Items, Projects), Configure (AI Workers, Permissions), Evidence (Quality & Evals, Delivery, Artifacts), and Administration (Runner Nodes, Connections, Credentials, Members, Workspace Settings). The rail can collapse to icons and always marks the active route.
• Mobile navigation: Control Tower, Work Items, and Projects stay one tap away in the bottom bar. More opens the complete grouped destination list, so no workspace capability disappears on a phone.
• Runner Nodes is the operator label for the managed-execution workers surface (Administration → Runner Nodes, at /[workspace]/settings/workers). The rename is UI-only — the MCP tools (list_workers, set_worker_enabled, and the enrollment tools) are unchanged.
• Workspace settings sub-pages: Connections, Communication, Policies, Credentials, Sources, and Import & export are each their own rail destination. Settings → General doesn't duplicate them.
• Relocated destinations: Work Orders, Agent Jobs, Simulations, Playbooks, Incidents, Harness Runs, and the ambiguous generic "Releases" label are no longer standalone rail destinations. Their records stay reachable through Control Tower filters (a filter chip per entity type), their detail views, historical deep links, and compatibility redirects — with no access loss. Each preserved list stays a working compatibility page: for example /[workspace]/playbooks keeps its Convert to skill action and drafts-review link (it does not redirect to the read-only filter until Harness Templates lands in a later milestone), and its promoted playbooks also surface under the Control Tower playbooks filter, whose rows link back to that page. Every record deep link such as /[workspace]/work-orders/:id continues to resolve. "Releases" is disambiguated as Delivery under Evidence.

The operational lists here — Work Orders, Agent Jobs, Harnesses, Decisions, Incidents, Simulations, Playbooks, Releases, Agents, Sources, Policies, and the Control Tower queues — use the same collapse/search/filter/sort controls the user guide documents for product lists.

The execution lifecycle view

The Control Tower opens on the executions that are still running, across PRD → Plan → Code → Test → Deploy → Monitor → Improve — each showing its Work Item, step progress, the current step and the attempt behind it, health, elapsed time, runtime-reported cost, and blocker. Everything finished, cancelled, frozen, or archived folds into one collapsed section, so a workspace with years of history still opens on today's work. A stopped execution is never dressed up as live work: a cancelled run reads cancelled, offers no next action, and stays out of Needs attention. Stopping is not the same as being finished with it, though — a completed run still awaiting your acceptance decision stays in Needs attention and stays out of the fold. The human actions — launch the current step, freeze, resume, cancel, archive, record how a run ended — are on the row itself, offered only where the server would accept them. Selecting a row opens the full execution with its correlated destinations (Work Item, PRD, current step, active attempt, evidence, PR, CI, deployment, incident, improvement work), its agent jobs and attempt telemetry, and its history. Evidence is labelled by who owns it, so a provider-owned CI or deployment result never reads like an agent's claim about itself. Details in Agent platform → The execution lifecycle view.

Telegram. Connecting an account is a full-deployment surface — from Settings → Connections → Telegram notifications, connect your Telegram account for that workspace. Assignment, mention, watched-comment, due-date, and SLA notifications arrive with Open task, Reply, and Mark read actions. A Telegram reply becomes a normal task comment attributed to you; each workspace is enabled independently.

New Control Tower items that need a person — approvals, blocked/stuck work, missing evidence, release/rollback decisions, harness exceptions, and other human-action queues — arrive within the five-minute sweep with Open Control Tower and Mark read. An identical human-action message is sent only once per recipient, even if its live Control Tower source key changes. Agent handoffs and informational active-harness status are excluded. Alerts go to a connected project/agent owner when one is accountable, otherwise to connected workspace admins (falling back to connected members when no admin is linked). Approval and rejection stay inside Jentrix rather than Telegram.

The Decision Register

The Decision Register records structured decisions for the workspace and, optionally, a project.

Decision lifecycle

1. Propose — any member can propose a decision (title, owner, context, options, rationale, dissent). It starts proposed.
2. Accept / Reject — the decision's owner or a workspace admin accepts or rejects it. Accepting stamps decidedAt.
3. Revise — editing an accepted decision appends a revision that preserves an immutable snapshot of the prior accepted state for audit, then updates the decision. Every change is traceable through the numbered revision history; nothing is lost.
4. Supersede — replace an accepted decision with a new one via Supersede: a new accepted decision is created and the old one is marked superseded. The lineage is linked both ways, and the activity feed records who superseded it.

Create a decision from a comment

On any task comment, the lightbulb action proposes a decision pre-filled with the comment as context and evidence. Edit the options, rationale, and dissent afterward on the Decisions page.

Nominating a decision to memory

Accepted decisions can be nominated to memory for promotion into long-lived project memory. The nomination creates or converges on a governed MemoryItem; workspace admins review, promote, reject, quarantine, or re-accept it on the Memory page. Only promoted ACCEPTED_TO_MEMORY items influence future Context Packs.

Permissions. Proposing a decision is open to any member; accept, reject, revise, and supersede require the decision's owner or a workspace admin.

The register is exposed over MCP as list_decisions, get_decision, and create_decision — full deployments only.

Contacts (People)

/[workspace]/contacts is the shared directory used by both CRM deals and support tickets: name, email, phone, company, and an optional external ID for syncing with other systems. Contacts are workspace-level — one person, linked everywhere.

Merging duplicates: select a duplicate and a survivor and hit Merge — deal links and tickets move to the survivor, empty fields on the survivor are filled from the duplicate, and the duplicate is deleted. One transaction; nothing is lost.

Dashboards

/[workspace]/dashboards renders a current operating snapshot from open tasks. The page leads with breached SLAs, blocked initiatives, and reopened bugs that need attention, then shows dense per-kind summaries and accessible breakdowns. It states sample sizes and metric limitations and does not invent historical comparisons the data model cannot support:

The Delivery dashboard (/[workspace]/dashboards/delivery, linked from the Dashboards header) measures software delivery over a chosen window (30 / 90 / 180 days) from the PR/CI/deploy graph: the four DORA metrics — lead time for change, deployment frequency, change-failure rate, and time to restore (MTTR) — plus agent-native signals (PR review turnaround, CI fix loops per PR, human edits per agent PR, delivery approval burden). Each project's Metrics tab shows the same numbers scoped to that project. The figures also roll up nightly into stored outcomes (readable over MCP list_outcomes).

/[workspace]/roadmap renders the initiative dependency graph: all open initiatives plus anything that blocks them (including blockers from other boards), laid out left-to-right, blocked nodes outlined red. Clicking a node deep-links to the task.

Releases and rollbacks

Releases (/[workspace]/releases) are lightweight, shipped-bundle records — GitHub Releases still owns tags and changelogs. Cut a release with a version/tag, an optional name and project (board), release notes, and a rollback plan. On the release page you can edit the notes and rollback plan, add or remove the pull requests it includes (picked from the project's PRs), and move it through draft → ready → deployed (a release in ready surfaces in the Control Tower Release approvals queue).

Incidents from delivery. When a production deployment fails (enters an error state), Jentrix automatically opens an incident linking the failed deployment and — if it shipped one — its release, so the failure is tracked with a timeline, root cause, and follow-up tasks rather than lost in a dashboard. You can also open an incident yourself from a release you've flagged as regressing, via Open incident on the release page. An incident shows its linked release and deployment, and a release lists the incidents opened from it.

One-click rollback. A failed production deploy with no recorded rollback raises a top-severity Rollback needed item in the Control Tower. Resolving it with Roll back performs the rollback through the governed path — a policy check, a short-lived brokered cloud credential, and a lease — and records a reverting deployment that names the one it reverted. Rollback authorization is admin-only; agents never self-rollback.

Harnesses

Harnesses (/[workspace]/harnesses, under Deliver in the workspace rail) govern a build as a spec → plan → stage → commit loop. A harness run owns an ordered set of stages, and its progress is generated from that stage state. The stepper and the registry table you see are a live projection (the first-undone stage is "current"), never a hand-edited checklist.

Create one with the New harness button (admins): give it a name, an optional owner/name repository, planner/reviewer agents, and its gate/advance/retry policy. Creation itself only records the DRAFT run; Start authoring opens the real authoring loop. An approved spec can auto-start decomposition when autoAdvanceStages is enabled, decomposition mints the ordered stages and Work Orders, and the external runner drives each serial stage through review, evidence, commit, push/PR, and completion. Open a run to see Overview, Stages, Artifacts, Findings, Decisions, and Settings; delivery correlation and freeze/resume/cancel controls are live.

A task that a harness is anchored to shows a Harnesses section in its detail panel — the run's current stage, next action, and open-finding count, linking through to the harness page.

The full lifecycle, the runnable-harness contract, and the runner's own setup are documented in Harness automation.

Import

Import (/[workspace]/import, admin-only, in the rail under Settings → Import & export):

• CSV → contacts or tasks: upload, map columns, preview a dry run, then import. Contact imports are idempotent — rows match existing contacts by external ID, then by email, and update instead of duplicating. Task imports run in chunks (1,000+ rows verified) with an optional "skip rows whose title already exists on the board" switch.
• Trello board JSON: a full board export imports as lists → columns, cards → tasks.

Export is not plane-dependent and stays in the user guide.