On 2026-09-07 I went through the heap. It held every proposal my agent loops had made that nobody had acted on. There were 143 proposals in total. 22 had already been worked out and 121 were lying open. When I finished, 21 of the open ones had become cards with work attached. 100 were rejected and 0 were skipped. Each of the 100 has its reason written down. The finding is not the ratio. It is that the heap had never been a production problem.
What I wanted was easy to state. I wanted to know whether the heap was a stock or a graveyard. A stock is work you have not reached yet. A graveyard is work nobody should ever reach. From the outside the two look the same: a list that gets longer every week. My order to myself was strict. Go through every item, close what brings nothing, build what brings something, and follow the process, with cards that carry artifacts.
I believed a growing heap meant the machine was producing more than I could handle. That belief shaped everything around it. It made the heap feel like a debt. It pointed to throughput as the fix: more loops picking items up, higher daily caps, faster review. It also made every new proposal look like more proof of the same thing, because each one made the list longer. I never asked what was in the list. I watched it grow, and I read the growth as demand.
The first surprise came before any decision. My database could not hold a rejection properly. It has one marker for it, decided-against, and nowhere to put a reason. So all the decisions and their reasons went into a JSON file in the repository, and the database only got the marker. If I had relied on the database alone, the 100 rejections would have been 100 identical flags with no explanation.
The heap was not a sign of too much good work. The machine produced more than it would itself have rated as worth doing. A count that only grows says nothing about what it counts. It rises the same way for a pile of good ideas as for a pile of duplicates, stale ideas and proposals waiting on something nobody will provide. Only a pass that opens every item and gives it a verdict separates stock from scrap. The reason has to stay attached, or the pass is wasted: the next loop sees an empty slot and proposes the same thing again. That is why the one-off script pressed only the two buttons the board already had, never propose again and adopt as card, instead of inventing a third path. It also set the product on each new card from the proposal’s target. Since 07.09 the channel follows the card, and a card without a product falls back to asking the rotation.
Die Halde durchgesehen: 21 Vorschläge werden Karten, 100 fallen mit Grund
Went through the heap: 21 proposals become cards, 100 are rejected with a reason
I measured before I decided, because many proposals rested on claims about the outside world. One product site answered with 200, which refuted two proposals that called it unreachable. A press page answered with 404, which confirmed one. Analytics showed no demo form submission and no sign-up in 90 days. Both press-release slots for 2026 had been used up since 17.08. 3 of 3 video cards adopted earlier had gone stale.
The ads proposals were the clearest case. 21 of them had waited six weeks for a budget nobody had approved. They were not bad ideas. They were stuck on a decision I had not made, and the loop kept them alive by default. I rejected them, but the ads loops themselves keep running. That contradiction is written down as an open question. It is not resolved.
| The heap on 2026-09-07 | Count |
|---|---|
| Proposals on the board | 143 |
| Already worked out | 22 |
| Open on the heap | 121 |
| Became cards | 21 |
| Rejected with a reason | 100 |
| Skipped | 0 |
- 2026-09-07I ran a one-off script against the production copy, first as a dry run and then for real. Both runs reported 21 accepted, 100 rejected and 0 skipped. Cards #457–#477 came out with a product and events attached. I also wrote two directory listing texts that no loop can write. I noted that #448 makes three product claims the homepage does not back up.
- 2026-09-07I wrote the handover. By 11:30:24 the dispatcher had queued all 21 cards and started three of them. 18 stayed queued behind the daily caps of 2 per loop and 30 overall. 17 cards went to loops and 4 to me.
- 2026-09-07That afternoon I did a smaller cleanup. I opened a written exception to reject five German drafts for a site that now publishes in English. No file gets deleted, because a rejected draft is a shelved one. The 24 German social remixes of the same site were explicitly out of scope, and the check afterwards had to show they were still there.
- 2026-09-07I ran it as a dry run and for real, and both gave the same numbers: 5 drafts rejected and card #383 dismissed. Then the counter-check looked like a failure, because 10 of the 24 remixes showed as rejected. I checked the reason text instead of the state. My reason was on 5 rows, all blog format, and on none of the remixes.
- 2026-09-07A separate piece of work that day measured how much of my agents’ output ever got accepted. Its thesis was the one the heap later confirmed: the loops have an acceptance problem, not a generation problem.
- 2026-09-07The triage journal lists what I measured before each decision and what stays open. That covers counting artifacts on 09.09, the #448 claims and the ads question.
- 2026-09-07A parallel session working on 42 hidden cards caught a mistake in the triage. The triage gave #460 to an agent, although I had chosen the other branch for that work.
Oeffnung: die fuenf deutschen georgsinger-Entwuerfe werden verworfen
Opening: the five German drafts for my blog are rejected
Vollzug: fuenf deutsche georgsinger-Entwuerfe verworfen, Oeffnung im selben Zug ins Archiv
Done: five German drafts for my blog rejected, and the opening goes to the archive in the same move
The 10 had someone else’s reasons on them. 6 said they were legacy from before a persona correction on 06.09.2026. 4 said user-reject. None had been touched in the last hour. If I had taken the 10 for mine, a check that passed would have become an invented finding. A state on its own proves nothing about who set it. The reason text and the timestamp do.
The record names one tool, quoted as “sqlite3”. It names no inferred ones. A journal from the same day says the production machine has no sqlite3 and is read through node:sqlite over ssh, so the record does not settle how each query actually ran. It also does not say how long the triage took.
Partly solved. The heap is sorted, every rejection carries its reason, and the opening that allowed the run went into the archive in the same move. Some things are not solved. At handover time 18 cards were still queued. The check of which cards actually produced artifacts was set for 09.09, and this record does not contain its result. #448 still makes three claims the homepage does not back up, and the autopush was going to take it at the next free slot. The ads question is open. #460 went to an agent against my own choice. What is ruled out is the belief I started with: the heap was not a throughput problem.
Four commits on 2026-09-07, plus the handover journals from the same day. The fact sheet was measured on 2026-09-17. Costs for the window were measured, but only as a sum of all runs in it, so the record cannot assign any of them to this topic.
99b0e032 · 41e3110f · 542d1a9a · a4d62d2c
