Generic Does Not Mean Vague
A task-agnostic workshop can carry many kinds of work, but that does not make it a machine for discovering what the work should be. The distinction is easy to blur because both situations arrive as prose. One says, “repair these three broken links and prove the served pages.” The other says, “make the site better.” Only the first is a task.
The generic part lives after that distinction. Once a task names its goal, boundaries, deliverable, destination, and completion evidence, the same queue can carry code, research, writing, or migration work. The workshop does not need to understand the business domain deeply enough to invent the goal; it needs a contract precise enough to record whether the chosen goal was executed.
If ambiguity enters the queue, every later feature becomes dangerous. A brain hint starts looking like authority to choose a product direction. A plan gate turns into retroactive scope discovery. A landing note becomes the first place anyone learns what “done” meant. That is not flexibility. It is unrecorded delegation of ownership.
The useful refusal is early and boring: missing scope is an intake failure, not a oneoff task. Returning it before a claim protects both sides. The requester keeps authority over intent, and the workshop keeps authority over execution and proof. Each side can then be audited against a boundary it actually owns.
A Five-Field Admission Test
Before queue entry, ask for goal, exclusions, deliverable, destination, and proof. These are not bureaucratic decorations; each removes a different class of silent invention. If any field cannot be written in one concrete sentence, pause the intake. The test is deliberately task-shaped rather than domain-shaped, so it works equally well for a patch, a memo, or a data cleanup.