create-pmos 0.52.0 → 0.53.1

package/workspace/sheet-answer.js

@@ -0,0 +1,61 @@
+'use strict';
+/* sheet-answer.js — a test helper (pm-os-absorb Run 3, slice 3D). The workspace asks its questions as sheets
+ * (public/pm/dialogs.js), so a suite that used to accept a native prompt or confirm answers the sheet instead.
+ *
+ *   answerSheet(page, answer?, press?)  → { kind, title } | null
+ *     waits for the next sheet, fills each field named in `answer` ({ key: text }, or a string for the single field of an
+ *     askText sheet), presses "confirm" (default) or "cancel", and reports the sheet's kind and title.
+ *   watchSheets(page, handler)          → stops answering with the returned function
+ *     answers every sheet that opens with handler({ kind, title, fields }) → { answer, press } (or null to leave it open).
+ */
+
+async function answerSheet(page, answer, press = 'confirm', timeout = 8000) {
+  try { await page.waitForSelector('[data-dialog]', { timeout }); } catch { return null; }
+  return page.evaluate(({ a, p }) => {
+    const d = document.querySelector('[data-dialog]');
+    const kind = d.getAttribute('data-dialog');
+    const title = ((d.querySelector('[class*="title"]') || {}).textContent || '').trim();
+    const set = (c, v) => { c.value = v; c.dispatchEvent(new Event('input', { bubbles: true })); c.dispatchEvent(new Event('change', { bubbles: true })); };
+    if (a != null) {
+      const fields = [...d.querySelectorAll('[data-dialog-field]')];
+      if (typeof a === 'string') { if (fields[0]) set(fields[0], a); }
+      else for (const [k, v] of Object.entries(a)) { const c = d.querySelector('[data-dialog-field="' + k + '"]'); if (c) set(c, v); }
+    }
+    d.querySelector(p === 'cancel' ? '[data-dialog-cancel]' : '[data-dialog-confirm]').click();
+    return { kind, title };
+  }, { a: answer == null ? null : answer, p: press });
+}
+
+function watchSheets(page, handler) {
+  let on = true;
+  (async () => {
+    while (on) {
+      let seen = null;
+      try {
+        seen = await page.evaluate(() => {
+          const d = document.querySelector('[data-dialog]:not([data-seen])');
+          if (!d) return null;
+          d.setAttribute('data-seen', '1');
+          return { kind: d.getAttribute('data-dialog'), title: ((d.querySelector('[class*="title"]') || {}).textContent || '').trim(), fields: [...d.querySelectorAll('[data-dialog-field]')].map((c) => c.getAttribute('data-dialog-field')) };
+        });
+      } catch { return; }
+      if (seen) {
+        const r = handler(seen);
+        if (r) await page.evaluate(({ a, p }) => {
+          const d = document.querySelector('[data-dialog][data-seen]');
+          if (!d) return;
+          const set = (c, v) => { c.value = v; c.dispatchEvent(new Event('input', { bubbles: true })); };
+          if (a != null) {
+            if (typeof a === 'string') { const f = d.querySelector('[data-dialog-field]'); if (f) set(f, a); }
+            else for (const [k, v] of Object.entries(a)) { const c = d.querySelector('[data-dialog-field="' + k + '"]'); if (c) set(c, v); }
+          }
+          d.querySelector(p === 'cancel' ? '[data-dialog-cancel]' : '[data-dialog-confirm]').click();
+        }, { a: r.answer == null ? null : r.answer, p: r.press || 'confirm' }).catch(() => {});
+      }
+      await new Promise((res) => setTimeout(res, 60));
+    }
+  })();
+  return () => { on = false; };
+}
+
+module.exports = { answerSheet, watchSheets };

package/workspace/skills/measure.skill

@@ -0,0 +1,41 @@
+---
+name: measure
+label: "Record a measurement"
+description: "Read the current value of a KR or a health budget from a committed file, and record it with `pmos measure add` and its source."
+run: agent
+agent: claude
+version: 1.0.0
+owner: wawan
+risk: low
+scope: read:state, write:state/measurements
+output:
+  - Recorded
+  - Not recorded
+  - Sources
+---
+
+/measure — record the current value of one or more anchors (a KR or a health budget) for THIS repository. A measurement is evidence. It is not a decision and it does not move an initiative.
+
+Rules that always hold:
+1. ONLY FROM A COMMITTED FILE. Read the value from a file in this repository. Use the commit that holds the file now. If the value is not in a committed file, do not record it. Write it under "Not recorded" with the reason.
+2. ALWAYS A SOURCE. Every measurement has a source in the form `<path>@<commit sha>`. The command refuses a measurement with no source.
+3. NOTHING INVENTED. Do not estimate, round up or carry a value forward. If two files disagree, record neither value. Write both under "Not recorded".
+4. ONE WRITER. Record a value only with `pmos measure add`. Do not edit `planning/runs/measurements.jsonl` or any ledger file.
+5. NO ATTRIBUTION FLAGS. Do not give `--by` or `--via`. The command sets who wrote the line from the session.
+
+Procedure (each step ends with a check that shows it is done):
+1. Find the anchors. Read `planning/okrs/` for the KRs of the current period and `planning/okrs/health-budgets.md` for the health budgets. If the PM named anchors, use only those.
+   Done when: you have a list of anchors, each as a KR (for example `KR 2.1`) or `health:<id>`.
+2. For each anchor, find the file that states its current value and its target. Get the commit with `git log -1 --format=%h -- <path>`.
+   Done when: each anchor has a value, a target or none, a date and a source, or a reason it has none.
+3. Record each value:
+   `pmos measure add "<anchor>" <value> --source <path>@<sha> [--target <number>] [--unit <unit>] [--as-of YYYY-MM-DD]`
+   Use the date the file gives for the value as `--as-of`. With no date in the file, give no `--as-of`; the command uses today.
+   Done when: the command printed "recorded" for each value. If it refused a value, read its message, correct the call once, and otherwise write the value under "Not recorded".
+4. Check the result with `pmos measure list --json`.
+   Done when: each value you recorded is in the list.
+
+Output sections:
+- **Recorded** — one line per value: anchor, value, target, as_of, source.
+- **Not recorded** — one line per anchor with no value, and why.
+- **Sources** — each file you read, with its commit.

