@sireai/optimus 0.1.1

package/task-harnesses/bugfix/STANDARD.md

@@ -0,0 +1,250 @@
+# STANDARD
+
+## Execution loop
+
+- Use PDCA, not guesswork.
+- `Plan`: define problem, scope, strongest root-cause judgment or hypothesis, and validation path.
+- `Do`: inspect evidence, make the minimum necessary change, add the smallest relevant verification when needed.
+- `Check`: validate through reproduction, tests, scenarios, logs, output comparison, build, or code evidence.
+- `Act`: close as fix or analysis and write one reviewable result file.
+
+## Patch gate
+
+- Patch only when both root-cause judgment and validation path are credible.
+- Create an explicit plan first when the task spans modules, has a long call chain, or exceeds a local change.
+- Use code, config, logs, call chains, and tests as evidence.
+- Keep changes minimal. Self-review the actual diff for regressions, boundary breaks, compatibility risk, and unnecessary changes before emitting a patch.
+- If safe patching is not justified, stay in analysis mode.
+
+## Validation policy
+
+- A claimed fix requires validation.
+- Prefer stronger evidence before weaker evidence.
+- Report the strongest level reached and why stronger levels were unavailable.
+
+1. `L4 functional`: real device, simulator, or another directly runnable environment
+2. `L3 self-check`: local unit tests, targeted custom tests, lightweight scenario injection
+3. `L2 build`: relevant compile target, module build, or targeted test task
+4. `L1 code evidence`: static reasoning, call-chain review, diff review
+
+### Android order
+
+1. Prefer real-device or simulator validation when `adb` and runnable targets exist.
+2. Otherwise prefer local tests or scenario injection.
+3. Use device-side automated checks only when local validation cannot cover the behavior.
+4. Fall back to compile validation such as `compileDebugKotlin` or relevant unit tests.
+5. Use code-only validation only when all stronger forms are unavailable.
+
+## Closure policy
+
+- Close as fix only when analysis, code changes, validation evidence, and residual-risk understanding are credible.
+- Close as analysis when information, environment, reproduction, or validation is insufficient for a trustworthy patch claim.
+- If code changed but validation reached only `L2` or `L1`, describe it as a repair candidate, not a verified fix.
+- If the issue is interaction, crash, device, integration, or resource related and validation stayed at `L2`, state what stronger environment or tooling was missing.
+- If build or test failed for unrelated reasons, report the stage, failure reason, and why it is treated as noise or a pre-existing blocker.
+- If only `L1` evidence exists, do not submit a formal patch claim; close as analysis.
+- Analysis closure must still provide root-cause judgment, fix direction, and either targeted local guidance or a module-level strategy.
+
+## Runtime contract
+
+- Return exactly one runtime JSON object.
+- Normal fix closure and normal analysis closure both return `completed`.
+- Return `failed` only when execution itself hits a real runtime exception.
+- `resultPath` must point to exactly one file under `artifactDir`.
+- Do not add extra keys or output prose outside the JSON object.
+
+### Examples
+
+```json
+{
+  "status": "completed",
+  "resultPath": "<artifactDir>/result.md"
+}
+```
+
+```json
+{
+  "status": "failed",
+  "error": {
+    "category": "schema_error",
+    "message": "failure reason"
+  }
+}
+```
+
+## Result artifacts
+
+- Always generate `result.md` on normal completion.
+- If code changed, runtime should also emit `patch.diff`.
+- If `patch.diff` exists, `Closure Level` must not be `Analysis Only`.
+- If `patch.diff` exists, Patch Closure Mode is mandatory.
+- Before writing `result.md`, determine `Closure Level`, then follow exactly one language mode:
+  - `Verified Fix` or `Repair Candidate`: Patch Closure Mode; all narrative sections are English
+  - `Analysis Only`: Analysis Closure Mode; narrative sections are Chinese
+- `Validation Summary` stays a single English token in all cases.
+- Use repository-relative code paths only; never use absolute local paths.
+- Commands, logs, stack traces, API errors, and identifiers may stay in their original language when needed.
+- If closure is patch-related and any narrative field is Chinese, the output is invalid and must be rewritten.
+
+## Mandatory field-name contract
+
+Do not rename these downstream-consumed keys:
+
+- English patch-mode keys:
+  - `Validation Summary`
+  - `Strongest Current Conclusion`
+  - `Analysis Summary`
+  - `Key Evidence`
+  - `Recommended Action`
+  - `Analysis Doc URL`
+- Chinese analysis-mode keys:
+  - `验证摘要`
+  - `当前最强结论`
+  - `分析摘要`
+  - `关键证据`
+  - `建议动作`
+  - `分析文档链接`
+
+Keep exact capitalization and wording.
+
+## Result content
+
+At minimum, `result.md` must include:
+
+- a validation summary as one high-density English token
+  Allowed values: `device_verified`, `simulator_verified`, `scenario_verified`, `unit_tests_passed`, `targeted_tests_passed`, `regression_tests_passed`, `compile_passed`, `module_build_passed`, `code_reviewed`, `validation_completed`
+  If multiple validations were performed, report only the strongest one.
+- problem summary and impact scope
+- category: functional, stability, performance, or compatibility
+- reproduction likelihood: always, high, low, or unknown
+- root-cause judgment or strongest current hypothesis
+- supporting evidence
+- blocking point if full fix was not completed
+- why patching is not justified yet when code did not change
+- patch notes when code changed: key changes, intent, impact scope
+- fix strategy when validation is insufficient
+- validation method, steps, actual results, and unverified items
+- residual risk and next step
+
+## Patch Closure Mode
+
+- Use only when `Closure Level` is `Verified Fix` or `Repair Candidate`.
+- Use the Patch Closure Template only.
+- Mandatory when `patch.diff` exists.
+- All narrative text must be English.
+- Do not emit Chinese prose in headings, bullets, conclusions, evidence, patch notes, validation narrative, risks, or next steps.
+- Do not emit `Analysis Summary` in patch closure output.
+- Patch closure must include:
+  - `Strongest Current Conclusion`
+  - `Key Evidence`
+  - `Recommended Action`
+
+### Patch Closure Template
+
+```md
+# Bugfix Result
+
+## Summary
+- Problem:
+- Impact:
+- Category: Functional / Stability / Performance / Compatibility
+- Reproduction Likelihood: Always / High / Low / Unknown
+
+## Root Cause
+- Strongest Current Conclusion:
+- Key Evidence:
+- Relevant Code Locations:
+
+## Change
+- Closure Level: Verified Fix / Repair Candidate
+- Patch Notes:
+- Fix Strategy:
+- Blocking Point: `None` if not blocked
+
+## Validation
+- Validation Summary: exactly one short English token, strongest validation only
+- Method:
+- Result:
+- Unverified Items:
+
+## Risks
+- Residual Risk:
+- Recommended Action:
+```
+
+## Analysis Closure Mode
+
+- Use only when `Closure Level` is `Analysis Only`.
+- Use the Analysis Closure Template only.
+- Forbidden when `patch.diff` exists.
+- Narrative text must remain Chinese.
+- `验证摘要` must still be a single English token.
+- Do not force patch-delivery prose such as `Patch Notes` into analysis closure output.
+- Analysis closure must include the Chinese contract keys for strongest conclusion, summary, evidence, and recommendation.
+
+### Analysis Closure Template
+
+Use the following Chinese output structure exactly:
+
+```md
+# 缺陷分析结果
+
+## 问题概述
+- 问题:
+- 影响:
+- 分类: 功能 / 稳定性 / 性能 / 兼容性
+- 复现概率: 必现 / 高概率 / 低概率 / 未知
+
+## 分析结论
+- 当前最强结论:
+- 分析摘要:
+- 关键证据:
+- 相关代码位置:
+
+## 修复判断
+- Closure Level: Analysis Only
+- 阻塞点:
+- 建议动作:
+
+## 验证情况
+- 验证摘要: exactly one short English token, strongest validation only
+- 已验证内容:
+- 未验证内容:
+
+## 风险
+- 主要风险:
+- 建议动作:
+- 分析文档链接:
+```
+
+## Language examples
+
+Patch closure examples:
+
+- Valid:
+  - `Strongest Current Conclusion: The Android-side debug path still keeps an intentional crash branch.`
+  - `Key Evidence: Clicking the button reaches METHOD_CRASH and terminates the process through an uncaught exception.`
+  - `Recommended Action: Review whether the debug-only crash path should be removed or guarded.`
+- Invalid:
+  - `Strongest Current Conclusion: Android-side debug code still keeps an intentional crash path.` followed by Chinese evidence or recommendation text
+
+## Delivery check
+
+- Ensure `resultPath` is real and readable.
+- Ensure the conclusion answers the task directly.
+- If code changed, ensure `result.md` and `patch.diff` do not contradict each other.
+- If important code changed, ensure explanatory comments are present.
+- If validation was performed, ensure claims are not overstated.
+- Distinguish confirmed facts from inference.
+- For patch closure, ensure `Strongest Current Conclusion`, `Key Evidence`, and `Recommended Action` are English before returning.
+
+## Final self-check
+
+- closure mode is chosen correctly
+- if `patch.diff` exists, closure mode is not `Analysis Only`
+- patch closure uses English narrative only
+- analysis closure uses Chinese narrative only
+- required downstream field names are exact
+- patch closure does not emit `Analysis Summary`
+- analysis closure does not mix in patch-delivery sections
+- `Validation Summary` or `验证摘要` is exactly one strongest English token

package/task-harnesses/bugfix/manifest.json

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

package/task-harnesses/registry.json

@@ -0,0 +1,8 @@
+{
+  "harnesses": [
+    {
+      "taskType": "bugfix",
+      "dir": "bugfix"
+    }
+  ]
+}