Execution safety

ScrumPulse uses several independent controls. A single switch should never be treated as the whole safety boundary.

Dashboard controls#

• New organizations default to dry_run.
• Free-plan workspaces cannot enable live mode through the API.
• Suspended organizations cannot execute approved actions.
• Runs can require confirmation when their action count reaches the workspace threshold.
• The workspace action cap limits planned activity.
• Approval state determines which actions are eligible for execution.
• API permissions separately control who may change organization settings, trigger runs, approve actions, or execute them.

Engine controls#

The standalone engine adds its own gates:

1. TAIGA_WRITE_ENABLED=true enables Taiga writes globally.
2. Action-specific switches enable transitions, closes, or deletes.
3. Per-action modes choose propose or auto.
4. The command must use --no-dry-run for live execution.
5. Multi-project writes require an allowlist or an explicit allow-all switch.
6. Delete operations require additional staged controls.
7. Per-run caps and notification cooldowns limit blast radius and alert noise.

Safe rollout sequence#

1. Connect one non-production or low-risk project.
2. Run a connectivity smoke test.
3. Complete dry runs for a limited cycle set.
4. Review action targets and payloads with the board owner.
5. Set a low action cap and a low confirmation threshold.
6. Enable only the specific write categories you intend to use.
7. Run one supervised live cycle.
8. Verify the provider board and the ScrumPulse action log.
9. Expand scope only after the evidence matches expectations.

High-risk operations#

Deletion is irreversible. Cycle H uses age, tag, staging-comment, grace-period, cooldown, and cap requirements, but operators must still preview the exact target set and verify the final provider state.

Never weaken auth, remove confirmations, or expose credentials to make a run succeed. Fix configuration or connectivity at the failing boundary.