Settle the harness vocabulary: rename `rovodev` to `rovo` and qualify the frontmatter key

[williamthorsen]

Problem

Atlassian is renaming Rovo Dev to Rovo. CodeAssembly spells the harness rovodev throughout its own vocabulary: the harness id, the --harness accepted value with its help and error text, the frontmatter overlay filename, harnesses: values in skill frontmatter, hook-catalog keys, and prose across the content docs.

The id is also conflated with the harness's home-directory name, so CodeAssembly's vocabulary cannot move ahead of Atlassian's filesystem layout even though the two rename on different schedules.

A second vocabulary defect sits in the same lines. harnesses: in skill frontmatter narrows an artifact to specific harnesses. #1111 introduces a harnesses: block in codeassembly.yaml that selects which harnesses a sync run targets. Same word, different files, different meaning, and both fail silently when confused: a harnesses: written into a declaration file expecting artifact narrowing is accepted as sync targeting, and one written into frontmatter expecting to set the target narrows deployment instead.

Context

• 28 occurrences of rovodev across 17 files in the shipped dist; source, tests, and authoring docs carry more.
• HARNESSES.rovodev.homeDir is .rovodev, an Atlassian-owned path. On the reference machine ~/.rovodev exists and ~/.rovo does not, so the CLI migration has not happened yet.
• Three shipped skills declare the frontmatter key: brainstorming and systematic-debugging are [rovodev], review-permissions is [claude]. An invocation token can name a skill that does not deploy to the reader's harness #1128 refers to the first two as [rovo] — the name they are already discussed by, against content that still spells rovodev.
• The sweep reaches outside packages/agents: packages/lifecycle names the harness in the EventEnvelope.harness doc comment, and packages/foreman keys its badge-color map on it. packages/agents/scripts/extract-plugin-skills.sh names it in a CodeAssembly-owned output path, which follows the id rather than homeDir.
• No third-party content root in the fleet declares the key or names the harness: @williamthorsen/nmr's agents/ tree carries neither token. The sweep is contained to this repository.
• Declare which harnesses sync targets #1111 depends on this landing first, so its new declaration key is born spelling rovo and reading unambiguously, needing no alias and no migration of consumer declaration files.

Proposed solution

Rename the harness id to rovo, and decouple it from homeDir:

rovo: {
  id: 'rovo',
  homeDir: '.rovodev',   // Atlassian's path; renames when the CLI migration lands
  ...
}

Renamed: harness id, --harness value with its help and error text, subagents/_data/rovodev.yaml → rovo.yaml, hook-catalog keys, content docs. Unchanged: homeDir, config.yml, prompts.yml. The unknown-harness error message derives its list from ALL_HARNESS_IDS and follows automatically.

No rovodev alias for --harness. The consumer fleet is first-party and no published declaration names the harness.

Rename the frontmatter key to supported-harnesses:.

In codeassembly.yaml, every key is a plural noun naming what the scope declares — rulebooks, skills, subagents, collections, packages, sources — and harnesses: belongs to that series. In frontmatter, keys are properties of the artifact — name, description, user-invocable, delivery — where a bare harnesses is the only key naming a thing rather than describing the artifact. Qualifying the frontmatter side both disambiguates and improves the name on its own merits; qualifying the declaration side would break the series and put the qualifier on the primary concept.

Sites: the property read in skill-deploy.ts plus its two /^harnesses\s*:/ regexes — one parses the key, one strips it from deployed output so it does not leak into the installed skill — the second, independent read in library-list.ts that feeds the delivery column, the field list and {skill:} token reference in codeassembly-content-specification.md, and the three SKILL.md frontmatter lines.

This rides here rather than in #1111 because these are the same three lines the value rename already edits.

Scope moved out

The CLI migration this ticket originally described — moving the harness base directory from ~/.rovodev to ~/.rovo, renaming project-level .rovodev/ directories, re-running install, and updating configs.macos — becomes its own ticket, filed when the migration is undertaken. Decoupling the id from homeDir is what lets that happen independently: afterward the migration is a one-line change to homeDir plus the directory moves.

Reporting the retired harnesses: key from validate moves to #1197, which lands after this.

Acceptance criteria

Must have

• The harness id, --harness value, help text, and error message spell rovo.
• The harness id is independent of homeDir, which still resolves .rovodev.
• The frontmatter overlay file is rovo.yaml.
• No rovodev token survives except where it names an Atlassian-owned path.
• Skill frontmatter declares supported-harnesses:, and the key is stripped from deployed output as before.
• codeassembly-content-specification.md names the renamed key wherever it described the old one.
• New/modified behavior in this change is covered by tests.
• Documentation, help text, and usage examples name rovo and the renamed key; no reference to the retired --harness rovodev value or the bare harnesses: frontmatter key survives.