标签：#dev

This is a shortened version of my original post . My wife and I have blogged about every trip since our honeymoon 10 years ago. For the people at home, for ourselves later, and by now for our children. We took turns writing, but both had photos and videos on their phones. The text was never the hard part. The photos and videos were: every day one of us sent them from the phone to the other, who had to upload them and sort them into the entry in the right order. So I wrote Texttile , an open-source blog engine built for writing together. One entry, two screens Multiple people can have the same entry open. One of them has the text and types, the other watches the words arrive and can take the text over with one click. Both can still work on the gallery. Photos and videos belong in the same gallery. Videos come from your own server. Drop one in and Texttile converts it, thumbnail included. No YouTube embed, no player from anywhere else. One container, one folder Phoenix, LiveView, ffmpeg and SQLite live in one Docker image. Everything is in /data . Move that folder and you move the blog. A reader's browser talks to your server and nothing else. No CDN, no tracker, no hosted font. What it is not There are no roles, no permission matrix, no plugins, no theme marketplace. Everybody with an account is an admin. I built it for people who trust each other, because that is who writes a blog together. You can try it or read the source . The full story includes a video showing both screens. How do you blog on the road?

One SQL statement over a VECTOR(768) column, 45,400 charities, and 2,917,459 real pairs used to check it. What the detector caught, and what it missed.

The engineering team at software company Figma recently documented how they built AI agents to help their security team investigate alerts, search past incidents, check company systems, and even prepare code fixes. The agents learn from previous investigations, reducing repetitive work and helping engineers resolve complex alerts about 70% faster. By Renato Losio

Nineteen OOM kills in nine days. Ten WordPress apps on a 32GB shared box. One of them a client site that took a CPU spike on 14 July during a paid campaign burst, and pushed the whole tenant into the wall. This post is the diagnosis before the rebuild. What we actually found when we stopped guessing. Two layers of Cloudflare, one page cache plugin, one preloader being silently challenged, and a language subpath that was cold every time it mattered. I'm writing it partly for anyone who runs multi-tenant WordPress on Cloudways or similar, and partly as a reminder for future-me. There's a checklist at the end. Steal it. The client is anonymized throughout. Every number is real. The stack Traffic hits two Cloudflare layers before it reaches origin. Both are Cloudflare, but they're different zones on different accounts, and they own different things. [ visitor ] ↓ [ Upstream Cloudflare zone (managed by a third party) ] ← DNS, SSL, HTML edge cache ↓ [ Cloudflare Enterprise add-on sold by Cloudways ] ← WAF, bot, rate limit, AI crawler block ↓ [ Cloudways origin: nginx + PHP-FPM ] ↓ [ WordPress + WPML + Elementor + FlyingPress ] Two Cloudflares isn't a mistake. The domain has been on Cloudflare via an upstream party since before the site moved to Cloudways. When Cloudways later offered a Cloudflare Enterprise add-on for its security stack, we kept both. We manage the Cloudways side. We don't own the upstream zone, which shapes what we can and can't do without a request going out. The trap is that both layers can cache HTML, and both can serve security challenges. If nobody writes down which layer does what, they fight. Our ownership split ended up like this: Layer Owns Upstream Cloudflare (third party) DNS, SSL, HTML edge cache, purge lifecycle Cloudways CF Enterprise add-on WAF, bot management, rate limiting, AI crawler blocking, ScrapeShield, Browser Integrity Check FlyingPress Origin page cache, Cloudflare integration pointed at the upstream zone, purge rules Cloudways "

