create-pmos 0.1.1 → 0.2.0

package/README.md

@@ -50,6 +50,30 @@ Next steps in /home/you/my-product:
 Do those three lines and setup is over. A fresh kit with zero history is not behind — it is
 exactly where every product starts.
 
+### Behind a corporate proxy? (403 on install)
+
+On many work laptops, npm goes through a company registry mirror — and a brand-new public package
+gets **403 Forbidden** until it's been vetted (a sandboxed AI session's network proxy can do the
+same). That's your environment being careful, not something broken — and there are three clean
+ways through:
+
+1. **Try a plain terminal first** — if the 403 came from inside an AI-session sandbox, the normal
+   terminal may just work.
+2. **Ask IT to allowlist `create-pmos`** — a routine request, and an easy one: public npm, MIT,
+   zero dependencies, no install scripts, no network code.
+3. **The registry-free install** — the package is just a file, so skip the registry entirely.
+   From any allowed network, download
+   `https://registry.npmjs.org/create-pmos/-/create-pmos-<version>.tgz`, move it to the work
+   machine, then:
+
+   ```bash
+   tar xzf create-pmos-*.tgz
+   node package/bin/create-pmos.js my-product
+   ```
+
+   Same result, byte-identical kit, no proxy involved. (Which is fitting — keeping your work
+   inside your own boundary is the whole point of this kit.)
+
 ## Your first conversation
 
 Open the folder with your coding agent and talk to it like a colleague — clear about the goal,
@@ -74,10 +98,16 @@ open about what you don't know. Copy-paste starters:
 ## The rhythm (every piece of work)
 
 1. **Name the work.** An initiative file is created in `pmos/state/initiatives/` — anchored to one
-   of your goals, so nothing exists "just because."
-2. **Define "good" first.** The agent drafts a PRD and a scoring rubric; you approve the contract
-   (`PM_approved: true`) before any building. Deciding the standard in advance is your task —
-   it is also what makes the agent's verdicts mean something later.
+   of your goals (or, for honest maintenance with no goal, a declared health budget), so nothing
+   exists "just because."
+2. **Define "good" first.** The agent drafts the spec artifact that fits the work's lane — a PRD +
+   scoring rubric for a feature (the default), a spike brief for research (`discovery`), a stated
+   intent for maintenance (`chore`), a content brief for copy (`content`). For a feature you
+   approve the contract (`PM_approved: true`) before any building — and spike/content briefs get
+   your sign-off before work starts too; a chore needs only its stated
+   intent, and an `incident` is the one sanctioned inversion — fix first, record within 48 hours.
+   Deciding the standard in advance is your task — it is also what makes the agent's verdicts
+   mean something later.
 3. **The agent builds** on its own branch and opens the work for review. A gate checks that every
    change is anchored. If someone (including the agent) skips the protocol, you'll see:
 
@@ -101,6 +131,13 @@ open about what you don't know. Copy-paste starters:
    > I accept this run. Append the acceptance to pmos/state/acceptances.jsonl with pm_label
    > "pass" and corrections: [how many things you had to fix].
 
