If this one slipped past you last week, it's worth catching up on:

On October 17, 2026, a security researcher discovered that the private keys of eight intermediate CA certificates from eMudhra (emSign) could be derived by a third party. The keys were generated during a key ceremony on April 30, 2025; due to a flaw in the process, P-384 keys that should carry 384 bits of security ended up with only a few bits of effective entropy.

This is not the routine "revoke one TLS certificate" incident. Derivable private keys mean an attacker could, in theory, issue browser-trusted certificates for any domain and quietly man-in-the-middle it — and the code-signing intermediates could have lent malware a legitimate-looking signature.

So over the past week we watched an unusually broad, cross-ecosystem response:

• Chrome, Mozilla and Apple blocked the six affected TLS intermediates; Microsoft blocked the two code-signing ones;
• Go released 1.27.3 / 1.26.10, hard-coding a deny list into crypto/x509 (CVE-2026-111943);
• Node.js shipped its October 21 security releases 22.23.4 / 24.22.1 / 26.12.1;
• Python's certifi, pip and uv, Rust's rustls-webpki and webpki-roots, and PHP's composer/ca-bundle all followed;
• Oracle issued an out-of-band security alert for Java on October 21–22 (CVE-2026-91403, CVSS 9.1);
• Electron, curl, and the Debian/Ubuntu/Alpine CA bundles updated in step.

The good news: as of Talos's analysis on October 21, there was no sign of abuse in the wild, and Chrome found no rogue certificates in Certificate Transparency logs.

But "not abused yet" has never been a reason to skip an upgrade — the whole point of this emergency wave is to close the door before the abuse starts.

What Actually Happened

The timeline starts about eighteen months before discovery.

On April 30, 2025, eMudhra held a key-generation ceremony for 24 subordinate CAs. A flaw in a wrap/unwrap step produced a set of badly weakened P-384 keys. Per Cisco Talos's analysis, their effective entropy was 3 to 8 bits — against a required 384. Eight of these weak keys ended up on eight intermediate certificates: six TLS intermediates (EV/OV/DV, G3B and G3C variants) and two code-signing ones, all under emSign Root TLS CA – G3 and Root CS CA – G3, plus a cross-signed path to Comodo AAA.

A few bits of entropy means the private key isn't in "unguessable" territory — it's in "brute-force it in a moment" territory. Reports note that one recovered key's value was absurdly small.

Those keys sat in the wild for roughly 17 months before discovery on October 17, 2026. eMudhra has since revoked the affected certificates and stopped issuing from its G3 root. Mozilla Bugzilla #2083449 tracks the handling; Talos published the full analysis on October 21.

Why the Fix Had to Be So Heavy-Handed

For a routine certificate incident, the fix is "revoke and replace", and applications barely notice.

Not this time. The private keys themselves are derivable, so revocation isn't enough — every TLS client on the planet must reject these public keys, wherever they show up.

The complication: the places that trust these keys go far beyond browsers.

• Some runtimes compile their trust store into the binary (Go's standard library, Rust's webpki-roots);
• Some distribution channels maintain their own snapshots (Python's certifi, PHP's composer/ca-bundle, Linux distros);
• And the JDK ships its own trust store.

So every ecosystem converged on the same fix: put the SPKI SHA-256 hashes of the eight compromised certificates on a deny list and ship it in an emergency release. The Go team went as far as hard-coding the list into crypto/x509.

That's what makes the keyword of this incident rebuild.

Upgrading the toolchain is only step one. In an already-compiled Go binary, the old deny list — or no list at all — is still baked in. In an already-published container image, the old ca-certificates are still there. An Electron app already delivered to users still runs the old framework. None of these get fixed by upgrading your dev machine — they must be rebuilt and redistributed.

Fix Versions Across Ecosystems

As announced between October 21 and 22:

Java: the Part That Needs More Than a Trust-Store Refresh

Java deserves its own section because the exposure and the fix are both easy to miss.

On October 21, OpenJDK published an advisory (CVE-2026-91403, CVSS 9.1, in javax.net.ssl): the JDK's bundled trust store contained the compromised eMudhra intermediates, so standalone runtimes trust any certificate chaining to them — including forged ones. The affected list is broad:

• JDK 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.32.1, 8u504, and earlier.

Oracle issued an out-of-band security alert, and various CERTs started relaying it on October 22.

The OpenJDK advisory offers three paths, in priority order:

1. Upgrade standalone JDK installs to the fixed releases;
2. If you can't upgrade yet, replace $JDK_HOME/lib/security/blocked.certs with the official file (called blacklisted.certs on JDK 8) — back up your custom entries first;
3. As mitigation, enable revocation checking: -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true, and verify signed JARs with jarsigner -verify -revcheck -strict.

Two details worth flagging: JDKs installed from OS repositories (Arch, Debian, Fedora, RHEL, Ubuntu, etc.) use the operating system's store, so updating the system ca-certificates suffices — but FreeBSD and Homebrew builds must be updated directly. And if a machine has several JDKs installed, every one of them needs this.

The Node Releases Also Contain an RCE

If you only watched the CA story, you may have missed the risk that hits Node users more directly: the October 21 Node.js security releases fixed around ten vulnerabilities, four of them High — and the heaviest one isn't about certificates at all:

CVE-2026-111497: an out-of-bounds write in the Brotli decoder that permits remote code execution, dubbed "Node2Shell" in echo of React2Shell. All three release lines are affected. It was reported by researchers from OpenAI Codex Security.

Also in the same batch:

• two TLS certificate hostname-validation bypasses (IPs written with fullwidth digits, hosts that loosely resolve to an IP), High;
• dns.resolve truncating names containing a NUL character, High;
• entropy caches of crypto.randomUUID() / randomInt() persisted into startup snapshots and SEAs — every process then repeats the same "random" values, Medium. If you generate tokens or IDs with these, that one matters;
• a keep-alive socket processing a response written before the request, non-canonical IPv4 hostname validation, and more.

Fixed versions: 22.23.4 / 24.22.1 / 26.12.1 — upgrade within your major line. Every EOL version remains affected; there is no lucky exemption.

What You Should Do Now

Match your stack:

Everyone:

# Upgrade local and CI toolchains (Node example)
nvm install 24.22.1 && nvm alias default 24.22.1

Then push your artifacts through the pipeline again: recompile, repackage, redeploy. For container images, pull the fresh base image before building — don't hit stale layer caches.

Go: after upgrading to 1.27.3 / 1.26.10, rebuild with go build and redeploy every service. Updating the Go version in CI without recompiling and redeploying fixes nothing.

Python: upgrade pip 26.2.2, certifi 2026.10.19, uv 0.13.4 — in CI and containers too.

Rust: cargo update -p rustls-webpki -p webpki-roots, then re-release.

PHP: composer update composer/ca-bundle.

Java: follow the OpenJDK advisory — upgrade or swap blocked.certs; count how many JDKs you have.

Electron apps: upgrade the framework, repackage, redistribute — installed old builds are not protected by the new release.

Not yet fixed: Bun and FreeBSD hadn't shipped fixes as of October 21. Watch their channels and upgrade the moment they do.

What This Site Did

The day I wrote this post, we closed the doors around here too:

• The local dev machine's Node went from 24.14.1 (affected) to 24.22.1 (fixed);
• The repo's .nvmrc moved from 22.22.2 to 22.23.4, with engines.node bumped to >=22.23.4, so everyone who clones this repo gets a patched toolchain;
• pnpm install, pnpm lint, pnpm typecheck and pnpm build all pass on the new toolchain.

As for runtime, this site runs on Cloudflare Workers: outbound TLS trust is maintained platform-side and doesn't depend on this machine's ca-certificates. But the local dev and build environments still needed the upgrade — an artifact's trust boundary starts at the machine that builds it.

The most tangible takeaway from doing this: none of the usual tooling sees this layer. pnpm audit and friends only look at what's in package.json — not your toolchain, your base images, or your JDK.

Takeaways

Three things I want to remember from this one.

First, the foundation of digital trust is entropy and process. A strength of 384 bits collapsed to 3–8 because of one ceremony flaw — a difference of many orders of magnitude — and the error hid for 17 months. In PKI, "the randomness wasn't random enough" is not bad luck; it's a single point of failure that ceremonies, audits and verification exist to defend.

Second, the unit of remediation has shifted from "upgrade" to "rebuild". We used to say "upgrade to fix", implying a change of state somewhere. This time, toolchains, binaries, container images and shipped apps each needed an explicit rebuild. The deeper the supply chain, the longer the rebuild list.

Third, don't outsource security awareness to a single tool. Auditors and bots watch the thin application-dependency layer; CA stores, language toolchains and system certificate packages below that still depend on humans reading the advisories. The ecosystem's response speed this time — from discovery on October 17 to fixes across the board within a week — was genuinely good. But it only helps if you see the announcement.

Upgrade now, while the weak keys are still unused.

References

• Cisco Talos: Compromised eMudhra intermediate certificates
• Node.js: Wednesday, October 21, 2026 Security Releases
• OpenJDK Vulnerability Advisory (CVE-2026-91403), 2026-10-21
• Oracle Security Alert Advisory for CVE-2026-91403
• The Hacker News: Eight eMudhra CA Keys Compromised
• OpenVPN: What happened and what to update now
• Mozilla Bugzilla #2083449

A while back, we wanted to build a front-end security monitoring system:

• CSP (Content Security Policy) violation tracking
• First-party JS integrity verification
• Third-party JS hash checks
• Risky script alerts

The product is a SaaS platform serving multiple countries. Combined monthly active users across all sites: close to 10 million.

The requirements sounded straightforward. Every time a user opens a page, check CSP compliance, verify JS hashes, and report anomalies. Then build trend analysis, risk statistics, real-time monitoring, and incident search on top.

We picked InfluxDB. The reasoning was, well...

"Time-series databases are fast."

Honestly, I wasn't very familiar with time-series databases at the time. But AI-assisted development moves so fast these days—the architecture isn't even figured out yet, and the system is already running.

The entire system was almost entirely written by Codex. Data structures, InfluxDB writes, dashboards, aggregation queries, front-end hash verification, query APIs—all AI-generated.

First version. Three days to production. Staging environment looked perfect.

Then we deployed.

Everything exploded.

v1: The Memory Aggregation Disaster

At first, I thought the queries were just badly written.

To be fair, the v1 logic was brutally simple: pull all raw data out of InfluxDB, then aggregate in Node.js memory.

Staging was completely fine. Small data volume, few users, low cardinality.

Production was a different planet.

About 20 minutes after deployment, alerts started firing:

• Node memory spiked
• CPU went through the roof
• Dashboard froze
• Queries kept getting slower

Turned out the bottleneck wasn't InfluxDB at all. It was me pulling every raw record into Node and crunching it in memory.

So we immediately started on v2.

v2: Still Broken

This time we made several changes:

• Pushed aggregation logic into InfluxDB's native functions
• Minimized Node-side computation
• Optimized raw query patterns
• Rewrote the query layer

Still broken.

And this time it was weirder—some queries took several minutes to return.

At this point I started wondering: is InfluxDB just not good enough?

Then it hit me. The problem wasn't InfluxDB. The problem was:

I was using a time-series database as a high-dimensional search engine.

What Time-Series Databases Actually Do

A common misconception when people first encounter InfluxDB, Prometheus, or OpenTSDB: "It's a database, so I should be able to query it like MySQL, right?"

No. What time-series databases actually solve is:

How does a metric change over time?

They excel at:

• CPU usage trends
• Error rate tracking
• QPS fluctuations
• Time-bucket aggregation
• Metric-based alerting

That's Time Series Analysis.

They do not excel at:

• Arbitrary multi-condition filtering
• Multi-dimensional search
• Pagination
• Looking up individual records

When I re-examined my actual requirements, I realized what I really needed was:

