标签：#EV

Most AEO/GEO advice hands you a checklist: add structured data, write answer-first, put a date on it, get a score. You do all of it, and the AI answer still quotes someone else. The checklist skipped the only question that decides the outcome first: for this particular query, can an independent site get cited at all? Getting cited by ChatGPT, Perplexity, or Google's AI Overviews is a two-stage funnel, and the stages fail for completely different reasons. Grade your page without knowing which stage you're stuck at and you'll spend a day tuning headings on a page that was never eligible. Here's the model, and how to run the check yourself before you touch the formatting. Stage 1: eligibility — can the engine retrieve you at all? Answer engines are retrieval-augmented. Before anything gets generated, a retriever picks a small set of candidate pages. If you're not in that set, nothing about your writing matters. Three things decide it, and only some are visible in your HTML. The part you can check on-page — the hard disqualifiers: noindex . A <meta name="robots" content="noindex"> (or an X-Robots-Tag header) keeps you out of the indexes these engines lean on. Easy to ship by accident on a templated page. AI crawlers blocked in robots.txt . GPTBot, PerplexityBot, ClaudeBot, and Google-Extended are distinct user agents. A Disallow: / for any of them means that engine can't fetch you even if Googlebot can. Check each one by name: curl -s https://example.com/robots.txt | grep -iA2 -E 'GPTBot|PerplexityBot|ClaudeBot|Google-Extended' Content that only exists after JS runs. If your article body is injected client-side and the server returns an empty shell, a fetch-based crawler sees nothing. Compare raw HTML to rendered: curl -s https://example.com/post | grep -c "a distinctive sentence from your article" Zero means your content isn't in the served HTML. Server-render it or pre-render it. The part you cannot check on-page — and this is where honesty matters — is domain authori

TL;DR 23 commits across 4 repos, one theme: opening apps to the outside world, safely. Public: kickoff v1.32.0 ships SDK-free support-widget integration stubs. Private: external intake channels (token-authed API, cookie-free widget, signed webhooks) on a helpdesk product; signed public API + rebuild webhooks on an event platform. Everything today was about external surfaces — letting the outside in without leaving the door unlocked. What shipped Where What kickoff v1.32.0 (public) SDK-free support-widget integration stubs: settings class + migration, Livewire admin settings page, Blade component, docs, Pest coverage Helpdesk product (private) External intake channels: token-authed API, magic-link requester view, cookie-free embeddable widget, signed outbound webhooks, hardening pass from an adversarial review Event platform (private) Signed public event API + landing-page rebuild webhooks, persona nav overhaul, 15 new MCP tools, offline PWA check-in, plan-limit enforcement Event platform docs (private) Tracker updates + before/after UX screenshots Stubs, not SDKs kickoff now ships a support-widget integration as stubs — settings class, migration, admin page, Blade component — copied into your app. No composer dependency for glue code: you own it, you can read it, you can change it. For ~100 lines of integration code, a stub beats a package. Intake is three problems The helpdesk work was the day's core: letting outside systems and end users create tickets. Every inbound surface splits into the same three problems — who gets in (token auth, magic links), what they can do (rate limits, severity clamps, single-use entry), and what you send back out (signed, idempotent webhooks). An adversarial review caught four real issues before launch; that story gets its own post, next. Static pages, fresh data The event platform got a signed public API plus webhooks that fire on content changes — so landing pages can be static builds that rebuild themselves when an event changes. C