+   Or record it yourself, no agent needed — the helper validates and appends in one command
+   (`pmos/AGENTS-HUMAN.md` is the whole protocol on one page for humans):
+
+   ```bash
+   pmos/scripts/pmos-log.sh accept <run_id> <initiative_id> pass "one wording fix"
+   ```
+
 ## Your weekly ten minutes
 
 ```bash
@@ -134,8 +171,8 @@ Each stage of the loop has a mechanism behind it — not a promise, a mechanism:
 
 | Without the kit | With the kit |
 |---|---|
-| Work starts because someone felt like it | **Nothing exists without an initiative** anchored to a goal — the gate rejects unanchored work, automatically on GitHub, by one command locally |
-| "Good" gets defined after seeing the output (so everything looks fine) | **The rubric and contract are written first** — building is blocked until you've flipped `PM_approved: true` |
+| Work starts because someone felt like it | **Nothing exists without an initiative** anchored to a goal — or a declared health budget for honest maintenance — the gate rejects unanchored work, automatically on GitHub, by one command locally |
+| "Good" gets defined after seeing the output (so everything looks fine) | **The lane's spec artifact is written first** — a feature is blocked until you've flipped `PM_approved: true`; every lane's requirement is gate-enforced (the one sanctioned inversion: an incident is fixed first, recorded within 48h) |
 | The builder grades their own homework | **A separate adversarial evaluator scores against your rubric** — and even its verdict is advisory; the merge is yours alone |
 | History gets quietly rewritten | **State files are append-only** — corrections are added, never erased; git keeps the audit trail |
 | Metrics flatter you | **Reds print first**, and a tripwire fires if the evaluator passes everything while you keep fixing things — a green that hides red gets caught |
@@ -153,8 +190,9 @@ defends structurally rather than relying on discipline:
   session read `pmos/AGENTS.md` before working — so a new session, a new model, or a new teammate
   starts on-protocol by default instead of drifting from a stale memory.
 - **The gate makes skipping visible.** On GitHub it's a failing check nobody can miss; locally
-  it's the one command before a merge. Keep the `no-initiative` escape hatch for genuine chores
-  only — if you find yourself reaching for it weekly, that's a signal, not a shortcut.
+  it's the one command before a merge. The `no-initiative` escape hatch is for anchor-free
+  trivia only (a typo, a broken link) — real maintenance takes the `chore` lane with a stated
+  intent, and if you find yourself reaching for the hatch weekly, that's a signal, not a shortcut.
 - **The weekly ten minutes is the ritual.** Put `metrics.py` + the discoveries scan on your
   calendar. A friction that shows up twice with no decision gets promoted to a rule — that's how
   the process improves instead of eroding.
@@ -197,6 +235,32 @@ Refreshes the skills, concepts, and scripts only. Your records — `state/`, `pl
 `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.2.0
+
+The kernel grew four capabilities, each born from real dogfooding of 0.1.x:
+
+- **Work-type lanes.** `type: feature | discovery | chore | incident | content` on the initiative
+  file — each lane has a fitting spec artifact (spike brief, stated intent, post-hoc incident
+  record, content brief) and the gate enforces per lane. Research, maintenance, fires, and copy no
+  longer have to cosplay as features.
+- **Human builders, first-class.** `pmos/AGENTS-HUMAN.md` is the whole protocol on one page for a
+  person, and `pmos/scripts/pmos-log.sh` writes validated state records with one command — mixed
+  human/agent teams share the same files and metrics.
+- **Health budgets.** Maintenance with no honest goal anchors to a declared budget
+  (`parent_kr: health:<id>` from `pmos/planning/okrs/health-budgets.md`, seeded with capped
+  tech/security/ops lines) instead of forcing a fake goal link. A fake anchor is worse than an
+  honest budget.
+- **Test-first Quality Gate.** `templates/product-ci-starter.yml` ships failing-until-wired, so a
+  fresh repo's CI is loud until you give it real tests — never silently empty.
+
+**Upgrade note:** the gate now rejects an initiative file with **no `parent_kr`**. If `--update`
+makes an old initiative fail the gate, that file was always unanchored — add a real goal, or a
+health budget id if it's honest maintenance. The gate failing is the fix working. (One caveat for
+upgraders: `--update` never touches `planning/`, so it won't create
+`pmos/planning/okrs/health-budgets.md` — declare your budgets by writing that small table yourself
+or copying it from a fresh vendor; the gate accepts the `health:<id>` string either way, but an
+undeclared budget id is exactly the fake-anchor problem in new clothes.)
+
 ## Scope & support
 
 This package contains only the PMOS workflow kernel. It holds no reference to, and never

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "create-pmos",
-  "version": "0.1.1",
-  "description": "Scaffold the PMOS portable kit — run the PMOS product-management workflow (initiative → PRD → eval rubric → contract → build → three gates) entirely inside your own repo, with all state as git-versioned files. No database, no network, no telemetry.",
+  "version": "0.2.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. No database, no network, no telemetry.",
   "license": "MIT",
   "bin": {
     "create-pmos": "bin/create-pmos.js"

package/payload/AGENTS-HUMAN.md

@@ -0,0 +1,43 @@
+# AGENTS-HUMAN.md — the PMOS kit for a human builder (D58)
+
+You're a person, not an agent — same loop, plain terms, one helper. The full protocol lives in
+[AGENTS.md](AGENTS.md); this page is everything you need day-to-day. **Never edit `pmos/state/`
+files by hand — use the helper**, which validates and appends (records are append-only; a
+correction is a new record, never an edit).
+
+## The loop (per piece of work)
+
+1. **Open the work.** Create `pmos/state/initiatives/<id>.md` with a lane
+   (`type: feature | discovery | chore | incident | content`) and its artifact — feature: PRD +
+   rubric (copy the templates from `pmos/okf/core/templates/`); discovery: a spike brief; chore:
+   an `intent:` line; incident: fix first, record within 48h; content: a content brief. Anchor to
+   a KR in `pmos/planning/okrs/` — or, for maintenance work with no honest KR, to a declared
+   health budget (`parent_kr: health:<id>` from `pmos/planning/okrs/health-budgets.md`). Always
+   one or the other; never unanchored.
+2. **Branch `initiative/<id>`, do the work.** For feature work, write your tests first where you
+   can — the CI you wired via `templates/product-ci-starter.yml` is your Quality Gate.
+3. **Record as you go** (each command prints exactly what it appended):
+
+   ```sh
+   pmos/scripts/pmos-log.sh run      <run_id> <initiative_id> [human_corrections]
+   pmos/scripts/pmos-log.sh eval     <run_id> <initiative_id> <score 0..1> <PASS|PASS-WITH-FINDINGS|FAIL> <rubric_path>
+   pmos/scripts/pmos-log.sh accept   <run_id> <initiative_id> <pass|fail> "note"
+   pmos/scripts/pmos-log.sh outcome  <initiative_id> <validated|refuted|inconclusive> "evidence"
+   pmos/scripts/pmos-log.sh friction "what fought you"
+   ```
+
+   The helper rejects bad values with a clear message (wrong verdict/disposition, a
+   validated/refuted outcome with no evidence, malformed score) — the same rules the hosted
+   backend enforces.
+4. **Merge = the Acceptance Gate.** The **accepting human (the PM)** merges and records it
+   (`accept … pass`) — if you built it and someone else accepts, they merge, not you. A solo
+   operator is their own PM and merges with that hat on. If
+   you declared an `outcome_metric` on the initiative, you're not done until you dispose it at
+   its horizon (`outcome …`).
+5. **Weekly (15 min):** run `python3 pmos/scripts/metrics.py` and read the red first; skim
+   `pmos/state/discoveries.md`.
+
+## Working with an agent sometimes?
+
+Mixed teams are fine: agents follow `AGENTS.md`, you follow this page — both write the same state
+through the same conventions, and `metrics.py` doesn't care who built.

package/payload/AGENTS.md

@@ -18,7 +18,7 @@ yourself wanting an MCP tool, use the state adapter below instead.
 
 | Hosted tool (as skills name them) | File-mode equivalent |
 |---|---|
-| `create_initiative` | write `pmos/state/initiatives/<id>.md` (frontmatter: id, title, parent_kr, stage, status, prd_path, rubric_path, created) |
+| `create_initiative` | write `pmos/state/initiatives/<id>.md` (frontmatter: id, title, parent_kr, stage, status, **type** — the D56 lane, default `feature` — plus `intent` for the chore lane, prd_path, rubric_path, created; optionally `outcome_metric` + `outcome_horizon` — the D57 declaration for post-ship success criteria) |
 | `save_spec` | the PRD file itself at `pmos/planning/prd/<id>-prd.md` (set `prd_path` on the initiative file) |
 | `get_spec` / `get_planning_artifact` | read `pmos/planning/…` |
 | `get_skill` | read `pmos/skills/<name>.skill` |
@@ -27,6 +27,7 @@ yourself wanting an MCP tool, use the state adapter below instead.
 | `log_agent_run` | append one JSON line to `pmos/state/runs.jsonl` (`{run_id, initiative_id, pre_run_contract, self_eval, human_corrections, date}`) |
 | `save_eval` | append one JSON line to `pmos/state/evals.jsonl` (`{run_id, initiative_id, rubric_path, score, verdict, dimensions, date}`) |
 | `record_acceptance` | append one JSON line to `pmos/state/acceptances.jsonl` (`{run_id, initiative_id, accepted, pm_label, note, date}`) — **written only on the PM's explicit word** |
+| `record_outcome_check` | append one JSON line to `pmos/state/outcome_checks.jsonl` (`{initiative_id, disposition, evidence, date}`) — the D57 post-acceptance outcome verdict (`validated | refuted | inconclusive`; evidence required for the first two). **PM's word only — never auto-dispose from metrics**; a re-judgment is a new line |
 | `save_okf_doc` | write the doc under `pmos/okf/product/…` marked as a DRAFT; the PM approves it via PR review (the file-mode form of draft→approved) |
 | `register_product_repo` | not applicable — this repo IS the product; skip the step |
 | `log_friction` / `log_discovery` | append to `pmos/state/discoveries.md` (ISO date, `#friction` tag where applicable) |