• Search by userId
• Search by scriptUrl
• Search by hash
• Search by pageUrl
• Multi-condition combination filters
• Risk investigation
• Pagination
• Detailed record retrieval

This isn't "time-series analysis." This is a risk control system, a log search engine, an OLTP query system.

The Abyss: Series Cardinality

The real problem emerged when I finally understood what tag and field actually mean in InfluxDB.

At first I thought:

• tag = indexed
• field = regular column

Nope. That's not it at all.

InfluxDB tags aren't just "indexed fields"—they're part of the series identity. When data is written, InfluxDB has already determined the series structure.

This is a completely different universe from MySQL. In MySQL, no index today? Just run ALTER TABLE ADD INDEX tomorrow. InfluxDB doesn't work like that. A wrong tag design means backfill, rewrite, rebuild—basically rebuilding the entire time-series structure.

7.5 Billion Series

Then I started researching what series cardinality actually means.

InfluxDB combines measurement + tag set into a unique series.

For example:

measurement=csp_report
siteCode=us
env=prod
userId=123
scriptUrl=a.js
pageUrl=/checkout
hash=xxxx

This entire combination is one series.

Change the userId? New series. Change the hash? Another new series.

If you know InfluxDB, you're probably already laughing at seeing userId and hash as tags.

Then I did the math:

Theoretical series:

30 × 100,000 × 500 × 50 × 100 = 7,500,000,000

7.5 billion.

The first time I calculated this, I thought I'd made a mistake. I double-checked. Triple-checked. Nope. 7.5 billion series.

That's when it hit me: the scariest thing about InfluxDB isn't one huge dimension—it's multiple "reasonable-looking" dimensions combining into a combinatorial explosion.

The Real Cost: Metadata, Not Data

Here's the thing: we only had about 1.7 million rows per day.

Honestly, that's not even that much. MySQL with sharding, ClickHouse, Elasticsearch—they could all handle it.

But InfluxDB's most expensive resource was never data volume. It was series cardinality.

People often assume series ≈ data volume. It doesn't.

Series is more like index space. For every single series, InfluxDB:

• Allocates a series ID
• Builds an inverted index
• Maintains metadata
• Creates tag indexes

The real resource drain isn't the data itself—it's the series metadata.

This is why InfluxDB's official docs keep saying: don't put userId, hash, uuid, requestId, or random strings into tags. These fields will blow up your series cardinality.

Why Queries Got Progressively Slower

Under high cardinality, InfluxDB queries aren't just "scanning data." They're scanning massive amounts of series metadata.

Especially:

• tag filters
• GROUP BY operations
• series expansion

These trigger:

• Expensive index scans
• Cross-shard traversal
• Frequent mmap page faults

This isn't something you can fix by "optimizing queries." It's a fundamental architecture mismatch.

The Fix: InfluxDB + MySQL Dual Storage

We tore the whole system apart and rebuilt it.

InfluxDB stayed, but only for what it's good at:

• Trend analysis
• count / sum aggregation
• TOP N rankings
• Time-bucket aggregation
• Alert trends

MySQL handled the search:

• Detail queries
• userId lookups
• hash lookups
• Multi-condition filtering
• Risk investigation
• Pagination

In other words:

InfluxDB for trends. MySQL for records.

The Final Tag / Field Design

The redesigned InfluxDB measurement only kept low-cardinality tags:

# Tags (low cardinality, part of series identity)
siteCode    → ~30 values
env         → prod / staging / dev
type        → csp_violation / js_integrity / third_party_hash / risk_script

# Fields (high cardinality, NOT part of series identity)
reportCount → integer (for aggregation)
riskLevel   → string (high / medium / low)

All high-cardinality fields (userId, hash, scriptUrl, pageUrl) go to MySQL only. InfluxDB only cares about "how many anomalies of type X happened today, and what's the trend."

On the write side, we do dual writes: each record goes to both InfluxDB (for aggregation) and MySQL (for detail queries). Write consistency is handled at the application layer with retries + MySQL transactions. Missing a few writes to InfluxDB doesn't significantly affect trend accuracy.

Here's what I finally understood: to decide whether a system fits a time-series database, don't ask "does the data have a timestamp?" Ask:

Are you looking at trends, or looking up records?

These are fundamentally different problems.

Looking Back

This whole project feels like a microcosm of software development in the AI era.

Codex helped me ship the entire system in 3 days. Staging passed instantly. Development velocity was insane.

But it didn't warn me about:

30 × 100,000 × 500 × 50 × 100 = 7,500,000,000

AI can accelerate development enormously. But systems still have to obey the laws of their underlying architecture.

Speed doesn't matter if you're heading in the wrong direction.

npm package poisoning no longer looks like someone registering a typo-squatted package and waiting for a tired developer to mistype a name.

