zemnanet

A Withheld Plugin Result Is Not the Tool Never Ran

Sat, 10 Oct 2026 07:00:00 +0700

The junior pastes a chat. The agent asked for Bash(git status). A plugin line then says Denied. The tool result is empty. They file the ticket: “the tool never ran. always-ask blocked it.”

I stop the run there. A withheld plugin result is not the tool never ran. Claude Code’s public notes that named this field are blunt: when a mod denies a tool call after the tool ran, Claude and you now read that the tool ran and a plugin withheld its result. The tool executed. The result was held. The empty pane is not a skip. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.295] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat a UNC path read as a local allow in A UNC Path Read Is Not a Local Allow, a leftover allowed-tools rule as you still in plan mode in A Leftover Allowed-Tools Rule Is Not You Still in Plan Mode, and a repeated reply ID as a second approval in A Repeated Reply ID Is Not a Second Approval. This post is the same desk rule for a denied tool with no result. Print withheld versus never ran. Name who owns the Claude Code answers.

The question is not whether the pane stayed empty. The question is whether the named owner can still tell a withheld plugin result from a tool that never ran.

A UNC Path Read Is Not a Local Allow

Fri, 09 Oct 2026 07:00:00 +0700

The junior approved Read on C:\work\app\config.yaml. The next turn reads \\fileserver\share\app\config.yaml with no dialog. Chat files the ticket: “always-ask is off. the sandbox already allowed it.”

