@sireai/optimus 0.1.30 → 0.1.33
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli/optimus.js +41 -22
- package/dist/cli/optimus.js.map +1 -1
- package/dist/integrations/jira/jira-access-manager.d.ts +1 -0
- package/dist/integrations/jira/jira-access-manager.js +24 -0
- package/dist/integrations/jira/jira-access-manager.js.map +1 -1
- package/dist/integrations/jira/jira-client.js +50 -8
- package/dist/integrations/jira/jira-client.js.map +1 -1
- package/dist/problem-solving-core/codex/codex-runner.d.ts +2 -0
- package/dist/problem-solving-core/codex/codex-runner.js +43 -28
- package/dist/problem-solving-core/codex/codex-runner.js.map +1 -1
- package/dist/task-environment/delivery/task-delivery-service.js +3 -1
- package/dist/task-environment/delivery/task-delivery-service.js.map +1 -1
- package/dist/task-environment/evidence/evidence-preparation-service.js +19 -3
- package/dist/task-environment/evidence/evidence-preparation-service.js.map +1 -1
- package/dist/task-environment/intake/manual-problem-intake.js +30 -0
- package/dist/task-environment/intake/manual-problem-intake.js.map +1 -1
- package/dist/task-environment/orchestration/execution-context-assembler.d.ts +1 -0
- package/dist/task-environment/orchestration/execution-context-assembler.js +50 -0
- package/dist/task-environment/orchestration/execution-context-assembler.js.map +1 -1
- package/dist/task-environment/orchestration/task-orchestrator.d.ts +1 -0
- package/dist/task-environment/orchestration/task-orchestrator.js +27 -5
- package/dist/task-environment/orchestration/task-orchestrator.js.map +1 -1
- package/dist/task-environment/orchestration/task-package-inputs.d.ts +2 -0
- package/dist/task-environment/orchestration/task-package-inputs.js +38 -0
- package/dist/task-environment/orchestration/task-package-inputs.js.map +1 -0
- package/dist/task-environment/orchestration/task-runtime-policy.d.ts +4 -0
- package/dist/task-environment/orchestration/task-runtime-policy.js +38 -0
- package/dist/task-environment/orchestration/task-runtime-policy.js.map +1 -0
- package/dist/task-environment/runtime/optimus-runtime.d.ts +2 -0
- package/dist/task-environment/runtime/optimus-runtime.js +49 -20
- package/dist/task-environment/runtime/optimus-runtime.js.map +1 -1
- package/dist/task-environment/storage/sqlite-event-store.d.ts +1 -1
- package/dist/task-environment/storage/sqlite-event-store.js +2 -1
- package/dist/task-environment/storage/sqlite-event-store.js.map +1 -1
- package/dist/types.d.ts +32 -0
- package/package.json +1 -1
- package/task-harnesses/bugfix/CONSTRAINTS.md +3 -0
- package/task-harnesses/pm/ACCEPT.md +94 -0
- package/task-harnesses/pm/CONSTRAINTS.md +27 -0
- package/task-harnesses/pm/CONTEXT.md +26 -0
- package/task-harnesses/pm/EVOLUTION.md +35 -0
- package/task-harnesses/pm/ROLE.md +59 -0
- package/task-harnesses/pm/STANDARD.md +125 -0
- package/task-harnesses/pm/manifest.json +13 -0
- package/task-harnesses/registry.json +4 -0
|
@@ -0,0 +1,125 @@
|
|
|
1
|
+
# STANDARD
|
|
2
|
+
|
|
3
|
+
## Execution loop
|
|
4
|
+
- start from requirement input, not visual polish
|
|
5
|
+
- identify the minimum prototype scope that makes the core flow reviewable
|
|
6
|
+
- convert requirement meaning into interaction structure, page flow, and visible states
|
|
7
|
+
- produce one reviewable prototype package
|
|
8
|
+
- surface assumptions and open questions explicitly
|
|
9
|
+
|
|
10
|
+
## Prototype rule
|
|
11
|
+
- the primary artifact is an interactive HTML prototype
|
|
12
|
+
- the prototype must make the main user flow inspectable
|
|
13
|
+
- static page output alone is not enough unless the task is explicitly analysis-only
|
|
14
|
+
- prioritize depth on the core path over shallow breadth
|
|
15
|
+
- simulate product behavior lightly; do not pretend to implement production systems
|
|
16
|
+
|
|
17
|
+
## Scope rule
|
|
18
|
+
- stay within the accepted prototype scope
|
|
19
|
+
- if the requirement is broad, reduce coverage to the most important flow
|
|
20
|
+
- if key detail is missing, make only the minimum assumption needed for continuity
|
|
21
|
+
- if trustworthy prototyping would require invention beyond the requirement basis, stop at analysis
|
|
22
|
+
|
|
23
|
+
## Runtime contract
|
|
24
|
+
- return exactly one runtime JSON object
|
|
25
|
+
- normal prototype completion returns `completed`
|
|
26
|
+
- analysis-only closure also returns `completed`
|
|
27
|
+
- return `failed` only when execution itself fails
|
|
28
|
+
- `resultPath` must point to exactly one file under `artifactDir`
|
|
29
|
+
- `resultPath` must point to `result.md`
|
|
30
|
+
- do not output prose outside the runtime JSON object
|
|
31
|
+
|
|
32
|
+
### Example
|
|
33
|
+
```json
|
|
34
|
+
{
|
|
35
|
+
"status": "completed",
|
|
36
|
+
"resultPath": "result.md"
|
|
37
|
+
}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## Result artifacts
|
|
41
|
+
- always generate `result.md` on normal completion
|
|
42
|
+
- supporting files are task-private outputs placed under `artifactDir`
|
|
43
|
+
- generate `prototype.html` for `Prototype Complete` and `Prototype Partial`
|
|
44
|
+
- use repository-independent artifact paths
|
|
45
|
+
- `result.md` is the only framework-required result artifact
|
|
46
|
+
- private output files must be declared inside `result.md`
|
|
47
|
+
|
|
48
|
+
## Closure target
|
|
49
|
+
Use exactly one closure level:
|
|
50
|
+
- `Prototype Complete`
|
|
51
|
+
- `Prototype Partial`
|
|
52
|
+
- `Analysis Only`
|
|
53
|
+
|
|
54
|
+
## Result content
|
|
55
|
+
At minimum, `result.md` must include:
|
|
56
|
+
|
|
57
|
+
### Delivery Summary
|
|
58
|
+
- `Closure`
|
|
59
|
+
- `Prototype Scope`
|
|
60
|
+
- `Core Flow`
|
|
61
|
+
- `Platform`
|
|
62
|
+
- `Coverage`
|
|
63
|
+
- `Assumptions`
|
|
64
|
+
- `Open Questions`
|
|
65
|
+
- `Next Action`
|
|
66
|
+
|
|
67
|
+
### Outputs
|
|
68
|
+
- `Main Review Artifact`
|
|
69
|
+
- `Additional Files`
|
|
70
|
+
- `Output Notes`
|
|
71
|
+
|
|
72
|
+
### Detail
|
|
73
|
+
- `Product Goal`
|
|
74
|
+
- `Target User`
|
|
75
|
+
- `Requirement Summary`
|
|
76
|
+
- `Covered Screens / Sections`
|
|
77
|
+
- `Key Interactions`
|
|
78
|
+
- `States Included`
|
|
79
|
+
- `Assumptions`
|
|
80
|
+
- `Open Questions`
|
|
81
|
+
- `Recommended Next Step`
|
|
82
|
+
|
|
83
|
+
## Content rules
|
|
84
|
+
- clearly separate confirmed requirement content from inferred structure
|
|
85
|
+
- do not hide missing requirement detail inside polished prototype output
|
|
86
|
+
- keep summaries dense and review-oriented
|
|
87
|
+
- prefer explicit gaps over fake completeness
|
|
88
|
+
- if prototype output is produced, declare its path under `Outputs`
|
|
89
|
+
- if no prototype output is produced, state `Main Review Artifact: not produced` and explain why
|
|
90
|
+
|
|
91
|
+
## Result template
|
|
92
|
+
Use this as the minimum `result.md` shape on normal completion:
|
|
93
|
+
|
|
94
|
+
```md
|
|
95
|
+
# Delivery Summary
|
|
96
|
+
- Closure: Prototype Complete
|
|
97
|
+
- Prototype Scope: First-run onboarding only
|
|
98
|
+
- Core Flow: Open invite -> fill profile -> complete setup
|
|
99
|
+
- Platform: responsive
|
|
100
|
+
- Coverage: invite landing, profile form, completion state
|
|
101
|
+
- Assumptions: invite is valid for one user session
|
|
102
|
+
- Open Questions: SSO is optional or required?
|
|
103
|
+
- Next Action: review flow coverage and copy gaps
|
|
104
|
+
|
|
105
|
+
# Outputs
|
|
106
|
+
- Main Review Artifact: `prototype.html`
|
|
107
|
+
- Additional Files: none
|
|
108
|
+
- Output Notes: private outputs live under `artifactDir`
|
|
109
|
+
|
|
110
|
+
# Detail
|
|
111
|
+
- Product Goal: Reduce first-day confusion
|
|
112
|
+
- Target User: New employee
|
|
113
|
+
- Requirement Summary: Requirement input asks for a reviewable onboarding prototype
|
|
114
|
+
- Covered Screens / Sections: invite landing, profile setup, confirmation
|
|
115
|
+
- Key Interactions: start onboarding, form validation, submit, success transition
|
|
116
|
+
- States Included: empty, validation error, loading, success
|
|
117
|
+
- Assumptions: backend behavior is simulated only
|
|
118
|
+
- Open Questions: whether manager approval is required before activation
|
|
119
|
+
- Recommended Next Step: confirm approval rule and add branch state if needed
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
## Closure policy
|
|
123
|
+
- `Prototype Complete`: the accepted scope is covered by a coherent interactive prototype
|
|
124
|
+
- `Prototype Partial`: a meaningful prototype exists, but coverage is incomplete
|
|
125
|
+
- `Analysis Only`: no trustworthy prototype was produced; explain blockers and missing input
|