I Built a Mobile Terminal Around My herdr + Codex Workflow I am building Termish , an open-source mobile remote-work tool for SSH/Mosh terminals, file management, remote screens, and AI-assisted development. The unusual part is that I built much of Termish through Termish itself. My daily workflow is: Termish on my phone → herdr on my host → Codex in the project The development environment and AI tools run on my own machine. My phone is where I enter commands, describe tasks, upload screenshots, inspect changes, and check the resulting UI. Termish is both the product I am building and a tool I use to build it. Put remote work in your pocket. Source code: github.com/ttermish/termish Why do AI-assisted coding on a phone? A phone is not a replacement for a desktop machine. Its screen is smaller. Reading a large codebase is harder. Long debugging sessions are more comfortable on a larger display. Those limitations are real. But AI-assisted development changes part of the workflow. Many tasks become: Describe a requirement. Provide context. Let an agent make changes. Review the output. Run a command or test. Decide what to change next. Some of that loop works well on a phone. For example, when I think of a feature away from my desk, I can open the project and ask an agent to start implementing it. When I find a UI problem, I can upload a screenshot to the host and ask the agent to inspect it together with the code. After the change is done, I can review the diff, run tests, and check the actual UI through a remote screen. The goal is not to write an entire application on a phone. The goal is to make a phone a useful place to start work, inspect work, and keep a task moving. Why another SSH and AI coding tool? This is a fair question. Tools such as Termius and Blink already provide strong SSH, Mosh, and file-management experiences. If you already have a setup that works well, you can run Codex, Claude Code, or other agents through a terminal today. Happy and similar produ

188 vulnerabilities. That's where we started. After the modernisation, the jjwt migration, the targeted remediations, and the documented suppressions, here's where we ended up: 6 open findings. All suppressed with documented reasons. 0 unaddressed. But "188 to 6" is a headline, not a measurement. This article is about what meaningful security posture measurement actually looks like — the metrics that tell a real story versus the ones that just make a dashboard look good. Why Raw Finding Count Is a Weak Metric The most common way teams measure SCA progress is finding count. Before: 188. After: 6. Improvement: 182 findings resolved. 97% reduction. That number is real but it's also misleading in isolation. Here's why. If I had suppressed all 188 findings without fixing anything, my finding count would also be 6. The dashboard would look identical. The actual security posture would be unchanged. Finding count measures activity, not outcomes. What you need to measure is: What risk was actually reduced — not just what got closed What risk remains and why — the documented residual risk How the remediation was achieved — fix vs. suppress breakdown What the exploit exposure looks like — before and after exploit maturity These four dimensions together tell a story that a single number can't. Metric 1: Risk Reduction by Severity The most important before/after comparison is severity distribution, not total count. Severity Before After Fixed After Suppressed Remaining Critical 10 10 0 0 High 99 93 6 0 Medium 59 29 23 0 (7 in 4.x backlog) Low 20 0 20 0 Total 188 132 49 0 unaddressed Every Critical finding was fixed — not suppressed, fixed. That's the number that matters most. No Critical vulnerability was accepted as residual risk. The 6 suppressed High findings are all in the "no known exploit" category with documented unreachability justifications. The 23 suppressed Medium findings are split between test-scope dependencies and unreachable code paths. What to say when presentin

This is a submission for the DEV Weekend Challenge: Generosity Edition. What I...

Knowing React Is Not the Same as Being a Frontend Engineer A huge number of self-taught developers can build a React component, wire up useState , and fetch data with useEffect . A much smaller number can build a frontend that stays fast as it grows, handles real error states gracefully, and doesn't quietly re-render half the page every time a user types a letter. That gap — between "I can use React" and "I can build a production frontend" — is where a lot of otherwise-promising candidates get stuck. It's not usually a knowledge problem about React's API. It's a gap in the surrounding skills: state architecture, performance, accessibility, and the unglamorous parts of frontend work that tutorials rarely cover in depth. This guide lays out a realistic path from "knows React" to genuinely job-ready frontend engineer, focused on the specific gaps that show up in real interviews and real codebases. This post originally appeared on the Ciphemic Academia blog . What "Frontend Engineer" Actually Requires Beyond React Basics The role is broader than component-building, and being explicit about what it covers helps target the right skills: State management at scale — not just useState in one component, but how state should flow through an application with many interconnecting pieces Performance — understanding re-renders, memoization, and why a frontend that works fine with test data can slow down badly with real data volume Accessibility and semantic HTML — building interfaces that actually work for everyone, not just visually API integration done properly — loading states, error states, race conditions, not just the happy-path fetch call Testing — component and integration tests that catch real regressions, not just tests that exist to say tests exist A typical React tutorial project touches the first item briefly and skips most of the rest. That's exactly why a portfolio built entirely from tutorial-style projects tends to fall short in real interviews. Step 1: Confirm Ja

