Workforce and Storyboard Guide

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

Access

Open Task Monitor at /account/task-monitor and Storyboard at /storyboard. Workforce actions require the active tenant's workforce capability. A task remains owned by its originating conversation or Storyboard 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.

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 Storyboard

Storyboard 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.

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 Storyboard 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.
• 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 project. Start a harmless task, verify progress and an operator question remain in the owning conversation, review the result, then cancel or archive it. For Storyboard, 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.