@sireai/optimus 0.1.44 → 0.1.46

package/task-harnesses/pm/ROLE.md

@@ -1,15 +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.
-
-## Required outputs
-- `prototype.html`: the main review artifact
-- `result.md`: dense rule supplement for downstream implementation
+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
@@ -17,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
@@ -31,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

@@ -2,6 +2,10 @@
 
 Defines the mandatory PM execution flow, artifact contract, and delivery standard.
 
+### Required outputs
+- `prototype.html`: the main review artifact
+- `result.md`: dense rule supplement for downstream implementation
+
 ## Execution sequence
 Complete work in this order:
 
@@ -9,19 +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:
@@ -39,25 +57,15 @@ 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
-- reviewer input must include:
-  - source requirement document
-  - source URL when available
-  - accepted scope
-  - requirement map
-  - representation plan
-  - `prototype.html` when present
-  - `result.md`
-  - previous review findings and builder revisions when this is round 2 or 3
-  - current round number and maximum round count
+- reviewer input must include the source requirement document, source URL when available, accepted scope, requirement map, representation plan, `prototype.html` when present, `result.md`, current round number, and maximum round count
+- include previous reviewer findings and builder revisions in rounds 2 and 3
 - reviewer must judge against the reviewer rubric defined below
-- record one review round log entry containing:
-  - round number
-  - reviewer verdict
-  - key gaps
-  - recommended revisions or explicit approval
+- record one review round log entry with round number, reviewer verdict, key gaps, and recommended revisions or explicit approval
 - if reviewer subagent invocation fails, log the failure, skip the reviewer loop for this run, and continue normal artifact finalization; do not hang waiting for the reviewer path to recover
 
 7. `Revise`
@@ -68,10 +76,7 @@ Complete work in this order:
   - another revise-and-review pass is unlikely to improve trustworthiness materially
 - if the final reviewer verdict still finds material gaps after the maximum rounds, downgrade closure instead of looping further
 - the builder must read the latest reviewer output before revising
-- each new review round must include:
-  - the previous reviewer findings
-  - what the builder changed
-  - what the builder intentionally did not change and why
+- each new review round must include the previous reviewer findings, what changed, and what was intentionally not changed and why
 
 8. `Deliver`
 - generate `result.md`
@@ -80,59 +85,21 @@ Complete work in this order:
 
 If execution stops early, explain which step could not be completed and why.
 
-## Review loop standard
-- the reviewer subagent must be explicitly requested; do not assume it will appear automatically
-- the reviewer must not rewrite the prototype directly; it judges and recommends
-- the builder applies revisions and owns the updated artifacts
-- provide the reviewer with facts first, not builder conclusions first
-- the reviewer should treat the source requirement and produced artifacts as primary evidence; builder framing is supporting context only
-- reviewer findings do not justify unlimited scope growth, denser chrome, or extra speculative screens by default
-- each review round should classify every material finding as one of:
+## Reviewer protocol
+- the reviewer subagent must be explicitly requested; it is a judge, not a builder
+- provide facts first: source requirement, source URL when available, accepted scope, produced artifacts, then builder framing
+- required reviewer inputs: requirement document, source URL when available, accepted scope, requirement map, representation plan, `prototype.html` when present, `result.md`, current round number, maximum rounds, and prior findings/revisions for rounds 2 and 3
+- reviewer findings do not justify unlimited scope growth, denser chrome, or speculative screens by default
+- each review round must classify material findings as:
   - `Must Fix Before Complete`
   - `Can Ship As Partial`
   - `Open Question`
