The authoring-guidance rulebook is ambiguously named and misframed

[williamthorsen]

Problem

authoring-guidance reads two ways: as guidance about authoring, which is what the rulebook contains, and as the authoring of guidance, which it does not cover. The ambiguity becomes live alongside #1090, a planned rulebook on writing guidance.

The framing is also inaccurate. The rulebook presents its rules as conventions, but most are a machine-checked contract that throws on violation. rulebook-schema.ts validates the slug and skill-name patterns and throws; dependency-frontmatter.ts throws on an unknown artifact-type key, a non-list value, or a members: block on anything but a collection; invocation-token rendering fails the build when a harness has not declared its sigil or a token names an artifact that does not exist. Nothing in the document tells a reader which rules fail the build and which are house style.

Context

The guidance-doctrine work this ticket originally carried moves to #1090. #1089 depends on the rename landing.

Proposed solution

Rename to codeassembly-content-specification, shipping as consult-codeassembly-content-specification. "Specification" because the material is an enforced contract rather than a set of habits; the codeassembly- prefix because frontmatter keys and token syntax are specific to this repository, which lets the absence of a prefix mark content that applies anywhere.

State which rules are enforced and which are convention.

Acceptance criteria

Must have

• The rulebook's name distinguishes it from a rulebook about writing guidance.
• A reader can tell, for each rule, whether violating it fails the build.
• An unrecognized rulebook delivery mode fails sync rather than delivering the rulebook nowhere.
• No reference to the former name survives outside changelog history.
• The naming convention the prefix establishes is recorded in the rulebook itself.
• New and modified behavior in this change is covered by tests.