Activity

1. mnriem

   added

   bug-assess

   on Sep 1, 2026
2. github-actions commented on Sep 1, 2026

   

   github-actionsBot

   on Sep 1, 2026 – with GitHub Actions

   Contributor

   More actions

   Bug assessment — scope-input-no-effect: Valid · severity low

   ---

   Bug Assessment: Bundled speckit workflow scope input has no effect

   • Slug: scope-input-no-effect
   • Created: 2026-09-01T12:10:03Z
   • Source: issue [Bug]: bundled speckit workflow exposes a scope input that has no effect #4384
   • Verdict: valid
   • Severity: low

   Report (summarized)

   Reported by @mforce. The bundled workflows/speckit/workflow.yml declares a scope input with an enum of ["full", "backend-only", "frontend-only"], but none of the four workflow steps (specify, plan, tasks, implement) reference {{ inputs.scope }} — they all use only {{ inputs.spec }}. The reporter confirmed this at commit 31e6b84f701b108a848847a8bc9ea86a1e2890b7 and found it while reviewing tooling in an external project. Their local fix removes the unused selector.

   Symptom

   Users are prompted to select a scope value (full, backend-only, frontend-only) when running the speckit workflow, but the choice has no effect — all three scope values result in identical execution. Expected behavior: either the scope input influences the steps, or it is removed.

   Reproduction

   1. Initialize a project with Spec Kit so the bundled workflow is installed (e.g. specify init my-project).
   2. Open .specify/workflows/speckit/workflow.yml.
   3. Observe the scope input declared at lines 38–41 with enum: ["full", "backend-only", "frontend-only"].
   4. Search for consumers: rg -n 'inputs\.scope' .specify/workflows/speckit/workflow.yml — returns no results.
   5. Optionally run the workflow with different scope values and observe identical behavior.

   Suspected Code Paths

   • workflows/speckit/workflow.yml:38-41 — scope input declaration; the enum is defined here but never consumed.
   • workflows/speckit/workflow.yml:44-78 — all four command steps use args: "{{ inputs.spec }}" with no scope forwarding.

   Root Cause Hypothesis

   The scope input was added to the workflow declaration (likely during a planning phase, referencing a future feature for conditional scope routing — see closed issue #2142) but the downstream argument wiring was never implemented. The step input.args fields were not updated to incorporate {{ inputs.scope }}. Confidence: high — the code is directly visible and unambiguous.

   Proposed Remediation

   Preferred: Remove the scope input declaration entirely from workflows/speckit/workflow.yml. The downstream commands (speckit.specify, speckit.plan, speckit.tasks, speckit.implement) have no documented contract for accepting or acting on a scope argument, so inventing scope-propagation semantics would be speculative. Removing the dead input is the safe, honest fix — it matches what the workflow actually does and eliminates user confusion.

   Alternatives:

   • Implement scope routing: Wire {{ inputs.scope }} into each step's args (e.g. args: "{{ inputs.spec }} --scope {{ inputs.scope }}") and update the underlying commands to honor the flag. This is the fuller feature but requires significant additional work and design — not appropriate as a bug fix alone.
   • Add a no-op with a comment: Leave the input but add a YAML comment noting it is reserved/unimplemented. This is worse than removal because it still misleads users at runtime.

   Files likely to change:

   • workflows/speckit/workflow.yml — remove lines 38–41 (the scope input block).

   Tests to add or update:

   • Add or update a workflow-schema/fixture test asserting the speckit workflow does not declare a scope input (prevents regression of re-adding a dead input).
   • If scope routing is later implemented, add a test asserting that each scope value produces a distinct command invocation.

   Risks & Considerations

   • Low blast radius: removing a dead input is a backward-compatible change for any user who does not pass -i scope=...; users who explicitly pass a scope value today will see it silently ignored either way, so removing the prompt actually improves clarity.
   • No data risk, no migration needed: the input is never persisted or consumed.
   • Workflow engine behavior: confirm that the workflow engine does not error on unknown inputs passed via -i; if it does, removal is even more important for users who scripted the flag.

   Open Questions

   • [NEEDS CLARIFICATION: Was scope routing planned as part of a future milestone, or was it an accidental leftover? Checking closed issue Workflow Engine with Catalog System #2142 may confirm intent, but the fix (removal) is valid regardless.]
   • [NEEDS CLARIFICATION: Does the workflow engine validate that all declared enum inputs are consumed, or only that supplied values are within the enum? If it validates consumption, this is already a latent engine error.]

   Generated by 🐛 Assess Bug from Labeled Issue for issue #4384 · 73.9 AIC · ⌖ 11 AIC · ⊞ 35.7K · ◷
3. github-actions

   added

   severity-low

   on Sep 1, 2026
4. Yash-Chindam commented on Sep 1, 2026

   

   Yash-Chindam

   on Sep 1, 2026

   Contributor

   More actions

   Confirmed on main — scope is declared and never referenced. Two corrections to the framing, though, because the actual behaviour is different from (and slightly worse than) what the report describes.

   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/ is in the gate step, unrelated to input collection. The prompt: key is currently documentation-only metadata — which is also why scope not having one went unnoticed. It is the only declared input without a prompt:, a fair sign it was never finished rather than deliberately hidden.

   What actually happens is a silent accept-and-discard. scope is enum-validated on the way in, then dropped. 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: [...]
   

   So a user passing -i scope=backend-only gets positive confirmation the value was understood — a bogus value would have errored — and then all four steps run with {{ inputs.spec }} exactly as before. Being validated and then ignored is more misleading than being ignored outright, since the rejection of bogus is evidence to the user that the flag works.

   That makes this a correctness issue about a silently-dropped input rather than a UI annoyance, though I agree severity stays low since the workflow still does the right thing by default.

   On the two options in Expected Behavior: removing the input looks clearly right to me as the immediate fix. Propagating scope has no contract to hang it on — the four steps take a single args string, so "backend-only" could only be smuggled in by appending prose to {{ inputs.spec }}, which puts a scoping instruction into the same free-text field the user's description occupies and leaves its interpretation to the agent. That is a feature with a design question attached, not a bug fix. Deleting three lines restores the invariant that every declared input affects the run, and a real scope selector can land later on its own terms.

   Worth considering separately: validate_workflow already rejects invalid enum shapes and out-of-enum defaults, but has no check for an input that no step references. A warning there would have caught this at authoring time and would catch the next one.

   Happy to open a PR removing the input if that is the direction you want.

   Disclosure: I used an AI assistant (Claude) to help investigate and draft this comment. The input-resolution behaviour and the coercion results above were verified against main.
5. mnriem commented on Sep 1, 2026

   

   mnriem

   on Sep 1, 2026

   Collaborator

   More actions

   @Yash-Chindam Feel free to create a PR with a fix
6. Yash-Chindam commented on Sep 1, 2026

   

   Yash-Chindam

   on Sep 1, 2026

   Last edited by Yash-Chindam

   Contributor

   More actions

   PR up: #4398

   Removes the input rather than wiring it up, for the reason in the PR: the four steps take a single args string, so a scope could only be smuggled in as prose appended to {{ inputs.spec }} and left to the agent to interpret. That is a feature with a design question attached, not a bug fix — better to restore the invariant now and leave a real scope selector free to land on its own terms.

   Also updates workflows/README.md, which demonstrated "Multiple Inputs" using --input scope="backend-only" against this very workflow — documenting the inert input as if it worked. The inputs.scope reference in the If/Then/Else section is a generic authoring example with its own hypothetical workflow, so it stays.

   Declared and referenced inputs now match exactly.

   Could you assign this issue to me so ownership is clear? Happy to revise on feedback.

   Disclosure: I used an AI assistant (Claude) to help investigate this, implement the change, and draft this comment. The verification described above was produced by running the code, and I reviewed the change before submitting.
7. Yash-Chindam

   added a commit that references this issue on Sep 1, 2026

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

   ...

   This issue will close once commit 89bf423 is merged into the 'main' branch.

   89bf423
8. mnriem

   assigned

   Yash-Chindam

   on Sep 2, 2026
9. mnriem

   closed this as completedin #4401on Sep 3, 2026
10. mnriem

    added a commit that references this issue on Sep 3, 2026

    docs(workflows): sync the reference copy with the shipped workflow (#…

    ...

    d11eb9c