On May 11, 2026, 84 malicious versions were published across 42 @tanstack/* packages. According to Tanner Linsley's postmortem, the publishes happened between 19:20 and 19:26 UTC, and the incident was publicly reported by an external researcher roughly 20 minutes later.

The important part is what did not happen: this was not a classic stolen npm account story, and there is no evidence that npm credentials were stolen.

Instead, the attacker chained three things together:

1. the pull_request_target "Pwn Request" pattern;
2. GitHub Actions cache poisoning across the fork-to-base trust boundary;
3. runtime extraction of an OIDC token from the GitHub Actions runner process, then direct publish requests to the npm registry.

In other words, the attacker did not steal a long-lived npm token. They borrowed a legitimate publishing identity from the release environment.

That is why this incident feels different. Supply-chain attacks are moving from "steal the credential" toward "abuse the automation that is allowed to mint one."

This Is Not Just a TanStack Problem

It would be easy to turn this into a neat little morality play about one project having one bad workflow.

I do not think that is the useful lesson.

TanStack is mature, widely used, and maintained by people who understand modern JavaScript infrastructure better than most teams do. That is exactly why the incident matters. The attacker did not take the most obvious path. They looked for the joints between CI/CD, caching, OIDC, and npm trusted publishing.

Many teams have a version of this setup today:

• fork PRs that automatically run checks;
• CI caches for pnpm, npm, or Yarn;
• release workflows with elevated permissions;
• npm trusted publishing through GitHub OIDC;
• dependency installs that allow lifecycle scripts;
• maintainers responsible for many packages at once.

Each of those choices can be reasonable on its own.

The problem is that supply-chain attacks are rarely polite enough to stay inside one box. They connect the boxes.

The Three Parts Worth Remembering

1. pull_request_target Is Not the Whole Problem

pull_request_target is not inherently evil. It is often used for labeling PRs, commenting on issues, and updating metadata because it runs in the context of the base repository.

The dangerous move is different: checking out fork-controlled code inside a pull_request_target workflow and then executing it.

That crosses a boundary. The workflow is running with base-repository context, but the code being executed came from an untrusted fork. GitHub Security Lab has warned about this pattern for years under the name "pwn request."

In the TanStack incident, the workflow attempted to split trusted and untrusted work. That instinct was right. The missed surface was the cache.

It is tempting to believe this is enough:

permissions:
  contents: read

But actions/cache post-job saves are not simply controlled by the normal GITHUB_TOKEN permission block. A job that looks read-only can still mutate cache state inside the repository's cache scope.

That is a subtle failure mode, and subtle failure modes are where automation gets expensive.

2. Cache Is a Performance Feature and a Trust Boundary

We usually talk about cache as a speed optimization. That framing is too small.

In a modern frontend project, a package-manager cache may contain:

• package store data;
• compiled artifacts;
• native binaries;
• files generated by postinstall or prepare;
• dependency content later reused by release workflows.

The attack took advantage of that. A malicious PR polluted the pnpm store and saved it under a key that the release workflow would later restore. When a legitimate push to main triggered the release workflow, the poisoned cache crossed from untrusted PR execution into a trusted publishing environment.

The PR did not need to be merged.

It could be force-pushed back to a no-op, closed, and deleted. The cache still existed.

That is the part I keep coming back to. Caches can outlive the social signal that made us stop looking at the PR.

3. OIDC Is Not a Magic Shield

npm trusted publishing and GitHub OIDC are good ideas. Short-lived credentials are better than long-lived npm tokens sitting in CI secrets. Provenance is better than a hand-rolled publish step with no paper trail.

But OIDC solves a specific problem: reducing long-lived secret exposure. It does not make a compromised runner safe.

If a release workflow has id-token: write, and attacker-controlled code is already executing on that runner, the attacker can try to obtain a publish-capable identity from the runtime environment. In the TanStack incident, the normal "Publish Packages" step was skipped because tests failed. The malicious code still made direct publish requests to registry.npmjs.org.

That is the uncomfortable lesson.

We used to ask, "Was the npm token leaked?"

Now we also need to ask, "Can any code path in this workflow reach the publishing identity?"

Why npm Poisoning Keeps Showing Up

npm is not uniquely doomed. But the ecosystem has several properties attackers love.

First, dependency chains are long. One compromised package can spread through transitive dependencies into projects that never selected it directly.

Second, install time can execute code. preinstall, postinstall, and prepare scripts have legitimate uses, from native addons to generated clients to binary downloads. That legitimacy makes them hard to ban outright.

Third, maintainers are overloaded. A single maintainer may own dozens of packages. A single compromised publishing path can become a multiplier.

Fourth, CI/CD has become complicated. Release systems now involve cache layers, matrix builds, preview jobs, automatic releases, provenance, OIDC, comment bots, and third-party actions. Every layer improves productivity. Every layer also creates a new trust boundary.

Fifth, open source is transparent. That transparency is a strength, but it also lets attackers study workflows, cache keys, release cadence, and maintainer habits in public.

So no, the lesson is not "npm is unsafe" or "open source is unsafe."

The better lesson is this: open-source package infrastructure has become high-value production infrastructure, while many of our habits still assume the main thing to protect is a static token.

That mental model is no longer enough.

What Regular Developers Can Do

If you installed one of the affected TanStack versions on May 11, 2026, the official recommendation was to treat the install host as potentially compromised and rotate reachable AWS, GCP, Kubernetes, Vault, GitHub, npm, and SSH credentials.

That sounds severe, but it matches the payload's goal: harvesting credentials from the environment where install scripts run.

For day-to-day work, I would turn a few practices into muscle memory.

1. Pay Attention to Strange Version Bursts

If a package suddenly publishes several patch versions in quick succession, especially without clear release notes, pause for a minute.

You can do a quick check with:

npm view @tanstack/history versions --json
npm diff --diff=@tanstack/history@1.161.8 --diff=@tanstack/history@1.161.9

Manual review will not catch every malicious payload. But it can catch strange files, strange dependencies, and unexpected lifecycle scripts.

2. Treat the Lockfile as a Security Artifact

pnpm-lock.yaml, package-lock.json, and yarn.lock are not just reproducibility files. They are audit surfaces.

After an incident, do not only inspect package.json. Check which versions were resolved, which tarballs were fetched, and whether any GitHub dependencies appeared unexpectedly.

3. Be More Explicit About Install Scripts

Disabling all scripts is not realistic for every project. But trusting every install script by default is becoming harder to defend.

For some CI phases, this is worth considering:

pnpm install --ignore-scripts

When a project genuinely needs build scripts, the allowed packages should be explicit. pnpm's newer build-approval direction is a healthy sign here: installation should not be an unlimited execution surface by default.

4. Reduce Horizontal Credential Exposure in CI

Install jobs, test jobs, and publish jobs should not all have access to the same cloud credentials or publishing identities.

A simple rule works surprisingly well: if a secret is not needed during install or test, do not make it available there. If a permission is only needed during publish, open it only during publish.

What Maintainers Should Audit

If you maintain npm packages, especially packages with automated publishing, the TanStack incident is a good reason to inspect a few things.

1. Search for pull_request_target

The question is not "should we ban it forever?" The question is "what exactly does it do?"

Safer uses usually look like:

• read PR metadata;
• apply labels;
• leave comments;
• do not checkout fork code;
• do not execute fork code;
• do not write cache entries later reused by release workflows.

If you need to run fork-controlled code, prefer pull_request and accept the constraints: first-time contributor approval, lower permissions, and isolated cache behavior.

2. Do Not Let Untrusted PRs Write Production Cache

A cache key is not just a string. It decides which jobs share state.

For fork PRs, consider:

• disabling cache saves;
• scoping cache keys to PR-only contexts;
• keeping release workflow caches separate;
• purging caches during incident response;
• documenting cache cleanup as part of the security playbook.

The boring operational detail matters because cache survives longer than the workflow run that created it.

3. Introduce Publishing Identity at the Last Moment

id-token: write should not be ambient across the entire workflow.

A sturdier shape is a separate publish job that only runs after tests, builds, and package-content validation pass. That job should not restore untrusted cache content, and it should not re-run install scripts that do not need to run.

This does not make publishing invincible. It does reduce the amount of workflow surface that can reach a publish-capable identity.

4. Pin Third-Party Actions

Floating refs are convenient: @main, @v5, @latest.

On release paths, that convenience is a standing supply-chain dependency on someone else's moving target. Pin critical third-party actions to commit SHAs. Upgrade them deliberately.

Slower is fine. Unbounded is not.

5. Monitor Your Own Publishes

TanStack was lucky in one important way: external researchers noticed quickly, and the public IOC pattern emerged fast.

But third-party discovery should not be the only alert.

Maintainers can monitor for:

• unexpected package versions;
• new optionalDependencies;
• unusually large files in tarballs;
• unexpected GitHub dependencies;
• npm provenance from the wrong workflow;
• unusual install errors or download spikes after a release.

Even a small post-publish validation script is better than finding out from a stranger's issue.

The Part That Stuck With Me

The phrase that kept coming back while reading the postmortem was this:

We confuse successful automation with safe automation.

CI is green. The release is automated. Provenance exists. Trusted publishing is configured. Cache restored successfully. Everything looks modern.

But attackers do not care whether our setup looks like best practice.

They care about:

• which code gets executed;
• which cache gets reused;
• which job has elevated permissions;
• when a token appears at runtime;
• which maintainer is too busy to manually inspect a release;
• which install script will run by default.

That is what makes supply-chain security uncomfortable. It is not usually one dramatic bug. It is the composition of reasonable systems.

Closing Thought

I do not think the answer is "stop using npm."

I do not think the answer is "stop using OIDC."

And I definitely do not think every open-source project can suddenly operate like a large security team. That would be unrealistic and unfair.

But we do need a better mental model.

npm package poisoning is no longer only a package-manager problem. It is a CI/CD problem, an identity problem, a cache problem, a release-governance problem, and a maintainer-load problem.

When I look at an automated publish workflow now, I want answers to three questions:

1. Can untrusted code influence the trusted release environment?
2. Does cache cross the fork, main, and release trust boundaries?
3. Does the publishing identity appear only at the final publish step?

If those answers are fuzzy, the risk is not theoretical.

Open source runs on trust. But in 2026, trust cannot only mean "everyone involved is well intentioned." It also has to mean boundaries, evidence, auditability, and a little more suspicion than feels comfortable.

That may be one of the core frontend engineering lessons from this new wave of npm package poisoning.

References

• TanStack/router tracking issue #7383
• GitHub Security Advisory GHSA-g7cv-rxg3-hmpx
• GitHub Security Lab: Preventing pwn requests
• Adnan Khan: The Monsters in Your Build Cache
• StepSecurity: tj-actions/changed-files action is compromised

This migration looked like a stack upgrade at first: Node.js 22.22.2, pnpm 11, Next.js 16, React 19, strict TypeScript, Biome, Zod, OpenNext, Wrangler, and a Cloudflare Workers deployment.

The version bump was not the hard part.

The real lesson was about runtime boundaries:

1. A Cloudflare Worker request should not expect the original content/posts directory to exist.
2. A Cloudflare Worker request cannot use MDX tooling that calls new Function under the hood.

Both problems pushed the project toward the same shape: discover, validate, and compile content at build time. At runtime, the Worker should read prepared data from the bundle and render it.

That sounds obvious after the fact. It did not feel obvious while chasing 500s.

The Upgrade Itself Was Pretty Calm

The project now states the runtime and package manager directly:

{
  "engines": {
    "node": ">=22.22.2"
  },
  "packageManager": "pnpm@11.0.9"
}

The main stack moved to:

{
  "next": "16.2.6",
  "react": "19.2.6",
  "react-dom": "19.2.6",
  "typescript": "^6.0.3",
  "@biomejs/biome": "2.4.14",
  "zod": "^4.4.3"
}

TypeScript stayed strict, and Biome became the main lint entry:

{
  "scripts": {
    "lint": "biome check .",
    "typecheck": "tsc --noEmit"
  }
}

None of this is flashy. But it matters. Once deployment issues start showing up, you want fewer moving parts: one Node version, one package manager, one lockfile, one lint command, and strict type checks that keep the boring stuff honest.

First Failure: Wrangler Tried to Configure the Project During Deploy

The first Cloudflare build was a little deceptive. next build finished successfully, and then npx wrangler deploy detected a Next.js project and tried to set things up interactively.

That is fine on a laptop. It is not fine in a non-interactive build environment.

pnpm 11 also made the failure more visible:

ERR_PNPM_IGNORED_BUILDS Ignored build scripts: workerd
Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts.

The fix was not to make the deploy step smarter. The fix was to make it less responsible.

The project now has an explicit wrangler.jsonc:

{
  "name": "hopes",
  "main": ".open-next/worker.js",
  "compatibility_date": "2026-05-09",
  "compatibility_flags": ["nodejs_compat"],
  "assets": {
    "binding": "ASSETS",
    "directory": ".open-next/assets"
  },
  "observability": {
    "logs": {
      "enabled": true,
      "invocation_logs": true
    },
    "traces": {
      "enabled": false
    }
  }
}

And a small OpenNext config:

import { defineCloudflareConfig, type OpenNextConfig } from '@opennextjs/cloudflare'

export default {
  ...defineCloudflareConfig(),
  buildCommand: 'pnpm next:build',
} satisfies OpenNextConfig

The deployment pipeline became more explicit: the project builds itself, OpenNext produces the Worker output, and Wrangler deploys that output.

Second Failure: The Worker Could Not Read content/posts

After the deploy config was fixed, the site still failed at runtime:

no such file or directory, readdir '/bundle/content/posts'

That error was useful because it was blunt. The app was still trying to scan the source content directory during a Worker request.

That works in local Node. It does not work once the app has been bundled for Workers.

The content discovery step moved into a build script:

const files = (await fs.readdir(postsDir))
  .filter(filename => filename.endsWith('.md') || filename.endsWith('.mdx'))
  .sort((a, b) => a.localeCompare(b))

The script parses each MDX file and writes a generated index:

lib/generated/content-index.json

The runtime then imports that generated file:

import generatedContentPosts from './generated/content-index.json'

This changed the mental model of the content system. The source directory is a build input, not a runtime dependency.

Third Failure: MDX Compilation Used new Function

Fixing the content directory issue made the blog list work, but article pages were still returning 500.

Cloudflare’s logs had the important line:

Code generation from strings disallowed for this context
at new Function (<anonymous>)
at compileMDX

This one was easier to miss because local development worked. The normal Next.js build also worked. The failure only appeared inside the Worker runtime.

The article page was still calling:

compileMDX(...)

compileMDX is convenient, but in this deployment target it was the wrong place to do the work. Cloudflare Workers does not allow the kind of dynamic code generation used by that path.

So the content generation step grew one more responsibility. It now turns Markdown/MDX content into HTML during the build:

const markdownProcessor = remark()
  .use(remarkGfm)
  .use(remarkToc, { heading: 'h2' })
  .use(remarkRehype)
  .use(rehypeSlug)
  .use(rehypeHighlight)
  .use(rehypeStringify)

Article pages render contentHtml from the generated index instead of compiling MDX during the request.

I also removed next-mdx-remote after that. Keeping an unused runtime compiler around would make it too easy to reintroduce the same issue later.

Frontmatter Also Needed a Small Contract

Several MDX posts were missing publishedAt, so the content schema and BLOG.md needed to agree on what a valid post looks like.

The important rules are simple:

• Always include publishedAt.
• Prefer a string date like "2026-05-09".
• Use "zh" or "en" for locale.
• Keep categories and tags as arrays.
• Prefer filenames like <slug>.<locale>.mdx.

This is not just documentation polish. A missing metadata field can quietly turn into a missing post in the list, which is exactly the kind of small content bug that wastes too much time later.

What I Verified

The final checks were:

pnpm lint
pnpm typecheck
pnpm build
npx wrangler deploy --dry-run

I also tested the OpenNext Worker preview directly against:

/zh/blog
/zh/blog/multica-shared-human-ai-board
/en/blog/multica-shared-human-ai-board

The important part was not just getting a 200. It was making sure the Worker no longer hit:

Code generation from strings disallowed for this context

That is the difference between “works in Next dev” and “works where it is actually deployed.”

What I Would Remember Next Time

Cloudflare Workers is not a regular Node server. That is easy to say, but migrations make you feel it.

For a content-heavy blog, I would now default to this shape:

• Scan posts at build time.
• Validate frontmatter at build time.
• Compile Markdown/MDX at build time.
• Keep runtime rendering as small and predictable as possible.

There is one trade-off: you lose some runtime flexibility. For this kind of site, that is fine. A blog does not need to compile every article on every request. It needs to be reliable, cacheable, and boring in the best possible way.

One last detail surprised me a little: after moving from MDX React components to generated HTML, the typography needed attention. The old component-level Tailwind classes did not magically follow the new renderer. The .prose styles had to carry that responsibility.

That is a good reminder. Shipping the page is not the same as making it feel right. For a blog, the reading experience is part of the system too.

Why I took Multica seriously

I tried Multica recently after someone nudged me to give it a real shot. Honestly, my expectations were low.

I assumed it would be one more AI workflow wrapper. Another dashboard trying to glue chat, tasks, and automation together and calling it an Agent platform.

But after actually running it on my home Mac mini M4, my opinion shifted.

What caught my attention wasn't the model list, or the idea of dispatching multiple agents in parallel. It was something much more basic: Multica puts humans and agents on the same board.

That sounds almost boring. But in practice, it's exactly the missing layer in a lot of current AI tooling.

How does a human hand off work? How does an agent pick it up? Where do intermediate updates go? Who makes the final call? What gets recorded when things go wrong? If those answers live across half a dozen terminals, chats, and ad hoc scripts, collaboration still feels improvised.

Multica doesn't solve every problem here, but it does pick the right interface to build around.

What it actually is

If I had to summarize it in one line, Multica is a collaboration platform where humans and AI agents share the same task board.

The flow is refreshingly clear:

1. A human creates an issue.
2. The issue gets assigned to an agent.
3. The agent picks it up on its bound Runtime, clones the repo, and does the work.
4. Progress and results are written back into the same issue.
5. The issue moves to In Review, not straight to Done.

That In Review detail matters more than it seems. It encodes a healthy default: agents execute, humans approve.

And if you're terminal-native, the CLI path is already pretty usable:

multica issue create --title "Write a post about Multica"
multica agent list --output json
multica daemon status
multica issue comment add <issue-id> --content "Draft is ready"

That's why I don't see it as just an "AI kanban." It feels closer to an interface layer for agent collaboration.

Deployment was mostly smooth, with two catches

From an infrastructure perspective, Multica is fairly approachable: Go backend, Next.js frontend, PostgreSQL, and a straightforward docker compose story.

I deployed it with OrbStack and Cloudflare Tunnel, using separate subdomains for the frontend and backend. Overall, it was a lot less painful than I expected.

Still, there were two catches worth calling out.

The first one is the default compose setup. It leans toward prebuilt images, which is fine until you want something more opinionated like a dual-domain setup with a custom WebSocket address. At that point, it becomes easier to switch to source builds than to keep stretching the default configuration.

The second one is APP_ENV=production. Once that is enabled, the universal verification code 888888 is disabled. If you haven't already configured Resend email, it's surprisingly easy to lock yourself out during first-time setup.

Neither issue is dramatic, but both are the kind of thing you'll want to know in advance.

Even so, my overall take on deployment is positive. Once the system is up, the operational path is clear, and the CLI is much better than I expected for day-to-day work.

Runtime is the feature that made me stop and think

The mental model is clean:

Workspace -> Project -> Repo -> Issue -> Agent -> Runtime

The interesting part is the last two layers.

An agent is bound to a Runtime, and a Runtime is bound to a machine. That means you're not vaguely saying "let an agent do this." You're saying "let this agent do this on that machine."

That turns out to be a very practical abstraction.

Real developer environments are not interchangeable. Some tasks only work on a specific machine because of internal network access, certificates, local toolchains, or cached state. In a lot of teams, that reality breaks automation and pushes work back into manual handling.

Runtime binding turns it into a scheduling problem instead.

If the company laptop is running a daemon, and an agent is bound to that Runtime, the task naturally lands there. That doesn't look flashy in a product demo, but it's exactly the kind of constraint that determines whether agent workflows survive contact with real work.

Skills and the CLI are the second layer of value

If Runtime answers "where does the work run," Skills answer "how does the work become reusable."

This is where Multica starts to feel different from plain task-routing tools.

When an agent solves something once, the solution can be captured as a Skill and reused across the workspace. Deployment playbooks, review checklists, migration routines, debugging sequences. Knowledge stops living only in one person's head and starts becoming an executable team asset.

That's a bigger deal than it sounds.

It's not just a prompt library. It's not just internal documentation. It's much closer to a reusable operational primitive.

Then the CLI reinforces the same idea. An agent doesn't need a browser. It needs a way to:

• create or pick up tasks
• leave updates
• change status
• trigger other agents

Those actions fit a CLI far better than a dashboard.

That's when another thought clicked for me: Multica may be designed for humans on the surface, but its best user might actually be the agent itself.

Humans are still in the loop, obviously. But the system feels strongest when agents can coordinate around the interface rather than waiting for humans to orchestrate every step manually.

It also exposes a deeper problem

What makes Multica interesting isn't only what it gets right today. It's also the question it quietly surfaces about what comes next.

Right now, the default flow still looks like this:

Human defines the task boundary -> Human creates the issue -> Agent executes -> Human reviews

That makes sense today. Models are still not reliable or autonomous enough to own full task decomposition most of the time.

But if agent capability keeps improving, the more natural flow may start looking like this:

Human states a goal -> Agents define tasks -> Agents split and coordinate work -> Human reviews key checkpoints

At that point, issue-driven collaboration may start to feel a bit heavy. Not because it's wrong, but because it belongs to a stage where humans still draw every boundary by hand.

That's why I see Multica as a transitional product in the best sense. It's grounded in today's constraints, but it already points toward the next interface problem.

Either it grows into something closer to an operating system for agents, or eventually it gets replaced by more native agent-to-agent coordination protocols.

Why I currently think of it as infrastructure

There's also a very practical lens here: utilization.

A lot of people now pay for multiple AI coding tools at the same time. The question is no longer "do I have access to a capable model?" It's "am I actually using the compute I've already paid for well?"

From that angle, tools like Multica have a simple job: keep agents doing useful work even when you're not actively sitting in front of the terminal.

That is why I think of it less as an instant productivity miracle and more as an infrastructure investment.

It hasn't yet delivered the kind of gain that makes me want to move everything into it overnight. But it feels like the kind of system you want connected early, with daemons running, machines registered, and workflows slowly accumulating around it.

If agent capability keeps improving, the return on that infrastructure should compound.

Final thoughts

My current take on Multica is pretty simple: it's already useful today, but its biggest value probably hasn't arrived yet.

What I find compelling is not any single feature. It's the fact that Multica is trying to answer a serious interface question: what should collaboration look like when humans and agents are both real participants in the same system?

If that question gets answered well, a lot of the agent workflows that still feel experimental right now will suddenly feel normal.

So my conclusion isn't "move everything into Multica tomorrow."

It's more conservative than that, and probably more durable:

Install it. Keep the daemon running. Let machines and agents start building a working relationship.

The rest of the value may show up as the models catch up.

You've probably noticed too

If you've been coding with AI lately, you might have noticed Claude feeling less sharp, or GPT running out of quota faster than before. It's not your imagination.

In April 2026, both issues blew up simultaneously — and neither is small.

Claude: From Developer Darling to Public Enemy

Quality cliff dive

Between April 9th and 10th, numerous Claude Code users reported a sudden degradation in reasoning quality:

• Simple bug fixes: What took 1-2 attempts now requires 7-10 rounds of trial and error
• Stopped using specialized tools: The model started ignoring /plan, /bug commands, and no longer routed correctly to subagents
• Shallower reasoning: Responses became more surface-level, lacking deep analysis

A GitHub issue (#46143) documented this change in detail — no client update, no config change, just suddenly dumber.

Even Claude admits it

The Register ran an interesting experiment: they asked Claude to analyze quality complaints in its own GitHub repo. The results:

• Jan-Feb: ~5 quality complaints per month on average
• March: Surged to 18 (a 3.5× jump)
• First 13 days of April: Already 20+, on track to exceed March

The bigger event: AMD executive's data report

On April 2nd, Stella Laurenzo, Senior Director of AMD's AI Group, filed what might be the most data-rich bug report in AI history on Anthropic's GitHub:

• Analyzed 6,852 session files
• Counted 234,760 tool calls
• Found reads-per-edit dropped from 6.6x to 2.0x

That's a drop of nearly 70%. A product's core metric losing 70% in a week would be unacceptable in any industry.

Translation: Claude stopped "reading code" before modifying it — edit without reading, introduce bugs, try again, repeat.

Anthropic's confirmed changes

• March 3: Default effort level changed from high to medium
• Feb 9: Adaptive thinking shipped, but thinking token UI display may have been hidden
• March 26: Peak-hour throttling introduced, reducing available tokens within 5-hour sessions
• Prompt cache TTL bug: Causing cost inflation of 10-20×

In short: Anthropic lowered the model's "effort level" to manage costs and cope with compute constraints. What users perceive is "it got dumber."

April 13th major outage

Adding insult to injury, Claude suffered a major outage on April 13th, affecting both Claude.ai and Claude Code for approximately 48 minutes, further fueling user frustration.

OpenAI: Price cuts + rate limiting

ChatGPT Pro price halved

On April 10th, OpenAI announced ChatGPT Pro dropping from $200/month to $100/month. Sounds great on the surface, but the underlying logic is worth examining:

• Price cuts usually mean user growth is below expectations, or the cost structure has shifted
• Simultaneously launched GPT-5.4 mini as a fallback model — automatically downgrading when rate limits are hit

Invisible quota reduction

While the price dropped, many users report tighter limits:

• GPT-5.4 Thinking usage restrictions are stricter
• More frequent fallbacks to GPT-5.4 mini
• Manual Thinking mode has a hard cap of 3,000 requests/week

The cost of lower prices is more aggressive throttling and model downgrades.

What's really going on?

Compute bottleneck is the core issue

Both companies' behavior points to the same conclusion: AI compute supply and demand are severely imbalanced.

1. Explosive demand growth: AI coding tools (Claude Code, Codex, Cursor, etc.) saw explosive user growth in Q1 2026, with enterprise users flooding in
2. Supply can't keep up: GPU capacity expansion takes time — new datacenter build cycles are typically 12-18 months
3. Massive cost pressure: Inference costs for large models remain high, and price wars are amplifying losses

Provider strategies compared

It's all the same playbook: when compute is insufficient, use every lever to reduce per-user resource consumption.

What this means for users

1. AI coding tool costs are no longer "negligible." My 150M tokens last week (with RTK) was already compressed. Without optimization tools, costs would be much higher
2. Model quality may continue to fluctuate. Providers prioritize enterprise customers when compute is scarce — individual user experience may suffer
3. Tooling matters more than ever. Token compression tools like RTK have gone from "nice to have" to "must have." Multi-model strategies make more sense too
4. Small models have their moment. GPT-5.4 mini shows providers are serious about "good enough" models that may be more cost-effective for specific use cases

My playbook

As a heavy AI coding user, here's my current strategy:

1. RTK always on: Validated 57% token savings with zero learning curve
2. Multi-model mixing: Don't rely on a single model — if Claude struggles, switch to GPT, and vice versa
3. Off-peak usage: Anthropic themselves said off-peak hours offer better experience
4. Local-first for simple tasks: Reserve big model quotas for complex work

The real problem: opacity

A compute shortage is understandable. What actually frustrated users was how it was handled.

Anthropic never candidly said "we're compute-constrained and need temporary throttling" — instead the default effort was quietly lowered, thinking token display was hidden, and throttling was packaged as "elastic definitions." OpenAI announced a price cut while silently switching users to the mini fallback model more often, without clear notice. You pay the same money and may receive a downgraded service, with no way to notice.

Users aren't stupid. They know exactly what they're getting and what they aren't. Instead of investing in spin, invest in capacity — give users the best product, not the cheapest excuse.

Final thoughts

The AI industry is in an interesting phase: technical capabilities are advancing rapidly, but infrastructure hasn't caught up. Providers are struggling to balance user growth, cost control, and experience quality.

For developers, the best response isn't complaining about dumber models — it's building a workflow that doesn't depend on a single provider. After all, tools exist to serve us, not the other way around.

Related posts:

• Previous: 150M Tokens in One Week: My Codex Usage with RTK
• Earlier: 350M Tokens in 11 Days: My Codex Usage Record

Background

Last week I logged 350M tokens consumed over 11 days and mentioned I'd try RTK to optimize. One week later, the results are in: 150M tokens.

Same workflow — Codex 5.4 and 5.3-codex mixed, the same write-review-revise loop, similar project complexity. The only change: RTK.

Data Comparison

From 350M down to 150M — 200M tokens saved. RTK's compression performed better than I expected.

RTK Experience

Biggest takeaway: invisible, but effective

Honestly, after a week with RTK, I barely notice it's there. It's a transparent proxy — AI tools do exactly what they did before, and output quality feels unchanged.

But when you check the usage stats, the difference speaks for itself.

Where compression shines

• git diff / git status: Large project diffs are extremely verbose. RTK compresses them into a concise version that AI can understand just as well
• Test output: Massive repetitive pass/fail logs get folded, keeping only key information
• Error logs: Stack traces get truncated to essential frames instead of stuffing the entire call chain into context
• File listings: find, ls outputs get grouped by directory with deduplication

Where it doesn't make much difference

• Direct coding conversations — token usage is already low, not much to compress
• Short command outputs — minimal difference before and after compression

What the saved tokens mean

1. Cost cut in half. At last week's burn rate, a month would be over a billion tokens. The savings are real money
2. Context window lasts longer. The same context window fits more conversation turns, so long tasks don't get truncated as easily
3. Less anxiety about context limits. No more worrying "this diff is too long, will it blow up the context"

Conclusion

Last week I said "next week's post will have the test results — let's see if RTK is a cost-saver or just hype." The verdict is clear: it's a cost-saver.

57% token reduction, zero learning curve (rtk init and you're done), virtually no impact on the development experience. For anyone heavily using Codex or similar AI coding tools, RTK is essentially a must-install.

Previous: 350M Tokens in 11 Days: My Codex Usage Record

Over the past 11 days, I've been using Codex heavily for daily development. Before I knew it, my token usage had climbed to 350 million. Here's a breakdown of what happened behind that number.

The Numbers

• Period: March 30 – April 9, 2026 (11 days)
• Total Token Consumption: ~350 million
• Models Used: Codex 5.4 (primary), Codex 5.3
• Main Use Case: Daily coding and documentation

How I Used the Models

The two models served distinct purposes:

• Codex 5.4: Used for writing documentation — higher quality output, more accurate expression
• Codex 5.3: Used for rewriting and iterating on top of 5.4's output

My actual workflow: draft with Codex 5.4 first, then rewrite and refine with Codex 5.3, followed by repeated review cycles — having the AI review its own writing, suggest changes, and iterate. This "write-review-revise" loop consumed the bulk of the 350 million tokens.

What Ate All Those Tokens

350 million sounds like a lot, and honestly, most of it came from:

• Implementing and iterating on complex features
• Code review and refactoring suggestions
• Long-context conversations (feeding entire files to the AI for context)

The productivity gains from AI-assisted coding are real, but the token cost is hard to ignore. Especially with the documentation workflow — the "write-review-revise" cycle produces high-quality docs, but tokens pile up fast. I need to think about optimizing this process: reducing unnecessary review rounds, managing context length, and keeping token usage in check without sacrificing output quality.

The Optimization Plan: Enter RTK

Starting today, I'm introducing RTK to cut down on wasted tokens. RTK is a CLI proxy that filters and compresses command output before it reaches the LLM, claiming to reduce token consumption by 60-90%.

It handles common dev command outputs — git diff, git log, cat, grep, test results, and more — stripping out the noise and keeping only what matters.

How It Works

RTK transparently rewrites Bash commands via hooks (e.g., turning git status into rtk git status). The AI tool never sees the rewrite — it just receives compressed output.

It applies four strategies per command type:

• Smart Filtering — Removes noise (comments, whitespace, boilerplate)
• Grouping — Aggregates similar items (files by directory, errors by type)
• Truncation — Keeps relevant context, cuts redundancy
• Deduplication — Collapses repeated log lines with counts

It supports Claude Code, Codex, Copilot, Gemini CLI, Cursor, Windsurf, Cline, and more — one command to set up.

Over the next week, I'll run a real-world development test comparing token usage with and without RTK using the same workflow. Results will be shared in a follow-up post.

E-commerce checkout pages handle sensitive data by nature — addresses, ID numbers, tax IDs. What makes it worse: the rise of AI tools has dramatically lowered the barrier for attackers. XSS injection and MITM attacks that once required real skill can now be automated — LLMs can generate exploit scripts, scan for vulnerabilities, and even mimic normal user behavior to bypass security controls. Security audits are getting stricter: sensitive input should not happen in the main page context.

But here's the reality — checkout address modules accumulate years of iteration, deep coupling, and fragile dependencies. A full rewrite isn't practical when you have a shipping deadline.

So the question became: how do we isolate sensitive input without rewriting the main checkout flow?

Why Not "Rewrite Everything"

We evaluated several approaches:

We went with the last option. The core judgment: isolating the input process solves the biggest security pain point in phase one. Read-only display on the main page can be addressed later.

Architecture: Three Layers, Clear Boundaries

1. Parent Page (Checkout)

• Continues handling address list queries and display (unchanged in phase one)
• Add/Edit buttons now open an iframe modal
• Requests a short-lived session token for each operation
• Listens for save-success messages from the iframe, then refreshes the address list

What the parent page does not do: render sensitive forms, read iframe DOM, or observe user input keystrokes.

2. Collector (Sandbox Iframe)

• Renders the full address/document form independently
• Manages its own form state and validation
• Fetches initialization data (country lists, edit prefill) from the middleware using the session token
• Submits through the middleware — never connects directly to backend APIs
• Notifies the parent via postMessage on successful save

Key design choice: a single collector supports two modes via a scope parameter — full address form or document-only form. One page, two use cases.

3. Middleware (Node Facade)

This is the funnel point for all sensitive operations:

• Manages short-lived session tokens (30-minute TTL, invalidated immediately after successful submit)
• Aggregates country lists and edit prefill data for the iframe
• Forwards address save and document save requests to real backend services
• Applies uniform log sanitization and parameter filtering

The middleware does not store address plaintext, maintain long-term drafts, or replace the existing address list data source.

Session Management: Security Meets UX

Session token design is the security backbone:

• Short-lived: Fixed 30-minute expiry, immediate invalidation after successful submission
• User-bound: Tokens are bound to the current user, site, and operation mode
• Single-session constraint: Only one active session per page; creating a new one automatically invalidates the old
• Edit permission check: In edit mode, the middleware verifies the user owns the address being edited

Even if a token leaks, the attack window is narrow and cross-user usage is impossible.

Submit Strategy: Handling Multi-API Failure Scenarios

Real-world saves involve multiple backend calls (address body, document info, default address sync). The failure handling strategy needed careful thought:

Execution order: Save address body → Save document info → Handle default address and billing address sync

Failure scenarios:

• Address saved, document save failed: No compensating delete (in create mode). Return "partial save" status, prompt user to verify
• Address and document saved, default address sync failed: Same "partial save" treatment
• Partial failure in edit mode: No automatic rollback promised. Prompt user to retry or manually refresh

Core principle: It's better to honestly tell the user "please verify" than to pretend everything succeeded.

Message Validation: Don't Let postMessage Become a New Attack Surface

Parent-iframe communication via postMessage is itself a potential vector. Our defenses:

• Verify message source is the iframe's contentWindow
• Generate a random nonce per session; iframe must include it in responses
• Only handle whitelisted message types (e.g., save-success); ignore everything else
• Don't rely on event.origin as the sole trust signal

What We Didn't Do (Being Honest)

Phase one has clear boundaries:

• ❌ Main page still displays full addresses in the list
• ❌ Middleware and backend still see full addresses during save/prefill
• ❌ No frontend rewrite for delete address or set-default-address flows

These aren't oversights — they're deliberate trade-offs. Phase one's goal is input process isolation, not full-pipeline data desensitization.

Rollout: Starting with a Single Site

Phase one is controlled via feature flags, launching first on a single site (Brazil). Key metrics we're watching:

• Session expiration rate
• Mobile collector open success rate
• Create/edit save success rate
• Partial save error rate

Expansion to other sites happens only after stability is confirmed.

Takeaways

Looking back, the biggest lesson: security improvements don't always require a big-bang rewrite.

Find the smallest meaningful cut, solve the biggest risk first, then expand incrementally. It's more practical than waiting for a "perfect" solution that never ships.

Of course, sandbox iframes aren't a silver bullet. Full-pipeline desensitization (including main page display) will require deeper data model changes. But that's phase two's problem.

Solve what's in front of you first. Idealism can wait.

I've been playing with OpenClaw lately — a framework that connects AI assistants to chat platforms like Telegram and Discord. The overall experience has been smooth, but I hit a frustrating roadblock when setting up scheduled cron jobs. Here's what happened and how I fixed it.

The Problem: pairing required

I wanted my bot to send me a daily AI news digest at 9 AM every morning. So I asked the bot to create a cron job from our Telegram chat.

The bot ran openclaw cron add, and got this error:

gateway connect failed: GatewayClientRequestError: pairing required
Error: gateway closed (1008): pairing required

The CLI couldn't talk to the Gateway because the device hadn't been paired yet.

Gotcha #1: The wrong pairing command

My first instinct was to check the docs and try openclaw gateway pair — seems logical, right? It didn't work.

The correct way is through the openclaw devices subcommand:

# Check available subcommands first
openclaw devices --help

# Then approve the pairing
openclaw devices approve

After running openclaw devices approve, the CLI could communicate with the Gateway normally.

Gotcha #2: Unpaired commands crash the Gateway

This one hurts. If you let the bot try running openclaw cron add before pairing is done, it doesn't just fail — the Gateway drops the connection entirely.

That means your bot goes offline and needs to reconnect. If you're operating through a chat interface, that's pretty frustrating.

The correct order:

1. Complete device pairing first: openclaw devices approve
2. Then let the bot create scheduled tasks

After Pairing: Creating the Cron Job

Once pairing is sorted, creating scheduled jobs is straightforward:

openclaw cron add \
  --name "AI Daily Brief" \
  --cron "0 9 * * *" \
  --tz "Asia/Shanghai" \
  --session isolated \
  --message "Search for AI news from the past 24 hours..." \
  --announce \
  --channel telegram \
  --to "your_chat_id"

Key parameters:

• --session isolated: Runs in an isolated session, doesn't interfere with your main chat
• --announce: Delivers the result to the specified channel after execution
• --cron + --tz: Cron expression with timezone for scheduling
• --channel telegram --to <id>: Specifies the delivery target

Model Choice

I'm using zai/glm-5-turbo (Zhipu GLM-5 Turbo) as the model. So far it's been solid — fast responses, good Chinese language understanding, more than enough for daily assistant tasks.

Summary

OpenClaw is a really interesting project overall, but the device pairing flow could definitely use better documentation. Hope this saves someone some time.

If you're also tinkering with OpenClaw, feel free to reach out 🤝

I’ve been a full-stack developer long enough to experience multiple waves of tooling revolutions — package managers, TypeScript, React, SSR, serverless, design systems. Nothing has reshaped my workflow as dramatically as the last three years of AI-assisted development.

The most surprising part?

AI kept writing more code for me — yet I became more tired, not less.

Backend controllers, database access layers, types, validators… Frontend components, layout scaffolding, responsive CSS, translations… AI writes them all — and writes them fast.

But the turning point came when I realized:

The hardest part is no longer generating code. The hardest part is verifying that the generated code is correct.

1. Two Opposite Voices — and How Full-Stack Developers End Up Caught in the Middle

Every discussion on AI coding collapses into two camps:

⚡ “Look how fast AI is!”

“I generated 20 components in 10 minutes.” “I built the whole login flow without typing anything.”

⚡ “AI is unreliable and costs more time.”

“I spent half an hour debugging AI’s mistakes.” “Looks correct, but breaks in edge cases.”

Both are true.

• Backend AI shines in CRUD, DTOs, pagination, boilerplate
• Frontend AI shines in layout, component scaffolding, design translation
• But AI struggles on:
  • complex business logic
  • stateful UIs with subtle interactions
  • codebases with history and hidden constraints
  • legacy systems with inconsistent styles

My early AI adoption was chaotic:

• If something “felt like AI could do it,” I threw it in
• Sometimes the output was amazing
• Sometimes I spent hours fixing elegant-looking but subtly broken code

I realized: Success was random because my process was random.

2. Stop Asking “Is the AI Accurate?” — Start Asking “Is It Worth It?”

I used to fixate on accuracy:

• “Did AI generate the correct component?”
• “Is this reducer logically sound?”
• “Is the validation rule complete?”

But accuracy is a trap.

The real metric is:

Value = Manual Time ÷ (AI Generation Time + Fix Time)

If a task takes me:

• 6 hours manually
• and 1 hour with AI including fixes

→ That’s a win Even if the first generation was imperfect.

The “sweet spot” of AI work

For both frontend and backend, high-ROI AI tasks share four characteristics:

1. Repetitive / template-based
2. Time-consuming but low creativity
3. Low risk, easy to review
4. Clear verification criteria

3. The Frontend Revolution: Design-to-Code Is No Longer a Dream

The biggest shift for frontend engineers happened in 2024–2025:

Gemini 3 Pro and similar models reached near-pixel-perfect design reconstruction.

I’m not exaggerating: Give it a Figma frame or even a screenshot, it outputs:

• React components
• Tailwind or CSS modules
• Responsive breakpoints
• Motion presets
• Accessible markup
• Semantic structure
• Even fine-tuned spacing rules

For components like:

• navigation bars
• hero sections
• pricing cards
• dashboards
• settings forms

The accuracy often reaches 90–100% visual parity.

What does a frontend engineer do now?

We no longer waste time hand-coding:

❌ spacing ❌ layout ❌ pixel alignment ❌ repetitive patterns ❌ boilerplate interactions

Instead, our time goes into:

✔ Interaction validation

Did the menu animate correctly? Are the tabs keyboard accessible?

✔ Logic consistency

Does the component handle all states? Empty, loading, error, offline, etc.

✔ Performance & compatibility

Does it behave the same across browsers? Does React’s hydration work with the generated structure? Are animations GPU-friendly?

✔ Edge-case UX

What happens if the user pastes a long string? What if API requests race?

✔ Code quality & maintainability

AI can match design — but it’s our job to guarantee:

• predictable component architecture
• clean props design
• consistent naming
• shared utilities
• integration with our design system

In other words:

Frontend developers moved from “drawing UI with code” to “verifying UI correctness in a complex environment.”

And this shift mirrors exactly what happened on backend.

4. Backend + Frontend = The Same New Role: Context Designer

The old role of a full-stack engineer was:

• Write code
• Write more code
• Write tests
• Maintain code

The new AI-augmented role is:

Design context → Generate → Validate → Integrate → Test → Monitor

I now treat AI like a highly skilled but context-blind intern

AI is brilliant at:

• coding patterns
• consistency
• speed
• structure
• transformations

AI is terrible at:

• intuition
• business rules
• historic constraints
• implicit assumptions
• domain-specific pitfalls

So my workflow changed from:

80% coding → 20% verifying to 30% coding → 70% verifying / validating / designing context

And honestly? This new ratio is harder — but also more valuable.

5. Making Projects “AI-Ready”: Standardization + Automation

This is the part almost every team underestimates.

AI thrives in clean environments.

AI suffers in messy ones.

The best investments I’ve made:

Backend

• standardizing DTOs
• centralizing error codes
• unifying logging patterns
• writing clear OpenAPI specs
• keeping SQL / Prisma schema consistent

Frontend

• consistent folder structure
• documented design system tokens
• reusable component patterns
• one source of truth for spacing / typography
• onboarding guides for AI (“How we name components”, etc.)

AI becomes dramatically more accurate when the project is coherent.

In a messy repo? AI hallucinations explode.

Automation completes the loop

• pre-commit hooks
• component snapshot tests
• visual regression tests
• type-level validations
• storybook interactions
• PR checks
• automated linting
• schema-driven UI generation

AI now sets up most of these for me.

The result?

Developers spend their effort on decisions, not on glue code and wiring.

6. Why Developers Feel More Exhausted Than Before

This is an uncomfortable truth:

Humans are LLMs with tiny context windows and expensive context switching.

AI writes fast, but it also creates:

• more PRs
• more decisions
• more threads
• more code to validate
• more interactions to test
• more complexity to manage

This leads to “attention fragmentation.” The brain becomes the bottleneck.

My survival strategy as a full-stack engineer

• Deep work blocks: one topic per block
• AI batching: prepare prompts → let AI run → batch-review
• 3-minute rule: instant decisions for trivial tasks
• Clear prompts: always include background + constraints
• One main project per day: avoid context thrashing

AI magnifies productivity — but only when we protect our attention.

7. Two Principles That Will Outlast Every AI Tool

1. The bottleneck has shifted from generation to validation.

The code is cheap. Correctness is expensive.

2. Context is King.

Your AI output is only as good as:

• your specs
• your examples
• your constraints
• your documentation
• your architecture
• your clarity

Teams that embrace this outperform those that rely on “prompt magic.”

8. Final Advice for Full-Stack Developers

If you’re new to AI coding

Start with:

• CRUD
• simple components
• small migrations

Learn the “value equation.”

If you’re already using AI extensively

Invest in:

• better context
• clearer prompts
• stronger validation pipelines
• project-wide standardization

If you’re a tech lead or manager

Shift from:

“How fast can AI generate code?” to “How robust is our human–AI collaboration pipeline?”

Closing Thoughts

AI hasn’t replaced developers. But it has fundamentally reshaped the job.

We’re no longer judged by:

• how fast we type
• how clever our abstractions are

Instead, our core value is:

• how well we express intent
• how well we design systems
• how effectively we validate correctness
• how reliably we orchestrate AI

AI now writes a significant portion of the code. But we decide what gets built, how it fits together, and whether it is safe to ship.

We’ve moved from “writing code” to “designing and verifying an intelligent system that writes code with us.”

To be honest, this project started differently from the beginning.

When I received that detailed design document, my first reaction was: this isn't just a technical requirement—it's a complete brand philosophy—"hopes.icu," a personal space for continuously producing reusable experiences and gentle insights between technology and life.

But what made this project different was my decision to completely rely on AI collaboration for the entire development process. From design understanding to technical implementation, from content creation to system optimization, I wanted AI to be a true development partner.

Pain Points: Efficiency Bottlenecks in Traditional Development

In similar past projects, I typically encountered these issues:

• Understanding Deviation: Information loss from design documents to technical implementation
• Repetitive Labor: Similar components and configurations required repeated writing
• Context Switching: Frequent switching between different tech stacks and tools
• Maintenance Costs: Need to re-understand previous code during iterations

Opportunity: The Value of AI as Development Partner

This time I wanted to test a hypothesis: Could AI be more than just a code generation tool, but a true development partner?

My goals were clear:

1. Design Understanding: AI could understand abstract design concepts
2. Technical Implementation: AI could generate high-quality code
3. Iterative Optimization: AI could continuously improve during development
4. Knowledge Transfer: AI could explain technical decisions and best practices

AI Collaboration Process | Complete Practice from Concept to Product

Phase One: Architecture Design and Technology Selection

Initial Prompt:

"I need to create a personal blog platform called hopes.icu, with the core concept of 'continuously producing reusable experiences and gentle insights between technology and life.' It needs to support Chinese and English, including homepage, blog list, tag filtering, about page, and other features. Please help design a complete technical architecture and project structure."

AI's response exceeded my expectations:

1. Tech Stack Recommendations: Next.js 15 + TypeScript + Tailwind CSS 4 + Supabase
2. Directory Structure Design: Complete folder hierarchy and component division
3. Data Model Design: Database structure for blog posts, categories, and tags
4. Internationalization Solution: Complete configuration suggestions for next-intl

What surprised me most was that AI not only provided technical solutions but also explained the reasoning behind each choice, like why to choose Tailwind CSS 4 over traditional versions.

Phase Two: UI Components and Design Systems

Design System Standardization:

The icon system in the project was a typical example. When I raised the need to unify icon styles:

"I need to standardize the entire website's icon system, using consistent visual style and theme color adaptation."

AI not only understood the requirement but also proactively analyzed existing problems:

• Identified icon usage issues in 27 files
• Suggested using lucide-react as the unified standard
• Created reusable Icon components
• Developed a phased migration strategy

// AI-generated unified Icon component
export function Icon({ name: IconComp, className, title, ...rest }: IconProps) {
  return (
    <IconComp
      className={cn("w-5 h-5 inline-block align-middle", className)}
      aria-hidden={title ? undefined : true}
      aria-label={title}
      {...rest}
    />
  )
}

Phase Three: Content Creation and Internationalization

Multilingual Content Generation:

The most impressive part was content creation. When I needed to populate the website with content:

"Please help me generate complete bilingual content for the hopes.icu website, including homepage copy, about page, navigation tags, etc., reflecting the brand philosophy of 'letting hope breathe in practice'."

AI not only generated fluent bilingual copy but also:

• Understood the brand's emotional tone
• Maintained stylistic consistency across Chinese and English versions
• Automatically adapted to different language reading habits
• Provided SEO-optimized metadata configuration

Phase Four: Technical Optimization and Problem Solving

Quick Resolution of 404 Issues:

When we encountered the 404 issue with http://localhost:3333/en/blog/glm-coding-plan-review:

"This blog page is returning 404, please help me troubleshoot."

AI's troubleshooting process was very systematic:

1. Checked if the file exists
2. Verified route configuration
3. Analyzed content parsing logic
4. Identified slug mismatch in frontmatter
5. Provided specific fix suggestions

The entire process took only a few minutes, whereas manual troubleshooting might have taken half an hour.

Technical Highlights of AI Collaboration

1. Context Understanding and Memory

Throughout the development process, AI demonstrated excellent contextual understanding:

• Design Concept Understanding: AI accurately grasped the abstract concept of "reusable experiences and gentle insights"
• Technical Stack Consistency: AI consistently maintained technical choices without recommending conflicting solutions
• Brand Tone Maintenance: Maintained consistent brand voice across all content generation

2. Proactive Problem Identification

AI wasn't just passively executing commands but proactively identifying potential issues:

// AI-proactively identified configuration issues
export default withNextIntl(nextConfig)
// Correct writing should be:
export default withNextIntl(nextConfig)

3. Best Practices Application

AI always followed modern frontend development best practices when implementing features:

• TypeScript Strict Mode: Complete type definitions
• Accessibility: Semantic HTML and ARIA labels
• Performance Optimization: Code splitting and lazy loading
• SEO Friendly: Complete metadata configuration

Efficiency Comparison and Analysis

Development Time Comparison

Code Quality Comparison

Traditional Development:

• Prone to design inconsistencies
• Requires manual type definition maintenance
• Easy to overlook accessibility
• SEO configuration might be missed

AI Collaborative Development:

• Automatically maintains design consistency
• Complete TypeScript type safety
• Proactively considers accessibility
• Complete SEO configuration

Learning Value

Beyond efficiency improvements, AI collaboration brought additional learning value:

• Technical Explanations: AI explains the reasons behind technical decisions
• Best Practices: AI shares industry best practices
• Alternative Solutions: AI provides comparisons of different technical choices
• Trend Insights: AI shares latest technology trends

Best Practices for AI Collaboration

1. Precise Requirement Description

This successful experience taught me that the key to AI collaboration is:

✅ Good Prompt:
"I need to create a personal blog platform with the core concept of 'continuously producing reusable experiences and gentle insights between technology and life,' supporting Chinese and English, including homepage, blog list, tag filtering, and other features. Please design technical architecture and explain choice reasons."

❌ Vague Prompt:
"Help me make a blog website."

2. Iterative Development

Don't expect perfect results in one go, but instead:

1. Initial Draft Generation: Let AI quickly generate a basic version
2. Detail Optimization: Gradually improve functionality and details
3. Quality Check: Manual verification and adjustment
4. Continuous Improvement: Further optimization based on usage feedback

3. Context Maintenance

In long-term projects, maintaining AI's contextual memory is important:

• Project Overview: Regularly remind AI of project goals and constraints
• Technical Conventions: Clarify code style and architectural decisions
• Brand Guidelines: Maintain consistent design and content style

4. Human-AI Collaboration Balance

AI doesn't replace humans but enhances human capabilities:

• AI Responsible For: Repetitive work, technical implementation, initial solutions
• Humans Responsible For: Requirement confirmation, quality control, creative decisions
• Collaboration Mode: AI provides suggestions, humans make choices

Pitfalls and Reflections

Technical Challenges

Honestly, we encountered some problems during the process:

Cache Issues: Some configurations generated by AI required server restarts to take effect, requiring experience to judge.

Version Compatibility: Some library versions recommended by AI might conflict with existing environments, requiring manual adjustments.

Personalized Needs: Generic solutions generated by AI might need adjustments based on specific requirements.

Collaboration Model Optimization

Through this practice, I learned how to better collaborate with AI:

1. Phased Validation: Verify results promptly after each phase completion
2. Clear Constraints: Clarify technical constraints and goals at the beginning
3. Retain Decision Power: AI is the suggester, humans are the decision-makers
4. Continuous Learning: Learn new technologies from AI's solutions

Future Outlook

Evolution of AI-Assisted Development

This practice showed me the huge potential of AI-assisted development:

1. Stronger Context Understanding: AI will better understand project long-term goals
2. End-to-End Automation: Full-process automation from requirements to deployment
3. Personalized Adaptation: AI will learn developer preferences and habits
4. Real-time Collaboration: AI will become real-time development partners

Transformation of Developer Roles

In the AI era, developer roles will fundamentally change:

• From Coder to Designer: More focus on system design and user experience
• From Executor to Decision Maker: Responsible for technology selection and architectural decisions
• From Maintainer to Innovator: Focus on creative work and technological innovation

Future Skill Directions

Future developers need to cultivate these abilities:

1. AI Collaboration Skills: Learn to communicate and collaborate efficiently with AI
2. System Design Skills: Understand complex system architecture and design
3. Problem Definition Skills: Accurately describe requirements and constraints
4. Quality Control Skills: Verify and optimize AI-generated solutions

Conclusion

This AI collaborative development journey completely changed my understanding of software development. From the initial concept to the final product, AI not only greatly improved development efficiency but, more importantly, opened up a completely new development paradigm.

What impressed me most was that AI isn't just a tool but more like a technical partner who understands project philosophy. When AI understood the abstract concept of "letting hope breathe in practice," the code and content it generated all carried a consistent brand tone.

In the AI era, the value of developers is no longer the ability to write code, but:

• Ability to understand requirements
• Ability to design systems
• Ability to control quality
• Ability to collaborate with AI

The birth of hopes.icu is a successful practice of this new development paradigm. It's not just a technical product but a crystallization of human wisdom and AI collaboration, demonstrating the infinite possibilities of future development.

Just as our website philosophy says: "letting hope breathe in practice," AI technology allows our development hopes to breathe and grow in reality.

Tech Tags: #ai-collaborative-development #nextjs15 #design-systems #modern-frontend #development-efficiency #human-ai-collaboration

To be honest, this problem had been bothering us for a long time.

Pain Points: A Chaotic Icon Ecosystem

Our hopes.icu project had accumulated various icon sources during iteration:

• Direct copy-pasted SVG code snippets
• Scattered inline <svg> tags
• Third-party icon libraries introduced at different times
• PNG format placeholder images and favicons
• Hand-drawn temporary icons

Even worse, these icons had completely inconsistent styles, sizes, and colors. Some used currentColor, others hardcoded #333, and some used outdated gradient effects. Sizes were all over the place: 16px, 18px, 20px, 24px mixed together, causing frequent alignment issues.

The Last Straw

The turning point came during last week's design review. The designer pointed out that our navigation bar icons displayed inconsistently in different themes: barely visible in dark mode, too prominent in light mode. Even more embarrassing was when we wanted to uniformly adjust all icon theme colors, we discovered we needed to manually modify files in over a dozen places—what a nightmare.

That evening, I spent three hours counting icon usage in the project:

# Statistics at the time
find . -name "*.tsx" -o -name "*.ts" -o -name "*.mdx" | xargs grep -l "svg\|icon" | wc -l
# Result: 27 files involved in icon usage

This number made me realize the problem's severity had exceeded simple fixes.

Goals: Establish a Unified Design Language

Our goals were clear:

1. Visual Consistency: All icons using the same design language
2. Theme Adaptation: Automatic adaptation to dark/light themes
3. Development Efficiency: Minimize cost of adding new icons
4. Maintainability: Unified management approach and API

Implementation Process | From Chaos to Order

Asset Inventory: Taking Stock

The first step was a comprehensive inventory of existing icon assets:

# Count various icon types
grep -r "lucide-react" . --include="*.tsx" | wc -l      # 15
grep -r "<svg" . --include="*.tsx" | wc -l              # 12
grep -r "className.*icon" . --include="*.tsx" | wc -l   # 8

Results showed that while the project already partially used lucide-react, there were still many custom SVGs and inline icons.

Decision: Choosing lucide-react as Standard

After team discussion, we decided to fully adopt lucide-react as our icon standard, with solid reasons:

1. Consistent Design Style: All icons use the same line weight and rounded corners
2. Good Theme Adaptation: Native support for currentColor
3. TypeScript Support: Complete type definitions
4. Excellent Performance: On-demand imports, tree-shaking friendly
5. Rich Icon Library: Covers all common icons we need

Unified Icon Component API

To simplify usage, we created a unified Icon component:

// components/ui/icon.tsx
import * as React from "react"
import type { LucideIcon } from "lucide-react"
import { cn } from "@/lib/utils"

type IconProps = {
  name: LucideIcon
  className?: string
  title?: string
  "aria-hidden"?: boolean
}

export function Icon({ name: IconComp, className, title, ...rest }: IconProps) {
  return (
    <IconComp
      className={cn("w-5 h-5 inline-block align-middle", className)}
      aria-hidden={title ? undefined : true}
      aria-label={title}
      {...rest}
    />
  )
}

Migration Strategy: Phased Replacement

We developed a three-phase migration strategy:

Phase One: Core Components

• Header navigation icons
• Footer social icons
• Theme toggle button

Phase Two: Functional Pages

• Blog list icons
• Tag and category icons
• Search and filter icons

Phase Three: Detail Optimization

• Form control icons
• Status indicator icons
• Decorative icons

Each phase went through complete testing to ensure no existing functionality was broken.

Technical Details | Tailwind CSS 4 & Next.js 15 Implementation Experience

Tailwind CSS 4 Configuration Optimization

Tailwind CSS 4 brings exciting new features, especially better support for design tokens:

/* app/globals.css */
@theme {
  /* Semantic icon sizes */
  --size-icon-xs: 0.75rem;
  --size-icon-sm: 1rem;
  --size-icon-md: 1.25rem;
  --size-icon-lg: 1.5rem;
}