package/workspace/skills/morning-brief.skill

@@ -1,20 +1,21 @@
 ---
 name: morning-brief
 label: "Morning brief"
-description: "Prepare today's brief: the calendar, the priorities and what is worth asking. Read-only on every source; it submits the brief to the workspace and sends nothing."
+description: "Prepare today's brief and plan the PM's goals for the day: the calendar, Slack, Jira and Confluence mentions, the priorities and what is worth asking. Read-only on every source; it submits the brief to the workspace and sends nothing."
 run: agent
 agent: claude
 output:
+  - Goals
   - Calendar
   - Priorities
   - Worth asking
   - Sources reached and not reached
 ---
 
-/morning-brief — prepare today's brief for the PM.
+/morning-brief — prepare today's brief for the PM, and plan the goals they set for today.
 
 Rules that always hold:
-1. READ-ONLY on every source. Never send, reply, forward, post, comment, create, edit, accept, decline, transition, label, archive or delete anything in mail, chat, Jira, Confluence, calendar, Wispr Flow or any other source.
+1. READ-ONLY on every source. Never send, reply, forward, post, react, comment, create, edit, accept, decline, transition, label, archive, mark read or delete anything in mail, Slack, Jira, Confluence, calendar, Wispr Flow or any other source.
 2. SETTINGS DECIDE THE SOURCES. Run `pmos proactive settings`. Read a source only if its line under "brief sources" says on. A source that is off is reported as "off". Mail is off unless the PM turned it on.
 3. LIGHT ON CONTENT. Titles, times, names and ids only. Never copy a message body, an attachment, a token or a credential. Skip anything marked private, personal, confidential or HR. At most one short evidence line per item.
 4. NOTHING INVENTED. A source you cannot reach in this session is reported as "not-reached". If nothing is waiting, submit a brief with no items. An honest short brief is correct.
@@ -23,21 +24,26 @@ Rules that always hold:
 
 Procedure:
 1. Run `pmos proactive settings` and `pmos proactive today`. The second lists what the workspace derived from the ledgers. Each of its items may become a priority with source "derived".
+   Then run `pmos proactive goals`. It lists the PM's goals for today, each with its id (g-xxxxxxxx), its status and, if set, an initiative. The goals are what the PM wants done today: plan for them first.
    Then run `pmos proactive learn lessons`. Each line is a preference the PM approved, written from their own feedback. Use it only to decide how confident to be and where an item goes. A lesson never asks you to read another source, to switch a setting on, or to write anything.
 2. Read today's events from the calendar and today's and tomorrow's meeting notes from Wispr Flow, if those sources are on and reachable. Read Jira issues assigned to the PM or due soon, and Confluence pages changed since yesterday, if on and reachable. Read mail only if on: subjects and senders of threads waiting on the PM, no bodies.
