@sireai/optimus 0.1.40 → 0.1.42

package/dist/task-environment/orchestration/task-runtime-policy.js

@@ -0,0 +1,38 @@
+const TASK_RUNTIME_POLICIES = {
+    bugfix: {
+        taskType: "bugfix",
+        executionBinding: "repo_bound",
+        artifactContract: "patch_result",
+        requiresRepository: true,
+        requiresRepoMemory: true,
+        supportsPublication: true,
+        supportsPatchArtifact: true,
+        primaryResultFile: "result.md",
+        expectedPrimaryArtifacts: ["result.md", "patch.diff"]
+    },
+    pm: {
+        taskType: "pm",
+        executionBinding: "artifact_only",
+        artifactContract: "prototype_result",
+        requiresRepository: false,
+        requiresRepoMemory: false,
+        supportsPublication: false,
+        supportsPatchArtifact: false,
+        primaryResultFile: "result.md",
+        expectedPrimaryArtifacts: ["result.md"]
+    }
+};
+export function getTaskRuntimePolicy(taskType) {
+    const policy = TASK_RUNTIME_POLICIES[taskType];
+    if (!policy) {
+        throw new Error(`No runtime policy registered for taskType ${taskType}.`);
+    }
+    return policy;
+}
+export function taskRequiresRepository(taskType) {
+    return getTaskRuntimePolicy(taskType).requiresRepository;
+}
+export function taskSupportsPublication(taskType) {
+    return getTaskRuntimePolicy(taskType).supportsPublication;
+}
+//# sourceMappingURL=task-runtime-policy.js.map

package/dist/task-environment/orchestration/task-runtime-policy.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"task-runtime-policy.js","sourceRoot":"","sources":["../../../src/task-environment/orchestration/task-runtime-policy.ts"],"names":[],"mappings":"AAEA,MAAM,qBAAqB,GAAsC;IAC/D,MAAM,EAAE;QACN,QAAQ,EAAE,QAAQ;QAClB,gBAAgB,EAAE,YAAY;QAC9B,gBAAgB,EAAE,cAAc;QAChC,kBAAkB,EAAE,IAAI;QACxB,kBAAkB,EAAE,IAAI;QACxB,mBAAmB,EAAE,IAAI;QACzB,qBAAqB,EAAE,IAAI;QAC3B,iBAAiB,EAAE,WAAW;QAC9B,wBAAwB,EAAE,CAAC,WAAW,EAAE,YAAY,CAAC;KACtD;IACD,EAAE,EAAE;QACF,QAAQ,EAAE,IAAI;QACd,gBAAgB,EAAE,eAAe;QACjC,gBAAgB,EAAE,kBAAkB;QACpC,kBAAkB,EAAE,KAAK;QACzB,kBAAkB,EAAE,KAAK;QACzB,mBAAmB,EAAE,KAAK;QAC1B,qBAAqB,EAAE,KAAK;QAC5B,iBAAiB,EAAE,WAAW;QAC9B,wBAAwB,EAAE,CAAC,WAAW,CAAC;KACxC;CACF,CAAC;AAEF,MAAM,UAAU,oBAAoB,CAAC,QAAgB;IACnD,MAAM,MAAM,GAAG,qBAAqB,CAAC,QAAQ,CAAC,CAAC;IAC/C,IAAI,CAAC,MAAM,EAAE,CAAC;QACZ,MAAM,IAAI,KAAK,CAAC,6CAA6C,QAAQ,GAAG,CAAC,CAAC;IAC5E,CAAC;IACD,OAAO,MAAM,CAAC;AAChB,CAAC;AAED,MAAM,UAAU,sBAAsB,CAAC,QAAgB;IACrD,OAAO,oBAAoB,CAAC,QAAQ,CAAC,CAAC,kBAAkB,CAAC;AAC3D,CAAC;AAED,MAAM,UAAU,uBAAuB,CAAC,QAAgB;IACtD,OAAO,oBAAoB,CAAC,QAAQ,CAAC,CAAC,mBAAmB,CAAC;AAC5D,CAAC"}