Why I built this Every time I applied for an internship, I did the same tedious thing: read the job description, guess what interview questions might come up, and google "common interview questions for [role]" — hoping something would stick. I wanted something smarter. Something that actually looked at my resume and the specific job description, and told me exactly where I stood and what to prepare. That's how PrepAI was born — an AI-powered career assistant that analyzes your resume against a job description and generates a match score, a skill-gap breakdown, personalized interview questions, and a 7-day preparation roadmap. 🔗 Live: prep-ai-navy-nine.vercel.app 💻 Code: github.com/Lalitprajapat47 What it does Upload your resume + paste a job description PrepAI extracts skills, experience, and keywords from both It generates: An ATS-style match score A skill-gap analysis (what the job wants vs. what you have) Personalized interview questions based on the actual role A 7-day roadmap to close the gaps before the interview Tech stack Frontend: React.js Backend: Node.js + Express.js Database: MongoDB AI: Google Gemini API for resume/JD analysis and question generation Classic MERN, with Gemini doing the heavy lifting on the reasoning side. The interesting part: prompting Gemini reliably The hardest part wasn't calling the API — it was getting consistent, structured output back every time. Interview prep needs predictable JSON (question lists, scores, roadmaps), not freeform paragraphs that break your UI. What helped: Being explicit in the prompt about the exact JSON shape I wanted back Feeding in resume text and JD text as clearly labeled sections, not just mashed together Adding a fallback parse step on the backend in case Gemini added extra text around the JSON This taught me a lot about prompt engineering as an actual engineering discipline — not just "ask nicely," but treating the prompt like an API contract. What I learned How to design a backend that talks to an LL

I've been quietly building Antigravity Tools — a collection of 59 free, browser-based developer utilities — and today I'm sharing everything I built and learned. Why vanilla JS? No React, no build step. The main constraint I set for myself: zero dependencies, zero server, zero telemetry . When you paste your JWT token into jwt.io, it goes to their server. When you use an online regex tester, your test strings are logged. I built Antigravity Tools so every operation runs inside your browser, using native APIs. No Node.js backend No npm packages No webpack/vite/parcel No Google Analytics No cookies Everything runs on Web Crypto API , Canvas API , Web Audio API , and IndexedDB — all native to modern browsers. The 8 tool categories 🔐 Security & Auth Tools JWT Inspector — decode JWT header, payload, and check expiry locally RSA & ECC Key Generator — generate 2048-bit key pairs via SubtleCrypto Hash & Password Generator — SHA-256/SHA-512 via Web Crypto PII Masker — strip emails, credit cards, SSNs, IPs from text Universal Encoder/Decoder — Base64, URL, Hex, HTML entities, Unicode 🤖 AI & Prompting Tools AI Token Counter — estimate cost across GPT-4o, Claude 3.5, Gemini 2.0, DeepSeek R1 System Prompt Builder — structure agent instructions with XML tags and tool definitions AI Text Humanizer — rephrase robotic AI output into natural writing Prompt Cost Trimmer — compress prompts by 30–50% to reduce API costs ⚡ Dev & Code Tools JSON Workbench — beautify, validate, convert to TypeScript, Python, Go types cURL Converter — cURL → JS fetch, Python requests, Go, PHP Regex Tester — real-time match highlighting with capture group display Cron Builder — visual cron expression editor with plain-English output Git Command Helper — build undo/squash/cherry-pick commands visually Try it 👉 https://antigravitytools.app

