Project Runtime Configuration
You can define how to run a project on the project workspace itself.- Project workspace runtime config describes how to run services for that project checkout
- This is the default runtime configuration that child execution workspaces may inherit
- Defining the config does not start anything by itself
Runtime configuration is declarative. It tells DarkDuck what commands to run and how, but execution is always explicitly triggered by a human operator.
Manual Runtime Control
Runtime services are manually controlled from the UI.- Project workspace runtime services are started and stopped from the project workspace UI
- Execution workspace runtime services are started and stopped from the execution workspace UI
- DarkDuck does not automatically start or stop these runtime services as part of issue execution
- DarkDuck also does not automatically restart workspace runtime services on server boot
Execution Workspace Isolation
Execution workspaces isolate code and runtime state from the project primary workspace.| Property | Description |
|---|---|
| Checkout path | Own directory, separate from project primary |
| Branch | Can be on a different branch than the project |
| Runtime instance | Runs its own services independently |
| Configuration | Inherits from project, can override |
Inheritance Model
An execution workspace inherits its runtime configuration from the linked project workspace by default. You can override with workspace-specific settings. The inherited configuration answers “how to run the service”, but the running process is always specific to that execution workspace.Issues and Execution Workspaces
Issues are attached to execution workspace behavior, not to automatic runtime management.- An issue may create a new execution workspace when you choose an isolated workspace mode
- An issue may reuse an existing execution workspace when you choose reuse
- Multiple issues may intentionally share one execution workspace so they can work against the same branch and running runtime services
- Assigning or running an issue does not automatically start or stop runtime services for that workspace
Execution Workspace Lifecycle
Execution workspaces are durable until a human closes them.Creation
A workspace is created when an issue requests isolation or when you manually create one from the UI.
Active use
Agents work within the workspace during heartbeats. Runtime services can be started and stopped from the UI.
Resolved Workspace Logic During Heartbeats
Heartbeats resolve a workspace for the run, but this is about code location and session continuity, not runtime-service control.- Heartbeat resolves a base workspace for the run
- DarkDuck realizes the effective execution workspace, including creating or reusing a worktree when needed
- DarkDuck persists execution-workspace metadata (paths, refs, provisioning settings)
- Heartbeat passes the resolved code workspace to the agent run
- Workspace runtime services remain manual UI-managed controls
Implementation Guarantees
| Guarantee | Detail |
|---|---|
| Project runtime config | Fallback for execution workspace UI controls |
| Execution workspace overrides | Stored on the execution workspace |
| Heartbeat runs | Do not auto-start workspace runtime services |
| Server startup | Does not auto-restart workspace runtime services |