Skip to content

Autonomic pipeline: document the fix-worker model choice in the playbook #474

Description

@chiptus

This was generated by AI during triage.

Split out from #462 (item 1). The decision itself is settled — triage runs on Sonnet; the fix worker runs on a stronger model chosen at Routine creation — but docs/agents/autonomic-issues.md only says "stronger model" in passing and never records the choice or its rationale as a decision.

Agent Brief

Category: enhancement
Summary: Record the model-choice decision for the two pipeline Routines explicitly in the autonomic-issues playbook

Current behavior:
The playbook (docs/agents/autonomic-issues.md) mentions the fix worker runs "on a stronger model" in its overview line and in the Routine-creation steps, but there is no dedicated statement of the decision: which model each Routine uses, that the fix worker's model is fixed at Routine creation (not per-firing), or why the split exists (cheap daily sweep vs. expensive PR-producing work).

Desired behavior:
The playbook carries a short, findable statement of the model policy: triage sweep on Sonnet; fix worker on a stronger model, selected when the Routine is created; one or two lines of rationale. Existing passing mentions should stay consistent with it. If the playbook has a decisions/conventions section, put it there; otherwise place it where someone re-creating the Routines would see it.

Key interfaces:

  • docs/agents/autonomic-issues.md: the only artifact to change — this is a documentation-only issue
  • The Routine-creation instructions in that doc: they should reference the policy rather than repeating a vague "stronger model"

Acceptance criteria:

  • The playbook states which model class each Routine uses and that the fix worker's model is picked at Routine creation
  • A brief rationale (cost/capability split) is included
  • No contradictory or vaguer duplicate phrasing remains in the doc
  • No code, Routine, or config changes — docs only

Out of scope:

  • Actually changing either Routine's model
  • Naming exact dated model IDs (they churn; model class/tier is enough)
  • Any mechanism for per-firing model selection

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions