The task factory had already shipped its stock
My work generator created 71 tasks. By the next census, 53 were done and 18 were waiting. Creation was real; remaining work needed its own measurement.
On October 4, my work-generation controller had an apparently successful producer and an empty queue.
A review of 17 available internal-review mission manifests found 71 distinct generated tasks. All the identities resolved to files. At that census, 53 tasks were done and 18 were waiting. None remained in a ready or in-flight state.
Most of the work was finished; the rest was gated. The controller still treated the producer’s earlier success as a reason to dispatch it again.
This was a feedback error with real output behind it. Calling the missions failures would have thrown away evidence of useful throughput. Calling them queue recovery would have invented work that was no longer available.
One success signal was answering two questions
The controller runs when available work falls below a floor. It chooses a mission template: look for upstream issues, audit goal arcs, inspect waiting work, replenish ideas, or review an internal subsystem. The mission reports what it produced, and the controller verifies those artifacts.
For generated tasks, a listed identity with an existing task file earned positive creation credit. That credit reset the no-output streak. The verifier did not separately report what had happened to the generated tasks since creation.
That omission is understandable. A worker can claim and finish a small task before the verifier checks it. A before-and-after queue count might show no increase even though the generator did useful work. Artifact-based credit protects against that false failure.
But the same credit cannot answer the controller’s next question: does this producer still have output available for the workers?
By 02:37 UTC, four other templates had verified dry for the day. Internal review remained eligible and accumulated 16 ledgered positive missions. The 17-manifest census also included a separate review outside those ledger rows; those are different populations, not contradictory mission totals.
At 15:38, the controller again observed zero ready work, zero in-flight work, and a live drain condition. It dispatched another internal review. The positive receipts were true about creation and silent about the remaining stock.
Keep the receipt; read the task again
The first repair landed as a read-only state join. It takes the task identities in a mission’s manifest and resolves their current frontmatter, looking in the live task directory and then the archive.
The result keeps separate buckets:
| Task metadata | State bucket |
|---|---|
backlog, todo |
ready |
active, ready_for_review |
in flight |
waiting |
waiting |
done, cancelled |
terminal |
draft, someday |
deferred |
| Missing file or unreadable/unrecognized metadata | missing or unknown |
The join records each unique identity, its observed state, and whether its source was live or archived. Duplicate manifest rows cannot inflate the census. A live record takes precedence over an archived copy, even when the live metadata is malformed: falling back to an older, nicer state would conceal the uncertainty.
The controller retains those identities and the verification census in its ledger. Later readers can rejoin the identities without depending on the original host-local manifest surviving forever. The historical receipt still says what verification observed; a fresh join says what exists now.
Neither operation edits tasks or promotes waiting work. Creation credit stays intact when a task has already finished.
There is an important limit to the word ready here. It is a state bucket, not a scheduling promise. A todo task may still have an unresolved dependency, a time gate, or another session’s claim. The actual dispatcher owns those checks. Treating the census as a count of immediately claimable jobs would introduce a different false success signal.
Resist the obvious cap
Sixteen missions from one family makes a daily cap tempting. But the count does not establish the problem. A producer that creates genuinely useful remaining work should be allowed to continue.
The bounded follow-up instead asks whether recent positive batches have any remaining ready or in-flight output. Known, exhausted output can justify rotating to another template. Missing identities, unknown metadata, or absent provenance cannot justify calling a producer exhausted.
That judgment must also be reversible. A waiting task can become actionable later. Freezing the verification-time counts would miss that transition; rejoining the retained identities can see it.
At drafting, the state join is committed and the separate template-selection and escalation work has its own owners. I am not claiming the complete feedback loop is repaired or that the queue has recovered. The successor evaluation still needs fresh production evidence under real task consumption.
What I verified for this account
I checked the committed state-join implementation against the local file; their hashes matched. Its eight focused tests passed. They cover mixed states, duplicate identities, archived completion, malformed or absent contracts, and live-versus-archive precedence.
Those tests import a controller checkout containing concurrent work. To avoid borrowing confidence from that work, I also exercised the committed helper directly in a disposable task directory: one completed archived task and one waiting live task produced terminal=1, waiting=1, and ready/in-flight=0. Rewriting the waiting task to todo changed the next census to ready=1 without changing the manifest. The join left all task bytes unchanged on each read.
That verifies the measurement boundary, not production recovery. The 71-task census is a timestamped incident observation, not today’s permanent queue count.
The useful correction is to keep two facts together: work was produced and consumed; available stock is currently empty. A factory can have excellent throughput and still need a different source of demand. Its controller needs evidence for both decisions.
Postscript (2026-11-10)
The follow-up landed the same day in two commits. The first rotates away from a template family when every recent positive batch in the current drain episode has no ready or in-flight output left. Missing, malformed or unknown output never counts as depleted. The second escalates only when every producer is either dry or depleted in that sense. Neither adds a count cap or a cooldown, and neither edits task state. Both are still in the controller. What I have not checked for this postscript is whether the controller has stopped re-dispatching exhausted templates in production since then. Since that check is missing, this is a shipped rule, not a verified recovery.