Security Bolted on at the End Is Not DevSecOps The most common failure pattern in teams that claim to "do DevSecOps" looks like this: build the pipeline, ship the feature, and run a security scan right before release — treating security as a checkbox at the end of the process instead of something built into every stage of it. That's not DevSecOps. That's a security review with extra steps. Real DevSecOps means security is woven into the pipeline itself — scanning dependencies on every commit, catching misconfigurations before they're deployed, and treating a vulnerability the same way you'd treat a failing test: something that blocks the pipeline, not something reviewed manually after the fact. This guide is for people who already have some DevOps or backend foundation and want to understand what it actually takes to move into a DevSecOps-focused role — not just "add security" to an existing skillset, but understand the mindset shift that makes the discipline distinct. This post originally appeared on the Ciphemic Academia blog . What "DevSecOps" Actually Requires DevSecOps sits at the intersection of three skill areas, and a real role expects working competence across all three, not deep expertise in just one: DevOps fundamentals — CI/CD pipelines, infrastructure-as-code, containers, the same core skills a cloud/DevOps engineer needs Application security — understanding common vulnerability classes, how to find them, and how to actually fix them, not just recognize their names Security automation — the specific skill of embedding security checks into a pipeline so they run automatically, consistently, on every change That third point is what actually distinguishes DevSecOps from "a DevOps engineer who also cares about security." It's specifically about automation and process — making secure practices the default path, not an extra manual step someone has to remember to do. Step 1: Confirm Your DevOps Foundation Is Solid DevSecOps is not an entry point into DevOps —

I run about thirty scheduled jobs on a single Windows box. Some are scrapers, some generate content, some are trading bots, some just check that the other jobs are alive. Most of them were written and are maintained by an AI coding agent that I let run unattended. Over three months, every one of the failures below reported success . The scheduler said LastTaskResult = 0 . The logs looked fine or didn't exist. And nothing had happened. If you only take one thing from this post: stop checking exit codes, start checking artifacts. I'll get to why at the end. First, the seven ways I got lied to. 1. The wrapper that always returns 0 To stop console windows flashing on my desktop every few minutes, I wrapped each scheduled task in a tiny VBScript launcher: Set WshShell = CreateObject ( "WScript.Shell" ) WshShell . Run "cmd /c "" python job.py >> job.log 2>&1 "" " , 0 , True 0 hides the window. True waits for completion. I assumed True also meant the exit code came back. It does not. WshShell.Run used as a statement discards the return value, so wscript.exe exits 0 no matter what the child did. I found this because a content pipeline had been dead for five days while the scheduler reported green every single day. The fix is to call Run as a function and pass the value out: Set WshShell = CreateObject ( "WScript.Shell" ) exitCode = WshShell . Run ( "cmd /c "" python job.py >> job.log 2>&1 "" " , 0 , True ) WScript . Quit ( exitCode ) Note the parentheses — required when you're taking a return value. After fixing this across 17 launchers, one task showed a non-zero result for the first time in its life . It had been failing for weeks. 2. The last line of your batch file overwrites the exit code Fixed the launcher, still got false greens. The next layer down was a .cmd shim: node pipeline .js >> run .log 2 >& 1 echo [ done ] exit code %errorlevel% >> run .log That echo is the last command, echo always succeeds, so the batch file returns its exit code — zero — regardless of wh

Struct tags are just strings — a typo'd checker name, a wrong-typed field, or a renamed cross-field target all compile fine and fail silently at runtime. checkerlint catches all three before you ship. Struct tags are string literals. The Go compiler checks that your struct compiles — it has no idea what checkers:"eq-field:Passwrd" means, so a typo in a field name, a checker applied to a field of the wrong type, or a renamed field that a cross-field rule still points at all compile fine. They fail later, at runtime, sometimes silently, sometimes as a panic in the middle of handling a request. type Registration struct { Password string `checkers:"trim required"` ConfirmPassword string `checkers:"required eq-field:Passwrd"` // typo: no such field Age int `checkers:"email"` // email is string-only } Nothing here trips go build , go vet , or a normal linter — they all treat checkers:"..." as an opaque string. The first bug only surfaces the moment someone submits a registration form and eq-field can't find a field called Passwrd . The second is worse: email assumes a string under the hood, so calling it on an int field panics at validation time instead of returning a normal error. checkerlint is a go/analysis -based static analyzer, shipped as its own module in the Checker repo, that reads these tags at build/lint time and catches exactly this class of bug before it ships: ./registration.go:3:2: checkerlint: eq-field references field "Passwrd", which doesn't exist on this struct ./registration.go:4:2: checkerlint: email requires a string, but the field's type is int What it actually checks Three things, all specific to how checkers / validate tags can go wrong: Unknown checker names. Every token in the tag has to be a registered checker, normalizer, field-relative checker, omitempty , or a name your own code registered via RegisterMaker / RegisterFieldMaker with a string literal. Typo requird instead of required and checkerlint flags it — nothing else in your toolchain w

