create-pmos 0.32.0 → 0.33.0

package/README.md

@@ -232,6 +232,17 @@ npx create-pmos@latest --update
 
 Refreshes the skills, concepts, and scripts only. Your records — `state/`, `planning/`, `okf/product/` — are yours, and an update never touches them. `pmos/KIT-VERSION` always says exactly what you're running.
 
+## What's new in 0.33.0
+
+**Three shipped documents stop telling you to do things that were never possible in your repo.** Run `npx create-pmos@latest --update`. No behaviour changes — this is a correctness release for the instructions the kit hands your agent.
+
+- **`SKILL-FORMAT.md` no longer sends you after a seed you never had.** When you edited a `.skill`, it told you to "regenerate the seed in the same PR" and to grep an RLS test suite for pinned metadata. Those instructions described a hosted mirror table that only ever existed in PMOS's own backend — never in a vendored kit. That backend has now been removed entirely, and the section is rewritten to say what is actually true for you: **the frontmatter on disk is the only copy**, which is why the whole class of mirror-drift bug it warned about cannot reach you. The trade is stated rather than glossed: nothing validates your skill metadata, so a wrong registry key is simply wrong.
+- **`ingest-repo` and `harness-refine` stop linking at reference docs your kit does not contain.** Both pointed at PMOS's hosted data-model and monitoring-view docs. `ingest-repo` now describes its write path as what it is in file mode — drafts into your own repo, approved in PR review — and `harness-refine` reads its evidence from `discoveries.md` and your run log instead of from SQL views.
+
+**Why now.** PMOS removed its own hosted backend in this release's parent change, and these three files were the places where instructions written for that backend had leaked into what your kit ships. None of it was ever reachable from a kit install, so nothing was broken — it was wrong documentation, and it is now right.
+
+**Unchanged:** the payload's skill set, the state layout, every gate, and the zero-network guarantee. Your records are untouched, as always.
+
 ## What's new in 0.32.0
 
 **The PM's own accept button now writes through the guarded writer, instead of appending to the acceptance log directly.** Run `npx create-pmos@latest workspace`; the version bump means an existing install auto-upgrades.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-pmos",
