{
  "summary": "No P1 findings. Four concrete P2 defects / release-requirement mismatches:\n\n1. **P2 — The installed-skill integration evidence exercises the wrong OMP discovery path.** `SCOPE.md:79-83` requires discovery from the installed `adapter.spt` layout. Production fresh/resume launches pass the extracted extension file directly (`adapter/omp-spt.toml:74,81`, `--extension {adapter_dir}/strings/omp-spt.mjs`). By contrast, `assertInstalledOmpDiscovery()` copies the source package to a synthetic directory and registers it through `omp plugin link` (`tests/omp-skills.mjs:247-267`), then starts RPC without any `--extension` argument (`tests/omp-skills.mjs:284-294`). **Trigger:** install the release normally and start/resume an endpoint; no `omp plugin link` occurs. **Impact:** the `[int->REQ-PARITY-*]` gate can pass even if direct-extension package-root resolution—the actual shipped seam—fails to expose sibling skills; users were explicitly promised no separate plugin install. **Fix:** stage/extract the real archive layout and run the RPC probe with `--extension <installed-root>/strings/omp-spt.mjs` and an otherwise empty plugin registry; do not make `plugin link` the discovery prerequisite.\n\n2. **P2 — Safety-critical packaged skills have unqualified identities and can be shadowed by higher-precedence project skills.** All four frontmatter identities are generic (`adapter/strings/skills/{commune,role,setup,signoff}/SKILL.md:2`), and the test hard-codes `/skill:commune`, `/skill:role`, `/skill:setup`, and `/skill:signoff` (`tests/omp-skills.mjs:10,309-320`) in an empty work directory (`tests/omp-skills.mjs:249-252`). OMP's public skill contract says deduplication is by skill `name`, first wins, with project/user `native` skills priority 100 and `omp-plugins` only priority 90: https://github.com/can1357/oh-my-pi/blob/main/docs/skills.md#built-in-skill-providers-and-precedence. **Trigger:** open a repository containing `.omp/skills/signoff/SKILL.md` (or commune/role/setup) with the same name, or load an earlier same-name provider collision, then request/invoke that workflow. **Impact:** OMP selects the colliding instructions instead of the adapter's endpoint-ID checks and trust-boundary choreography; the packaged capability is not reliably addressable and a colliding signoff/role workflow can target the wrong endpoint. **Fix:** give shipped capabilities adapter-qualified names/directories such as `spt-commune`, `spt-signoff`, `spt-role`, and `spt-setup` (descriptions can retain natural-language triggers), update startup guidance/docs/tests, and add a discovery test with hostile same-name project skills proving the qualified package identities still resolve.\n\n3. **P2 — The setup skill tells the model to execute an interactive attach command inside its tool turn.** The ordinary-session branch correctly says to “direct the user” to `/ready` or `/live`, but the next branch instructs the agent itself to “run” `spt endpoint run ... --create` (`adapter/strings/skills/setup/SKILL.md:43-44`). That command's documented/default behavior is to attach the invoking terminal to the new native OMP TUI (`docs-site/src/quickstart.md:63-64`; the public-surface probe deliberately checks `default action` at `tests/omp-skills.mjs:200`). **Trigger:** invoke setup and ask it to create a hosted endpoint. **Impact:** the model launches an interactive, long-lived native TUI under its command tool, which can block/fail the setup turn or nest/replace the current OMP surface—the exact behavior line 47 warns against. The test only verifies that the command text exists, so the gate blesses the bad choreography. **Fix:** make this an explicit operator handoff: print the exact attach command for the operator to run in their own terminal and never execute it from the agent tool; if a public headless start mode is intentionally supported, use that for agent execution and hand off `spt rc <id>` separately.\n\n4. **P2 — Canonical published lifecycle docs contradict the new safe-boundary delivery behavior.** `docs-site/src/reference/harness-contract.md:51` says a queued message is submitted only when no agent turn is active, and lines 57-58 say an active-turn message waits in the queue. The generated public export repeats the claims at `docs-site/llms-full.txt:216,222-223`. The milestone contract instead requires entry at the first proven active-turn boundary (`docs/PARITY.md:34-38`), and implementation/tests prove context injection before the next model/tool continuation (`adapter/strings/omp-spt.mjs:1744-1778`; `tests/omp-extension.mjs:1772-1802`). **Trigger:** a peer message arrives while OMP is between model/tool continuations in an active turn. **Impact:** v0.3.0's rendered Pages and agent export document materially weaker/wrong latency and ordering semantics, undermining the parity release claim even though the code implements it. **Fix:** rewrite the lifecycle row and paragraph to distinguish first-message safe-boundary injection from later-message ordered next-turn fallback, regenerate `llms-full.txt`, and add a focused docs truth assertion for the active-boundary contract.",
  "files": [
    {
      "path": "tests/omp-skills.mjs",
      "description": "Installed discovery integration uses `omp plugin link`, an empty work directory, generic skill names, and only textual setup assertions; it does not reproduce production direct-extension loading or collision/interactive-attach triggers."
    },
    {
      "path": "adapter/omp-spt.toml",
      "description": "Defines the actual production fresh/resume seam: OMP receives the extracted `strings/omp-spt.mjs` through `--extension`."
    },
    {
      "path": "adapter/strings/skills/commune/SKILL.md",
      "description": "Generic unqualified `commune` identity; safety-sensitive endpoint-qualified continuity/checkpoint workflow is shadowable by higher-priority same-name skills."
    },
    {
      "path": "adapter/strings/skills/signoff/SKILL.md",
      "description": "Generic unqualified `signoff` identity; its self-ID and graceful-shutdown safeguards disappear when shadowed."
    },
    {
      "path": "adapter/strings/skills/role/SKILL.md",
      "description": "Generic unqualified `role` identity; durable-role target safeguards disappear when shadowed."
    },
    {
      "path": "adapter/strings/skills/setup/SKILL.md",
      "description": "Generic unqualified `setup` identity and line 44's incorrect instruction to execute the default interactive attach path from the model workflow."
    },
    {
      "path": "docs-site/src/reference/harness-contract.md",
      "description": "Canonical Pages source still describes only idle/next-turn submission and contradicts implemented safe-boundary delivery."
    },
    {
      "path": "docs-site/llms-full.txt",
      "description": "Generated agent export faithfully republishes the stale active-turn delivery claim."
    },
    {
      "path": "docs-site/src/quickstart.md",
      "description": "Confirms `endpoint run`'s default behavior attaches the invoking terminal to native OMP, making setup SKILL.md's agent-executed choreography unsafe."
    },
    {
      "path": "SCOPE.md",
      "description": "Locked skill policy requires release verification to prove discovery from the installed `adapter.spt` layout."
    }
  ],
  "architecture": "The release packages one OMP package under `adapter.spt/strings`; spt-core launches its extension by direct `--extension` path, and OMP's `omp-plugins` provider discovers sibling skills by global skill name. The current integration gate instead registers that directory as a user plugin, in a collision-free synthetic workspace. Model-driven commune/signoff/role/setup live in those skills; deterministic activation/checkpoint/lifecycle stays extension-owned. Documentation is generated from `docs-site/src` into `llms-full.txt` and a temporary mdBook Pages artifact, and both docs and skill gates are centrally invoked by `ci/run-gates.sh`. Central inclusion itself is present; the defects are production-path fidelity, skill source identity, setup terminal ownership, and stale published lifecycle truth."
}