René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"bug: verify.schema-drift parses files_modified as an inline array only — block-sequence plans give it an empty file set","articleBody":"## Summary\n\n`verify.schema-drift` extracts its file list from plan frontmatter with a regex that only matches an **inline** array. Plans written with a YAML **block sequence** — which is what `gsd-planner` itself emits — never match, so the gate inspects zero files and returns `block: false` without checking anything.\n\nThe gate is declared `blocking: true` at `execute:wave:post`, so this is a silent pass on a gate that is meant to stop a wave.\n\n## The code\n\n`bin/lib/verify.cjs`, in `cmdVerifySchemaDrift` (~line 1959):\n\n```js\nconst fmMatch = content.match(/files_modified:\\s*\\[([^\\]]{0,8000})\\]/);\n```\n\nThe `\\[` requires an inline array:\n\n```yaml\nfiles_modified: [a.py, b.py]     # matches\n```\n\nBut a block sequence has no `[`:\n\n```yaml\nfiles_modified:                  # does NOT match\n  - backend/app/models/job.py\n  - backend/app/services/queue.py\n```\n\n`fmMatch` is `null`, nothing is pushed to `allFiles`, and `checkSchemaDrift([], executionLog)` early-returns at `schema-detect.cjs:86` on `detectSchemaFiles([]).detected === false` — **before** the loop that reads `executionLog`. So neither of the function's two inputs is consulted.\n\n## Reproduction\n\nOn a phase whose plans use block-sequence `files_modified`:\n\n```\n$ gsd-tools query check verify.schema-drift 01 --raw\n{\n  \"block\": false,\n  \"drift_detected\": false,\n  \"blocking\": false,\n  \"schema_files\": [],\n  \"orms\": [],\n  \"unpushed_orms\": [],\n  \"message\": \"\",\n  \"skipped\": false\n}\n```\n\nMatching the regex against every plan in the phase directly:\n\n```\nplans whose files_modified the regex MATCHED: 0\nplans whose files_modified it MISSED:        12\n```\n\nThe empty `schema_files` / `orms` are the only tell that the gate did no work — the verdict alone is indistinguishable from a real pass.\n\n## Why this is likely to be widespread\n\n`gsd-planner` emits block-sequence `files_modified`. Every plan in the affected project was produced by GSD's own planner, so any project on that default format has a permanently green blocking gate. `phase-plan-index` parses the same field correctly, so the two disagree about what a plan declares.\n\n## Suggested fix\n\nAccept both forms where `files_modified` is read, ideally via one shared parser rather than a second regex. A block-sequence branch:\n\n```js\nconst block = content.match(/^files_modified:[ \\t]*\\n((?:[ \\t]+-[ \\t]*.+\\n)+)/m);\n```\n\n## Separate note — not part of this bug\n\nAfter fixing the parse locally and feeding the gate 135 correctly-parsed entries, it still returns `schemaFiles: []`. `SCHEMA_PATTERNS` (`schema-detect.cjs:17-28`) covers five JS/TS ORMs — payload, prisma, drizzle, supabase, typeorm — and no Python ORM at all, so SQLAlchemy/Alembic projects get no coverage either way. That is a feature gap rather than a defect and is not what this issue asks you to fix; flagging it only so the parse fix is not mistaken for full coverage on a Python backend.\n\nFound on `@opengsd/gsd-core` 1.13.0.","author":{"url":"https://github.com/Vince-Cercury","@type":"Person","name":"Vince-Cercury"},"datePublished":"2026-09-09T07:14:45Z","url":"https://github.com/open-gsd/gsd-core/issues/4562"}