create-pmos 0.33.0 → 0.36.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/bin/create-pmos.js

@@ -129,15 +129,27 @@ function workspaceOrDie() {
   }
 }
 
+// A spawn that never RAN is a failure, not a success: spawnSync's .status is null when the child
+// could not be spawned (r.error set — e.g. a broken global `pmos` shim after a partial uninstall;
+// onPath only proves resolvability, not runnability) or died on a signal. The old `.status || 0`
+// coerced both to exit 0, so a launch that launched nothing reported success to whatever invoked it.
+function launchStatus(r) {
+  if (r.error) {
+    console.error(`create-pmos: ERROR — launch failed: ${r.error.message}`);
+    return 1;
+  }
+  return r.status === null ? 1 : r.status;
+}
+
 function launchWorkspace(targetDir, viaGlobal) {
   if (viaGlobal && onPath('pmos')) {
     // `pmos` owns the whole lifecycle: start the server detached, open the browser on this repo.
-    return spawnSync('pmos', [targetDir], { stdio: 'inherit', shell: process.platform === 'win32' }).status || 0;
+    return launchStatus(spawnSync('pmos', [targetDir], { stdio: 'inherit', shell: process.platform === 'win32' }));
   }
   // Fallback: run the bundled launcher directly. Its ensureInstalled() pulls runtime deps on first run.
   console.log('Launching from the bundled copy (the `pmos` command is not on PATH).');
-  return spawnSync(process.execPath, [path.join(WORKSPACE, 'bin', 'pmos.js'), targetDir],
-    { stdio: 'inherit', env: process.env }).status || 0;
+  return launchStatus(spawnSync(process.execPath, [path.join(WORKSPACE, 'bin', 'pmos.js'), targetDir],
+    { stdio: 'inherit', env: process.env }));
 }
 
 // Compare two dotted numeric versions. Returns -1 if a<b, 0 if equal, 1 if a>b. Missing/non-numeric

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-pmos",
-  "version": "0.33.0",
+  "version": "0.36.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@f04854e
+assembled: 2026-08-08
 mode: vendor

package/payload/okf/core/concepts/agent-harness.md

@@ -24,12 +24,12 @@ The harness includes:
 - **Knowledge** — the [OKF bundle](/okf/core/concepts/okf-governance.md): concepts, templates,
   playbooks.
 - **Skills** — procedural competence loaded on demand
-  ([SKILL-FORMAT](/skills/core/SKILL-FORMAT.md)).
+  ([SKILL-FORMAT](/skills/SKILL-FORMAT.md)).
 - **Tools / MCP** — the [ACI surface](/build-skills/MCP-SPEC.md) the agent acts through.
 - **Sandboxes** — where work runs safely.
 - **Orchestration** — sequencing, concurrency, routing.
 - **Guardrails** — the [three-tier eval gate](/okf/core/concepts/output-eval.md), kill conditions.
-- **Observability** — `agent_runs`, [discoveries.md](/discoveries.md), transcript review.
+- **Observability** — `agent_runs`, [discoveries.md](/state/discoveries.md), transcript review.
 
 **PMOS builds the harness, not the app.** Improving any harness element improves every future run —
 that is the leverage the [control plane](/okf/core/concepts/control-plane.md) exists to capture.

package/payload/okf/core/concepts/design-loop.md

