## Status
- **OQ1/OQ2 RESOLVED (doyle, owl 2026-06-15).** Repo topology decided: monorepo file-form for dev;
  dedicated root-`manifest.toml` repo for `--github` (pointer mode, binaries on PATH). Wave 1 is now
  **fully unblocked** — authoring both activation branches.
- **Wave C is on A's critical path:** the operator's "dogfood the plugin" = end-user path = needs the
  dedicated `--github` repo to exist. Surfaced to operator (repo name + creation + OQ2 binary choice).

# JIT plan — `/sptc:setup` activation bridge (F-005) → grow toward LOCKED v1 setup {1–7}

> Next slice after the cplugs first-publish (b1e2895). Goal: make `/sptc:setup` actually
> **activate** the claude-spt adapter after the binary check (the F-005 post-install bridge), so a
> freshly-installed plugin yields a *registered & active* adapter — not a `deregistered` one. Then
> stage the richer LOCKED v1 setup paths (`SCOPE.md` §"/spt:setup" = {1..7}) as later waves.
> Public-surface-only still binds (AGENTS.md).

## Why (the dogfooding finding, 2026-06-15)

An agent ran `/sptc:setup` on a fresh install: `spt 0.7.2` present → skill reported "No install
needed" and **stopped**. But `spt adapter list` showed **`claude-spt: … deregistered`** — the
adapter surface (profiles/strings/hints/`[digest]`) was inert, `/sptc:*` UPS-injection had nothing
to source. **Binary present ≠ adapter active.** doyle triaged F-005 (docs/SPT-CORE-FINDINGS.md) and
confirmed the missing step: after the binary check, setup must run
**`spt adapter add [--github <repo>]`** to ACTIVATE. The current skill has no such step, and (Point
2, operator) no already-installed branch at all — it is a degenerate installer-floor stub far below
the LOCKED v1 `{1..7}` scope.

## Operator decisions (this session, 2026-06-15)

1. **Proceed with the setup slice (B).** Activation (A — un-break the local adapter) is fulfilled by
   the operator **dogfooding the plugin**, not a separate step here.