@@ -36,6 +37,26 @@ State files are **append-only**: never rewrite or delete an existing line or ini
 correct by appending. When a vendored skill names a hosted tool, apply this table — the skill
 bodies are single-sourced from the PMOS kernel and are not forked for file mode.
 
+## Work-type lanes (D56)
+
+Every initiative carries a `type` — the lane picks what the gate requires **before** work; the
+kernel (anchor — a KR **or** `health:<id>` from `planning/okrs/health-budgets.md` (D59) —
+eval-before-work in lane-appropriate form, human Acceptance, append-only state)
+holds in every lane. Unknown/missing type = `feature`, the strictest lane. The enum is closed —
+never invent a lane; a work shape with no lane escalates to the PM.
+
+| type | spec artifact the gate requires | eval form |
+|---|---|---|
+| `feature` (default) | PRD + eval rubric before build | rubric + evaluator skill (unchanged) |
+| `discovery` | spike brief at `prd_path` (question + timebox — `skills/discovery.skill`, template in `okf/core/templates/`) | disposition: learned / promoted / discarded; rubric optional |
+| `chore` | a one-paragraph `intent:` in the initiative file | repo CI + PM spot-check at merge |
+| `incident` | incident record at `prd_path`, **post-hoc within 48h** (template in `okf/core/templates/`) — the one sanctioned inversion of eval-first | retro in the record; follow-ups become their own initiatives |
+| `content` | content brief at `prd_path` (audience, message, claims + sources — `skills/copywriting.skill`, template in `okf/core/templates/`) | copy rubric recommended, not required (D58); PM judges at the gate otherwise |
+
+`no-initiative` label = anchor-free trivia ONLY (a typo, a broken link). A chore, spike,
+incident, or piece of content is real work and takes its lane — that is what keeps the record
+honest.
+
 ## Agent run protocol (every run, in order)
 
 1. Read this file.
