fix(workflows): drop the bundled speckit workflow's inert scope input

[Yash-Chindam]

Fixes #4384

Problem

The bundled workflows/speckit/workflow.yml declared a required-choice scope input that no step referenced. All four steps pass {{ inputs.spec }}, so every choice behaved identically.

What actually happens

Two corrections to the report's framing, both checked against main:

Workflow inputs are never prompted for. The report says users "are prompted to choose among three values", but nothing in the engine reads an input's prompt: field to ask anything — _resolve_inputs only merges provided values with defaults, and the sole interactive input() call in workflows/ belongs to the gate step. The prompt: key is documentation-only metadata today, which is also why scope being the one input without one went unnoticed.

The value is validated, then discarded. Calling _coerce_input with the declared definition:

-i scope=full           -> ACCEPTED as 'full'
-i scope=backend-only   -> ACCEPTED as 'backend-only'
-i scope=frontend-only  -> ACCEPTED as 'frontend-only'
-i scope=bogus          -> REJECTED: Input 'scope' value 'bogus' not in allowed values: [...]

That is worse than being ignored outright: a bogus value errors, so the acceptance of backend-only reads to the user as confirmation the flag does something.

Why removal rather than propagation

The issue offered both. Propagating scope has no contract to hang it on — the four steps take a single args string, so a scope could only be smuggled in by appending prose to {{ inputs.spec }}, putting a scoping instruction into the same free-text field the user's own description occupies and leaving its interpretation to the agent. That is a feature with a design question attached, not a bug fix.

Removing the selector restores the invariant that every declared input affects the run, and leaves a real scope feature free to land later on its own terms.

Also updated

workflows/README.md demonstrated "Multiple Inputs" using this exact input against the bundled workflow:

specify workflow run speckit \
  --input spec="..." \
  --input scope="backend-only"

That documented the inert input as if it worked, so the example now uses a declared one (integration). The inputs.scope reference further down in the If/Then/Else section is a generic authoring illustration with its own hypothetical workflow, not the bundled one, so it stays.

Verification

declared  : ['integration', 'spec']
referenced: ['integration', 'spec']
referenced-but-undeclared: none
declared-but-unused      : none

pytest tests/test_workflows.py — 941 passed. The 20 failures are all WinError 1314: A required privilege is not held by the client from symlink creation; I confirmed the identical set fails on unmodified upstream/main, so they are environmental and unrelated.

Follow-up worth considering separately

validate_workflow already rejects malformed enum shapes and out-of-enum defaults, but has no check for a declared input that no step references. A warning there would have caught this at authoring time. Left out of this PR to keep it to the fix.

---

Disclosure: this change was developed with AI assistance (Claude). The AI helped trace the input-resolution path, establish the accept-and-discard behaviour, and draft this description. The coercion results and the declared/referenced comparison above were produced by running the code; I reviewed the change before submitting.

[Copilot]

🟡 Changes recommended

The reference guide still reproduces and advertises the removed scope input.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Removes the bundled workflow’s unused scope input and updates its usage example.

Changes:

• Removes the inert scope selector.
• Uses the functional integration input in documentation.

File summaries

File	Description
workflows/speckit/workflow.yml	Removes the unused input declaration.
workflows/README.md	Corrects the multiple-input example.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Yash-Chindam]

Fixed — scope is now removed from the reference copy in docs/reference/workflows.md too. That file reproduces the shipped workflow verbatim, so leaving it would have made the documented definition disagree with the workflow this PR changes. Good catch; my original sweep for consumers missed it.

I checked the other scope references and left them deliberately, since none claims to reproduce the bundled workflow:

• workflows/README.md:407 — the input type-coercion section, where scope is the illustrative enum example alongside task_count (number) and dry_run (boolean)
• workflows/PUBLISHING.md:72 — a skeleton for authoring your own workflow (speckit_version: ">=0.6.1", any: ["claude", "gemini"])
• workflows/ARCHITECTURE.md:146 — the schema table row documenting what enum does

Pre-existing drift in the same reference copy

While confirming that block, I noticed the copy has drifted from the shipped workflow in three other ways, all predating this PR:

	docs/reference/workflows.md	workflows/speckit/workflow.yml
speckit_version	">=0.7.2"	">=0.8.5"
integrations.any	["copilot", "claude", "gemini"]	also alquimia, opencode
integration default	"copilot"	"auto"

The last one is the most user-visible — the docs state the default integration is copilot when it is actually auto, resolved from the project's initialized integration.

I have left these out to keep the PR to the reported bug. Happy to sync them here if you would prefer the reference copy fully accurate in one go, or to file it separately — your call.

Also rebased onto current main.

Disclosure: AI assistance (Claude) was used for this change and comment, as with the original PR.