fix(skills): stop workflows from adopting a project that never ran init (#1787)

* fix(skills): stop workflows from adopting a project that never ran init

Generated skills and commands are installed once per machine and offered in
every repository the agent opens, including ones with no OpenSpec at all.
Nothing stopped the workflow there: root resolution falls back to an implicit
root at the current directory, so `openspec new change` quietly creates
`openspec/` in whatever repo the agent happened to be standing in (#1645).

Two changes, both in the generated instructions:

- Every workflow now carries a shared project check. Before the first step
  that writes, the agent reads `root.source` from `openspec status --json`;
  `implicit` (or a `No OpenSpec root found` error) means the project is not
  set up, and the agent stops and asks the user whether to run `openspec
  init`, target a store, or drop OpenSpec for that request. It may not
  initialize the project on its own or let a command create the root as a
  side effect.
- Every deployed skill description now names OpenSpec. Hosts pick skills by
  description, and "Enter explore mode - a thinking partner..." reads as a
  generic offer in a repository that has never heard of OpenSpec.

Closes #1645

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* chore(changeset): note the uninitialized-project guard

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(skills): let onboarding run init once the user asks for it

The guard read as an absolute ban on `openspec init`, which contradicts the
option it offers one sentence earlier and the onboard workflow's job.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs(troubleshooting): explain an OpenSpec workflow starting in an unset-up project

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(skills): check the root with a command that never fabricates one

`openspec status --json` demands --change once a project has changes, so the
guard's own check could fail in exactly the projects it should wave through.
`openspec list --json` answers in one shape everywhere: a root object when the
project is set up, `root: null` both when nothing is set up and when only
stores are registered.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* test(skills): pin the guard against every write, not the first fence

CodeRabbit's point: checking only the first ```bash fence would miss a write
outside a fence. Assert instead that nothing preceding the guard runs a
command or writes, and that the guard sits directly under the store-selection
guidance - both fail when the guard is moved down a workflow.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* feat(new-change): say when the command had to create the root itself

The generated workflows now check for a root before writing, but the guard is
instructions - an agent that ignores it, or a human running the CLI directly,
still turned an unset-up directory into an OpenSpec project without a word.
Creating the root stays zero-config; it is no longer silent.

Human output only: --json is unchanged, and `root.source` already carried the
same fact for programmatic callers.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(skills): tell agents the root check's non-zero exit is the answer

`openspec list --json` exits 1 when there is no root. An agent that reads that
as a broken CLI is one step from hand-creating `openspec/` instead, which is
the failure the guard exists to prevent.

Also drops a vacuous assertion: the notice test now checks that the note names
the directory it created and that the change really landed there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* style(skills): read the guard back and untangle its two 'in that case' clauses

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(skills): carry the store flag into the root check; pin the notice path exactly

CodeRabbit, both valid:
- With a store selected the store IS the root, so the check has to run as
  `openspec list --json --store <id>`. The store-selection paragraph above
  already says to append the flag to every command it lists, but leaving it
  implicit here invited a check against the wrong directory.
- The notice assertion matched any `openspec/` suffix. It now pins the exact
  rendered path, and a new case runs the command from a subdirectory to show
  the note names the directory actually adopted (and that the repo above it
  is left alone).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs: move the no-root contract to the canonical docs-lab pages

alfred-openspec on #1787: docs-lab/README.md makes docs-lab/ canonical and the
old docs/ tree legacy, and the canonical pages were stale in the two places the
review named.

- docs-lab/reference/cli.md, 'openspec new': documents the implicit-root notice
  after the 'Next:' line, with the exact output the CLI prints, that it goes to
  stdout and never appears with --json, and that JSON carries the same fact as
  root.source: implicit. Verified against a real run in an empty directory with
  an isolated HOME.
- docs-lab/reference/skills.md: states the shared response and stop behavior
  once, above the index table, since it now holds for every skill: confirm the
  resolved root before the first write, stop when there is none, offer init, a
  store, or dropping OpenSpec, wait for the answer, never create openspec/ on
  its own.

Drops the legacy docs/troubleshooting.md addition.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(skills): make the no-root answer depend on how the workflow was reached

alfred-openspec's product call on #1787. One answer could not serve both
arrivals: #1645 asks the workflow to get out of the way ('it can go through the
normal general propose not the openspec'), while a user who typed the skill's
name is owed an answer about OpenSpec.

The guard now branches after the same `openspec list --json` check:

- Auto-selected: the model picked this workflow without the user naming
  OpenSpec, naming the skill, or running its command. Drop OpenSpec and answer
  the request normally, with no setup question and no mention of OpenSpec.
- Explicit OpenSpec request: stop before writing and ask whether to run
  `openspec init`, target a store, or continue without OpenSpec, then wait.

Neither branch may create the root as a side effect, stated once for both.

One text serves both surfaces rather than a command-only variant, because
apply-change and onboard render a single body into the skill and the command
alike; a command-only constant would mean threading a surface flag through
bodies that deliberately have none (#1515). The bullets scope themselves
instead, and a slash command is an explicit invocation, so only the ask branch
can apply there. A test pins that branch reaching every generated opsx command.

Four regressions: the auto-selected branch (asserting it does not mention
`openspec init` or `--store`), the explicit branch, the explicit branch's
presence in every command file, and the shared no-side-effect rule.

docs-lab/reference/skills.md said every no-root invocation asks. It now carries
the same two branches as scan anchors.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(skills): keep the root guard off store-only projects and fix its docs

A store-only project whose `store:` line names a store this machine has
not registered reports `"root": null` from `openspec list --json`, so the
guard read a real OpenSpec project as uninitialized. The guard now checks
for the `Declared in` status message first and shows the store error
instead. A stale global defaultStore reports the same codes in unrelated
repositories, which is why the message prefix, not the code, decides.

Propose's context step from #1657 offered `openspec init` on
`no_openspec_root` regardless of how the workflow was reached. It now
defers to the project check, so an auto-selected propose skill stays
silent.

The changeset names both no-root branches, and the `new change --json`
docs separate the initialized example from the verified `implicit` one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(skills): keep the root guard off projects with a malformed store line

A config-only project whose `store:` line is malformed reports
`"root": null` with an `Invalid store declaration in` message, not
`Declared in`, so the project check read it as never initialized and
would drop OpenSpec or offer `openspec init` there. The guard now names
both prefixes, and a root-selection test pins that every declaration
failure starts with one of them while a stale global defaultStore
starts with neither.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* test(skills): check guard ordering in the skill body, not its frontmatter

A skill's YAML frontmatter is metadata a host reads to choose the skill,
not instructions the agent runs, so a description that quotes a command
name must not trip the ordering check. Scope the scan to the text after
the closing frontmatter delimiter; a command injected into the body ahead
of the guard still fails.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>