Skip to main content

Jentrix user guide

Everything you can do in the Jentrix UI. For agents and integrations, see the MCP tool reference and agent setup guides.

Surfaces that only a full deployment carries — the Control Tower rail, Contacts, Dashboards, Releases, Harnesses, and CSV/Trello import — are documented separately in Platform UI.

Contents


Core concepts

  • Workspace — the top-level container: members, boards, contacts, tokens, webhooks. Each workspace has a URL slug (/acme/...) and a task prefix (ACME).
  • Board — a kanban surface inside a workspace. Every board has a kind that shapes its columns and task fields (see below).
  • Column — a stage on a board. Drag to reorder; archive when unused.
  • Task — the unit of work. Every task gets a permanent human-readable key like STK-123 (workspace prefix + per-workspace sequence number) that never changes, even when the task moves between columns.
  • Completing = archiving. Jentrix has no separate "done" flag — when work is finished (or abandoned), archive the task from the detail panel header. Archived tasks disappear from boards, search, and dashboards but keep their history.

The workspace shell is the same on every product page:

  • Workspace switcher (top-left) — switch between your workspaces or create one.
  • Desktop rail: the destination list depends on what your deployment carries. A product deployment shows Work (Home, My Work, Work, Projects, Setup, Sessions, Search, Inbox) and Settings (Members, API tokens); a full deployment adds the operate/configure/evidence/administration groups documented in Platform UI. Either way the rail can collapse to icons and always marks the active route.
  • Mobile navigation: the primary destinations stay one tap away in the bottom bar, and More opens the complete grouped list, so no capability your deployment has disappears on a phone.
  • Top bar: sync state, Docs, the notification bell (with unread count), the ⌘K command palette, and your user menu stay available while you move around the workspace. Search accepts task titles, descriptions, comments, and exact task keys such as STK-123.

Operational lists: collapse, search, filter, sort

Every operational list page — Projects, Sessions, Artifacts, and on a full deployment the plane lists too — shares one set of list controls, mirroring the board's filter bar:

  • Collapse/expand: every list section has a chevron in its header (with a live count). Collapsing a section is remembered per browser, so a page stays arranged the way you left it. Long lists additionally fold after the first few rows behind a Show N more toggle, the same stacked-deck affordance board columns use.
  • Search: a text box filters the list as you type (titles, keys, names — whatever identifies the row).
  • Filters: enumerable facets per surface (e.g. type, visibility, and redaction on artifacts; status on projects). Multiple values within one facet OR together; facets AND together.
  • Sort: each surface offers the orders that make sense for it (recently updated, title, status, progress, …). Default order restores the server's own ranking.

Search, filters, and sort live in the URL (like board filters), so a filtered list can be bookmarked or shared; collapse state is a local preference and stays out of shared links.

Rows also show provenance. Every artifact row carries its creation time plus chips linking back to where it came from — the session that produced it, the task (by key), and the project — and a Linked to filter narrows the list by those origins; searching matches the origins too (e.g. a task key).

