Three safeguards reversed the same way. None of them raised an error.
One rule keeps a single outlet from taking over. One keeps the same event from running twice. One keeps posts that are not news out. Over the past month all three turned into their opposites, doing exactly what they say, without making a sound.
This is not a news summary. It is a record of something that happened while building this site.
This site runs unattended at 08:00 KST every day. It pulls a day of articles from twelve feeds, scores them, picks ten and writes them up in Korean and English. A few rules sit in the middle of that. One keeps a single outlet from taking over. One keeps the same event from running twice. One keeps posts that are not news out.
Over the past month I watched all three turn into their opposites. None of them broke. Each did exactly what it says, and none of them made a sound while doing it.
One: keeping a single outlet from taking over
Any one outlet gets at most three of the ten slots. The point is that a reader gets a cross-section rather than one newsroom's front page.
The rule has a back door. Selection walks the candidates in score order, and if that pass ends short of ten, it drops the cap and walks the same list again. Publishing nine under a promise of ten is a visible failure, so I chose to fold the cap rather than leave a slot empty.
On July 31st the back door opened. Five feeds returned 403 that morning. Not because the news was thin. The scheduled run reaches the internet through an allowlist, and the addresses on it were slightly off. The list said wired.com while the feed URL points at www.wired.com. Host names have to match exactly.
Eight of that day's nine articles came from TechCrunch. Counting 28 editions, this happened four times, and every one of those four drew on two or three outlets.
What makes it hard is that none of it looks like anything. The edition has ten entries or nine, the page renders the same, and nothing anywhere records that the cap folded.
Two: keeping the same event from running twice
When two of the ten cover the same event, the run pairs them up and says so. It does not drop either one. An earlier version merged them automatically, and one day five unrelated Google stories collapsed into a single cluster and four of them were quietly thrown away. Since then it only points, and a person reading the originals decides.
On August 20th that warning came back twelve lines long. Four of the ten stories were about Google and four about OpenAI. Four stories from one company make six pairs. Each story you add grows the pile faster than the story count.
Ten of those twelve lines were unrelated. A story about Google buying a bankrupt airline's employee data sat next to a story about Google shipping study tools, flagged as possibly the same event.
The warning exists so the person reading the originals can check. At twelve lines nobody checks. It did not stop working. It said so much that it stopped saying anything.
Three: keeping posts that are not news out
Some feeds carry more than news. The official OpenAI feed mixes company updates and customer stories in with the articles, so the run reads the category on each item and drops what is not news. It also drops items with no category at all, because every uncategorized post I checked turned out to be a customer story.
This rule has a back door too, pointing the other way. The first two loosen when they cannot hold. This one tightens. If a feed stops attaching categories one morning, every item from that feed is dropped that day. It fails toward losing good articles rather than letting bad ones through.
What the three have in common
All three do their job on an ordinary day. All three reverse when they reach their limit. And all three go silent at exactly that moment.
The silence is the worst part. A crash announces itself: there is a red line in the log and a page that will not load. This is not that. The run exits zero, the site builds the way it always does, the email goes out on time. The only thing missing is any record that a rule folded.
Two fixed, one not
Neither fix changed the rule. Both removed the silence.
The same-event warning now sorts by how likely each pair is to be real, shows the top three, and says how many it cut. Cutting quietly would read as "only three today". The category filter now warns when 100 percent of a feed's items are dropped. That number is far more likely to mean the feed stopped sending categories than that everything it published that day was promotional.
The cap is still there. What stops me is not the code but the decision. I do not know what is right on a genuinely quiet day. Eight articles from five outlets may beat ten from two, and that is not a bug but a question about what this site promises: ten stories a day, or ten stories from across the field.
What I can do now is tell the two apart. Since August 20th the run records the names of feeds that did not answer. Short because the world was quiet and short because my configuration was wrong now look different in the record. I would rather decide against a few weeks of that than guess.
Same order as the previous two notes. The writeup comes before the fix so the numbers above stay reproducible. Whatever changes gets appended to this page.