docs(openspec): propose the agent command and the Vale authoring path

[thecodedrift]

Stack (root → tip):

• feat(cli): share the platform-binary resolver, add the Vale binary spec #71
  • feat(cli): verify Vale rules from per-rule fixture directories #93
    • feat(cli): dispatch the three engines concurrently and merge their findings #94
      • feat(cli): add the engine-selection topic and archive add-vale-rule-engine #95
        • test(cli): check a project both engines have work in, and fix what it found #100
          • ➡️ docs(openspec): propose the agent command and the Vale authoring path #102 (you are here)

Proposal only — no implementation. Draft so the archive gate stays quiet until the work is stacked beneath it.

add-vale-rule-engine shipped a chooser without a destination. engine-selection teaches an agent to conclude a rule belongs to vale, and then there is nowhere to go — static.txt is ast-grep authoring, and its only mention of Vale tells the reader to confirm sg was right. runtime dead-ends the same way. That exclusion was a recorded non-goal at the time, defensible while nothing chose Vale; the chooser is what made it reachable.

What it proposes

From	To
taskless help <topic>	taskless agent <topic>
taskless help rule create	taskless agent create-rule (single token, no positional join)
static	create-sg-rule
existing	create-legacy-rule
—	create-vale-rule, create-runtime-rule
route + engine-selection	one route

Plus a section-less scaffolded .vale.ini, so a project lints nothing until someone scopes it deliberately.

The two decisions worth reviewing

D1 — route and engine-selection merge. One decision, made once from one reading of the evidence. Whether a rule is expressible locally and which engine can express it are answered from the same signals, so splitting them cost a second fetch and a handoff without adding information.

The consequence needed solving rather than hand-waving: the platform generator consumes engine-selection through TOPICS and has no route step, so merging can't just delete what it reads. Exporting route instead is wrong — it's built on taskless detect --json and local authoring, neither of which a Worker can do. So the criterion distributes to the destinations: each create-*-rule states the evidence that makes its engine right, and route applies those same tests. That keeps every exported topic one a service-side consumer can actually act on, and removes the drift class where a chooser and its destinations disagree.

D4 — the section-less scaffold ships paired with surfacing Vale's stderr. Measured: with no section to copy, the natural first edit is rules.<id> = YES at top level, which Vale reports as W101 ... is ignoring it — on stderr, exit 0, valid {} on stdout. runVale reads stderr only on a non-zero exit, so today that's discarded and the author gets a rule that verifies, runs, and reports nothing. Shipping the scaffold alone would reintroduce the exact silent-disable class this engine's design exists to prevent, one level up. They are one requirement in the spec, not two.

Also settled

• No create-remote-rule. "Remote" names who generates, not an engine, and the one place it bites — the user is logged out — is where create-runtime-rule already has to speak. One topic, one gate explained once.
• Every backwards-incompatible item here is a MINOR bump. Pre-1.0.
• Found while writing it: cli-knowledge-prompts currently requires a topic rename be MAJOR. The delta corrects that to pre-1.0 semantics, keeping the obligation that actually matters — naming the rename in the changeset, since TOPICS crosses a deploy boundary and the generator breaks on upgrade rather than at our build time.

Open questions in the design

• remote.txt / rule-create.txt still implement service generation but are no longer named by route. Keep, fold into create-sg-rule's escalation path, or merge? Worth deciding before the cross-reference sweep.
• Does create-runtime-rule explain the login gate itself, or defer to auth?

Scope

~306 occurrences of taskless help across 77 files — but concentrated: only one skill file, the rest are recipe cross-references and tests. Delivery shape is a single PR stacked on #100, because recipes cross-reference each other by literal command string, so a half-renamed surface points at commands that don't exist.

pnpm openspec validate --strict passes.

Refs #100