Workspaces and members

  • Your first workspace is created automatically on sign-up; create more from the workspace switcher (top-left).
  • Members (/[workspace]/members): invite people by email — they receive a link (/invite/...) that adds them on acceptance.
  • Roles: OWNER, ADMIN, MEMBER. Members can do day-to-day work (tasks, comments, boards, views). Admin-level actions — converting a board's kind, managing webhooks and automations, running imports — require ADMIN or OWNER.
  • Settings → General (/[workspace]/settings): workspace name, agent-token governance (admins see and can revoke any member's token pinned to the workspace), and a link to your personal API tokens. On a full deployment the other settings destinations (Connections, Communication, Policies, Credentials, Sources, Import & export) each have their own rail entry — General doesn't duplicate them.
  • Deleting a workspace: owners can permanently delete a workspace from the "Danger zone" at the bottom of settings. To guard against mistakes — including two workspaces that share a name — you must type the workspace's unique URL slug to confirm. Deletion removes everything in the workspace (boards, tasks, contacts, comments, attachments, members, webhooks, automations) and cannot be undone; you're sent to another of your workspaces afterward, or to create a new one if it was your last.

Boards and board kinds

Every board has a kind, chosen at creation. The kind decides which columns are seeded and which extra fields tasks carry:

KindSeeded columnsExtra task fields (sidecar)
TASKS (default)Backlog · In progress · In review · Done
CRMLead · Qualified · Proposal · Negotiation · Won · LostDeal: amount + currency, expected close date, linked contacts
SUPPORTNew · Open · Waiting on customer · Resolved · ClosedTicket: severity, SLA due, first response, resolved, source, one linked contact
BUGSTriage · Open · In progress · Fixed · Verified · ClosedBug report: severity, repro steps, expected/actual behavior, affected version, environment, resolved
ROADMAPDiscovery · In design · In build · Shipped · Won't doInitiative: target quarter, confidence, effort, RICE score

The seeded columns are a starting point — rename, add, reorder, or archive them freely.

What differs by deployment is the tooling around a kind, not the kind itself. Every deployment can create and convert boards of all five kinds, and the sidecar fields above render in the detail panel. A product deployment carries no kind-specific MCP tools — no deal, ticket, bug-report, or initiative tools for an agent to call, and no MCP tool for converting a board's kind (the UI menu action still works) — and none of the kind dashboards. BUGS is the exception worth knowing: it is where jentrix push findings --mint-issue files, so an Issues board earns its keep on any deployment.

Archived boards stay visible on the normal Boards page in an Archived boards section below the active grid. The section is collapsed by default and remembers its expanded/collapsed state in the browser. Every workspace member can inspect an archived board's name, kind, column count, and archive date; archived rows are not links. ADMIN and OWNER members can select one or many archived boards (up to 50 per operation) and restore them atomically with Unarchive selected. Restored boards return to the active grid immediately.

Converting a board between kinds (board menu → admin-only): every open task is backfilled with the new kind's sidecar in one transaction. Existing sidecars from the old kind are preserved (nothing is deleted), so converting back loses nothing.

Working with tasks

Creating tasks. Use the inline composer at the bottom of any column. On non-TASKS boards the composer offers kind-specific quick fields so you capture the essentials in one step — deal amount + contact on CRM, severity + contact on Support, severity + affected version on Bugs, target quarter on Roadmap.

The detail panel. Click a card to open it. The task identity and primary properties remain visible while the rest is grouped into four sections:

  • Overview: title, status, priority, assignees, due date, labels, the kind sidecar (Deal / Ticket / Bug report / Initiative), description, and subtasks.
  • Agent work: project links and linked agent sessions, plus — on a full deployment — leases, governed preparation, specifications, and simulations.
  • Delivery: task links, plus GitHub, PR/CI delivery state, and harness runs where the deployment carries them.
  • Discussion: attachments, comments with @mentions, and the full activity trail.

Inactive sections show useful item counts. Only the selected remote section is loaded, and the selected section is reflected in the URL. On phones the panel fills the viewport instead of squeezing desktop content into a narrow sheet. Archive remains in the header; this is how tasks are completed.

Deep links and history. /[workspace]/board/[board]?task=<id> opens the board with that task's panel expanded. Search results, notifications, and the roadmap graph all link this way. Opening and closing a card updates the query without reloading the board, browser Back closes the panel, and Forward reopens it. Existing filter and saved-view query parameters are preserved.

The board view

  • Drag and drop cards between columns and within a column; column order itself is also draggable. Position is preserved per board and syncs to everyone in real time.
  • Realtime: other users' (and agents') changes appear live — no refresh needed.
  • Filters (top bar): by label, assignee, priority, and due window (Overdue / Today / This week). On narrower screens these controls collapse into one Filters button with an active-filter count and Clear all action. Filters live in the URL, so a filtered board can be bookmarked or shared.
  • Sort: Priority, Due date, or Newest — or leave unset for manual ordering. While a sort is active the visible order is computed, so same-column dragging is disabled; dropping a card into another column appends it at the end.
  • Saved views: save the current filter + sort combination under a name; views appear as chips in the top bar for one-click recall. Any member can create views; views can be shared with the board; deleting needs the creator or a board admin.
  • Multi-select and bulk edit: shift-click cards to select several (plain click opens the panel and clears the selection). A floating action bar then applies move to column, set priority, add label, assign, or archive to the whole selection at once.

