create-pmos 0.33.0 → 0.34.0

package/README.md

@@ -232,6 +232,14 @@ 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.
@@ -363,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.33.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@51a8275
-assembled: 2026-08-06
+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/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-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/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.json

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