How to turn struct-tag validation failures into a standard "application/problem+json" response — the RFC 9457 format — with one method call, no hand-rolled error envelope. Most Go APIs invent their own validation error shape. One team returns {"errors": [...]} , another {"field_errors": {...}} , a third just a flat {"error": "message"} and hopes the client parses it. Every one of those is a private contract the client has to learn from your docs, because there's no shared shape for "here's what's wrong with your request." RFC 9457 — Problem Details for HTTP APIs — is the IETF standard that fixes this: a application/problem+json body with type , title , status , and room for problem-specific extensions. Checker now builds one of these directly from a failed struct validation, via CheckErrors.ProblemDetails() . The shape RFC 9457 defines four base members — type , title , status , detail , instance — and lets a specific problem type add its own. For validation errors, RFC 9457 §3.1 sketches exactly this extension: an invalid-params array listing which fields failed and why. That's what Checker produces. From a failed struct to a problem+json body Take a struct with a missing required field: type Person struct { Name string `checkers:"required"` } person := & Person {} errs , ok := checker . CheckStruct ( person ) if ! ok { data , _ := json . Marshal ( errs . ProblemDetails ()) fmt . Println ( string ( data )) } { "type" : "about:blank" , "title" : "Your request parameters failed validation." , "status" : 400 , "invalid-params" : [ { "name" : "Name" , "reason" : "Required value is missing." , "code" : "REQUIRED" } ] } One method call — errs.ProblemDetails() — turns the same CheckErrors you'd otherwise call .JSON() on into a *ProblemDetails value, ready to marshal. type defaults to "about:blank" (RFC 9457's own default for "no more specific problem type registered"), status defaults to 400 , and each invalid-params entry carries the field name , a localized human-readab

Level 300 Some time ago we created a blog showing the capabilities of AI DLC and SDD to create quick and efficient prototypes as a MVP, the results were amazing, however, we omitted something: DevSecOps best practices and CICD for the workload. The prototype was built with a serverless framework and modern cloud-native application patterns. However, moving from a working MVP to a production-ready solution requires stronger alignment with DevSecOps, CI/CD, and operational excellence. That transition leaves several important questions open: Security posture • What security vulnerabilities exist in the solution? • Is the platform ready to withstand common web attacks? Code quality and production readiness • What is the overall quality of the code? • Is this truly an example of an enterprise-ready solution? Cloud compliance and misconfiguration risk • Which cloud security compliance gaps still need to be addressed? • Are there misconfigurations that could create operational or security risk? The other side of this challenge is organizational readiness. Many companies are enabling development teams with assistants such as Kiro, Claude, Cursor, and similar tools. However, without a mature process to review, scan, govern, and manage code at scale, these tools can introduce high costs, expand security risks, and growing technical debt. For the Agentic AI era, DevSecOps maturity is no longer optional. A secure software development lifecycle, policy-driven development, and zero-trust principles must become core operating requirements rather than afterthoughts. Open loop – Starter point a classical DevSecOps CICD system Suppose that the company already has a continuous integration and delivery framework and tools for that kind of workload with classical tools, in terms of maturity level and L3 Defined and Managed here we have Security gates integrated in CI/CD; SAST/SCA/secrets/IaC; centralized findings; quality gates. The maturity model we use We measure against a five-level