@@ -29,12 +29,12 @@ An initiative with a user-facing surface runs four legs *inside* Build:
                                           build, web-ci)                library back)
 ```
 
-1. **Brief** — the [design-brief skill](/skills/core/design-brief.skill) writes the context handoff: what
+1. **Brief** — the [design-brief skill](/skills/design-brief.skill) writes the context handoff: what
    to design and the hard, presentation-only constraints, each surface tied to a real data source. It is to
-   design what the [PRD](/skills/core/prd.skill) is to build.
+   design what the [PRD](/skills/prd.skill) is to build.
 2. **Design** — the design is made in an external design surface (PMOS-self uses claude.ai/design;
    any capable design surface fits — external to this repo).
-3. **Reconcile + build** — the [design-reconcile skill](/skills/core/design-reconcile.skill) classifies
+3. **Reconcile + build** — the [design-reconcile skill](/skills/design-reconcile.skill) classifies
    every surface against **the product's capability ledger** and the PM signs off before any code; then the
    design is built into the product's app on its design system, verified by the product's CI. (For PMOS's own
    app the ledger is [web-capability-ledger.md](/planning/web-capability-ledger.md), the system is D38, and
@@ -98,8 +98,8 @@ time such that the board hides real "designed-but-not-built" state, the lighter
 
 The loop is a **method**; PMOS's own app is just its first instance. What is **shared** vs **per-product** (D50):
 
-- **Shared, authored once, read by every PM** — this concept, the [design-brief](/skills/core/design-brief.skill)
-  and [design-reconcile](/skills/core/design-reconcile.skill) skills, the
+- **Shared, authored once, read by every PM** — this concept, the [design-brief](/skills/design-brief.skill)
+  and [design-reconcile](/skills/design-reconcile.skill) skills, the
   [design-brief template](/okf/core/templates/design-brief-template.md), and the **generic dimensions** of the
   [design-fidelity rubric](/planning/evals/design-fidelity-eval-rubric.md). These live in PMOS-self's knowledge
   and are already reachable by tenants (repo-managed OKF rows are shared-read, D37; the `skills` table is

package/payload/okf/core/concepts/eval-driven-pm.md

@@ -52,7 +52,7 @@ this the right thing?* — and on whether the rubric itself was right.
 ## How it shapes the loop
 
 - **Spec stage** authors the rubric alongside the PRD — the
-  [eval-rubric skill](/skills/core/eval-rubric.skill) and [prd skill](/skills/core/prd.skill) are
+  [eval-rubric skill](/skills/eval-rubric.skill) and [prd skill](/skills/prd.skill) are
   paired for this reason.
 - **Contract stage** turns the rubric into agreed, testable done-criteria the generator and evaluator
   both sign off on before work starts.

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/okr-anti-optimism.md

@@ -36,7 +36,7 @@ report the more pessimistic reading and make the uncertainty explicit.
 4. **Name the gap to intent.** Where the work has bent away from the parent objective, say so
    explicitly, even if every individual run passed.
 5. **Surface friction.** Anything that fought the harness goes to
-   [discoveries.md](/discoveries.md) tagged `#friction`, not buried in a success summary.
+   [discoveries.md](/state/discoveries.md) tagged `#friction`, not buried in a success summary.
 
 ## Why this is structural, not cultural
 

package/payload/okf/core/concepts/okr-tree.md

@@ -29,8 +29,8 @@ Objective (qualitative, directional — the "what we want to be true")
 - **Key Result** — a quantitative, measurable outcome that proves the objective is being met.
   Each objective has 2–5 KRs. *"Human correction rate per agent run < 0.5 by end of Q3."*
 - **Initiative** — a concrete body of work expected to move one or more KRs. Each initiative owns a
-  PRD ([prd skill](/skills/core/prd.skill)) and an eval rubric
-  ([eval-rubric skill](/skills/core/eval-rubric.skill)).
+  PRD ([prd skill](/skills/prd.skill)) and an eval rubric
+  ([eval-rubric skill](/skills/eval-rubric.skill)).
 - **Agent run** — the leaf: one execution against an initiative's pre-run contract, logged to
   `agent_runs`.
 

package/payload/okf/core/concepts/output-eval.md

@@ -10,7 +10,7 @@ timestamp: 2026-06-28
 
 **Situating context:** Every turn of the [SDLC loop](/okf/core/concepts/sdlc-loop.md) ends by
 judging what an agent produced. This concept defines the three-tier gate that judgment runs through,
-so the [eval-rubric skill](/skills/core/eval-rubric.skill), AGENTS.md, and the PM all use the same
+so the [eval-rubric skill](/skills/eval-rubric.skill), AGENTS.md, and the PM all use the same
 vocabulary. It informs where automation stops and human judgment begins.
 
 ## The three tiers
