v0.8.0

0.8.0 finishes what 0.7.0 started. That release gave a session somewhere to park a feature it can't finish without a human choice. This one gives you somewhere to answer it.

Answer a parked decision from the dashboard

A deferred epic's card on the Implementation page now shows each blocked feature's question and the session's own recommendation as their own elements, with an Answer… button beside them. It opens a dialog with three choices — follow the recommendation, write your own answer, or drop the feature — and Save does everything the manual edit did. The epic returns to the queue on the next poll exactly as before.

Until now the callout told you to open config.json, find the right entry among the epics, and type into a blocked_answer field. On a real plan that is a 300KB file with a running agent writing to it — a bad thing to ask anyone to edit by hand and an easy thing to break. Answering by hand still works, and is still what tempa status, the halt log and the decision email describe, since there's no button in any of those.

Your answer can't be lost to a write race

config.json has several uncoordinated writers — the runner's session threads, and the spawned agent, which is told to edit its own epic's entry directly. A field written from a third process can be overwritten by whichever of them next saves from a copy it read beforehand. That failure is silent, and it's the worst one available here: you believe you decided, and the epic never comes back.

So answering is written down twice. The decision is recorded first under .tempa/decisions/ — one file per answered feature, one writer, one reader, the same shape the graceful-stop sentinel already uses — and only then written into config.json, through a new cross-process lock (.tempa/config.lock) that re-reads the file inside the lock and touches nothing but that one field. The runner re-applies the recorded answer on every poll until the epic has actually moved, so an overwrite costs a poll interval instead of the decision, and the record is retired once it has been acted on.

Fixed

Dropping a blocked feature no longer strands its epic in deferred forever. The instructions have always offered dropping a feature outright — set its status to done and say why in blocked_answer — but a dropped feature is no longer blocked, so nothing recognised it as answered, and deferred is skipped by both the scheduler and the QA gate. An epic now returns to the queue as soon as nothing is left waiting on you, whether that came about by answering or by dropping, hand edits included.

Full changelog: https://github.com/daus95/tempa/blob/v0.8.0/CHANGELOG.md