TL;DR Built an embeddable support widget for a helpdesk product: no cookies — a short-lived bearer token in a header, hashed at rest. Entry is an HMAC-signed assertion from the host page. An adversarial review caught four real holes before launch. Outbound webhooks: sign the exact bytes, dedupe key for idempotency, SSRF guard on destination URLs. The requirement: end users file tickets from pages the product doesn't own. That means an embeddable widget — and embeddable means everything you know about sessions stops working. Why cookie-free The widget lives on customers' domains, so any cookie it sets is a third-party cookie — blocked or partitioned by modern browsers. Fighting that means flaky sessions, so: no cookies at all. The entry exchange mints a short-lived session token the widget sends in a header, and the server caches the session keyed by sha256(token) — a cache dump yields nothing replayable. Sessions last 60 minutes, and expiry shows a real recovery path in the UI instead of dying silently. customer backend widget (on customer page) helpdesk API | signs ref|email|name | | | into HMAC assertion ---> |-- redeem assertion (single use) ->| | |<-- session token (60-min TTL) ---| | |-- X-Widget-Token: ... ---------->| What the adversarial review caught Finding Fix Replay burn keyed by client-chosen nonce Burn by HMAC signature — a leaked assertion can't mint extra sessions `\ ` accepted inside signed fields Origin check failed open when Origin/Referer absent Fall back to the unspoofable Sec-Fetch-Dest header to enforce embedding Widget could request critical severity Clamp effective severity (including the channel default) to the widget's allowlist My favourite is the delimiter one. If you sign ref|email|name and accept | inside a field, two different identity tuples can share one valid signature. Canonicalization bugs, not crypto bugs. Webhooks out: sign the exact bytes Outbound webhooks get composed once at enqueue time and stored; the delivery job re-encod

In the first article of this series, we saw how a custom build-time compiler can transform a legacy Angular.js template into raw, optimized JavaScript. To recap, starting from this template: <!-- simple.html --> <p> Hello {{ name }}! </p> Our Go compiler generates the following JavaScript module: // simple.js export function template () { const p_0 = document . createElement ( " p " ); const text_1 = document . createTextNode ( "" ); p_0 . append ( text_1 ); return { mount ( container ) { container . append ( p_0 ); }, update ( change ) { if ( " name " in change ) { text_1 . data = " Hello " + change . name + " ! " ; } } } } This is incredibly clean. By running template() , we get an object with mount and update methods. Using mount is fully intuitive: we pass a reference to a DOM element, and it injects our empty paragraph ( p_0 ) into it: import { template } from ' ./simple.js ' ; const { mount , update } = template (); const container = document . getElementById ( ' view-container ' ); mount ( container ); // The DOM now contains: <p></p> (waiting for data) However, the paragraph remains empty until we call update with a change object like this: let changes = { name : " Mario " , }; update ( changes ); // The DOM surgically updates to: <p>Hello Mario!</p> But who is responsible for tracking changes in our application state, building this changes object, and calling update ? The answer lies in marrying the legacy Angular.js $scope with the modern JavaScript Proxy API . The Legacy State Pattern In a traditional Angular.js application, developers mutate the state directly inside a controller by assigning properties to the $scope object: // simple-controller.js export function SimpleController ( $scope ) { $scope . name = " Mario " ; } To bridge the gap between this legacy controller and our new build-time template, we need a way to automatically capture the assignment $scope.name = "Mario" and translate it into a structured update: let changes = { name : " Mario " }

Here's the failure mode I keep running into. A team gives a coding agent a repo, a task, and maybe a README. The agent can find files and write code, but it still has to guess the operating rules. It guesses the package manager. It guesses which checks matter. It guesses whether generated files are safe to edit. It guesses what "done" means. A README is usually for humans: what the project is, how to run it, and where the important docs live. A coding agent needs different context. Setup rules. Test commands. Boundaries. Completion criteria. That's the gap AGENTS.md fills. The official AGENTS.md guidance describes it as a predictable place for coding-agent instructions: setup commands, test commands, code style, security considerations, and nested instructions for large monorepos. I find the split useful in a more boring way. The README answers, "What is this project?" AGENTS.md answers, "What should an agent know before touching it?" That second question is where the work usually gets fragile. Where Goose Fits Goose makes this less theoretical because it isn't just a chat box. It's an open source local AI agent with a desktop app, CLI, API, MCP extensions, and skills. Without AGENTS.md , I find myself writing prompts like this: Update the docs, but don't touch generated files, use pnpm, run the lint and test commands, keep the PR small, and tell me what you couldn't verify. With AGENTS.md , the prompt can get shorter: Update the quickstart docs for the new config flag. Goose can run the task in the repo. The repo can carry the standing instructions. I noticed this on a small docs/config update where generated files sat near source files. Without repo instructions, the prompt had to carry the package manager, generated-file boundary, checks, and the "tell me what you could not verify" rule. Once those rules lived in AGENTS.md , the prompt became just the task. Not magic. Just fewer chances to forget the boring parts. Where Skills Fit I would add one more layer once