@@ -72,7 +72,7 @@ green Review Gate auto-accept — removes the only structural defense against dr
   call sequences.
 - **Weighted, with partial credit:** the Review Gate scores weighted dimensions and totals against a
   threshold; it is not all-or-nothing. (See the
-  [eval-rubric skill](/skills/core/eval-rubric.skill) and
+  [eval-rubric skill](/skills/eval-rubric.skill) and
   [template](/okf/core/templates/eval-rubric-template.md).)
 
 ## Relationship to autonomy

package/payload/okf/core/concepts/sdlc-loop.md

@@ -26,7 +26,7 @@ PMOS drives a closed lifecycle. Each turn of the loop moves one initiative throu
                                                              Gate)
 ```
 
-1. **Spec** — the initiative gets a PRD via the [prd skill](/skills/core/prd.skill). The PRD says
+1. **Spec** — the initiative gets a PRD via the [prd skill](/skills/prd.skill). The PRD says
    what to build and why, anchored to a KR in the [OKR tree](/okf/core/concepts/okr-tree.md) —
    or, for maintenance work, a declared [health budget](/okf/core/concepts/health-anchors.md) (D59).
 2. **Contract** — generator and evaluator agree a **pre-run contract**: testable done-criteria,

package/payload/okf/core/concepts/self-refining-harness.md

@@ -14,7 +14,7 @@ transcripts, `eval-calibration.md`). What it lacked was a named pattern — and
 that evidence back into harness improvements. This concept names it. It was extracted from the
 2026-07-01 "Agent = Model + Harness" research (which found the field converging on *harness engineering*
 as its own discipline, and "agents improving their own tools" as its highest-leverage loop) and it
-informs the [harness-refine skill](/build-skills/harness-refine.skill), [D47](/okf/products/pmos/adr/d47-self-refining-harness.md),
+informs the [harness-refine skill](/skills/harness-refine.skill), [D47](/okf/products/pmos/adr/d47-self-refining-harness.md),
 and the [D23](/okf/products/pmos/adr/d23-quarterly-cadence.md) quarterly harness review.
 
 ## The pattern
@@ -36,7 +36,7 @@ one level up — applied to the harness itself:
 1. **Detect** — a deterministic signal shows a gap: a `v_friction_recurrence` theme with no resolving
    decision, a recurring `evals` defect class, a persistent `eval-calibration.md` disagreement, a
    context-budget signal.
-2. **Draft** — the [harness-refine skill](/build-skills/harness-refine.skill) reads that evidence and
+2. **Draft** — the [harness-refine skill](/skills/harness-refine.skill) reads that evidence and
    drafts concrete, **evidence-cited** edits, each mapped to one artifact: an MCP tool description
    ([ACI](/build-skills/MCP-SPEC.md), D19), a skill body, an OKF concept, or an `AGENTS.md` heuristic.
    It **prunes** as readily as it adds (D23 / [prune the scaffolding](/PRINCIPLES.md)).
@@ -73,5 +73,5 @@ sources.
 - [control-plane](/okf/core/concepts/control-plane.md) — why PMOS edits the harness, not the app.
 - [output-eval](/okf/core/concepts/output-eval.md) — the Acceptance Gate this loop submits to.
 - [watermelon-flag](/okf/core/concepts/watermelon-flag.md) — the L4 failure mode the L3 bounds prevent.
-- Skill: [harness-refine](/build-skills/harness-refine.skill). Decision:
+- Skill: [harness-refine](/skills/harness-refine.skill). Decision:
   [D47](/okf/products/pmos/adr/d47-self-refining-harness.md).

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/okf/core/templates/content-brief-template.md

@@ -10,7 +10,7 @@ timestamp: 2026-07-18
 
 **Situating context:** Authored with [D58](/okf/products/pmos/adr/d58-builder-profiles.md) as the
 content lane's spec artifact — the contract copy work is drafted and judged against. The
-[copywriting skill](/skills/domains/copywriting.skill) instantiates it. A rubric is recommended,
+[copywriting skill](/skills/copywriting.skill) instantiates it. A rubric is recommended,
 not required (PM call at D58 ratification); the optional section below is the recommended shape.
 
 > Usage: replace every `<…>` placeholder. An empty audience or an unsourced claim list means the

package/payload/okf/core/templates/design-brief-template.md

@@ -9,7 +9,7 @@ timestamp: 2026-07-01
 # Design Brief Template
 
 **Situating context:** This template is the canonical scaffold the
-[design-brief skill](/skills/core/design-brief.skill) instantiates — leg 1 of the
+[design-brief skill](/skills/design-brief.skill) instantiates — leg 1 of the
 [design loop](/okf/core/concepts/design-loop.md). It is to design what the
 [PRD template](/okf/core/templates/prd-template.md) is to build: the shared definition before work starts.
 Copy the block into `/planning/design/<slug>-design-brief.md` and fill it; the copy is an operational

package/payload/okf/core/templates/eval-rubric-template.md

@@ -9,7 +9,7 @@ timestamp: 2026-06-28
 # Eval Rubric Template
 
 **Situating context:** This template was authored as the canonical scaffold the
-[eval-rubric skill](/skills/core/eval-rubric.skill) instantiates, so every rubric uses the same
+[eval-rubric skill](/skills/eval-rubric.skill) instantiates, so every rubric uses the same
 weighted-scoring math and carries its sprint contract. Copy the block into
 `/planning/evals/<slug>-eval-rubric.md` and fill it; the copy is operational and does not live in the
 OKF bundle.

package/payload/okf/core/templates/log.md

@@ -3,7 +3,7 @@
 OKF reserved file (no frontmatter). Change history, newest first, ISO 8601 dates.
 
 ## 2026-07-01
-- Added `design-brief-template` — the design-brief scaffold (leg 1 of the design loop, D48), instantiated by the [design-brief skill](/skills/core/design-brief.skill). Distilled from the first instance, `planning/design-brief.md`.
+- Added `design-brief-template` — the design-brief scaffold (leg 1 of the design loop, D48), instantiated by the [design-brief skill](/skills/design-brief.skill). Distilled from the first instance, `planning/design-brief.md`.
 
 ## 2026-06-29
 - Creation — per-folder index/log added (OKF recursive progressive disclosure; D29 reversal direction).

package/payload/okf/core/templates/prd-template.md

@@ -9,7 +9,7 @@ timestamp: 2026-06-28
 # PRD Template
 
 **Situating context:** This template was authored as the canonical scaffold the
-[prd skill](/skills/core/prd.skill) instantiates, so every PRD in PMOS has the same shape and the
+[prd skill](/skills/prd.skill) instantiates, so every PRD in PMOS has the same shape and the
 same anchoring discipline. Copy the block below into `/planning/prd/<slug>-prd.md` and fill it; the
 copy is an operational instance and does not live in the OKF bundle.
 

package/payload/okf/core/templates/spike-brief-template.md

@@ -11,7 +11,7 @@ timestamp: 2026-07-17
 **Situating context:** Authored with [D56](/okf/products/pmos/adr/d56-initiative-lanes.md) as the
 discovery lane's spec artifact, resolving the eval-first paradox the SDLC stress test named: a
 prototype exists to *discover* its own done-criteria, so the lane contracts on a **question and a
-timebox**, not on requirements. The [discovery skill](/skills/core/discovery.skill) instantiates
+timebox**, not on requirements. The [discovery skill](/skills/discovery.skill) instantiates
 this template. Copy the block below into `/planning/prd/<id>-spike.md` and fill; the copy is an
 operational instance, not OKF knowledge.
 

package/payload/scripts/frontier.sh

@@ -18,8 +18,12 @@ DIR="${1:-state/tickets}"
 # --- field readers (frontmatter only: stop at the closing --- fence) ----------------------------
 fm() { awk 'NR>1 && /^---[[:space:]]*$/{exit} {print}' "$1"; }   # lines between the opening and closing ---
 field() { printf '%s\n' "$1" | sed -n "s/^$2:[[:space:]]*//p" | head -1 | sed 's/^["'\'']//;s/["'\'']$//;s/[[:space:]]*$//'; }
-# blocked_by is an inline list "[\"002\", \"005\"]"; extract the bare ids (digits) in order.
-blockers() { printf '%s\n' "$1" | sed -n 's/^blocked_by:[[:space:]]*//p' | head -1 | grep -oE '[0-9]+' || true; }
+# blocked_by is an inline list "[\"002\", \"005\"]"; extract the bare ids in order. Ids are NOT
+# assumed numeric — idof below derives slug ids (an explicit `id:` field, or a digitless filename),
+# and a digits-only extraction silently DROPPED every such blocker, listing a blocked ticket as
+# workable (fail-open). Every non-empty token survives instead: a token that matches no done ticket
+# keeps the ticket off the frontier, so a malformed or unknown blocker fails CLOSED.
+blockers() { printf '%s\n' "$1" | sed -n 's/^blocked_by:[[:space:]]*//p' | head -1 | sed 's/[][]//g' | tr ',' '\n' | sed 's/["'\'']//g' | tr -d ' \t\r' | grep -v '^$' || true; }
 # derive an id: explicit `id:` field, else the leading NNN of the filename.
 idof() { local i; i="$(field "$1" id)"; [ -n "$i" ] && { printf '%s' "$i"; return; }; basename "$2" | grep -oE '^[0-9]+' || basename "$2" .md; }
 

package/payload/scripts/gate-initiative.sh

@@ -49,9 +49,30 @@ printf '%s' "$id" | grep -qE '^[a-z0-9][a-z0-9._-]*$' || fail "Initiative id '$i
 init_file="$KIT_ROOT/state/initiatives/$id.md"
 [ -f "$init_file" ] || fail "No initiative file at $init_file. Create it first — an initiative must exist before its PR. This is the loop rule the gate enforces."
 
-frontval() { # frontval <key> — first 'key: value' line in the file, value trimmed.
-  # `|| true`: an absent key must fall through to the explicit fail() below, not abort silently.
-  { grep -m1 -E "^$1:[[:space:]]*" "$init_file" || true; } | sed -E "s/^$1:[[:space:]]*//" | tr -d '\r' | sed -E 's/[[:space:]]+$//'
+frontval() { # frontval <key> — the key's value from the LEADING frontmatter block, trimmed.
+  # The LEADING block only, mirroring workflow-state.js / file-mode-parse.js / metrics.py: the gate
+  # used to grep the whole file, so a body line starting `parent_kr: ...` (a pasted example) could
+  # fake the declaration the gate exists to check. Same rules as the canonical parsers: an opening
+  # --- fence (before any key) is skipped and the next --- ends the block; blank lines are skipped;
+  # the first non-key line ends the block (fenceless records, e.g. the kit-ci smoke fixture, keep
+  # parsing from line 1); first value wins; ONE pair of surrounding double quotes is stripped. An
+  # absent key prints nothing and falls through to the explicit fail() below.
+  awk -v want="$1" '
+    /^---/ { if (fence || seen) exit; fence = 1; next }
+    /^[[:space:]]*$/ { next }
+    {
+      i = index($0, ":")
+      key = (i > 0) ? substr($0, 1, i - 1) : ""
+      if (key !~ /^[a-z_]+$/) exit
+      seen = 1
+      if (key != want) next
+      val = substr($0, i + 1)
+      gsub(/\r/, "", val)
+      gsub(/^[[:space:]]+|[[:space:]]+$/, "", val)
+      if (length(val) >= 2 && val ~ /^".*"$/) val = substr(val, 2, length(val) - 2)
+      print val
+      exit
+    }' "$init_file"
 }
 prd="$(frontval prd_path)"
 rubric="$(frontval rubric_path)"

package/payload/scripts/metrics.py

@@ -56,14 +56,30 @@ def leading_frontmatter(path):
     body line, the loop breaks, and every key below it is dropped. Agreement with the JS parser was
     never sufficient to catch this — both carried the same wrong regex, so the fixture compared two
     identical mistakes and passed. See kit/fixtures/state/initiatives/epsilon-empty-value.md.
+
+    The closing --- fence is TERMINAL, never skipped: stepping over it absorbed a key-shaped first
+    body line into the block (zeta-fence-fake.md pins this). Fenceless files parse from line 1 and
+    stop at the first non-key line. First value wins, and ONE pair of surrounding double quotes is
+    stripped, exactly as the JS parsers do (eta-quoted-value.md pins the quoted case).
     """
     fm = {}
+    fence_open = False
     with open(path, encoding="utf-8") as fh:
-        for line in fh:
-            m = re.match(r"^([a-z_]+):\s*(.*?)\s*$", line.rstrip("\n"))
+        for raw in fh:
+            line = raw.rstrip("\n")
+            if line.startswith("---"):
+                # Only the FIRST ---, before any key, opens the block; every later --- ends it.
+                if fence_open or fm:
+                    break
+                fence_open = True
+                continue
+            m = re.match(r"^([a-z_]+):\s*(.*?)\s*$", line)
             if m:
-                fm.setdefault(m.group(1), m.group(2))
-            elif line.strip() and not line.startswith("---"):
+                val = m.group(2)
+                if len(val) >= 2 and val.startswith('"') and val.endswith('"'):
+                    val = val[1:-1]
+                fm.setdefault(m.group(1), val)
+            elif line.strip():
                 break  # frontmatter is the LEADING block only
     return fm
 

package/payload/scripts/read-jsonl.js

@@ -0,0 +1,53 @@
+'use strict';
+/*
+ * scripts/read-jsonl.js — THE JSONL reader for the scripts/ checkers and the workflow engine.
+ *
+ * Six near-identical readers grew here, with three different torn-line contracts, and the repo's
+ * own comments record the cost twice: a silently-dropped torn line re-opened a verified entry
+ * (check-verify-queue.js) and made an accepted initiative read as never accepted (workflow-state.js).
+ * Each new checker re-decided the torn-line question from scratch and got it wrong at least twice.
+ * One reader, one contract — the strictest one found:
+ *
+ *   - a torn line is DROPPED, never guessed at — a truncated row parsed "as far as it goes" would
+ *     fabricate a record nobody wrote;
+ *   - and it is REPORTED, never swallowed: every defect comes back with its file, 1-based line,
+ *     parse reason and a bounded slice of the text, so the caller can say out loud what it could
+ *     not read. "Assuming someone else counts is how nobody counts."
+ *   - a MISSING (or unreadable) file is its own state, distinguishable from an empty one — the
+ *     cadence checker needs the difference and a gate must not confuse "no ledger" with "no rows".
+ *
+ * Returns { rows, defects, torn, missing }: rows are the parsed objects in file order; defects is
+ * [{ file, line, reason, text }]; torn === defects.length, kept as a count because most callers
+ * only need the number; missing is true when the file could not be read at all (rows/defects empty).
+ *
+ * DELIBERATELY FLAT in scripts/, not scripts/lib/: the kit and the workspace bundle both vendor the
+ * engine's require closure by BASENAME into a flat directory (kit/build-kit.sh, scripts/
+ * vendor-workspace-engine.js), so a `./lib/` require would resolve in the checkout and break in
+ * every vendored copy — the exact incident class the scripts/lib/sink.js re-export note records.
+ * workspace/lib/file-mode-parse.js does NOT delegate here for the mirrored reason: the workspace
+ * bundle ships alone, cannot require across the bundle boundary, and its silent-drop reader is the
+ * locked mirror of kit/scripts/metrics.py (kit/fixtures/test_parsers.py holds that agreement).
+ *
+ * Zero dependencies, stock Node.
+ */
+const fs = require('fs');
+
+function readJsonl(file) {
+  let text;
+  try { text = fs.readFileSync(file, 'utf8'); }
+  catch { return { rows: [], defects: [], torn: 0, missing: true }; }
+  const rows = [];
+  const defects = [];
+  const lines = text.split('\n');
+  for (let i = 0; i < lines.length; i++) {
+    const t = lines[i].trim();
+    if (!t) continue;
+    try { rows.push(JSON.parse(t)); }
+    catch (e) {
+      defects.push({ file, line: i + 1, reason: String((e && e.message) || 'not valid JSON').slice(0, 120), text: t.slice(0, 120) });
+    }
+  }
+  return { rows, defects, torn: defects.length, missing: false };
+}
+
+module.exports = { readJsonl };