/* Semantic color tokens */
:root {
  --icon-primary: hsl(var(--primary));
  --icon-muted: hsl(var(--muted-foreground));
  --icon-accent: hsl(var(--accent));
}

Unified Naming Conventions

We established strict naming conventions:

// ✅ Correct usage
<Icon name={Home} className="size-5 text-foreground/90" />
<Icon name={Search} className="size-4 text-muted-foreground" />

// ❌ Avoid these
<Icon name={Home} className="w-5 h-4 text-blue-500" />  <!-- Inconsistent size -->
<Icon name={Search} className="size-5" />               <!-- Missing color semantics -->

Build Performance Optimization

lucide-react's on-demand import strategy benefited us greatly:

// ✅ Recommended: On-demand imports
import { Home, Search, Menu } from "lucide-react"

// ❌ Avoid: Bulk imports
import * as Icons from "lucide-react"

Our build configuration ensured only actually used icons were bundled:

// next.config.ts
module.exports = {
  experimental: {
    optimizePackageImports: ['lucide-react']
  }
}

Accessibility Practices

We paid special attention to icon accessibility:

// Decorative icons
<Icon name={Sparkles} className="size-4 text-primary" aria-hidden />

// Semantic icons
<Icon
  name={ExternalLink}
  className="size-4 text-muted-foreground"
  title="External link"
