decide_findings_openai

This command keeps judgment and routing at the orchestrator level. Child sessions do bounded work only: research disputed areas, apply bounded cleanups, execute planning pipelines, or verify state.

The goal is to move every in-scope finding into one of these terminal states:

• resolved by bounded cleanup (verified, committed, pushed)
• resolved via plan + implementation (verified, committed, pushed)
• accepted as context (no action needed, rationale documented)
• explicitly deferred with rationale
• explicitly declined with rationale
• research-pending (investigation spawned, awaiting reclassification)

<workflow_contract>

1. Follow all 9 steps in order.
2. Use todowrite and keep exactly one task in_progress at a time.
3. Always normalize findings into an internal corpus before routing.
4. Cluster related findings before choosing routes.
5. Prefer research when evidence is weak, disputed, or blast radius is unclear.
6. Prefer plan_and_implement when multi-file changes, design decisions, or test harness work are involved.
7. Any cleanup claiming a fix must happen only after verification (just check + just test), commit, and push.
8. Update the source artifact with a backlink to the decision document after writing it.
9. Refresh findings state after material progress before declaring completion.
10. Do not use session-centric findings commands; this workflow replaces that pattern with orchestrator-driven resolution. </workflow_contract>

<step_1>

Step 1: Interpret Intent and Establish Autonomy Bounds

1. Extract the source artifact path from <userMessage>. If no path is provided, ask for one and stop.
2. Infer the requested autonomy level from <userMessage>.
3. Support common modifiers such as:
   • cleanup only — only execute cleanup_now routes, defer everything else
   • planning focus — bias toward identifying work that needs planning rather than quick cleanup
   • research first — spawn research for any finding with confidence gaps before routing
   • dry run — route and document decisions but do not execute changes
   • high severity only — process only high-severity findings
   • include low — include low-severity findings (normally skipped)
   • category filters like only testing, only security, etc.
4. If the user does not narrow scope, assume:
   • all Medium+ severity findings are in scope
   • autonomous routing is allowed
   • code changes and commits are allowed
5. Ask a clarification question only if you cannot determine the source artifact or if the user gave mutually exclusive instructions.
6. Record the explicit limits for this run, especially whether code changes and commits are allowed.

</step_1>

<step_2>