docs(openspec): partition rules by engine directory

[thecodedrift]

Draft — not ready for review. Spec only; no implementation yet. Opened to keep the work on the remote.

Makes the on-disk rule layout multi-engine before any second engine exists, and changes nothing a user can observe: check reports exactly what it did before, from a different path.

Rules partition into .taskless/<engine>/{config, rules/, rule-tests/} — sg/, vale/ (scaffolded empty and inert), runtime/. The containing directory determines the engine, so dispatch never parses a file, and each engine's committed native config becomes the source of truth. Ephemeral sgconfig.yml generation leaves the check path entirely; because that is what used to trigger migrations, check now calls ensureTasklessDirectory directly.

Migration 0004 does the moving, content-preserving throughout: rules/ → sg/, runtime-rules/ → runtime/rules/. sgconfig.yml's ruleDirs: [rules] is relative to the config, so it survives unedited. Runtime capture bytes are untouched, which matters because those bytes determine reconciliation hashes — editing during the move would invalidate every signature. runMigrations also starts throwing on a scaffold newer than the CLI understands, rather than returning silently, unless --allow-version-mismatches is passed.

Two decisions keep this from needing anyone else's cooperation. Ingest defaults to sg, permanently — the delivery API carries no engine discriminator (verified: no engine, analysisType, or ruleType field anywhere in the generated types), so an engine-less payload is ast-grep by definition; an unrecognized engine fails loudly rather than defaulting into a directory the wrong parser reads. And both layouts stay readable — legacy .taskless/rules/ dispatches as ast-grep alongside sg/rules/, de-duplicated — so an unmigrated checkout still runs and no producer has to cut over.

Why this is separate

Split out of #71, which had grown to 44 tasks across ten groups. Since an OpenSpec change must land complete in one PR, a change that large cannot land at all. This half is where the risk lives — the relayout and the migration — so isolating it means a difference in check output after merge has exactly one candidate explanation.

stack: openspec-archived will be red until the change is implemented and archived. That is expected: archiving now would delete the spec before anything is built against it.

Where this sits

Each change is independently landable: one OpenSpec change, one PR, archived on merge. The archive gate requires it — a tip PR must leave openspec/changes/ empty — so nothing here is stacked and none of these depend on a shared branch.

PR	Change	Prerequisites
#70	knowledge prompt export	none
#72	Vale binary packages	none
#73 (this PR)	partition rules by engine	none
#71	Vale engine + engine-selection topic	#73 (executes the vale/ directory it scaffolds) and #72 (needs a binary to resolve)

Only #71 has prerequisites. The other three can land in any order.

#70 and #71 are coupled by exactly one line: whichever lands second adds the engine-selection topic to TOPICS. Ordering between them doesn't matter.

Downstream, the generator's decision router (TSKL-279) needs a published release containing #70 and #71. It consumes a normal release — no prerelease, no path dependency — so it waits without blocking anything here.

Fixes OSS-24