2. **End-user `--github` target = `SaberMage/spt-claude-code`** (operator: "this repo is published
   there"). ⚠ See Open Question 1 — the monorepo layout conflicts with `adapter add --github`'s
   root-`manifest.toml` expectation; topology must be resolved before the end-user branch is wired.

## Ground truth (verified against live `spt 0.7.2` this session)

- `spt adapter add --help`: PATH = **"a dir holding `manifest.toml`, or the manifest file itself"**;
  `--github user/repo` clones under `adapters/_github/`, **manifest-first**, then conducts the
  declared `[update]` avenue once. **No subpath flag.** "Install is the first update."
- Our manifest is **`adapter/claude-spt.toml`** (a subdir, *not* named `manifest.toml`); no
  `manifest.toml` exists anywhere in the repo. → the **local** activation form that works today is
  the *manifest-file-itself* form: `spt adapter add ./adapter/claude-spt.toml`.
- `claude-spt` reads **`deregistered`** in the registry (Phase-D int tests register→clean-up by
  design) — re-adding re-activates.
- Extractor/runner = `tools/claude-spt-digest` + `tools/claude-spt-psyche` (source). Command
  templates are **opaque, resolved from PATH at runtime** — so for the adapter to *function* (digest
  + Psyche), those binaries must be **built and on PATH**, independent of manifest registration.

## Open questions

1. **[RESOLVED — doyle, owl 2026-06-15, from source] End-user `--github` target topology.**
   `adapter add` is **ROOT-ONLY, code-confirmed** (`source_manifest_file`): a dir source resolves to
   `<dir>/manifest.toml` **exactly** (exact filename, no scan, no subpath); `--github user/repo`
   reads `<clone-root>/manifest.toml`. Our `adapter/claude-spt.toml` misses on both counts → a
   **doc-gap** (it's in spt-core source, not the published docs; doyle is patching the activation
   docs). **Ruling:**
   - **Local dev** keeps the monorepo `adapter/claude-spt.toml`; activate via the **file-form**
     `spt adapter add ./adapter/claude-spt.toml` (takes any path + any filename).
   - **End-user `--github`** needs a **DEDICATED published adapter repo** (Wave C) whose **root** is
     `manifest.toml` (named exactly) + `strings/` + the binaries the manifest references.
   - **Copy-vs-pointer by `[update]` avenue:** claude-spt's avenue is `delegated`
     (`claude plugin update spt`) → **POINTER mode**: spt-core copies **nothing** into
     `adapters/<name>/`; it reads `manifest.toml` + `strings/` **live from the durable
     `adapters/_github/<safe>` clone**, for life. (`file_pull`/no-`[update]` = COPY mode instead.)
     Root-only holds in both modes.
2. **[RESOLVED via Q3 ruling] End-user binary delivery for `claude-spt-digest` / `claude-spt-psyche`.**
   doyle: the manifest-referenced **binaries are NOT auto-copied** in either mode (only `strings/`
   is). So they must be **resolvable on the target**: absolute path, on PATH, or — in our pointer
   mode — **shipped in the `--github` repo at the manifest's referenced paths** so they resolve from
   the durable `_github` clone. **Action:** our command templates reference the binaries by **bare
   name** (`claude-spt-digest …`, `claude-spt-psyche …`) ⇒ resolved from **PATH**. So end-user
   delivery must put both on PATH (ride the installer) OR we switch the manifest to clone-relative
   paths + ship the binaries in the Wave-C repo. **Decide in Wave C** (lean: ship on PATH via the
   installer — keeps templates portable). Folded into Wave C.
3. **Setup context detection.** Skill probes for a local `adapter/claude-spt.toml` (operator
   dogfooding from a checkout → file-form) else uses `--github <Wave-C repo>` (casual end-user).

## Waves

### Wave 1 — the activation bridge (fulfills A on dogfood) — `REQ-SETUP-ACTIVATE`
**Scope:** make `/sptc:setup`'s binary-present path **activate + verify**, not no-op.
- Rewrite step 1 of both bodies (the self-contained `plugin/sptc/skills/setup/SKILL.md` floor **and**
  the file-backed `adapter/strings/skills/setup.md`): after `command -v spt && spt --version`, check
  whether `claude-spt` is **registered & active** (`spt adapter list` parse). If active → report +
  stop. If absent/`deregistered` → **activate**:
  - **local dev / operator dogfood:** `spt adapter add ./adapter/claude-spt.toml` (manifest-file
    form) when a repo-local manifest is detectable (OQ3).
  - **end-user:** `spt adapter add --github <target>` — **wired once OQ1 resolves** (target TBD).
- **Verify** activation: `spt adapter list` shows `claude-spt` active (not `deregistered`); spot a
  profile resolve (`spt adapter get-string claude-spt:live …` or `spt api … capability`).
- Keep the absent-binary install path (current step 2/3) intact — install **then** activate.
- Idempotent + safe to re-run (mirrors the bootstrap's contract).
- **Evidence:** doc = both bodies; impl = the activation+verify step; int = a registration
  re-activate assertion (`ci/manifest/registration-int.sh` extension, or a new `setup-activate-int`)
  — `deregistered → active`, profile resolves, registry left clean. Activate
  `REQ-SETUP-ACTIVATE = ["doc","impl","int"]`.
- **Note the binary-on-PATH caveat (OQ2)** in the body: activation registers the manifest;
  digest/Psyche need the tool binaries present (built + on PATH) to *function*.

### Wave C — the dedicated published adapter repo (the end-user `--github` target) — **on A's critical path**
**Why:** the operator's A-fulfilling dogfood is "install the **plugin**" (the end-user path) → setup
runs `adapter add --github <repo>` → so that repo must EXIST and be correctly shaped. The monorepo
`SaberMage/spt-claude-code` **cannot** be it (root-only rule). **Decision needed (operator):** repo
name + creation (SaberMage org credentials) + the binary-delivery choice (OQ2: on-PATH-via-installer
vs clone-relative-paths-in-repo).
- Lay out repo **root** = `manifest.toml` (the monorepo's `adapter/claude-spt.toml`, renamed) +
  `strings/` (copied) + (per OQ2 decision) the built `claude-spt-digest` + `claude-spt-psyche`.
- A `ci/publish/` step that **generates** this repo from the monorepo `adapter/` (rename + copy +
  drop binaries) so the two never drift — mirrors `package-skeleton.sh` for the cplugs side.
- Verify end-to-end: a clean machine `spt adapter add --github <repo>` → active + a profile resolves
  + digest/Psyche binaries resolve. New REQ (`REQ-DIST-ADAPTER-REPO`) when this wave starts.

### Later waves — LOCKED v1 setup paths {1..7} (each its own slice + REQ; deps flagged)
Staged, not built now (JIT). From `SCOPE.md` §"/spt:setup" LOCKED {1,2,3,4,5,6,7}:
- **#4 already-installed branch** (new subnet / join=add-this-machine / show-code / just-add-endpoint)
  — the natural extension of Wave 1's active-adapter path; pairs with `/sptc:subnet` (already ships).
- **#1 `cc`/`cc <id>` launcher** at project root — **dep:** full-fat M12 `spt endpoint run` picker
  ("lands in a later wave" per `endpoint run --help`; REQ-DIST-SHORTCUT-BASENAME int is held on it).
- **#2** offer `.gitignore` the launchers (rides #1).
- **#3 create first subnet** — QR of the TOTP seed + self-elevating window (elevation design LOCKED,
  `SCOPE.md`; unbuilt). **dep:** elevation machinery.
- **#5 legacy owl migration** — detect `claude_skill_owl`/owl → migrate identity+agents+psyche.
- **#6 OS-service registration** (always-on daemon) — **dep:** spt-core service support.
- **#7 ccs profile wiring** — if `~/.ccs` present; also offer to install ccs. Pairs with the shipped
  `claude-spt:ccs` profile (REQ-CCS-PROFILES).
- Deferred per SCOPE: **#8** off-subnet Psyche sync, **#9** doctor/verify-at-end (operator: "except 9").

## Gate (every wave)
`sh ci/run-gates.sh` PASS + `traceable-reqs check` green. Commit `Co-authored by: perri`.

## Status
- **Plan + `REQ-SETUP-ACTIVATE` seeded (this commit).** Wave-1 build **HELD on OQ1** (doyle topology
  ruling) for the end-user `--github` branch; the **local-dir activation path is buildable now** and
  is what the operator's dogfood exercises. Resume Wave 1 on doyle's reply.

-- **Plan + `REQ-SETUP-ACTIVATE` seeded (this commit).** Wave-1 build **HELD on OQ1** (doyle topology

-  ruling) for the end-user `--github` branch; the **local-dir activation path is buildable now** and

-  is what the operator's dogfood exercises. Resume Wave 1 on doyle's reply.

+- **OQ1/OQ2 RESOLVED (doyle, owl 2026-06-15).** Repo topology decided: monorepo file-form for dev;

+  dedicated root-`manifest.toml` repo for `--github` (pointer mode, binaries on PATH). Wave 1 is now

+  **fully unblocked** — authoring both activation branches.

+- **Wave C is on A's critical path:** the operator's "dogfood the plugin" = end-user path = needs the

+  dedicated `--github` repo to exist. Surfaced to operator (repo name + creation + OQ2 binary choice).


F-005 monorepo doc-gap note, then authoring the bodies.


Edit

**doyle's doc actions (docs-site):** publish the post-install ACTIVATION step (`adapter add
[--github]`) in `install-on-demand` + the integration checklist · author Ed25519 signing-key
provisioning · an explicit "zero-touch `file_pull` auto-distribution is roadmap (REQ-UPD-1)" note so
no author builds expecting it.

**doyle's doc actions (docs-site):** publish the post-install ACTIVATION step (`adapter add
[--github]`) in `install-on-demand` + the integration checklist · author Ed25519 signing-key
provisioning · an explicit "zero-touch `file_pull` auto-distribution is roadmap (REQ-UPD-1)" note so
no author builds expecting it.

**Follow-up doc-gap (doyle, 2026-06-15) — `adapter add` is ROOT-ONLY, code-confirmed.**
`source_manifest_file` resolves a dir source to `<dir>/manifest.toml` **exactly** (exact filename,
no scan, no subpath); `--github user/repo` reads `<clone-root>/manifest.toml`. Undocumented (in
source, not published) → doyle adding the distribution-repo topology to the activation docs (root
`manifest.toml` requirement, `--github` root-only, copy-vs-pointer by `[update]` avenue, where the
manifest-referenced **binaries** live — NOT auto-copied, only `strings/` is). **Our consequence:**
the end-user `--github` target must be a **dedicated repo** (root = `manifest.toml` + `strings/` +
binaries), distinct from the monorepo; local dev uses the file-form `adapter add
./adapter/claude-spt.toml`. Drives `SETUP-SLICE-PLAN.md` Wave C.


The file C:\Users\decid\Documents\projects\spt-claude-code\docs\SPT-CORE-FINDINGS.md has been updated successfully. (file state is current in your context — no need to Read it back)

**doyle's doc actions (docs-site):** publish the post-install ACTIVATION step (`adapter add
[--github]`) in `install-on-demand` + the integration checklist · author Ed25519 signing-key
provisioning · an explicit "zero-touch `file_pull` auto-distribution is roadmap (REQ-UPD-1)" note so
no author builds expecting it.

**Follow-up doc-gap (doyle, 2026-06-15) — `adapter add` is ROOT-ONLY, code-confirmed.**
`source_manifest_file` resolves a dir source to `<dir>/manifest.toml` **exactly** (exact filename,
no scan, no subpath); `--github user/repo` reads `<clone-root>/manifest.toml`. Undocumented (in
source, not published) → doyle adding the distribution-repo topology to the activation docs (root
`manifest.toml` requirement, `--github` root-only, copy-vs-pointer by `[update]` avenue, where the
manifest-referenced **binaries** live — NOT auto-copied, only `strings/` is). **Our consequence:**
the end-user `--github` target must be a **dedicated repo** (root = `manifest.toml` + `strings/` +
binaries), distinct from the monorepo; local dev uses the file-form `adapter add
./adapter/claude-spt.toml`. Drives `SETUP-SLICE-PLAN.md` Wave C.

+**Follow-up doc-gap (doyle, 2026-06-15) — `adapter add` is ROOT-ONLY, code-confirmed.**

+`source_manifest_file` resolves a dir source to `<dir>/manifest.toml` **exactly** (exact filename,

+no scan, no subpath); `--github user/repo` reads `<clone-root>/manifest.toml`. Undocumented (in

+source, not published) → doyle adding the distribution-repo topology to the activation docs (root

+`manifest.toml` requirement, `--github` root-only, copy-vs-pointer by `[update]` avenue, where the

+manifest-referenced **binaries** live — NOT auto-copied, only `strings/` is). **Our consequence:**

+the end-user `--github` target must be a **dedicated repo** (root = `manifest.toml` + `strings/` +

+binaries), distinct from the monorepo; local dev uses the file-form `adapter add

+./adapter/claude-spt.toml`. Drives `SETUP-SLICE-PLAN.md` Wave C.

**Our action items (ours, not doyle's):** (i) wire `spt adapter add --github <repo>` into

`/sptc:setup`'s binary-present branch (the activation bridge — folds into the setup-slice below);

(ii) the manifest needs its own **published github repo target** for the `--github` end-user path


Now authoring the activation step into both setup bodies. Using `SaberMage/claude-spt` as the recommended dedicated-repo name (operator confirms in Wave C).


Write

# /sptc:setup — operative instructions

> Delivered file-backed via the `claude-spt` adapter `[strings]`
> (`[strings.skills].setup = { file = "skills/setup.md" }`), resolved at injection time. The cplugs
> SKILL.md stays a thin skeleton (ADR-0001).

**Goal:** install or repair spt-core for this session **and ACTIVATE the claude-spt adapter** — the
mid-session installer that covers the gap when no SessionStart bootstrap has fired (a user who
installs the plugin mid-session). Installing the binary is only half the job: a present binary with
a **deregistered** adapter has no profiles/strings/hints/`[digest]`, so `/sptc:*` injection has
nothing to source. Setup must leave the adapter **active**.

<!-- [doc->REQ-SETUP-ACTIVATE] -->

**Do this:**

1. **Binary.** Check whether spt-core is present: `command -v spt && spt --version`.
   - If absent, run the published install-on-demand bootstrap (verbatim against the spt-releases
     contract, `harness-contract/install-on-demand.md`):
     - **POSIX:** `curl -fsSL https://sabermage.github.io/spt-releases/install.sh | sh`
     - **Windows (PowerShell):** `irm https://sabermage.github.io/spt-releases/install.ps1 | iex`
   - `PATH` is not reloaded in the current shell after a fresh install — verify with the absolute
     path for the first call: `"$HOME/.local/bin/spt" --version` (POSIX). Report the version.

2. **Adapter activation (the step a present binary still needs).** Run `spt adapter list` and look
   for `claude-spt`:
   - If `claude-spt` is listed and **not** marked `deregistered` → the adapter is **active**; report
     "adapter active" and go to step 4.
   - If `claude-spt` is **missing or `deregistered`** → **activate** it. Pick the source:
     - **Local dev / dogfooding from a repo checkout** (an `adapter/claude-spt.toml` is present near
       cwd): `spt adapter add ./adapter/claude-spt.toml` (the file-form takes any path + filename).
     - **End-user (plugin only, no repo checkout):**
       `spt adapter add --github SaberMage/claude-spt` — the dedicated adapter repo whose root holds
       `manifest.toml` + `strings/` + the tool binaries. `adapter add` is manifest-first (an invalid
       manifest registers nothing) and conducts the declared `[update]` avenue once.

3. **Verify activation.** Re-run `spt adapter list`: `claude-spt` must now appear **active** (no
   `deregistered`). Spot-check a profile resolves: `spt adapter get-string claude-spt:live adapter_label`
   (any shipped profile). Report the active state.

4. **Tools on PATH (feature prerequisite).** The `[digest]` extractor (`claude-spt-digest`) and the
   Psyche runner (`claude-spt-psyche`) are invoked by **bare name** → resolved from PATH at runtime.
   Activation registers the manifest, but session-digest + LiveAgent Psyche only **function** once
   those two binaries are on PATH (they ride the installer / the dedicated adapter repo). If either
   is missing from PATH, note it — registration succeeds but those features stay inert until they
   resolve.

After this initial bootstrap + activation, `spt update` handles signed self-updates automatically —
the user does not run setup again. The whole flow is idempotent and safe to re-run.


proceed with B, which will be used to fulfill A thru dogfooding the plugin (i'll do it). this repo is published at https://github.com/SaberMage/spt-claude-code


The file C:\Users\decid\Documents\projects\spt-claude-code\adapter\strings\skills\setup.md has been updated successfully. (file state is current in your context — no need to Read it back)

# /sptc:setup — operative instructions

> Delivered file-backed via the `claude-spt` adapter `[strings]`
> (`[strings.skills].setup = { file = "skills/setup.md" }`), resolved at injection time. The cplugs
> SKILL.md stays a thin skeleton (ADR-0001).

**Goal:** install or repair spt-core for this session **and ACTIVATE the claude-spt adapter** — the
mid-session installer that covers the gap when no SessionStart bootstrap has fired (a user who
installs the plugin mid-session). Installing the binary is only half the job: a present binary with
a **deregistered** adapter has no profiles/strings/hints/`[digest]`, so `/sptc:*` injection has
nothing to source. Setup must leave the adapter **active**.

<!-- [doc->REQ-SETUP-ACTIVATE] -->

**Do this:**

1. **Binary.** Check whether spt-core is present: `command -v spt && spt --version`.
   - If absent, run the published install-on-demand bootstrap (verbatim against the spt-releases
     contract, `harness-contract/install-on-demand.md`):
     - **POSIX:** `curl -fsSL https://sabermage.github.io/spt-releases/install.sh | sh`
     - **Windows (PowerShell):** `irm https://sabermage.github.io/spt-releases/install.ps1 | iex`
   - `PATH` is not reloaded in the current shell after a fresh install — verify with the absolute
     path for the first call: `"$HOME/.local/bin/spt" --version` (POSIX). Report the version.

2. **Adapter activation (the step a present binary still needs).** Run `spt adapter list` and look
   for `claude-spt`:
   - If `claude-spt` is listed and **not** marked `deregistered` → the adapter is **active**; report
     "adapter active" and go to step 4.
   - If `claude-spt` is **missing or `deregistered`** → **activate** it. Pick the source:
     - **Local dev / dogfooding from a repo checkout** (an `adapter/claude-spt.toml` is present near
       cwd): `spt adapter add ./adapter/claude-spt.toml` (the file-form takes any path + filename).
     - **End-user (plugin only, no repo checkout):**
       `spt adapter add --github SaberMage/claude-spt` — the dedicated adapter repo whose root holds
       `manifest.toml` + `strings/` + the tool binaries. `adapter add` is manifest-first (an invalid
       manifest registers nothing) and conducts the declared `[update]` avenue once.

3. **Verify activation.** Re-run `spt adapter list`: `claude-spt` must now appear **active** (no
   `deregistered`). Spot-check a profile resolves: `spt adapter get-string claude-spt:live adapter_label`
   (any shipped profile). Report the active state.

4. **Tools on PATH (feature prerequisite).** The `[digest]` extractor (`claude-spt-digest`) and the
   Psyche runner (`claude-spt-psyche`) are invoked by **bare name** → resolved from PATH at runtime.
   Activation registers the manifest, but session-digest + LiveAgent Psyche only **function** once
   those two binaries are on PATH (they ride the installer / the dedicated adapter repo). If either
   is missing from PATH, note it — registration succeeds but those features stay inert until they
   resolve.

After this initial bootstrap + activation, `spt update` handles signed self-updates automatically —
the user does not run setup again. The whole flow is idempotent and safe to re-run.

-**Goal:** install or repair spt-core for this session — the mid-session installer that covers the

-gap when no SessionStart bootstrap has fired (a user who installs the plugin mid-session).

+**Goal:** install or repair spt-core for this session **and ACTIVATE the claude-spt adapter** — the

+mid-session installer that covers the gap when no SessionStart bootstrap has fired (a user who

+installs the plugin mid-session). Installing the binary is only half the job: a present binary with

+a **deregistered** adapter has no profiles/strings/hints/`[digest]`, so `/sptc:*` injection has

+nothing to source. Setup must leave the adapter **active**.

-1. Check whether spt-core is already present: `command -v spt && spt --version`. If it reports a

-   version, spt-core is installed — nothing to do; report the version and stop.

-2. Otherwise run the published install-on-demand bootstrap (verbatim against the spt-releases

-   contract, `harness-contract/install-on-demand.md`):

-   - **POSIX:** `curl -fsSL https://sabermage.github.io/spt-releases/install.sh | sh`

-   - **Windows (PowerShell):** `irm https://sabermage.github.io/spt-releases/install.ps1 | iex`

-3. `PATH` is not reloaded in the current shell after a fresh install — verify with the absolute

-   path for the first call: `"$HOME/.local/bin/spt" --version` (POSIX). Report the version.

-4. After this initial bootstrap, `spt update` handles signed self-updates automatically — the user

+1. **Binary.** Check whether spt-core is present: `command -v spt && spt --version`.

+   - If absent, run the published install-on-demand bootstrap (verbatim against the spt-releases

+     contract, `harness-contract/install-on-demand.md`):

+     - **POSIX:** `curl -fsSL https://sabermage.github.io/spt-releases/install.sh | sh`

+     - **Windows (PowerShell):** `irm https://sabermage.github.io/spt-releases/install.ps1 | iex`

+   - `PATH` is not reloaded in the current shell after a fresh install — verify with the absolute

+     path for the first call: `"$HOME/.local/bin/spt" --version` (POSIX). Report the version.

-This is the same bootstrap the SessionStart hook runs; it is idempotent and safe to re-run.

+2. **Adapter activation (the step a present binary still needs).** Run `spt adapter list` and look

+   - If `claude-spt` is listed and **not** marked `deregistered` → the adapter is **active**; report

+     "adapter active" and go to step 4.

+   - If `claude-spt` is **missing or `deregistered`** → **activate** it. Pick the source:

+     - **Local dev / dogfooding from a repo checkout** (an `adapter/claude-spt.toml` is present near

+       cwd): `spt adapter add ./adapter/claude-spt.toml` (the file-form takes any path + filename).

+     - **End-user (plugin only, no repo checkout):**

+       `spt adapter add --github SaberMage/claude-spt` — the dedicated adapter repo whose root holds

+       `manifest.toml` + `strings/` + the tool binaries. `adapter add` is manifest-first (an invalid

+       manifest registers nothing) and conducts the declared `[update]` avenue once.

+3. **Verify activation.** Re-run `spt adapter list`: `claude-spt` must now appear **active** (no

+   `deregistered`). Spot-check a profile resolves: `spt adapter get-string claude-spt:live adapter_label`

+   (any shipped profile). Report the active state.

+4. **Tools on PATH (feature prerequisite).** The `[digest]` extractor (`claude-spt-digest`) and the

+   Psyche runner (`claude-spt-psyche`) are invoked by **bare name** → resolved from PATH at runtime.

+   Activation registers the manifest, but session-digest + LiveAgent Psyche only **function** once

+   those two binaries are on PATH (they ride the installer / the dedicated adapter repo). If either

+   is missing from PATH, note it — registration succeeds but those features stay inert until they

+After this initial bootstrap + activation, `spt update` handles signed self-updates automatically —

+the user does not run setup again. The whole flow is idempotent and safe to re-run.

# /sptc:setup — operative instructions

> Delivered file-backed via the `claude-spt` adapter `[strings]`
> (`[strings.skills].setup = { file = "skills/setup.md" }`), resolved at injection time. The cplugs
> SKILL.md stays a thin skeleton (ADR-0001).

**Goal:** install or repair spt-core for this session — the mid-session installer that covers the
gap when no SessionStart bootstrap has fired (a user who installs the plugin mid-session).

**Do this:**

1. Check whether spt-core is already present: `command -v spt && spt --version`. If it reports a
   version, spt-core is installed — nothing to do; report the version and stop.
2. Otherwise run the published install-on-demand bootstrap (verbatim against the spt-releases
   contract, `harness-contract/install-on-demand.md`):
   - **POSIX:** `curl -fsSL https://sabermage.github.io/spt-releases/install.sh | sh`
   - **Windows (PowerShell):** `irm https://sabermage.github.io/spt-releases/install.ps1 | iex`
3. `PATH` is not reloaded in the current shell after a fresh install — verify with the absolute
   path for the first call: `"$HOME/.local/bin/spt" --version` (POSIX). Report the version.
4. After this initial bootstrap, `spt update` handles signed self-updates automatically — the user
   does not run setup again.

This is the same bootstrap the SessionStart hook runs; it is idempotent and safe to re-run.


---
name: setup
description: |
  Install or repair spt-core AND activate the claude-spt adapter for this Claude Code session
  (mid-session installer + post-install activation).
allowed-tools: [Bash]
---

# /sptc:setup

> **Self-contained by necessity.** Unlike other `/sptc:*` skills, `setup` cannot rely on
> UPS-injection of its body: it runs precisely when spt-core may be **absent**, so
> `spt adapter get-string` (the injection source) is unavailable. The operative steps therefore live
> in this SKILL.md (the floor); the file-backed `[strings.skills].setup` body mirrors them for the
> spt-present repair path. See `docs/adr/0001-distribution-splits-by-volatility.md`.

Covers the mid-session install + activation gap (ADR-0001): a user who installs the plugin mid-session
has not had a SessionStart bootstrap fire, so `/sptc:setup` runs the same invisible-installer
bootstrap to fetch + verify spt-core on demand **and then activates the claude-spt adapter**. A
present binary is not enough: an unregistered/`deregistered` adapter has no profiles/strings/hints/
`[digest]`, so the `/sptc:*` surface is inert until activation.

**Do this:**

1. **Binary.** If spt-core is absent (`command -v spt && spt --version` reports nothing), run the
   published install-on-demand bootstrap (spt-releases `harness-contract/install-on-demand.md`):
   - **POSIX:** `curl -fsSL https://sabermage.github.io/spt-releases/install.sh | sh`
   - **Windows (PowerShell):** `irm https://sabermage.github.io/spt-releases/install.ps1 | iex`

   `PATH` is not reloaded in this shell after a fresh install — verify with the absolute path:
   `"$HOME/.local/bin/spt" --version`. After this, `spt update` handles signed self-updates.

2. **Activate the adapter.** Run `spt adapter list` and find `claude-spt`:
   - Listed and **not** `deregistered` → already active; report it and skip to step 3.
   - Missing or `deregistered` → activate it:
     - **Local dev / dogfooding a repo checkout** (an `adapter/claude-spt.toml` is present near cwd):
       `spt adapter add ./adapter/claude-spt.toml` (the file-form accepts any path + filename).
     - **End-user (plugin only):** `spt adapter add --github SaberMage/claude-spt` (the dedicated
       adapter repo: root `manifest.toml` + `strings/` + tool binaries). Manifest-first; conducts the
       declared `[update]` avenue once.

3. **Verify.** Re-run `spt adapter list` — `claude-spt` must read **active** (no `deregistered`).
   The `[digest]` extractor (`claude-spt-digest`) and Psyche runner (`claude-spt-psyche`) resolve by
   **bare name from PATH**; if either is missing, registration still succeeds but session-digest /
   LiveAgent Psyche stay inert until those binaries are on PATH. Note any that are missing.

Idempotent and safe to re-run — the same bootstrap + activation the SessionStart hook performs.


The file C:\Users\decid\Documents\projects\spt-claude-code\plugin\sptc\skills\setup\SKILL.md has been updated successfully. (file state is current in your context — no need to Read it back)

---
name: setup
description: |
  Install or repair spt-core AND activate the claude-spt adapter for this Claude Code session
  (mid-session installer + post-install activation).
allowed-tools: [Bash]
---

# /sptc:setup

> **Self-contained by necessity.** Unlike other `/sptc:*` skills, `setup` cannot rely on
> UPS-injection of its body: it runs precisely when spt-core may be **absent**, so
> `spt adapter get-string` (the injection source) is unavailable. The operative steps therefore live
> in this SKILL.md (the floor); the file-backed `[strings.skills].setup` body mirrors them for the
> spt-present repair path. See `docs/adr/0001-distribution-splits-by-volatility.md`.

Covers the mid-session install + activation gap (ADR-0001): a user who installs the plugin mid-session
has not had a SessionStart bootstrap fire, so `/sptc:setup` runs the same invisible-installer
bootstrap to fetch + verify spt-core on demand **and then activates the claude-spt adapter**. A
present binary is not enough: an unregistered/`deregistered` adapter has no profiles/strings/hints/
`[digest]`, so the `/sptc:*` surface is inert until activation.

**Do this:**

1. **Binary.** If spt-core is absent (`command -v spt && spt --version` reports nothing), run the
   published install-on-demand bootstrap (spt-releases `harness-contract/install-on-demand.md`):
   - **POSIX:** `curl -fsSL https://sabermage.github.io/spt-releases/install.sh | sh`
   - **Windows (PowerShell):** `irm https://sabermage.github.io/spt-releases/install.ps1 | iex`

   `PATH` is not reloaded in this shell after a fresh install — verify with the absolute path:
   `"$HOME/.local/bin/spt" --version`. After this, `spt update` handles signed self-updates.

2. **Activate the adapter.** Run `spt adapter list` and find `claude-spt`:
   - Listed and **not** `deregistered` → already active; report it and skip to step 3.
   - Missing or `deregistered` → activate it:
     - **Local dev / dogfooding a repo checkout** (an `adapter/claude-spt.toml` is present near cwd):
       `spt adapter add ./adapter/claude-spt.toml` (the file-form accepts any path + filename).
     - **End-user (plugin only):** `spt adapter add --github SaberMage/claude-spt` (the dedicated
       adapter repo: root `manifest.toml` + `strings/` + tool binaries). Manifest-first; conducts the
       declared `[update]` avenue once.

3. **Verify.** Re-run `spt adapter list` — `claude-spt` must read **active** (no `deregistered`).
   The `[digest]` extractor (`claude-spt-digest`) and Psyche runner (`claude-spt-psyche`) resolve by
   **bare name from PATH**; if either is missing, registration still succeeds but session-digest /
   LiveAgent Psyche stay inert until those binaries are on PATH. Note any that are missing.

Idempotent and safe to re-run — the same bootstrap + activation the SessionStart hook performs.

-  Install or repair spt-core for this Claude Code session (mid-session installer).

+  Install or repair spt-core AND activate the claude-spt adapter for this Claude Code session

+  (mid-session installer + post-install activation).

-Covers the mid-session install gap (ADR-0001): a user who installs the plugin mid-session has not had

-a SessionStart bootstrap fire, so `/sptc:setup` runs the same invisible-installer bootstrap to fetch +

+Covers the mid-session install + activation gap (ADR-0001): a user who installs the plugin mid-session

+has not had a SessionStart bootstrap fire, so `/sptc:setup` runs the same invisible-installer

+bootstrap to fetch + verify spt-core on demand **and then activates the claude-spt adapter**. A

+present binary is not enough: an unregistered/`deregistered` adapter has no profiles/strings/hints/

+`[digest]`, so the `/sptc:*` surface is inert until activation.

-1. If spt-core is already present (`command -v spt && spt --version`), report the version and stop.

-2. Otherwise run the published install-on-demand bootstrap (spt-releases

-   `harness-contract/install-on-demand.md`):

+1. **Binary.** If spt-core is absent (`command -v spt && spt --version` reports nothing), run the

+   published install-on-demand bootstrap (spt-releases `harness-contract/install-on-demand.md`):

-3. `PATH` is not reloaded in this shell after a fresh install — verify with the absolute path:

+   `PATH` is not reloaded in this shell after a fresh install — verify with the absolute path:

+2. **Activate the adapter.** Run `spt adapter list` and find `claude-spt`:

+   - Listed and **not** `deregistered` → already active; report it and skip to step 3.

+   - Missing or `deregistered` → activate it:

+     - **Local dev / dogfooding a repo checkout** (an `adapter/claude-spt.toml` is present near cwd):

+       `spt adapter add ./adapter/claude-spt.toml` (the file-form accepts any path + filename).

+     - **End-user (plugin only):** `spt adapter add --github SaberMage/claude-spt` (the dedicated

+       adapter repo: root `manifest.toml` + `strings/` + tool binaries). Manifest-first; conducts the

+       declared `[update]` avenue once.

+3. **Verify.** Re-run `spt adapter list` — `claude-spt` must read **active** (no `deregistered`).

+   The `[digest]` extractor (`claude-spt-digest`) and Psyche runner (`claude-spt-psyche`) resolve by

+   **bare name from PATH**; if either is missing, registration still succeeds but session-digest /

+   LiveAgent Psyche stay inert until those binaries are on PATH. Note any that are missing.

+Idempotent and safe to re-run — the same bootstrap + activation the SessionStart hook performs.

---
name: setup
description: |
  Install or repair spt-core for this Claude Code session (mid-session installer).
allowed-tools: [Bash]
---

# /sptc:setup

> **Self-contained by necessity.** Unlike other `/sptc:*` skills, `setup` cannot rely on
> UPS-injection of its body: it runs precisely when spt-core may be **absent**, so
> `spt adapter get-string` (the injection source) is unavailable. The operative steps therefore live
> in this SKILL.md (the floor); the file-backed `[strings.skills].setup` body mirrors them for the
> spt-present repair path. See `docs/adr/0001-distribution-splits-by-volatility.md`.

Covers the mid-session install gap (ADR-0001): a user who installs the plugin mid-session has not had
a SessionStart bootstrap fire, so `/sptc:setup` runs the same invisible-installer bootstrap to fetch +
verify spt-core on demand.

**Do this:**

1. If spt-core is already present (`command -v spt && spt --version`), report the version and stop.
2. Otherwise run the published install-on-demand bootstrap (spt-releases
   `harness-contract/install-on-demand.md`):
   - **POSIX:** `curl -fsSL https://sabermage.github.io/spt-releases/install.sh | sh`
   - **Windows (PowerShell):** `irm https://sabermage.github.io/spt-releases/install.ps1 | iex`
3. `PATH` is not reloaded in this shell after a fresh install — verify with the absolute path:
   `"$HOME/.local/bin/spt" --version`. After this, `spt update` handles signed self-updates.


Both bodies now carry the activation step. Activating `REQ-SETUP-ACTIVATE` doc stage (skill body = doc evidence, per the subnet-skill precedent — no impl code, it's agent instructions).


Edit

[[requirements]]
id = "REQ-SETUP-ACTIVATE"
title = "/sptc:setup, after confirming the spt binary is present, ACTIVATES the claude-spt adapter (`spt adapter add` — the manifest file in local dev; `--github <published-adapter-repo>` for end-users) so profiles/strings/hints/[digest] go live, then verifies (adapter no longer `deregistered`). Binary-present is NOT a no-op — this is the F-005 post-install activation bridge."
required_stages = []  # SEEDED inactive (activate-don't-pre-fail). Activates ["doc","impl","int"] when the setup-slice Wave 1 executes: doc = adapter/strings/skills/setup.md + plugin SKILL.md (the activation branch); impl = the `spt adapter add` activation step + verify; int = a registration re-activate assertion (deregistered -> active, profiles resolve). Blocked-open: the end-user `--github` target repo topology (doyle Q1-Q3 pending) — local-dir activation is unblocked.

[[requirements]]
id = "REQ-SETUP-ACTIVATE"
title = "/sptc:setup, after confirming the spt binary is present, ACTIVATES the claude-spt adapter (`spt adapter add` — the manifest file in local dev; `--github <published-adapter-repo>` for end-users) so profiles/strings/hints/[digest] go live, then verifies (adapter no longer `deregistered`). Binary-present is NOT a no-op — this is the F-005 post-install activation bridge."
required_stages = ["doc"]  # doc: adapter/strings/skills/setup.md + plugin/sptc/skills/setup/SKILL.md — the activation step (probe `adapter list`; if missing/deregistered, `adapter add` local-file-form for dev | `--github` for end-user; verify active; PATH-binary caveat). A setup skill body is doc-class instruction prose (no adapter-side code of its own — same model as REQ-SKILL-SUBNET). int (a registration re-activate assertion: deregistered->active + profile resolves) lands with the int sub-step; the END-USER `--github` int is gated on Wave C (the dedicated root-manifest adapter repo). Topology RESOLVED (doyle owl 2026-06-15): monorepo file-form for dev, dedicated repo for --github (pointer mode, binaries on PATH). See SETUP-SLICE-PLAN.md.


The file C:\Users\decid\Documents\projects\spt-claude-code\traceable-reqs.toml has been updated successfully. (file state is current in your context — no need to Read it back)

[[requirements]]
id = "REQ-SETUP-ACTIVATE"
title = "/sptc:setup, after confirming the spt binary is present, ACTIVATES the claude-spt adapter (`spt adapter add` — the manifest file in local dev; `--github <published-adapter-repo>` for end-users) so profiles/strings/hints/[digest] go live, then verifies (adapter no longer `deregistered`). Binary-present is NOT a no-op — this is the F-005 post-install activation bridge."
required_stages = []  # SEEDED inactive (activate-don't-pre-fail). Activates ["doc","impl","int"] when the setup-slice Wave 1 executes: doc = adapter/strings/skills/setup.md + plugin SKILL.md (the activation branch); impl = the `spt adapter add` activation step + verify; int = a registration re-activate assertion (deregistered -> active, profiles resolve). Blocked-open: the end-user `--github` target repo topology (doyle Q1-Q3 pending) — local-dir activation is unblocked.

[[requirements]]
id = "REQ-SETUP-ACTIVATE"
title = "/sptc:setup, after confirming the spt binary is present, ACTIVATES the claude-spt adapter (`spt adapter add` — the manifest file in local dev; `--github <published-adapter-repo>` for end-users) so profiles/strings/hints/[digest] go live, then verifies (adapter no longer `deregistered`). Binary-present is NOT a no-op — this is the F-005 post-install activation bridge."
required_stages = ["doc"]  # doc: adapter/strings/skills/setup.md + plugin/sptc/skills/setup/SKILL.md — the activation step (probe `adapter list`; if missing/deregistered, `adapter add` local-file-form for dev | `--github` for end-user; verify active; PATH-binary caveat). A setup skill body is doc-class instruction prose (no adapter-side code of its own — same model as REQ-SKILL-SUBNET). int (a registration re-activate assertion: deregistered->active + profile resolves) lands with the int sub-step; the END-USER `--github` int is gated on Wave C (the dedicated root-manifest adapter repo). Topology RESOLVED (doyle owl 2026-06-15): monorepo file-form for dev, dedicated repo for --github (pointer mode, binaries on PATH). See SETUP-SLICE-PLAN.md.

-required_stages = []  # SEEDED inactive (activate-don't-pre-fail). Activates ["doc","impl","int"] when the setup-slice Wave 1 executes: doc = adapter/strings/skills/setup.md + plugin SKILL.md (the activation branch); impl = the `spt adapter add` activation step + verify; int = a registration re-activate assertion (deregistered -> active, profiles resolve). Blocked-open: the end-user `--github` target repo topology (doyle Q1-Q3 pending) — local-dir activation is unblocked.

+required_stages = ["doc"]  # doc: adapter/strings/skills/setup.md + plugin/sptc/skills/setup/SKILL.md — the activation step (probe `adapter list`; if missing/deregistered, `adapter add` local-file-form for dev | `--github` for end-user; verify active; PATH-binary caveat). A setup skill body is doc-class instruction prose (no adapter-side code of its own — same model as REQ-SKILL-SUBNET). int (a registration re-activate assertion: deregistered->active + profile resolves) lands with the int sub-step; the END-USER `--github` int is gated on Wave C (the dedicated root-manifest adapter repo). Topology RESOLVED (doyle owl 2026-06-15): monorepo file-form for dev, dedicated repo for --github (pointer mode, binaries on PATH). See SETUP-SLICE-PLAN.md.


Bash

cd "C:/Users/decid/Documents/projects/spt-claude-code" && export PATH="$HOME/.cargo/bin:$PATH"; echo "=== traceable-reqs check ==="; traceable-reqs check 2>&1 | grep -E "REQ-SETUP-ACTIVATE|FAIL|MISSING|error|Summary|passed|OK\]" | head; echo "exit=${PIPESTATUS[0]}"; echo "=== full check exit ==="; traceable-reqs check >/dev/null 2>&1; echo "check_exit=$?"

Verify traceable-reqs green after activating doc stage


=== traceable-reqs check ===
  [OK] REQ-CCS-PROFILES  required: [doc, impl, unit, int]  stages: +doc +impl +unit +int
  [OK] REQ-CI-ACCEPTANCE  required: [doc, impl, int]  stages: +doc +impl -unit +int
  [OK] REQ-CI-BUS  required: [doc, impl]  stages: +doc +impl -unit -int
  [OK] REQ-CI-GATES  required: [doc, impl, unit]  stages: +doc +impl +unit -int
  [OK] REQ-CI-MANUAL  required: [doc, impl]  stages: +doc +impl -unit -int
  [OK] REQ-CI-OWL-DISCOVERY  required: [doc, impl, unit]  stages: +doc +impl +unit -int
  [OK] REQ-CI-TRIGGER  required: [doc, impl]  stages: +doc +impl -unit -int
  [OK] REQ-DIST-BOOTSTRAP-INSTALL  required: [doc, impl]  stages: +doc +impl -unit -int
  [OK] REQ-DIST-DIGEST-EXTRACTOR  required: [impl, unit, int]  stages: -doc +impl +unit +int
  [OK] REQ-DIST-HOOKS-API  required: [doc, impl, unit, int]  stages: +doc +impl +unit +int
exit=0
=== full check exit ===
check_exit=0


cd "C:/Users/decid/Documents/projects/spt-claude-code" && export PATH="$HOME/.cargo/bin:$PATH"; traceable-reqs check 2>&1 | grep -A1 "REQ-SETUP-ACTIVATE"

Confirm REQ-SETUP-ACTIVATE doc satisfied


  [OK] REQ-SETUP-ACTIVATE  required: [doc]  stages: +doc -impl -unit -int
       /sptc:setup, after confirming the spt binary is present, ACTIVATES the claude-spt adapter (`spt adapter add` — the manifest file in local dev; `--github <published-adapter-repo>` for end-users) so profiles/strings/hints/[digest] go live, then verifies (adapter no longer `deregistered`). Binary-present is NOT a no-op — this is the F-005 post-install activation bridge.


`REQ-SETUP-ACTIVATE [OK] +doc`, check exit 0. Running the full gate before commit.


cd "C:/Users/decid/Documents/projects/spt-claude-code" && export PATH="$HOME/.cargo/bin:$HOME/AppData/Local/spt-core/bin:$PATH"; sh ci/run-gates.sh 2>&1 | tail -30; echo "gates_exit=${PIPESTATUS[0]}"

Run full CI gate suite


running 12 tests
............
test result: ok. 12 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

ok  claude-spt-digest: cargo test + release build

=== GATE: psyche-runner (cargo build + test) ===

running 8 tests
........
test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

ok  claude-spt-psyche: cargo test + release build

=== GATE: traceable-reqs check (requirement coverage) ===
ok  coverage green

=== GATE: skeleton-validate (cplugs installability) ===
ok  skeleton installable

=== GATE: manifest-schema ===
ok   C:/Users/decid/Documents/projects/spt-claude-code/adapter/claude-spt.toml
ok   manifest validates against published manifest.schema.json

=== GATE: docs-drift ===
ok   mdbook build
ok   llms.txt in sync

=== RESULT: PASS ===
gates_exit=0


Gate PASS (incl. both tool binaries build + test green). Committing Wave 1.


cd "C:/Users/decid/Documents/projects/spt-claude-code" && git add adapter/strings/skills/setup.md plugin/sptc/skills/setup/SKILL.md traceable-reqs.toml SETUP-SLICE-PLAN.md docs/SPT-CORE-FINDINGS.md && git commit -m "feat(setup): /sptc:setup activates the adapter, not just installs the binary (Wave 1, REQ-SETUP-ACTIVATE doc)

The F-005 bridge: after the binary check, probe \`spt adapter list\`; if
claude-spt is missing/deregistered, activate via \`adapter add\` (local file-form
for dev, --github <dedicated repo> for end-users) and verify active. Note the
PATH-resolved tool-binary prerequisite (digest/Psyche). Both bodies updated
(self-contained SKILL.md floor + file-backed strings mirror).

Records doyle's topology ruling (adapter add ROOT-ONLY; dedicated repo for
--github; pointer mode; binaries not auto-copied) in the plan + F-005, and adds
Wave C (the dedicated published adapter repo, on A's critical path).

Co-authored by: perri" 2>&1 | tail -3

Commit Wave 1 setup activation


[main 3158a87] feat(setup): /sptc:setup activates the adapter, not just installs the binary (Wave 1, REQ-SETUP-ACTIVATE doc)
 5 files changed, 123 insertions(+), 42 deletions(-)


**Wave 1 done — `/sptc:setup` now activates the adapter** (`3158a87`, gate PASS, `REQ-SETUP-ACTIVATE` doc green). Both bodies probe `adapter list` → `adapter add` (local file-form for dev, `--github` for end-user) → verify active, with the PATH-binary caveat noted. doyle's topology ruling recorded in the plan + F-005; Wave C added.

Three things stand between here and "plugin-dogfood fulfills A":

1. **Wave C — the dedicated adapter repo** (the `--github` target). `SaberMage/spt-claude-code` *can't* be it (root-only rule). Needs a new repo: root = `manifest.toml` + `strings/` + the two binaries. **On A's critical path** for the end-user path; needs your SaberMage credentials.
2. **cplugs republish** — the published skeleton (`b1e2895`) still has the *old* setup body. End-users won't get the activation floor until a republish (bumps `plugin.json`).
3. **bootstrap auto-activate** (optional) — SessionStart `bootstrap.sh` still installs binary only; wiring `adapter add` there means first-session users never need to run setup manually (coupled to Wave C existing).

Note: **Wave 1's local-dir path works *now*** — with the repo checked out, `adapter add ./adapter/claude-spt.toml` activates. So you can validate the activation logic immediately, before investing in Wave C.

Two decisions to route the next step:


AskUserQuestion

Question: What should I do next?

Choices:
Lay out the dedicated adapter repo (root manifest.toml + strings/ + binaries) + a ci/publish generator from the monorepo. You create+push the repo (credentials). Unblocks the true end-user --github dogfood.
You dogfood the local-dir activation path now (repo checked out → adapter add ./adapter/claude-spt.toml) to confirm the activation logic before investing in Wave C. I hold.
Re-stage + push the cplugs skeleton with the new setup activation floor (bumps plugin.json) so the published plugin carries it, then Wave C.
Do both structural pieces: dedicated adapter repo layout/generator AND the cplugs republish, in one pass.

Question: Name for the dedicated --github adapter repo (the end-user activation target)?

Choices:
Matches the adapter_name (claude-spt). Recommended — the skill body already references this. Clean mapping: adapter repo == adapter name.
Mirrors the cplugs plugin name (sptc). Groups it visually with the sptc skeleton.
Explicit '-adapter' suffix; unambiguous that it's the registry/manifest repo, distinct from the monorepo.


Your questions have been answered: "What should I do next?"="regarding wave C: 1. if SaberMage/spt-claude-code "can't be it", then how is the manifest's [update] meant to work today? is that also non-functioning? --- notice: doyle is working on a change to unblock you. stand by for doyle's direction", "Name for the dedicated --github adapter repo (the end-user activation target)?"="no separate repo. stand by". You can now continue with these answers in mind.

Question: What should I do next?

Choices:
Lay out the dedicated adapter repo (root manifest.toml + strings/ + binaries) + a ci/publish generator from the monorepo. You create+push the repo (credentials). Unblocks the true end-user --github dogfood.
You dogfood the local-dir activation path now (repo checked out → adapter add ./adapter/claude-spt.toml) to confirm the activation logic before investing in Wave C. I hold.
Re-stage + push the cplugs skeleton with the new setup activation floor (bumps plugin.json) so the published plugin carries it, then Wave C.
Do both structural pieces: dedicated adapter repo layout/generator AND the cplugs republish, in one pass.

Question: Name for the dedicated --github adapter repo (the end-user activation target)?

Choices:
Matches the adapter_name (claude-spt). Recommended — the skill body already references this. Clean mapping: adapter repo == adapter name.
Mirrors the cplugs plugin name (sptc). Groups it visually with the sptc skeleton.
Explicit '-adapter' suffix; unambiguous that it's the registry/manifest repo, distinct from the monorepo.

regarding wave C: 1. if SaberMage/spt-claude-code "can't be it", then how is the manifest's [update] meant to work today? is that also non-functioning? --- notice: doyle is working on a change to unblock you. stand by for doyle's direction


Standing by on Wave C / separate repo — noted. But your question is the sharp one; let me answer it precisely. Checking what `[update]` our manifest actually declares.


Bash

cd "C:/Users/decid/Documents/projects/spt-claude-code" && echo "=== [update] in manifest ==="; grep -n -A12 "^\[update\]" adapter/claude-spt.toml 2>&1; echo "=== any [update] mention ==="; grep -n -i "update" adapter/claude-spt.toml | head -20

Check manifest [update] avenue declaration


=== [update] in manifest ===
=== any [update] mention ===
20:#   * [update]                      — distribution self-update. `file_pull` needs (a) a published
22:#     `delegated` to `claude plugin update` needs CC to attest signature verification


Checked — and it sharpens your point. **Our manifest declares no `[update]` section at all.** It exists only as a header *comment* explaining why it's omitted ("tracked as a finding rather than guessed here") — both avenues had blockers: `file_pull` needs a registry repo + Ed25519 key we don't hold; `delegated` needed `self_verifies` (since confirmed documented — my F-005 read-miss).

So, directly answering you:

**Yes — the manifest's `[update]`/self-update path is non-functioning today, by *omission*, not breakage.** And it reframes Wave C:

- **No `[update]` → COPY mode** (doyle's Q3: "file_pull / no `[update]` → copies `manifest.toml` + `strings/` into `adapters/<name>/`"). Not pointer mode — doyle assumed `delegated` from the header's *mention*, but it's unauthored.
- **First activation does NOT need `[update]`.** `adapter add` registers the manifest *first*, then conducts the `[update]` avenue "once" — with none declared, there's simply nothing to conduct. Registration still succeeds + the adapter goes active.
- **What works today:** local dev file-form (`adapter add ./adapter/claude-spt.toml`) — finds manifest by direct path, COPY-registers, active. Fully functional.
- **What's dead today:** the `--github` end-user path — *registration itself* fails (root-only, manifest in subdir), so `[update]` never even gets a chance. That's the whole F-005 hole.

**The key consequence:** the end-user *activation* only needs `adapter add --github` to **find + register** the manifest. It needs **no `[update]`, no keys, no signed self-update, no dedicated repo** — just a reachable manifest at a resolvable path. So if doyle's incoming change lets `--github SaberMage/spt-claude-code` resolve the monorepo's `adapter/` manifest (subpath, or similar), end-user activation works **directly off this repo** — exactly why "no separate repo" is right. The `[update]`/self-update channel (logic-churn delivery, file_pull, keys, REQ-UPD-1) stays a **separate, later** concern, untouched by first activation.

(Caveat unchanged: the two tool binaries still must be on PATH to *function* — but not for activation/registration.)

**Standing by for doyle.** Not building Wave C / a separate repo. Wave 1 (the setup activation logic) already landed and is correct regardless of how the `--github` target resolves — only the target *string* changes. Want me to flag doyle that our avenue is actually *no-`[update]`/COPY-mode* (not `delegated`/pointer), since his framing assumed delegated? It doesn't change his fix, but keeps his mental model exact.


<task-notification>
<task-id>bp4sffhfb</task-id>
Monitor event: "« spt event »"
<event><EVENT-PART seq="1/5" id="312cd4b4" type="msg" from="doyle">[doyle -&gt; perri] UNBLOCKED — your monorepo --github problem is solved by a new acquisition source I just shipped + published: `spt adapter add --release &lt;user/repo&gt; [--tag &lt;tag&gt;]`.

It fetches a `.spt` archive (a tar whose ROOT holds manifest.toml + strings/ + your binaries) from your repo's GitHu</EVENT-PART>
<EVENT-PART seq="2/5" id="312cd4b4">b release, extracts it to the durable home, and registers the root. So you ship the adapter straight from your EXISTING monorepo — NO dedicated root-manifest repo needed. Your release CI just packs the archive: `tar -czf adapter.spt -C adapter manifest.toml strings/ ...` (arrange the tar so manifest.toml is at the archive ROOT, named exactly</EVENT-PART>
<EVENT-PART seq="3/5" id="312cd4b4"> that) + the built binaries, and uploads it as a release asset (default name adapter.spt; override with --asset). First-acquisition trusts HTTPS+GitHub like the install one-liner; signing rides the file_pull update avenue later.

Live docs (revised): https://sabermage.github.io/spt-releases/harness-contract/install-on-demand.html#activat</EVENT-PART>
<EVENT-PART seq="4/5" id="312cd4b4">e-the-adapter--register-your-manifest — `--release` is now the recommended distribution; --github (root-manifest repo) + the local directory form are the alternatives. CLI: `spt adapter add --help`.

So for /sptc:setup's activation step: `spt adapter add --release &lt;your-org&gt;/&lt;your-repo&gt;` (latest) or `--tag &lt;ver&gt;` to p</EVENT-PART>
<EVENT-PART seq="5/5" id="312cd4b4">in. Local dev stays the file-form `spt adapter add ./adapter/claude-spt.toml`. This does NOT change the [update] route — it's acquisition only (re-running --release --tag &lt;newer&gt; is a manual re-acquire). Carry on — this should close F-005's distribution leg for you.</EVENT-PART></event>
</task-notification>


<owl_reachability_notice>
You have an active owl perch. When spawning subagents or doing work, use run_in_background: true so you stay reachable for incoming messages.
</owl_reachability_notice>


CAVEMAN MODE ACTIVE (full). Drop articles/filler/pleasantries/hedging. Fragments OK. Code/commits/security: write normal.


doyle shipped the unblock: a new acquisition source **`spt adapter add --release <user/repo> [--tag <tag>]`** — fetches a `.spt` tar (root = `manifest.toml` + `strings/` + binaries) from the repo's GitHub **release**, no dedicated repo. Ships straight from **this monorepo** (release CI packs `adapter.spt`). Matches your "no separate repo." Recommended over `--github`.

Checking whether the local 0.7.2 binary already has `--release` (decides build-now vs version-gated).


export PATH="$HOME/AppData/Local/spt-core/bin:$PATH"; echo "spt ver: $(spt --version 2>&1)"; echo "=== adapter add --help ==="; spt adapter add --help 2>&1

Check if local binary has --release flag


spt ver: spt 0.7.2
=== adapter add --help ===
Register an adapter from a local path (a dir holding `manifest.toml`, or the manifest file itself)
or from GitHub (`--github user/repo`, cloned under `adapters/_github/`). Manifest-first: an invalid
manifest registers nothing. Install is the first update — the declared `[update]` avenue is
conducted once after recording

Usage: spt.exe adapter add [OPTIONS] [PATH]

Arguments:
  [PATH]  Local manifest source (omit when using --github)

Options:
      --github <GITHUB>  GitHub source `user/repo` — manifest-first, then install via the declared
                         `[update]` avenue
  -h, --help             Print help


Local 0.7.2 has only `--github` + local path — `--release` shipped in a **newer** spt release (not yet on the operator's install). So authoring to it is fine; the int/dogfood is **version-gated** on upgrading local spt (same pattern as the live-int gate). Updating the setup bodies to the recommended `--release` path.


Edit

     - **End-user (plugin only, no repo checkout):**
       `spt adapter add --github SaberMage/claude-spt` — the dedicated adapter repo whose root holds
       `manifest.toml` + `strings/` + the tool binaries. `adapter add` is manifest-first (an invalid
       manifest registers nothing) and conducts the declared `[update]` avenue once.

     - **End-user (plugin only, no repo checkout):**
       `spt adapter add --release SaberMage/spt-claude-code` — fetches the published `adapter.spt`
       release asset (a tar whose **root** holds `manifest.toml` + `strings/` + the tool binaries)
       from the repo's GitHub release, extracts it to the durable adapter home, and registers it.
       Add `--tag <ver>` to pin a version (omit for latest). Re-running with a newer `--tag` is a
       manual re-acquire. `adapter add` is manifest-first (an invalid manifest registers nothing).
       (Recommended path — ships straight from the monorepo, no dedicated repo. Needs the spt
       release that carries `--release`; the older `--github <root-manifest-repo>` is the alternative.)


     - **End-user (plugin only, no repo checkout):**
       `spt adapter add --release SaberMage/spt-claude-code` — fetches the published `adapter.spt`
       release asset (a tar whose **root** holds `manifest.toml` + `strings/` + the tool binaries)
       from the repo's GitHub release, extracts it to the durable adapter home, and registers it.
       Add `--tag <ver>` to pin a version (omit for latest). Re-running with a newer `--tag` is a
       manual re-acquire. `adapter add` is manifest-first (an invalid manifest registers nothing).
       (Recommended path — ships straight from the monorepo, no dedicated repo. Needs the spt
       release that carries `--release`; the older `--github <root-manifest-repo>` is the alternative.)

# /sptc:setup — operative instructions

> Delivered file-backed via the `claude-spt` adapter `[strings]`
> (`[strings.skills].setup = { file = "skills/setup.md" }`), resolved at injection time. The cplugs
> SKILL.md stays a thin skeleton (ADR-0001).

**Goal:** install or repair spt-core for this session **and ACTIVATE the claude-spt adapter** — the
mid-session installer that covers the gap when no SessionStart bootstrap has fired (a user who
installs the plugin mid-session). Installing the binary is only half the job: a present binary with
a **deregistered** adapter has no profiles/strings/hints/`[digest]`, so `/sptc:*` injection has
nothing to source. Setup must leave the adapter **active**.

<!-- [doc->REQ-SETUP-ACTIVATE] -->

**Do this:**

1. **Binary.** Check whether spt-core is present: `command -v spt && spt --version`.
   - If absent, run the published install-on-demand bootstrap (verbatim against the spt-releases
     contract, `harness-contract/install-on-demand.md`):
     - **POSIX:** `curl -fsSL https://sabermage.github.io/spt-releases/install.sh | sh`
     - **Windows (PowerShell):** `irm https://sabermage.github.io/spt-releases/install.ps1 | iex`
   - `PATH` is not reloaded in the current shell after a fresh install — verify with the absolute
     path for the first call: `"$HOME/.local/bin/spt" --version` (POSIX). Report the version.

2. **Adapter activation (the step a present binary still needs).** Run `spt adapter list` and look
   for `claude-spt`:
   - If `claude-spt` is listed and **not** marked `deregistered` → the adapter is **active**; report
     "adapter active" and go to step 4.
   - If `claude-spt` is **missing or `deregistered`** → **activate** it. Pick the source:
     - **Local dev / dogfooding from a repo checkout** (an `adapter/claude-spt.toml` is present near
       cwd): `spt adapter add ./adapter/claude-spt.toml` (the file-form takes any path + filename).
     - **End-user (plugin only, no repo checkout):**
       `spt adapter add --github SaberMage/claude-spt` — the dedicated adapter repo whose root holds
       `manifest.toml` + `strings/` + the tool binaries. `adapter add` is manifest-first (an invalid
       manifest registers nothing) and conducts the declared `[update]` avenue once.

3. **Verify activation.** Re-run `spt adapter list`: `claude-spt` must now appear **active** (no
   `deregistered`). Spot-check a profile resolves: `spt adapter get-string claude-spt:live adapter_label`
   (any shipped profile). Report the active state.

4. **Tools on PATH (feature prerequisite).** The `[digest]` extractor (`claude-spt-digest`) and the
   Psyche runner (`claude-spt-psyche`) are invoked by **bare name** → resolved from PATH at runtime.
   Activation registers the manifest, but session-digest + LiveAgent Psyche only **function** once
   those two binaries are on PATH (they ride the installer / the dedicated adapter repo). If either
   is missing from PATH, note it — registration succeeds but those features stay inert until they
   resolve.

After this initial bootstrap + activation, `spt update` handles signed self-updates automatically —
the user does not run setup again. The whole flow is idempotent and safe to re-run.

-       `spt adapter add --github SaberMage/claude-spt` — the dedicated adapter repo whose root holds

-       `manifest.toml` + `strings/` + the tool binaries. `adapter add` is manifest-first (an invalid

-       manifest registers nothing) and conducts the declared `[update]` avenue once.

+       `spt adapter add --release SaberMage/spt-claude-code` — fetches the published `adapter.spt`

+       release asset (a tar whose **root** holds `manifest.toml` + `strings/` + the tool binaries)

+       from the repo's GitHub release, extracts it to the durable adapter home, and registers it.

+       Add `--tag <ver>` to pin a version (omit for latest). Re-running with a newer `--tag` is a

+       manual re-acquire. `adapter add` is manifest-first (an invalid manifest registers nothing).

+       (Recommended path — ships straight from the monorepo, no dedicated repo. Needs the spt

+       release that carries `--release`; the older `--github <root-manifest-repo>` is the alternative.)


     - **End-user (plugin only):** `spt adapter add --github SaberMage/claude-spt` (the dedicated
       adapter repo: root `manifest.toml` + `strings/` + tool binaries). Manifest-first; conducts the
       declared `[update]` avenue once.

     - **End-user (plugin only):** `spt adapter add --release SaberMage/spt-claude-code` — fetches
       the published `adapter.spt` release asset (tar root = `manifest.toml` + `strings/` + tool
       binaries) from the repo's GitHub release, extracts to the durable home, registers. `--tag
       <ver>` pins a version. Recommended (ships from the monorepo, no dedicated repo); needs the spt
       release carrying `--release`.


     - **End-user (plugin only):** `spt adapter add --release SaberMage/spt-claude-code` — fetches
       the published `adapter.spt` release asset (tar root = `manifest.toml` + `strings/` + tool
       binaries) from the repo's GitHub release, extracts to the durable home, registers. `--tag
       <ver>` pins a version. Recommended (ships from the monorepo, no dedicated repo); needs the spt
       release carrying `--release`.

---
name: setup
description: |
  Install or repair spt-core AND activate the claude-spt adapter for this Claude Code session
  (mid-session installer + post-install activation).
allowed-tools: [Bash]
---

# /sptc:setup

> **Self-contained by necessity.** Unlike other `/sptc:*` skills, `setup` cannot rely on
> UPS-injection of its body: it runs precisely when spt-core may be **absent**, so
> `spt adapter get-string` (the injection source) is unavailable. The operative steps therefore live
> in this SKILL.md (the floor); the file-backed `[strings.skills].setup` body mirrors them for the
> spt-present repair path. See `docs/adr/0001-distribution-splits-by-volatility.md`.

Covers the mid-session install + activation gap (ADR-0001): a user who installs the plugin mid-session
has not had a SessionStart bootstrap fire, so `/sptc:setup` runs the same invisible-installer
bootstrap to fetch + verify spt-core on demand **and then activates the claude-spt adapter**. A
present binary is not enough: an unregistered/`deregistered` adapter has no profiles/strings/hints/
`[digest]`, so the `/sptc:*` surface is inert until activation.

**Do this:**

1. **Binary.** If spt-core is absent (`command -v spt && spt --version` reports nothing), run the
   published install-on-demand bootstrap (spt-releases `harness-contract/install-on-demand.md`):
   - **POSIX:** `curl -fsSL https://sabermage.github.io/spt-releases/install.sh | sh`
   - **Windows (PowerShell):** `irm https://sabermage.github.io/spt-releases/install.ps1 | iex`

   `PATH` is not reloaded in this shell after a fresh install — verify with the absolute path:
   `"$HOME/.local/bin/spt" --version`. After this, `spt update` handles signed self-updates.

2. **Activate the adapter.** Run `spt adapter list` and find `claude-spt`:
   - Listed and **not** `deregistered` → already active; report it and skip to step 3.
   - Missing or `deregistered` → activate it:
     - **Local dev / dogfooding a repo checkout** (an `adapter/claude-spt.toml` is present near cwd):
       `spt adapter add ./adapter/claude-spt.toml` (the file-form accepts any path + filename).
     - **End-user (plugin only):** `spt adapter add --github SaberMage/claude-spt` (the dedicated
       adapter repo: root `manifest.toml` + `strings/` + tool binaries). Manifest-first; conducts the
       declared `[update]` avenue once.

3. **Verify.** Re-run `spt adapter list` — `claude-spt` must read **active** (no `deregistered`).
   The `[digest]` extractor (`claude-spt-digest`) and Psyche runner (`claude-spt-psyche`) resolve by
   **bare name from PATH**; if either is missing, registration still succeeds but session-digest /
   LiveAgent Psyche stay inert until those binaries are on PATH. Note any that are missing.

Idempotent and safe to re-run — the same bootstrap + activation the SessionStart hook performs.

-     - **End-user (plugin only):** `spt adapter add --github SaberMage/claude-spt` (the dedicated

-       adapter repo: root `manifest.toml` + `strings/` + tool binaries). Manifest-first; conducts the

-       declared `[update]` avenue once.

+     - **End-user (plugin only):** `spt adapter add --release SaberMage/spt-claude-code` — fetches

+       the published `adapter.spt` release asset (tar root = `manifest.toml` + `strings/` + tool

+       binaries) from the repo's GitHub release, extracts to the durable home, registers. `--tag

+       <ver>` pins a version. Recommended (ships from the monorepo, no dedicated repo); needs the spt


Now the plan + F-005: `--release` supersedes the dedicated-repo requirement (Wave C becomes release-asset packaging).


1. **[RESOLVED — doyle, owl 2026-06-15, from source] End-user `--github` target topology.**
   `adapter add` is **ROOT-ONLY, code-confirmed** (`source_manifest_file`): a dir source resolves to
   `<dir>/manifest.toml` **exactly** (exact filename, no scan, no subpath); `--github user/repo`
   reads `<clone-root>/manifest.toml`. Our `adapter/claude-spt.toml` misses on both counts → a
   **doc-gap** (it's in spt-core source, not the published docs; doyle is patching the activation
   docs). **Ruling:**
   - **Local dev** keeps the monorepo `adapter/claude-spt.toml`; activate via the **file-form**
     `spt adapter add ./adapter/claude-spt.toml` (takes any path + any filename).
   - **End-user `--github`** needs a **DEDICATED published adapter repo** (Wave C) whose **root** is
     `manifest.toml` (named exactly) + `strings/` + the binaries the manifest references.
   - **Copy-vs-pointer by `[update]` avenue:** claude-spt's avenue is `delegated`
     (`claude plugin update spt`) → **POINTER mode**: spt-core copies **nothing** into
     `adapters/<name>/`; it reads `manifest.toml` + `strings/` **live from the durable
     `adapters/_github/<safe>` clone**, for life. (`file_pull`/no-`[update]` = COPY mode instead.)
     Root-only holds in both modes.

1. **[RESOLVED — doyle shipped `--release`, owl 2026-06-15] End-user acquisition. NO dedicated repo.**
   doyle shipped a new acquisition source — **`spt adapter add --release <user/repo> [--tag <ver>]`**
   — that fetches a published **`adapter.spt`** release asset (a tar whose **root** holds
   `manifest.toml` + `strings/` + the binaries) from the repo's GitHub **release**, extracts to the
   durable home, and registers the root. **So we ship straight from THIS monorepo — no dedicated
   root-manifest repo needed** (operator: "no separate repo"). First-acquisition trusts HTTPS+GitHub
   like the install one-liner; it's **acquisition only** (does NOT change the `[update]` route;
   re-running `--release --tag <newer>` is a manual re-acquire). Recommended over `--github`.
   Docs (revised): `install-on-demand.html#activate-the-adapter--register-your-manifest`.
   - **Local dev:** file-form `spt adapter add ./adapter/claude-spt.toml` (any path/filename).
   - **End-user:** `spt adapter add --release SaberMage/spt-claude-code` (latest) / `--tag <ver>`.
   - ⚠ **Version gate:** local spt is 0.7.2, which has only `--github` + local path — `--release`
     ships in a **newer** spt release. Authoring is unblocked; the int/dogfood waits on the upgrade.
   - **Superseded:** the root-only `--github`/`source_manifest_file` constraint (dir → exact
     `<dir>/manifest.toml`, no subpath — code-confirmed, a doc-gap doyle patched) still holds, but
     `--release` routes around it. The old "dedicated repo" plan (former Wave C) is **dropped**.


The file C:\Users\decid\Documents\projects\spt-claude-code\SETUP-SLICE-PLAN.md has been updated successfully. (file state is current in your context — no need to Read it back)

1. **[RESOLVED — doyle shipped `--release`, owl 2026-06-15] End-user acquisition. NO dedicated repo.**
   doyle shipped a new acquisition source — **`spt adapter add --release <user/repo> [--tag <ver>]`**
   — that fetches a published **`adapter.spt`** release asset (a tar whose **root** holds
   `manifest.toml` + `strings/` + the binaries) from the repo's GitHub **release**, extracts to the
   durable home, and registers the root. **So we ship straight from THIS monorepo — no dedicated
   root-manifest repo needed** (operator: "no separate repo"). First-acquisition trusts HTTPS+GitHub
   like the install one-liner; it's **acquisition only** (does NOT change the `[update]` route;
   re-running `--release --tag <newer>` is a manual re-acquire). Recommended over `--github`.
   Docs (revised): `install-on-demand.html#activate-the-adapter--register-your-manifest`.
   - **Local dev:** file-form `spt adapter add ./adapter/claude-spt.toml` (any path/filename).
   - **End-user:** `spt adapter add --release SaberMage/spt-claude-code` (latest) / `--tag <ver>`.
   - ⚠ **Version gate:** local spt is 0.7.2, which has only `--github` + local path — `--release`
     ships in a **newer** spt release. Authoring is unblocked; the int/dogfood waits on the upgrade.
   - **Superseded:** the root-only `--github`/`source_manifest_file` constraint (dir → exact
     `<dir>/manifest.toml`, no subpath — code-confirmed, a doc-gap doyle patched) still holds, but
     `--release` routes around it. The old "dedicated repo" plan (former Wave C) is **dropped**.

# JIT plan — `/sptc:setup` activation bridge (F-005) → grow toward LOCKED v1 setup {1–7}

> Next slice after the cplugs first-publish (b1e2895). Goal: make `/sptc:setup` actually
> **activate** the claude-spt adapter after the binary check (the F-005 post-install bridge), so a
> freshly-installed plugin yields a *registered & active* adapter — not a `deregistered` one. Then
> stage the richer LOCKED v1 setup paths (`SCOPE.md` §"/spt:setup" = {1..7}) as later waves.
> Public-surface-only still binds (AGENTS.md).

## Why (the dogfooding finding, 2026-06-15)

An agent ran `/sptc:setup` on a fresh install: `spt 0.7.2` present → skill reported "No install
needed" and **stopped**. But `spt adapter list` showed **`claude-spt: … deregistered`** — the
adapter surface (profiles/strings/hints/`[digest]`) was inert, `/sptc:*` UPS-injection had nothing
to source. **Binary present ≠ adapter active.** doyle triaged F-005 (docs/SPT-CORE-FINDINGS.md) and
confirmed the missing step: after the binary check, setup must run
**`spt adapter add [--github <repo>]`** to ACTIVATE. The current skill has no such step, and (Point
2, operator) no already-installed branch at all — it is a degenerate installer-floor stub far below
the LOCKED v1 `{1..7}` scope.

## Operator decisions (this session, 2026-06-15)

1. **Proceed with the setup slice (B).** Activation (A — un-break the local adapter) is fulfilled by
   the operator **dogfooding the plugin**, not a separate step here.
2. **End-user `--github` target = `SaberMage/spt-claude-code`** (operator: "this repo is published
   there"). ⚠ See Open Question 1 — the monorepo layout conflicts with `adapter add --github`'s
   root-`manifest.toml` expectation; topology must be resolved before the end-user branch is wired.

## Ground truth (verified against live `spt 0.7.2` this session)

- `spt adapter add --help`: PATH = **"a dir holding `manifest.toml`, or the manifest file itself"**;
  `--github user/repo` clones under `adapters/_github/`, **manifest-first**, then conducts the
  declared `[update]` avenue once. **No subpath flag.** "Install is the first update."
- Our manifest is **`adapter/claude-spt.toml`** (a subdir, *not* named `manifest.toml`); no
  `manifest.toml` exists anywhere in the repo. → the **local** activation form that works today is
  the *manifest-file-itself* form: `spt adapter add ./adapter/claude-spt.toml`.
- `claude-spt` reads **`deregistered`** in the registry (Phase-D int tests register→clean-up by
  design) — re-adding re-activates.
- Extractor/runner = `tools/claude-spt-digest` + `tools/claude-spt-psyche` (source). Command
  templates are **opaque, resolved from PATH at runtime** — so for the adapter to *function* (digest
  + Psyche), those binaries must be **built and on PATH**, independent of manifest registration.

## Open questions

1. **[RESOLVED — doyle, owl 2026-06-15, from source] End-user `--github` target topology.**
   `adapter add` is **ROOT-ONLY, code-confirmed** (`source_manifest_file`): a dir source resolves to
   `<dir>/manifest.toml` **exactly** (exact filename, no scan, no subpath); `--github user/repo`
   reads `<clone-root>/manifest.toml`. Our `adapter/claude-spt.toml` misses on both counts → a
   **doc-gap** (it's in spt-core source, not the published docs; doyle is patching the activation
   docs). **Ruling:**
   - **Local dev** keeps the monorepo `adapter/claude-spt.toml`; activate via the **file-form**
     `spt adapter add ./adapter/claude-spt.toml` (takes any path + any filename).
   - **End-user `--github`** needs a **DEDICATED published adapter repo** (Wave C) whose **root** is
     `manifest.toml` (named exactly) + `strings/` + the binaries the manifest references.
   - **Copy-vs-pointer by `[update]` avenue:** claude-spt's avenue is `delegated`
     (`claude plugin update spt`) → **POINTER mode**: spt-core copies **nothing** into
     `adapters/<name>/`; it reads `manifest.toml` + `strings/` **live from the durable
     `adapters/_github/<safe>` clone**, for life. (`file_pull`/no-`[update]` = COPY mode instead.)
     Root-only holds in both modes.
2. **[RESOLVED via Q3 ruling] End-user binary delivery for `claude-spt-digest` / `claude-spt-psyche`.**
   doyle: the manifest-referenced **binaries are NOT auto-copied** in either mode (only `strings/`
   is). So they must be **resolvable on the target**: absolute path, on PATH, or — in our pointer
   mode — **shipped in the `--github` repo at the manifest's referenced paths** so they resolve from
   the durable `_github` clone. **Action:** our command templates reference the binaries by **bare
   name** (`claude-spt-digest …`, `claude-spt-psyche …`) ⇒ resolved from **PATH**. So end-user
   delivery must put both on PATH (ride the installer) OR we switch the manifest to clone-relative
   paths + ship the binaries in the Wave-C repo. **Decide in Wave C** (lean: ship on PATH via the
   installer — keeps templates portable). Folded into Wave C.
3. **Setup context detection.** Skill probes for a local `adapter/claude-spt.toml` (operator
   dogfooding from a checkout → file-form) else uses `--github <Wave-C repo>` (casual end-user).

## Waves

### Wave 1 — the activation bridge (fulfills A on dogfood) — `REQ-SETUP-ACTIVATE`
**Scope:** make `/sptc:setup`'s binary-present path **activate + verify**, not no-op.
- Rewrite step 1 of both bodies (the self-contained `plugin/sptc/skills/setup/SKILL.md` floor **and**
  the file-backed `adapter/strings/skills/setup.md`): after `command -v spt && spt --version`, check
  whether `claude-spt` is **registered & active** (`spt adapter list` parse). If active → report +
  stop. If absent/`deregistered` → **activate**:
  - **local dev / operator dogfood:** `spt adapter add ./adapter/claude-spt.toml` (manifest-file
    form) when a repo-local manifest is detectable (OQ3).
  - **end-user:** `spt adapter add --github <target>` — **wired once OQ1 resolves** (target TBD).
- **Verify** activation: `spt adapter list` shows `claude-spt` active (not `deregistered`); spot a
  profile resolve (`spt adapter get-string claude-spt:live …` or `spt api … capability`).
- Keep the absent-binary install path (current step 2/3) intact — install **then** activate.
- Idempotent + safe to re-run (mirrors the bootstrap's contract).
- **Evidence:** doc = both bodies; impl = the activation+verify step; int = a registration
  re-activate assertion (`ci/manifest/registration-int.sh` extension, or a new `setup-activate-int`)
  — `deregistered → active`, profile resolves, registry left clean. Activate
  `REQ-SETUP-ACTIVATE = ["doc","impl","int"]`.
- **Note the binary-on-PATH caveat (OQ2)** in the body: activation registers the manifest;
  digest/Psyche need the tool binaries present (built + on PATH) to *function*.

### Wave C — the dedicated published adapter repo (the end-user `--github` target) — **on A's critical path**
**Why:** the operator's A-fulfilling dogfood is "install the **plugin**" (the end-user path) → setup
runs `adapter add --github <repo>` → so that repo must EXIST and be correctly shaped. The monorepo
`SaberMage/spt-claude-code` **cannot** be it (root-only rule). **Decision needed (operator):** repo
name + creation (SaberMage org credentials) + the binary-delivery choice (OQ2: on-PATH-via-installer
vs clone-relative-paths-in-repo).
- Lay out repo **root** = `manifest.toml` (the monorepo's `adapter/claude-spt.toml`, renamed) +
  `strings/` (copied) + (per OQ2 decision) the built `claude-spt-digest` + `claude-spt-psyche`.
- A `ci/publish/` step that **generates** this repo from the monorepo `adapter/` (rename + copy +
  drop binaries) so the two never drift — mirrors `package-skeleton.sh` for the cplugs side.
- Verify end-to-end: a clean machine `spt adapter add --github <repo>` → active + a profile resolves
  + digest/Psyche binaries resolve. New REQ (`REQ-DIST-ADAPTER-REPO`) when this wave starts.

### Later waves — LOCKED v1 setup paths {1..7} (each its own slice + REQ; deps flagged)
Staged, not built now (JIT). From `SCOPE.md` §"/spt:setup" LOCKED {1,2,3,4,5,6,7}:
- **#4 already-installed branch** (new subnet / join=add-this-machine / show-code / just-add-endpoint)
  — the natural extension of Wave 1's active-adapter path; pairs with `/sptc:subnet` (already ships).
- **#1 `cc`/`cc <id>` launcher** at project root — **dep:** full-fat M12 `spt endpoint run` picker
  ("lands in a later wave" per `endpoint run --help`; REQ-DIST-SHORTCUT-BASENAME int is held on it).
- **#2** offer `.gitignore` the launchers (rides #1).
- **#3 create first subnet** — QR of the TOTP seed + self-elevating window (elevation design LOCKED,
  `SCOPE.md`; unbuilt). **dep:** elevation machinery.
- **#5 legacy owl migration** — detect `claude_skill_owl`/owl → migrate identity+agents+psyche.
- **#6 OS-service registration** (always-on daemon) — **dep:** spt-core service support.
- **#7 ccs profile wiring** — if `~/.ccs` present; also offer to install ccs. Pairs with the shipped
  `claude-spt:ccs` profile (REQ-CCS-PROFILES).
- Deferred per SCOPE: **#8** off-subnet Psyche sync, **#9** doctor/verify-at-end (operator: "except 9").

## Gate (every wave)
`sh ci/run-gates.sh` PASS + `traceable-reqs check` green. Commit `Co-authored by: perri`.

## Status
- **OQ1/OQ2 RESOLVED (doyle, owl 2026-06-15).** Repo topology decided: monorepo file-form for dev;
  dedicated root-`manifest.toml` repo for `--github` (pointer mode, binaries on PATH). Wave 1 is now
  **fully unblocked** — authoring both activation branches.
- **Wave C is on A's critical path:** the operator's "dogfood the plugin" = end-user path = needs the
  dedicated `--github` repo to exist. Surfaced to operator (repo name + creation + OQ2 binary choice).

-1. **[RESOLVED — doyle, owl 2026-06-15, from source] End-user `--github` target topology.**

-   `adapter add` is **ROOT-ONLY, code-confirmed** (`source_manifest_file`): a dir source resolves to

-   `<dir>/manifest.toml` **exactly** (exact filename, no scan, no subpath); `--github user/repo`

-   reads `<clone-root>/manifest.toml`. Our `adapter/claude-spt.toml` misses on both counts → a

-   **doc-gap** (it's in spt-core source, not the published docs; doyle is patching the activation

-   - **Local dev** keeps the monorepo `adapter/claude-spt.toml`; activate via the **file-form**

-     `spt adapter add ./adapter/claude-spt.toml` (takes any path + any filename).

-   - **End-user `--github`** needs a **DEDICATED published adapter repo** (Wave C) whose **root** is

-     `manifest.toml` (named exactly) + `strings/` + the binaries the manifest references.

-   - **Copy-vs-pointer by `[update]` avenue:** claude-spt's avenue is `delegated`

-     (`claude plugin update spt`) → **POINTER mode**: spt-core copies **nothing** into

-     `adapters/<name>/`; it reads `manifest.toml` + `strings/` **live from the durable

-     `adapters/_github/<safe>` clone**, for life. (`file_pull`/no-`[update]` = COPY mode instead.)

+1. **[RESOLVED — doyle shipped `--release`, owl 2026-06-15] End-user acquisition. NO dedicated repo.**

+   doyle shipped a new acquisition source — **`spt adapter add --release <user/repo> [--tag <ver>]`**

+   — that fetches a published **`adapter.spt`** release asset (a tar whose **root** holds

+   `manifest.toml` + `strings/` + the binaries) from the repo's GitHub **release**, extracts to the

+   durable home, and registers the root. **So we ship straight from THIS monorepo — no dedicated

+   root-manifest repo needed** (operator: "no separate repo"). First-acquisition trusts HTTPS+GitHub

+   like the install one-liner; it's **acquisition only** (does NOT change the `[update]` route;

+   re-running `--release --tag <newer>` is a manual re-acquire). Recommended over `--github`.

+   Docs (revised): `install-on-demand.html#activate-the-adapter--register-your-manifest`.

+   - **Local dev:** file-form `spt adapter add ./adapter/claude-spt.toml` (any path/filename).

+   - **End-user:** `spt adapter add --release SaberMage/spt-claude-code` (latest) / `--tag <ver>`.

+   - ⚠ **Version gate:** local spt is 0.7.2, which has only `--github` + local path — `--release`

+     ships in a **newer** spt release. Authoring is unblocked; the int/dogfood waits on the upgrade.

+   - **Superseded:** the root-only `--github`/`source_manifest_file` constraint (dir → exact

+     `<dir>/manifest.toml`, no subpath — code-confirmed, a doc-gap doyle patched) still holds, but

+     `--release` routes around it. The old "dedicated repo" plan (former Wave C) is **dropped**.


2. **[RESOLVED via Q3 ruling] End-user binary delivery for `claude-spt-digest` / `claude-spt-psyche`.**
   doyle: the manifest-referenced **binaries are NOT auto-copied** in either mode (only `strings/`
   is). So they must be **resolvable on the target**: absolute path, on PATH, or — in our pointer
   mode — **shipped in the `--github` repo at the manifest's referenced paths** so they resolve from
   the durable `_github` clone. **Action:** our command templates reference the binaries by **bare
   name** (`claude-spt-digest …`, `claude-spt-psyche …`) ⇒ resolved from **PATH**. So end-user
   delivery must put both on PATH (ride the installer) OR we switch the manifest to clone-relative
   paths + ship the binaries in the Wave-C repo. **Decide in Wave C** (lean: ship on PATH via the
   installer — keeps templates portable). Folded into Wave C.

2. **[OPEN — fold into Wave C′ packaging] Binary resolution for `claude-spt-digest` / `claude-spt-psyche`.**
   The `--release` `adapter.spt` tar **includes** the binaries at the archive root (extracted to the
   durable home). BUT our command templates reference them by **bare name** ⇒ resolved from **PATH**,
   not the durable home. So packing them only helps if spt-core runs templates with the adapter home
   on PATH / cwd — **unverified**. Two clean options: **(a)** ship both binaries **on PATH** via the
   installer (keeps bare-name templates portable; lean), or **(b)** reference them by a path relative
   to the adapter home in the manifest + rely on the archive extraction. **Decide when building the
   release-asset packaging (Wave C′).** Activation/registration does NOT need the binaries — only
   runtime digest/Psyche do — so this never blocks the activation step.