Skip to main content
/ The workflow

The wall & bypass

With the pipeline installed, a require_run wall stands while no run is active. It is its own lever in droost.workflow.yml, default hard, and hard even when the key is absent: a repository that has said nothing has not opted out of anything.

Where it stands

  • The editor guard blocks any edit to modules/custom or themes/custom.
  • Droost's build tools refuse over MCP: droost_scaffold, droost_structure_create, the display and Views composers, droost_config_set. A config-only build is governed exactly like custom code.

A finished or failed run counts as not active. The record is history, not a licence.

Docs, non-build tools (content entry, SQL, module operations) and non-Drupal files never trip it.

The two ways forward

The block names both:

bash
/droost:workflow:start "<what you are building>"         # the normal path
drush droost:workflow:bypass "hotfix: rotate the API key"  # the operator's path
drush droost:workflow:bypass --off                          # clear it

A bypass is a recorded decision

A bypass needs a reason and is stamped with when it was granted. drush droost:workflow:status shows it while it stands. It is CLI-only: nothing on the MCP surface can grant one, so an agent that hits the wall can ask you, but cannot let itself through.

Levels

require_run Editor guard Build tools
hard (default) blocks refuse
soft nudges once allow
off silent allow

Set soft for a one-time nudge on a repository where governed runs are the norm but not the rule; set off to disable the wall. Either is a one-line, reviewable diff to the lever file, which is the point of the lever living in a file.

Enforcement inside a run

enforcement is a separate lever for what the hooks do while a run is active: hard blocks out-of-phase actions (editing project files during plan, ending the turn mid-phase), soft warns once per phase, off stands the hooks down. Outside an active run the phase hooks have no opinion, but require_run still stands.

Why the wall exists

The first live-agent eval round found a config-only build that legally skipped the pipeline: nothing routed a build into a run, because the doctrine scoped the pipeline to "custom code". The wall was widened to the tool surface, and the next round opened with the agent saying, unprompted, "this is a build, so per the project's pipeline I'll start a workflow run first". The wall rarely has to fire; the pushed surfaces do the routing. When it does fire, it was the last thing standing.

Verified against droost 2.0.0-alpha4 · workflow 0.6.9 · 2026-09-03