@@ -43,9 +64,14 @@ bodies are single-sourced from the PMOS kernel and are not forked for file mode.
    No skill fits → escalate to the PM; do not improvise a procedure.
 3. Retrieve context: `pmos/okf/` for concepts, `pmos/okf/product/` for this product's knowledge,
    `pmos/state/runs.jsonl` + `discoveries.md` for what prior runs tried (episodic memory).
-4. Anchor: the initiative file must exist at stage `intake`/`spec` with a PRD and rubric authored
-   **before** build (eval-first, D13). Write the **pre-run contract** into the rubric's sprint
-   contract section and get the PM's explicit approval (`PM_approved: true`) before any work.
+4. Anchor: the initiative file must exist at stage `intake`/`spec` with its **lane's** spec/eval
+   artifacts authored **before** build (eval-first, D13, generalized per lane — see the lane table
+   above; `feature` = PRD + rubric; the incident lane alone records post-hoc). Contract per lane:
+   `feature` = the rubric's sprint-contract section with the PM's explicit `PM_approved: true`;
+   `discovery` = the PM-approved spike brief (question + timebox); `chore` = the stated intent;
+   `content` = the PM-approved content brief. No work before the lane's approval. Feature-lane
+   `test_method`s SHOULD be executable checks written before build (D58) — wire
+   `templates/product-ci-starter.yml` so tier 1 is never silently empty.
 5. Branch `initiative/<id>`; execute at control altitude; one commit per artifact.
 6. Self-evaluate against the contract — self-eval is unreliable; it is an input to the gates, never
    a verdict.
@@ -55,6 +81,28 @@ bodies are single-sourced from the PMOS kernel and are not forked for file mode.
    = the human PM merges and disposes — final and non-delegable. Never merge your own PR.
 8. Log the run (`runs.jsonl`) and any friction (`discoveries.md`, `#friction`).
 
