mirror of
https://github.com/github/spec-kit.git
synced 2026-08-03 06:26:30 +08:00
cf71d00dfe
A gate with `on_reject: retry` consumes a bound reject verdict before
pausing by resetting the named input to `""` (documented behaviour, so a
later resume prompts again). Every `resume()` re-resolves the persisted
inputs through `_coerce_input`.
Those two rules collide when the bound input declares an `enum` that does
not list `""`. The reset writes a value the input's own enum forbids, and
the run wedges:
inputs:
spec_verdict:
type: string
enum: [approve, reject]
steps:
- id: review
type: gate
options: [approve, reject]
on_reject: retry
verdict_input: spec_verdict
$ specify workflow run wf --input spec_verdict=reject
Status: paused
$ specify workflow resume <run_id> --input note=b
Error: Input 'spec_verdict' value '' not in allowed values:
['approve', 'reject'].
The workflow validates clean and the first run looks fine, so the failure
only appears at the second resume. It is also unrecoverable in practice:
`_resolve_inputs` re-coerces the whole persisted map, so *any* resume that
supplies an input dies on the stored `""`. Only a resume with no inputs at
all still works -- and that is precisely the call that cannot deliver a new
verdict, which is the one thing the retry cycle exists to allow.
Extend the existing `verdict_input` cross-check (which already confirms the
name is declared) to also require that a retry-bound input's `enum` admits
the reset sentinel, and report it with a fix hint. To do that, thread the
input *definitions* through `_validate_steps` instead of just their names.
Rejected the alternative of popping the key instead of writing `""`: that
lets the input's `default` flow back in on the next resume, so a gate the
user just rejected would silently auto-approve.
Docs: note the `enum` requirement next to the reset behaviour it follows
from.
Adds 4 validation tests for the new guard plus a characterization test that
drives the engine directly to pin the wedge it prevents.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Assisted-by: Claude Opus 5 (1M context)
Documentation
This folder contains the documentation source files for Spec Kit, built using DocFX.
Building Locally
To build the documentation locally:
-
Install DocFX:
dotnet tool install -g docfx -
Build the documentation:
cd docs docfx docfx.json --serve -
Open your browser to
http://localhost:8080to view the documentation.
Structure
docfx.json- DocFX configuration fileindex.md- Main documentation homepagetoc.yml- Table of contents configurationinstallation.md- Installation guidequickstart.md- Quick start guide_site/- Generated documentation output (ignored by git)
Deployment
Documentation is automatically built and deployed to GitHub Pages when changes are pushed to the main branch. The workflow is defined in .github/workflows/docs.yml.