Website performance is no longer just a nice-to-have feature—it's a critical factor for user experience, SEO, and business success. Even a one-second delay in page load time can reduce conversions and increase bounce rates. Whether you're building a portfolio, SaaS application, eCommerce platform, or business website, these optimization techniques can make a significant difference. Optimize Images Images are often the largest assets on a webpage. Use modern formats like AVIF or WebP, compress images, and serve responsive image sizes to reduce bandwidth usage. Self-Host Fonts Third-party font requests add latency. Self-hosting fonts, preloading critical font files, and serving only the required character subsets can dramatically improve loading performance. Remove Unused CSS & JavaScript Shipping unnecessary code increases download size and execution time. Tree shaking, code splitting, and removing unused styles help keep your bundle lean. Enable Caching Configure long-term browser caching for static assets and use hashed filenames for cache busting. This allows returning visitors to load your website much faster. Use Lazy Loading Images, videos, and iframes that aren't immediately visible should load only when needed. Native lazy loading is supported by modern browsers and is easy to implement. Optimize Core Web Vitals Google's Core Web Vitals measure how users experience your website. Focus on: Largest Contentful Paint (LCP) Interaction to Next Paint (INP) Cumulative Layout Shift (CLS) Improving these metrics benefits both SEO and user satisfaction. Minify Assets Minify HTML, CSS, and JavaScript files before deployment. Smaller files transfer faster and improve overall performance. Use a CDN Serving assets from edge locations around the world reduces latency and improves loading times for global visitors. Prioritize Accessibility Accessible websites provide a better experience for everyone and often align with SEO best practices. Use semantic HTML, descriptive labe

"Docker vs Kubernetes" is one of those framings that quietly sends people down the wrong road. It sounds like a choice between two competing tools, so teams treat it like a bake-off. It isn't. Docker builds and runs containers. Kubernetes orchestrates a fleet of them. You can happily use one without the other, and most teams should — at least for a while. The question that actually matters is hiding underneath: do I need an orchestrator yet? That's the one worth thinking about carefully, because the cost of answering "yes" too early is real, and it mostly shows up later, on a Saturday, when you're the one holding the pager. What each tool actually does Let me separate the two cleanly, because the confusion causes most of the bad decisions. Docker (or any OCI-compatible runtime — Podman, containerd, and friends) does two jobs: it builds an image from a Dockerfile , and it runs that image as a container on a host. That's the unit of packaging. When you type this: docker build -t registry.example.com/myapp:1.4.2 . docker run -d -p 8080:8080 registry.example.com/myapp:1.4.2 you've packaged your app and started it on one machine . If that machine dies, your app dies with it. If you need three copies, you start three by hand. If you push a bad image, you roll it back by hand. Kubernetes doesn't build or run containers itself — it schedules them across a set of machines and keeps them in the state you declared. You tell it "I want three replicas of myapp:1.4.2 , behind a stable network name, and if a node dies, reschedule them." Kubernetes then spends its life making reality match that declaration. So they're not competitors. Kubernetes runs your Docker-built images. The real comparison isn't "Docker vs Kubernetes" — it's "a couple of containers on a host I manage" versus "a control plane that manages containers for me." A small, honest comparison Concern Plain Docker (or Compose) Kubernetes Where it runs One host you manage A cluster of nodes If a node dies You notice and