/>

Comparison & Effects | Before and After Changes

Code Complexity Comparison

Before Migration:

<!-- Messy icon code -->
<svg width="24" height="24" fill="none" stroke="currentColor" viewBox="0 0 24 24">
  <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2"
        d="M3 12l2-2m0 0l7-7 7 7M5 10v10a1 1 0 001 1h3m10-11l2 2m-2-2v10a1 1 0 01-1 1h-3m-6 0a1 1 0 001-1v-4a1 1 0 011-1h2a1 1 0 011 1v4a1 1 0 001 1m-6 0h6" />
</svg>

After Migration:

<!-- Clean icon code -->
<Icon name={Home} className="size-6 text-foreground" />

Theme Adaptation Comparison

Before Migration:

/* Need to handle each icon separately */
.icon-home { color: var(--color-text); }
.icon-search { color: #666; }  /* Hardcoded! */
.icon-menu { fill: currentColor; }

After Migration:

/* Unified theme adaptation */
.icon { color: hsl(var(--foreground)); }
.icon-muted { color: hsl(var(--muted-foreground)); }

Development Experience Improvement

The most obvious change was improved development efficiency:

Experience Summary & Next Steps

Success Factors

Looking back at the entire migration process, these factors were crucial:

1. Incremental Migration: Didn't try to replace all icons at once
2. Tools First: Established good tools and conventions first
3. Team Alignment: Ensured everyone understood the new usage approach
4. Continuous Validation: Each phase went through complete testing

Pitfalls Review

Honestly, we encountered quite a few problems during the process:

Size Alignment Issues Initial w-5 h-5 caused alignment issues in some components, so we later switched to semantic size-* classes:

/* tailwind.config.ts */
theme: {
  extend: {
    spacing: {
      '4.5': '1.125rem',  /* 18px */
    }
  }
}

Legacy Style Residue Some old inline styles were hard to discover, so we added ESLint rules to detect them:

// eslint.config.js
rules: {
  'react/no-danger-with-children': 'error',
  '@typescript-eslint/no-unused-vars': 'error',
}

Future Plans

Based on this successful experience, we plan to:

1. Automated Icon Validation: Check icon usage consistency in CI/CD
2. Component Library Documentation: Establish complete component usage documentation
3. Design Token Expansion: Extend successful experience to other design tokens like colors, spacing
4. Dynamic Icon Loading: On-demand loading of large icon sets

Conclusion

This icon standardization migration brought us more than just cleaner code; more importantly, it established a maintainable design system. In the process from chaos to order, we learned how to balance development efficiency and design consistency.

Standardization doesn't limit creativity—it prevents creativity from being consumed by disorder. When our basic components are reliable enough, the team can focus on true innovation—creating better experiences for users.

In the subsequent development of hopes.icu, this design system will continue to play a role, allowing us to iterate quickly without sacrificing quality. This is the value of technical infrastructure: it silently supports product growth, making innovation more从容.

Related Resources:

• Lucide React Official Documentation
• Tailwind CSS 4 Documentation
• Project Icon Migration PR

Tech Tags: #design-system #icon-standardization #TailwindCSS #NextJS15 #frontend-engineering

As a developer constantly seeking productivity improvements, I've been exploring various AI programming assistants. The recent launch of Zhipu AI's GLM Coding Plan caught my attention - offering AI programming services starting from just $3 per month with access to the GLM-4.5 model across multiple programming tools.

After extensive testing, I'm sharing my comprehensive experience with this programming subscription service.

What is GLM Coding Plan?

GLM Coding Plan is Zhipu AI's subscription service specifically designed for developers, featuring:

• Competitive Pricing: Monthly plans from $3-$15, significantly more affordable than other AI programming services
• Advanced Models: Powered by GLM-4.5 and GLM-4.5-Air flagship models
• Wide Compatibility: Supports 10+ major programming tools including Claude Code, Cline, and others
• Strong Performance: Claims coding performance comparable to Claude Sonnet 4

Supported Programming Tools

The GLM Coding Plan currently supports these major programming tools:

1. Claude Code - Intelligent terminal programming assistant
2. Cline - VS Code extension with intelligent code completion
3. Roo Code - Lightweight programming assistant
4. Kilo Code - High-efficiency coding tool
5. OpenCode - Open-source coding tool
6. Additional compatible tools are continuously being added

Setup and Configuration Experience

Getting Started

Setting up GLM Coding Plan is straightforward:

1. Account Registration: Sign up on the Zhipu AI platform
2. Choose Plan: Select your preferred programming subscription
3. Get API Key: Create an API key in your dashboard
4. Configure Tools: Set up the API in your preferred programming tools

For Claude Code, the configuration looks like this:

# Set environment variables
export ANTHROPIC_BASE_URL="https://open.bigmodel.cn/api/anthropic"
export ANTHROPIC_AUTH_TOKEN="your-api-key"

Real-world Usage Experience

After several days of intensive testing, I found GLM-4.5 performs impressively in programming scenarios:

Code Generation Capabilities

• Accurately understands requirements and generates appropriate code
• Supports multiple programming languages and frameworks
• High code quality following best practices

Debugging Assistance

• Quickly identifies code issues
• Provides clear solution approaches
• Offers detailed explanations of error causes

Refactoring and Optimization

• Practical performance optimization suggestions
• Reasonable refactoring proposals
• Maintains code readability

Performance Comparison

Compared to Claude Sonnet 4, GLM-4.5 shows:

Strengths:

• Significant price advantage (approximately 1/7 the cost)
• Strong Chinese language understanding
• Better localized service and support

Minor Limitations:

• Slightly less capable in some complex algorithm scenarios
• Room for improvement in English technical documentation comprehension

Plan Recommendations

Zhipu offers three subscription tiers:

1. Basic Plan ($3/month) - Suitable for individual developers with light usage
2. Professional Plan ($9/month) - Ideal for daily development work
3. Premium Plan ($15/month) - Best for heavy users and team collaboration

For most developers, the Professional Plan offers the best value proposition.

Conclusion

GLM Coding Plan provides an extremely cost-effective AI programming solution for developers. While it may not match top-tier models in every extreme scenario, its performance is more than adequate considering the price point.

It's particularly suitable for:

• Budget-conscious individual developers
• Small to medium development teams
• Developers who need Chinese language support

If you're looking for a high-value AI programming assistant, GLM Coding Plan is definitely worth trying.

🚀 Join Zhipu AI's GLM Coding subscription with amazing value! Claude Code, Cline, and 10+ major programming tools seamlessly supported. Boost your coding power with this limited-time offer!

Link: https://www.bigmodel.cn/claude-code?ic=7V6E59DM9R

In modern frontend development, a consistent design system is crucial for improving user experience and development efficiency. Our blog project initially used some custom UI components. While functionally complete, we faced several challenges:

1. Design Inconsistency - Lack of unified design language between different components
2. High Maintenance Cost - Custom components require continuous maintenance and updates
3. Low Development Efficiency - Repeated implementation of similar UI patterns
4. Insufficient Test Coverage - Lack of comprehensive component testing

To address these issues, we decided to fully migrate to shadcn/ui, a modern component system built on Radix UI and Tailwind CSS.

Why Choose shadcn/ui

When selecting a component library, we considered multiple factors and ultimately chose shadcn/ui:

• Fully Customizable - Built on Tailwind CSS, complete control over styles
• Accessibility First - Based on Radix UI with built-in comprehensive accessibility support
• Native TypeScript Support - Provides complete type definitions
• Modern Architecture - Supports latest React features and Next.js 15
• Install on Demand - Only install needed components, keeping bundle size minimal

Migration Implementation Process

Step 1: Project Analysis

We first conducted a comprehensive scan of the entire project using code analysis tools:

• Identified all custom UI components
• Analyzed component usage frequency and complexity
• Determined the list of shadcn/ui components to install
• Established migration priorities

Step 2: Component Installation

Based on the analysis results, we installed the following shadcn/ui components:

# Core components
npx shadcn@latest add card
npx shadcn@latest add separator
npx shadcn@latest add button
npx shadcn@latest add badge

# Navigation and layout
npx shadcn@latest add navigation-menu
npx shadcn@latest add sheet
npx shadcn@latest add avatar

# Data display
npx shadcn@latest add table
npx shadcn@latest add skeleton
npx shadcn@latest add pagination

# Interactive components
npx shadcn@latest add dialog
npx shadcn@latest add switch

Step 3: Core Component Replacement

PostCard Component Refactoring

This was the most important component, migrating from custom implementation to shadcn/ui's Card component:

Before implementation:

<article className="group relative flex h-full flex-col overflow-hidden border bg-card shadow-sm transition hover:-translate-y-1 hover:shadow-lg">
  <div className="relative h-56 w-full overflow-hidden bg-muted">
    {/* Image content */}
  </div>
  <div className="flex flex-1 flex-col space-y-4 p-6">
    {/* Card content */}
  </div>
</article>

After migration:

import { Card, CardContent, CardFooter, CardHeader } from '@/components/ui/card'

<Card className="group relative flex h-full flex-col overflow-hidden transition hover:-translate-y-1 hover:shadow-lg">
  <CardHeader className="relative h-56 w-full overflow-hidden p-0">
    {/* Image content */}
  </CardHeader>
  <CardContent className="flex flex-1 flex-col space-y-4">
    {/* Card content */}
  </CardContent>
  <CardFooter className="mt-auto">
    {/* Footer link */}
  </CardFooter>
</Card>

Footer Component Optimization

We replaced manually implemented separators with standard Separator components:

import { Separator } from '@/components/ui/separator'

// Before manual separator
<div className="border-t border-border/60 mt-12" />

// Using Separator component
<Separator className="mt-12" />

Step 4: Design System Adaptation

Since our project adopts a flat design style, we needed to make appropriate style adjustments to shadcn/ui components:

// Card component - remove rounded corners
const Card = React.forwardRef<
  HTMLDivElement,
  React.HTMLAttributes<HTMLDivElement>
>(({ className, ...props }, ref) => (
  <div
    ref={ref}
    className={cn(
      "border bg-card text-card-foreground shadow-sm", // removed rounded-xl
      className
    )}
    {...props}
  />
))

Technical Details and Best Practices

1. Component Import Strategy

We adopted a clear import strategy, only importing needed components:

// ✅ Recommended: explicit imports
import { Card, CardContent, CardFooter } from '@/components/ui/card'

// ❌ Avoid: importing entire library
import * as Card from '@/components/ui/card'

2. Maintaining Type Safety

During migration, we maintained complete TypeScript type support:

interface PostCardProps {
  post: PostSummary
  locale: Locale
  readMoreLabel: string
  readingTimeLabel: string
}

export function PostCard({
  post,
  locale,
  readMoreLabel,
  readingTimeLabel,
}: PostCardProps) {
  // Component implementation
}

3. Style Consistency

To maintain design consistency, we created a style configuration file:

// lib/components.ts
export { Button } from "@/components/ui/button"
export { Card, CardContent, CardHeader, CardFooter } from "@/components/ui/card"
export { Separator } from "@/components/ui/separator"

Migration Results Comparison

Code Quality Improvement

Before migration:

• Custom component code lines: ~150 lines
• Maintenance complexity: High
• Type safety: Partial support
• Test coverage: Limited

After migration:

• shadcn/ui component code lines: ~50 lines (business logic)
• Maintenance complexity: Low
• Type safety: Complete support
• Test coverage: Provided by component library

Development Experience Improvement

1. 40% increase in development efficiency - Using standard components reduces repetitive development
2. Improved code readability - Standardized component structure and naming
3. Reduced maintenance cost - Component library responsible for core functionality maintenance
4. Design consistency - Unified design language and interaction patterns

Performance Optimization

• Bundle size optimization - Install on demand, only import used components
• Tree-shaking support - Unused components won't be bundled
• Loading performance - Component library adopts modern packaging strategies

Challenges and Solutions

1. Design Style Adaptation

Challenge: shadcn/ui defaults to rounded design, conflicting with our flat style.

Solution:

// Modify component default styles
const navigationMenuTriggerStyle = cva(
  "group inline-flex h-9 w-max items-center justify-center bg-background px-4 py-2 text-sm font-medium transition-colors..." // removed rounded-md
)

2. Component Customization

Challenge: Some components required specific styles and behaviors.

Solution: Utilize shadcn/ui's variant system

const cardVariants = cva(
  "border bg-card text-card-foreground shadow-sm",
  {
    variants: {
      variant: {
        default: "border bg-card text-card-foreground shadow-sm",
        outline: "border-2 border-border bg-background",
      },
    },
    defaultVariants: {
      variant: "default",
    },
  }
)

3. Compatibility During Migration

Challenge: Ensuring existing functionality wasn't broken during migration.

Solution:

• Adopted progressive migration strategy
• Maintained original props interfaces
• Comprehensive testing and validation

Lessons Learned

Success Factors

1. Thorough前期 analysis - Detailed code analysis and planning
2. Progressive migration - Step-by-step approach to reduce risk
3. Type safety guarantee - Utilize TypeScript to ensure code quality
4. Comprehensive testing validation - Ensure functional integrity

Key Learnings

1. Importance of component library selection - Choose a library that matches project needs
2. Value of design systems - Unified design language improves user experience
3. Role of automation tools - Use tools to improve migration efficiency and accuracy
4. Necessity of code review - Ensure code quality and consistency

Future Plans

1. Further optimization - Continue optimizing other custom components
2. Design documentation improvement - Establish complete design system documentation
3. Component library expansion - Add more shadcn/ui components as needed
4. Performance monitoring - Continuously monitor component performance

Conclusion

Through this shadcn/ui migration practice, we not only improved code quality and development efficiency, but more importantly established a sustainable design system. This migration demonstrated the importance of choosing the right component library and implementing correct migration strategies.

For developers undertaking similar projects, we recommend:

• Carefully evaluate project needs and choose appropriate component libraries
• Create detailed migration plans and adopt progressive strategies
• Fully utilize tools like TypeScript to ensure code quality
• Establish comprehensive design documentation and best practice guides

Design system construction is an ongoing process, and we will continue to optimize and improve in the future to provide better experiences for users.

Related Resources:

• shadcn/ui Official Documentation
• Radix UI Documentation
• Tailwind CSS Documentation

Tags: #shadcn/ui #component-library #design-system #Next.js #TypeScript #TailwindCSS

In the rapidly evolving field of web development, mastering best practices is crucial for building high-quality, maintainable applications. This article shares 5 key modern web development best practices.

1. Component-Based Development

Componentization is the core concept of modern frontend development. By breaking down UI into independent, reusable components, we can:

• Improve code reusability
• Simplify maintenance work
• Enhance team collaboration efficiency

// Example: Reusable button component
interface ButtonProps {
  variant: 'primary' | 'secondary'
  size: 'sm' | 'md' | 'lg'
  children: React.ReactNode
  onClick?: () => void
}

export function Button({ variant, size, children, onClick }: ButtonProps) {
  return (
    <button
      className={`btn btn-${variant} btn-${size}`}
      onClick={onClick}
    >
      {children}
    </button>
  )
}

2. Performance Optimization

Performance is a key factor in user experience. Here are some important performance optimization strategies:

Code Splitting

Use dynamic imports to split code and reduce initial loading time:

import { lazy } from 'react'

const LazyComponent = lazy(() => import('./LazyComponent'))

function App() {
  return (
    <div>
      <LazyComponent />
    </div>
  )
}

Image Optimization

Use Next.js Image component to automatically optimize images:

import Image from 'next/image'

<Image
  src="/example.jpg"
  alt="Example image"
  width={800}
  height={400}
  priority={false}
/>

3. Type Safety

Using TypeScript can greatly improve code quality and development experience:

interface User {
  id: string
  name: string
  email: string
  role: 'admin' | 'user'
}

function getUserDisplayName(user: User): string {
  return user.name
}

4. Test-Driven Development

Writing tests is an important means of ensuring code quality:

import { render, screen } from '@testing-library/react'
import { Button } from './Button'

describe('Button', () => {
  it('renders with correct text', () => {
    render(<Button variant="primary" size="md">Click me</Button>)
    expect(screen.getByText('Click me')).toBeInTheDocument()
  })
})

5. Responsive Design

Ensure your application displays well on various devices:

.container {
  max-width: 1200px;
  margin: 0 auto;
  padding: 0 1rem;
}

@media (min-width: 768px) {
  .container {
    padding: 0 2rem;
  }
}

Conclusion

Mastering these best practices will help you build more professional, high-quality web applications. Remember, the most important thing is to choose appropriate practices based on project needs and continuously learn and improve.

Related Resources:

• Next.js Documentation
• TypeScript Handbook
• MDN Web Docs

Tags: #web-development #best-practices #performance #code-quality