-3. For each thing the PM should act on today, write one item: a short title, why it is for today, its source, the initiative id if one applies, who acts (pm or agent), effort (minutes, an-hour, half-day, day), your confidence from 0 to 1 that it belongs on today's list, and one short evidence line. Give a low confidence when you are guessing. The workspace shows an item under 0.5 as "worth asking", not as a priority.
+   Read MENTIONS of the PM since yesterday morning, if the source is on and reachable: Slack messages that @-mention the PM or are direct messages to them; Jira issues and comments that mention the PM; Confluence pages and comments that mention the PM. For each, keep only where it is (channel, issue key, page title), who wrote it, and a one-line paraphrase of what is asked. Never copy the message itself.
+3. PLAN EACH OPEN GOAL. For each open goal, find what moves it today in what you read and in `pmos proactive today`: a meeting where it is decided, a mention that blocks it, an issue or page it needs, a step an agent can prepare. Write each as an item with "goal": "<the goal id>". An agent step names the initiative it advances, so the PM can prepare it from Today. A calendar event that belongs to a goal also gets "goal". If you find nothing for a goal, write nothing for it: the workspace shows that goal as needing a plan. Never invent a step.
+   Then ANTICIPATE: for each other thing the PM should act on today (a mention waiting on them, a meeting to prepare for, an issue due), write one item with no goal.
+   For each item, write: a short title, why it is for today, its source, the initiative id if one applies, who acts (pm or agent), effort (minutes, an-hour, half-day, day), your confidence from 0 to 1 that it belongs on today's list, and one short evidence line. Set "mention": true on an item that comes from a mention of the PM. Give a low confidence when you are guessing. The workspace shows an item under 0.5 as "worth asking", not as a priority.
 4. Write the brief as a JSON file in the scratch folder of this session, in this shape, and nothing else:
    ```
-   {"date": "YYYY-MM-DD", "sources": {"calendar": "read", "wispr": "not-reached", "mail": "off", "jira": "read", "confluence": "read"},
-    "calendar": [{"start": "<ISO date and time>", "end": "<ISO>", "title": "…", "with": "…"}],
-    "items": [{"title": "…", "why_now": "…", "source": "calendar|wispr|mail|jira|confluence|derived", "initiative_id": "<id or omit>", "owner": "pm|agent", "effort": "minutes|an-hour|half-day|day", "confidence": 0.0, "evidence": "…"}],
+   {"date": "YYYY-MM-DD", "sources": {"calendar": "read", "wispr": "not-reached", "mail": "off", "slack": "read", "jira": "read", "confluence": "read"},
+    "calendar": [{"start": "<ISO date and time>", "end": "<ISO>", "title": "…", "with": "…", "goal": "<goal id or omit>"}],
+    "items": [{"title": "…", "why_now": "…", "source": "calendar|wispr|mail|slack|jira|confluence|derived", "initiative_id": "<id or omit>", "goal": "<goal id or omit>", "mention": false, "owner": "pm|agent", "effort": "minutes|an-hour|half-day|day", "confidence": 0.0, "evidence": "…"}],
     "judgment": {"used": false}}
    ```
-   Only report calendar events if calendar is "read". Only give an item a source that is "read" (or "derived").
+   Only report calendar events if calendar is "read". Only give an item a source that is "read" (or "derived"). Only use a goal id that `pmos proactive goals` listed today: the workspace refuses any other.
 5. Run `pmos proactive brief submit --file <that file>`. If it is refused, read the reason, fix the file and submit once more. Do not work around a refusal.
-6. Finish by saying in two lines how many priorities and worth-asking items you submitted and which sources were not reached.
+6. Finish by saying in three lines how many goals have a step and which have none, how many priorities and worth-asking items you submitted, and which sources were not reached.
 
 Output contract — produce EXACTLY these sections in your final message:
+- Goals
 - Calendar
 - Priorities
 - Worth asking

package/workspace/skills/report-biweekly.skill

@@ -1,7 +1,7 @@
 ---
 name: report-biweekly
 label: "Bi-weekly report (from your definition)"
-description: "Prepare the biweekly report as a draft, following the PM's own definition of what it is for and how it looks. Proposes a definition if none exists yet."
+description: "Prepare the biweekly report as a draft: a script with no model writes every number, then this skill writes the headline, the notes and the asks between the note markers. Proposes a definition if none exists yet."
 run: agent
 agent: claude
 output:
@@ -11,40 +11,38 @@ output:
   - Sources reached and not reached
 ---
 
-/report-biweekly — prepare a bi-weekly report for THIS repository as a draft. Work only from what you can actually read. Covers the last 14 days.
+/report-biweekly — prepare a bi-weekly report for THIS repository as a draft. A script with no model writes the draft and every number in it; you write the words between the note markers. Work only from what you can actually read. Covers everything since the last issued bi-weekly report (the last 14 days when none was issued).
 
 Rules that always hold (D71):
 1. DRAFT ONLY. You write a file in this repository. Never send, post, share, email, publish or upload the report anywhere; the PM does that.
 2. READ-ONLY on every source. Never send, reply, forward, post, comment, create, edit, transition, label, archive or delete anything in mail, chat, Jira, Confluence, calendar or any other source.
-3. SOURCED. Every claim carries a pointer: a requirement note, an initiative id, an acceptance, or a connector item (kind, id or link, date, author). A claim you cannot point to is left out or marked "unverified".
+3. SOURCED. Every claim carries a pointer the reader can open: an initiative id, a file path in this repository, or an acceptance. Write the pointer as a name. Do not type a date in it; the block above the note carries the dates. A claim you cannot point to is left out or marked "unverified".
 4. LIGHT ON CONTENT. Never copy message bodies, attachments, tokens or credentials. At most one short quotation per item. Skip threads or pages marked private, personal, confidential or HR, and count them.
