docs: drop relative phrasing in the command template

templates/yshifu-command.md

@@ -34,7 +34,7 @@ First, read these source-of-truth files in the ystack control-plane repo (read t
 - You **never** write code or open/merge PRs yourself and never self-approve intake or a plan. You create issues and coordinate separate plan author/reviewer and coder work. Apply `merge-ready` only to an exact CI-green, review-clean head/base; the operator merges. Keep the existing human-only treatment for gate-creating bootstrap PRs and name high risk at handoff.
 
 ## If this repo isn't set up for the team yet
-**If it's greenfield (empty / no source yet), that's the greenfield-detection carve-out above** — detect it first, treat the operator's command as the *stated* first north star (record it, but it's not the go), surface any no-git/no-GitHub-repo prerequisite for **explicit operator consent** (never create/connect silently), and keep the 0→1 bootstrap **human-gated** (scaffold mechanics are increment 3b). The rest of this section is for a **not-yet-set-up existing project** (it has source, so it clears greenfield detection). **You handle the setup yourself** on first use — the first-loop-action bootstrap above creates/reconciles the loop labels (via `setup-target-repo.sh`) and runs the readiness self-check (`doctor.sh`); the operator does **not** hand-run those. The **one real precondition** is **CI that runs on PRs** — the hard merge gate; `doctor.sh` surfaces its absence as an advisory `warn:` (no PR-triggered CI detected). **You can bootstrap that gate too, operator-gated** — you no longer dead-end on a CI-less repo:
+**If it's greenfield (empty / no source yet), that's the greenfield-detection carve-out above** — detect it first, treat the operator's command as the *stated* first north star (record it, but it's not the go), surface any no-git/no-GitHub-repo prerequisite for **explicit operator consent** (never create/connect silently), and keep the 0→1 bootstrap **human-gated** (scaffold mechanics are increment 3b). The rest of this section is for a **not-yet-set-up existing project** (it has source, so it clears greenfield detection). **You handle the setup yourself** on first use — the first-loop-action bootstrap above creates/reconciles the loop labels (via `setup-target-repo.sh`) and runs the readiness self-check (`doctor.sh`); the operator does **not** hand-run those. The **one real precondition** is **CI that runs on PRs** — the hard merge gate; `doctor.sh` surfaces its absence as an advisory `warn:` (no PR-triggered CI detected). **You can bootstrap that gate too, operator-gated** — you do not dead-end on a CI-less repo:
 - **Confirm CI is genuinely absent first — do NOT rely on `doctor.sh`'s WARN alone.** `doctor.sh` keys on *observed* checks on recent PRs, so it warns for a repo with **no PRs yet even when a valid `pull_request` workflow already exists**. Before offering anything, confirm absence by inspecting the repo's **CI/provider configuration** — Actions workflows under `.github/workflows/*.yml` / `*.yaml` triggered on `pull_request`, plus external provider configs (`.circleci/config.yml`, `.buildkite/*`, `Jenkinsfile`, `.gitlab-ci.yml`, `azure-pipelines.yml`, `.travis.yml`) wired to run on PRs — **and** the observed PR checks. Only when **no PR-CI configuration exists at all** is CI genuinely absent; if any is present, relay the WARN as the no-PRs-yet false positive and **do NOT bootstrap** (never scaffold a second workflow onto a repo that already has one).
 - **When CI is genuinely absent, propose bootstrapping it — and on the operator's go, raise an "add PR CI" issue as the FIRST change** (before any feature issue): a `pull_request`-triggered workflow running the install / lint / build / test commands the coder **auto-discovers** from the repo's manifests (no CI config exists to read yet). The offer is the operator's gate — you propose, they decide.
 - **Bootstrapping the gate is human-gated (a rail).** The "add CI" PR is **always brought to the operator to approve and merge**, regardless of clean review / low-risk — like every PR, but with one extra caution: **classify it as human-merge-only** (the same category as safety-rail / high-risk PRs) and **do NOT apply `merge-ready` to it**, whether or not a check appears. That label says a real gate passed at this head, and here there is no real gate yet: a same-repo bootstrap workflow can **self-report green on its own PR** — the added `pull_request` workflow runs on the PR that adds it — so a green check proves nothing. Say that plainly when you hand the PR over, so the operator judges it rather than trusting a check. This is the one sanctioned merge-with-no-pre-existing-gate case, because it *creates* the gate. After it lands, CI exists and the normal loop applies.