Hi! Congrats on the release — I've been reading through the README, and the rejection-handling design (close the task, spawn a draft with code + feedback, keep the queue moving) is an elegant answer to the infinite-retry trap.
One gap I noticed while mapping this onto my own workflows: Review is synchronous, but some tasks can only be verified over time.
Examples:
- A performance fix — the commit is clean, but you only know it worked after the system has run for a few days
- A stability fix for an intermittent failure — "did it stop recurring?" is inherently a delayed question
- A dependency upgrade — silent breakage often surfaces later
For these, reviewing the exact commit can confirm "the change was made correctly", but not "the problem is actually solved". The task needs an observation period: done with the code, but pending a judgment that can only be made later.
A possible shape (rough, just to make it concrete):
- A task can carry explicit success criteria (what to measure, what threshold counts as solved)
- Instead of going straight to Done, such a task enters an observing state
- A later scheduler run (or a separate command) re-checks the criteria against real data:
- met → close for real
- not met → spawn a draft task carrying the observation data, reusing the existing rejection path — the "feedback never dies, queue keeps moving" property carries over naturally
This also touches the task lifecycle: there's likely a need for a non-blocking intermediate state (distinct from ready-to-run and closed) — "parked, waiting for a judgment". Right now the lifecycle is effectively binary (run / rejected), and my guess is you'll eventually hit tasks that shouldn't be retried immediately but shouldn't be closed either.
Context: I run a similar mechanism in a personal system — cards with explicit acceptance criteria, checked on a 3-day schedule (read data → compare against criteria → close or pull back). The main lesson after a couple of months: separating "the code is done" from "the outcome is confirmed" keeps both judgments honest.
Happy to discuss — this is clearly a "later" feature given the current one-task-at-a-time focus, but it might be worth having in the architecture's back pocket.
Hi! Congrats on the release — I've been reading through the README, and the rejection-handling design (close the task, spawn a draft with code + feedback, keep the queue moving) is an elegant answer to the infinite-retry trap.
One gap I noticed while mapping this onto my own workflows: Review is synchronous, but some tasks can only be verified over time.
Examples:
For these, reviewing the exact commit can confirm "the change was made correctly", but not "the problem is actually solved". The task needs an observation period: done with the code, but pending a judgment that can only be made later.
A possible shape (rough, just to make it concrete):
This also touches the task lifecycle: there's likely a need for a non-blocking intermediate state (distinct from ready-to-run and closed) — "parked, waiting for a judgment". Right now the lifecycle is effectively binary (run / rejected), and my guess is you'll eventually hit tasks that shouldn't be retried immediately but shouldn't be closed either.
Context: I run a similar mechanism in a personal system — cards with explicit acceptance criteria, checked on a 3-day schedule (read data → compare against criteria → close or pull back). The main lesson after a couple of months: separating "the code is done" from "the outcome is confirmed" keeps both judgments honest.
Happy to discuss — this is clearly a "later" feature given the current one-task-at-a-time focus, but it might be worth having in the architecture's back pocket.