This is a submission for Weekend Challenge: Generosity Edition What I Built Every year an enormous amount of aid money goes unclaimed. Not because it runs out, and not because nobody needs it, but because of something much stupider. The form is the wall. If you are blind, if you never learned to read well, or if you arrived last month and don't yet speak the language the form is printed in, the help you are entitled to is sitting behind a document you cannot fill in. You need a neighbour, a caseworker, or a volunteer to sit down with you. So you wait. Or you never apply at all. I wanted to see if the wall could just be removed. Amparo completes a real aid application entirely by talking . No reading. No typing. No form. It asks a few simple questions out loud, you answer in your own words in whatever language you speak, it reads back what it understood so you can catch mistakes, and it hands you a finished PDF to take to your local food bank. The part I care most about is that it accepts answers the way people actually give them. Nobody says "household size: four". They say: "We're me, my mum and two little kids." Amparo works out that there are 4 people in the household, 2 of them children , and moves on. It does the paperwork thinking so the person doesn't have to. You can also correct it at any time, about any field, however long ago you answered. Say "no, I said three, not four" and it fixes that value and carries on. That mattered more than I expected. A voice interface without a correction path is a trap, because you cannot see what it wrote down. Demo The moment worth watching: one messy spoken sentence, and three fields fill themselves in on the right. Code lluisestape-upc / Amparo Apply for aid entirely by talking, in your own language. Voice-first accessibility tool built with Gemini + ElevenLabs. Amparo Apply for aid entirely by talking, in your own language. Billions in aid go unclaimed every year, and one of the reasons is painfully simple: the form its

1. Project Introduction and Objective In this project, I used Microsoft Excel and Power Query to clean and analyze a Jumia product dataset and then built an interactive dashboard to summarize pricing, discounts, ratings and customer engagement. The main objective was to turn a small raw e-commerce dataset into useful business information. I wanted the final dashboard to answer practical questions such as: Do products with higher discounts receive more customer engagement? Do higher priced products have better ratings? Is there a relationship between product rating and number of reviews? Which products have the highest review engagement? Which products may require further investigation because they have high discounts but low ratings? The project also gave me practical experience in data cleaning, excel formulas, PivotTables, PivotCharts, slicers, correlation analysis and dashboard design. 2. Dataset and Business Questions The original dataset contained 115 rows and 6 columns: Product Current price Old price Discount Review Rating The dataset was small but it contained several realistic data quality problems. This made it useful for me to practice the complete analytics process rather than going directly to visualization. I structured the workbook into the following sheets: Raw_Data Cleaned_Data Analysis Pivot_Tables Dashboard Data_Dictionary As we have always been taught in class,I kept the Raw_Data sheet unchanged so that I always have a copy of the original source data. 3. Initial Data-Quality Audit Before cleaning the data, I profiled the dataset in Power Query using Column Quality, Column Distribution and Column Profile. The audit identified several issues: Data-quality check Result Original rows 115 Original columns 6 Blank Review values 58 Blank Rating values 58 Populated Review values stored as negative numbers 57 Current Price ranges 1 Old Price ranges 1 Exact duplicate rows removed 3 Discount values outside 0 to 100% 0 Rating values outside 0 to 5 after cle

This is a submission for Weekend Challenge: Generosity Edition I have given money to charities for years and I have never once known whether the one I gave to was about to close. The number everybody puts in front of you is overhead, the share of spending that does not go to programmes. Every rating site leads with it. I assumed it meant something. So this weekend I downloaded the IRS Statistics of Income extracts of Form 990 and Form 990-EZ, which is 3,697,515 filings covering 700,873 organisations across fiscal 2017 to 2024, then asked a narrower question. Not whether a charity is efficient. Whether it is going to still be there. I took the 328,186 organisations that filed a long-form Form 990 for fiscal 2018 or 2019, then checked which of them appear on any filing for fiscal 2022 or later. 8.88% do not. Then I scored two candidate signals inside each of ten spending deciles, so that nothing I found could turn out to be a story about big charities outliving small ones. Feeding America spends $4.93 billion a year and holds 1.04 months of it in cash. The Greater Chicago Food Depository spends $261 million and holds half a month. Second Harvest Food Bank of Central Florida holds nine days. None of that is on any rating site, because the number nobody computes for you is the one that decides whether the lights stay on. What I Built Keepalive computes months of runway for 579,178 US nonprofits, straight off their own filings. Runway is cash plus savings divided by one month of spending. It is the number a finance director lives by and the number a donor never sees. Across 1,573,687 long-form filings the median is 5.5 months . 33.5% hold under three months. 15.1% hold under one. The site does four things with that. Where does my gift buy the most time. Say what you can give, pick a cause and a state. It ranks real organisations by days of runway your money adds, which is 365 * yearly gift / annual spending . $25 a month is 12 hours of runway at a $260 million food bank