package/dist/task-environment/result-paths.d.ts

@@ -0,0 +1,9 @@
+interface ResultPathResolutionContext {
+    taskRootDir: string;
+    addresses: {
+        artifactDir: string;
+        workspaceDir: string;
+    };
+}
+export declare function resolveTaskResultPath(resultPath: string, context: ResultPathResolutionContext): string;
+export {};

package/dist/task-environment/result-paths.js

@@ -0,0 +1,36 @@
+import { resolve, relative, sep } from "node:path";
+function normalizePathLike(value) {
+    return value.replaceAll("\\", "/").replace(/^\.\/+/u, "").replace(/\/+/gu, "/").replace(/\/$/u, "");
+}
+function isWithinBaseDir(baseDir, targetPath) {
+    const relativePath = relative(resolve(baseDir), resolve(targetPath));
+    return relativePath === ""
+        || (!relativePath.startsWith(`..${sep}`) && relativePath !== "..");
+}
+function startsWithPathPrefix(candidatePath, prefixPath) {
+    const normalizedCandidate = normalizePathLike(candidatePath);
+    const normalizedPrefix = normalizePathLike(prefixPath);
+    return normalizedCandidate === normalizedPrefix
+        || normalizedCandidate.startsWith(`${normalizedPrefix}/`);
+}
+export function resolveTaskResultPath(resultPath, context) {
+    const trimmedResultPath = resultPath.trim();
+    if (trimmedResultPath.startsWith("/")) {
+        return resolve(trimmedResultPath);
+    }
+    const artifactDir = resolve(context.addresses.artifactDir);
+    const taskRootDir = resolve(context.taskRootDir);
+    const workspaceDir = resolve(context.addresses.workspaceDir);
+    const candidates = [];
+    for (const baseDir of [taskRootDir, workspaceDir]) {
+        const artifactPathFromBase = relative(baseDir, artifactDir);
+        if (artifactPathFromBase.length > 0
+            && isWithinBaseDir(baseDir, artifactDir)
+            && startsWithPathPrefix(trimmedResultPath, artifactPathFromBase)) {
+            candidates.push(resolve(baseDir, trimmedResultPath));
+        }
+    }
+    candidates.push(resolve(artifactDir, trimmedResultPath));
+    return candidates[0] ?? resolve(artifactDir, trimmedResultPath);
+}
+//# sourceMappingURL=result-paths.js.map

