Feature/unify lifecycle status

[melohagan]

Description

Unify the set live / stop terminology. Remove 'Switch on/off', Remove 'Draft'.

TODO: Published changes (x) - will do in separate PR

Addresses

• PRD: Unified Lifecycle & Status Model #18000

Screenshots

set.live.stop.mov

Launchcontrol

Unifies lifecycle language to “Set live”/“Stop” and clarifies status across apps, automations, and agents with Live, Stopped, and Not Deployed. Adds deployment tracking to distinguish published vs live, and fixes home status display and automation publish behavior.

[cubic-dev-ai]

2 issues found across 19 files

Confidence score: 3/5

• There is a concrete state-consistency risk in packages/builder/src/stores/builder/automations.ts: the publish path skips save, so if publishApp() fails, automation changes may persist without correctly flagging unpublished changes in workspaceDeploymentStore.
• packages/server/src/sdk/workspace/ai/agents/crud.ts has inconsistent publish logic between create and update, which can leave newly created agents with deployment-channel config in an unpublished state until a later update.
• Given one medium-high severity issue with high confidence and another medium issue, this carries some user-facing regression risk and is not fully low-risk yet.
• Pay close attention to packages/builder/src/stores/builder/automations.ts, packages/server/src/sdk/workspace/ai/agents/crud.ts - publish-state handling is inconsistent and may leave resources in unexpected deployment states.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/server/src/sdk/workspace/ai/agents/crud.ts">

<violation number="1" location="packages/server/src/sdk/workspace/ai/agents/crud.ts:249">
P2: `create` uses a narrower publish condition than `update`, so agents with deployment-channel config can be created as unpublished and only become published on a later update.</violation>
</file>

<file name="packages/builder/src/stores/builder/automations.ts">

<violation number="1" location="packages/builder/src/stores/builder/automations.ts:2204">
P2: The publish branch bypasses `save`, so a failed `publishApp()` can leave the automation updated without marking unpublished changes in `workspaceDeploymentStore`.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/server/src/sdk/workspace/ai/agents/crud.ts">

<violation number="1" location="packages/server/src/sdk/workspace/ai/agents/crud.ts:329">
P2: Removing the deployment-channel check from `hasBeenPublished` means provisioning a Slack/Discord/Teams channel no longer sets `publishedAt` unless the agent is live. That makes provisioned-but-stopped agents show as "Not Deployed" and drops deployment history. Reintroduce the integration-config check (or equivalent) when computing `hasBeenPublished`.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[adrinr]

What is the difference between publishedAt and deployedAt?

[melohagan]

deployedAt is the very first publish of a resource.

So if deployedAt is empty, then the status will be Not Deployed.
Otherwise if the resource is unpublished it will show the status Stopped.

[adrinr]

Having this in here and in the resources themselves will cause inconsistencies. Can't we use just once?

[melohagan]

It's just a duplicate of the resourcesPublishedAt field, but for tracking the initial publish

More: #18360 (comment)