Tasks can be linked across any boards in a workspace — a bug can block a roadmap initiative, a support ticket can relate to a deal:

Link kindMeaning
BLOCKSThe source task blocks the target
DEPENDS_ONThe source task depends on the target
RELATES_TOLoose association, no direction semantics
DUPLICATESThe source duplicates the target
  • Cards show a red Blocked badge while any non-archived task blocks them.
  • BLOCKS / DEPENDS_ON cycles are rejected — the error names the exact cycle path by task key (e.g. STK-7 → STK-6 → STK-7).
  • Both linked tasks get an activity entry, so the relationship is auditable from either side.

Board-kind guides

CRM

Deals move through the pipeline columns; the Deal sidecar holds amount (with currency), expected close date, and any number of linked contacts from the workspace People directory. The CRM dashboard aggregates pipeline value by stage and owner and shows what's closing this quarter. Both are full-deployment surfaces.

Support

Tickets carry severity, an SLA due time, first-response and resolved timestamps, an intake source (email/chat/phone/other), and one linked contact. When a ticket's SLA due time passes unresolved, the system writes an SLA breached activity and notifies the assignees — exactly once per breach. Agents and automations can react to the same event (ticket.sla_breached).

Bugs

Bug reports carry severity, repro steps, expected vs. actual behavior, affected version, and environment. Resolving/reopening is tracked (resolution transitions appear in activity as Bug resolved / Bug reopened). With the semantic layer configured, the panel shows a "Possible duplicates" section — semantically similar open bugs with one-click "Link duplicate".

Roadmap

Initiatives carry a target quarter, confidence, effort, and a RICE score. A full deployment also renders the initiative dependency graph at /[workspace]/roadmap.

  • Cmd-K opens the command palette anywhere; /[workspace]/search is the full-page version.
  • Search covers task titles and descriptions, comment bodies (matches surface the parent task), and contacts — with proper word matching (stemming, multi-word queries) plus substring fallback for partial words and identifiers.
  • Archived items never appear in results.
  • Results deep-link straight to the task panel.

My Work

/[workspace]/my-work is your cross-board focus page: Overdue, Due today, and Assigned to me (each task appears in exactly one group). The workspace home page shows a compact digest of the same plus recent workspace activity.

Inbox and notifications

You're notified when you are assigned, @mentioned, or when a task you watch gets a comment — plus system notices when a task you're assigned to is due soon / overdue or a ticket breaches its SLA. Watching is automatic: you watch tasks you created, tasks you're assigned to, and tasks you've commented on.

  • The bell in the top bar shows your unread count; /[workspace]/inbox lists everything. Clicking through marks the notification read; "Mark all read" clears the lot.
  • Email: mentions and assignments can also email you immediately — a per-user toggle on the inbox page. A daily digest (08:00 UTC) emails opted-in users their unread notifications from the last 24 hours.
  • Due-date reminders are deliberately quiet: at most two per due date (entering the 24h window, and going overdue). Changing the due date re-arms them.

Activity and attribution

Every mutation writes an activity entry — visible per-task in the detail panel and per-workspace on the home page. Jentrix distinguishes who kind of actor did each thing:

  • Humans — actions from the UI.
  • Agents — actions through the MCP API. These are badged via 🤖 <agent name> using the token's display name and emoji (set when the token is created), in the activity feed, comment threads, and the home digest.
  • System / automations — cron-generated events (reminders, SLA breaches) and automation runs. Automation actions carry a via ⚡ automation chip so they're never mistaken for the human who created the rule.

The task activity feed has a filter for exactly these buckets: All / Humans / Agents / System.

Export

GET /api/export is served by every deployment. CSV and Trello import is a full-deployment surface — see Platform UI.

Export: GET /api/export?workspaceId=…[&boardId=…]&format=csv|json (signed-in session required). Archived items are excluded. The JSON format round-trips everything including sidecar fields; CSV is spreadsheet-friendly.