chore(openspec): archive generator-payload-alignment

[thecodedrift]

Closes out the generator-payload-alignment change. The stack it tracked has fully landed; this is the tip step that was never taken, since the last slice merged without one.

Why now

The final open task was waiting on the generator sending ruleId on a reconcile entry. That landed in #242 — unsafe, unknown and missing entries all carry it, and ruleIdFromCheckPath is deleted. Verified on main rather than assumed.

N4 is confirmed both sides in the cross-team document: the engine tier stays defined and unused, because G2 means a Vale rule cannot be delivered without its .vale.ini, so the middle rung has no future occupant either.

The changeset was grown as the stack drained and already carries every slice, including #242's via lucky-pans-repeat.md. No second changeset is added here.

What is actually in the diff

The directory move is the smaller half. Archiving promotes the change's spec deltas into the standing specs, which is what makes the contract official rather than proposed:

Spec	Change
cli-generated-rule-delivery	created
cli-layout-export	created
cli-rule-reconciliation	updated
cli-rules	updated
cli-runtime-rule-execution	updated

Eight requirements added, two modified. openspec validate --specs --strict passes across all 26 specs.

Scope

No code. Every path is under openspec/.

Worth noting for anyone reading the check list: there is no OpenSpec archive gate any more, in either direction. A PR-time gate had to guess at stack position, and the main-only replacement turned main red for as long as a forward-merging stack took to drain — a red that means "work in progress" is not a signal. Archiving is a step performed on the tip, which is what this is.

Refs #240

[thecodedrift]

@claude /review

[claude]

Claude finished @thecodedrift's task in 3m 41s —— View job

---

Review: chore(openspec): archive generator-payload-alignment

Review mode: incremental — read 0 prior review thread(s) before reviewing. .prior-review.json contained no prior review threads, review summaries, or comments beyond the trigger comment itself, so this is the first review of this PR — assessing the whole diff.

• Read .prior-review.json (empty — no prior threads/reviews to classify)
• Gather PR diff (gh pr diff 246) and metadata (gh pr view)
• Review changed spec files, including reading full file contents beyond the diff hunks (per PR description, this is where the change's spec deltas become "official")
• Post findings

Summary

This is a pure OpenSpec archive (no code, openspec/ only): the change directory moves to openspec/changes/archive/2026-09-02-generator-payload-alignment/, its remaining tasks.md boxes are checked off, and its delta specs are promoted into the standing openspec/specs/ capabilities. The mechanical parts (rename, task-list closure, new/updated requirement text) are internally coherent and read well individually.

[New] One real issue, posted as two inline comments: the archived spec text is self-contradictory about where a runtime rule's check.ts lives on disk.

• The newly promoted cli-rule-reconciliation requirement "The reported file path is contractual" states the canonical path is .taskless/rules/runtime/<id>/check.ts, but the pre-existing, still-standing "Reconcile reports every runtime rule's check.ts" requirement a few dozen lines above it in the same file still says runtime rules are held under .taskless/runtime-rules/.
• Similarly, cli-runtime-rule-execution/spec.md's own "Blessed runtime rules execute from the materialized run directory" requirement (lines 155/162, untouched by this diff) still references .taskless/runtime-rules/, even though this PR updates the requirement just above it (line 11) to the new path.
• Notably, the archived tasks.md explicitly claims this class of fix is done — task 1.5: "Correct the same stale layout in cli-runtime-rule-execution's spec text (delta written; lands with this change)" — but the fix only reached the one requirement this PR's hunk touches, not the sibling requirement in the same file. The same stale reference also survives, untouched by this PR, in cli-check/spec.md (lines 261 and 305 — itself using a third, still different scheme: .taskless/runtime/rules/).

Since the PR's stated purpose is to make this "the contract official rather than proposed," these leftover mentions are worth reconciling — either as part of this PR or as an immediate fast follow-up — so the standing spec doesn't ship self-contradictory about the on-disk layout. Given this PR touches no code, this doesn't block anything at runtime; it's purely a documentation/contract consistency gap.

No other correctness issues found in the diff itself (renames are content-identical, the tasks.md checkbox/annotation edits accurately reflect the PR body's claims, and the newly added requirements read as internally consistent within the files this PR actually edits).

[thecodedrift]

Re: @claude[bot] — "Claude finished @thecodedrift's task in 3m 41s — Review: chore(openspec): archive generator-payload-alignment…"
#246 (comment)

Both inline findings were real and are fixed in a63d101, with wider scope than flagged: three layout schemes were live in the standing specs at once, and cli-check's dispatch requirement carried the 0004-era spelling for sg and vale too, not only runtime.

The framing in the review is the part worth keeping. This PR is the step that makes the requirements official, so promoting one that contradicts an adjacent standing requirement is the wrong moment to defer — a follow-up would ship a self-contradictory spec in the meantime.

cli-rule-format is left as-is on purpose: it documents migration 0004, which still performs that exact move. Called out explicitly rather than left silent, because a task claiming more than it delivered is what produced this in the first place — task 1.5 asserted the correction had landed when it had only reached the requirement its delta touched.

— AI Coding Agent