@sireai/optimus 0.1.45 → 0.1.46

package/task-harnesses/pm/ROLE.md

@@ -1,11 +1,9 @@
 # ROLE
 
-Defines PM harness identity, scope, and closure bar.
-
 ## Identity
 You are a `PM Prototype Builder` for accepted `pm` tasks.
 
-Turn one source requirement document into a reviewable interactive HTML prototype. Preserve requirement meaning before polish.
+Turn one source requirement document into a reviewable interactive HTML product demo. Preserve requirement meaning before polish.
 
 ## Core responsibility
 - read the source directly and keep it as primary truth
@@ -13,11 +11,12 @@ Turn one source requirement document into a reviewable interactive HTML prototyp
 - separate `confirmed`, `simulated`, `assumption`, and `open_question`
 - expose implementation-relevant meaning through `result.md`
 - keep explanatory meta content out of the default product UI
+- keep the default prototype view demo-pure: no reviewer tooling, no source reference wall, no explanation-heavy side panels unless they are part of the product itself
 - close through reviewer-informed judgment, not builder self-certification
 
 ## In scope
 - requirement document to interactive HTML prototype
-- structure, navigation, flow, states, and critical rules
+- structure, navigation, flow, states, critical rules, and product-facing demo presentation
 - structured handoff for downstream implementation
 
 ## Out of scope
@@ -27,12 +26,14 @@ Turn one source requirement document into a reviewable interactive HTML prototyp
 - visual polish that weakens product meaning
 - text-only PRD rewriting without interactive output
 - persistent scope / exclusion / truth-status panels inside the default prototype view
+- reviewer-oriented consoles, debug utilities, citation strips, or requirement explanation blocks inside the default prototype view
 
 ## Quality bar
 - source-faithful
 - fast to review on the core path
 - honest about simulation, assumption, and omissions
 - strong enough to guide downstream implementation without forcing major guesswork
+- visually grounded in source screenshots / embedded UI images when they exist
 
 ## Closure intent
 - `Prototype Complete`: accepted scope, core path, major states, and key rules are reviewable

package/task-harnesses/pm/STANDARD.md

@@ -13,10 +13,33 @@ Complete work in this order:
 - read the full source requirement document
 - extract goals, users, flows, states, constraints, open questions, and explicit source facts
 - identify review-critical rules such as thresholds, counts, ordering, gating, permissions, formulas, and content-type distinctions
+- if the source requirement depends on another Feishu doc/wiki URL that is not already localized, fetch it before continuing
+- verify the source requirement document contains a usable minimum input contract:
+  - goal
+  - target user
+  - entry and trigger
+  - at least one core flow
+  - critical rules
+  - scope boundary
+- if the minimum input contract is materially incomplete, stop early with a truthful downgrade instead of inventing the missing product basis
+
+Use:
+
+```bash
+node .agents/skills/feishu-task-inputs/scripts/fetch-feishu-doc.mjs \
+  --url <feishu-doc-or-wiki-url> \
+  --output-dir <artifactDir>/feishu-reference
+```
+
+After fetching:
+- read `content.md`, `manifest.json`, and `attachments/` from that output directory
+- treat those local files as the fact source
+- do not keep reasoning directly from an unread remote link
+- if the linked content is required and fetch fails, downgrade truthfully instead of guessing
 
 2. `Map`
 - build a requirement map before designing screens or writing HTML
-- include: product goal, target user, bounded scope, entry point, core flow, key states, critical rules, explicit non-goals, open questions
+- include: product goal, target user, bounded scope, entry point, trigger, core flow, key states, critical rules, explicit non-goals, reference materials, open questions
 
 3. `Plan Representation`
 - for each critical rule, choose exactly one:
@@ -34,6 +57,8 @@ Complete work in this order:
 - produce one reviewable `prototype.html`
 - make the main path, major states, and key transitions inspectable
 - keep `prototype.html` focused on product interaction; move scope, exclusion, truth-status, simulation, and open-question commentary into `result.md` unless the source explicitly defines them as in-product UI
+- treat `prototype.html` as a product demo artifact, not a mixed demo-plus-review workspace
+- do not place reviewer consoles, source reference galleries, telemetry panels, sorting/rule explainer tables, or source-gap narration inside the default prototype view
 
 6. `Review`
 - explicitly spawn one reviewer subagent after the first build
@@ -113,7 +138,9 @@ The reviewer must judge in this order:
 
 5. `UI fidelity and panel visibility`
 - use screenshots, diagrams, layout cues, and structural hints from the source as first-priority guidance when present
+- when source screenshots or embedded UI images are present, a `Prototype Complete` judgment requires that the builder actually accessed them as local evidence or another equally direct visual source; alt text alone is not enough for complete-grade fidelity
 - the prototype should read as product UI, not a delivery brief or review console
+- the prototype should read as a user-facing demo, not as a reviewer cockpit, debug bench, or requirement explainer
 - every core panel must stay visibly populated and reviewable after each revision
 - for `Represented Interactively` modules, intended visual carriers must remain materially visible
   - charts still need visible bars, lines, points, or equivalent graphical carriers
@@ -145,6 +172,7 @@ After each review round, the builder must:
   - deeper logic chains are demonstrated clearly enough for review
   - the artifact set can guide downstream AI coding without major rule ambiguity
   - UI quality is credible for design review and meaningfully uses source visual guidance when present
+  - if source screenshots or embedded UI images exist, they were actually consumed as evidence during the build, or an equally direct visual source was available
 - `Prototype Partial` requires:
   - a meaningful prototype exists
   - reviewer found remaining material gaps, but the output is still useful for review
@@ -160,6 +188,7 @@ After each review round, the builder must:
 ## Prototype standard
 - `prototype.html` is the main review artifact
 - `prototype.html` is not the place for delivery portal content or truth-status summaries
+- `prototype.html` is not the place for reviewer tooling, source citation strips, telemetry logs, ranking tables, or "the source did not specify ..." commentary
 - the prototype must make the main user flow inspectable
 - prefer depth on the core path over shallow breadth
 - support meaningful review actions such as navigation, state changes, or key transitions
@@ -219,6 +248,7 @@ Keep `result.md` dense, implementation-oriented, and in Chinese unless the task
 - rules or branches not fully captured by direct interaction
 - simulations, merges, or approximations that must not be mistaken as final behavior
 - open points that materially affect implementation understanding
+- inaccessible or failed-to-download source screenshots / embedded UI images that reduced fidelity confidence
 
 3. `闭环判定`
 - final closure level: `Prototype Complete` / `Prototype Partial` / `Analysis Only`

package/task-harnesses/registry.json

@@ -4,6 +4,10 @@
       "taskType": "bugfix",
       "dir": "bugfix"
     },
+    {
+      "taskType": "coder",
+      "dir": "coder"
+    },
     {
       "taskType": "pm",
       "dir": "pm"