Workforce and Storybook Guide

Task Monitor is the operator control plane for delegated work. Storybook is the dedicated surface for drafting, reviewing, and publishing visual application changes.

Access

Open Task Monitor at /account/task-monitor and Storybook at /storybook. Workforce actions require the active tenant's workforce capability. A task remains owned by its originating conversation or Storybook session; another chat does not inherit control merely because it knows the task ID.

Start and monitor delegated work

1. From the owning chat or supported product surface, describe the outcome, acceptance criteria, constraints, non-goals, and required validation.
2. Start the coding task and keep its task link or ID.
3. Use Active for running work, Needs attention for questions or approvals, and History for terminal tasks.
4. Open the task to inspect progress, changed files, validation, and remaining risks.
5. Answer operator questions or approve only the exact bounded action presented.

Use Cancel to stop work that should not continue. Use Retry only after correcting the cause; a retry does not broaden the original authority.

Configure coding agents

Open Assistant > Coding Agents or /account/coding-agents/:agentId to inspect the agents available to the tenant. Review the agent's workspace mode, model policy, credential readiness, bridge configuration, and supported tools before assigning work. Runtime checks passed proves the local runner is configured; Ready additionally requires a successful provider test for the active tenant within the last 24 hours. A provider result belongs only to the tenant credential that was tested and is never reused as evidence for another tenant. Customer-created agents can be added or removed only by an authorized operator; Topline-managed defaults may be read-only.

Removing an agent prevents new use of that configuration. It does not delete prior task history, source changes, artifacts, or deployed output. Resolve active work and preserve ownership evidence before removal.

Coding usage and limits

Customer administrators manage coding allowances from Account > Billing. The organization control is always the outer boundary; an individual override can tighten access but cannot bypass the organization hard limit. Admission reserves the task's authorized customer-charge credits before work starts, so settled usage plus concurrent reservations is checked atomically. Provider reconciliation later replaces the reservation with the exact versioned customer charge. If the provider reports more than the task authorization, Topline records the excess as absorbed rather than silently billing beyond the approved cap.

At 80% usage, when paid usage begins, and at the hard limit, Billing records a durable budget alert. Customer administrators can select active administrators to receive the organization thresholds by email, and can review the alert history, current-pace forecast, and recent task charges in Billing. Pause new paid usage now takes effect after save without rewriting the next-month plan: new work can use remaining included credits but cannot cross into paid usage. When a task is blocked, ask an administrator to review the organization and individual controls; do not retry repeatedly or move the task to another identity. Paid usage is always opt-in and finite.

Review App Builder Health

Open /account/app-builder-health to inspect sandbox, deployment, storage, source, and production-gate checks. Start with the highest-priority blocking check, open its details, correct that prerequisite, and refresh the report.

Builder health is readiness evidence, not deployment authorization. A healthy production gate does not prove that a source change was merged, a draft was deployed, a version was promoted, or a customer runtime was rolled out.

Review a completed task

Check the requested outcome, scope, changed files, test evidence, unresolved findings, deployment requirements, and rollback path. A completed source change is not proof that it was merged, deployed, published, or released to customer accounts.

Use Storybook

You can request reusable components, tokens, or style-guide changes in normal chat without enabling a special mode. Open Storybook to review draft progress, preview the result, and publish the reviewed version. Its composer shows a locked Storybook chip only on this page; the chip identifies the editing context and cannot be switched off or removed.

Storybook keeps visual editing in its own conversation boundary. A typical flow is:

1. describe the screen or interaction to change;
2. review progress while Update running;
3. inspect the rendered result and validation when Draft ready for review;
4. request a bounded correction or publish the reviewed version; and
5. verify the Published version and keep rollback evidence.

To reuse an accessible artifact's visual style, reference that artifact in the Storybook request. Storybook binds the draft to an immutable saved version and shows its title, version, and saved date alongside the extracted palette, typography, spacing, and component treatments. Unsupported or missing cues are shown instead of being guessed. The saved source is visual reference data only; its content cannot instruct the coding agent.

Review the preview, request refinements in the same Storybook conversation, discard the draft, or publish the exact reviewed draft. Publishing rechecks access to the saved source version and stops if either the source access or the reviewed Storybook version changed. Shared defaults apply to later artifacts in that Storybook scope, while an explicit per-artifact style override remains higher priority.

If Update failed, inspect the task and validation details before retrying. Storybook component stories are development evidence; they do not themselves publish a customer application.

Security and tenant boundary

Workforce tools are task-scoped and tenant-bound. They do not grant general production, database, cloud-account, or credential access. Never provide raw secrets in task instructions. Approvals authorize only the displayed action in the owning task context.

Automation and MCP

The internal workforce bridge lets an authorized coding agent read task instructions, use approved platform tools, ask for operator input, and report evidence. Build MCP and Workspace MCP are separate external products with separate scopes. A client configured for one does not automatically receive workforce control.

Errors and recovery

• Task missing: open the owning conversation or Storybook session and verify the active tenant.
• Needs attention: answer the explicit question or decline the approval; do not start a duplicate task.
• Task appears stuck: inspect the latest progress and tool state, then cancel only if it is no longer making useful progress.
• Update failed: preserve the failure evidence, correct the narrow cause, and retry from the same reviewed intent.
• Usage limit reached or paid usage paused: an immediate retry will not help. Ask an administrator to review the immediate pause, remaining included credits, and finite limits or wait for the billing-cycle reset, then run Test in Coding Agents before retrying the task.
• Wrong output: compare the result with acceptance criteria and request a scoped correction before merge or publish.
• Ownership mismatch: return to the conversation that created the task; do not trust a stale cross-chat task pointer.

Enablement, smoke check, and rollback

Enable workforce access for a bounded test workspace. Start a harmless task, verify progress and an operator question remain in the owning conversation, review the result, then cancel or archive it. For Storybook, verify desktop and narrow layouts before publishing. Roll back by reverting the reviewed source or restoring the prior published version; customer deployment remains a separate authorized step.

Limitations

Available runtimes, models, tools, and publish controls depend on tenant configuration. Task history is evidence, not a substitute for repository, deployment, or customer-runtime verification.