-- examples of `Must Fix Before Complete`:
-  - missing core flow coverage
-  - important requirement content is omitted, misunderstood, or inconsistent with the source document
-  - missing or materially wrong key rule representation
-  - deeper business or interaction logic is only described textually and not demonstrated clearly enough through the prototype
-  - explicit source fact drift that changes review interpretation
-  - simulated behavior presented as if it were faithful interaction
-  - the artifact set is too weak to guide downstream AI coding without major guessing about rules, state behavior, or implementation intent
-  - UI quality is materially below design-review expectations, especially when the requirement document already contains screenshots, diagrams, or strong structural visual cues that were not meaningfully used
-- examples of `Can Ship As Partial`:
-  - useful prototype exists, but some non-core states remain merged or downgraded
-  - some important but secondary rules remain simulated or unresolved in direct interaction
-  - the core design direction is usable, but parts of the visual system or interaction polish still fall below designer-grade expectations
-- examples of `Open Question`:
-  - requirement ambiguity prevents stronger representation without invention
-
-## Reviewer input contract
-Each reviewer round should receive these inputs in this priority order:
-
-1. `Source facts`
-- requirement document
-- source URL when available
-- explicit accepted scope
-
-2. `Produced artifacts`
-- `prototype.html` when present
-- `result.md`
-
-3. `Builder framing`
-- requirement map
-- representation plan
-- declared deviations, simulations, and unresolved points
-
-4. `Round context`
-- current round number
-- maximum rounds: `3`
-- previous reviewer findings and builder revisions for rounds 2 and 3
-
-## Reviewer output contract
-Each reviewer round must produce a compact review record that the builder can consume directly.
-
-Minimum fields:
+- `Must Fix Before Complete` covers missing or wrong core flow/rule coverage, source inconsistency, weak logic demonstration, misleading simulation, artifact weakness that blocks downstream AI coding, or materially subpar UI fidelity against available source cues
+- `Can Ship As Partial` covers useful but incomplete review artifacts: merged non-core states, simulated secondary rules, or design quality gaps that do not destroy core reviewability
+- `Open Question` covers requirement ambiguity that cannot be resolved without invention
+
+## Reviewer record
+Each review round must produce a compact record with:
 - `Round`
 - `Reviewer Verdict`
 - `Coverage Assessment`
@@ -151,61 +118,50 @@ Allowed `Reviewer Verdict` values:
 - `Can Ship As Partial`
 - `Approved for Prototype Complete`
 
-## Builder handoff contract
-After each review round, the builder must:
-- read the full reviewer output
-- revise the prototype and companion artifacts when `Must Fix Before Complete` findings exist
-- preserve unresolved but non-blocking findings inside `result.md` when closure remains partial
-- run a full core-panel self-check before requesting the next review, not only a point fix for the previous `Must Fix`
-- prefer downgrade over another revise round when the next change would require speculative product invention, materially larger scope, or a noisier prototype that reduces reviewability
-- write a concise round handoff into `review-log.md` containing:
-  - what was changed
-  - what was intentionally left unchanged
-  - why the next review should or should not still expect a gap
-
-## Reviewer rubric
-The reviewer must evaluate the prototype against these principles in order:
+## Review judgment order
+The reviewer must judge in this order:
 
 1. `Requirement completeness and correctness`
-- the interactive prototype must reflect the requirement document fully enough for the accepted scope
-- important requirement content must not be missing, misunderstood, or inconsistent
+- accepted-scope content must be present, correctly understood, and consistent with the source
 
 2. `Logic demonstrability`
-- deeper logic chains, dependencies, and cause-effect behavior must be demonstrated clearly
-- the prototype must not stop at first-layer description when the requirement meaning depends on richer interaction logic
+- deeper dependencies and cause-effect behavior must be demonstrated, not left at first-layer description
 
 3. `Representation correctness`
-- interaction, simulation, and omission must each be used deliberately and truthfully
-- if a rule cannot be demonstrated faithfully in interaction, disclose the gap clearly in `result.md`
-- avoid reviewer-driven overbuilding: do not add extra flows, fake data breadth, or decorative complexity unless they directly improve requirement understanding
+- interaction, simulation, and omission must be deliberate and truthful
+- if a rule cannot be shown faithfully, declare the gap in `result.md`
+- avoid reviewer-driven overbuilding that adds decorative or speculative complexity without improving requirement understanding
 
 4. `Implementation readiness for AI coding`
