Short notes.With context.

I pushed to the same branch twice, about a minute apart. Both automatic builds came back green. The new page still returned 404.

The build for the older commit had finished five seconds after the build for the newer one, so the older version was the one that went live. Two green checks, and the live site was wrong.

Another commit triggered a fresh build of the current version, and that fixed it. Now, after two pushes close together, I check which build finished last before I verify the live site.

I’m planning a small mobile app that turns the time you have left with the people close to you into a number and asks one question each morning. The plan and the decision notes looked consistent. Before any real code, I had an agent build a rough, clickable simulation of the finished app and click through it end to end while I watched.

In 30 to 40 minutes it showed things I had missed on paper:

• A 16-year-old child marked as living in the same home got about 11,100 days together. The math assumed they would share a home for life.
• After a visit was logged, the app said the number had been updated, and it didn’t move. The formula softened early entries on purpose, so the motivation it promised wouldn’t show in the first months.
• The same visit could be logged from the morning card and from the person’s card, so it counted twice.
• After 30 days, a summary said my intentions matched reality for people I hadn’t seen at all. For someone you see a few times a year, 30 days is too short to judge.
• A phone call and an in-person meeting landed under the same “last seen” label.

Each one went back to the decision list.

For a simple flow this is probably more than needed. Here the numbers, the timing and the wording depend on each other, and reading the plan didn’t show me where they stopped fitting together. Walking through a fake version of the finished thing did.

One of my projects grew in a way I never planned. I put up a few pilot pages, forgot it existed for months, and only went back after a search engine I rarely use emailed me about its traffic. I optimized it, added content every day, and it turned into real monthly income. I count that as a success, but it was a surprise jump, not how my projects usually go.

Recently its revenue started falling. I first suspected a technical problem on the partner’s tracking side. Then I checked analytics, search queries and traffic. Nothing looked wrong, and I still could not work out why sales had dropped.

That is the part I have no patience for. It was going well, nothing changed, the clicks are still coming, and the revenue is not there to match.

The best I can do is keep analyzing and tracking. It may be a shift in the broader trend, a random dry spell, or something else. I believe it can be solved.

For two days I have watched the notifications show up in my own system. The behavior I expected from them has not happened.

It makes me wonder whether I am missing the same gap here too: giving an agent an instruction is not the same as building a process that works.

I have not verified the cause or a fix yet.

At Google’s Search Central Live Deep Dive in Barcelona, Gary Illyes spoke about core updates. Two people who were in the room published recaps in the first days of October 2026. On one point they report opposite things.

Nacho Mascort’s write-up, in Spanish, asks whether Google evaluates the page or the site and answers “El site.” He writes that Illyes made it clear in the room that core updates look at the site, and that weak pages drag down the good ones.

The ROAST recap of day three puts it this way: “Core updates don’t focus on websites. They target content at page level, not at domain level. That is why some pages on a site go up while others go down.”

Neither recap is a transcript. Both paraphrase, and neither marks the line as a direct quote from the stage.

Google’s core updates documentation can be read in support of either one. It says the changes “don’t target specific sites or individual web pages.” It also tells an owner with a sustained drop to check whether “your site overall (not just individual pages)” is delivering helpful content, and says it can take several months for Google’s systems to confirm that “the site as a whole” has improved.

A reader who saw only one recap came away with a rule the other contradicts. The documentation is the only one of the three sources that Google wrote.

I asked my AI assistant what a website did. It read the text and called it a blog. After I asked it to open the site in a browser, it found an interactive terminal.

Trying the commands clarified things further: the terminal opened articles, music and a game. The development tools described in the articles ran elsewhere.

Next time an assistant says it has inspected something, I’ll ask what it read, what it saw and what it actually tried.

We compared traffic over matching days and hours, but the first reading was still incomplete. A few days later, the report showed more sessions for the same past day. The reporting had caught up.

The calendar had moved on before the data had finished processing. Matching time windows hadn’t removed that uncertainty.

Before changing the site in response to an apparent drop, we needed to read the same window again once the data had settled.

In one project, rules meant to prevent mistakes were also removing useful information. An uncertain connection was enough to discard an item, even when its source was available.

Showing the sourced item with a clear uncertainty label brought that information back without treating the connection as established. This flexibility stayed separate from claims where a wrong connection could cause harm.

A quality check needs to catch unsupported additions and useful information that disappears. Fewer visible errors do not tell the whole story.

Copies do not always occupy separate space. On a copy-on-write filesystem, they can share disk blocks. These implementation notes explain how temporary application copies use that mechanism.

Adding up their folder sizes does not tell you how much space deletion will free. Measure free space before and after cleanup, and account for anything else changing the disk at the same time.

My Mac’s fans were running, which doesn’t usually happen. Coding agents were working in a few projects at the time, so they were the obvious suspect.

They weren’t the load. The agent apps were using 1 to 3 percent CPU. Five yes processes were using about 80 percent each and had been running for two and a half hours. Their parent was launchd, so nothing owned them anymore, and their working directory showed which repository they came from.

I asked the agent working in that repository. According to it, an earlier session had started them to put the machine under load while chasing unstable tests, and the command to stop them didn’t work in that environment. It stopped all five.

An agent session ending doesn’t mean the processes it started have ended.