+## Human builders & multi-repo initiatives (D58)
+
+- **A human building instead of an agent?** Same loop, plain terms: [AGENTS-HUMAN.md](AGENTS-HUMAN.md).
+  State is written with `scripts/pmos-log.sh` (validated, append-only) — never hand-edited. Mixed
+  human+agent teams write the same state through the same conventions.
+- **An initiative spanning multiple repos?** ONE repo is its **home** — the initiative record,
+  brief/PRD, rubric, and state live there. Every sibling repo's PR anchors by declaring
+  `Initiative: <id>` in the PR body (the gate's body-key path); records land in the home state
+  layer. There is no cross-repo registry — the body key IS the join. **Sibling repos either do
+  not install the pmos gate, or mirror the initiative file locally** — a vendored sibling gate
+  fails closed on a missing local record by design (S5 Review Gate finding).
+
+## New agent paths — the lethal-trifecta audit
+
+Before creating any new agent path or widening a tool grant, verify it does **not** hold all three
+of: **private data access + untrusted-content exposure + external communication**. An agent holding
+all three can be tricked by content it reads into exfiltrating what it knows — remove a leg
+(preferably external communication) structurally; prompt-level defenses alone are bypassed by
+adaptive attacks. If a path genuinely needs all three, its PRD/brief must name the compensating
+gate; silence is not a pass. The evaluator is the standing example: it reads adversarial diffs, so
+it stays read-only with its verdict append as the only write.
+
 ## Escalation (stop and ask the PM)
 
 An architectural choice with no recorded decision; a wrong or unsatisfiable contract; scope growth;
@@ -73,7 +121,34 @@ and the Goodhart tripwire from `pmos/state/`.
 
 Scan `discoveries.md`; a friction theme seen twice with no resolving decision must be promoted to a
 decision. Read run records since last review; log overrides to `eval-calibration.md`. Run
-`pmos/scripts/metrics.py` and read the red first.
+`pmos/scripts/metrics.py` and read the red first. **Scan the lane mix (D56):** count initiatives
+per `type` — a chore share climbing review over review, discovery spikes that never close their
+disposition, or `no-initiative` PRs that should have been chores are drift signals; a lane misused
+twice is promoted to a decision like any recurring friction. **Scan the anchor mix (D59):** feature-vs-health share of the period's initiatives; a budget over
+its cap or health-shaped work with a KR anchor is a drift signal; quarterly, review the caps.
+**Scan outcome checks (D57):**
+metrics.py lists due outcomes (accepted, past horizon, undisposed) — dispose each
+(`validated | refuted | inconclusive`, evidence for the first two) or consciously defer; a check
+deferred twice, or a horizon moved twice, is promoted like recurring friction. An accepted
+initiative with a declared outcome is NOT finished until disposed. **Read the run's explainer where
+one exists** — the `explain-run` skill writes an independently-authored literate explainer + quiz to
+`pmos/planning/evals/explainers/<run_id>-explainer.md`; start there instead of the raw transcript,
+and for a high-risk run pass its quiz as a comprehension self-check before you accept. Recommended
+discipline, not an enforced gate — accepting runs you cannot explain is the PM's own watermelon.
+
+**Anti-atrophy forcing functions (complacency is structural, not a willpower problem):**
+- **Name one hand-verified fact at every Acceptance** — the `record_acceptance` note states something
+  *you* checked directly (ran it, read the hunk, reproduced it), not the evaluator's verdict restated.
+- **Watch the acceptance-friction meta-watermelon** — a run of zero-comment, fast acceptances is
+  itself a flag; mandated oversight decays into rubber-stamping that legitimizes the system.
+- **Guard the four satisficing heuristics**: plan-as-proxy, tests-as-guarantee (CI-green ≠ correct —
+  the Quality Gate is not the Acceptance Gate), eyeballing-suffices, deference-in-unfamiliar-domains.
+- **Adaptive autonomy** — drop an initiative to every-diff review on a failed eval, a reverted merge,
+  a gate-touching change, or a subsystem you haven't personally touched in ~3 months.
+- **Monthly**, do one hands-on rep — personally diagnose one defect or re-derive one diff from its
+  spec before reading the agent's version (diagnosis-shaped; comprehension decays faster than typing).
+  **Quarterly**, ask *"what would I no longer know how to fix by hand?"* — supervision cost rises as
+  runs improve.
 
 ## Kit maintenance
 

package/payload/KIT-VERSION

@@ -1,3 +1,3 @@
-kernel-source: pmos@30a011b
-assembled: 2026-07-17
+kernel-source: pmos@907bf50
+assembled: 2026-07-20
 mode: vendor

package/payload/README.md

@@ -10,6 +10,9 @@ personally-owned PMOS backend).
 
 - `AGENTS.md` — the run protocol. **Start here; every agent session reads it first.** Contains the
   state adapter: the table mapping each hosted PMOS tool to a file convention.
+- `AGENTS-HUMAN.md` — the same loop for a **human** builder (D58): plain terms + the
+  `scripts/pmos-log.sh` helper that appends validated state records in one command. Mixed
+  human+agent teams share the same state.
 - `skills/` — the PMOS skill kernel (prd, eval-rubric, okr, evaluator, …). Single-sourced from the
   PMOS repo; where a skill names a hosted tool, apply the AGENTS.md state adapter.
 - `okf/core/` — kernel concepts (the sdlc loop, the three-tier gate, watermelon flags, …).
@@ -35,6 +38,11 @@ workflow: `initiative/<id>` branches, merge = Acceptance), but GitHub is optiona
 existing code there is nothing to ingest: start by seeding `planning/okrs/` (the okr skill) and a
 first right-sized initiative; the product's code grows in the same folder.
 
+**403 on `npx` (corporate proxy/mirror)?** Try a plain terminal (not a sandboxed AI session); ask
+IT to allowlist `create-pmos` (zero deps, no install scripts, no network code); or install
+registry-free — download the `.tgz` from `registry.npmjs.org/create-pmos/-/create-pmos-<v>.tgz`
+on any allowed network, then `tar xzf create-pmos-*.tgz && node package/bin/create-pmos.js <dir>`.
+
 **No GitHub?** Skip the workflow file and run the gate by hand before merging any initiative
 branch: `HEAD_REF=$(git branch --show-current) bash pmos/scripts/gate-initiative.sh` — green means
 anchored; your local `git merge` is the Acceptance Gate. If the repo later lands on GitHub, copy
@@ -42,11 +50,17 @@ anchored; your local `git merge` is the Acceptance Gate. If the repo later lands
 
 ## Operate (every piece of work)
 
