Part A: The Gate That Isn't One
As of July 10, 2026, the private essay at junochen.com/what-do-you-count.html delivers its full HTML content on HTTP 200 before any client-side password overlay fires. The strategic pricing analysis, the reasoning, the complete document ships in the response body. The overlay is cosmetic. The gate is not a gate.
This is a portfolio architecture failure. And it is the specific kind that contradicts the central argument your own work is making.
The buyer who will find this
Picture who you're positioning for. A CPO at a frontier AI company. An engineering leader evaluating whether your design thinking survives contact with technical reality. They received your outreach. It was precise. They clicked through.
This person opens dev tools the way you open Figma. Reflexively, the way they check anything. They see the overlay, view source, and find everything behind it already loaded, fully rendered in the DOM, waiting for a password check that runs entirely in the browser.
Now they read your Trust essay. They hit the Decision Gate framework. They read your argument that every loop boundary should be treated as a designed gate with enough context for a real decision. They absorb the five-handoff model: "Automate what you can verify. Keep a human where the outcome is irreversible." They read that the Thermo Fisher regulatory release was "non-negotiable" as a human checkpoint.
Then they remember what they just saw on the private essay page. A gate that verifies nothing server-side. A human checkpoint that fires after the content has already been delivered. An access-control pattern that is, by your own published framework, neither automated verification nor a meaningful human decision point.
The site just made an argument you didn't author:
"She writes about trust architecture but doesn't apply it to her own systems."
Why this specific contradiction is expensive
At Director+ level, buyers already believe you can do the work. What they're evaluating is whether your judgment holds in the margins, in the places where nobody is grading you. A technically literate hiring committee will read this as a judgment gap. The portfolio argues for systems where gates are structural. The site implements a gate as a CSS overlay on top of content already shipped to the browser.
The severity is highest on the private essay because you explicitly chose to gate that page. You made a decision that this content warranted restricted access. Then you implemented the restriction in a way that restricts nothing.
The Trust essay is the strongest piece on your site. It is the thing that makes a buyer believe you think architecturally about human-system boundaries. Every minute that essay coexists with a client-side-only gate on the same domain, the essay's credibility depreciates.
Same pattern, lower severity, same risk
The five full case study pages (Alibaba, Thermo Fisher, Red Cross, Equinox+, Allē) use a related approach. They check localStorage for an access flag and redirect to a shared login page if it's absent. Same password-hash ecosystem, same pf_access_v1 storage key. But they also return HTTP 200 with full case content in the response body before the client-side redirect fires.
The redirect is marginally better than the inline overlay because a casual visitor gets bounced before they read. The content is still in the response. A buyer who knows how HTTP works sees the same structural gap. Worth flagging. The private essay is the P0. The case studies are the P1.
Fix sequence
P0: Server-side gating on the private essay. Move the access check to the server. The page should return a 401 or 403 with a login form. The protected content should not exist in the response body until authentication succeeds. Your site is served by Vercel, which supports edge middleware that can intercept the request before HTML is generated. Use it. Note: this means the current approach of hashing a password in client-side JavaScript and checking it against a stored hash won't carry over. The credential model itself has to move server-side, not just the check. This is a same-week fix.
P1: Server-side gating on the five case study pages. Same principle. Keep the redirect-to-login UX flow. But the case content should not ship in the initial response. Serve a shell page that fetches content after authentication, or gate at the edge. Same mechanism as P0, applied five more times.
P2: Audit the localStorage credential model. A single shared key (pf_access_v1) means one successful login unlocks every gated page permanently, across sessions, with no expiry. Decide whether that's the access model you want. If the private essay warrants a gate, it probably warrants a gate that can be revoked.
Do not let your own site be the counterexample to your best argument.