Nobody on your team chose 13px. Someone pasted it. Someone nudged 12px until a border lined up. A coding agent produced it because nothing told it your scale stops at 12 and 16. .card { padding : 13px ; /* off-scale: nearest are 12px or 16px */ margin-bottom : 7px ; /* off-scale: nearest are 4px or 8px */ } Six months later git grep finds forty distinct spacing values, and the design system's spacing page describes a project that no longer exists. This spring I pointed Rhythmguard , the Stylelint plugin I maintain for spacing scales, at twenty public design systems to find out how quiet it could be on code I do not control. The numbers changed the tool more than any feature request has. This is what a team can take from them, whether or not you use this plugin. Part 1. What twenty repositories showed The benchmark clones each repository at a pinned commit, runs the audit, and classifies every finding as real drift or as noise the tool should not have raised. The full table lives in QUIET_BENCHMARK.md and CI regenerates it on every change. A slice: Repo Off-scale findings Scale source Note Mastodon 564 its own --space-* tokens see below Carbon 272 fallback spacing goes through spacing() Primer CSS 97 fallback tokens arrive from a package shadcn/ui 58 its own Tailwind --spacing base Bootstrap 41 fallback spacing goes through $spacer Mantine 30 its own --mantine-spacing-* tokens Radix Themes 7 its own --space-* tokens values written as calc(4px * var(--scaling)) Spectrum CSS 5 fallback everything is a --spectrum-* token Three things held across the set. Drift concentrates in a handful of values Mastodon defines a real spacing scale as custom properties: // app/javascript/styles/mastodon/tokens/_shape.scss --space-3xs : 2px ; --space-xs : 8px ; --space-sm : 12px ; --space-md : 16px ; --space-lg : 20px ; --space-xl : 24px ; --space-4xl : 36px ; --space-5xl : 40px ; Its stylesheets ignore that scale 564 times. Here is the audit's own histogram: ## CSS Off-Scale Values | V

The permission prompt was the last brake on my fleet, and it was in the wrong place. A prompt fires when a human is sitting there to read it. My agents do most of their work when nobody is: the nightly drain, the noon pass, the headless jobs that read the open web. Those run with prompts skipped, by design, because a prompt nobody answers is a stalled job. So the protection was strongest exactly where I was already watching, and absent where the unattended work runs. What replaced it is a hook. The harness runs a small shell script before every tool call, in every session, in every permission mode, bypass and headless included. The script reads the call as JSON and either lets it through or exits with the code that feeds its message back to the model. Until last week it covered one class: the moves an injected instruction would need, reading a credential file, dumping the keychain, piping a download into a shell. It now covers the class I had left to the prompt: force pushes, a hard reset or a branch swap in the one working tree several live sessions share, a recursive delete aimed at a home or project root, a package release. The hook exists because of where the old rules lived. One of my contract rules was written in four documents and enforced in one place: a deny list that loads only for a session rooted in a particular directory. Both sessions that broke the rule were rooted somewhere else, so they met no rule at all, while the doctor that checks the setup went green, because it grepped the deny list's text. A rule enforced one directory wide is enforced in the one place the violation was never going to come from. A hook loads everywhere, so it is where a rule that binds every session has to live. The rule for adding a rule is a throughput rule, not a caution rule. A rule earns its place only if it fires almost never, or if it prevents the kind of cross-session destruction that forces other sessions to redo their work. Anything frequent and recoverable stays ou