-1. Create `pmos/state/initiatives/<id>.md` (stage `intake`, anchored to a KR in `planning/okrs/`).
-2. Author the PRD and the rubric **before building** (copy the rubric template); agree the sprint
-   contract; the PM flips `PM_approved: true`.
+1. Create `pmos/state/initiatives/<id>.md` (stage `intake`, anchored to a KR in `planning/okrs/` — or to a health budget,
+   `parent_kr: health:<id>` from `planning/okrs/health-budgets.md` (D59)),
+   with its **work-type lane**: `type: feature` (default) `| discovery | chore | incident | content`
+   (D56/D58 — the lane table in `AGENTS.md` says what each requires).
+2. Author the lane's spec artifacts **before building** — feature: PRD + rubric (copy the
+   templates), sprint contract, PM flips `PM_approved: true`; discovery: a spike brief (question +
+   timebox) the PM approves; chore: a one-paragraph `intent:`; incident: fix first, record within
+   48h.
 3. Branch `initiative/<id>`, build, open a PR — the `pmos-gate` CI check fails any PR that isn't
-   anchored (branch or `Initiative: <id>` in the PR body; `no-initiative` label for genuine chores).
+   anchored (branch or `Initiative: <id>` in the PR body; `no-initiative` label for anchor-free
+   trivia ONLY — a chore, spike, or incident takes its lane, D56).
 4. Review Gate: run the evaluator skill against the rubric; append the verdict to
    `state/evals.jsonl`. The verdict is advisory until locally calibrated.
 5. Acceptance Gate: the **human PM** merges and disposes; append to `state/acceptances.jsonl`
@@ -64,6 +78,11 @@ Talk to your agent like a colleague; your task is direction and judgment, its ta
   initiative — fast first win, not completeness."
 - **Start a piece of work:** "Read pmos/AGENTS.md. I want: [outcome]. Create the initiative file,
   then draft the PRD and eval rubric for my approval before you build anything."
+- **Explore before committing (discovery lane):** "Read pmos/AGENTS.md. I don't know yet whether
+  [idea] is worth building. Open a discovery initiative per pmos/skills/discovery.skill: draft the
+  spike brief — one question, a timebox — for my approval. Prototype code is throwaway."
+- **Quick maintenance (chore lane):** "Read pmos/AGENTS.md. Open a chore initiative: [one-sentence
+  intent]. No PRD or rubric — just state the intent in the initiative file and do it."
 - **Review Gate:** "Follow pmos/skills/evaluator.skill: score the work on branch initiative/[id]
   against its rubric. Be skeptical — try to refute it. Append the verdict to pmos/state/evals.jsonl."
 - **Acceptance:** "I accept this run. Append the acceptance to pmos/state/acceptances.jsonl with
