Autonomous vs quick-fix processing

Ideafy has three processing types — background jobs that run the agent against a card without an open terminal. Each type runs a different workflow and has different expectations about how long it takes and what card state it starts from.

IMG-autonomous-vs-quickfix-20260417235112653

The three types

Type	Column requirement	What it does	Typical runtime
`evaluate`	Ideation	Reads the card + product narrative, calls `save_opinion` with verdict	2–10 min
`autonomous`	Any (detects phase)	Full workflow: plan → implement → generate tests. Creates a worktree.	5–30 min
`quick-fix`	Bugs	Short, targeted fix. No worktree ceremony.	1–10 min

Each type is triggered from a button in the card modal header. While a type is running, the card is locked — you can't edit it — and the processing indicator on the card surface shows an animated ring.

`evaluate`

Use when you have an Ideation card and you want the AI's take on whether it's worth doing.

What the agent does.

Loads the card description
Loads docs/product-narrative.md (or your configured narrative)
Analyses the idea against the narrative's non-goals, target users, success metrics
Calls save_opinion with the full template (Summary Verdict, Strengths, Concerns, Recommendations, Priority, Final Score) and a positive/negative verdict

When it finishes. The card has an Opinion tab you can read, and the card surface shows a Brain icon with a green check or red cross.

`autonomous`

Use when a card is ready to ship and you trust the agent to drive.

What the agent does. It first works out which phase the card is in, from the card's own state:

Card state	Phase	What the run does
No plan yet	`planning`	Reads the relevant source, drafts a plan, calls `save_plan` → card moves to In Progress
Plan exists, no tests	`implementation`	Creates a worktree, starts a dev server on an allocated port, writes code, commits, then outputs the test checklist
Tests exist, card is in Human Test	`verify`	Walks the checklist's core flow — see below
Tests exist, card is anywhere else	`retest`	"It broke, fix it" — the run fixes, commits, and rewrites the checklist

When it finishes (planning / implementation). The card is in Human Test, the worktree is live, the dev server is running on its allocated port. You verify the acceptance criteria by hand and then merge from the card modal.

This is the closest Ideafy gets to "AI does the whole thing." You still verify and merge.

The verify phase

Human Test is a queue waiting on a person, and it's the column that grows fastest — the agent finishes in minutes and verification takes days. So a re-run on a card that's already in Human Test doesn't mean "it broke". It means "walk what you can before I get there."

In that phase the run:

executes only the items under the checklist's first group — ## Core flow (English) or ## Temel akış (Turkish)
never runs, ticks, or edits anything in a later group (## Edge cases, ## Regression) — those stay for you
verifies by actually exercising the code: reading it, running it, running the build or the test the step names. Reasoning that a step "should" pass is not verification
reproduces the entire checklist unchanged — every group, every item, original order and wording — editing only - [ ] → - [x] on core items it ran and saw pass
leaves a core item unticked when it failed or couldn't be run, and adds one short line naming what blocked it

If the checklist has no core group at all, it ticks nothing and says so. Without that heading it can't tell which items are essential, and guessing would hand back a checklist that looks verified and isn't.

See The core flow for the contract that puts the group there in the first place.

`quick-fix`

Use when there's a bug with a narrow scope and you just want it fixed.

What the agent does.

Reads the card description
Makes targeted edits in the worktree
Commits the fix
Leaves the card in the Bugs column (quick-fix doesn't auto-move status)

When it finishes. You still review. Quick-fix is the fastest path but has the least ceremony — there's no enforced plan or test generation, just "fix this thing."

Locking and interruption

When a processing job is running, the card is locked in the UI — no edits, no drag-drop, the modal is read-only-ish. The lock is visible in the card surface as an animated indicator.

If you need to stop a running job, use the Clear processing option in the card modal header. That sets processingType = null and kills the process. You keep whatever state was already written (partial plans, partial commits) — recovery is manual.

How autonomous differs from interactive chat

Autonomous, quick-fix, and evaluate all run the agent without session resume — every invocation is a fresh CLI call with the full system prompt. The chat panel in the card modal is the opposite: it resumes the previous CLI session via --resume, so the conversation feels continuous across days.

Autonomous also always runs with --dangerously-skip-permissions and --output-format json. It has to — nobody's at the keyboard to approve prompts, and the result has to be machine-parseable so Ideafy can update the card. Interactive chat uses elevated permissions only on the Tests tab (for cards at In Progress and beyond); everywhere else it uses the default confirmation flow.

For the full permission-flag matrix and session resume mechanics, see Interactive CLI sessions.

What to pick

Scanning an idea queue? → evaluate in a loop. Fast feedback on which ideas are worth building.
Well-scoped feature with a clear description? → autonomous.
A small, well-understood bug? → quick-fix.
A large, vague feature? → Don't use processing. Plan interactively in the Solution tab chat, then run autonomous once the plan is solid.

Processing types are not magic. They work best when the card already has enough context. If Detail is empty, the agent is guessing — and guessing isn't faster.

Prev: MCP tools reference Next: Interactive CLI sessions Up: User guide index