-- the artifact set must give downstream AI coding enough rule context and implementation guardrails to avoid major guessing
-- `result.md` must supplement the prototype where direct interaction is insufficient
-
-5. `UI design quality and visual fidelity`
-- the prototype should reach designer-grade quality for its intended fidelity level
-- visual style, layout cues, screenshots, diagrams, and structural hints from the requirement document should be used as first-priority guidance when present
-- avoid generic or template-looking UI when the source document provides stronger visual direction
-- every core panel must remain visibly populated and reviewable after each revision; do not accept a panel that retains only a title, labels, or empty chrome while its intended information carrier disappears
-- default prototype surface should read as product UI, not as a delivery brief or review console
-- for `Represented Interactively` modules, visible content must remain materially present:
-  - charts must still show visible bars, lines, points, or equivalent graphical carriers rather than only captions or axes
-  - product-facing explanatory content that is actually part of the requirement UI must retain enough information density to communicate its meaning, not collapse into thin placeholder copy
-- if a revision fixes one issue but causes another panel to become visually blank, materially thinner, or harder to interpret, treat it as a new blocking regression
-
-6. `Artifact consistency`
+- the artifact set must give downstream AI coding enough rule context and guardrails to avoid major guessing
+- `result.md` must supplement the prototype where interaction alone is insufficient
+
+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
+  - product-facing explanatory regions defined by the source UI must not collapse into thin placeholder copy
+- if one fix makes another panel visually blank, materially thinner, or harder to interpret, treat that as a new blocking regression
+
+6. `Artifact consistency and regression control`
 - `prototype.html` and `result.md` must agree on key rules, limitations, and truth status
+- later rounds must re-check the whole accepted surface, not only the previous `Must Fix` list
+- explicitly check for newly blank panels, invisible graph content, materially weakened product-facing explanatory regions, and regressions where a previously acceptable panel becomes weaker after a later fix
+- record material regressions under `New Regression Since Previous Round`
+- prefer `Prototype Partial` over further churn when the next revision would mainly add complexity, speculative branches, or visual clutter without improving requirement truth
 
-7. `Regression control after revision`
-- every later review round must re-check the whole accepted prototype surface, not only the previous `Must Fix` list
-- the reviewer must explicitly check for:
-  - newly blank or near-blank core panels
-  - graph containers whose DOM exists but whose intended visual content is no longer meaningfully visible
-  - product-facing explanatory regions required by the source UI whose copy became materially thinner or lost review-critical meaning
-  - regressions where a previously acceptable panel becomes weaker after a later fix
-- if such regressions appear, record them under `New Regression Since Previous Round` and classify them as `Must Fix Before Complete` when they reduce reviewability materially
-- if a proposed follow-up revision would mainly add complexity, speculative branches, or visual clutter without improving requirement truth, prefer `Prototype Partial` over further churn
+## Builder response to review
+After each review round, the builder must:
+- read the full reviewer output
+- revise the prototype and companion artifacts when `Must Fix Before Complete` findings exist
+- preserve unresolved but non-blocking findings in `result.md` when closure remains partial
+- run a full core-panel self-check before requesting the next review, not only a point fix for the previous `Must Fix`
+- prefer downgrade over another revise round when the next change would require speculative invention, materially larger scope, or a noisier prototype that reduces reviewability
+- write a concise handoff into `review-log.md` containing what changed, what stayed unchanged, and why the next review should or should not still expect a gap
 
 ## Closure policy
 - decide closure only after the final review round
@@ -216,6 +172,7 @@ The reviewer must evaluate the prototype against these principles in order:
   - 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
@@ -231,6 +188,7 @@ The reviewer must evaluate the prototype against these principles in order:
 ## 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
@@ -290,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"