-  "version": "0.32.0",
+  "version": "0.33.0",
   "description": "Scaffold the PMOS portable kit — run the PMOS product-management workflow (initiative → lane-fit spec → contract → build → three gates, with work-type lanes for features, research, maintenance, incidents, and content) entirely inside your own repo, with all state as git-versioned files. Includes `workflow-sweep`, which audits the state every board derives from and separates real defects from work you simply have not done. `create-pmos workspace` also installs + launches the local Terminal Workspace GUI. No database, no network, no telemetry.",
   "license": "MIT",
   "bin": {

package/payload/KIT-VERSION

@@ -1,3 +1,3 @@
-kernel-source: pmos@6d5951a
-assembled: 2026-08-05
+kernel-source: pmos@51a8275
+assembled: 2026-08-06
 mode: vendor

package/payload/skills/SKILL-FORMAT.md

@@ -6,23 +6,17 @@ timestamp: 2026-07-23
 
 # SKILL-FORMAT.md — Required Format for PMOS Skills
 
-This document defines the **required** structure for every `.skill` file in PMOS. It is the
-authority that all seed skills (`prd`, `eval-rubric`, `okr`, `strategic-brief`, `source-to-concept`)
-and every future skill must conform to.
+This document defines the **required** structure for every `.skill` file in PMOS. It is the authority that all seed skills (`prd`, `eval-rubric`, `okr`, `strategic-brief`, `source-to-concept`) and every future skill must conform to.
 
 ## Why a fixed format
 
-Skills are how PMOS gives an agent procedural competence on demand without flooding its context.
-The format exists to make that economical: cheap to keep many skills available, expensive to load
-only the one in use. The mechanism is **three-level progressive disclosure**.
+Skills are how PMOS gives an agent procedural competence on demand without flooding its context. The format exists to make that economical: cheap to keep many skills available, expensive to load only the one in use. The mechanism is **three-level progressive disclosure**.
 
 ## The three levels
 
 ### Level 1 — Frontmatter (always loaded)
 
-YAML frontmatter containing **only `name` and `description`**. This is pre-loaded for **all** skills
-at agent startup, so it must stay small — it is the *trigger signal* the agent uses to decide
-whether the skill is relevant.
+YAML frontmatter containing **only `name` and `description`**. This is pre-loaded for **all** skills at agent startup, so it must stay small — it is the *trigger signal* the agent uses to decide whether the skill is relevant.
 
 ```yaml
 ---
@@ -32,189 +26,96 @@ description: Write a Product Requirements Document for an initiative. Use when a
 ```
 
 Rules:
+
 - `name` — lowercase, matches the filename stem (`prd` → `prd.skill`). **Required.**
-- `description` — one or two sentences. State **what** the skill does and **when** to use it.
-  This is the only text the agent sees for an unloaded skill, so the "when" is what makes it fire.
-  **Required.**
-- `maturity_mode` — **optional**. Present **only** on skills that are not yet active (e.g. `bootstrap`);
-  omit it entirely on active skills. It lives at L1 because "is this skill executable yet?" is an
-  execution-gating signal a loader/CI must be able to read without parsing the body. Values: `bootstrap`
-  (specified, non-executable) → graduates to active (key removed) by a PM decision in `DECISIONS.md`.
-- **Optional Phase-B registry metadata (D49)** — a skill may also carry `version`, `owner`, `risk`,
-  `category`, and `scope`. These are **optional**, producer-defined registry fields that
-  the resync generator [`gen_okf_mirror_seed.py`](/supabase/gen_okf_mirror_seed.py) sources into the `skills` table so the skill
-  library can group/version/scope skills. A skill with only `name` + `description` is still fully
-  conformant (e.g. `build-skills/evaluator.skill`); carry the registry keys on durable `skills/core/`
-  entries for consistency with their siblings.
-- `lifecycle` — **optional**, in the same D49 registry slot. Values: `active` (the default when the
-  key is absent) | `deprecated`. A deprecated skill **stays on disk and stays in the registry** —
-  `get_skill` returns it in full with a `deprecated_notice` so a retrieving agent is *told* not to
-  start new work on it. Retirement is a state you can read; deletion is a separate act (see the
-  invariant below). Distinct from `maturity_mode`, which is about a skill not yet executable —
-  `lifecycle` is about one on its way out.
-- **No other L1 keys.** Beyond the required `name` + `description`, the optional `maturity_mode`, and the
-  optional Phase-B registry keys above, procedural detail does not belong in L1 — it lives in the body.
-
-### The disk ⇄ registry invariant (enforced in CI)
-
-**Every `.skill` on disk is seeded, and every seeded skill exists on disk — exactly.** The `skills`
-table is a *mirror*, and `get_skill` serves it to agents in other people's repos, so a mirror that
-has quietly drifted is a wrong answer delivered confidently.
-
-The `REGISTRY` check in [`check_okf_drift.py`](/supabase/check_okf_drift.py) fails the build on:
-adding or renaming a `.skill` without regenerating the seed; a seeded skill whose file is gone; and
-any registry-metadata value that disagrees with the file's own frontmatter. That last one is not
-theoretical — a generator whose INSERT omitted the Phase-B columns silently nulled
-`version/owner/risk/category/scope` for **all 21 skills for about three weeks** in 2026-07, and was
-caught only by an incidental version pin in an RLS test. So:
-
-> **When you add, rename, delete, or edit the frontmatter of a `.skill`, regenerate the seed in the
-> same PR** ([okf-sync playbook](/okf/core/playbooks/okf-sync.md)) — and sweep `supabase/tests/` for
-> pins on that skill's registry metadata before you do (the prd-grilling F1 rule).
+- `description` — one or two sentences. State **what** the skill does and **when** to use it. This is the only text the agent sees for an unloaded skill, so the "when" is what makes it fire. **Required.**
+- `maturity_mode` — **optional**. Present **only** on skills that are not yet active (e.g. `bootstrap`); omit it entirely on active skills. It lives at L1 because "is this skill executable yet?" is an execution-gating signal a loader/CI must be able to read without parsing the body. Values: `bootstrap` (specified, non-executable) → graduates to active (key removed) by a PM decision in `DECISIONS.md`.
+- **Optional Phase-B registry metadata (D49)** — a skill may also carry `version`, `owner`, `risk`, `category`, and `scope`. These are **optional**, producer-defined registry fields that the workspace's skill library reads to group/version/scope skills. They used to be sourced into a hosted `skills` table by a resync generator; [D66](/DECISIONS.md) removed that mirror along with the backend, so the frontmatter on disk is now the only registry there is. A skill with only `name` + `description` is still fully conformant (e.g. `build-skills/evaluator.skill`); carry the registry keys on durable `skills/core/` entries for consistency with their siblings.
+- `lifecycle` — **optional**, in the same D49 registry slot. Values: `active` (the default when the key is absent) | `deprecated`. A deprecated skill **stays on disk** — a reader gets it in full and is *told* not to start new work on it. Retirement is a state you can read; deletion is a separate act (see the invariant below). Distinct from `maturity_mode`, which is about a skill not yet executable — `lifecycle` is about one on its way out.
+- **No other L1 keys.** Beyond the required `name` + `description`, the optional `maturity_mode`, and the optional Phase-B registry keys above, procedural detail does not belong in L1 — it lives in the body.
+
+### The disk ⇄ registry invariant — retired with the mirror (D66)
+
+There used to be a second copy of every skill: a hosted `skills` table that `get_skill` served to agents in other people's repos. A `REGISTRY` check in the drift gate held the two in sync, because a mirror that has quietly drifted is a wrong answer delivered confidently — and it was not theoretical. A generator whose INSERT omitted the Phase-B columns silently nulled `version/owner/risk/category/scope` for **all 21 skills for about three weeks** in 2026-07, caught only by an incidental version pin in an RLS test.
+
+[D66](/DECISIONS.md) deleted the mirror, the generator and that check together with the hosted backend. **The file on disk is now the only copy**, which is why the class of bug above cannot recur: there is nothing left to disagree with. The cost is that skill metadata is no longer validated by CI at all — if a registry key is wrong in the frontmatter, it is simply wrong. Read the frontmatter as authoritative and keep it accurate by hand.
 
 ### Level 2 — SKILL.md body (loaded when relevant)
 
-The body below the frontmatter holds the **full procedural detail**: steps, heuristics, required
-fields, gate criteria, examples. The agent reads this only after Level 1 has signalled relevance.
+The body below the frontmatter holds the **full procedural detail**: steps, heuristics, required fields, gate criteria, examples. The agent reads this only after Level 1 has signalled relevance.
 
-This is where the actual "how to do the task" lives. Write it at optimal altitude — concrete
-heuristics that guide judgment, not a brittle decision tree and not a vague mandate.
+This is where the actual "how to do the task" lives. Write it at optimal altitude — concrete heuristics that guide judgment, not a brittle decision tree and not a vague mandate.
 
 ### Level 3 — Linked sub-files (loaded on demand)
 
-Rare sub-cases, long reference tables, or edge-case procedures live in **separate files**,
-referenced **by filename** from the Level 2 body. The agent reads them only when the body points it
-there for the specific case in hand.
+Rare sub-cases, long reference tables, or edge-case procedures live in **separate files**, referenced **by filename** from the Level 2 body. The agent reads them only when the body points it there for the specific case in hand.
 
 Example reference from a body: *"For multi-product PRDs, follow `prd-multiproduct.md`."*
 
-Use Level 3 to keep Level 2 focused. If a section applies to <20% of runs, it is a Level 3
-candidate.
+Use Level 3 to keep Level 2 focused. If a section applies to <20% of runs, it is a Level 3 candidate.
 
 ## Quality — what makes a skill good (not just well-formed)
 
-The three levels are *structure*. This section is the *bar*. A skill can be perfectly structured and
-still be junk; these are the tests that keep it worth its context.
+The three levels are *structure*. This section is the *bar*. A skill can be perfectly structured and still be junk; these are the tests that keep it worth its context.
 
 ### Predictability is the root virtue
 
-A skill exists to **wring determinism out of a stochastic system**: it makes the agent take the same
-*process* every run — not produce the same *output* (an evaluator should predictably *judge*; its
-words vary, its behavior doesn't). Every rule below serves predictability; cost and readability are
-symptoms of it, not rival goals. When unsure whether a line belongs, ask: *does it make the agent's
-process more repeatable?* If not, cut it.
+A skill exists to **wring determinism out of a stochastic system**: it makes the agent take the same *process* every run — not produce the same *output* (an evaluator should predictably *judge*; its words vary, its behavior doesn't). Every rule below serves predictability; cost and readability are symptoms of it, not rival goals. When unsure whether a line belongs, ask: *does it make the agent's process more repeatable?* If not, cut it.
 
 ### Per-step completion criteria
 
-Every procedural step ends on a **checkable done-condition** — the agent must be able to tell done
-from not-done. Where it matters, make the criterion **exhaustive**, not vague: *"every living mirror
-of the rule accounted for"*, not *"produce a change list"*. A fuzzy criterion invites **premature
-completion** — the agent stops when it feels done, not when it is. The
-[semantic-pass rule](/build-skills/evaluator.skill) ("enumerate the live-doc set, then read each for
-meaning — a grep is evidence, never done") is the exemplar this generalizes: it exists because a
-vague "sweep it" criterion let real stale mirrors survive five "clean" passes.
+Every procedural step ends on a **checkable done-condition** — the agent must be able to tell done from not-done. Where it matters, make the criterion **exhaustive**, not vague: *"every living mirror of the rule accounted for"*, not *"produce a change list"*. A fuzzy criterion invites **premature completion** — the agent stops when it feels done, not when it is. The [semantic-pass rule](/build-skills/evaluator.skill) ("enumerate the live-doc set, then read each for meaning — a grep is evidence, never done") is the exemplar this generalizes: it exists because a vague "sweep it" criterion let real stale mirrors survive five "clean" passes.
 
 ### Pruning — hunt these named failure modes
 
 A skill without a pruning discipline only ever grows. Hunt, sentence by sentence:
 
-- **No-op** — a line the model already obeys by default, so you pay context to say nothing. Test:
-  does it change behavior vs. the default? *"Be thorough"* to an already-thorough agent is a no-op;
-  the fix is a stronger word (a leading word), not more words.
-- **Sediment** — stale layers that settle because adding feels safe and removing feels risky. The
-  default fate of any skill without this discipline.
-- **Sprawl** — simply too long, even when every line is live. Cure: disclose reference to Level 3;
-  split by branch.
-- **Duplication** — the same meaning in more than one place. Costs tokens and maintenance, and
-  inflates a meaning's apparent importance. Keep one source of truth.
-- **Negation** — steering by prohibition backfires: *"don't think of an elephant"* names the
-  elephant. State the **positive** target behavior; keep a prohibition only as a hard guardrail you
-  can't phrase positively, and pair it with what to do instead.
-
-**This is the checklist the quarterly harness-assumption review runs** (DECISIONS.md cadence): the
-review's question — *what scaffolding can be removed because the model now handles it natively?* — is
-the no-op and sediment hunt applied across every skill.
+- **No-op** — a line the model already obeys by default, so you pay context to say nothing. Test: does it change behavior vs. the default? *"Be thorough"* to an already-thorough agent is a no-op; the fix is a stronger word (a leading word), not more words.
+- **Sediment** — stale layers that settle because adding feels safe and removing feels risky. The default fate of any skill without this discipline.
+- **Sprawl** — simply too long, even when every line is live. Cure: disclose reference to Level 3; split by branch.
+- **Duplication** — the same meaning in more than one place. Costs tokens and maintenance, and inflates a meaning's apparent importance. Keep one source of truth.
+- **Negation** — steering by prohibition backfires: *"don't think of an elephant"* names the elephant. State the **positive** target behavior; keep a prohibition only as a hard guardrail you can't phrase positively, and pair it with what to do instead.
+
+**This is the checklist the quarterly harness-assumption review runs** (DECISIONS.md cadence): the review's question — *what scaffolding can be removed because the model now handles it natively?* — is the no-op and sediment hunt applied across every skill.
 
 ### Leading words
 
-A **leading word** is a compact concept already in the model's pretraining that anchors a whole
-region of behavior in one token — *tight* (loop), *watermelon*, *default-to-refute*, *silent drift*,
-*Summary Gate*. Repeated across a skill, it accumulates a distributed definition and recruits priors
-the model already holds. A triad spelled out at three sites (*"fast, deterministic, low-overhead"*)
-is begging to **collapse** into one word (*tight*). You win twice: fewer tokens, and a sharper hook
-the agent hangs its behavior on. Hunt every skill for restatements a leading word retires.
+A **leading word** is a compact concept already in the model's pretraining that anchors a whole region of behavior in one token — *tight* (loop), *watermelon*, *default-to-refute*, *silent drift*, *Summary Gate*. Repeated across a skill, it accumulates a distributed definition and recruits priors the model already holds. A triad spelled out at three sites (*"fast, deterministic, low-overhead"*) is begging to **collapse** into one word (*tight*). You win twice: fewer tokens, and a sharper hook the agent hangs its behavior on. Hunt every skill for restatements a leading word retires.
 
 ### Invocation (advisory)
 
-The Agent-Skills world splits skills by *who can invoke them* — **model-invoked** (description always
-loaded, agent can auto-fire it, pays permanent context load) vs **user-invoked** (invisible to the
-agent, human-only, zero context load). PMOS's model differs — skills are **retrieved on demand**
-(see the retrieval rationale under *Ecosystem compatibility* below), so Level-1 frontmatter is the
-always-available trigger and there is no auto-fire to gate. Treat the axis as an authoring lens —
-*is this skill's description earning its keep as an always-available trigger?* — **not** a required
-field. (A formal `invocation:` key is a deferred registry question, not part of this format.)
+The Agent-Skills world splits skills by *who can invoke them* — **model-invoked** (description always loaded, agent can auto-fire it, pays permanent context load) vs **user-invoked** (invisible to the agent, human-only, zero context load). PMOS's model differs — skills are **retrieved on demand** (see the retrieval rationale under *Ecosystem compatibility* below), so Level-1 frontmatter is the always-available trigger and there is no auto-fire to gate. Treat the axis as an authoring lens — *is this skill's description earning its keep as an always-available trigger?* — **not** a required field. (A formal `invocation:` key is a deferred registry question, not part of this format.)
 
 ## Ecosystem compatibility — the Agent Skills standard
 
-The open **Agent Skills standard** (Claude Code, Codex, and other harnesses) packages a skill as a
-**directory** `<skill-name>/SKILL.md` with YAML frontmatter (`name`, `description`, optionally
-`license`, `allowed-tools`) plus bundled sub-files. It **validates PMOS's three-level disclosure** —
-same frontmatter-as-trigger, body-as-procedure, sub-files-on-demand shape.
+The open **Agent Skills standard** (Claude Code, Codex, and other harnesses) packages a skill as a **directory** `<skill-name>/SKILL.md` with YAML frontmatter (`name`, `description`, optionally `license`, `allowed-tools`) plus bundled sub-files. It **validates PMOS's three-level disclosure** — same frontmatter-as-trigger, body-as-procedure, sub-files-on-demand shape.
 
-PMOS **diverges** deliberately: skills are flat `<name>.skill` files, **not** `<name>/SKILL.md`
-directories. The rationale is PMOS's retrieval model — skills are fetched on demand via `get_skill`
-or referenced from AGENTS.md, **not** auto-discovered by a harness scanning for `SKILL.md`, so the
-directory ceremony buys nothing here. The **mapping is lossless**, which is what keeps the divergence
-cheap:
+PMOS **diverges** deliberately: skills are flat `<name>.skill` files, **not** `<name>/SKILL.md` directories. The rationale is PMOS's retrieval model — skills are fetched on demand via `get_skill` or referenced from AGENTS.md, **not** auto-discovered by a harness scanning for `SKILL.md`, so the directory ceremony buys nothing here. The **mapping is lossless**, which is what keeps the divergence cheap:
 
 - a `<name>.skill` file **≅** a standard `SKILL.md` body;
 - PMOS's required `name` + `description` frontmatter is **already** the standard's required pair;
 - Level-3 sub-files **≅** the standard's bundled files.
 
-(One nuance for the follow-on below: PMOS's *optional* D49 registry keys —
-`version`/`owner`/`risk`/`category`/`scope`/`lifecycle` — are top-level custom keys; the standard would expect
-producer-defined extensions under a `metadata:` map. The **core** shape is lossless; relocating the
-registry keys belongs to the native-format packaging follow-on, not this flat form.)
+(One nuance for the follow-on below: PMOS's *optional* D49 registry keys — `version`/`owner`/`risk`/`category`/`scope`/`lifecycle` — are top-level custom keys; the standard would expect producer-defined extensions under a `metadata:` map. The **core** shape is lossless; relocating the registry keys belongs to the native-format packaging follow-on, not this flat form.)
 
 ### Kit native-format packaging (E6 — shipped)
 
-The **kit** now ships every skill in native Agent-Skills directory form *as well as* the flat file —
-a lossless portability layer, generated **from** the flat `.skill` at build time (never
-hand-authored, so it cannot drift from its source). For each shipped skill, `kit/build-kit.sh` emits
-`skills-native/<name>/SKILL.md` where:
-
-- the directory name **equals** the frontmatter `name` (the standard's hard rule), and required
-  `name` + `description` are present;
-- PMOS's D49 registry keys (`version`/`owner`/`risk`/`category`/`scope`/`lifecycle`) are relocated
-  **under a `metadata:` map with a `pmos-` prefix** — the standard's producer-extension slot — never
-  as top-level custom keys, so a conformant runtime ignores them cleanly;
-- a **fail-closed conformance self-check** in `build-kit.sh` aborts the build on any violation
-  (name≠dirname, missing required field, or a top-level custom key), the same posture as the
-  containment check.
-
-The flat `.skill` files remain the file-mode source of truth (the AGENTS.md state adapter references
-`pmos/skills/<name>.skill`); the native tree is the ecosystem-portable mirror. **Still a named
-follow-on (not built here):** wiring `create-pmos` to install the native tree into a runtime's
-auto-discovery locations (`.claude/skills/`, `.agents/skills/`). E6 delivers the conformant
-*packaging*; the *install location* is a separate change, revisited when native-discovery demand in
-kit repos is proven.
+The **kit** now ships every skill in native Agent-Skills directory form *as well as* the flat file — a lossless portability layer, generated **from** the flat `.skill` at build time (never hand-authored, so it cannot drift from its source). For each shipped skill, `kit/build-kit.sh` emits `skills-native/<name>/SKILL.md` where:
+
+- the directory name **equals** the frontmatter `name` (the standard's hard rule), and required `name` + `description` are present;
+- PMOS's D49 registry keys (`version`/`owner`/`risk`/`category`/`scope`/`lifecycle`) are relocated **under a `metadata:` map with a `pmos-` prefix** — the standard's producer-extension slot — never as top-level custom keys, so a conformant runtime ignores them cleanly;
+- a **fail-closed conformance self-check** in `build-kit.sh` aborts the build on any violation (name≠dirname, missing required field, or a top-level custom key), the same posture as the containment check.
+
+The flat `.skill` files remain the file-mode source of truth (the AGENTS.md state adapter references `pmos/skills/<name>.skill`); the native tree is the ecosystem-portable mirror. **Still a named follow-on (not built here):** wiring `create-pmos` to install the native tree into a runtime's auto-discovery locations (`.claude/skills/`, `.agents/skills/`). E6 delivers the conformant *packaging*; the *install location* is a separate change, revisited when native-discovery demand in kit repos is proven.
 
 ### Per-skill eval harness (E8 — convention shipped, benchmark deferred)
 
-A skill may carry an **opt-in** eval file at `skills/evals/<name>.evals.json` (mapping to the
-standard's `<name>/evals/evals.json` in native packaging), adopting the skill-creator harness shape:
+A skill may carry an **opt-in** eval file at `skills/evals/<name>.evals.json` (mapping to the standard's `<name>/evals/evals.json` in native packaging), adopting the skill-creator harness shape:
 
-- **`description_triggers`** — `should_fire` / `should_not_fire` prompt lists that test whether the
-  L1 description fires on the right requests and stays silent on the wrong ones (trigger-accuracy).
-- **`cases`** — each a `{ name, prompt, expect, with_without }`, where `expect` is an **outcome
-  property** a grader checks (never a script) and `with_without` toggles whether the case is meant
-  for with-vs-without-the-skill benchmarking.
+- **`description_triggers`** — `should_fire` / `should_not_fire` prompt lists that test whether the L1 description fires on the right requests and stays silent on the wrong ones (trigger-accuracy).
+- **`cases`** — each a `{ name, prompt, expect, with_without }`, where `expect` is an **outcome property** a grader checks (never a script) and `with_without` toggles whether the case is meant for with-vs-without-the-skill benchmarking.
 
-`scripts/check_skill_evals.py` (run in the `okf-drift` job) validates the **shape** of any present
-eval file and that it names a real skill. It **never runs a benchmark** — actually scoring
-with-vs-without needs labeled outcomes + compute and is **deferred** (there is no negative class
-yet); running models in CI would make the gate nondeterministic. The convention and a worked example
-(`skills/evals/prd.evals.json`) ship now; the verdict "this skill measurably helps" does not.
+`scripts/check_skill_evals.py` (run in the `okf-drift` job) validates the **shape** of any present eval file and that it names a real skill. It **never runs a benchmark** — actually scoring with-vs-without needs labeled outcomes + compute and is **deferred** (there is no negative class yet); running models in CI would make the gate nondeterministic. The convention and a worked example (`skills/evals/prd.evals.json`) ship now; the verdict "this skill measurably helps" does not.
 
 ## File naming
 
@@ -232,9 +133,7 @@ yet); running models in CI would make the gate nondeterministic. The convention
 
 A skill is well-formed when:
 
-1. Level 1 frontmatter has `name` + `description` (both required), plus optionally `maturity_mode` (on
-   non-active skills) and the Phase-B registry keys `version`/`owner`/`risk`/`category`/`scope`/
-   `lifecycle` (D49); no other L1 keys.
+1. Level 1 frontmatter has `name` + `description` (both required), plus optionally `maturity_mode` (on non-active skills) and the Phase-B registry keys `version`/`owner`/`risk`/`category`/`scope`/ `lifecycle` (D49); no other L1 keys.
 2. `name` matches the filename stem.
 3. `description` states both what the skill does and when to use it.
 4. The body (Level 2) carries the full procedure and is self-sufficient for the common case.
@@ -242,13 +141,9 @@ A skill is well-formed when:
 
 **Quality bar** (the "good", not just "well-formed" — see Quality above):
 
-6. **Predictability served** — every line makes the agent's *process* more repeatable; cut what
-   doesn't.
-7. **Per-step completion criteria** — each procedural step ends on a checkable (and where it matters
-   exhaustive) done-condition, not a vague "do X".
-8. **Pruned** — no no-ops, no sediment, no duplication; prohibitions phrased as positive targets;
-   sprawl disclosed to Level 3.
+6. **Predictability served** — every line makes the agent's *process* more repeatable; cut what doesn't.
+7. **Per-step completion criteria** — each procedural step ends on a checkable (and where it matters exhaustive) done-condition, not a vague "do X".
+8. **Pruned** — no no-ops, no sediment, no duplication; prohibitions phrased as positive targets; sprawl disclosed to Level 3.
 9. **Leading words** — restated qualities collapsed into pretrained tokens where one earns its keep.
 
-All seed skills are authored against this checklist; the quarterly harness-assumption review re-runs
-items 6–9 across every skill.
+All seed skills are authored against this checklist; the quarterly harness-assumption review re-runs items 6–9 across every skill.

package/payload/skills/harness-refine.skill

@@ -87,8 +87,9 @@ field's "agents improving their own tools" loop while staying at the **L3 ceilin
   bounding decision [D47](/okf/products/pmos/adr/d47-self-refining-harness.md).
 - The sibling detect→draft→PR loop: [okf-author](/build-skills/okf-author.skill),
   [D42](/okf/products/pmos/adr/d42-okf-author-on-demand.md).
-- The evidence surfaces: [v_friction_recurrence](/okf/products/pmos/references/metrics/v_friction_recurrence.md),
-  [v_context_budget](/okf/products/pmos/references/metrics/v_context_budget.md),
+- The evidence surfaces: recurring friction themes and self-reported context pressure, read from
+  file-mode state ([discoveries.md](/discoveries.md) and `runs.jsonl`; the hosted
+  `v_friction_recurrence` / `v_context_budget` views went with the backend in D66) plus
   [eval-calibration.md](/planning/evals/eval-calibration.md).
 - The cadence it serves: [D23](/okf/products/pmos/adr/d23-quarterly-cadence.md) (harness-assumption
   review); the altitude standard: [agent-harness](/okf/core/concepts/agent-harness.md).

package/payload/skills/ingest-repo.skill

@@ -13,8 +13,8 @@ scope: read:tenant-repo, write:tenant-okf-drafts, write:product_repos
 This skill is the **existing-repo on-ramp**: a PM arrives with a product that already ships and already
 has a repo, and PMOS needs knowledge of it so a build agent doesn't cold-start on every run (re-deriving
 the stack, assuming wrong, producing work the PM must heavily correct — the north-star cost). It is the
-**inverse of [analyze-product-infra](/build-skills/analyze-product-infra.skill)** (which goes PRD →
-what the product *needs*): ingest-repo goes **code → what the product *is***. It emits a **draft** OKF
+**inverse** of deriving an infrastructure spec from a PRD (PRD → what the product *needs*):
+ingest-repo goes **code → what the product *is***. It emits a **draft** OKF
 reference layer + a repo registration and then **stops for PM approval**.
 
 > **Format:** three-level progressive disclosure ([SKILL-FORMAT](/skills/core/SKILL-FORMAT.md)). L1
@@ -101,18 +101,19 @@ reference layer + a repo registration and then **stops for PM approval**.
 - **`register_product_repo` semantics:** designed for provisioning output — here `app_surface`/
   `backend_model` are *observed*, a usage-only difference (no schema change); note it.
 - **B5 measurability:** the value thesis is "warm start → fewer corrections"; the first post-ingest
-  build run should retrieve these concepts (B5 > 0 for the tenant, via
-  [v_knowledge_reuse](/okf/products/pmos/references/metrics/v_knowledge_reuse.md) — now written by
-  get_okf_concepts FETCH). That real correction-delta, not the doc count, is the win.
+  build run should retrieve these concepts. That real correction-delta, not the doc count, is the
+  win — measure it as corrections on the first post-ingest run versus the cold-start baseline.
+  (The hosted `v_knowledge_reuse` view that automated this count went with the backend in D66.)
 
 ## Level 3 — references
 
-- The write path + PM gate: [okf-author](/build-skills/okf-author.skill) Mode B, [D37](/okf/products/pmos/adr/d37-tenant-okf-db-native.md).
+- The write path + PM gate: write the docs into the product's own repo as drafts and let the PM
+  approve them in PR review — the file-mode form of draft→approved. (D37's database-native tenant OKF
+  and its `save_okf_doc` tool were retired by [D66](/DECISIONS.md).)
 - The ledger method: [design-loop concept](/okf/core/concepts/design-loop.md),
   [design-reconcile](/skills/core/design-reconcile.skill), [watermelon-flag](/okf/core/concepts/watermelon-flag.md).
 - Extraction discipline: [source-to-concept](/skills/core/source-to-concept.skill).
-- Scan location: [D51](/okf/products/pmos/adr/d51-scan-location.md). Registry:
-  [register_product_repo](/okf/products/pmos/references/mcp-tools/register_product_repo.md),
-  [product_repos](/okf/products/pmos/data-model/product_repos.md).
-- Sibling on-ramps: [analyze-product-infra](/build-skills/analyze-product-infra.skill),
-  [product-onboarding playbook](/okf/core/playbooks/product-onboarding.md).
+- Scan location: [D51](/okf/products/pmos/adr/d51-scan-location.md). There is no longer a central
+  registry to register into — the hosted `product_repos` table and `register_product_repo` went with
+  the backend (D66); the product repo that carries the kit IS the registration.
+- Sibling on-ramp: [product-onboarding playbook](/okf/core/playbooks/product-onboarding.md).

package/payload/skills-native/harness-refine/SKILL.md

@@ -82,8 +82,9 @@ field's "agents improving their own tools" loop while staying at the **L3 ceilin
   bounding decision [D47](/okf/products/pmos/adr/d47-self-refining-harness.md).
 - The sibling detect→draft→PR loop: [okf-author](/build-skills/okf-author.skill),
   [D42](/okf/products/pmos/adr/d42-okf-author-on-demand.md).
-- The evidence surfaces: [v_friction_recurrence](/okf/products/pmos/references/metrics/v_friction_recurrence.md),
-  [v_context_budget](/okf/products/pmos/references/metrics/v_context_budget.md),
+- The evidence surfaces: recurring friction themes and self-reported context pressure, read from
+  file-mode state ([discoveries.md](/discoveries.md) and `runs.jsonl`; the hosted
+  `v_friction_recurrence` / `v_context_budget` views went with the backend in D66) plus
   [eval-calibration.md](/planning/evals/eval-calibration.md).
 - The cadence it serves: [D23](/okf/products/pmos/adr/d23-quarterly-cadence.md) (harness-assumption
   review); the altitude standard: [agent-harness](/okf/core/concepts/agent-harness.md).

package/payload/skills-native/ingest-repo/SKILL.md

@@ -15,8 +15,8 @@ metadata:
 This skill is the **existing-repo on-ramp**: a PM arrives with a product that already ships and already
 has a repo, and PMOS needs knowledge of it so a build agent doesn't cold-start on every run (re-deriving
 the stack, assuming wrong, producing work the PM must heavily correct — the north-star cost). It is the
-**inverse of [analyze-product-infra](/build-skills/analyze-product-infra.skill)** (which goes PRD →
-what the product *needs*): ingest-repo goes **code → what the product *is***. It emits a **draft** OKF
+**inverse** of deriving an infrastructure spec from a PRD (PRD → what the product *needs*):
+ingest-repo goes **code → what the product *is***. It emits a **draft** OKF
 reference layer + a repo registration and then **stops for PM approval**.
 
 > **Format:** three-level progressive disclosure ([SKILL-FORMAT](/skills/core/SKILL-FORMAT.md)). L1
@@ -103,18 +103,19 @@ reference layer + a repo registration and then **stops for PM approval**.
 - **`register_product_repo` semantics:** designed for provisioning output — here `app_surface`/
   `backend_model` are *observed*, a usage-only difference (no schema change); note it.
 - **B5 measurability:** the value thesis is "warm start → fewer corrections"; the first post-ingest
-  build run should retrieve these concepts (B5 > 0 for the tenant, via
-  [v_knowledge_reuse](/okf/products/pmos/references/metrics/v_knowledge_reuse.md) — now written by
-  get_okf_concepts FETCH). That real correction-delta, not the doc count, is the win.
+  build run should retrieve these concepts. That real correction-delta, not the doc count, is the
+  win — measure it as corrections on the first post-ingest run versus the cold-start baseline.
+  (The hosted `v_knowledge_reuse` view that automated this count went with the backend in D66.)
 
 ## Level 3 — references
 
-- The write path + PM gate: [okf-author](/build-skills/okf-author.skill) Mode B, [D37](/okf/products/pmos/adr/d37-tenant-okf-db-native.md).
+- The write path + PM gate: write the docs into the product's own repo as drafts and let the PM
+  approve them in PR review — the file-mode form of draft→approved. (D37's database-native tenant OKF
+  and its `save_okf_doc` tool were retired by [D66](/DECISIONS.md).)
 - The ledger method: [design-loop concept](/okf/core/concepts/design-loop.md),
   [design-reconcile](/skills/core/design-reconcile.skill), [watermelon-flag](/okf/core/concepts/watermelon-flag.md).
 - Extraction discipline: [source-to-concept](/skills/core/source-to-concept.skill).
-- Scan location: [D51](/okf/products/pmos/adr/d51-scan-location.md). Registry:
-  [register_product_repo](/okf/products/pmos/references/mcp-tools/register_product_repo.md),
-  [product_repos](/okf/products/pmos/data-model/product_repos.md).
-- Sibling on-ramps: [analyze-product-infra](/build-skills/analyze-product-infra.skill),
-  [product-onboarding playbook](/okf/core/playbooks/product-onboarding.md).
+- Scan location: [D51](/okf/products/pmos/adr/d51-scan-location.md). There is no longer a central
+  registry to register into — the hosted `product_repos` table and `register_product_repo` went with
+  the backend (D66); the product repo that carries the kit IS the registration.
+- Sibling on-ramp: [product-onboarding playbook](/okf/core/playbooks/product-onboarding.md).

package/workspace/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "pmos-workspace",
-  "version": "0.28.0",
+  "version": "0.33.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "pmos-workspace",
-      "version": "0.28.0",
+      "version": "0.33.0",
       "license": "MIT",
       "dependencies": {
         "@xterm/addon-fit": "^0.11.0",

package/workspace/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pmos-workspace",
-  "version": "0.32.0",
+  "version": "0.33.0",
   "private": true,
   "description": "PMOS Terminal Workspace — local companion hosting real PTYs beside the library and gates (D62)",
   "license": "MIT",