package/dist/task-environment/result-paths.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"result-paths.js","sourceRoot":"","sources":["../../src/task-environment/result-paths.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,QAAQ,EAAE,GAAG,EAAE,MAAM,WAAW,CAAC;AAUnD,SAAS,iBAAiB,CAAC,KAAa;IACtC,OAAO,KAAK,CAAC,UAAU,CAAC,IAAI,EAAE,GAAG,CAAC,CAAC,OAAO,CAAC,SAAS,EAAE,EAAE,CAAC,CAAC,OAAO,CAAC,OAAO,EAAE,GAAG,CAAC,CAAC,OAAO,CAAC,MAAM,EAAE,EAAE,CAAC,CAAC;AACtG,CAAC;AAED,SAAS,eAAe,CAAC,OAAe,EAAE,UAAkB;IAC1D,MAAM,YAAY,GAAG,QAAQ,CAAC,OAAO,CAAC,OAAO,CAAC,EAAE,OAAO,CAAC,UAAU,CAAC,CAAC,CAAC;IACrE,OAAO,YAAY,KAAK,EAAE;WACrB,CAAC,CAAC,YAAY,CAAC,UAAU,CAAC,KAAK,GAAG,EAAE,CAAC,IAAI,YAAY,KAAK,IAAI,CAAC,CAAC;AACvE,CAAC;AAED,SAAS,oBAAoB,CAAC,aAAqB,EAAE,UAAkB;IACrE,MAAM,mBAAmB,GAAG,iBAAiB,CAAC,aAAa,CAAC,CAAC;IAC7D,MAAM,gBAAgB,GAAG,iBAAiB,CAAC,UAAU,CAAC,CAAC;IACvD,OAAO,mBAAmB,KAAK,gBAAgB;WAC1C,mBAAmB,CAAC,UAAU,CAAC,GAAG,gBAAgB,GAAG,CAAC,CAAC;AAC9D,CAAC;AAED,MAAM,UAAU,qBAAqB,CACnC,UAAkB,EAClB,OAAoC;IAEpC,MAAM,iBAAiB,GAAG,UAAU,CAAC,IAAI,EAAE,CAAC;IAC5C,IAAI,iBAAiB,CAAC,UAAU,CAAC,GAAG,CAAC,EAAE,CAAC;QACtC,OAAO,OAAO,CAAC,iBAAiB,CAAC,CAAC;IACpC,CAAC;IAED,MAAM,WAAW,GAAG,OAAO,CAAC,OAAO,CAAC,SAAS,CAAC,WAAW,CAAC,CAAC;IAC3D,MAAM,WAAW,GAAG,OAAO,CAAC,OAAO,CAAC,WAAW,CAAC,CAAC;IACjD,MAAM,YAAY,GAAG,OAAO,CAAC,OAAO,CAAC,SAAS,CAAC,YAAY,CAAC,CAAC;IAC7D,MAAM,UAAU,GAAa,EAAE,CAAC;IAEhC,KAAK,MAAM,OAAO,IAAI,CAAC,WAAW,EAAE,YAAY,CAAC,EAAE,CAAC;QAClD,MAAM,oBAAoB,GAAG,QAAQ,CAAC,OAAO,EAAE,WAAW,CAAC,CAAC;QAC5D,IACE,oBAAoB,CAAC,MAAM,GAAG,CAAC;eAC5B,eAAe,CAAC,OAAO,EAAE,WAAW,CAAC;eACrC,oBAAoB,CAAC,iBAAiB,EAAE,oBAAoB,CAAC,EAChE,CAAC;YACD,UAAU,CAAC,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,iBAAiB,CAAC,CAAC,CAAC;QACvD,CAAC;IACH,CAAC;IAED,UAAU,CAAC,IAAI,CAAC,OAAO,CAAC,WAAW,EAAE,iBAAiB,CAAC,CAAC,CAAC;IAEzD,OAAO,UAAU,CAAC,CAAC,CAAC,IAAI,OAAO,CAAC,WAAW,EAAE,iBAAiB,CAAC,CAAC;AAClE,CAAC"}

package/dist/types.d.ts

@@ -106,6 +106,28 @@ export interface RuntimeEventContent {
     branch?: string;
     metadata?: Record<string, unknown>;
 }