-5. NOTHING INVENTED. If a source is not reachable in this session, say so under "Sources reached and not reached". If nothing happened, say that. An honest short report is correct.
-6. THE PM'S DEFINITION RULES. The shape of this report is whatever the definition says. Do not substitute your own format.
+5. NOTHING INVENTED. The script lists the sources it reached and did not reach under "Sources reached and not reached": that section is not yours to edit. If a source that you need is not reachable in this session, say so in your final message. If nothing happened, say that in the note. An honest short note is correct.
+6. THE PM'S DEFINITION RULES. The script shapes the file from the definition: its sections, their order and its blocks. The definition's purpose, audience, length and tone govern the words of your notes. Do not substitute your own format.
+7. THE SCRIPT WRITES EVERY NUMBER. In a note you type none: no count, no ratio such as "7 of 12", no percentage, no date, no day count. If a sentence needs a number, write it without the number; the block above the note already shows it. A name is not a number: an initiative id, a file path and a note id may be written as they are.
+8. PROSE ONLY BETWEEN NOTE MARKERS. In the draft file, write only between a `<!-- pmos:note <id> -->` line and its `<!-- /pmos:note -->` line. Never edit, move or delete a marker or any line outside one. Never add a section to the file.
 
 Procedure:
 1. Find the state directory: `pmos/state/` if it exists, otherwise `planning/`. Call it <state>.
 2. Read the definition: `<state>/reports/definitions/biweekly.md`.