If you're comfortable with docker compose up , you already understand more of Kubernetes than you think. Compose taught you to describe an application declaratively — services, their images, their config, how they talk to each other — instead of running containers by hand. Kubernetes is the same instinct, scaled out across a cluster, with more moving parts because it's solving a harder problem: keeping that application running when machines fail. The good news is the mental model transfers. The honest news is that the operational surface grows, and it's worth knowing exactly what changes before you commit. Let me map the concepts you already know onto their Kubernetes equivalents, show the YAML side by side, and be straight about the parts that get harder. First, the thing that doesn't change: your images This trips people up, so let's clear it early. The Docker images you already build run on Kubernetes unmodified. Kubernetes doesn't use the Docker daemon to run them — most clusters use containerd or CRI-O — but every one of those runtimes runs standard OCI images. That's the whole point of the OCI standard: the image you built with docker build is the same artifact the cluster pulls and runs. docker build -t registry.example.com/myapp:1.4.2 . docker push registry.example.com/myapp:1.4.2 That image works identically whether docker run starts it or a Kubernetes node's containerd does. So the packaging is settled. What changes is everything around the container. The concept map Here's the translation table I'd keep next to you while you learn: Docker Compose Kubernetes What changed service Deployment + Service Running vs. reachable are now two objects image: spec.containers[].image Same OCI image ports: Service (+ Ingress for external) Networking is explicit and named depends_on: probes / initContainers Ordering becomes health, not sequence environment: / .env ConfigMap / Secret Config decoupled from the pod volumes: PersistentVolume / PVC Storage is claimed, not jus

"Works on my machine" is one of the oldest jokes in software, and it stopped being funny the first time it cost me a weekend. The code was fine. The environment wasn't. A library version on the build box didn't match production, and nobody could see it because "the environment" was a fuzzy, undocumented thing that lived partly in a config management tool, partly in someone's .bashrc , and partly in tribal memory. Containerization is the boring, durable fix for that whole class of problem. Not because containers are magic, but because they force you to turn a fuzzy environment into a single, inspectable, reproducible artifact. That shift — from "a machine we hope is configured right" to "an image we can point at" — is the actual win. Let me walk through what that means operationally, with a minimal example. What containerization actually solves Strip away the tooling and a container image is one thing: your application plus everything it needs to run, packaged together and frozen. The OS libraries, the runtime, the dependencies, your code — all captured at build time into one immutable blob with a content-addressable identity. That has three consequences that matter when you're the one on call: The environment stops being a variable. If it runs from image myapp:1.4.2 in staging, the same image runs in production. You're no longer debugging the difference between two machines. The artifact is immutable. You don't patch a running container in place and hope. You build a new image, tag it, and roll it out. The old one still exists, unchanged, if you need to go back. Rollback becomes trivial. "Roll back" means "run the previous image tag." That's it. No reinstalling packages, no un-applying config drift. After enough years in operations, you learn that most 3 a.m. incidents aren't exotic. They're some version of "this box isn't like the other boxes." Containers don't make you smarter, but they take that entire category off the table. Images vs. containers, briefly These

This is the story of a for-fun project, Luka Fit Index that started with me typing "ai for fun?...

🎮 I Built a Free Browser Gaming Platform – FizGame Over the past few weeks, I've been working on a side project called FizGame, a free browser gaming platform where anyone can instantly play HTML5 games without downloads or installations. 🌐 Website: FizGame Why I Built It I wanted to create a simple platform where players can: 🎮 Play instantly in their browser 🚫 No downloads or installations 📱 Play on both desktop and mobile ⚡ Fast loading experience Current Features Hundreds of HTML5 games Mobile-friendly design Instant game loading Categories like Puzzle, Action, Arcade, Racing, and Casual Search and game discovery Responsive UI Tech Stack PHP Symfony MySQL HTML5 Games JavaScript CSS Nginx Current Focus I'm currently working on: Better SEO Faster page speed AI-generated game descriptions Improved game recommendations Daily game publishing Social media automation Biggest Challenge One of the hardest parts isn't building the website—it's helping people discover it. I'm experimenting with: YouTube Shorts Instagram Reels Facebook Reels Pinterest Organic SEO If you've built a gaming website before, I'd love to hear what worked best for you. Feedback Welcome I'd appreciate any feedback on: UI/UX Performance Navigation SEO Features you'd like to see 🎮 Check it out: FizGame Thanks for reading! 🚀