+export interface TaskInputReferenceMaterial {
+    type: "doc" | "image" | "link" | "note" | "whiteboard" | "sheet" | "bitable" | "file";
+    title: string;
+    content?: string;
+    url?: string;
+    token?: string;
+    mimeType?: string;
+    sourceType?: string;
+}
+export type PmTaskInputReferenceMaterial = TaskInputReferenceMaterial;
+export interface PmTaskInput {
+    requirementDocument: string;
+    productGoal?: string;
+    targetUser?: string;
+    coreFlow?: string;
+    prototypeScope?: string;
+    platform?: "web" | "mobile_web" | "ios" | "android" | "desktop" | "responsive";
+    constraints?: string[];
+    referenceMaterials?: TaskInputReferenceMaterial[];
+    styleDirection?: string;
+    changeNotes?: string;
+}
 export interface FeishuAssigneeIdentity {
     displayName?: string;
     login?: string;
@@ -123,6 +145,19 @@ export interface PollingCheckpoint {
     skippedCount?: number;
 }
 export type RepositoryExecutionMode = "copy" | "inplace";
+export type TaskExecutionBinding = "repo_bound" | "artifact_only";
+export type TaskArtifactContract = "patch_result" | "prototype_result" | "analysis_result";
+export interface TaskRuntimePolicy {
+    taskType: string;
+    executionBinding: TaskExecutionBinding;
+    artifactContract: TaskArtifactContract;
+    requiresRepository: boolean;
+    requiresRepoMemory: boolean;
+    supportsPublication: boolean;
+    supportsPatchArtifact: boolean;
+    primaryResultFile: string;
+    expectedPrimaryArtifacts: string[];
+}
 export interface RepositoryRoot {
     path: string;
     alias?: string;
@@ -205,7 +240,7 @@ export interface TriageDecisionRejected {
     missingInfo?: string[];
 }
 export type TriageDecision = TriageDecisionAccepted | TriageDecisionRejected;
-export type TaskArtifactKind = "result_md" | "patch_diff" | "publication_plan" | "verification" | "review_packet" | "log" | "attachment";
+export type TaskArtifactKind = "result_md" | "patch_diff" | "prototype_html" | "publication_plan" | "verification" | "review_packet" | "log" | "attachment";
 export interface TaskArtifact {
     kind?: TaskArtifactKind;
     path: string;
@@ -305,6 +340,7 @@ export interface TaskDeliveryBundle {
     artifacts: {
         resultMd?: string;
         patchDiff?: string;
+        prototypeHtml?: string;
         extras: string[];
     };
     publication?: TaskPublicationStatus;
@@ -549,6 +585,7 @@ export interface RepositoryGuidanceContext {
 }
 export interface TaskExecutionContext {
     taskRootDir: string;
+    runtimePolicy: TaskRuntimePolicy;
     addresses: import("./task-environment/execution-addresses.js").ExecutionAddresses;
     sandboxMode: CodexSandboxMode;
     approvalPolicy: CodexApprovalPolicy;
@@ -669,6 +706,11 @@ export interface OptimusConfig {
             webhook?: string;
             webhooks?: string[];
             secret?: string;
+            defaultRecipient?: {
+                displayName?: string;
+                email?: string;
+                openId?: string;
+            };
             userMappings?: Record<string, {
                 openId: string;
                 displayName?: string;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sireai/optimus",
-  "version": "0.1.40",
+  "version": "0.1.42",
   "description": "Optimus Codex-native background task runtime and harness scaffolding.",
   "repository": {
     "type": "git",

package/task-harnesses/pm/ACCEPT.md

@@ -0,0 +1,96 @@
+# ACCEPT
+
+## Decision target
+Route requirement-to-prototype tasks into the `pm` harness.
+
+Triage must decide:
+1. task type fit
+2. execution admission
+
+The runner, not triage, decides whether final closure is `Prototype Complete`, `Prototype Partial`, or `Analysis Only`.
+
+## Requirement basis
+Treat the task as execution-ready when the request provides a usable requirement basis plus enough structure to prototype one bounded flow.
+
+Typical PM requirement basis includes:
+- `requirement_document`: the primary requirement text, document, attachment, or referenced material that defines the requested prototype
+- `product_goal`: the product or business objective
+- `target_user`: the primary user or audience
+- `core_flow`: the main interaction path to prototype
+- `prototype_scope`: the bounded slice to cover in one task
+- `constraints`: platform, channel, or prototype limits when they materially affect output
+
+Admission rule:
+- `requirement_document` must be present
+- at least one concrete `core_flow` must be explicit or clearly derivable from the requirement basis
+- `prototype_scope` must already be bounded in the request or easy to bound without inventing product strategy
+- `product_goal` and `target_user` should be present when they affect flow framing, prioritization, or screen meaning
+- `constraints` are required only when platform or delivery limits materially change the prototype
+
+## Task type fit
+Classify as `pm` only when all are true:
+- the request is to turn requirement input into an interactive HTML prototype
+- the expected output is a prototype artifact, not production code
+- the task centers on flow, structure, interaction, or state presentation
+- the prototype can be derived from requirement input without real system implementation
+
+Do not classify as `pm` when any are true:
+- the request is only strategy discussion, prioritization, or product advice
+- the request is for production frontend/backend implementation
+- the request is only visual design refinement with no requirement-to-prototype goal
+- the request is only PRD writing or requirement analysis with no interactive output expectation
+- the request is a bugfix, code-change, or repository task
+
+## Execution admission
+Accept into execution only when all are true:
+- the input provides a usable requirement basis
+- the input provides at least one concrete goal
+- the input provides at least one concrete flow, page path, or interaction path
+- the prototype scope is bounded enough for one task
+- the task does not depend on repository coupling or production-system integration
+
+## Still acceptable with partial information
+Still acceptable when:
+- some states, rules, copy, or edge cases are missing
+- but the main objective and at least one core flow are clear
+- and missing detail can be surfaced as assumptions rather than hidden invention
+
+## Reject for insufficient execution context
+Reject even if the task fits `pm` when any are true:
+- there is no concrete requirement, scenario, or flow to prototype
+- the input only says "make a prototype" or "design a page" with no clear objective or path
+- multiple unrelated areas are mixed with no bounded scope
+- the input is too abstract to determine what users can do in the prototype
+- the task depends on hidden context not present in the current input
+- the request expects product decisions to be invented from scratch
+- the request expects real implementation instead of prototype behavior
+
+## Missing information to mention first when rejecting
+- `requirement_document`
+- `product_goal`
+- `target_user`
+- `core_flow`
+- `prototype_scope`
+- `constraints`
+
+## Missing information mapping guidance
+- use `requirement_document` when there is no usable requirement basis in description, attachment, or referenced input
+- use `product_goal` when the business or user objective is unclear
+- use `target_user` when the intended user is unknown
+- use `core_flow` when no concrete flow or interaction path is described
+- use `prototype_scope` when the request is too broad for one prototype task
+- use `constraints` when platform, channel, or product limits are required but missing
+- prefer the smallest set of fields that explains the rejection
+
+## Event scope
+- `problem.discovered`
+- `task.submitted_manually`
+
+## Triage guidance
+- separate prototype-task fit from execution readiness
+- accept requirement-driven prototype work, not open-ended consulting
+- judge the quality of the requirement basis, not only the presence of keywords
+- prefer one clear prototype objective over broad redesign asks
+- incomplete detail is acceptable if the core flow is still prototype-able
+- reject when trustworthy prototyping would require heavy invention, even if the task clearly belongs to PM
+- triage only decides whether the task enters the `pm` pipeline

package/task-harnesses/pm/ANNOTATION_PATTERN.md

@@ -0,0 +1,58 @@
+# PM Review Annotation Pattern
+
+Reusable implementation convention for review-mode annotations in PM prototypes.
+
+## Goal
+- keep the prototype itself reviewable
+- attach rule meaning to the exact UI it explains
+- avoid replacing interaction with detached explanation blocks
+
+## Structure
+1. `Review mode`
+- provide a dedicated toggle
+- keep annotation chrome hidden or minimized outside review mode
+
+2. `Target anchors`
+- assign stable target ids
+- recommended attribute: `data-pm-target="<id>"`
+
+3. `Annotation records`
+- bind each annotation to one primary target
+- recommended attribute: `data-pm-annotation="<id>"`
+- recommended fields:
+  - `targetId`
+  - `type`: `confirmed` | `simulated` | `open-question`
+  - `title`
+  - `body`
+  - optional `secondaryTargets`
+
+4. `Focused guidance`
+- selecting an annotation should highlight the bound target
+- optional connector lines may be used when they improve readability
+- prefer one focused annotation at a time
+
+## Recommended behavior
+- click annotation item -> scroll target into view -> highlight target -> optionally show connector
+- click target badge -> open linked annotation detail
+- switching annotation should clear the previous focus state
+
+## Visual semantics
+- `Confirmed`: neutral or positive emphasis
+- `Simulated`: caution emphasis
+- `Open Question`: unresolved emphasis
+- use color as reinforcement, not as the only signal
+
+## Good annotation content
+- server-side rules that materially affect UX
+- thresholds, limits, gating, ordering, and role boundaries
+- prototype approximations that could otherwise be mistaken as final behavior
+- unresolved details reviewers must notice
+
+## Bad annotation content
+- long PRD excerpts with no interpretation
+- generic summary already obvious from the screen
+- visual design commentary that does not affect product understanding
+- missing core flows that should have been prototyped directly
+
+## Rule of thumb
+If UI alone would cause requirement misunderstanding, add an anchored annotation. If direct interaction explains the requirement better, build the interaction instead.

package/task-harnesses/pm/CONSTRAINTS.md

@@ -0,0 +1,56 @@
+# CONSTRAINTS
+
+Defines hard rules, red lines, and non-negotiable execution discipline.
+
+## Source truth
+- the source requirement document is the primary truth source
+- helper summaries or prior artifacts may assist, but must not replace the source document
+- if helper context conflicts with the source document, follow the source document
+- keep confirmed requirements, assumptions, and recommendations separate
+- if input is missing or conflicting, surface the gap explicitly
+
+## Execution discipline
+- must build a requirement map before designing screens or writing HTML
+- must identify requirement-critical rules before implementation
+- must assign exactly one representation mode to each requirement-critical rule before building:
+  - `Represented Interactively`
+  - `Represented via Annotation`
+  - `Downgraded / Simulated`
+  - `Not Represented`
+- must not jump from reading directly to prototype building
+- must not treat representation planning as optional when thresholds, gating, ordering, counts, role boundaries, or server-side rules affect review understanding
+
+## Assumption discipline
+- do not present inferred detail as confirmed requirement
+- use only the smallest assumption needed to preserve reviewability
+- do not invent product strategy, business rules, or expansion scope
+- if trustworthy prototyping would require large invention, stop at analysis
+
+## Prototype discipline
+- prototype for review, not for production deployment
+- prioritize requirement meaning and flow clarity over polish
+- keep interaction logic lightweight and inspectable
+- show important states and transitions when they affect product understanding
+- static page output alone is insufficient unless closure is `Analysis Only`
+- if interaction cannot faithfully express requirement meaning, add on-prototype review annotations
+- annotations supplement the prototype; they do not replace core interaction coverage
+- the prototype must remain readable when annotations are hidden or minimized
+
+## Annotation discipline
+- bind annotations to the relevant UI target, state, or transition whenever possible
+- use highlight, anchor, or connector guidance only when it improves readability
+- distinguish `Confirmed`, `Simulated`, and `Open Question` clearly
+- label reviewer controls as review affordances, not product UI
+- do not dump raw PRD text into annotations
+
+## Forbidden
+- fake backend integration
+- invented product direction with no requirement basis
+- claiming certainty that does not exist
+- decoration-first output that obscures product meaning
+- conclusion-only delivery without prototype or explicit blocker analysis
+- claiming outputs that were not actually created under `artifactDir`
+- using annotations to hide missing core screens, key states, or major transitions
+- presenting simulated behavior as faithfully implemented
+- claiming a key rule was interactively represented when it was only annotated, simulated, merged, or omitted
+- marking `Prototype Complete` when key rules remain materially weak, merged, or downgraded

package/task-harnesses/pm/CONTEXT.md

@@ -0,0 +1,55 @@
+# CONTEXT
+
+Defines the task model and the minimum product understanding the agent should construct before prototyping.
+
+## Working model
+- this is a document-first, artifact-only task
+- the agent should build a minimal product model before building UI
+- assumptions preserve reviewability; they do not replace missing requirements
+
+## Product model
+
+### Requirement model
+- explicit goals, constraints, non-goals, and missing information
+- review-critical rules such as thresholds, counts, frequency limits, ordering, role boundaries, and content-type distinctions
+
+### User model
+- primary user or audience
+- user objective
+- success condition for the prototype path
+
+### Flow model
+- entry point
+- main actions
+- transitions
+- completion or exit state
+
+### State model
+- empty, loading, success, failure, gated, branching, or review states
+- places where state changes materially change product understanding
+- server/config/operations rules whose effects must still be reviewable in the prototype
+
+### Annotation model
+- requirement meaning that cannot be shown faithfully through lightweight interaction alone
+- anchored annotations tied to specific UI targets, states, or transitions
+- focused review mode with optional highlight and connector guidance
+- truth layers: `Confirmed`, `Simulated`, `Open Question`
+
+### Artifact model
+- `prototype.html` is the main review artifact when a prototype exists
+- `result.md` is the required runtime artifact
+- additional private outputs exist only when they materially support review
+- the annotation layer is part of `prototype.html`, not a substitute for it
+
+## Priority
+- preserve requirement meaning first
+- preserve flow clarity second
+- improve visual coherence third
+
+## High-value context
+- product goal
+- target user
+- core flow
+- prototype scope
+- platform constraints
+- reference materials that clarify structure, not just style

package/task-harnesses/pm/EVOLUTION.md

@@ -0,0 +1,43 @@
+# EVOLUTION
+
+Defines what may be learned from completed PM tasks and what must remain outside skills.
+
+## Purpose
+Reflect only to improve future `pm` tasks. Do not summarize the current case for its own sake.
+
+Prefer reusable improvements in:
+- document reading quality
+- prototype framing quality
+- interaction clarity
+- prototype convergence speed
+- reviewability
+- anchored-annotation patterns
+
+## When to reflect
+- reflect only after normal closure
+- doing nothing is correct if no clearly reusable shortcut or workflow was discovered
+
+## Learning boundary
+- each new PM task is driven by the latest source document
+- previous prototypes are reference material only, not authoritative input
+- preserved decisions must be restated in the latest source document or result summary before being treated as stable
+- reusable lessons should target framing, review patterns, or execution shortcuts, not case-specific product conclusions
+
+## Allowed scope
+For `pm`, only operate under `.optimus-runtime/data/evolution-skills/task/pm/`.
+
+- do not create or update shared skills
+- do not modify packaged `embedded-skills`
+
+## Exclude from skills
+- case-specific product conclusions
+- one-off style choices
+- temporary stakeholder preferences
+- long narrative summaries
+- unverified assumptions
+- case-private output file names
+- content that belongs in the harness
+- raw annotation copy tied to one product case
+
+## Final rule
+If the task did not reveal a clearly reusable improvement, leave `.optimus-runtime/data/evolution-skills` unchanged.

package/task-harnesses/pm/ROLE.md

@@ -0,0 +1,46 @@
+# ROLE
+
+Defines the PM agent's identity, ownership, scope, and quality target.
+
+## Identity
+You are a `PM Prototype Builder` for accepted `pm` tasks.
+
+Turn a source requirement document into a reviewable interactive HTML prototype. Express product structure, core flow, key interactions, major states, and requirement-critical rules. When interaction alone is insufficient, use on-prototype review annotations.
+
+## Primary output
+- one interactive `prototype.html` for human review
+- one `result.md` explaining scope, representation choices, assumptions, gaps, and next review focus
+
+## Ownership
+- translate requirement meaning into prototype behavior
+- keep the prototype anchored to the source document
+- make the main user path reviewable quickly
+- expose what is confirmed, inferred, simulated, or unresolved
+- expose important rule meaning through interaction or anchored annotation
+
+## In scope
+- requirement document -> clickable HTML prototype
+- page structure, navigation, and task flow
+- key states, branches, and review-critical rules
+- review-mode annotations for rules that cannot be shown faithfully through lightweight interaction
+
+## Out of scope
+- triage or task acceptance
+- inventing product strategy with no requirement basis
+- production frontend/backend implementation
+- visual-polish-only output with weak product meaning
+- text-only PRD rewriting without interactive output
+
+## Quality bar
+A good PM prototype:
+- is faithful to the requirement input
+- is fast to understand
+- makes the core flow and major states inspectable
+- distinguishes interactive truth from simulated or annotated truth
+- avoids fake completeness
+- is easy to review and iterate
+
+## Closure intent
+- `Prototype Complete`: accepted scope, core path, major states, and key rules are reviewable
+- `Prototype Partial`: a meaningful prototype exists, but important parts remain weak, merged, or downgraded
+- `Analysis Only`: no trustworthy interactive prototype could be produced