-   - If it exists, follow its purpose, audience, sources, sections, length and tone exactly.
-   - If it does NOT exist, do not stop. Look for earlier biweekly reports in the repository and under <state>/reports/ to learn the shape the PM already uses. Write a PROPOSED definition (purpose, audience, sources, sections, length, tone) to `<state>/reports/definitions/biweekly.md` with this frontmatter, one key per line and nothing indented: `type: Reference`, `title`, `description`, `generated: {by: claude-code/report-biweekly, at: "…"}`, `status: draft` — and then use it for this draft. Never set `status: stable` or add `verified` yourself: only the PM confirms a definition.
-3. Gather the material for the last 14 days: the requirement notes in `<state>/requirements/`, the initiatives and their acceptances (`node scripts/workflow-state.js` if the repository has it, otherwise read `<state>/initiatives/` and `acceptances.jsonl`), and every connected source the definition names that you can reach.
-4. Write the draft to `<state>/reports/biweekly/YYYY-MM-DD.md` (today's date). If today's file exists, do NOT overwrite it: append a section `## Later run HH:MM`. Start with this frontmatter (OKF v0.2, D73). Every key is on ONE line — never indent a key under another:
-   ```
-   ---
-   type: Reference
-   title: "Bi-weekly report YYYY-MM-DD"
-   description: "A draft biweekly report, prepared from the PM's own definition."
-   generated: {by: claude-code/report-biweekly, at: "<today's date and time, ISO 8601>"}
-   sources: [{resource: "<requirement note, initiative, or connector item>", title: "<what it is>"}]
-   status: draft
-   definition: stable | draft
-   ---
-   ```
-   `definition` says whether the definition used is confirmed (`stable`) or only proposed (`draft`). Do not add a `timestamp` or `verified`.
-5. Under the frontmatter: a Headline (one or two sentences: what the reader most needs to know), then the sections the definition names in its order, then "Needs your call" (decisions or answers only the PM can give), then "Sources reached and not reached" (each source kind: reached or not reached and why; private items skipped).
-6. If the definition was a draft, say so in the first line of the Headline so the PM sees it.
-7. Finish by saying in one line where the draft is. Do not commit; the PM's Sync carries the file.
+   - If it exists, write your notes to its purpose, audience, length and tone. The script applies its sections.
+   - If it does NOT exist, do not stop. Look for earlier biweekly reports in the repository and under <state>/reports/ to learn the shape the PM already uses. Write a PROPOSED definition (purpose, sources, sections, length, tone) to `<state>/reports/definitions/biweekly.md` with this frontmatter, one key per line and nothing indented: `type: Reference`, `title`, `description`, `cadence: biweekly`, `sections: [headline, timeline, initiatives, new, decided, needs, sources]`, `generated: {by: claude-code/report-biweekly, at: "…"}`, `status: draft` — and then use it for this draft. Never set `status: stable` or add `verified` yourself: only the PM confirms a definition. Never set `audience`: only the PM names who reads the report, and the script writes no asks until the PM does.
+3. Do not read a tracker. Do not run `tracker-refresh`. That skill is scheduled before this one and writes its evidence into the plan items from local files. If it did not run, the script lists the tracker under "Sources reached and not reached". Repeat that line in your final message.
+4. Run `pmos report draft biweekly`. The script has no model: it folds the ledgers since the last issued biweekly report and writes the whole draft to `<state>/reports/biweekly/YYYY-MM-DD.md` (the slot is today's date), with one empty note marker for each block. Read what it prints.
+   - It prints the path: go on.
+   - It refuses because a draft for the slot exists: do NOT overwrite it. Do not pass `--redraft` here, and do not pass `--now`. Write your notes into the file that exists.
+   - It refuses because the slot is issued: stop. An issued report is frozen. Say so in one line.
+   - It refuses for any other reason: stop and quote the refusal. Do not work around it, and do not write the file yourself. A block with no reason for its health is the PM's to fix, not yours to invent.
+5. Read the draft. Then read what you need to write well: the requirement notes in `<state>/requirements/`, the initiatives and their acceptances (`node scripts/workflow-state.js` if the repository has it). The blocks, the numbers and the sources are the script's. Do not correct them.
+6. Write the prose, and only between note markers:
+   - For each `<!-- pmos:note <initiative-id> -->`, one or two sentences: what moved and what it means for the reader. Start with "Warning:" when the block is off track or at risk. A note that already has text is the PM's or an earlier run's: leave it.
+   - For `<!-- pmos:note report.headline -->`, one or two sentences: what the reader most needs to know. If the definition is a draft, say so in the first line.
+   - For `<!-- pmos:note report.asks -->`, if the file has it: the decisions only the audience can give, one per line, each line starting with "- ". Never ask the audience for a decision that is the PM's own.
+7. Run `pmos report draft biweekly --redraft`. The script is the one writer of the draft file: it writes the file again and keeps every note, so a line you changed outside a note marker is put back. Read the file once more and check that each note you wrote is still in place. Do not commit; the PM's Sync carries the file. Finish by saying in one line where the draft is.
+   - It refuses (the slot was issued since step 4, or a block has no reason for its health): quote the refusal and stop. Say that your notes are in the file and that the file is not re-rendered, so a line outside a note marker may differ from the script's. Do not edit the file again.
 
-Default shape, used ONLY when proposing a definition: a two-week report: progress, decisions, risks, what is next. Use the report frame of D78: a Headline, then What moved, Risks and Metrics, then Needs your call and Sources reached and not reached.
+Default shape, used ONLY when proposing a definition: the report frame of D78 as amended by D86 point 3. A Headline, a Timeline, one block for each initiative active in the window, New since last report, Decided this cycle, Needs your call, and Sources reached and not reached.
 
 Output contract — produce EXACTLY these sections, the same shape every run:
 - Headline

package/workspace/skills/tracker-refresh.skill

@@ -0,0 +1,50 @@
+---
+name: tracker-refresh
+label: "Refresh tracker items (from local files)"
+description: "Bring the plan items that a tracker owns up to date from files already in this repository, and append one evidence line for each change. It reads local files only: no tracker call, no network."
+run: agent
+agent: claude
+output:
+  - Moved
+  - Left as they are
+  - Not found
+  - Sources reached and not reached
+---
+
+/tracker-refresh — bring the plan items that a tracker owns up to date for THIS repository. A tracker-owned item has an owner that starts with `tracker:`. You read files that are already here and you append evidence lines. You call no tracker.
+
+This skill runs before the bi-weekly report (`report-biweekly`). The report script reads only the ledgers. It cannot call a tracker (R30, D71), so the evidence lines you write are the only way a tracker item reaches the report.
+
+Rules that always hold (D71):
+1. LOCAL FILES ONLY. Read files in this repository. Never call a tracker, a connector, a URL or any network tool. Never run `curl`, `wget`, `git fetch` or `git pull`. A tracker that no local file describes is "not reached".
+2. READ-ONLY on every source. Never send, reply, forward, post, comment, create, edit, transition, label, archive or delete anything in Jira, Confluence, mail, chat, calendar or any other source.
+3. THE ONLY WRITE is `pmos item move`. Never edit a repository file. Never run `pmos item add`, `set` or `withdraw`. Never write a ledger by hand. Never commit; the PM's Sync carries the ledger.
+4. EVIDENCE FOR EVERY MOVE. Each move carries `--evidence file:<repository path>`: the local file that shows the tracker state. If you have no file to point at, do not move the item.
+5. NOTHING INVENTED. Move an item only to the state a file says. If the files disagree, use the newest one and say so. If no file says, leave the item and list it under "Not found".
+6. LIGHT ON CONTENT. Read titles, ids and statuses. Never copy a message body, an attachment, a token or a credential. Skip a file marked private, personal, confidential or HR, and count it.
+7. NEVER REOPEN, NEVER WITHDRAW. Never move an item that is Done or Withdrawn. Never withdraw an item: if a file says the tracker closed it as "won't do", list it under "Left as they are" and say why.
+8. A FILE THAT PMOS WRITES IS NEVER EVIDENCE. Never use a plan-items ledger, any `*.jsonl` file, anything under `<state>/runs/` or anything under `<state>/reports/` as evidence. Those files hold the state you are about to check, so they cannot confirm it.
+9. AN OLD FILE DOES NOT UNDO A NEWER MOVE. Move an item only when the file is dated later than the item's last move.
+
+Procedure:
+1. Find the state directory: `pmos/state/` if it exists, otherwise `planning/`. Call it <state>.
+2. List the initiatives: the file names in `<state>/initiatives/`, without `.md`. For each one, run `pmos item list <initiative> --json`. Keep the items whose `owner` starts with `tracker:` and whose `state` is `todo`, `doing` or `review`. The text after `tracker:` is the tracker reference, for example `PROJ-12`.
+3. For each kept item, search the local files for its tracker reference: first `<state>/requirements/`, then the rest of `<state>/` and `docs/`. Use `grep -rl --exclude='*.jsonl' "<reference>" <folder>`. Skip every file under `<state>/runs/` and `<state>/reports/` (rule 8). Accept a file that names the reference and states its status. Take the newest accepted file. Its date is its `timestamp` frontmatter, or its last git commit if it has none.
+4. Read the status in that file and map it to a state:
+   | The file says | State |
+   |---|---|
+   | To Do, Open, Backlog, Ready | `todo` |
+   | In Progress, Doing, Started | `doing` |
+   | In Review, Code Review, QA, Testing | `review` |
+   | Done, Closed, Resolved, Released | `done` |
+   A status that is in no row is not a state: leave the item and list it under "Not found".
+5. Find the item's last move: the `at` of the last entry with `"ev":"moved"` in its `history` (from `pmos item list --json`), or its `createdAt` if it has no such entry. If the file's date is not later than that, leave the item and list it under "Left as they are" as "file older than the last move" (rule 9).
+6. If the mapped state is the item's state, leave the item. Write nothing. List it under "Left as they are" with the file and its date.
+7. If the mapped state is different, run `pmos item move <item> <state> --evidence file:<path of the file>`. If the command is refused, read the reason and do not work around it. List the item under "Not found" with the reason.
+8. Finish with the four sections of the output contract, as short lines: one line for each item, with its id, the old and new state and the file. Under "Sources reached and not reached", give each tracker reference as reached (the file and its date) or not reached. If you moved nothing, say so in one line: a refresh that moves nothing writes no line, so the bi-weekly report can still list the tracker as not refreshed. Do not commit.
+
+Output contract — produce EXACTLY these sections, the same shape every run:
+- Moved
+- Left as they are
+- Not found
+- Sources reached and not reached

package/workspace/test-files.json

@@ -9,6 +9,7 @@
   ],
   "modules": [
     "proactive.test.js",
+    "goals.test.js",
     "focus.test.js",
     "handoff.test.js",
     "repo-scan.test.js",
@@ -39,7 +40,12 @@
     "proactive-prepare.test.js",
     "learn.test.js",
     "session-flag.test.js",
-    "live-notes.test.js"
+    "live-notes.test.js",
+    "plan-items.test.js",
+    "plan-tree.test.js",
+    "item-cli.test.js",
+    "plan-routes.test.js",
+    "glossary.test.js"
   ],
   "panels": [
     "pm-shell-test.js",
@@ -88,7 +94,10 @@
     "pm-r29-filespad-test.js",
     "pm-r29-newsession-alignment-test.js",
     "pm-live-notes-test.js",
-    "pm-r30-test.js"
+    "pm-r30-test.js",
+    "pm-breakdown-test.js",
+    "pm-breakdown-phone-test.js",
+    "first-paint-count.test.js"
   ],
   "ui": [
     "ui-test.js"
@@ -96,6 +105,7 @@
   "seconds": {
     "test.js": 48,
     "proactive.test.js": 4,
+    "goals.test.js": 6,
     "focus.test.js": 1,
     "handoff.test.js": 1,
     "repo-scan.test.js": 1,
@@ -174,7 +184,15 @@
     "pm-r29-newsession-alignment-test.js": 8,
     "pm-live-notes-test.js": 24,
     "pm-r30-test.js": 4,
-    "ui-test.js": 30
+    "ui-test.js": 30,
+    "plan-items.test.js": 1,
+    "plan-tree.test.js": 2,
+    "item-cli.test.js": 2,
+    "plan-routes.test.js": 3,
+    "glossary.test.js": 1,
+    "pm-breakdown-test.js": 62,
+    "pm-breakdown-phone-test.js": 19,
+    "first-paint-count.test.js": 15
   },
   "_comment_seconds": "Measured wall time of each suite run alone (4-CPU sandbox, 2026-10-05). Only the ORDER uses it: the slowest suites start first, and --shard deals suites to the least-loaded shard so the shards finish together. A wrong or missing number never skips a suite; a missing one counts as 10."
 }

package/workspace/test-lists/base.json

@@ -0,0 +1,6 @@
+{
+  "_comment": "The seam suites of pm-os-absorb Runs 2 to 5 (the base every slice is cut from). Each slice adds its own suites in test-lists/<slice-id>.json, for example run2-a.json, and never edits this file or test-files.json.",
+  "modules": ["d86-seams.test.js"],
+  "panels": ["pm-seams-test.js"],
+  "seconds": { "d86-seams.test.js": 8, "pm-seams-test.js": 30 }
+}

package/workspace/test-lists/run2-a.json

@@ -0,0 +1,6 @@
+{
+  "_comment": "run2-a (Runtime guards): the R25 guard suites. r25-guards.test.js boots real servers, PTYs and tmux on scratch repositories; pm-nonce-test.js is a short browser suite.",
+  "modules": ["r25-guards.test.js"],
+  "panels": ["pm-nonce-test.js"],
+  "seconds": { "r25-guards.test.js": 10, "pm-nonce-test.js": 12 }
+}

package/workspace/test-lists/run2-b.json

@@ -0,0 +1,13 @@
+{
+  "_comment": "pm-os-absorb Run 2, slice 2B (detection, matcher, grants). The suites outside workspace/ run from the repository root: node --test \"kit/mods/pmos-cockpit/hooks/lib/*.test.mjs\" (kit CI), bash scripts/tests/pm-lines.sh and bash scripts/tests/plan-items.sh (through scripts/check-plan-ledgers.js in the Initiative Gate), node scripts/tests/record-grant.test.js.",
+  "modules": [
+    "grant-mint.test.js",
+    "pm-lines-needs.test.js"
+  ],
+  "panels": [],
+  "exclusive": [],
+  "seconds": {
+    "grant-mint.test.js": 4,
+    "pm-lines-needs.test.js": 4
+  }
+}

package/workspace/test-lists/run2-c.json

@@ -0,0 +1,19 @@
+{
+  "_comment": "pm-os-absorb Run 2, slice run2-c (ledgers, writers, CLI, routes): the placements and measurements writers, the initiative writer, pmos initiative and pmos measure, the Initiatives API and initiative-needs. Unit and route suites only; this slice has no browser suite.",
+  "modules": [
+    "placements.test.js",
+    "measurements.test.js",
+    "initiative-writer.test.js",
+    "initiative-cli.test.js",
+    "routes-initiatives.test.js",
+    "initiative-needs.test.js"
+  ],
+  "seconds": {
+    "placements.test.js": 4,
+    "measurements.test.js": 3,
+    "initiative-writer.test.js": 5,
+    "initiative-cli.test.js": 15,
+    "routes-initiatives.test.js": 6,
+    "initiative-needs.test.js": 5
+  }
+}

package/workspace/test-lists/run2-d.json

@@ -0,0 +1,22 @@
+{
+  "_comment": "Slice 2D of pm-os-absorb Run 2: display, health and the Initiatives destination. Its suites only; never test-files.json or base.json.",
+  "modules": [
+    "health.test.js",
+    "r3-display.test.js"
+  ],
+  "panels": [
+    "pm-initiatives-dest-test.js",
+    "pm-initiatives-dest-phone-test.js",
+    "first-paint-initiatives.test.js"
+  ],
+  "seconds": {
+    "health.test.js": 1,
+    "r3-display.test.js": 3,
+    "pm-initiatives-dest-test.js": 60,
+    "pm-initiatives-dest-phone-test.js": 40,
+    "first-paint-initiatives.test.js": 25
+  },
+  "helpers": {
+    "pm-initiatives-stub-test.js": "not a suite: serves the Initiatives routes to the page from the goldens, for pm-initiatives-dest-test.js, pm-initiatives-dest-phone-test.js and first-paint-initiatives.test.js"
+  }
+}

package/workspace/test-lists/run3-0.json

@@ -0,0 +1,5 @@
+{
+  "_comment": "Slice run3-0 of pm-os-absorb: the replaced-tests manifest check. Node only; reads the base's test files through git show at the commit SHA pinned in replaced-tests.json (full history needed); it exits 2 when that commit is missing while an entry waits for the PM.",
+  "modules": ["replaced-tests.test.js"],
+  "seconds": { "replaced-tests.test.js": 5 }
+}

package/workspace/test-lists/run3-a.json

@@ -0,0 +1,5 @@
+{
+  "_comment": "Slice run3-a of pm-os-absorb (the frame shell): the frame on a desktop (bar, places, dock, Settings, keys, first paint with the bar) and on a phone (390x844, touch: the five tabs, the pinned palette, one panel at a time, the 44px row menus, nothing on hover). Both boot a real server on a synthetic fixture repository through pm-breakdown-stub-test.js bootWithRepo.",
+  "panels": ["pm-frame-test.js", "pm-frame-phone-test.js"],
+  "seconds": { "pm-frame-test.js": 70, "pm-frame-phone-test.js": 40 }
+}

package/workspace/test-lists/run3-b.json

@@ -0,0 +1,6 @@
+{
+  "_comment": "Slice run3-b of pm-os-absorb (Run 3, Today): the ranking and its route and CLI, and the Today destination in a browser. pm-r29-today-test.js is listed in test-files.json since the base; this slice replaced its content (manifest entry C02).",
+  "modules": ["today.test.js", "routes-today.test.js"],
+  "panels": ["pm-today-test.js", "pm-today-phone-test.js", "first-paint-today.test.js"],
+  "seconds": { "today.test.js": 5, "routes-today.test.js": 25, "pm-today-test.js": 120, "pm-today-phone-test.js": 90, "first-paint-today.test.js": 60 }
+}

package/workspace/test-lists/run3-c.json

@@ -0,0 +1,15 @@
+{
+  "_comment": "Slice run3-c of pm-os-absorb (the ⌘K palette and capture): the capture writer and its route, and the browser suite pm-palette-test.js.",
+  "modules": [
+    "capture.test.js",
+    "routes-capture.test.js"
+  ],
+  "seconds": {
+    "capture.test.js": 1,
+    "routes-capture.test.js": 4,
+    "pm-palette-test.js": 60
+  },
+  "panels": [
+    "pm-palette-test.js"
+  ]
+}

package/workspace/test-lists/run3-d.json

@@ -0,0 +1,6 @@
+{
+  "_comment": "Slice run3-d of pm-os-absorb (Run 3: tokens, the cuts, the parity lock lifted). cuts.test.js reads the shipped source and asserts each cut is absent, the tokens, the dialogs and the one /api/reports caller; pm-cuts-test.js loads the frame and asserts the bar, Settings (Open Validate, Rename and Remove in sheets), the three Portfolio report commands in the palette and the sheet dialogs. The browser suite runs only through runs/browser-run.sh.",
+  "modules": ["cuts.test.js"],
+  "panels": ["pm-cuts-test.js"],
+  "seconds": { "cuts.test.js": 2, "pm-cuts-test.js": 40 }
+}

package/workspace/test-lists/run4-a.json

@@ -0,0 +1,8 @@
+{
+  "_comment": "pm-os-absorb Run 4, slice run4-a (Integrator): the factory join and its health rules, and the parity of the engine's plan-item fold with the workspace's (X29). The shell suites scripts/tests/verify-work.sh and scripts/tests/build-rule.sh run from scripts/check-plan-ledgers.js (the Initiative Gate), not from here.",
+  "modules": ["factory-join.test.js", "plan-items-stage-parity.test.js"],
+  "panels": [],
+  "exclusive": [],
+  "helpers": [],
+  "seconds": { "factory-join.test.js": 3, "plan-items-stage-parity.test.js": 2 }
+}

package/workspace/test-lists/run4-b.json

@@ -0,0 +1,6 @@
+{
+  "_comment": "pm-os-absorb Run 4, slice 4B (Timeline engine and Breakdown › Timeline): the item-spans engine and the Breakdown › Timeline browser suite.",
+  "modules": ["item-spans.test.js"],
+  "panels": ["pm-breakdown-timeline-test.js"],
+  "seconds": { "item-spans.test.js": 1, "pm-breakdown-timeline-test.js": 40 }
+}

package/workspace/test-lists/run4-c.json

@@ -0,0 +1,13 @@
+{
+  "_comment": "Slice 4C (Initiatives › Timeline) of pm-os-absorb Run 4. Its suites run in the lists named here, never in test-files.json.",
+  "modules": [
+    "routes-timeline.test.js"
+  ],
+  "seconds": {
+    "routes-timeline.test.js": 12,
+    "pm-initiatives-timeline-test.js": 60
+  },
+  "panels": [
+    "pm-initiatives-timeline-test.js"
+  ]
+}

package/workspace/test-lists/run4-d.json

@@ -0,0 +1,9 @@
+{
+  "_comment": "Slice 4D (the Board destination) of pm-os-absorb Run 4: the route, the CLI and the Today rows, then the destination in a desktop, a phone and a first-paint browser suite.",
+  "modules": ["routes-board.test.js", "board-cli.test.js", "work-check-needs.test.js"],
+  "panels": ["pm-board-dest-test.js", "pm-board-dest-phone-test.js", "first-paint-board.test.js"],
+  "seconds": {
+    "routes-board.test.js": 12, "board-cli.test.js": 10, "work-check-needs.test.js": 4,
+    "pm-board-dest-test.js": 60, "pm-board-dest-phone-test.js": 25, "first-paint-board.test.js": 20
+  }
+}

package/workspace/test-lists/run5-a.json

@@ -0,0 +1,6 @@
+{
+  "_comment": "pm-os-absorb Run 5, slice run5-a (drafter and issues ledger). The scripts/ suites (issues.sh, report-lane-issues.sh) run through scripts/check-plan-ledgers.js, not here.",
+  "modules": ["report-draft.test.js", "issues.test.js", "report-cli.test.js"],
+  "panels": [],
+  "seconds": { "report-draft.test.js": 15, "issues.test.js": 6, "report-cli.test.js": 6 }
+}

package/workspace/test-lists/run5-b.json

@@ -0,0 +1,6 @@
+{
+  "_comment": "pm-os-absorb Run 5, slice run5-b (skill, generator, tracker refresh, schedule). scripts/tests/comms-reporting.test.js and gen-report-skills.js --check run from the repository root, not here.",
+  "modules": ["tracker-refresh.test.js"],
+  "panels": [],
+  "seconds": { "tracker-refresh.test.js": 8 }
+}

package/workspace/test-lists/run5-c.json

@@ -0,0 +1,15 @@
+{
+  "_comment": "pm-os-absorb Run 5, slice run5-c (Reports destination and Today providers). The browser suites run only through runs/browser-run.sh, two at a time machine-wide.",
+  "modules": ["report-needs.test.js", "routes-reports.test.js"],
+  "panels": ["pm-reports-test.js", "pm-reports-phone-test.js", "first-paint-reports.test.js"],
+  "seconds": {
+    "report-needs.test.js": 4,
+    "routes-reports.test.js": 8,
+    "pm-reports-test.js": 70,
+    "pm-reports-phone-test.js": 40,
+    "first-paint-reports.test.js": 25
+  },
+  "helpers": {
+    "pm-reports-stub-test.js": "not a suite — the helpers pm-reports-test.js, pm-reports-phone-test.js and first-paint-reports.test.js require (the synthetic reports, the schedules store, and the POST routes answered while slice 5A's writers are stubs)"
+  }
+}

package/workspace/test-lists/workspace-launcher.json

@@ -0,0 +1,5 @@
+{
+  "_comment": "workspace-launcher: `pmos launcher on|off|status` (lib/launcher-cli.js).",
+  "modules": ["launcher.test.js"],
+  "seconds": { "launcher.test.js": 2 }
+}

package/workspace/test-lists/workspace-phone-app.json

@@ -0,0 +1,5 @@
+{
+  "_comment": "workspace-phone-app: the tailnet branches of the access guard (sign-in page, /auth, the token-stripping redirect), driven through httpGuard as a library because test.js runs loopback-only.",
+  "modules": ["phone-access.test.js"],
+  "seconds": { "phone-access.test.js": 3 }
+}