Week 16 shipped the AI background remover: Rust-native, ort + ISNet + libvips, no Python. That was the feature. Week 17 was not about writing more of it. It was about the boring, high-leverage part that most side projects skip: turning one working feature into pages that can actually rank, and wiring those pages together so search engines can find them. No new engine code this week. Just leverage on what already existed. Here is what that actually looked like. The problem: a hub with nothing pointing at it The background remover lives at /remove-background . That is the hub. The plan was classic hub-and-spoke: one general tool page, then use-case spokes that each target a specific intent (removing a signature background, prepping an Amazon product photo, and so on). I built two spokes this week. But halfway through, I looked at how internal links actually worked on the site and found the real problem: nothing linked from the hub to the spokes. The spokes linked back to the hub in their body text, but the hub had no idea they existed. Neither did the ~180 converter pages. Tool links on the site were hardcoded in a frontend constant, roughly: export const IMAGE_TOOLS = [ { label : " Compress JPG " , href : " /compress/jpg " , tool : " compress " }, { label : " Resize Image " , href : " /resize-image " , tool : " resize " }, { label : " Crop Image " , href : " /crop-image " , tool : " crop " }, { label : " Images to PDF " , href : " /images-to-pdf " , tool : " convert " }, ] as const ; That list covered the converter tools. It did not include the background remover or its spokes at all. So the new pages were orphans: reachable only through the sitemap, with no internal links carrying any signal to them. For a domain that is still young and still earning Google's trust, orphan pages get discovered slowly and rank even slower. The fix: one constant as the source of truth Instead of hardcoding links in three different places, I made a single constant describe the whole cl

Introduction Building Reliable LLM Applications in Python put it plainly: treat model output as a hypothesis to verify, not a fact to trust. Testing Best Practices in Python put the same discipline in pytest terms: a suite only earns trust by asserting the right things at the right level, unhappy paths included. This post is where those two ideas meet — a pytest assertion either passes or fails against a fixed expected value; an LLM's output is a paragraph of prose that might be right in spirit while differing token-for-token from anything you wrote down in advance. Evaluating it takes a harness, not an assert . That harness has three parts: a golden dataset of representative cases with known-good expected behavior, scoring that turns each case into a pass/fail or a number, and regression testing that runs the harness on every change and fails the build when the score drops. Making RAG Accurate in Python already gave you half of this story — recall@k, precision@k, MRR, nDCG measure whether retrieval found the right chunks. This post measures the other half: whether the generated answer built from those chunks is actually good, which is a genuinely different question a retrieval metric can't answer on its own. Everything below is illustrative, non-executed Python, grounded in the same Anthropic SDK shapes as posts 10/11. The Golden Dataset: Curating Cases, Not Just Inputs A golden dataset is a small, hand-curated set of (input, expected behavior) pairs that represents the ways your application is actually used — not a random sample, and not just the cases that already work. Each case needs enough structure to be scored automatically later: from dataclasses import dataclass , field @dataclass class EvalCase : id : str category : str # "extraction", "qa", "summarization", ... input : str # the prompt/question sent to the system under test expected_exact : str | None = None # non-None only for cases scorable by exact match must_contain : list [ str ] = field ( default_f