@@ -87,6 +106,11 @@ PMOS checkout) — refreshes ONLY the kernel (skills/okf-core/scripts/AGENTS.md/
 stamps `KIT-VERSION`, never touches `state/`, `planning/`, or `okf/product/`. Updates flow
 one-way, PMOS → kit; review the diff as a normal PR.
 
+> Upgrade note (D59 kernel): the gate now rejects an initiative file with **no `parent_kr`**
+> (hosted parity, D21). If a pre-D59 vendored file trips it, that file was always unanchored —
+> add a real KR, or `parent_kr: health:<id>` from `planning/okrs/health-budgets.md` if it is
+> honest maintenance. The gate failing is the fix working, not a regression.
+
 ## The containment guarantee
 
 The assembly script greps its own output and fails on any reference to the hosted PMOS backend.

package/payload/okf/core/concepts/health-anchors.md

@@ -0,0 +1,41 @@
+---
+type: Concept
+title: Health Anchors
+description: The second anchor class — work anchors to a KR or a declared health budget (a standing, capped, PM-reviewed allocation), so refactor/ops/security work anchors honestly instead of faking a KR or escaping the record.
+tags: [anchoring, health, anti-optimism, budgets]
+timestamp: 2026-07-18
+---
+
+# Health Anchors
+
+**Situating context:** Added with [D59](/okf/products/pmos/adr/d59-health-anchors.md) out of the
+SDLC stress test: KR-only anchoring forced legitimate KR-orthogonal work (refactors, ops/SLO
+upkeep, security hardening) into fake anchors or the escape hatch — Goodhart on the anchoring rule
+itself. This concept defines the second anchor class the [OKR tree](/okf/core/concepts/okr-tree.md)
+rule now admits.
+
+## The rule
+
+Every initiative anchors ([D21]) — but to one of **two classes**:
+
+- **A KR** — an outcome bet: the initiative moves a measurable result.
+- **A health budget** — `health:<id>` from the closed registry
+  [`planning/okrs/health-budgets.md`](/planning/okrs/health-budgets.md): a standing, capped
+  allocation for work that keeps the system worth building on (tech health, security, ops).
+
+The distinction is honest bookkeeping: **health is a budget, not an outcome bet.** Dressing a
+refactor as a KR corrupts both — the KR's metric and the refactor's justification.
+
+## Governance
+
+The registry is closed (PM-edited, visible diffs). Caps are shares of a quarter's initiatives.
+The weekly scan reads the **anchor mix** (feature vs health) beside the lane mix — a climbing
+health share, a budget over cap, or health-shaped work still arriving with KR anchors are drift
+signals. The quarterly cadence reviews caps and **promotes** budget work to a real KR when it
+stops being upkeep and becomes a bet.
+
+## Relationship to lanes
+
+Orthogonal axes of one kernel rule: the [lane](/okf/products/pmos/adr/d56-initiative-lanes.md)
+fixes WHAT the gate requires; the anchor fixes WHY the work exists. A `chore`-lane refactor
+anchored `health:tech` is the canonical honest pairing.

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

@@ -7,6 +7,7 @@ to pick concepts, then fetch the file(s) you need.
 - [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.
 - [design-loop](design-loop.md) — How PMOS makes UI/UX design a first-class, repeatable sub-flow of the Build stage — brief → design → reconcile → build → design-sync — gated by the Review Gate, presentation-only, and never a data decision.
 - [eval-driven-pm](eval-driven-pm.md) — PMOS's core method — write the eval before the build. The rubric is the spec; the PM manages by defining what "good" means, not by inspecting work after the fact.
+- [health-anchors](health-anchors.md) — The second anchor class (D59): work anchors to a KR or a declared, capped, PM-reviewed health budget, so refactor/ops/security work anchors honestly.
 - [okf-governance](okf-governance.md) — How PMOS organizes its Open Knowledge Format bundle and the governance rules that keep it spec-conformant.
 - [okr-anti-optimism](okr-anti-optimism.md) — Why PMOS biases status reporting toward pessimism — surfacing the red underneath green metrics — to keep KR self-reporting honest.
 - [okr-tree](okr-tree.md) — How PMOS structures Objectives and Key Results as a tree that links strategy to initiatives and to the agent runs that move them.

package/payload/okf/core/concepts/okr-anti-optimism.md

@@ -52,3 +52,10 @@ The goal is *calibration*, not gloom. Over-reporting red is also a failure — i
 ignore reports. The discipline is: report the honest reading, weight uncertainty toward the
 downside, and always separate "where we are" from "how confident we are." A well-calibrated amber is
 worth more than a confident green or a reflexive red.
+
+## Amendment — the anchor mix (D59, 2026-07-18)
+
+Anti-optimism reporting gains the **anchor mix**: the feature-vs-health share of a period's
+initiatives, read beside the lane mix. Drift signals: a health budget over its cap, a climbing
+health share crowding out outcome bets, or health-shaped work still arriving with KR anchors
+(fake-anchor recidivism). See [health-anchors](/okf/core/concepts/health-anchors.md).

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

@@ -65,3 +65,10 @@ Individual KRs should ladder toward it, directly or indirectly.
 - KRs are reviewed on the PM's regular cadence; objectives are reset each period.
 - The OKR file is an **operational instance** — it lives under `/planning/`, not in OKF. This
   concept is the timeless *structure*; the quarterly file is the dated *content*.
+
+## Amendment — the second anchor class (D59, 2026-07-18)
+
+Initiative anchoring generalizes: an initiative anchors to a KR **or** to a declared
+[health budget](/okf/core/concepts/health-anchors.md) (`health:<id>` from the closed registry in
+`/planning/okrs/health-budgets.md`). Health work is a budget, not an outcome bet — forcing it
+under a KR corrupts both. The tree's KR discipline is unchanged for outcome work.

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

@@ -39,7 +39,8 @@ nature and a different owner.
 
 - **Nature:** subjective, strategic.
 - **Checks:** strategic fit. Is this what the product actually needs right now? Does it move the
-  parent KR? **This is NOT a re-check of the rubric.**
+  parent KR — or, for health-anchored work, honestly serve its declared budget (D59)? **This is
+  NOT a re-check of the rubric.**
 - **Owner:** the **human PM only**. Non-delegable.
 - The PM's role at the end of every agent run **is** the Acceptance Gate.
 

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

@@ -27,7 +27,8 @@ PMOS drives a closed lifecycle. Each turn of the loop moves one initiative throu
 ```
 
 1. **Spec** — the initiative gets a PRD via the [prd skill](/skills/core/prd.skill). The PRD says
-   what to build and why, anchored to a KR in the [OKR tree](/okf/core/concepts/okr-tree.md).
+   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,
    before any work starts. The PM approves it. (P0: temp file + PM approval; P1+:
    `agent_runs.pre_run_contract`.)

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

@@ -0,0 +1,70 @@
+---
+type: Template
+title: Content Brief Template
+description: The scaffold for a content-lane brief (D58) — audience, message, voice, deliverables, claim sources, and an optional weighted copy rubric. Copy into /planning/prd/ as <id>-content-brief.md and set it as the initiative's prd_path.
+tags: [template, content, copywriting, lanes]
+timestamp: 2026-07-18
+---
+
+# Content Brief Template
+
+**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,
+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
+> brief is not ready. PM approval of this brief is the lane's pre-work contract.
+
+---
+
+```markdown
+# Content Brief: <initiative title>
+
+## Identity
+- initiative_id: <id>
+- type: content
+- product_slug: <product_slug>
+- pm_slug: <pm_slug>
+- parent_KR: <link or health:<id> (D59)> — *"<KR text quoted>"; <why this copy advances it>*   <!-- REQUIRED -->
+- status: draft | approved
+- date: <YYYY-MM-DD>
+
+## Audience & placement
+<!-- WHO reads this, WHERE it appears (page/screen/email), and what they know walking in. One
+     line per audience/placement pair; each pair gets its own variant in the draft. -->
+- <audience> @ <placement>
+
+## Message
+<!-- The ONE thing each audience should take away, and the action it should prompt. -->
+
+## Voice & constraints
+<!-- Tone (e.g. plain, technical, playful), banned phrases, length limits, required terms,
+     localization notes. Link the product voice guide if one exists in OKF. -->
+
+## Claims & sources
+<!-- EVERY factual claim the copy will make, each with its source. Unsourced claims don't ship —
+     wrong public claims are incidents, not nits. -->
+- <claim> — <source>
+
+## Deliverables
+- <artifact + path, e.g. web/landing hero copy, README intro>
+
+## Copy rubric (RECOMMENDED, optional — delete if the PM judges at the gate instead)
+| Dimension | Weight |
+|---|---:|
+| Audience-fit (right register + assumed knowledge per variant) | 0.30 |
+| Clarity (message lands in one read; no filler) | 0.30 |
+| Voice (constraints above followed, or deviation argued) | 0.15 |
+| Claim accuracy (every claim matches its source) | 0.25 |
+| **Total** | **1.00** |
+pass_threshold: 0.85
+```
+
+---
+
+## Authoring checklist
+
+- [ ] `parent_KR` present with quoted text — content is anchored work, never the hatch.
+- [ ] Every claim has a source; every audience/placement pair has a planned variant.
+- [ ] PM approved the brief before drafting began.

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

@@ -28,7 +28,7 @@ instance and does not live in the OKF bundle.
 - initiative_id: <id>
 - product_slug: <product_slug>
 - pm_slug: <pm_slug>
-- parent_KR: <objective.kr reference>
+- parent_KR: <objective.kr reference OR health:<id> (D59)>
 - date: <YYYY-MM-DD>
 
 ## Point of view (so the design has one)

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

@@ -28,7 +28,7 @@ OKF bundle.
 - initiative_id: <id>
 - product_slug: <product_slug>
 - pm_slug: <pm_slug>
-- parent_KR: <reference>
+- parent_KR: <reference OR health:<id> (D59)>
 - pass_threshold: <0.00–1.00>          <!-- pre-committed, before output exists -->
 - date: <YYYY-MM-DD>
 
@@ -83,7 +83,18 @@ Rules:
   is repeatable across evaluators (and calibratable against
   [eval-calibration.md](/planning/evals/eval-calibration.md)).
 - **Threshold is pre-committed.** Never tune the threshold after seeing the output.
+- **Evidence per dimension.** A Review-Gate verdict must carry, for each scored dimension, a short
+  verbatim quote or precise pointer (file+line, query output, CI line) from the evaluated artifact;
+  a dimension without evidence is marked `unverified` and scored conservatively (≤ 0.5). Rubric
+  authors should write dimensions so that evidence is *citable* — observable outcomes, not
+  impressions ([llm-judge-calibration](/planning/research/llm-judge-calibration.md)).
 - **Outcome-only.** Score the artifact produced, not the tool-call sequence or reasoning path.
+- **Coherence criteria are semantic.** A "rule holds everywhere" criterion must enumerate its
+  live-doc set — every living mirror of a live surface (skills, templates, playbooks, concepts,
+  protocol docs, tool schemas + their reference/data-model mirrors, UI copy, intake instruments) —
+  and be tested by a semantic pass (reading for meaning); a grep sweep is evidence,
+  never the definition of done (health-anchors lesson —
+  [eval-calibration](/planning/evals/eval-calibration.md)).
 
 ## Authoring checklist
 
@@ -92,4 +103,7 @@ Rules:
 - [ ] Each dimension supports partial credit with anchored 0/0.5/1.
 - [ ] `pass_threshold` pre-committed.
 - [ ] Gate assignment stated; Acceptance Gate marked PM-only, not graded.
+- [ ] Dimensions written so a verdict can cite verbatim evidence per dimension (observable
+      outcomes, not impressions).
+- [ ] Any rule-coherence criterion enumerates its live-doc set and tests by semantic pass.
 - [ ] Sprint contract present with `PM_approved`.