create-pmos 0.32.0 → 0.34.0

package/README.md

@@ -232,6 +232,25 @@ 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.34.0
+
+**A feature this README advertised for fifteen releases and never shipped.** Run `npx create-pmos@latest workspace`; the version bump means an existing install auto-upgrades.
+
+- **The session chooser now shows the agent's last words.** It has been listed under "What's new in 0.19.0" since that release and never rendered once. The chooser read `doing` off each session row; the rows carry `lastWords`, and the server mapped between the two only on the path the *pane* uses, not the path the *chooser* uses. So the line was always blank. If you are on 0.19.0 through 0.33.0, that one line was missing from the chooser and nothing else on that list was affected.
+- **How it was found, and why that matters more than the fix.** An independent evaluation of the original run — commissioned because that run had been merged and published without ever passing a Review Gate — drove a real browser against the shipped code and measured the field. The test that was supposed to cover this passed the whole time: it handed the function a hand-written row with a literal `doing` key that no real row has, so it tested a passthrough rather than the feature. The new test uses the wire shape and asserts the key is absent, so a rename on the server cannot quietly re-break it while the suite stays green.
+- **Known broken, and not fixed here: `end it` in the chooser.** In a freshly opened window with no terminal tab yet, the chooser is populated over HTTP while the terminal socket is still closed, so clicking `end it` **silently does nothing** — the button disarms as though it worked and the session keeps running. It has no test coverage anywhere. It is named here rather than left for you to discover. `open it` and `＋ start another session here anyway` are unaffected.
+
+## 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.
@@ -352,8 +371,10 @@ Refreshes the skills, concepts, and scripts only. Your records — `state/`, `pl
 - **Opening a long document no longer scrolls the whole window.** Scrolling a document in the right panel moved the entire interface — the top bar slid away, the status bar rose from below — while the panel's own scrollbar never engaged. Every panel now scrolls inside itself and the app frame never moves. (If you are curious: the shell's middle row was written `1fr`, which is `minmax(auto, 1fr)`, so a tall document enlarged the row rather than overflowing it. Every style involved read as correct, which is why it survived review.)
 - **`＋ session` now asks before it starts one, when the checkout is already busy.** It used to start the session and *then* tell you how many others were in there — a count arriving after the decision, naming something you cannot act on. Now you get a chooser first, listing every session in that checkout.
 - **It says what each one is.** Its name, its agent, the same word the sidebar uses (`working` · `quiet 12m` · `needs you` · `maybe blocked`), the agent's own last words, and who holds the writer claim.
+  - **Correction (0.34.0):** the last-words line was advertised here from 0.19.0 and **never rendered** — the chooser read a field name the session rows do not carry, so it was always blank. Fixed in 0.34.0; if you are on any version from 0.19.0 to 0.33.0, that one line was missing and nothing else on this list was affected.
 - **…and what ending it would cost, without over-claiming.** Only `needs you` reads as settled — its turn finished and it is waiting on you. `working` says output is arriving right now. `quiet` and `maybe blocked` say, in as many words, that the workspace *cannot tell* a finished turn from a permission prompt from a stuck tool. A confident "safe to end" that discarded a running turn would be worse than no reading at all.
 - **You can take the running session instead of making another.** `open it` attaches a tab to it and starts nothing. `end it` is there too — the first click arms it and names what it will end, the second does it. `＋ start another session here anyway` is always one click: being told is never being blocked, and no session is ever refused because another is there.
+  - **Correction (0.34.0):** `end it` does not work reliably and is being repaired. In a freshly opened window with no terminal tab yet, the chooser is populated over HTTP while the terminal socket is still closed, so the click **silently does nothing** — the button disarms as though it had worked and the session keeps running. If you use it, confirm in the sidebar that the session actually ended. `open it` and `start another anyway` are unaffected.
 - **The same detail is written into the new session's scrollback**, so scrolling back tomorrow answers the same question the chooser did.
 
 ## What's new in 0.18.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-pmos",
-  "version": "0.32.0",
+  "version": "0.34.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@1313507
+assembled: 2026-08-07
 mode: vendor

package/payload/okf/core/concepts/index.md

@@ -1,7 +1,6 @@
 # core/concepts — Index
 
-OKF reserved file (no frontmatter). Directory listing for progressive disclosure — read this
-to pick concepts, then fetch the file(s) you need.
+OKF reserved file (no frontmatter). Directory listing for progressive disclosure — read this to pick concepts, then fetch the file(s) you need.
 
 - [agent-harness](agent-harness.md) — Everything wrapping the model that lets it finish work — and the Summary Gate, the input gate that compresses prior-session context into essential state.
 - [control-plane](control-plane.md) — What it means for PMOS to be a control plane — it orchestrates, specs, evaluates, and routes agent work rather than generating production code itself.
@@ -18,4 +17,5 @@ to pick concepts, then fetch the file(s) you need.
 - [product-slug-convention](product-slug-convention.md) — The rules for product_slug — the stable lowercase identifier that scopes products across OKF namespaces, planning artifacts, and agent records.
 - [sdlc-loop](sdlc-loop.md) — The closed agent-driven software development lifecycle PMOS orchestrates — spec, contract, build, evaluate, accept, learn — and how it loops.
 - [self-refining-harness](self-refining-harness.md) — The pattern where the harness improves from its own run evidence (evals, friction, calibration) via a detect → draft → PM-gate loop, bounded at the L3 ceiling — never L4 self-mutation.
+- [simplified-technical-english](simplified-technical-english.md) — ASD-STE100: the controlled-language standard (53 rules / 9 sections + a ~900-word one-meaning dictionary), what it deliberately does not cover, and why its register boundary matters to any house adoption.
 - [watermelon-flag](watermelon-flag.md) — A status that reads green on automated metrics but is red underneath on strategic alignment — and silent drift, the L4 failure mode it signals.

package/payload/okf/core/concepts/simplified-technical-english.md

@@ -0,0 +1,74 @@
+---
+type: Concept
+title: "ASD-STE100 Simplified Technical English"
+description: The controlled-language standard for technical documentation — 53 writing rules in 9 sections plus a ~900-word controlled dictionary, owned by ASD. What it is, what it constrains, what it deliberately does not cover, and why its scope boundary matters to anyone adopting it as a house standard.
+tags: [writing, controlled-language, technical-writing, standards, ste, documentation]
+timestamp: 2026-07-30
+---
+
+# ASD-STE100 Simplified Technical English
+
+**Situating context:** Extracted from the free official Issue 9 specification (2025-01-15) and the STEMG's own FAQ during the [ste-house-standard-spike](/planning/prd/ste-house-standard-spike.md) discovery spike, which asked whether STE should become the standard for PMOS output. This concept holds the durable half — what the standard *is*. The PMOS-specific adoption question, its scope boundary, and the enforcement design live in the spike brief, not here.
+
+## What it is
+
+**ASD-STE100 Simplified Technical English (STE)** is a *controlled natural language*: a restricted subset of English defined by an explicit rule set and an explicit approved vocabulary. It exists to make technical documentation unambiguous on first read — originally for aircraft maintenance manuals read by mechanics whose first language is not English.
+
+It has exactly two parts:
+
+| Part | Content | Size (Issue 9) |
+|---|---|---|
+| **Part 1 — Writing rules** | 53 numbered rules in 9 sections, plus 8 general recommendations (GR-1…GR-8) | 53 rules / 9 sections |
+| **Part 2 — Dictionary** | Approved words, each with **one meaning and one part of speech**, plus unapproved words with their approved replacements | ≈900 approved words |
+
+The dictionary is the expensive half and the reason STE is a *controlled* language rather than a style guide: `test` is approved as a noun only, `oil` as a noun only, and a writer who wants the verb must use the approved one. Words outside the dictionary are legal only as **technical nouns** or **technical verbs** — domain terms admitted under rules 1.5–1.13, which is how STE stays usable in a field it has never seen.
+
+## The nine sections
+
+Rule statements below are **paraphrased**, with rule numbers as pointers into the specification. The document is ASD copyright and is not reproduced here (see *Licensing* below).
+
+1. **Words (1.1–1.14).** Use only approved words, each as its listed part of speech and listed meaning, in its approved verb/adjective forms (1.1–1.4). Domain terms enter as technical nouns (1.5–1.11) or technical verbs (1.12–1.13): keep them short, never use a technical noun as a verb or a technical verb as a noun, never two names for one thing, no slang/regional/jargon terms. American English spelling unless a directive says otherwise (1.14).
+2. **Multi-word nouns (2.1–2.2).** At most three words in a noun cluster; a longer term is written in full once and then shortened or hyphenated.
+3. **Verbs (3.1–3.7).** Only the dictionary's verb forms (3.1), and only infinitive, imperative, simple present, simple past, simple future, and past participle-as-adjective (3.2–3.3). No auxiliary stacks / complex constructions (3.4). `-ing` only inside a technical noun (3.5). **Active voice** — passive only in descriptive text when the agent is genuinely unknown (3.6). Describe an action with an approved verb, not a nominalization (3.7).
+4. **Sentences (4.1–4.5).** Short and clear (4.1). Never drop words or use contractions to shorten (4.2). Vertical lists for complex material (4.3). Explicit connecting words between related sentences (4.4). Keep articles and demonstratives in front of nouns (4.5).
+5. **Procedural writing (5.1–5.5).** **Maximum 20 words per sentence** (5.1). One instruction per sentence unless the actions are simultaneous (5.2). Imperative form (5.3). A precondition is stated first, then comma, then the command (5.4). Notes inform; they never instruct (5.5).
+6. **Descriptive writing (6.1–6.6).** Information gradually (6.1); key words/phrases carry the structure (6.2); **maximum 25 words per sentence** (6.3); paragraphs group related information (6.4), **one topic each** (6.5), **at most six sentences each** (6.6). The imperative is not permitted here — description is not instruction.
+7. **Safety instructions (7.1–7.3).** Name the risk level with the applicable word ("warning", "caution") (7.1); open with a clear command or condition (7.2); explain the risk or the consequence (7.3).
+8. **Punctuation and word count (8.1–8.7).** All standard punctuation **except the semicolon** (8.1); hyphens join directly-related words (8.2); parentheses for references, identifiers, work steps, abbreviations (8.3). Then the counting rules that make the length limits decidable: in a vertical list a colon ends a sentence (8.4); a parenthetical counts as one word (8.5); numbers, numbers-with-units, abbreviations, alphanumeric identifiers and proper nouns count as one word each (8.6); a hyphenated word counts as one (8.7).
+9. **Writing practices (9.1–9.4) + GR-1…GR-8.** Restructure the sentence when word-for-word replacement fails (9.1); use approved words correctly (9.2); no invented phrasal verbs (9.3); consistent terminology and style (9.4). The general recommendations cover the conjunction "that", the preposition "with", pronoun use and antecedents (GR-3/GR-4), false friends, Latin abbreviations, and — new in Issue 9 — **inclusive language** (GR-7) and possessive form (GR-8).
+
+## What STE deliberately does not do
+
+The specification's own FAQ is unusually explicit about its boundaries, and this is the part most adopters miss:
+
+- **It does not regulate formatting** — typeface, numbering, lettering belong to a publications specification or style guide.
+- **It does not regulate abbreviations or units of measurement** — projects decide.
+- **It cannot be used alone.** In the FAQ's words: *"No. It is intended to be used with other applicable specifications for technical publications, style guides, and official directives. A high standard of professionalism is necessary to use STE correctly."*
+- **It is not general-purpose English.** STE targets maintenance and technical documentation. The STEMG's position is that STE's *principles* — short sentences, one topic per sentence, active voice — transfer to other writing; the full rule set and dictionary do not.
+- **No tool can certify compliance.** Checkers flag violations; they cannot convert non-STE text into STE, and the writer remains accountable.
+
+## The one-meaning trade
+
+STE's power and its cost are the same mechanism. Because every approved word has one meaning, ambiguity collapses — and so does nuance. The dictionary's recurring-errors list replaces `should` and `may` with `MUST`, and `shall` with `MUST`; `CAN`, `CANNOT`, `WILL` and `MUST` are approved, while `may`, `might`, `should` and `would` are not. That is correct for a maintenance manual, where a hedged instruction is a defect. It is destructive for text whose payload *is* graded confidence — a recommendation, an estimate, a risk statement — because STE's replacement converts a recommendation into an obligation and a possibility into a certainty. Adopting STE for such text does not make it clearer; it makes it more certain than the author was.
+
+This is the boundary any adoption must draw explicitly. It is also why STE splits **procedural** (section 5) from **descriptive** (section 6) writing and gives them different rules: it already recognizes that one register's rule is another register's error. Argumentative text — a decision record, a strategy memo, an evaluation verdict — is a third register the standard never addressed.
+
+## History, status, licensing
+
+- Originated 1986 as the *AECMA Simplified English Guide*, requested by the European airline industry for aircraft maintenance documentation; the name honors the ATA100 publications specification.
+- Maintained by the **Simplified Technical English Maintenance Group (STEMG)**, a working group of **ASD** (Aerospace, Security and Defence Industries Association of Europe), formed 1983.
+- **Issue 9, 2025-01-15** is current. Free of charge to anyone on request since Issue 6 (2013).
+- **Copyright is fully owned by ASD.** The document states that no reproduction or publication in whole or in part may be made without ASD's written authority; irrevocable free reproduction rights are granted only to named categories (ASD/AIA/AIAC/ICCAIA members and their customers, member-state Ministries of Defense, and similar). **Practical consequence:** an adopter outside those categories may apply and cite STE freely, but must not vendor the rule text or the dictionary into its own repository — reference it by rule number and link to the source.
+- Adoption has spread well beyond aerospace (machinery, automotive, electronics, medical, IT, and language services). Most non-aerospace organizations adopt the writing rules and skip the controlled dictionary, which is a partial adoption, not compliance.
+
+## Known limitations
+
+- **Correct application is hard.** It demands strong English *and* domain knowledge; research on STE adoption consistently finds writers apply it incorrectly without training.
+- **It is often misused as a substitute for a style guide** rather than a layer on top of one — the failure mode the FAQ answer above exists to prevent.
+- **A clean check is not a correct document.** STE-compliant prose that is factually wrong reads *more* authoritative than the sloppy version — a controlled language raises the confidence a reader places in the text without touching its truth.
+
+## Related
+
+- [output-eval](/okf/core/concepts/output-eval.md) — the three-tier gate any writing standard is graded through; a clean lint is a Quality-tier signal, never an Acceptance-tier one.
+- [okr-anti-optimism](/okf/core/concepts/okr-anti-optimism.md) — the reporting stance that STE's modal replacements would flatten; the reason the register boundary above is load-bearing in PMOS.
+- Sources: [asd-ste100.org](https://www.asd-ste100.org/) (specification + FAQ, free on request), [ASD](https://www.asd-europe.org/standards-specifications/simplified-technical-english/).

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/discovery.skill

@@ -32,9 +32,11 @@ fake rubric, or escaped the record entirely.
 
 ## Procedure
 
-1. **Anchor and create the initiative** with `type: discovery`
-   (`create_initiative({id, title, parent_kr, type: 'discovery'})`; file mode: `type: discovery`
-   in the initiative frontmatter).
+1. **Anchor and create the initiative** in the `discovery` lane.
+   - File mode: write `lane: discovery` in the initiative frontmatter.
+   - Do not write `type: discovery` there. `type` is D63's registry key, and its value is `Initiative`.
+   - Tool form: `create_initiative({id, title, parent_kr, type: 'discovery'})`. The argument keeps
+     its name. Read it as "record the equivalent in file-mode state" (AGENTS.md).
 1b. **Existing surface? Understand it first.** If answering the question honestly requires reading
    code that already exists, run an [explain-surface](/build-skills/explain-surface.skill) pass on
    that region — in a fresh context, **before** writing the brief. A spike aimed at a system the PM

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/discovery/SKILL.md

@@ -34,9 +34,11 @@ fake rubric, or escaped the record entirely.
 
 ## Procedure
 
-1. **Anchor and create the initiative** with `type: discovery`
-   (`create_initiative({id, title, parent_kr, type: 'discovery'})`; file mode: `type: discovery`
-   in the initiative frontmatter).
+1. **Anchor and create the initiative** in the `discovery` lane.
+   - File mode: write `lane: discovery` in the initiative frontmatter.
+   - Do not write `type: discovery` there. `type` is D63's registry key, and its value is `Initiative`.
+   - Tool form: `create_initiative({id, title, parent_kr, type: 'discovery'})`. The argument keeps
+     its name. Read it as "record the equivalent in file-mode state" (AGENTS.md).
 1b. **Existing surface? Understand it first.** If answering the question honestly requires reading
    code that already exists, run an [explain-surface](/build-skills/explain-surface.skill) pass on
    that region — in a fresh context, **before** writing the brief. A spike aimed at a system the PM

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/lib/tree-share.js

@@ -161,6 +161,20 @@ function endRisk(shown, quietMs) {
  * Everything here is either copied off the row or derived by `endRisk`; nothing is invented. In
  * particular `doing` is the agent's own last words as the sidebar already shows them, and it stays
  * null when the workspace could not read them rather than becoming a cheerful placeholder.
+ *
+ * ── IT READS BOTH FIELD NAMES, AND THAT IS THE FIX, NOT A CONVENIENCE ──────────────────────────
+ * This read `s.doing` alone. The server's `describePeer` maps `lastWords -> doing` before calling
+ * here, so the PANE was correct; the browser's `treePeersNow` feeds RAW `/api/sessions` rows
+ * straight through, and a wire row has no `doing` key at all — 21 keys, `lastWords` among them,
+ * `doing` absent. So `describeTenant(wireRow).doing` was ALWAYS null and the chooser never rendered
+ * the agent's last words. An independent pass proved it end to end in a real browser with
+ * `lastWords` populated, and `npm-pkg/README.md` had been shipping that feature to adopters as a
+ * claim since 0.19.0.
+ *
+ * The fix belongs HERE, in the one function both surfaces call, not in the browser adapter.
+ * Correcting the caller would have made the two agree today and left them free to diverge again the
+ * next time a row shape moves — which is exactly how this defect was born. One function, both field
+ * names, no adapter to forget.
  */
 function describeTenant(row, writerId) {
   const s = row || {};
@@ -172,7 +186,7 @@ function describeTenant(row, writerId) {
     agent: s.agent || null,
     shown,
     label: s.label || shown,
-    doing: s.doing || null,
+    doing: s.doing || s.lastWords || null,
     branch: s.branch || null,
     writer: !!(writerId && s.id === writerId),
     risk: endRisk(shown, s.quietMs),

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.34.0",
   "private": true,
   "description": "PMOS Terminal Workspace — local companion hosting real PTYs beside the library and gates (D62)",
   "license": "MIT",