go-handrolled-yaml-parser-sequence-continuation-keys-dropped
Solved and verified against the real repository (totalwindupflightsystems/off-by-one, cloned to /tmp/off-by-one). The full write-up is at ~/SOLUTION.md.
Root cause (off-by-one on the indent threshold): parseYAMLSequence builds a synthetic block for an inline-mapping item (- name: q) and re-indents the first line to the sequence's baseIndent, while continuation lines keep their deeper indent. parseYAMLMapping consumes only lines where indent == baseIndent (yaml.go:223), so it reads name and stops at the deeper in:/schema: lines. Those lines were already consumed off the real line slice, so they vanish with no error — taking nested flow enums with them.
Fix (pkg/api/yaml.go): compute itemIndent as the shallowest indent of the collected continuation block (the item mapping's own indent; first continuation line in well-formed YAML), re-indent the first line to it, and call parseYAMLBlock(..., itemIndent).
Evidence
- Before: /api/v1/problems parameters = [{"name":"q"},...,{"name":"offset"}] (6 bare names).
- After: all six carry in/description/schema; status.schema.enum is a 4-element array.
- Enum count across the served doc went from 5 → 7, matching the 7 enum: lines in openapi.yaml.
- Added a parser-level golden test + a served-document acceptance test, and tightened the existing enum guard from >= 5 to == 7.
- Proved the tests catch the bug: reverting only yaml.go makes all three fail with the original symptom; restored, go test -count=1 ./pkg/api/ passes and go vet is clean.
# Evidence - Problem class: go-handrolled-yaml-parser-sequence-continuation-keys-dropped - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-18T08:40:02.890Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "A hand-rolled YAML subset parser (block mappings + block sequences, no yaml.v3 dependency) silently loses every continuation key of a sequence item that begins as an inline mapping. Observed on the served OpenAPI document of a Go service: `paths./api/v1/problems.get.parameters` came back as `[{\"name\": \"q\"}, {\"name\": \"env\"}, ...]` instead of the six parameters declared in the source, because each parameter is written as `- name: q` followed by deeper-indented `in:`, `required:`, `schema:`, `description:` lines. Consequence: a spec consumer (Muster auto-config, a generated client, a validator) sees parameters without in/schema/required, and any flow sequence nested inside those dropped blocks (e.g. `enum: [...]`) never reaches the document at all.", "environment": "linux", "language": "go", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "go-handrolled-yaml-parser-sequence-continuation-keys-dropped", "provider": "openrouter", "solved_at": "2026-09-18T08:40:02.890Z", "version": "1.26"}Solved and verified against the real repository (totalwindupflightsystems/off-by-one, cloned to /tmp/off-by-one). The full write-up is at ~/SOLUTION.md.
Root cause (off-by-one on the indent threshold): parseYAMLSequence builds a synthetic block for an inline-mapping item (- name: q) and re-indents the first line to the sequence's baseIndent, while continuation lines keep their deeper indent. parseYAMLMapping consumes only lines where indent == baseIndent (yaml.go:223), so it reads name and stops at the deeper in:/schema: lines. Those lines were already consumed off the real line slice, so they vanish with no error — taking nested flow enums with them.
Fix (pkg/api/yaml.go): compute itemIndent as the shallowest indent of the collected continuation block (the item mapping's own indent; first continuation line in well-formed YAML), re-indent the first line to it, and call parseYAMLBlock(..., itemIndent).
Evidence
- Before: /api/v1/problems parameters = [{"name":"q"},...,{"name":"offset"}] (6 bare names).
- After: all six carry in/description/schema; status.schema.enum is a 4-element array.
- Enum count across the served doc went from 5 → 7, matching the 7 enum: lines in openapi.yaml.
- Added a parser-level golden test + a served-document acceptance test, and tightened the existing enum guard from >= 5 to == 7.
- Proved the tests catch the bug: reverting only yaml.go makes all three fail with the original symptom; restored, go test -count=1 ./pkg/api/ passes and go vet is clean.
# Evidence - Problem class: go-handrolled-yaml-parser-sequence-continuation-keys-dropped - Model: openrouter/deepseek/deepseek-v4.1-flash - Solved: 2026-09-18T08:40:02.890Z - Verification: solution produced by pi in sandbox; see signatures.json
{"description": "A hand-rolled YAML subset parser (block mappings + block sequences, no yaml.v3 dependency) silently loses every continuation key of a sequence item that begins as an inline mapping. Observed on the served OpenAPI document of a Go service: `paths./api/v1/problems.get.parameters` came back as `[{\"name\": \"q\"}, {\"name\": \"env\"}, ...]` instead of the six parameters declared in the source, because each parameter is written as `- name: q` followed by deeper-indented `in:`, `required:`, `schema:`, `description:` lines. Consequence: a spec consumer (Muster auto-config, a generated client, a validator) sees parameters without in/schema/required, and any flow sequence nested inside those dropped blocks (e.g. `enum: [...]`) never reaches the document at all.", "environment": "linux", "language": "go", "model": "openrouter/deepseek/deepseek-v4.1-flash", "problem_class": "go-handrolled-yaml-parser-sequence-continuation-keys-dropped", "provider": "openrouter", "solved_at": "2026-09-18T08:40:02.890Z", "version": "1.26"}