@sireai/optimus 0.1.1 → 0.1.3

package/task-harnesses/bugfix/ACCEPT.md

@@ -1,30 +1,54 @@
 # ACCEPT
 
 ## Decision target
-Route real software defect tasks into the `bugfix` harness. The runner, not triage, decides whether final closure is fix or analysis.
+Route real software defect tasks into the `bugfix` harness.
+Triage must decide:
+1. task type fit
+2. execution admission
+The runner, not triage, decides whether final closure is fix or analysis.
 
-## Accept when
-Accept when all are true:
-- the input describes a real issue to handle, not open-ended discussion
-- the issue relates to code, configuration, build logic, runtime behavior, testing flow, or system behavior
-- the input contains at least an identifiable symptom, failure result, or abnormal behavior
-- the target repository can be identified; if `repo` is missing, default selection is allowed only when exactly one repository is registered
+## Task type fit
+Classify as `bugfix` only when all are true:
+- real issue to handle, not open-ended discussion
+- tied to code, configuration, build logic, runtime behavior, test flow, or system behavior
+- concrete defect object exists: crash, error, regression, broken flow, wrong result, or abnormal behavior
 
-## Still acceptable with incomplete information
-The task may still be accepted when:
+Do not classify as `bugfix` when any are true:
+- product advice, design discussion, architecture debate, or technology comparison
+- pure consultation, Q&A, or open-ended brainstorming
+- no concrete defect object
+- no engineering repository or system-behavior relation
+
+## Execution admission
+Accept into execution only when all are true:
+- target repository is resolvable; if `repo` is missing, default selection is allowed only when exactly one repository is registered
+- at least one concrete defect anchor is present
+- the anchor is specific enough to locate one of:
+  - failing scenario or trigger path
+  - observable evidence text
+  - named page, feature, module, or flow
+
+## Still acceptable with partial information
+Still acceptable when:
 - root cause is unknown
-- full reproduction steps are missing
-- logs, stack traces, screenshots, or ready-made tests are missing
-- but the problem is still clear enough to judge that it is a real software defect rather than generic consultation
-
-## Reject when
-Reject when any are true:
-- the request is product advice, design discussion, or technology comparison
-- the request is pure consultation, Q&A, or open-ended brainstorming
-- there is no concrete defect object to handle
-- no relation to code, system behavior, or an engineering repository can be established
-- the target repository cannot be determined and multiple candidate repositories exist
-- the content is so vague that even the basic symptom cannot be identified
+- reproduction is incomplete
+- logs, stack traces, screenshots, or tests are missing
+- but the affected flow is still concrete enough to investigate safely
+- and at least one anchor exists, such as:
+  - named page or feature plus failing action
+  - visible symptom tied to a specific flow
+  - error message, exception text, or crash evidence
+
+## Reject for insufficient execution context
+Reject even if the task fits `bugfix` when any are true:
+- target repository cannot be determined and multiple candidates exist
+- content is so vague that even the basic symptom cannot be identified
+- input only says wrong / abnormal / failed / not working, with no concrete symptom, actual behavior, failure output, or affected flow
+- crash / error / failure is claimed, but there is neither:
+  - a concrete scenario or trigger path
+  - nor observable evidence text such as logs, stack trace, error text, or crash record
+- only a generic action is named, such as click / enter / open / use, but no page, feature, control, or path is identified
+- only a broad result is given, such as "app crashes" or "application is abnormal", without enough context to locate the failing flow
 
 ## Missing information to mention first when rejecting
 - `repo`
@@ -36,6 +60,16 @@ Reject when any are true:
 - `expected_behavior`
 - `actual_behavior`
 
+## Missing information mapping guidance
+- use `repo` when the target repository is required but cannot be resolved safely
+- use `description_or_content` when the request does not describe a concrete bug object or affected flow
+- use `actual_behavior` when the observed failure, symptom, or abnormal behavior is not stated clearly
+- use `expected_behavior` when the expected result is needed to understand the defect gap
+- use `reproduction_steps` when no concrete trigger path, scenario, page, feature, or action chain is described
+- use `logs` when the task explicitly depends on error output but no error text is provided
+- use `stack_trace` when the task claims a crash or exception and stack evidence is the missing blocker
+- prefer the smallest set of fields that explains exactly why triage cannot safely accept the task
+
 ## Event scope
 - `bug.discovered`
 - `problem.discovered`
@@ -44,4 +78,6 @@ Reject when any are true:
 ## Triage guidance
 - Supporting words such as crash, error, fail, exception, regression, not working, frozen, or abnormal are hints only; they must not replace semantic judgment.
 - Judge the whole task meaning, not keywords.
+- Separate `task type fit` from `execution admission`.
+- A task may clearly be a `bugfix` in type but still be rejected because execution context is insufficient.
 - Triage only decides whether the task enters the `bugfix` pipeline.