@sireai/optimus 0.1.40 → 0.1.42

package/task-harnesses/pm/STANDARD.md

@@ -0,0 +1,186 @@
+# STANDARD
+
+Defines the mandatory execution sequence, result contract, and closure standard.
+
+## Execution sequence
+Complete work in this order:
+
+1. `Read`
+- read the full source requirement document
+- extract explicit goals, users, flows, states, constraints, and missing information
+- identify review-critical rules such as thresholds, counts, ordering, gating, frequency limits, role boundaries, and content-type distinctions
+
+2. `Map`
+- build a requirement map before designing screens or writing HTML
+- include at minimum:
+  - product goal
+  - target user
+  - entry point
+  - core flow
+  - key states
+  - requirement-critical rules
+  - explicit non-goals
+  - open questions
+
+3. `Plan Representation`
+- for each requirement-critical rule, choose exactly one:
+  - `Represented Interactively`
+  - `Represented via Annotation`
+  - `Downgraded / Simulated`
+  - `Not Represented`
+- prefer interaction for core user behavior and decision-critical meaning
+- use annotation when meaning is review-critical but not faithfully expressible through lightweight interaction
+- use downgrade/simulation only when it still supports useful review
+- choose `Represented Interactively` only when the prototype will contain clear behavioral evidence of that rule
+- if the rule is mainly conveyed by explanation, scenario toggles, or approximation rather than direct behavior, classify it as `Represented via Annotation` or `Downgraded / Simulated`
+
+4. `Frame`
+- define the minimum prototype scope that makes the core flow reviewable
+- decide covered screens, transitions, states, and review-mode needs
+- reduce breadth before inventing detail
+- record only the minimum assumptions needed for continuity
+
+5. `Build`
+- produce one reviewable interactive HTML prototype package
+- convert requirement meaning into UI structure, interaction, and visible states
+- add review mode when rule meaning cannot be carried clearly by interaction alone
+- use annotation content to mark `Confirmed`, `Simulated`, and `Open Question` where helpful
+
+6. `Deliver`
+- generate `result.md`
+- declare outputs precisely
+- surface assumptions, open questions, uncovered areas, and representation choices explicitly
+
+If execution stops early, explain which step could not be completed and why.
+
+## Prototype standard
+- the primary artifact is an interactive `prototype.html`
+- the prototype must make the main user flow inspectable
+- the prototype should support meaningful review actions such as navigation, state changes, or key transitions
+- prioritize depth on the core path over shallow breadth
+- when major requirement meaning cannot be expressed clearly by interaction alone, include review annotations
+- review annotations should be anchored to concrete UI targets, states, or transitions whenever possible
+- the prototype must remain understandable when annotations are hidden or minimized
+
+## Result contract
+- return exactly one runtime JSON object
+- normal completion and analysis-only closure both return `completed`
+- return `failed` only for true runtime exceptions
+- `resultPath` must point to exactly one `result.md` under `artifactDir`
+- do not output prose outside the runtime JSON object
+
+### Example
+```json
+{
+  "status": "completed",
+  "resultPath": "<artifactDir>/result.md"
+}
+```
+
+## Result artifacts
+- always generate `result.md` on normal completion
+- generate `prototype.html` for `Prototype Complete` and `Prototype Partial`
+- use repository-independent artifact paths
+- `result.md` is the only framework-required result artifact
+- any task-private files must be declared inside `result.md`
+
+## Result content
+At minimum, `result.md` must include:
+
+### Delivery Summary
+- `Closure`
+- `Document Basis`
+- `Prototype Scope`
+- `Core Flow`
+- `Platform`
+- `Coverage`
+- `Uncovered Areas`
+- `Assumptions`
+- `Open Questions`
+- `Next Action`
+
+### Outputs
+- `Main Review Artifact`
+- `Additional Files`
+- `Output Notes`
+
+### Requirement Mapping
+- `Requirement-Critical Rules`
+- `Represented Interactively`
+- `Represented via Annotation`
+- `Downgraded / Simulated`
+- `Not Represented`
+- `Representation Notes`
+
+### Detail
+- `Product Goal`
+- `Target User`
+- `Requirement Summary`
+- `Covered Screens / Sections`
+- `Key Interactions`
+- `States Included`
+- `Confirmed Requirements Used`
+- `Inferred Structure`
+- `Interaction Fidelity Notes`
+- `Review Annotation Notes`
+- `Assumptions`
+- `Open Questions`
+- `Recommended Next Step`
+
+## Result rules
+- separate confirmed requirement content from inferred structure
+- prefer explicit gaps over fake completeness
+- if annotation-assisted explanation is used, state what was annotated and why interaction was insufficient
+- do not claim a requirement was fully represented when it was only approximated or annotated
+- ensure representation fields reflect the actual prototype, not the intended prototype
+- if a key rule was merged or flattened for simplicity, record that downgrade explicitly
+- `Represented Interactively` requires clear behavioral evidence in the prototype itself, not only surrounding explanation
+- if a rule depends mainly on annotation, scenario controls, review notes, or narrative explanation, do not classify it as fully interactive
+
+## Closure standard
+- `Prototype Complete`: accepted scope, core path, major states, and key rules are reviewable through faithful interaction or clear anchored annotation
+- `Prototype Partial`: a meaningful prototype exists, but important parts remain uncovered, over-merged, or materially downgraded
+- `Analysis Only`: no trustworthy interactive prototype was produced; explain blockers and minimum missing input
+
+## Result template
+```md
+# Delivery Summary
+- Closure: Prototype Complete
+- Document Basis: source requirement document provided with the task
+- Prototype Scope: First-run onboarding only
+- Core Flow: Open invite -> fill profile -> complete setup
+- Platform: responsive
+- Coverage: invite landing, profile form, completion state
+- Uncovered Areas: admin approval flow, edge-case recovery paths
+- Assumptions: invite is valid for one user session
+- Open Questions: SSO is optional or required?
+- Next Action: review flow coverage and copy gaps
+
+# Outputs
+- Main Review Artifact: `prototype.html`
+- Additional Files: none
+- Output Notes: private outputs live under `artifactDir`
+
+# Requirement Mapping
+- Requirement-Critical Rules: invite entry, profile setup, completion confirmation
+- Represented Interactively: invite landing, profile form, submit, validation, success transition
+- Represented via Annotation: backend invite validation timing and account-provisioning dependency
+- Downgraded / Simulated: loading and approval check are simulated only
+- Not Represented: admin exception handling path
+- Representation Notes: approval timing is review-critical but backend-owned, so it is explained through anchored annotation instead of fake workflow logic
+
+# Detail
+- Product Goal: Reduce first-day confusion
+- Target User: New employee
+- Requirement Summary: Requirement input asks for a reviewable onboarding prototype
+- Covered Screens / Sections: invite landing, profile setup, confirmation
+- Key Interactions: start onboarding, form validation, submit, success transition
+- States Included: empty, validation error, loading, success
+- Confirmed Requirements Used: invite entry, profile setup, completion confirmation
+- Inferred Structure: lightweight validation and loading states to preserve flow continuity
+- Interaction Fidelity Notes: validation and submit flow are interactive; backend approval timing is annotation-assisted
+- Review Annotation Notes: approval dependency is attached to submit and success states in review mode
+- Assumptions: backend behavior is simulated only
+- Open Questions: whether manager approval is required before activation
+- Recommended Next Step: confirm approval rule and add branch state if needed
+```

package/task-harnesses/pm/manifest.json

@@ -0,0 +1,13 @@
+{
+  "id": "pm",
+  "triageRules": [
+    "ACCEPT.md"
+  ],
+  "executionRules": [
+    "ROLE.md",
+    "CONSTRAINTS.md",
+    "CONTEXT.md",
+    "STANDARD.md",
+    "EVOLUTION.md"
+  ]
+}

package/task-harnesses/registry.json

@@ -3,6 +3,10 @@
     {
       "taskType": "bugfix",
       "dir": "bugfix"
+    },
+    {
+      "taskType": "pm",
+      "dir": "pm"
     }
   ]
 }