create-pmos 0.38.4 → 0.38.6

package/payload/skills-native/prd/SKILL.md

@@ -32,22 +32,17 @@ agreed.
 
 ## Procedure
 
-0a. **Existing surface? Understand it first — before grilling.** If specifying this honestly
+0a. **Existing surface? Understand it first — before asking.** If specifying this honestly
    requires reading code that already exists, an [explain-surface](/skills/explain-surface.skill)
    pass runs on that region **first**, in a fresh context and **not by you**. Its *Open questions*
-   section is a declared input to the grilling below: those are the things that could not be
+   section is a declared input to the questions in step 0: those are the things that could not be
    determined from the code, and they must be resolved with the PM or carried explicitly into the
    PRD's risks — never silently answered by assumption. Greenfield → skip. This exists because step 0b's
    boundary rule, on its own, gives the **agent** the understanding and the PM none.
-0. **Grill before you write.** Before any authoring, interrogate the PM's intent as a dialogue —
-   **one question at a time, a recommended answer offered with each**, no authoring until shared
-   understanding is confirmed. Stop when the intent is **unambiguous**, not at a count — there is
-   deliberately **no question cap** (under-specification needs unlimited digging; a redundant
-   question is a quality bug, not a quantity bug). A batch questionnaire is **not** compliant with
-   this step. Boundary rule, near-verbatim from AGENTS.md: *if a fact can be found by exploring the
-   environment, look it up rather than asking — the decisions, though, are the PM's* (D12 at
-   optimal altitude). A stated requirement that later goes unhonored in a build (the recorded
-   "too many navigations" class) is exactly what this step exists to pin down in writing.
+0. **Ask before you write.** Follow the [requirements-elicitation skill](/skills/requirements-elicitation.skill):
+   its asking rule holds here, and no authoring starts until the PM confirms the shared understanding.
+   A stated requirement that later goes unhonored in a build (the recorded "too many navigations"
+   class) is what this step pins down in writing.
 1. **Anchor to strategy first.** Identify the parent KR in the
    [OKR tree](/okf/core/concepts/okr-tree.md) — or, for maintenance work with no honest KR, the
    declared [health budget](/okf/core/concepts/health-anchors.md) (`health:<id>`, D59). If the
@@ -109,8 +104,7 @@ its situating sentence (D58); the eval rubric is queued to be written first.
 
 ## Level 3 sub-cases
 
-- Multi-product or platform PRDs that span more than one `product_slug`: see `prd-multiproduct.md`
-  (author on first need).
+- None yet.
 - Spike / discovery work where the deliverable is a learning, not a feature, is **not a PRD
   case** — take the discovery lane ([D56](/okf/products/pmos/adr/d56-initiative-lanes.md)):
   [discovery skill](/skills/discovery.skill) +

