Self-healing blockers

Most tools stop at a blocked task and wait for someone to notice. Tharas runs a resolution loop: observe, reason, hypothesise, research, plan, repair, verify, learn — and only escalates once that budget is genuinely spent.

What a blocked task means here#

The loop below is long. This is the whole of why it exists.

Most tools

  • Stop at the blocked task and wait
  • Report a red status and a stack trace
  • Ask you to run it again
  • Learn nothing from the failure

Tharas

  • Diagnoses the failure and states a hypothesis
  • Researches it, then plans ranked repair strategies
  • Repairs through the same jailed engineer, then re-runs QA
  • Writes down what worked — and what did not

What happens to a blocked task#

A task that exhausts its QA retries, or that the Supervisor blocks, enters this loop automatically.

  1. ObserveBuilds an evidence bundle: the task objective and its scope, the last defects, what is actually different on disk against base, and the raw blocked event.
  2. ReasonOne query across every knowledge tier at once — code, decisions, plan summaries, gotchas, learned skills, reflections, failure patterns, anti-patterns and live research. Ranked by relevance, recency and historical success rate.
  3. HypothesiseStates what it believes is wrong, before research runs. Research then validates or refutes that statement — it does not replace the thinking step.
  4. ResearchSearches the web for the specific failure. Without a search key configured it logs a skip and returns nothing — it never raises and never blocks the loop.
  5. PlanOne structured call returns a root cause and a set of repair strategies, each with a confidence, a risk and a cost. They are scored and sorted best-first.
  6. RepairRe-tasks the same jailed engineer the rest of the pipeline uses, with the chosen strategy as guidance. The resolution engine has no file-writing tool of its own — every change goes through the existing jail.
  7. VerifyRuns the unchanged QA gate against the result.
  8. Reflect and learnRuns whether it worked or not, recording root cause, strategy, outcome, attempts, cost and whether anything regressed. A confident success is promoted to a reusable skill.

The loop gets better at your codebase#

The learning step is what stops every blocker starting from zero. A resolution that worked becomes a skill, deduplicated against skills that already exist, and the next similar block finds it during the reason step.

Reflections are written on failure too. Knowing which strategy did not work on this repository is worth as much as knowing which one did.

When it does give up, it hands you something useful

Exhaustion raises a resolution report: the root cause, every strategy it tried, why each one failed, and the metrics for the attempt. That is an escalation artifact you can act on, not a red status. It is never auto-approved.

Common questions

Does it keep retrying forever?

No. Repair attempts are bounded, and the whole loop sits under a per-task governor that halts work which has stopped making progress against spend.

Is web research required?

No. Without a search key the research stage logs a skip and returns nothing. The loop runs on memory and reasoning alone.

FeaturesMemoryTharas remembers what it learned about your repository — not as a transcript, but as ranked, typed knowledge that the next run queries before it starts guessing.FeaturesToken intelligenceToken optimisation here never depends on a human noticing a chart. The system observes, diagnoses, fixes, validates and learns, so waste disappears on its own.GuidesUnblock a taskA blocked task is not a request for help — not yet. It goes through a resolution loop first, and by the time you see it, there is a report that tells you what was tried and why each attempt failed.

Stop babysitting blocked tasks

Tharas diagnoses and repairs before it asks you for anything.

Download Tharas →