CommandTalon Studio v1.0.2-beta

Workspace

The same cockpit, scoped to one workspace — its pipeline gates, connection health, deployments and validation runs.

What it is

Command → Workspace (/command/workspace) is the release view of mission control. Both dashboards follow the workspace in the switcher; where Overview answers "how well are we covered?", this one answers a different question: is this workspace ready to ship?

It reads that workspace's release-pipeline state, SIEM connection health, recent commits, validation runs and deployment outcomes — the operational detail Overview deliberately leaves out.

How it works

The dashboard composes a few read-only panels, each backed by a workspace-scoped API call:

Release Readiness

A pipeline timeline — Connect → Forge → Validate → Review → Package → Deploy. Each gate resolves to done, ready, waiting, blocked or warn, and a Deploy ready badge appears when the package and target gates allow a deploy.

Connection health

Each SIEM connection's status, last sync time and any error detail (part of the Deployment Environment panel).

Deployment targets

The target SIEM lanes for this workspace, which one is the default, and the latest release on each.

Last commit

Author, message, short hash and time of the most recent commit on the workspace repo.

Deployment Runs & Validation

The most recent app-install / SIEM-push outcomes and validation results, newest first — click any row for a detail sheet.

The panels hydrate from GET /api/dashboard/summary?workspaceId=… (project, gates and connections), GET /api/dashboard/recent-runs?workspaceId=… (validation runs) and GET /api/workspaces/<id>/recent-activity (git commits). There is no dashboard table — it's all aggregated live from your workspace, deployment and validation records.

Command → Workspace · Release Readiness

The Release Readiness timeline. Each pill is a gate — green is done, accent is ready, amber is warn, red is blocked. Click a deployment or validation row on the right to open its detail sheet.

What a partial gate reads like

Forge shows literally "{n} detections · {m} in release" when the packaged count trails the workspace's total drafts; Package shows "{n} rules packaged" once a release exists. Deploy's most common blocked state reads "Deploy target has no token — auto-deploy disabled". And Review gates on governance alone: uncommitted working-tree edits are a save-your-work concern, not a release gate — a release packages only main's committed state, so uncommitted edits never ship.

Usage

Pick the workspace you're shipping in the workspace switcher — the whole dashboard follows that selection (it's stored per-browser).

Walk the Release Readiness gates left to right; the first non-green gate is what's holding a deploy.

Open a failed validation or deployment run to see events tested vs matched, or the install/push error, in the side sheet.

Tip

Behavioural validation is a signal, not a hard gate — a failing simulation or a drifted detection won't stop you deploying. What the release gate refuses on is a missing current Package, a Target that has not passed its package-install preflight in the last 30 minutes, and a detection whose latest environment-readiness check failed (it cannot run in the SIEM). The timeline still draws Validate amber in that last case, so read the gate's message rather than the colour. Review is warn-only: an open change request lives on its own branch and never holds back what's already merged to main. An organisation can escalate behavioural failures to blockers with validation_gate_policy: block — see Validation Settings.

Community Edition

The Community Edition has one workspace and one deployment target, and deploys from main only. Change requests still work on branches; deploying a branch other than main to its own target is refused with "Deploying a branch other than main is an Enterprise feature, and Enterprise is in development."