I stop the run there. A UNC path read is not a local allow. Claude Code’s public notes that named this field are blunt: PreToolUse hook approvals and auto mode used to bypass the permission prompt for file reads from network (UNC) paths. Official permissions docs already say a command whose arguments include a network (UNC) path prompts, because looking that path up can send Windows credentials to the host it names. The human approved a local spelling. The second path is not that allow. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.292] [Source: https://code.claude.com/docs/en/permissions]

I already refused to treat a leftover allowed-tools rule as you still in plan mode in A Leftover Allowed-Tools Rule Is Not You Still in Plan Mode, a repeated reply ID as a second approval in A Repeated Reply ID Is Not a Second Approval, and sandbox auto-allow as a retry tax on equals in Sandbox Auto-Allow Is Not a Retry Tax on Equals in Inline Scripts. This post is the same desk rule for a network-shaped read. Print the path class. Print whether the allow was local. Name who owns the Claude Code answers.

The question is not whether the prompt stayed quiet. The question is whether the named owner can still tell a UNC path read from a local allow.

A Leftover Allowed-Tools Rule Is Not You Still in Plan Mode

Thu, 08 Oct 2026 07:00:00 +0700

The junior hits Shift+Tab. The status bar leaves plan mode. The next turn still runs Bash from a skill with no prompt. Chat files the ticket: “plan mode is still on. always-ask is off.”

I stop the run there. A leftover allowed-tools rule is not you still in plan mode. Claude Code’s public notes that named this field are blunt: a skill’s or slash command’s allowed-tools rule used to come back in a later turn when you leave auto mode or plan mode partway through that turn. Official skills docs already say the grant is for the invoking turn and clears when you send the next message. The human left the mode. The second turn is not a stuck plan. [Source: https://code.claude.com/docs/en/changelog] [Source: https://code.claude.com/docs/en/skills]

I already refused to treat a repeated reply ID as a second approval in A Repeated Reply ID Is Not a Second Approval, a nested deny as a mod approval in A Nested Deny Is Not a Mod Approval, and an allowed-mail list as a Cloudflare account in An Allowed-Mail List Is Not a Cloudflare Account. This post is the same desk rule for a leftover skill pass. Print the allowed-tools line. Print whether the session already left plan or auto. Name who owns the Claude Code answers.

The question is not whether the status bar looked quiet. The question is whether the named owner can still tell a leftover allowed-tools rule from a stuck plan.

A Repeated Reply ID Is Not a Second Approval

Wed, 07 Oct 2026 07:00:00 +0700

The junior pastes a phone screenshot. They already answered yes kqmpw on Telegram. A second Bash row ran. Chat files the ticket: “always-ask is off. I never approved that command.”

I stop the run there. A repeated reply ID is not a second approval. Claude Code’s public notes that named this field are blunt: permission relay on --channels used to treat a reply ID that repeats inside one session as a verdict on a different prompt. The field now ignores that repeat. The human still answered one ID. The second tool is not a second allow. [Source: https://code.claude.com/docs/en/changelog] [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.290]

I already refused to treat an allowed-mail list as a Cloudflare account in An Allowed-Mail List Is Not a Cloudflare Account, a nested deny as a mod approval in A Nested Deny Is Not a Mod Approval, and a 40-character ghs_ check as a valid App token in A 40-Character ghs_ Check Is Not a Valid App Token. This post is the same desk rule for a channel yes. Print the reply ID. Print whether that ID is still an open request. Name who owns the Claude Code answers.

The question is not whether the phone said yes. The question is whether the named owner can still tell a repeated reply ID from a second approval.

An Allowed-Mail List Is Not a Cloudflare Account

Tue, 06 Oct 2026 07:00:00 +0700

The junior pastes a screenshot. The coding agent shared a trycloudflare.com URL. The visitor typed an email, hit a Cloudflare Access page, and stalled. Chat files the ticket: “the visitor needs a Cloudflare account. Access is misconfigured.”

I stop the run there. An allowed-mail list is not a Cloudflare account. Cloudflare’s public notes that named this field are blunt: --allowed-mail on cloudflared restricts a Quick Tunnel to the email addresses and domains you list. Visitors authenticate with a one-time PIN. Nobody on either side needs a Cloudflare account. Access ends when you stop the process. That is email OTP on a Quick Tunnel. It is not production Access on a named Tunnel. It is not a dashboard login. [Source: https://blog.cloudflare.com/protected-quick-tunnels/] [Source: https://developers.cloudflare.com/changelog/post/2026-10-02-protected-quick-tunnels/]

I already refused to treat a nested deny as a mod approval in A Nested Deny Is Not a Mod Approval, a 40-character ghs_ check as a valid App token in A 40-Character ghs_ Check Is Not a Valid App Token, and a redirected dangerous rm as always-ask off in Print the Redirect Before You File Always-Ask Off. This post is the same desk rule for a shared preview URL. Print the guest list. Print whether a Cloudflare account exists. Name who owns the tunnel answers.

The question is not whether the Access page looked official. The question is whether the named owner can still tell an allowed-mail list from a Cloudflare account.

A Nested Deny Is Not a Mod Approval

Mon, 05 Oct 2026 07:00:00 +0700

The junior pastes a session log. The managed machine has Bash(git clean *) on deny, or Bash(rm *) on ask. The agent ran cd /tmp && git clean -fd. A user-installed mod printed Approved on the inner command. They file the ticket: “deny is off. The managed allow won.”

I stop the run there. A nested deny is not a mod approval. Anthropic’s public notes that named this field are blunt: a deny or ask rule on a nested part of a compound shell command did not hold over a user-installed mod’s approval on managed machines. The inner command still had a rule. The approval source was a user-installed mod, not the named owner of Claude Code answers. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.289] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat a 40-character ghs_ check as a valid App token in A 40-Character ghs_ Check Is Not a Valid App Token. I already refused to treat a redirected dangerous rm as always-ask off in Print the Redirect Before You File Always-Ask Off. This post is the same desk rule for a compound shell. Print the nested rule. Print the approval source. Name who owns the Claude Code answers.

The question is not whether the inner command ran. The question is whether the named owner can still tell a nested deny from a plugin that approved the inner piece.

A 40-Character ghs_ Check Is Not a Valid App Token

Sun, 04 Oct 2026 07:00:00 +0700

The junior pastes a CI log. The GitHub App minted a ghs_ string. The helper printed invalid token: expected 40 characters. They file the ticket: “the App token is broken.”

I stop the run there. A 40-character ghs_ check is not a valid App token. GitHub’s public notes that named this field are blunt: newly minted GitHub App installation tokens still start with ghs_, and they are now about 520 characters instead of 40. Permissions, repository scoping, the one-hour expiry, and the installation-token REST endpoint did not change. [Source: https://github.blog/changelog/2026-10-02-stateless-github-app-installation-tokens-rolled-out/] [Source: https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app]

I already refused to treat a redirected dangerous rm as always-ask off in Print the Redirect Before You File Always-Ask Off. I already refused to treat a laravel/ai lockfile line as a patched fetch client in A Laravel/AI Lockfile Line Is Not a Patched Fetch Client. I already refused to treat Copilot’s ready-to-approve line as a required merge vote in Leave Copilot Approve Off. This post is the same desk rule for a GitHub App installation token. Print the length check. Print whether the string was treated as opaque. Name who owns the App answers.

The question is not whether the string is 40 characters. The question is whether the named owner can still tell a length check written for the legacy format from a token that GitHub already minted.

Print the Redirect Before You File Always-Ask Off

Sat, 03 Oct 2026 07:00:00 +0700

The junior pastes a terminal screenshot. The coding agent ran a delete. There was no always-ask prompt. They file the ticket: “always-ask is off, so this rm is allowed.”

I stop the run there. Print the full command, including the redirect, before you file always-ask off. The public Claude Code notes that named this field are blunt: a dangerous rm on / or the home directory lost its always-ask safeguard when the same command also redirected output to a ~ or wildcard path. That is a redirect on the same line, not a named allow and not a missing setting. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.287] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat a NUL byte in a permission rule as a wildcard allow in A NUL Byte in a Permission Rule Is Not a Wildcard Allow. I already refused to treat sandbox auto-allow as a retry tax on equals in Sandbox Auto-Allow Is Not a Retry Tax on Equals in Inline Scripts. I already refused to treat Copilot’s ready-to-approve line as a required merge vote in Leave Copilot Approve Off. This post is the same desk rule for always-ask on a dangerous delete. Print the redirect. Print whether always-ask still fired. Name who owns the always-ask answers.

The question is not whether the prompt appeared. The question is whether the named owner can still tell a tilde redirect from a setting that is actually off.

A Laravel/AI Lockfile Line Is Not a Patched Fetch Client

Fri, 02 Oct 2026 07:00:00 +0700

The junior pastes composer.lock. The file contains laravel/ai. Dependabot is green. The ticket says “AI package is patched.”

I stop the run there. A laravel/ai lockfile line is not a patched fetch client. The public advisory that named this field is blunt: the Vercel adapter and the AG-UI adapter in laravel/ai 1.0.0 accepted a client-supplied file URL and fetched it on the server without a guard. That is one package, one pair of adapters, one fetch client. It is not laravel/mcp. It is not framework 13.34. It is not “Composer found a line, so the chat endpoint is safe.” [Source: https://github.com/laravel/ai/security/advisories/GHSA-6qhr-3g93-pxhw] [Source: https://laravel-news.com/laravel-ai-mcp-security-advisories]

I already refused to treat a 2,500+ Actions count as an exact run inventory in A 2,500+ Actions Count Is Not an Exact Run Inventory. I already refused to treat a NUL byte in a permission rule as a wildcard allow in A NUL Byte in a Permission Rule Is Not a Wildcard Allow. I already refused to treat Copilot’s ready-to-approve line as a required merge vote in Leave Copilot Approve Off. This post is the same desk rule for a Composer lock line. Print the package. Print the locked version. Name who owns the Laravel answers.

The question is not whether the lockfile looks patched. The question is whether the named owner can tell this fetch client from a different advisory and from a framework bump.

Sandbox Auto-Allow Is Not a Retry Tax on Equals in Inline Scripts

Thu, 01 Oct 2026 07:00:00 +0700

The junior pastes a terminal screenshot. Sandbox is on. Auto-allow is on. The coding agent ran python3 -c "x=1". Claude Code asked for approval. They file the ticket: “auto-allow is off.”

I stop the run there. Sandbox auto-allow is not a retry tax on equals in inline scripts. The public Claude Code notes that named this field are blunt: sandbox auto-allow asked for approval on every run of many inline scripts (python3 -c, node -e) just because they contain =. That is a matcher on the equals sign, not a missing allow. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.285] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat a NUL byte in a permission rule as a wildcard allow in A NUL Byte in a Permission Rule Is Not a Wildcard Allow. I already refused to treat a present AGENTS.md as the project instructions while CLAUDE.md exists in A Present AGENTS.md Is Not the Project Instructions While CLAUDE.md Exists. I already refused to treat Copilot’s ready-to-approve line as a required merge vote in Leave Copilot Approve Off. This post is the same desk rule for sandbox auto-allow. Print the command. Print whether it contains =. Name who owns the auto-allow answers.

The question is not whether the prompt looks like a broken allow. The question is whether the named owner can tell an equals matcher from a setting that is actually off.

A Moved Self-Hosted Runner Deadline Is Not an All-Clear

Wed, 30 Sep 2026 07:00:00 +0700

Standup hears “the date moved.” Someone pasted the GitHub Changelog from 28 September 2026. The coding agent pasted the headline and filed all-clear: “we have extra time; skip the fleet this week.”

I stop the run there. A moved self-hosted runner deadline is not an all-clear. Official GitHub changelog for 28 September 2026 is blunt: the enforcement date for GitHub Actions minimum version requirements for self-hosted runners on GitHub Enterprise Cloud changed. The change ships Monday 28 September 2026. Full enforcement begins Tuesday 29 September 2026. That is instead of the date previously announced. The requirements themselves are unchanged. Today is Wednesday 30 September 2026. The extra day already ended. [Source: https://github.blog/changelog/2026-09-28-self-hosted-runner-version-enforcement-date-has-moved/]

I already refused to treat a 2,500+ Actions badge as an exact run inventory in A 2,500+ Actions Count Is Not an Exact Run Inventory. I already refused to treat ubuntu-latest as a runner image I already tested in Ubuntu-latest Is Not a Runner Image You Already Tested. I already refused to treat a timed-out Laravel job as a killed worker pool in A Timed-Out Job Is Not a Killed Worker. This post is the same desk rule for a moved date. Print the moved date. Print both floors. Name who owns the self-hosted fleet.

The question is not whether a moved date demos well in a screenshot. The question is whether the named owner can tell a moved date from a refused job before paging CI.

A 2,500+ Actions Count Is Not an Exact Run Inventory

Tue, 29 Sep 2026 07:00:00 +0700

Standup hears “we have 2,500 runs.” Someone pasted the Actions tab. The coding agent pasted total_count from GET /repos/{owner}/{repo}/actions/runs. The junior files missing-runs: “the rest of the history vanished.”

I stop the run there. A 2,500+ Actions count is not an exact run inventory. Official GitHub changelog for 25 September 2026 is blunt: queries for workflow runs in the Actions API and UI still paginate up to 1,000 items, and if the number of found records exceeds 2,500, GitHub reports “2,500+” instead of an exact number. Larger queries often timed out and returned however many records had been counted before the timeout. The cap is the honest number. The exact inventory is a different ticket. [Source: https://github.blog/changelog/2026-09-25-changes-to-query-results-in-the-github-actions-api-and-ui/]

I already refused to treat a timed-out Laravel job as a killed worker pool in A Timed-Out Job Is Not a Killed Worker. I already refused to treat ubuntu-latest as a runner image I already tested in Ubuntu-latest Is Not a Runner Image You Already Tested. I already refused to treat an auto-started Codex background server as compatible settings in An Auto-Started Codex Background Server Is Not Compatible Settings. This post is the same desk rule for Actions history. Print the cap. Print the page. Name who owns the workflow-run query.

The question is not whether a dashboard demos a big number. The question is whether the named owner can tell a capped count from a missing run before paging CI.

An Auto-Started Codex Background Server Is Not Compatible Settings

Mon, 28 Sep 2026 07:00:00 +0700

The junior pastes a terminal. codex opened. Chat is quiet. They file an all-clear: “the background server is compatible.”

I stop the run there. An auto-started Codex background server is not compatible settings. The public Codex CLI notes that named this field are blunt: automatic background-server startup is enabled for eligible interactive sessions, with recovery choices when server settings are incompatible. That is a launch path. It is not a signed match between this session and the shared server. [Source: https://github.com/openai/codex/releases/tag/rust-v0.157.0] [Source: https://github.com/openai/codex/pull/47318]

I already refused to treat a green wrangler deploy as an immediate Durable Object cutover in A Green Wrangler Deploy Is Not an Immediate Durable Object Code Cutover, a /readyz 200 through a Postgres blip as a healthy store in A /readyz 200 Through a Postgres Blip Is Not a Healthy Store, and a timed-out job as a killed worker in A Timed-Out Job Is Not a Killed Worker. This post is the same desk rule for a Codex prompt that opened. Print auto-start. Print the recovery choice. Name who owns the Codex session.

The question is not whether the CLI looks open. The question is whether the named owner can still tell “eligible launch started a shared server” from “this session’s required settings match that server.”

A Green Wrangler Deploy Is Not an Immediate Durable Object Code Cutover

Sun, 27 Sep 2026 07:00:00 +0700

The junior pastes a terminal. npx wrangler deploy exits 0. Chat is quiet. They file an all-cutover: “Durable Object code is live.”

I stop the run there. A green wrangler deploy is not an immediate Durable Object code cutover. The public Workers SDK notes that named this field are blunt: Durable Objects now have code update strategies on wrangler deploy, wrangler versions deploy, and wrangler rollback. When the strategy is unset, it defaults to deferred with a 5-minute maximum delay. Delays cannot exceed 24 hours. That is a Worker bundle that uploaded. It is not every live object already running the new class. [Source: https://github.com/cloudflare/workers-sdk/releases/tag/wrangler%404.141.0] [Source: https://releasebot.io/updates/cloudflare/workers-sdk]

I already refused to treat a /readyz 200 through a Postgres blip as a healthy store in A /readyz 200 Through a Postgres Blip Is Not a Healthy Store. I already refused to treat a timed-out job as a killed worker in A Timed-Out Job Is Not a Killed Worker. I already refused to treat every-turn HTTP 400 as a dead gateway in Every-Turn HTTP 400 on ANTHROPIC_BASE_URL Is Not a Dead Gateway. This post is the same desk rule for a green deploy. Print deploy. Print the strategy. Name who owns the Workers cutover.

The question is not whether the CLI looks green. The question is whether the named owner can still tell “Worker version uploaded” from “Durable Object instances left the old class.”

A /readyz 200 Through a Postgres Blip Is Not a Healthy Store

Sat, 26 Sep 2026 07:00:00 +0700

The junior pastes a curl. /readyz returns 200. Chat is quiet. They file an all-clear: “Postgres is healthy.”

I stop the run there. A /readyz 200 through a Postgres blip is not a healthy store. The public Claude Code notes that named this field are blunt: the Claude apps gateway gained store.readiness_grace_seconds so /readyz can stay ready through a short Postgres outage such as a database failover. That is a ready bit that held. It is not a store that answered SELECT 1. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.282] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat a NUL byte in a permission rule as a wildcard allow in A NUL Byte in a Permission Rule Is Not a Wildcard Allow. I already refused to treat a timed-out job as a killed worker in A Timed-Out Job Is Not a Killed Worker. I already refused to treat every-turn HTTP 400 as a dead gateway in Every-Turn HTTP 400 on ANTHROPIC_BASE_URL Is Not a Dead Gateway. This post is the same desk rule for a green ready check. Print ready. Print the store. Name who owns the gateway check.

The question is not whether curl looks green. The question is whether the named owner can still tell “ready to take traffic” from “the store answered.”

A NUL Byte in a Permission Rule Is Not a Wildcard Allow

Fri, 25 Sep 2026 07:00:00 +0700

The junior pastes a /permissions screenshot. A deny rule is in the list. The coding agent still ran the tool. They file an allow-all ticket: “the rule allowed everything.”

I stop the run there. A NUL byte in a permission rule is not a wildcard allow. The public Claude Code release that named this field is blunt: a permission rule containing a NUL byte was expanded into a wildcard match; such a rule now matches nothing. That is a matcher bug, not proof that deny lost. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.281] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat a timed-out job as a killed worker in A Timed-Out Job Is Not a Killed Worker. I already refused to treat one matching glob as a sandbox exemption for the rest of the line in One Matching Glob Is Not a Sandbox Exemption for the Rest of the Line. I already refused to treat a present AGENTS.md as the project instructions while CLAUDE.md exists in A Present AGENTS.md Is Not the Project Instructions While CLAUDE.md Exists. This post is the same desk rule for permission bytes. Print the bytes. Print the match. Name who owns the permission list.

The question is not whether a deny line looks present in JSON. The question is whether the named owner can tell a wildcard from a rule that matches nothing.

A Timed-Out Job Is Not a Killed Worker

Thu, 24 Sep 2026 07:00:00 +0700

The junior pastes a Supervisor screenshot. One queue:work line vanished. The failed_jobs table is empty. Horizon still shows a running supervisor. They file a pool outage: “the workers are dead.”

I stop the run there. A timed-out job is not a killed worker. Official Laravel queue docs are blunt: the default timeout is 60 seconds, and if a job runs longer than that number, the worker processing that job exits with an error. A process manager on the server then starts another worker. That is one job hitting a clock, not a pool that died. [Source: https://laravel.com/docs/13.x/queues]

I already refused to treat one matching glob as a sandbox exemption for the rest of the line in One Matching Glob Is Not a Sandbox Exemption for the Rest of the Line. I already refused to treat a hostname handed to a forward proxy as a missing host in Handing the Hostname to the Forward Proxy Is Not a Missing Host. I already refused to treat ubuntu-latest as a runner image I already tested in Ubuntu-latest Is Not a Runner Image You Already Tested. This post is the same desk rule for queues. Print the timeout. Print the kill. Name who owns queue:work.

The question is not whether a long job demos on your laptop. The question is whether the named owner can tell a job clock from a worker death before paging the pool.

One Matching Glob Is Not a Sandbox Exemption for the Rest of the Line

Wed, 23 Sep 2026 07:00:00 +0700

The junior pastes a settings.json screenshot. sandbox.excludedCommands has docker *. The coding agent ran npm ci && docker build .. The first token looks like a match. They file a sandbox hole: “the whole line ran outside the box.”

I stop the run there. One matching glob is not a sandbox exemption for the rest of the line. Official settings docs are blunt: your entries take a Bash call out of the sandbox only when they cover every command in it. A docker * entry alone does not take npm ci && docker build . out of the sandbox. [Source: https://code.claude.com/docs/en/settings-reference]

I already refused to treat a failed local DNS lookup as a missing host in Handing the Hostname to the Forward Proxy Is Not a Missing Host. I already refused to treat a present AGENTS.md as the project instructions while CLAUDE.md exists in A Present AGENTS.md Is Not the Project Instructions While CLAUDE.md Exists. I already refused to treat ubuntu-latest as a runner image I already tested in Ubuntu-latest Is Not a Runner Image You Already Tested. This post is the same desk rule for compound Bash. Print the glob. Split the parts. Name who owns sandbox.excludedCommands.

The question is not whether docker * demos on a single command. The question is whether the named owner can prove every part of the line matched.

Handing the Hostname to the Forward Proxy Is Not a Missing Host

Mon, 21 Sep 2026 07:00:00 +0700

The junior SSHs into the gateway box. nslookup api.anthropic.com times out. getent hosts is empty. They paste that into the incident channel and call DNS down. Standup treats it as a missing host.

I stop the run there. Handing the hostname to the forward proxy is not a missing host. On a Claude apps gateway whose only egress is that proxy, the field is whether the gateway hands the proxy the name. Local resolve on the pod is the wrong screenshot.

Official config docs put the switch in one environment variable: CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1, next to HTTPS_PROXY, when the pod reaches other hosts only through that forward proxy and cannot resolve public DNS names itself, or when the proxy refuses CONNECT to an IP address. [Source: https://code.claude.com/docs/en/claude-apps-gateway-config]

I already refused to treat a present AGENTS.md as the project instructions while CLAUDE.md exists in A Present AGENTS.md Is Not the Project Instructions While CLAUDE.md Exists. I already refused to treat ubuntu-latest as a runner image I already tested in Ubuntu-latest Is Not a Runner Image You Already Tested. I already refused to treat a missing Wrangler previews block as production bindings in A Missing Previews Block Is Not a License to Reuse Production Bindings. This post is the same desk rule for gateway egress. Print the env. Read the boot network: line. Name who owns the boundary.

The question is not whether the pod can resolve the provider. The question is whether the named owner can prove the hostname left the box through the proxy.

A Present AGENTS.md Is Not the Project Instructions While CLAUDE.md Exists

Sun, 20 Sep 2026 07:00:00 +0700

The junior opens the repo root. AGENTS.md is there. Codex already reads it. Copilot already reads it. They added Claude Code last week. The agent still ships a Laravel migration without the test command they wrote in that file. Standup calls it a model miss.

I stop the run there. A present AGENTS.md is not the project instructions while CLAUDE.md exists. Default load is the Claude files only when CLAUDE.md or CLAUDE.local.md sits in the working directory or above it. The shared file stays on disk. The session never treats it as the brief.

Official memory docs put that in one table. An AGENTS.md with no Claude file in the tree loads. An AGENTS.md next to a CLAUDE.md or CLAUDE.local.md does not. Change the mix under Project instructions in /config. [Source: https://code.claude.com/docs/en/memory]

I already refused to treat ubuntu-latest as a runner image I already tested in Ubuntu-latest Is Not a Runner Image You Already Tested. I already refused to treat a missing Wrangler previews block as production bindings in A Missing Previews Block Is Not a License to Reuse Production Bindings. This post is the same desk rule for an instruction file. Print the load line. Open /config. Name who owns the file Claude actually read.

The question is not whether AGENTS.md exists on disk. The question is whether the named owner can prove which file this session loaded.

Ubuntu-latest Is Not a Runner Image You Already Tested

Sat, 19 Sep 2026 07:00:00 +0700

Standup hears “CI is green.” Someone pasted a GitHub Actions log. The job used runs-on: ubuntu-latest. PHPUnit passed. Vite built. The coding agent says the pipeline is already on the new runner because the changelog said Ubuntu 26 is generally available.

I stop the run there. ubuntu-latest is not a runner image you already tested. Official GitHub notes for 17 September 2026 say the Ubuntu 26.04 runner image left public preview and is fully supported for production workflows on x64 and arm64. The same note says the ubuntu-latest label will migrate from Ubuntu 24.04 to Ubuntu 26.04 gradually between 19 October and 19 November 2026. Until that window, a green job on ubuntu-latest is still the current label, not a signed test of the next image. [Source: https://github.blog/changelog/2026-09-17-ubuntu-26-generally-available-and-latest-migration/]

The announcement issue in actions/runner-images is public. You can select the new image today with runs-on: ubuntu-26.04 or runs-on: ubuntu-26.04-arm. GitHub’s own table of selected software differences is not an exhaustive list. Workflows that depend on a package version, system library, compiler, prebuilt binary, or architecture-specific dependency still need a job on the new image. [Source: https://github.com/actions/runner-images/issues/14747]

I already refused to treat a missing Wrangler previews block as permission to reuse production bindings in A Missing Previews Block Is Not a License to Reuse Production Bindings. I already refused to treat an old MCP handshake as a dead Laravel server in A Client That Still Sends Initialize Is Not a Broken Laravel MCP Server. This post is the same desk rule for a moving CI label. Print the label. Print the named pin. Name who owns the workflow file.

The question is not whether Ubuntu 26 demos well on a personal fork. The question is whether the named owner can still tell a moving label from an image the team already ran.

A Missing Previews Block Is Not a License to Reuse Production Bindings

Fri, 18 Sep 2026 07:00:00 +0700

Standup hears “preview is using production.” Someone pasted a Wrangler log. There is no previews block in the local config. The CLI wrote a Preview Base into the file. When no Preview Base existed, it printed a placeholder derived from production bindings and warned against reusing that configuration. The junior treats the placeholder as a filled-in answer. They tell the coding agent to copy the production KV id, the production D1 id, and the production secret names into the new block so the preview “just works.”

I stop the run there. A missing previews block is not a license to reuse production bindings. Official Wrangler notes for the 16 September 2026 GitHub tag, not a prerelease, name the field: when a local previews block is absent, Wrangler writes the Preview Base configuration to the local config file. When no Preview Base configuration exists, Wrangler prints a placeholder configuration derived from production bindings and warns against reusing production binding configuration. [Source: https://github.com/cloudflare/workers-sdk/releases/tag/wrangler%404.133.0]

The pull request behind that note is public. When you run npx wrangler preview with no local previews block, Wrangler recommends a snippet. The expected snippet uses REPLACE_ME placeholders. Two origins, same rule: dashboard Preview Base, or first-time preview from production settings. Both paths are supposed to land on placeholders, not on live production ids. [Source: https://github.com/cloudflare/workers-sdk/pull/15600]

I already refused to treat an old MCP handshake as a dead Laravel server in A Client That Still Sends Initialize Is Not a Broken Laravel MCP Server. I already refused to treat a five-minute WebFetch fail as a hung model in A 300-Second WebFetch Fail Is Not a Hung Model. This post is the same desk rule for a config write. Print the block. Print the placeholder. Name who owns wrangler.jsonc.

The question is not whether wrangler preview demos well on a personal account. The question is whether the named owner can still tell an onboarding warning from permission to point preview at production data.

A Client That Still Sends Initialize Is Not a Broken Laravel MCP Server

Thu, 17 Sep 2026 07:00:00 +0700

Standup hears “Laravel MCP is broken.” Someone pasted a JSON-RPC log. The first method is initialize. The package pin on the host is the new stable line. The junior files a server-outage ticket. They ping the person who shipped the bump. They tell the coding agent to wait for a rollback.

I stop the run there. A client that still opens with initialize is not a broken Laravel MCP server. Official upgrade notes for the 14 September 2026 GitHub tag, published 14:39 UTC, not a prerelease, name the field: the server now speaks protocol revision 2026-07-28 by default, and server/discover replaces the old handshake for modern clients. The same notes say clients that still open with initialize continue to work. The server answers that handshake with 2025-11-25 or 2025-06-18, whichever the client requested. [Source: https://github.com/laravel/mcp/releases/tag/v1.0.0] [Source: https://github.com/laravel/mcp/blob/v1.0.0/UPGRADE.md]

Laravel News, 15 September 2026, repeats the same desk rule in one sentence: clients that still connect with initialize continue to work. [Source: https://laravel-news.com/laravel-mcp-1-0]

I already refused to treat an every-turn HTTP 400 as a dead gateway in Every-Turn HTTP 400 on ANTHROPIC_BASE_URL Is Not a Dead Gateway. I already refused to treat a five-minute WebFetch fail as a hung model in A 300-Second WebFetch Fail Is Not a Hung Model. This post is the same desk rule for an old handshake on a new MCP server. Print the method. Print the pin. Name who owns both.

The question is not whether the new handshake demos well in Inspector. The question is whether the named owner can still tell an old client from a dead server.

A 300-Second WebFetch Fail Is Not a Hung Model

Wed, 16 Sep 2026 07:00:00 +0700

Standup hears “the model hung.” Someone pasted a terminal. The line sat on Fetching. Five minutes later it went red. The junior files a model-outage ticket. They ping the vendor channel. They tell chat to wait for a new brain.

I stop the run there. A red WebFetch at five minutes is not a hung model. Official notes from 10 September 2026 name the field: WebFetch used to hang indefinitely on a server that keeps the response open without finishing. A fetch now fails after 300 seconds. The env that overrides that deadline is CLAUDE_CODE_WEBFETCH_DEADLINE_MS. Zero turns the limit off. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.268] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat a wait line as a finished background agent in Waiting for Your Input Is Not a Finished Background Agent. I already refused to treat an every-turn HTTP 400 as a dead gateway in Every-Turn HTTP 400 on ANTHROPIC_BASE_URL Is Not a Dead Gateway. This post is the same desk rule for a fetch that never closed. Print the pin. Print the deadline. Name who owns both.

The question is not whether chat looks stuck. The question is whether the named owner can still tell a download deadline from a model that stopped producing tokens.

Every-Turn HTTP 400 on ANTHROPIC_BASE_URL Is Not a Dead Gateway

Mon, 14 Sep 2026 07:00:00 +0700

Standup hears “the gateway is down.” Someone pasted a terminal. Every turn is HTTP 400. The junior files a status ticket. They ping the network channel. They tell chat to wait for the vendor.

I stop the run there. A wall of 400s on a named ANTHROPIC_BASE_URL is not a dead gateway. Official notes from 10 September 2026 name the field: every turn failed with HTTP 400 on third-party Anthropic-compatible endpoints since a mid-week CLI pin, because those endpoints rejected a regex in the Artifact tool’s input schema. The later pin fixes the schema. The host was answering. The request was illegal for that endpoint. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.268] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat a wait line as a finished background agent in Waiting for Your Input Is Not a Finished Background Agent. I already refused to treat a Node API miss as a new module registry in Node.js APIs On Is Not the New Module Registry. This post is the same desk rule for a 400 wall. Print the body. Print the named base URL. Name who owns the CLI pin.

The question is not whether chat looks red. The question is whether the named owner can still tell a schema reject from a host that does not answer.

Waiting for Your Input Is Not a Finished Background Agent

Sun, 13 Sep 2026 07:00:00 +0700

Standup hears “the agent is waiting.” Someone pasted a remote or headless screenshot. The line says waiting for your input. The junior treats that as a stop. They close the laptop. They tell the chat the overnight job is done.

I stop the run there. A wait line is not a finished background agent. On a remote or headless host, that sentence used to print while other agents were still running. The work was live. The status lied.

Official notes from 11 September 2026 name the split. Remote and headless sessions reported “waiting for your input” while background agents were still running. Status now reports those tasks as running. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.269] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat a Node API miss as a new module registry in Node.js APIs On Is Not the New Module Registry. I already refused to treat an unreadable managed allow-list as a company lockdown in Treat Unreadable Managed Settings as Empty. This post is the same desk rule for a wait line. Read the agent list. Split Needs input from Working. Name who owns the remote-headless host and the CLI pin.

The question is not whether chat printed a polite pause. The question is whether the named owner can still see the work that is running.

Node.js APIs On Is Not the New Module Registry

Sat, 12 Sep 2026 07:00:00 +0700

Standup hears “Node compat is off.” Someone pasted a red agent log. import.meta.url is undefined. A package that worked on Node 22 throws in wrangler dev. The junior opens the Cloudflare status page. The coding agent offers to “turn Node.js compatibility back on” by rewriting compatibility_flags until chat works.

I stop the run there. A missing import.meta.url is a module-registry ticket until proven otherwise. It is not “Workers turned Node off.”

On 9 September 2026 Cloudflare published the field note that names the split. Node.js APIs that you want in a serverless Worker are already on by default. The new URL-based module registry is a separate compatibility flag named new_module_registry. Official post: that flag does not have a default-on date. It will not turn on from compatibility_date alone. You add it on purpose. [Source: https://blog.cloudflare.com/workers-module-registry-nodejs/]

I already refused to treat a failed Cloudflare login as a status outage in Read the Requested Scopes Before You File an Outage. I already refused to treat an unreadable managed allow-list as a company lockdown in Treat Unreadable Managed Settings as Empty. This post is the same desk rule for Workers flags. Read the list. Split the two switches. Name who owns that list. Do not let the agent flip no_nodejs_compat because a URL API is missing.

The question is not whether Node “works” in chat. The question is which flag the named owner pinned, and whether the coding agent is allowed to touch it.

Treat Unreadable Managed Settings as Empty

Thu, 10 Sep 2026 07:00:00 +0700

Standup hears “the org locked HTTP hooks.” Someone pasted a red agent log. The hook URL that worked yesterday is blocked. The junior opens the vendor status page. The coding agent offers to “relax the allow-list in the project file until chat works.”

I stop the run there. A sudden block on HTTP hooks is a readable-file problem until proven otherwise. It is not “Claude Code locked the company.”

On 9 September 2026 Claude Code published a patch that names three managed allow-list keys. Official notes say managed allowedHttpHookUrls, httpHookAllowedEnvVars, and allowedChannelPlugins now admit nothing, not everything, when those settings are unreadable. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.267] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat an Organization policy why-line as a loaded fleet file in Read the Why-Line Before You Trust the Org Policy. I already refused to treat a failed Cloudflare login as a status outage in Read the Requested Scopes Before You File an Outage. This post is the same desk rule for the managed allow-list. Read the file. Parse the three keys. Name who owns that file. Do not let the agent rewrite policy as a drive-by lint.

The question is not whether the CLI printed a new block. The question is whether the managed file on this machine is readable, and who owns the pin when it is not.

Read the Requested Scopes Before You File an Outage

Wed, 09 Sep 2026 07:00:00 +0700

Standup hears “Cloudflare OAuth is down.” Someone pasted a red terminal. cf auth login died. The junior opens the status page. The coding agent offers to “switch providers until login works.”

I stop the run there. A failed login is a requested-scope list. It is not a status incident.

On 7 September 2026 Cloudflare published a patch for @cloudflare/workers-auth. The notes are blunt: cf auth login asked for email_routing:read and email_sending:read. The Cloudflare OAuth server does not define those names. Login failed with an unknown OAuth scope error. The CLI now requests only the registered write scopes for those products. [Source: https://github.com/cloudflare/workers-sdk/releases/tag/%40cloudflare/workers-auth%400.6.9]

I already refused to treat an Organization policy why-line as a loaded fleet file in Read the Why-Line Before You Trust the Org Policy. I already refused to treat a green apt update as a trusted key in A Green apt Update Is Not a Trusted Key After Saturday. This post is the login version of the same desk rule. Read the scope the client asked for. Check whether the server registered it. Name who owns the CLI pin. Do not page an outage for a catalog mismatch.

The question is not whether Cloudflare’s dashboard loaded this morning. The question is whether the binary on this laptop asked the OAuth server for a name that server has never heard.

Read the Why-Line Before You Trust the Org Policy

Tue, 08 Sep 2026 07:00:00 +0700

Standup hears “org policy is on.” Someone pasted a screenshot of /status. There is a line that says Organization policy. The junior treats that line as a green light and keeps prompting.

I stop the run there. A line that explains a miss is not a loaded policy. A proxy that drops the settings endpoint will still print a reason. The reason is useful. The reason is not enforcement.

On 4 September 2026 Claude Code added an Organization policy line to /status and claude doctor. Official notes say the line reports why the organization’s policy could not be loaded, for example a proxy not passing the endpoint through. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.261] [Source: https://code.claude.com/docs/en/changelog]

I already refused to treat a deferred group name as a PHP helper in A Deferred Group Name Is Not a Helper. I already refused to treat a missing Issues tab as a missing ticket in An Issues Tab Is Not a Laravel Package Ticket. This post is the same desk rule for fleet policy. Read the why-line. Name who owns the proxy and the allow-list. Do not resume a coding agent until that owner answers.

The question is not whether the CLI printed a new label. The question is whether the machine you are about to trust actually loaded the policy your admin thinks is in force.

A Deferred Group Name Is Not a Helper

Mon, 07 Sep 2026 07:00:00 +0700

The dashboard is green in the browser. Users load. Roles load. The Vue Deferred fallback flips to the user card. The feature test is red. Standup hears “Inertia dropped the auth group.”

I stop the run there. A deferred group named auth is a request batch. It is not the Laravel auth() helper. A red loadDeferredProps('auth') line this week is not a missing Vue prop.

On 4 September 2026 the Laravel adapter for Inertia published a testing-helper fix: loadDeferredProps() crashed when the group string matched a global PHP function. The Vue npm client did not move. [Source: https://github.com/inertiajs/inertia-laravel/releases/tag/v3.3.3] [Source: https://github.com/inertiajs/inertia-laravel/pull/908]

I already refused to treat a missing Issues tab as a missing ticket in An Issues Tab Is Not a Laravel Package Ticket. I already refused to treat a green apt line as a trusted key in A Green apt Update Is Not a Trusted Key After Saturday. This post is the deferred-props version of the same desk rule. Name the group. Name whether it collides with a PHP helper. Name who owns that string before a coding agent copies auth from the controller into the test.

The question is not whether the Vue client bumped. The question is whether your next feature test treats a batch name as a callback.

An Issues Tab Is Not a Laravel Package Ticket

Sun, 06 Sep 2026 07:00:00 +0700

The junior opens laravel/socialite and looks for the Issues tab. GitHub has nothing to click. Standup hears “we cannot file the OAuth bug.” The coding agent offers to post in Discord instead.

I stop the run there. A missing Issues tab is not a missing ticket. On most Laravel packages this week, the ticket is a pull request that names the failure. The chat thread is gossip.

Taylor Otwell wrote the rule in public on 3 September 2026: last week he disabled GitHub Issues on most Laravel open-source packages. If you hit a bug, describe it to a coding agent and open a PR. Even if the code is not great, iterate. The PR still documents the problem. Laravel News restated it on 4 September: this is for packages, not the main Laravel repo. [Source: https://x.com/taylorotwell/status/2095516796748996843] [Source: https://laravel-news.com/taylor-disabled-github-issues]

I already refused to treat a green apt line as a trusted key in A Green apt Update Is Not a Trusted Key After Saturday. I already refused to treat one Copilot exclusion list as every surface in Name the Copilot Surface Before You Trust the Exclusion List. This post is the contribution-path version of the same desk rule. Name the repo. Name whether Issues are on. Name who owns the PR that documents the bug.

The question is not whether Taylor is “right about open source.” The question is whether your next Socialite failure becomes a fork, a Discord ping, or a PR a maintainer can review.

A Green apt Update Is Not a Trusted Key After Saturday

Sat, 05 Sep 2026 07:00:00 +0700

The CI job is green. Last night apt-get update returned zero. The runner still has gh. Standup hears “Linux packages are fine.”

I stop the run there. A green last update is a timestamp. It is not a trusted key.

Today is Saturday, 5 September 2026. GitHub’s changelog is blunt: the current PGP key for the GitHub CLI Linux package repositories expires on this date. Beginning with the first release after that date, APT and RPM repository metadata and newly published RPM packages will be signed with just the replacement key. [Source: https://github.blog/changelog/2026-09-03-github-cli-linux-package-signing-key-expires-september-5/]

If this box installed gh from the official APT or RPM repos before 8 April 2026 and nobody reran the setup, the local keyring is still the old file. Last night’s green apt update only proves the old key was still alive at that hour. It does not prove the replacement key is on disk.

I already refused to treat a Copilot overview as a merge vote in Leave Copilot Approve Off. I already refused to treat one exclusion list as every Copilot surface in Name the Copilot Surface Before You Trust the Exclusion List. This post is the package-trust version of the same desk rule. Name who owns the keyring on the image. Name which install path you used. Do not treat a green apt line as recovered trust.

The question is not whether GitHub published a new key in April. The question is whether the Dockerfile that still copies last year’s githubcli-archive-keyring.gpg will survive the first apt-get update after the old key dies.

Name the Copilot Surface Before You Trust the Exclusion List

Fri, 04 Sep 2026 07:00:00 +0700

A junior opens .env, sees no ghost text, and closes the laptop. The exclusion list is in repository settings. Inline suggestions stayed quiet. Standup hears “secrets are off Copilot.”

I stop the run there. Quiet inline is one surface. It is not every surface.

On 2 September 2026 GitHub made content exclusion generally available in the Copilot app and Copilot CLI for Copilot Business and Copilot Enterprise. Those two products now skip excluded files as context. The same week, GitHub’s own docs still say Edit mode and Agent mode in Copilot Chat do not support content exclusion. [Source: https://github.blog/changelog/2026-09-02-content-exclusions-generally-available-in-copilot-app-and-cli/] [Source: https://docs.github.com/en/copilot/concepts/context/content-exclusion]

The list is real. The gap is also real. A policy row in settings is not a recovered secret.

I already left Copilot’s ready-to-approve line as a comment, not a vote, in Leave Copilot Approve Off. I already kept Merge on a named human in I Do Not Give a Coding Agent Merge Rights. This post is the file-boundary version of the same desk rule. Name who owns the exclusion list. Name which Copilot surface you tested. Do not treat one green check as the whole product.

The question is not whether GitHub added a settings page. The question is whether the path you care about still reaches Agent chat when a person is tired.

Leave Copilot Approve Off

Thu, 03 Sep 2026 07:00:00 +0700

The pull request is green. Copilot already reviewed it. The overview comment says the change is ready to approve. A junior on the desk reads that line as the missing vote.

I stop the run there. Ready-to-approve is Copilot’s judgment in a comment. It is not a required approval. It is not Merge.

GitHub shipped this as public preview on 1 September 2026. Every Copilot code review now includes an approval assessment in the overview comment. Admins can later authorize Copilot to submit a real approval that counts toward the repository’s required-approvals rule. That ability is off by default at enterprise, organization, and repository level. An assessment alone does not count toward merge requirements. [Source: https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/]

I already refused agent merge in I Do Not Give a Coding Agent Merge Rights. This post is the review-line that landed after that refusal. The agent still opens the branch. Copilot still comments. A named human still owns required approvals and the Merge click.

The question is not whether Copilot writes a fluent review. The question is whether the team treats that fluency as a vote on the branch we deploy.

Five Things I Refused This Week

Sun, 30 Aug 2026 07:00:00 +0700

The agent opened the pull request on Friday. Saturday morning nobody could name the model. The merge button still had no owner. The retry after abort sat in a chat log.

I did not ship a new tool this week. I refused five things. Rank them. Screenshot the list. Put the names on the ticket before Monday.

The question is not whether the agent demos well. The question is whether the change survives review, merge, retry, and the next person who has to roll it back.

I Do Not Let a Coding Agent Pick Its Own Model

Sat, 29 Aug 2026 07:00:00 +0700

The session is already running. The agent opened a pull request, wrote a confident summary, and asked for review. Nobody on the ticket can say which model produced the diff.

That is the moment I stop the run. The agent may write the branch. The agent may open the pull request. The agent does not choose the model for that work. A named human writes the model on the ticket before the first prompt.

Yesterday I wrote the merge click. Merge stays with a person. Today’s refusal is one gate earlier: the model that authors the change, and the model that reviews it, are human picks. Auto is a vendor default. It is not a name.

I Do Not Give a Coding Agent Merge Rights

Fri, 28 Aug 2026 07:00:00 +0700

The pull request is green. The agent asked for review. Someone is in a standup and enables agent merge so the branch can land while they talk.

That is the moment I stop the run. The agent may write the branch. The agent may push commits. The agent may request review. The merge button stays with a named human.

GitHub already treats Copilot pull requests as work that needs a human pass. The docs say to check the diff thoroughly before merging, and if the repository requires approvals, your approval of a Copilot pull request does not count toward that number. Another reviewer has to approve. [Source: https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/review-copilot-output]

I use that as policy, not as a product footnote. The question is not whether the agent can land the PR. The question is whether a person with a name still owns the click when the deploy path is Laravel, Vue, and a Monday morning database.

I Do Not Add a Second Chart Stack Mid-Sprint

Thu, 27 Aug 2026 07:00:00 +0700

The chart PR is green. The screenshot on the happy path looks fine. Then someone adds a second chart library “just for one widget.”

That is not a visualization improvement. That is two tooltips, two dark-mode contracts, two SSR hydrate paths, and two rollback stories living in the same admin shell. I refuse that merge until two names exist on the ticket: the person who owns revert, and the fixture that fails when the chart lies.

This week’s ApexCharts default-bundle shrink is evidence that the stack you already have still moves. It is not a reason to install Apache ECharts beside it before Friday.

The question is not whether the extra widget demos well. The question is whether it survives maintenance, handoff, and the three dashboard screens your operators open every Monday.

Empty Tool Output Is Not Success Until the Harness Says Interrupted

Wed, 26 Aug 2026 07:00:00 +0700

The cron row is green. The JSONL says the MCP tool finished. The stdout field is empty.

That is the most expensive sentence a headless coding agent can write. The next step is invented. The PR lands. The Laravel worker image still talks to last week’s schema. Nobody owns the rollback because the transcript never recorded a failure.

Anthropic’s Claude Code notes for 25 August 2026 (tag v2.1.246, published 2026-08-25T22:31:43Z) name the lie in one line: MCP tool calls interrupted by an incoming message in headless and remote sessions were reported to the model as “completed with no output” instead of an explicit interrupted error. [Source: https://github.com/anthropics/claude-code/releases/tag/v2.1.246]

The question is not whether a new tag demos well. It is whether your harness still treats empty completion as a close.

Your Coding Agent Needs a Map, Not a Bigger Context Window — Part 2

Fri, 21 Aug 2026 07:00:00 +0700

The agent grepped the whole Laravel app, opened a sibling Vue folder, and “fixed” shipping in a helper nobody called from the failing test. The PR looked busy. The bug was still in app/Services/ShippingCost.php.

That is the failure I now refuse. A bigger context window does not make a coding agent safer. It makes the wrong search cheaper. The map file is the allow-list. I do not let the agent search the whole tree. Paths outside the map fail the job.

The question is not whether this demos well. The question is whether it survives the next review, the next handoff, and the person who has to revert the branch.

Hermes Agent Multi-Agent Orchestration: How Cron Pipelines Delegate, Verify, and Recover

Sun, 16 Aug 2026 07:00:00 +0700

You schedule the cron. The agent runs. Exit code 0. Green dashboard. Nothing actually shipped.

I’ve watched this pattern repeat across dozens of production pipelines. The process exits cleanly. The heartbeat ticks. The monitoring shows healthy. But the artifact — the file, the row, the URL, the test log — never materialized. This is the zombie task problem, and it’s the central failure mode of autonomous AI agent pipelines.

Building a Background Agent Recovery CLI: The Three-Gate Check

Fri, 14 Aug 2026 07:00:00 +0700

The overnight coding agent wrote “Done.” The chat was green. The shipping cost file on disk was still yesterday’s version.

I do not mark that run recovered. Recovered means three things I can show a junior without opening the vendor UI: a file that exists, a job log that names why the process stopped, and one restart from the last good commit that is allowed to fail once.

The question is not whether the agent demos well. The question is whether the next person can restart the job from a known commit when I am offline.

Parallel AI Agents on a Shared Checkout — The Lease Contract You Need

Thu, 06 Aug 2026 07:00:00 +0700

Two agents. One checkout. No lease. The merge race starts the moment the second agent writes.

Your team adopts Claude Code for the backend, Codex for the frontend, and a Hermes subagent for the migration script. They all target main. The first agent creates a feature branch, stages changes, commits. The second agent, unaware, checks out the same branch, stages its own changes, commits. The third agent runs a rebase. The result: orphan commits, staging pollution, a force-push that rewrites history, and three hours of forensic git archaeology to recover what was lost. This is not a hypothetical. GeekNews has documented parallel agent failure patterns including branch hijacking, orphan commits, staging pollution, and double implementation [Source: https://news.hada.io/topic?id=26120].

A Green Cron Exit Is Not a Finished Job

Sun, 02 Aug 2026 07:00:00 +0700

Your nightly embedding pipeline exits 0. The logs show INFO Job completed. The monitoring dashboard stays green. Three days later you discover the vector index hasn’t been updated since Tuesday — the agent skipped the upsert because the upstream API returned 429, caught the exception, logged a warning, and returned success. The cron scheduler sees exit 0 and marks the run healthy. This is not a bug. This is the default behavior of every cron implementation since 1979 (Version 7 Unix).

A table beta bump is still a pilot decision

Sat, 01 Aug 2026 07:00:00 +0700

The release note says the table got smarter about global filters.

TanStack Table v9.0.0-beta.64, published 2026-07-31, includes one core fix that sounds small enough to merge while someone else is talking: table-core honors an explicit global-filter opt-in (#6439). Packages on that tag include @tanstack/table-core@9.0.0-beta.64 and @tanstack/vue-table@9.0.0-beta.64. [Source: https://github.com/TanStack/table/releases/tag/v9.0.0-beta.64]

That line is useful. It is not a production decision.

On the same calendar day, npm dist-tags for both @tanstack/table-core and @tanstack/vue-table still showed:

dist-tag	Version (verified 2026-08-01)
`latest`	8.21.3
`beta`	9.0.0-beta.65 (already past `.64`)

[Source: https://registry.npmjs.org/@tanstack/table-core] [Source: https://registry.npmjs.org/@tanstack/vue-table]

Read that table twice. Stable is still 8.21.3. The beta channel did not freeze on the opt-in fix you just bookmarked. beta.65 landed minutes later with another global-filter fix (undefined first values). If your spike branch says “install beta” without an exact pin, you are not testing the release note you read. You are testing whichever beta the registry served that hour.

The question is not whether beta.64 demos cleanly in a fresh sandbox. The question is whether a multi-surface admin table — filters, sort, pagination, selection, SSR hydrate, worker parity — still has a named owner, a fixture that would fail if opt-in is ignored, and a one-command rollback when the pilot goes sideways.

A UI kit lockfile bump is change control, not cosmetics

Fri, 31 Jul 2026 07:00:00 +0700

A quiet package.json bump can still be a release.

shadcn-vue 2.8.1 shipped on 2026-07-29. npm latest points at 2.8.1. The GitHub release is not a major redesign and does not advertise a Reka primitive rewrite. It adds registry entries, tightens CLI icon mapping, ships shimmer and scroll-fade utilities, preserves a message-scroller scrollbar gutter, improves Tailwind icon-selector extraction, and applies style-aware classes to number-field inputs. That is exactly the kind of patch teams merge while talking about something else. [Source: https://github.com/unovue/shadcn-vue/releases/tag/v2.8.1] [Source: https://www.npmjs.com/package/shadcn-vue]

The failure mode is not “the patch is evil.” The failure mode is calling cosmetics what is actually generated surface area: registry pull paths, icon maps, chat UI chrome, form field styling, and CSS extraction. If your product has an admin shell, a support chat pane, or dense numeric forms, those surfaces break before the marketing page does.

The question is not whether the bump demos cleanly in a fresh sandbox. The question is whether it survives maintenance, handoff, and the three screens your operators open every Monday.

PHP 8.5.9 is a runtime patch contract, not an app deploy

Thu, 30 Jul 2026 07:00:00 +0700

A green application deploy is a weak answer to a PHP security release.

PHP 8.5.9 is already visible as source truth: the php-8.5.9 NEWS entry is dated 30 Jul 2026, the distribution tarball at https://www.php.net/distributions/php-8.5.9.tar.gz returns HTTP 200, and the PGSQL section records a fix for GHSA-7qpv-r5mr-78m4 — SQL injection via E'...' backslash breakout, tracked as CVE-2026-17543. At the same time, the public php.net releases JSON endpoint still presents 8.5.8 (02 Jul 2026) as the current 8.x announcement row, and the main ChangeLog page has not yet absorbed 8.5.9. That lag is not a reason to ignore the patch. It is a reason to treat the release as a runtime inventory problem instead of an “npm-style bump” you fold into the next app ship. [Source: https://raw.githubusercontent.com/php/php-src/php-8.5.9/NEWS] [Source: https://www.php.net/releases/index.php?json]

If your product is a Laravel app on pgsql, the vulnerable surface is not “some controller you forgot to review.” It is the PHP binary that still accepts traffic, runs queue workers, executes scheduled commands, and builds CI images. The question is not whether the changelog demos cleanly. The question is whether the fix survives handoff across every surface that still claims to be production.

ApexCharts 6.6 unit and waffle charts are a product decision, not a type swap

Wed, 29 Jul 2026 07:00:00 +0700

A new chart type looks like a one-line config change. In a SaaS dashboard, it is rarely that small.

ApexCharts 6.6.0, published on 2026-07-27, introduces the first premium chart type in the library: unit, with waffle as a thin alias. The release is explicit that the feature renders in trial mode with an APEXCHARTS watermark until a license key is set, that other chart types stay free and unwatermarked, and that existing configs render unchanged. Those three sentences already change the maintenance conversation. You are no longer choosing between pie and donut. You are choosing whether a paid, watermarked, opt-in visualization path belongs in a product surface that support, sales, and compliance will see.

The question is not whether the demo looks clever. The question is whether the change survives license review, handoff, SSR, accessibility checks, and a clean rollback when the new type is the wrong fit.

The Schema Change an AI Coding Agent Cannot Safely Guess

Tue, 28 Jul 2026 07:00:00 +0700

An AI coding agent can open your repository, invent a migration class, rename a column in three models, and produce a green local test suite before lunch. That speed is useful. It is also the trap.

The dangerous output is not a broken SQL statement. The dangerous output is a tidy schema change that looks complete because php artisan migrate succeeded on a developer laptop. Production still has old queue workers, dual readers, partially backfilled rows, cached Eloquent attributes, and a rollback path that only exists as a chat transcript. The model guessed a destination schema. It did not own the compatibility contract that keeps live traffic safe while both shapes exist.

The question is not whether the agent demos well. The question is whether the change survives maintenance, handoff, and local constraints. If nobody can answer “what still works while old and new code run together,” the migration is not ready to merge.

The Rollback Path Is the Real AI Coding Feature

Sat, 25 Jul 2026 07:00:00 +0700

The most dangerous AI-generated change is not the obviously bad one. It is the tidy diff that passes a happy-path test, reaches staging, and leaves nobody able to answer one operational question: how do we get back?

A model can produce a controller, a migration, a queue handler, and a deployment file in minutes. That does not make the combined change reversible. The question is not whether this demos well; it is whether it survives maintenance, handoff, and local constraints. If the answer depends on someone remembering a chat transcript or improvising SQL during an incident, the change was not ready to merge.

This is a backend and infrastructure discipline, not an anti-AI argument. AI coding is useful when it reduces the cost of drafting a bounded implementation. It becomes risky when the speed of drafting hides the fact that a change crosses several recovery boundaries at once: application behavior, schema shape, data backfill, asynchronous work, configuration, and deployment.

Audit the resume boundary: verify a coding agent from repository evidence

Thu, 23 Jul 2026 07:00:00 +0700

A transcript tells you what an agent said it did. A repository tells you what it left behind.

That difference matters when a coding-agent session ends at an inconvenient point: the terminal disconnects, a context window closes, a machine reboots, a CI command hangs, or someone simply returns the next day. The tempting move is to resume and ask, “Where were we?” That question invites a narrative. It does not establish a safe starting point.

Vue Query Cache Invalidation Is a Contract, Not a Refetch Button

Wed, 22 Jul 2026 07:00:00 +0700

A save can return 200 OK, the detail view can show the new value, and the list that brought the operator there can still show yesterday’s row. That is not a cosmetic bug. In an admin screen, the list is often the operational truth: who is assigned, which invoice is overdue, whether an account is active, or which queue needs attention.

The usual response is to add a refetch button. That hides the decision that caused the stale screen: nobody owns the relationship between a mutation and the query keys it changes. The question is not whether this demos well; it is whether it survives maintenance, handoff, and local constraints.

TanStack Query already gives us the primitives: query keys, invalidation, mutation callbacks, optimistic updates, cancellation, snapshots, and hydration. Its documentation describes invalidation as marking matching queries stale and refetching active observers; mutation callbacks are where teams connect a completed write to that work. Source: TanStack Query invalidation guide Source: mutations guide

The hard part is not calling an API. It is writing a contract that says which cached facts a write invalidates, which screen owns the policy, what gets restored after failure, and how server-rendered state joins the browser cache. This is a practical companion to the maintenance boundaries in Laravel + Vue SaaS and the verification habits collected in Developer Tools.

ApexCharts 6.4 Is a Dashboard Contract Migration, Not a Package Bump

Tue, 21 Jul 2026 07:00:00 +0700

A charting dependency can change a dashboard without changing a single API endpoint. That is the uncomfortable part of an ApexCharts 6.4 upgrade.

The release was published on 2026-07-20, and it changes the rules that turn a heatmap data point into pixels, interaction, and labels. It also introduces an opt-in Canvas renderer with its own import requirement and fallback behavior. Those are dashboard contracts: visible agreements between your data, your configuration, and the people who use the screen. The v6.4.0 release notes are the source for those changes.

Git trailers turn a commit into a handoff contract

Mon, 20 Jul 2026 07:00:00 +0700

A commit already records code and a message. For a team that hands work between people, time zones, and automated checks, that is often not enough. Someone needs to know what changed, what verified it, where the review discussion lives, and whether there is a follow-up that should not vanish into a chat thread.

AI Agent Frameworks in 2026 — What the Comparison Charts Don't Tell You

Sun, 19 Jul 2026 07:00:00 +0700

The comparison chart is already lying to you the moment it asks which agent framework is “best.” It turns an operational decision into a shopping decision: features in rows, names in columns, and a tidy winner at the bottom.

Treat frontend file watching as a maintenance contract

Sat, 18 Jul 2026 07:00:00 +0700

A dev server that misses filesystem events is not a frontend nuisance. It is an unreliable feedback loop.

The visible symptom looks small: a component changes on disk and the browser does not update. The operational cost is larger. A developer edits again, refreshes manually, restarts the server, doubts the CSS, then doubts the build. The system has stopped giving a trustworthy answer to a simple question: “did the change I made reach the page I am looking at?”

A Coding-Agent Policy Is Change Control, Not a Settings File

Fri, 17 Jul 2026 07:00:00 +0700

A repository instruction file is easy to underestimate. It looks like a convenient place to put a test command, a style preference, and a warning about migrations. That framing is wrong once a coding agent can open pull requests, change schemas, edit infrastructure, or run commands on behalf of a team.

Laravel Image Processing Is an Adoption Contract, Not an Upload Feature

Thu, 16 Jul 2026 07:00:00 +0700

A file input and Storage::putFile() can make image work look finished. The browser accepts a JPEG, the application stores it, and a page renders something back. That is a demo.

The production question is different: what does the rest of the application get to rely on after an image arrives?

The Request Boundary Is Your Compatibility Contract

Wed, 15 Jul 2026 07:00:00 +0700

A request is not a bag of values that happens to arrive at a controller. It is a compatibility promise between at least four pieces of software: the browser that sends intent, the Laravel code that interprets it, any queued work that outlives the HTTP request, and the client code that consumes the next response.

A Small Diff Is Not a Small Change: Review AI Patches by Code Entity

Tue, 14 Jul 2026 07:00:00 +0700

A coding agent changes seven lines in a validator. The pull request looks safe. The reviewer sees a small diff, a green test run, and a tidy commit message.

But the validator feeds a controller, the controller builds a queue payload, and a fixture still describes the old rejection shape. The diff is seven lines. The behavior boundary is not.

That is the review mistake I see most often with AI-assisted changes: treating line count as a proxy for change size. A diff is an excellent record of text edits. It is not automatically a map of the functions, classes, callers, tests, and rollback points that now have a different contract. The question is not whether this demos well; it is whether it survives maintenance, handoff, and local constraints.

Strict TypeScript Is a Migration Contract, Not a Compiler Nuisance

Mon, 13 Jul 2026 07:00:00 +0700

A UI utility upgrade rejects undefined. The pull request looks harmless: replace a few object literals, widen a type, move on. Then the same error appears in a prop adapter, an API mapper, a saved-filter serializer, and a test fixture. The compiler is not being difficult. It found an ownership decision that the codebase never wrote down.

That is why strict TypeScript work deserves a migration plan. exactOptionalPropertyTypes draws a real line between a property that is absent and a property that is present with undefined. The question is not whether an editor can silence the error. The question is which layer owns the meaning of absence, default, and invalid input. The question is not whether this demos well; it is whether it survives maintenance, handoff, and local constraints.

Vue 3.6 Vapor Mode: Build a Pilot Harness Before You Change a Rendering Path

Sat, 11 Jul 2026 07:00:00 +0700

Vue 3.6 Vapor Mode is worth watching for a practical reason: it gives a mature Vue application a compiler-oriented rendering path to evaluate without committing the whole product to a rewrite. That is a useful option for teams with a real performance complaint, an established test suite, and enough operational discipline to compare a change against a baseline.

Grok 4.5 Is a Coding-Agent Moment Only If It Survives the Harness

Fri, 10 Jul 2026 07:00:00 +0700

Grok 4.5 is available through the xAI API for coding, agentic tasks, and knowledge work. Before moving coding-agent work to a new frontier model, verify behavior against your own repos, tools, budgets, and rollback needs.

Wrangler Now Treats AI-Agent Static Deploys Differently: Verify the Target, Not Just Success

Thu, 09 Jul 2026 07:00:00 +0700

A deploy command can exit zero and still leave you looking in the wrong product.

That is the interesting part of Wrangler 4.108.0. Cloudflare did not ship a loud “AI deployment platform” announcement. It shipped a small release-note line with a large operational consequence: when wrangler pages deploy or wrangler pages project create is run by an AI coding agent against a brand-new, purely static project, Wrangler can delegate that deploy to Workers static assets instead of Cloudflare Pages. The question is not whether this demos well; it is whether your deployment contract survives maintenance, handoff, and local constraints.

TanStack Table v9 Row-Model Workers: What Breaks When Your Grid Crosses postMessage?

Wed, 08 Jul 2026 07:00:00 +0700

TanStack Table v9 beta did something that looks small in a changelog and large in a production grid: v9.0.0-beta.33 added web workers for row models. Less than two days later, v9.0.0-beta.34, beta.35, and beta.36 followed with sorting optimizations, sticky pinned-column documentation, cell-order performance work, touch-cancel cleanup, and extra tests. [Source: https://github.com/TanStack/table/releases/tag/v9.0.0-beta.33] [Source: https://github.com/TanStack/table/releases/tag/v9.0.0-beta.34] [Source: https://github.com/TanStack/table/releases/tag/v9.0.0-beta.35] [Source: https://github.com/TanStack/table/releases/tag/v9.0.0-beta.36]

That sequence is the signal. Workerized row models are not a speed button. They are a boundary change. The moment a table’s row pipeline crosses postMessage, your migration moves from “upgrade a package” to “prove serialization, determinism, adapter behavior, SSR fallback, and rollback.” The question is not whether the demo scrolls smoothly; it is whether the grid survives maintenance, handoff, and local constraints after the first bug report.

A Repeatable Review Harness for AI-Generated Code After the First Merge Gate

Tue, 07 Jul 2026 07:00:00 +0700

The first merge gate is where teams feel safe too early.

An AI agent opens a pull request. The code compiles. The unit tests pass. A human reviewer scans the diff, asks for two naming changes, and merges. Everyone moves on because the gate did its job.

Then the slower problems start. The new route bypasses an old authorization check. A background job retries forever because the agent copied the wrong timeout pattern. The test passes because it asserts a mocked response, not the real boundary. The rollback plan is missing because the change looked small. Three weeks later, another agent edits the same area and treats that weak pattern as local convention.

That is the part I care about. The question is not whether AI-generated code can pass review. The question is whether it survives maintenance, handoff, production rollback, and the next agent that touches it. Working as a software architect in Indonesia makes this practical rather than theoretical: vendor callbacks, deployment windows, and handoff notes decide whether a change survives the week.

This post is about the harness I want after the first merge gate: a repeatable, boring, evidence-heavy review loop for AI-generated code. Not another proof checklist. The proof checklist belongs before merge. This one runs after the first gate and keeps running while the code becomes part of the system.

Developer Tools and Model Choices

Mon, 06 Jul 2026 21:52:00 +0700

Developer tools are not neutral. They shape review habits, cost structure, portability, and how quickly a small team can recover when a workflow breaks.

This hub collects the posts where the question is not “is the tool impressive?” but “what does this tool make easier or harder to operate?”

Laravel and Vue SaaS Notes

Mon, 06 Jul 2026 21:51:00 +0700

This is the engineering lens I use when writing about Laravel, Vue, cron jobs, and small SaaS systems.

The public posts are not framework tutorials in isolation. They are notes about the seams that usually break in real products: scheduled jobs, generated files, state ownership, UI correctness, upgrade paths, and rollback discipline.

AI Agent Operations

Mon, 06 Jul 2026 21:50:00 +0700

AI agents are useful when they become part of operations, not when they only produce impressive transcripts.

This hub collects the posts on agent boundaries, cron verification, repository maps, model portability, and artifact proof. Read these as a working system: each article answers one failure mode in the same operating loop.

Uses

Mon, 06 Jul 2026 21:06:00 +0700

This page documents the working setup behind zemna.net. It is not a sponsored tool list. It is the stack I use, test, or write about.

Writing and publishing

Area	Current choice
Site generator	Hugo extended
Hosting	Cloudflare Pages
Domain	zemna.net
Source control	GitHub
Writing format	Markdown with Hugo frontmatter
Public feed	RSS and JSON feed
Design system	Token-driven custom Hugo theme

The site is intentionally static. Static pages keep the operational surface small: no database, no login, no server runtime, and fewer moving parts to debug.

Start Here

Mon, 06 Jul 2026 21:05:00 +0700

zemna.net is not a news feed. It is a working notebook for software systems that need to survive real maintenance.

If you are new here, read these paths in order.

1. Agent boundaries

Start with the contract before the agent touches a repository.

Zero-Cost Observability for Agent Crons

Mon, 06 Jul 2026 07:00:00 +0700

A cron job that says success can still leave no customer email sent, no blog post published, no report attached, and no safe way back. AI-assisted development makes that failure mode sharper: the agent often completes the instruction it was given, while the system around it has no proof that the work is usable.

The fix is not a larger dashboard on day one. Before adding another paid automation layer, prove three things on the smallest possible surface: one artifact, one alert, and one rollback path. The question is not whether this demos well; it is whether it survives maintenance, handoff, and local constraints.

This post is for solo maintainers and small teams running AI agents, cron jobs, Laravel/Vue SaaS flows, content pipelines, and internal scripts that already have enough moving parts. The goal is zero-cost observability first: local files, structured logs, a shell verifier, GitHub Actions, and free developer or usage-based free tiers only when they earn their place.

Closed Loop Beats More Automation

Sun, 05 Jul 2026 07:00:00 +0700

A broken automation system is easy to recognize when it crashes. The dangerous one exits cleanly, posts a green check, and teaches you nothing. That is the failure mode I keep seeing in agent workflows, content pipelines, scheduled jobs, and developer tooling: the work runs, the logs look polite, and the system forgets to learn from the thing that just happened.

The Agent Edit Contract I Use Before a Coding Agent Touches a Repo

Sat, 04 Jul 2026 07:00:00 +0700

A coding agent should not get write access just because the prompt sounds clear.

The prompt is the weakest part of the workflow. It is conversational, lossy, and too easy to expand while nobody is watching. The contract has to sit outside the chat: a short file that says what the agent may inspect, what it may change, what command proves the change, what artifact must exist, and how to roll back if the run gets clever in the wrong direction.

Your Coding Agent Needs a Map, Not a Bigger Context Window

Fri, 03 Jul 2026 07:00:00 +0700

A coding agent with a very large context window can still make the wrong change in the wrong file.

That sounds harsh until you watch the failure happen. The agent reads half the repository, quotes three irrelevant modules back at you, edits the visible function, and misses the caller that actually owns the invariant. The problem was never that the window was too small. The problem was that the agent had no map.

Before You Adopt a Beta Library, Prove the Exit Path

Thu, 02 Jul 2026 07:00:00 +0700

A beta dependency feels safe right up to the moment it becomes load-bearing.

The release note looks small: one adapter added, one selection bug fixed, one worker event improved, one alpha runtime tagged. You pin it in a branch, the demo works, and the pull request starts to look boring. That is the dangerous part. Boring demos hide the work that matters: how to reverse the change, how to prove the migration surface, how to stop a beta from leaking into production by accident, and how to keep the team honest after the first successful run.

Code That Renders Is Not Code You Can Trust

Wed, 01 Jul 2026 07:00:00 +0700

A developer asks an AI agent to build a settings modal. Thirty seconds later, there is a modal on screen. It opens when you click a button. It closes when you click the backdrop. It looks clean. The developer merges the pull request.

Your Cron Job Is Not Healthy Until the Artifact Proves It

Tue, 30 Jun 2026 07:00:00 +0700

Your cron job exited zero. Fine. Where is the artifact?

That is the question I want on every scheduled job review now. Not “did the process run?” Not “did the dashboard stay green?” Not “did the log avoid a stack trace?” A scheduled job is healthy only when the expected artifact exists, is fresh, and passes a domain check. Anything weaker is process theater.

Open Weights Just Ate the API Margin — What a Pragmatic Dev Actually Does on Monday

Mon, 29 Jun 2026 07:00:00 +0700

If you’ve been shipping LLM-powered features for the last two years, you’ve felt it: the API bill that started as a rounding error and is now a line item your CFO asks about in weekly meetings. The model providers built beautiful APIs, priced them per token, and we all built businesses on top of usage-based pricing that only goes in one direction — up.

The 5 Cron Patterns That Lie to You — Exit 0 Doesn't Mean Success

Sun, 28 Jun 2026 07:00:00 +0700

You set up a cron job — let’s say a database backup. It runs every night at 2 AM. The exit code is always 0. The dashboard is green. Six months go by. Then one day you need to restore, and the backup file is 0 bytes. The job never failed. It just never actually worked.

The JavaScript I Deleted With CSS: A 2026 Survival Guide

Sat, 27 Jun 2026 07:00:00 +0700

I deleted 150 lines of JavaScript from a tooltip component last week. The replacement was four lines of CSS. No virtual DOM reconciliation, no requestAnimationFrame loop, no ResizeObserver to handle container changes, no scroll listener for collision detection. The browser does all of it now, natively, on the compositor thread, faster than any framework’s JS ever did. The diff went into the PR with a one-line comment: “CSS does this.”

Why AI Cron Jobs Lie to You: The Exit 0 With Empty Output Pattern

Fri, 26 Jun 2026 07:00:00 +0700

My health check cron ran 180 times over six hours. Exit code 0 every time. Green dashboard. And you never once asked. Neither did I — until I checked the output and found six hours of perfect silence.

I Swapped My LLM Backend — The API Call Worked on the First Try

Thu, 25 Jun 2026 07:00:00 +0700

I Swapped My LLM Backend — The API Call Worked on the First Try

The migration took eleven minutes. The fallout took three weeks. I switched our production agent from GPT-4o to a cheaper model on a Tuesday afternoon, confirmed the health check passed, and pushed it live. The API returned 200. The response body was valid JSON. Everything looked fine. It was not fine. Over the next twenty-one days, I watched our error rate climb 340%, our RAG pipeline silently return garbage, and our “deterministic” eval suite give everything a pass because it was never actually measuring what I thought it was. This post is about what breaks when you swap an LLM mid-project — not the API layer, which is the easy part, but everything built on top of it.

Your AI Agent Pipeline Has No Zombie Detection — Here's How to Add It

Wed, 24 Jun 2026 07:00:00 +0700

I ran an autonomous task system for three months before I realized it had a blind spot the size of a barn door. Processes were “healthy.” CPU was fine. Memory was fine. And yet, nothing was getting done.

The AI Coding Agent Arms Race — Why Model Portability Matters More Than Benchmarks

Tue, 23 Jun 2026 07:00:00 +0700

A coding-agent migration often starts with a model comparison, then fails somewhere much less glamorous: a test command was stored in a chat preset, a deployment warning existed only in one tool’s dashboard, or a local override quietly changed what the agent was allowed to touch.

That is the wrong place to discover the real dependency. The durable asset is not a model setting. It is the repository-owned release policy: which paths are protected, which command verifies a change, who approves an exception, what evidence must survive review, and how the team returns to safety when a tool behaves badly.

The question is not whether a coding agent demos well; it is whether its work survives maintenance, handoff, and local constraints.

Autonomous AI Agents on Cron: A Zombie-Task Postmortem

Sat, 20 Jun 2026 08:00:00 +0700

Two weeks ago I woke up to a green dashboard. Every cron job had fired, every task reported status: completed, every heartbeat was healthy. The content pipeline I run — research, draft, fact-check, design, publish — had apparently done its job overnight while I slept.

Long-Running AI Agents — From Demos to Production

Fri, 19 Jun 2026 07:00:00 +0700

The session was still green. The agent had typed cd backend, kept editing files, and wrote “done” in the log. Nobody on the ticket could say whether the sandbox moved with the working directory.

That is the failure I now refuse. A long-running agent is not production because it stayed up overnight. It is production when the boundary still holds after a directory change, after a nested helper spends tokens, and after a tool result is rewritten before the model sees it.

The question is not whether this demos well. The question is whether it survives maintenance, handoff, and the next person who has to roll the branch back.

OpenCode Dethroned Cursor — and Claude Fable 5 Got Suspended. What June 2026's AI Coding Shakeup Means for You

Thu, 18 Jun 2026 08:00:00 +0700

June 2026 is the month the AI coding agent landscape cracked open. Two stories broke within days of each other, and both have real implications for how you build software.

Story one: OpenCode hit 160,000 GitHub stars and 7.5 million monthly active users, displacing Cursor from the #1 spot in LogRocket’s AI dev tool power rankings. It’s open source, it’s model-agnostic, and it runs in your terminal.

GLM 5.2 Just Became the Best Open-Weights Model — Here's What That Means

Wed, 17 Jun 2026 18:28:00 +0700

Zhipu AI (Z.AI) dropped GLM 5.2 on June 13, 2026, and it didn’t just raise the bar for open-weights models — it grabbed the bar and threw it across the room. With a 744B Mixture-of-Experts architecture, a usable 1-million-token context window, and an MIT license, this is the strongest argument yet that you don’t need a closed API to run frontier-level AI.

How I Dissected 54 Design Systems and Transplanted Linear.app DNA Into My Hugo Blog in One Day

Tue, 16 Jun 2026 18:00:00 +0700

This morning I opened my blog and thought: this looks like a 2015 Tistory template. So I told my Hermes agent, in exactly these words: “This looks like garbage. Go through all 54 design systems and rebuild it with the best one.”

Colophon

Tue, 16 Jun 2026 00:00:00 +0000

Colophon

This page documents the how of zemnanet — what the site is built with, what tools run it, and why those choices were made.

Stack

Layer	Tool	Why
Site generator	Hugo v0.140 extended	Go single binary, sub-second builds, no Node toolchain
Hosting	Cloudflare Pages	Free, global CDN, zemna.net already on Cloudflare
Domain	zemna.net on Cloudflare Registrar	Same provider, no extra DNS hops
Content	Markdown + Hugo frontmatter	Plain text, version-controlled, AI-friendly
Versioning	Git on GitHub	Public history, no vendor lock-in
Deployment	git push to `main` → Cloudflare Pages build	Zero-config CI; the only “ops” is git
Search	Pagefind (planned)	Static index, runs at build time, no JS framework

Typography

Inter for UI, navigation, and English headlines — open source, broad weight range, readable at small sizes.
Noto Serif KR for Korean editorial content — open source, designed for the Korean script.
JetBrains Mono for code — ligatures for => and !=, tabular numerals.

Colors

Three brand colors, derived from a synthesis of Korean hanji (off-white) and Indonesian batik (navy + vermilion). Full palette and semantic mappings live in the design system.

Design System

Tue, 16 Jun 2026 00:00:00 +0000

zemnanet Design System

A single source of truth for the visual and typographic language used across:

zemna.net (this website)
Blog posts and series
Social media graphics (IG carousels, X headers, podcast covers)
Any presentation, README, or tool that says “zemnanet” on it

The system is token-first — every visual decision is a named token. No hard-coded values in templates. No drift between surfaces.

The quiet consolidation in Korean dev tooling

Tue, 16 Jun 2026 00:00:00 +0000

The Korean developer-tools market has historically been fragmented. Dozens of small teams shipping one thing well, each with its own API, its own auth model, its own quirks. That era is ending.

In the last twelve months, three acquisitions have reshaped the landscape:

Stop reaching for a state library

Mon, 15 Jun 2026 00:00:00 +0000

Every JavaScript codebase I’ve touched in the last two years has had a state-management library somewhere in package.json. Most of them didn’t need one.

Here’s the test: does your state need to outlive a single function call? If the answer is “no” for 80% of your state, you don’t need a library. You need a function.

The Indonesian developer scene is having its Linux moment

Sun, 14 Jun 2026 00:00:00 +0000

I’ve been in Jakarta long enough to have watched the Indonesian tech scene go through three hype cycles. The current one is different — and more durable — because it’s not being driven by outside attention.

A pragmatic review of Hermes Agent after six months

Sat, 13 Jun 2026 00:00:00 +0000

I have been running Hermes as my primary AI agent for about six months. This is a pragmatic review — not sponsored, not a teardown. Just notes from daily use.

What it is, and what it isn’t

Hermes is a personal AI agent. It runs locally, talks to a CLI, a Telegram bot, a Slack workspace, a TUI, and a desktop app — all from the same core. It has skills, memory, scheduled jobs, and the ability to spawn sub-agents.

Why I'm no longer worried about AI replacing senior developers

Fri, 12 Jun 2026 00:00:00 +0000

There’s a genre of LinkedIn post that goes: “AI will replace senior developers because seniors are slower, more expensive, and refuse to learn new tools.”

I have been watching this play out in actual engineering teams for two years. It is not what’s happening.

About

Mon, 01 Jan 0001 00:00:00 +0000

Hi, I’m Shinjae Kang

I’m a programmer and software architect based in Cileungsi, Bogor, Indonesia. Since May 2026 I have been General Manager, AI Business at PT Fast Beauty Indonesia. Public writing and personal projects stay on zemna.net and GitHub.

Portfolio

Mon, 01 Jan 0001 00:00:00 +0000

Now

General Manager, AI Business, PT Fast Beauty Indonesia (May 2026 – present). Public branding remains programmer and software architect. This page lists systems I built, not employers.

Laravel SaaS projects

Modoo appears here as a set of software projects I built, not as an employer label. Repositories live under modoo-id. Application repos are private; docs surfaces are public.