package/payload/skills-native/requirements-elicitation/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: requirements-elicitation
+description: Turn a vague ask, or notes the PM gathered, into a requirements brief by asking the PM questions one at a time. Use when the PM wants to gather, clarify or sharpen requirements, or before any lane writes its first artifact (PRD, spike brief, fix specification, content brief).
+license: MIT
+metadata:
+  pmos-version: 1.0.0
+  pmos-owner: wawan
+  pmos-risk: low
+  pmos-category: planning
+  pmos-scope: read:okf, read:planning, read:state, write:planning/briefs
+---
+
+# requirements-elicitation — Ask until the requirement is sharp
+
+This skill is the one place where PMOS states how an agent asks the PM questions. It also
+holds the questions each lane needs. Its output is a requirements brief that a PRD, a spike
+brief or a fix specification starts from. It does not write those documents.
+
+> **Format note:** this skill follows [SKILL-FORMAT](/skills/SKILL-FORMAT.md). The text is
+> instructional (class A of [technical-writing-ste](/skills/technical-writing-ste.skill)).
+
+## When to use vs. not
+
+- **Use** when the PM asks to gather, clarify or sharpen requirements.
+- **Use** before the first artifact of any lane, when the intent is not yet unambiguous.
+- **Do not use** to decide the lane. That is the [pmos-router](/skills/pmos-router.skill).
+- **Do not use** to judge whether to build at all. That is the
+  [strategic-brief](/skills/strategic-brief.skill).
+- **Do not use** when an instance of the idea is needed before the PM can judge it. Route to the
+  prototype lane first.
+
+## The asking rule
+
+This rule holds in every step below. Other skills point here and do not repeat it.
+
+1. Ask one question at a time.
+2. Give a recommended answer with each question.
+3. Do not set a limit on the number of questions. Stop when the intent is unambiguous.
+4. Do not send a batch questionnaire. A batch does not satisfy this rule.
+5. Look up each fact that the repository or the record can answer. Do not ask the PM for it.
+6. Leave each decision to the PM.
+7. Write nothing until the PM confirms the shared understanding.
+
+## Procedure
+
+1. **Find the lane.** Read the initiative record and its `type`. Run
+   `node scripts/workflow-state.js --lanes --json` (in a kit repository the script is
+   `pmos/scripts/workflow-state.js`). Find the lane in `defs`.
+   State the lane's `input`, `output` and `done` in plain words before the first question.
+   *Done when:* the PM has seen the lane's input, output and done-rule.
+
+   If the script is missing or the lane is not in `defs`, say so. Ask the PM which lane applies.
+   Do not guess a question set.
+
+2. **Look up what exists.** Read the record, the PRD or brief if one exists, the OKR the
+   record names, and the explainer if the surface exists. Collect the facts you found.
+   *Done when:* every fact you will use has a source, and none of them is a question for the PM.
+
+3. **Read the gathered notes.** List `<state>/requirements/*.md`. `<state>` is `pmos/state/`
+   if it exists, and `planning/` if not. Select each item whose `initiative` names this
+   initiative. Show each item to the PM with its pointer and its `confidence`. Ask for one
+   answer per item: confirmed, rejected or deferred. Record the answer.
+   - A confirmed item goes in the brief under *Decisions*, with its pointer.
+   - A rejected item is dropped. Name it in *Gathered notes used* as rejected.
+   - A deferred item goes in *Open questions*.
+   - An item with `confidence: unconfirmed` stays unconfirmed until the PM answers. Never write
+     it as a fact.
+   - Name a note that does not parse. Skip it.
+   - If no notes exist, say so and continue.
+
+   Never edit a note. The notes are read-only drafts (D71).
+   *Done when:* every selected item has an answer, or the PM has said to skip the notes.
+
+4. **Ask the topic questions.** Work through the [question inventory](#question-inventory).
+   Skip a topic the lane's input does not need, and say that you skipped it.
+   Skip a question that step 2 or step 3 already answered.
+   *Done when:* each topic is answered, skipped with a reason, or listed in *Open questions*.
+
+5. **Ask the lane questions.** Find the lane in [Question sets by lane](#question-sets-by-lane).
+   Ask each question there that the earlier steps did not answer.
+   *Done when:* every element of the lane's `input` has an answer or an *Open questions* entry.
+
+6. **Confirm.** Say the shared understanding back to the PM in one short list. Ask the PM to
+   confirm or correct it.
+   *Done when:* the PM has confirmed. If the PM corrects it, go back to step 4.
+
+7. **Write the brief.** Copy the
+   [requirements-brief-template](/okf/core/templates/requirements-brief-template.md). Fill every
+   section from the confirmed answers, in the PM's words where the PM gave words. Write it to
+   `planning/briefs/<id>-requirements.md`. Set `brief_path` on the initiative record. If the lane
+   uses `prd_path` for its first artifact and that file does not exist yet, tell the PM that the
+   brief is the input and that the lane's own skill writes `prd_path`.
+   *Done when:* the file exists, no section is empty, and `brief_path` is set.
+
+8. **Hand over.** Name the next skill for the lane: [prd](/skills/prd.skill) for
+   feature and new-feature, [discovery](/skills/discovery.skill) for discovery,
+   [copywriting](/skills/copywriting.skill) for content, and the lane's own
+   template for the others. State the open questions that remain.
+   *Done when:* the PM knows what comes next and what is still open.
+
+## Question inventory
+
+Each topic has an opening question. Add follow-up questions when the answer is vague.
+
+| Topic | Opening question |
+|---|---|
+| Problem and user | Who has this problem, and what do they do today instead? |
+| Evidence | What shows that the problem is real: a number, a ticket, a quote, an incident? |
+| Constraints | What is fixed: a date, a budget, a technology, a rule or a promise already made? |
+| Stakeholders and decision owner | Who is affected, who must agree, and who decides if they disagree? |
+| Dependencies | What must exist, or be done by someone else, before this can work? |
+| Data | What data does this read or change, and who owns it? |
+| Non-functional needs | What must hold about speed, security, privacy, access or cost? |
+| Risks | What is the worst way this fails, and how would we notice? |
+| Success measure | Which measure moves if this works, from what value to what value, by when? |
+| Out of scope | What will this not do, even though someone might expect it to? |
+
+## Question sets by lane
+
+Each lane has its own heading. The headings use the lane names in `scripts/lane-defs.js`.
+A lane name that both profiles use (discovery, chore) has one set.
+
+### Lane `feature`
+
+1. What behaviour changes for the user, in one sentence?
+2. Does the surface exist today? If yes, what does it do now?
+3. Which KR or health budget does this serve?
+4. Can the PM judge this from a description, or must the PM see an instance first?
+5. What would the PM check by hand to accept it?
+
+### Lane `new-feature`
+
+1. Who has the problem, and how often does it happen?
+2. What shows that it is real?
+3. What do users do today?
+4. What must a first version do, and what can wait?
+5. What would make the PM drop it?
+
+### Lane `improvement`
+
+1. What does the feature do now? Look it up first.
+2. What is wrong or missing, and for whom?
+3. Which measure should the change move, and by how much?
+4. What must stay the same?
+5. How will we tell that it worked?
+
+### Lane `bug-fix`
+
+1. What are the steps that reproduce it?
+2. What is the expected result?
+3. What is the actual result?
+4. How severe is it, and who is affected?
+5. Is there a workaround?
+
+### Lane `discovery`
+
+1. What is the question, in one sentence?
+2. What is unknown, and what is already known?
+3. What evidence would end the spike?
+4. What would make this worth picking up, and what would make it worth dropping?
+5. How long may it take?
+
+### Lane `chore`
+
+1. What is the intent, in one paragraph?
+2. Which health budget does it serve?
+3. What must not change?
+4. How will the PM see that it is done?
+
+### Lane `incident`
+
+1. What broke, and who noticed?
+2. What is the cause?
+3. What was the repair, and is it permanent?
+4. What stops it from happening again?
+5. When was it fixed? The record is due within 48 hours.
+
+### Lane `content`
+
+1. Who reads it, and what should they do after?
+2. What is the one message?
+3. What tone and length does the reader expect?
+4. What facts must it contain, and where are they?
+5. Does the PM want a rubric?
+
+### Lane `prototype`
+
+1. What judgement does the PM need to make?
+2. Which format fits the specimens: a screen, a sample output, a transcript or a schema?
+3. What should the 2–3 specimens differ on?
+4. Which conventions does the class need before the specimens (design system, skill format)?
+
+### Lane `prd`
+
+1. What is the question the document answers?
+2. Who reads it?
+3. Which decision does it inform?
+4. What do the readers already know?
+
+### Lane `strategy`
+
+1. What is the question the document answers?
+2. Who reads it?
+3. Which decision does it inform?
+4. Over what period?
+
+### Lane `project-plan`
+
+1. What is in scope, and what is out?
+2. Who is on it, and for how much of their time?
+3. Which dates are fixed, and who fixed them?
+4. What does it depend on?
+
+### Lane `decision-record`
+
+1. What are the options?
+2. Which one was chosen, and by whom?
+3. What is the reason?
+4. What would reverse the choice?
+
+### Lane `report`
+
+1. What period or subject does it cover?
+2. Who reads it?
+3. What should the reader do after reading?
+4. Which sources does it use, and which can it not reach?
+
+## Failure behaviour
+
+- The lane definition cannot be read: say so, and ask the PM which lane applies.
+- No gathered notes exist: say so, and continue.
+- A note does not parse: name it, and skip it.
+- The PM leaves a question open: write it under *Open questions*. Do not answer it.

package/payload/state/discoveries.md

@@ -2,7 +2,7 @@
 type: Reference
 title: "Discoveries and friction log"
 description: "Append-only record of what runs discovered and where the process rubbed."
-generated: {by: process:create-pmos, at: "2026-10-02T08:57:21Z"}
+generated: {by: process:create-pmos, at: "2026-10-03T00:48:37Z"}
 status: stable
 ---
 

package/payload/state/log.md

@@ -2,6 +2,6 @@
 
 Newest first, ISO dates.
 
-## 2026-10-02
+## 2026-10-03
 
 - Adopted OKF v0.2 (D73).

package/workspace/lib/audit.js

@@ -0,0 +1,54 @@
+'use strict';
+/* audit.js — the workspace's door to the workflow sweep (D77).
+ *
+ * The sweep is ONE file, scripts/workflow-sweep.js, shared with the CLI an agent runs. It is loaded the
+ * way the workflow engine is: from the checkout two directories up, or from the copy the packaging step
+ * vendors into lib/engine/. This door only READS: it runs the sweep and reports. Repairs are made by
+ * `node scripts/workflow-sweep.js --fix`, on the PM's word, because they write the repository.
+ */
+const fs = require('fs');
+const path = require('path');
+
+const PATHS = [
+  path.join(__dirname, '..', '..', 'scripts', 'workflow-sweep.js'),
+  path.join(__dirname, 'engine', 'workflow-sweep.js'),
+];
+function core() {
+  for (const p of PATHS) {
+    if (!fs.existsSync(p)) continue;
+    try { return { ok: true, core: require(p) }; }
+    catch (e) { return { ok: false, error: `the workflow sweep at ${p} failed to load — ${String((e && e.message) || e).slice(0, 160)}` }; }
+  }
+  return { ok: false, error: 'the workflow sweep is not present in this install' };
+}
+
+const DEFECT_CAP = 40;
+const OWED_CAP = 12;
+
+/* Run the sweep on `root` and return a compact report. Defects are listed in full up to a cap, owed work as
+ * counts per class plus the first few, because a defect is the board lying and owed work is an open loop. */
+function run(root) {
+  const c = core(); if (!c.ok) return c;
+  let res;
+  try { res = c.core.sweep({ root }); }
+  catch (e) { return { ok: false, error: 'the sweep could not run — ' + String((e && e.message) || e).slice(0, 160) }; }
+  if (!res || res.ok === false) return { ok: false, error: (res && res.error) || 'the sweep could not read this repository' };
+  const pick = (f) => ({
+    class: f.class, id: f.id || null, file: f.file || null, what: f.what, evidence: f.evidence || null,
+    repair: f.repair ? { key: f.repair.key || null, to: f.repair.to || null } : null,
+    hand: f.hand || null,
+    command: f.repair ? 'node scripts/workflow-sweep.js --fix' : null,
+  });
+  const owedBy = {};
+  for (const f of res.owed || []) owedBy[f.class] = (owedBy[f.class] || 0) + 1;
+  return {
+    ok: true, root, initiatives: res.initiatives,
+    counts: { defects: (res.defects || []).length, owed: (res.owed || []).length, repairable: res.repairable || 0 },
+    defects: (res.defects || []).slice(0, DEFECT_CAP).map(pick),
+    owed_by_class: owedBy,
+    owed: (res.owed || []).slice(0, OWED_CAP).map(pick),
+    notes: res.notes || [],
+  };
+}
+
+module.exports = { run, core, PATHS };

package/workspace/lib/engine/lane-defs.js

@@ -0,0 +1,226 @@
+'use strict';
+/*
+ * Lane definitions — the one place a workflow is defined (D77).
+ *
+ * A lane is a kind of work. This file says, for each lane: what it is for, what goes in, which
+ * rungs the work passes, what comes out, and when it is done. The workflow engine, the lane
+ * picker, the lane write and the workspace detail pane all read THIS file. Change a lane here and
+ * every one of them changes; there is no second list to keep in step.
+ *
+ * Two kinds of field:
+ *   · prose (label, when, input, output, done) — shown to the PM, never read by the engine's rules;
+ *   · rules (track, rungs, labels) — read by the engine, so a change here changes the ladder.
+ *
+ * The engine runs under stock Node with no dependencies, and the kit vendors it by walking its
+ * relative requires, so this is a plain CommonJS module rather than a JSON file.
+ *
+ * `rungs` lists the pm-artifacts rungs a lane passes through. A rung left out reads `n/a` with the
+ * lane named as the reason, so a lane that skips a rung says so instead of showing it pending.
+ * The code profile's ladder is fixed by D56/D58/D60; its definitions here are descriptive.
+ */
+
+const PM_ALL_RUNGS = ['brief', 'draft', 'review', 'approved', 'handoff'];
+const PM_NO_HANDOFF = ['brief', 'draft', 'review', 'approved'];
+
+const PM_ARTIFACTS = {
+  'new-feature': {
+    label: 'New feature',
+    group: 'work',
+    when: 'A capability that does not exist yet.',
+    input: 'The problem, who has it, and the evidence that it is real.',
+    output: 'A product requirements document (PRD).',
+    done: 'The PRD exists, a reviewer has judged it, the PM has accepted it, and it is handed to the team or tracker.',
+    track: 'governed', rungs: PM_ALL_RUNGS, brief_label: 'problem brief', draft_label: 'PRD',
+  },
+  improvement: {
+    label: 'Feature improvement',
+    group: 'work',
+    when: 'A change to a feature that already exists.',
+    input: 'The feature as it is now, what is wrong or missing, and the measure the change should move.',
+    output: 'A change specification: what changes, what stays the same, and how to tell it worked.',
+    done: 'The change specification exists, a reviewer has judged it, the PM has accepted it, and it is handed off.',
+    track: 'governed', rungs: PM_ALL_RUNGS, brief_label: 'change brief', draft_label: 'change specification',
+  },
+  'bug-fix': {
+    label: 'Bug fix',
+    group: 'work',
+    when: 'Behaviour that is wrong against what was promised.',
+    input: 'A bug report: steps to reproduce, expected result, actual result, severity.',
+    output: 'A fix specification: the cause, the behaviour after the fix, and the check that proves it.',
+    done: 'The fix specification exists, a reviewer has judged it, the PM has accepted it, and it is handed off.',
+    track: 'light', rungs: PM_ALL_RUNGS, brief_label: 'bug report', draft_label: 'fix specification',
+  },
+  discovery: {
+    label: 'New product discovery',
+    group: 'work',
+    when: 'A question that must be answered before anyone commits to build.',
+    input: 'The question, what is unknown, and the evidence that would make this worth picking up or dropping.',
+    output: 'Findings and a recommendation: go, drop, or learn more.',
+    done: 'The findings exist, a reviewer has judged them, the PM has accepted them, and the recommendation is handed off.',
+    track: 'governed', rungs: PM_ALL_RUNGS, brief_label: 'question brief', draft_label: 'findings',
+  },
+  chore: {
+    label: 'Chore',
+    group: 'work',
+    when: 'Upkeep that needs no requirements document.',
+    input: 'One paragraph that states the intent.',
+    output: 'The change itself, with the paragraph in the record.',
+    done: 'The change is made and the PM has accepted it. Nothing is handed off.',
+    track: 'light', rungs: PM_NO_HANDOFF, brief_label: 'intent', draft_label: 'change',
+  },
+  prd: {
+    label: 'PRD (document)',
+    group: 'document',
+    when: 'A standalone requirements document that is not a new feature, an improvement or a bug fix.',
+    input: 'The brief: the question, the reader, the decision it informs.',
+    output: 'A product requirements document.',
+    done: 'The PRD exists, a reviewer has judged it, the PM has accepted it, and it is handed off.',
+    track: 'governed', rungs: PM_ALL_RUNGS, brief_label: 'brief', draft_label: 'PRD',
+  },
+  strategy: {
+    label: 'Strategy (document)',
+    group: 'document',
+    when: 'A statement of direction: where to play, how to win, what not to do.',
+    input: 'The brief: the question, the reader, the decision it informs.',
+    output: 'A strategy document.',
+    done: 'The document exists, a reviewer has judged it, the PM has accepted it, and it is handed off.',
+    track: 'governed', rungs: PM_ALL_RUNGS, brief_label: 'brief', draft_label: 'strategy document',
+  },
+  'project-plan': {
+    label: 'Project plan (document)',
+    group: 'document',
+    when: 'Who does what, by when, in what order.',
+    input: 'The scope, the people and the dates that are fixed.',
+    output: 'A project plan.',
+    done: 'The plan exists, a reviewer has judged it, the PM has accepted it, and it is handed off.',
+    track: 'governed', rungs: PM_ALL_RUNGS, brief_label: 'brief', draft_label: 'project plan',
+  },
+  'decision-record': {
+    label: 'Decision record (document)',
+    group: 'document',
+    when: 'A decision that was made and must not be re-argued.',
+    input: 'The options, the choice, and the reason.',
+    output: 'A decision record.',
+    done: 'The record exists, a reviewer has judged it, and the PM has accepted it. Nothing is handed off.',
+    track: 'light', rungs: PM_NO_HANDOFF, brief_label: 'brief', draft_label: 'decision record',
+  },
+  report: {
+    label: 'Report (document)',
+    group: 'document',
+    when: 'An account of what happened or where things stand.',
+    input: 'The period or subject, and the reader.',
+    output: 'A report.',
+    done: 'The report exists, a reviewer has judged it, and the PM has accepted it. Nothing is handed off.',
+    track: 'light', rungs: PM_NO_HANDOFF, brief_label: 'brief', draft_label: 'report',
+  },
+};
+
+/*
+ * The code profile's lanes. They share ONE ladder; a lane changes only the artifact the spec rung
+ * requires (`requires`), whether a rubric is needed, the prototype rule, and the build-path rule. Those
+ * rules are fixed by D56/D58/D60 and live in workflow-state.js; what is here is what the PM reads.
+ */
+const PRODUCT_CODE = {
+  feature: {
+    label: 'Feature',
+    group: 'work',
+    when: 'New or changed behaviour in the product.',
+    input: 'A product requirements document and an evaluation rubric, written before the build.',
+    requires: 'A PRD and a rubric, both written before the build.',
+    output: 'A pull request that satisfies the rubric.',
+    done: 'The build passes the rubric, an explainer is written, and the PM has accepted it.',
+  },
+  discovery: {
+    label: 'Discovery',
+    group: 'work',
+    when: 'A question to answer before building.',
+    input: 'A spike brief: the question and the evidence that would end the spike.',
+    requires: 'A spike brief.',
+    output: 'Findings that answer the question.',
+    done: 'The findings answer the brief and the PM has accepted them.',
+  },
+  chore: {
+    label: 'Chore',
+    group: 'work',
+    when: 'Upkeep that needs no requirements document.',
+    input: 'One paragraph that states the intent.',
+    requires: 'One paragraph of intent, written in the record\'s status.',
+    output: 'The change.',
+    done: 'The change is made and the PM has accepted it.',
+  },
+  incident: {
+    label: 'Incident',
+    group: 'work',
+    when: 'Something broke and was fixed first.',
+    input: 'A record written after the fix: what broke, the cause, the repair.',
+    requires: 'An incident record.',
+    output: 'The fix and its post-hoc record.',
+    done: 'The record states the cause and the repair, and the PM has accepted it.',
+  },
+  content: {
+    label: 'Content',
+    group: 'work',
+    when: 'Writing or media that ships with the product.',
+    input: 'A content brief. A rubric is recommended.',
+    requires: 'A content brief. A rubric is optional.',
+    output: 'The content.',
+    done: 'The content meets the brief and the PM has accepted it.',
+  },
+  prototype: {
+    label: 'Prototype',
+    group: 'work',
+    when: 'An idea the PM cannot judge from a description.',
+    input: 'A quick brief.',
+    requires: 'A quick prototype brief.',
+    output: '2–3 specimens the PM can look at. A prototype is never scored.',
+    done: 'The PM has looked at the specimens and chosen what to do with them.',
+  },
+};
+
+/*
+ * What decides each rung. This is the answer to "how does PMOS know this step is done" — one
+ * sentence per rung, shown beside the evidence in the detail pane. It restates the engine's test;
+ * the engine remains the authority, and the suite checks that every rung the engine emits has a
+ * sentence here.
+ */
+const RUNG_RULES = {
+  'pm-artifacts': {
+    route: 'The lane named in the record is one this repository offers.',
+    anchor: 'parent_kr names a KR, a declared health budget, or a domain goal that resolves.',
+    brief: 'The file named in brief_path (or prd_path) exists.',
+    draft: 'The file named in doc_path exists. On the governed track it did not first appear before the brief.',
+    review: 'evals.jsonl holds a verdict for this initiative, or the record names a reviewer in reviewed_by.',
+    approved: 'acceptances.jsonl holds an accepted line for this initiative. The PM records it; it is never automatic.',
+    handoff: 'handed_off in the record names where the work went.',
+  },
+  'product-code': {
+    route: 'The lane is one this repository offers, and its specimen and surface questions are answered.',
+    anchor: 'parent_kr names a KR, a declared health budget, or a domain goal that resolves.',
+    prototype: 'A prototype brief first appeared before the PRD, where the specimen test calls for one.',
+    understand: 'An explainer for the existing surface first appeared before the PRD.',
+    spec: 'The PRD and rubric named in the record exist and first appeared at or before the first build commit.',
+    priors: 'The record cites a prior run or states that none applies.',
+    contract: 'A run in agent-runs.jsonl holds done criteria and a test method with PM_approved set.',
+    build: 'Commits attributed to this initiative change a build path.',
+    quality: 'CI decides on the pull request. The engine never claims a test result it did not run.',
+    review: 'evals.jsonl holds a Review-Gate verdict for this initiative, or a skip.',
+    explain: 'An explainer exists for the run.',
+    accept: 'acceptances.jsonl holds an accepted line for this initiative. The PM records it.',
+    outcome: 'outcome_checks holds a validated, refuted or inconclusive disposition with evidence.',
+  },
+};
+
+function defsFor(profile) {
+  return profile === 'pm-artifacts' ? PM_ARTIFACTS : PRODUCT_CODE;
+}
+function laneNames(profile) {
+  return Object.keys(defsFor(profile));
+}
+function laneDef(profile, lane) {
+  return defsFor(profile)[lane] || null;
+}
+function rungRule(profile, key) {
+  return (RUNG_RULES[profile] || {})[key] || null;
+}
+
+module.exports = { PM_ARTIFACTS, PRODUCT_CODE, RUNG_RULES, defsFor, laneNames, laneDef, rungRule };