Introduction Building Reliable LLM Applications in Java put it plainly: treat model output as a hypothesis to verify, not a fact to trust. Testing Best Practices in Java put the same discipline in JUnit terms: a suite only earns trust by asserting the right things at the right level, unhappy paths included. This post is where those two ideas meet — a JUnit test either passes or fails against a fixed expected value; an LLM's output is a paragraph of prose that might be right in spirit while differing token-for-token from anything you wrote down in advance. Evaluating it takes a harness, not an assertEquals . That harness has three parts: a golden dataset of representative cases with known-good expected behavior, scoring that turns each case into a pass/fail or a number, and regression testing that runs the harness on every change and fails the build when the score drops. Making RAG Accurate in Java already gave you half of this story — recall@k, precision@k, MRR, nDCG measure whether retrieval found the right chunks. This post measures the other half: whether the generated answer built from those chunks is actually good, which is a genuinely different question a retrieval metric can't answer on its own. Everything below is illustrative, non-executed Java, grounded in the same Anthropic Java SDK shapes as posts 10/11. The Golden Dataset: Curating Cases, Not Just Inputs A golden dataset is a small, hand-curated set of (input, expected behavior) pairs that represents the ways your application is actually used — not a random sample, and not just the cases that already work. Each case needs enough structure to be scored automatically later: public record EvalCase ( String id , String category , // "extraction", "qa", "summarization", ... String input , // the prompt/question sent to the system under test String expectedExact , // non-null only for cases scorable by exact/programmatic match List < String > mustContain , // key facts a correct answer must mention (programma

There was a period in the early aughts when Definitive Jux (nee: Def Jux) seemed like it was going to be the future of hip hop. While the label featured plenty of experimental, boundary-pushing, and politically minded acts, Lif stood out as the most "conscious rapper" in the traditional sense. It was clear though, that […]

A tour of the stack behind mattstratton.com and speaking.mattstratton.com: a monorepo holding two Astro sites and a dev.to sync tool, twenty years of blog posts, and the pipeline that crossposts posts like this one.

I’m building Euro Toolhub , a German-first index of European software, SaaS, cloud and AI alternatives. The idea is simple: many companies, agencies, developers and privacy-conscious users want alternatives to common tools when they care about things like data residency, open source, self-hosting, European jurisdiction or reducing dependency on non-European providers. But most existing lists stop at listing tools. I want Euro Toolhub to go one step further. Each provider profile can include: country and jurisdiction category alternative-to mappings open source status self-hosting availability EU data residency DPA availability certifications where known target audience strengths and limitations a transparent sovereignty score embeddable badges for providers The project starts in German because the first target market is DACH, but the structure is prepared for more languages later. The long-term vision is to build a practical decision platform for digital sovereignty: not just “which European alternatives exist?”, but “which one fits my actual use case?” Current categories include web analytics, cloud and hosting, newsletter tools, CRM, email, password managers, AI APIs, project management, video conferencing and e-signatures. I’m looking for feedback from developers, SaaS founders, privacy people and self-hosting communities: Which European tools should be added? Which categories matter most? What would make a sovereignty score trustworthy? Should the provider dataset be opened through GitHub for corrections and submissions? Project: https://www.euro-toolhub.eu/de Provider submission: https://www.euro-toolhub.eu/de/anbieter-eintragen ``

Slides have an odd status in engineering: we make them constantly, but we treat them as disposable. They rarely live in a repo. They rarely go through review. The diagram you spent twenty minutes aligning in Keynote is gone the moment the talk ends. Dinghy's Slide Builder treats a slide like any other artifact: a folder of source files that compiles to a single deliverable. What it is A presentation builder layered on top of RevealJS , wired into the same Dinghy CLI you already have: YAML DSL: recognized keys map to semantic blocks, and any other key becomes the matching HTML element, so you describe slides in a structured, indented form. Markdown and HTML, auto-loaded: drop a .md or .html file in the slide folder and it becomes a section. Self-contained HTML output: assets inlined, a single file you can share or host anywhere. Live reload dev server: run dinghy slide start and edit-to-reload feedback. Prezi-style zoom and pan: exclusive to Dinghy, covered below. A YAML slide The core idea is that a slide is a tree of HTML elements, and YAML is a tidy way to describe nested structure: sections : - badge : Show Case title : Slide Builder subtitle : author RevealJS presentations in YAML ul : li : - YAML DSL maps keys to HTML elements - Self-contained HTML output - Live reload development server Some keys are recognized aliases: badge becomes <div class="badge"> , title becomes <h2 class="title"> , subtitle becomes <p class="subtitle"> . Any other key, such as p , h3 , ul , or li , becomes that HTML element directly. Multi-file slides are just multiple YAML files in the same folder, picked up in filename order. A Markdown slide If you want to add a section quickly, plain Markdown works: ## Slide Builder - YAML DSL maps keys to HTML elements - Self-contained HTML output - Live reload dev server Markdown files become slides automatically. You can mix YAML, Markdown, and raw HTML in the same slide and use whichever fits each section. The single-file output Run dinghy slid

Episode 1/4 of the mini-series The week Supabase lied to me 4 times . The three following episodes cover a mutation silently swallowed by the SDK [CANONICAL URL EPISODE 2: to fill in after push], an RLS recursion resolved by a JWT hook [CANONICAL URL EPISODE 3: to fill in after push], and a query that stops at exactly 1000 rows without saying so [CANONICAL URL EPISODE 4: to fill in after push]. The Tuesday the security probe spoke It's 9:12am on a Tuesday in May. The daily drift probe has been running automatically for three weeks — an aclexplode query across all public objects, filtered on anon . I don't open it every morning. That morning, it's waiting for me with a row that has no business being there. Niran sets a coffee on the corner of my desk without a word. He reads the output over my shoulder. A PII backup table — personal data in plaintext, created two days earlier for a bulk reclassification — shows up in the list with SELECT , INSERT , UPDATE , DELETE granted to anon . Accessible to any unauthenticated curl request. He lets three seconds pass and says: "It's not RLS." Then he goes back to his hoodie. He's right. It's not an RLS bug. The table itself is open, at the GRANT layer, before RLS even applies. Three objects, three doors, one mechanism That week, I realize I'm not dealing with an isolated incident. Three distinct objects, in three different migrations, each open a door nobody thought they'd opened. The backup table first. Then a policy set TO public because the public landing page needs it, which lets a POST {} from anon through with an HTTP 400 NOT NULL response instead of 401 Unauthorized . And finally four SECURITY DEFINER functions written to execute transactional operations with their owner's privileges, all invocable by anon because EXECUTE defaults to TO PUBLIC at CREATE time. Three objects, three superficially distinct mechanisms, yet one shared root. At every CREATE , Postgres completes the migration with an implicit GRANT the author nev

The question you don't dare ask out loud It's 10:40 PM on a Tuesday, I just closed an ADR — the seventy-fourth in this setup, written conscientiously, dated, cross-referenced with its migration, its contract test, and the commit that triggered it. And the question rises, the way it always rises at that hour when you've been coding alone for ten hours: who did I just write this for . No tech lead to convince, no PR review that'll catch it, no hypothetical acquirer to reassure, no architecture committee to brief tomorrow. Just the file, just me, just the doubt. It's the question of a solo dev at 70 days of serious practice. It has an honest answer, and that answer is neither "it'll pay when you sell" nor "it'll pay when you hire". Those two ROIs belong to other trajectories. The ROI of the solo dev who documents is an ROI he buys himself — deferred, intangible at moments, but materially countable if you force yourself to measure it in the first person. Here's mine, over 74 ADRs and 18 doctrine rules accumulated in 70 days, with no external observer to validate the grid. The false economy of "I'll remember" First trap, the one that cost me three weeks before I learned the lesson. The solo dev believes he doesn't need to write down what he decided because he decided it himself — his memory is worth an ADR. False at 14 days, systematically false at six weeks. Not because general memory fails, but because technical memory has a deceptive shape: you remember perfectly that you decided , you no longer remember why you decided that way. Three weeks after the May 5 session where I wrote ADR-0051 (FK ON DELETE SET NULL + CHECK NOT NULL incompatible, DELETE failing silently), I reopen the migration to add a column. I reread the diff, I don't understand why a certain CHECK constraint is phrased like this — the alternative I mentally dismiss today seems simpler, and I'm two clicks from refactoring. I go check the ADR. The answer is there, dated, sourced, in three lines. The simpl