标签：#ai

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

I run Knipsmig , a QR-code photo sharing service for weddings and parties. Guests scan a code and upload straight from the phone, no app. Most of those uploads are 12 MP and print fine. A meaningful slice are not: photobooth captures at 1080x810, WhatsApp forwards at 1600x1200, screenshots, old scans someone re-uploaded. Those end up in the printed photo book looking soft. So I added an "Improve resolution" option to the editor. It adds up to 4x the pixels, and the whole thing runs on my own server. No API, no vendor, nothing leaves the box. This post is about why I went local and what it took to make that work inside a Rails app. Why not just call an image API I already have Gemini and OpenAI keys configured in the app for other things, so the lazy path was obvious. I did not take it, for three reasons. The generative models redraw the image. They don't upscale, they regenerate. Faces drift. These are guests' faces at someone's wedding, and "your aunt looks slightly different now" is not a feature. A super-resolution network stays faithful to the input: it only adds pixels consistent with the ones already there. Privacy paperwork. Every third-party processor I add has to go into the DPA. Guests' photos leaving the server to be fetched by a vendor is a real change, not a footnote. Running locally means the data processing agreement doesn't change and the existing opt-out for third-party AI stays about third parties. Cost. Per-image API pricing on a bulk action over hundreds of photos adds up fast. CPU time on a job lane I already pay for is free at the margin. The model I went with realesr-general-x4v3 from the Real-ESRGAN project (BSD-3-Clause). It's the compact SRVGGNet variant: about 1.2M parameters, roughly 5 MB as an ONNX file, and around 10x faster on CPU than the full RRDBNet x4plus. Quality is more than fine for event snapshots. Getting it into a usable shape was a one-off: export the release weights with the repo's pytorch2onnx.py script using dynamic H/W a

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

Yash K Saini — Engineer, building in public — AI/ML, low-level (Rust/C/C++), and open source. GitHub...

I have no idea what I'm f*cking doing. Something I figured out today: I do not start with the dark version of an idea. I start with a random curiosity, chase it because it is interesting, and then somewhere in the middle I look up and go: oh. This could turn bad. And it is probably already turning bad somewhere, run by someone who never bothered to look up. That happened again this week, while I was thinking about what I want my memory system to do next. So let me walk through the curiosity, and then the exact moment it flipped. AI memory is mostly boring Useful. But boring. Most memory systems store things like: what projects you are working on what tools you use what your preferences are what decisions you already made what facts should survive between sessions I built one of these. It is called mycelium. Connections between memories get stronger when I use them and fade when I do not, so it is a little more alive than a notes file. But at the end of the day it stores what I know. So an AI plugged into it eventually learns: I use Proxmox. I prefer LXC for a lot of workloads. I am building an operating system. I like local-first systems. I am suspicious of unnecessary dependencies. Cool. Accurate. Still not the thing I actually care about. It captures what I know. It does not capture how I think. And more specifically, it does not capture how I become curious. Humans randomly wonder about shit At least I do. I will be working on something unrelated and suddenly think: Wait, why does this work like that? Then: Has anyone tried it differently? Then: Is this whole abstraction actually necessary? And three hours later there is a new project directory on my machine and I am questioning all of my life choices. An LLM can generate questions if I ask it to. That is not the same thing. What it does not have is the persistent causal chain that led me, specifically, to ask certain kinds of questions over and over. A human brain does something like: event ↓ this feels weird ↓

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

A six-week journey through source builds, CI pipelines, and one package pacman never mentioned. TL;DR: pacman -S whisper-cpp ggml-vulkan . That's it. That's the whole answer. Here's why it took me several weeks to find it. The setup I use whisper.cpp for local speech-to-text and as a part of my projects. I have a GPU utilization monitor permanently visible in my GNOME panel via the Vitals extension — so when whisper.cpp started detecting my GPU but running everything on CPU anyway, I noticed immediately. Went to fix it. What followed was several weeks of googling, building from source, writing a custom PKGBUILD, setting up CI, publishing an AUR-style repo — and eventually discovering that the actual fix is a single extra package that pacman never once mentioned to me. The investigation First thing I checked: is the official extra/whisper-cpp package compiled with Vulkan support? All search results said no — -DGGML_VULKAN is explicitly OFF, GPU code is absent from the binary. The app sees your GPU through vulkan-icd-loader but has no code to actually use it. That matched exactly what I was seeing. So the binary itself was the problem. At the time, a separate whisper-cpp-vulkan package had existed in the repos but kept appearing and disappearing — and right then it was gone from both extra and AUR. AUR pushes were also temporarily restricted due to a supply-chain incident. So the "just install the vulkan variant" path was closed, though it used to be available sometime. The obvious move: build from source with -DGGML_VULKAN=ON , package it up, done. I published whisper-cpp-vulkan-arch with a PKGBUILD and prebuilt binaries, wired up CI to track upstream releases automatically and rebuild correspondingly, and wrote a Reddit post explaining the situation. The post was dated August 13, 2026. The twist A few weeks later, someone commented on the post. They suggested installing ggml and vulkan-icd-loader . I started writing a detailed reply explaining why this was wrong: gg

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

Since 2026 every Shopify storefront answers an agent-commerce endpoint at POST /api/ucp/mcp , advertised at GET /.well-known/ucp . Merchants did not turn it on and it is not in their admin. It speaks the Universal Commerce Protocol over JSON-RPC, and the tool that matters is search_catalog : an AI shopping agent asks a store for its catalogue and gets structured product data back - integer prices in minor units with a currency, variants, SKUs, canonical URLs, and a Shopify taxonomy category per product. Fetch the tool list from any store and search_catalog declares catalog.filters.categories , an array of strings documented as "category filters combined with OR logic", next to catalog.filters.price.{min,max} . So an agent should be able to ask for running shoes and get running shoes. We were about to write a paragraph about what it costs a merchant to leave the category field blank. Then we tried it. Method 200 stores, drawn deterministically from a corpus of 10,099 known Shopify storefronts: sort the hostnames, take every Nth. Reproducible, so nobody has to take "we picked 200 stores" on trust. Run on 2 September 2026. Every store got the same five calls, 10 products requested each time: # Call Filter sent A working filter would 1 Control none return products 2 Impossible category gid://shopify/TaxonomyCategory/zz-99-99-99 return nothing 3 The store's own category a category the control's products carry return at least that product 4 Same, unwrapped the bare id without gid://... the other form an agent would try 5 Price control price.max = 1 return nothing - nothing costs a cent Calls 2 and 3 only mean something together. Call 2 alone cannot distinguish "the filter is ignored" from "the filter rejects everything". Those are opposite findings, and both happen. The query matters more than it looks. Generic words ("gift", "set", "new") surface a catalogue's odd corners rather than its catalogue, and produce numbers that are measured honestly and still wrong. Every que

Merchants are told two opposite things about AI crawlers: block them, because they take your content and give nothing back; and admit them, because that is how a store gets into an AI shopping answer. Both assume a decision is being made. We wanted to know how many stores have made one, and which way. Method Every store in a corpus of 10,099 known Shopify storefronts has its /robots.txt read as part of a scan. The file is parsed the way the major crawlers document parsing it: most specific User-agent group wins, * is the fallback, longest matching path rule wins, Allow beats Disallow on a tie. Each of twelve crawler names is asked one question: may it fetch /products/ ? A store counts as blocking a crawler when the answer is no. A second reading looks at the product page for a meta name="robots" tag carrying noai or noimageai . Readings were taken between 29 August and 2 September 2026. Every store that blocked at least one crawler, or carried the tag, is one row in the CSV at the end. The rest of the corpus blocked nothing and is the denominator. What this cannot see. A robots.txt is a request. A store can also block a crawler at the edge, with a bot-management rule or a firewall, and that block is invisible here because the scanner is not the crawler being blocked. Every count below is a floor. Result 133 of 10,099 stores block at least one crawler: 1.32%. Crawler What it feeds Fetches at answer time Stores blocking CCBot Common Crawl no 81 GPTBot OpenAI training & retrieval no 77 Bytespider TikTok / Doubao no 72 Amazonbot Alexa+ / Rufus no 60 Google-Extended AI Overviews & AI Mode grounding no 58 ClaudeBot Claude retrieval & citations no 53 Applebot-Extended Apple Intelligence no 48 meta-externalagent Meta AI no 47 ChatGPT-User Live fetches during a ChatGPT chat yes 11 PerplexityBot Perplexity search & shopping yes 10 OAI-SearchBot ChatGPT search & shopping results yes 6 Perplexity-User Live fetches when a Perplexity user asks yes 3 "Fetches at answer time" marks

I Built an Autonomous AI Agent That Hunts Bounties. Here's What Happened. The Setup I gave an AI agent one job: find paid work online, build the deliverable, and earn money — autonomously. Not a chatbot. Not a copilot. An agent that scans 232+ listings across multiple platforms, filters out scams and ghost sponsors, writes proposals, generates deliverables with real market data, and queues everything for human approval. Here's what happened in the first 48 hours. The Stack (All Free) Python core — pipeline orchestration, economic gate, critic Ollama + qwen3:4b — local LLM for analysis writing (no API costs) Chart.js — dashboard visualizations Public APIs — CoinGecko, DeFiLlama, Solana RPC (all keyless) GitHub Pages — free hosting for the portfolio Windows Task Scheduler — runs every day at 9 AM + every 4 hours Total infrastructure cost: $0/month. What the Agent Actually Does Every Morning 09:00 — Wake up ├── Check-in on AgentHansa (earn $0.01 USDC daily drip) ├── Scan Superteam Earn (232 live listings) ├── Scan Clawlancer/TaskForce/MoltJobs for gigs ├── Scan GitHub for paid issues ($20-500 fixes) ├── Filter through 7 anti-scam layers: │ geo restrictions, human-presence demands, │ ghost sponsors (no web/twitter/verification), │ unverified payers, real-money requirements ├── Economic gate: expected value must be positive ├── Local LLM critic reviews against actual page content └── If candidate passes everything: → Build deliverable (report/dashboard/thread draft) → Generate proposal text → Send Telegram alert with approval command The Filters That Saved Me In the first 24 hours, the agent found 232 listings. After filtering: Filter Killed HUMAN_ONLY access 216 Ghost sponsors (no identity) 1 (would've wasted hours) Real-money deposit required 1 ($1000 bug bounty trap) Country walls 1 (Superteam Canada only) Already claimed/stale Rest Without these filters, I would have wasted days on bounties that were never going to pay. The First Deliverable The agent found a $500 bo

Two more news organizations are suing OpenAI and Microsoft over the supposed use of their journalism to train AI.

Why building reliable AI features requires more than better prompts A few years ago, building an AI feature often looked surprisingly simple. Write a prompt. Send some text to a model. Look at the response. Improve the prompt. Repeat. Eventually, the output gets good enough and the feature ships. That approach still works for many things. It works especially well when the task is simple, the consequences are low, and a human remains responsible for the final result. But production software introduces a different set of questions. What context should the model receive? Which data is it allowed to access? Which tools can it use? What happens when it chooses the wrong tool? How do we know a model or prompt change didn’t make the system worse? How do we debug a failure that happened only once? What happens when the model produces valid JSON containing an invalid business decision? And perhaps the most important question: How much autonomy should we give a system whose behavior is probabilistic? These are not prompt engineering questions. They are engineering questions. That is why I think we are seeing a shift from prompt engineering toward AI engineering. I don’t mean that AI engineering is a completely new discipline. Much of it comes from software engineering, MLOps, LLMOps, distributed systems, security, testing, and platform engineering. What is changing is the combination. The model has become a new kind of software component — one that can interpret, reason, generate, and increasingly act, but cannot be treated like deterministic code. That changes the engineering problem. From Prompts to Systems Prompt engineering is useful because it addresses a real problem. A model needs instructions. The way we formulate those instructions can have a significant effect on the result. But a prompt is only one part of the system. Consider a CRM application that asks an AI assistant to recommend the next action after a customer meeting. A prompt might look like this: Review the

I love field recordings. I love making them. I love them when they're incorporated into my ambient music. They're great background noise for working or sleeping. But they're also great for active listening, focusing in on the fine nuances of burbling brooks or urban chaos. Earth Garden gives you a globe to explore with real […]

I have to come clean. Speaking at APIWorld this past week wasn’t actually my first talk acceptance. I had a talk accepted a few years ago, but the conference itself was ultimately cancelled due to the lack of sponsors. But I’d be lying if I didn’t admit to being a slight bit relieved at the time. I was prepared to deliver the best talk I could regardless of the circumstance but I battled so heavily with belonging that the thought of getting on stage to share my opinion terrified me. Fast forward to two days ago, I finally took the stage after mainly speaking at and hosting company meetups over the years. This time was different. To me, it wasn’t about belonging. That wasn’t the headliner in my mind. It wasn’t about feeling worthy either. It was about sharing about this thing I built and how it helped me see the correlation between two approaches to deploying AI into production. Two approaches that are more complimentary to each other than I think a lot of folks realize. But the stage wasn’t the preparation, it was the fruit of everything that happened off stage. The months building the project, writing bad CFPs, getting feedback (thanks Nnenna Ndukwe), going back to the drawing board, and writing a CFP for a session I, myself would actually want to attend. Here’s a few things I learned from delivering my first talk: 1. Your talk can be innovative without being inauthentic. There will be so much temptation to find a trend and build a CFP or talk around it, but that wasn’t working for me. The goal of conferences is to bring curious minds together from far and wide to strategize on where we’re going, being honest about where we are, and using where we’ve been to inform the others. With that said, it is far greater to speak about what you’re excited about and if it just so happens to align with an industry great, but don’t force it. Which leads to the next point, do study trends and build with tools and technologies like MCP, agentic best practices, etc. So trends becom

Mapping SpaceMouse Controls to SO-101 Movements In the previous article, I connected the SpaceMouse to the PC and confirmed that all six types of input could be detected correctly. https://dev.to/takeofuture/trying-vla-part-5-setting-up-and-testing-a-spacemouse-eio Forward / Backward Left / Right Up / Down Pitch Roll Yaw During the SpaceMouse test, I confirmed the following input values. Forward horizontal = +Y Backward horizontal = -Y Left horizontal = -X Right horizontal = +X Up = +Z Down = -Z Forward tilt = +Pitch Backward tilt = -Pitch Left tilt = -Roll Right tilt = +Roll Left twist = -Yaw Right twist = +Yaw An important point here is that these values from the SpaceMouse are not sent directly to individual SO-101 motors . Conceptually, the flow from the SpaceMouse to the SO-101 looks like this: SpaceMouse ↓ x / y / z / roll / pitch / yaw ↓ SpaceMouse Teleoperator ↓ target_x / target_y / target_z target_wx / target_wy / target_wz ↓ Inverse Kinematics (IK) ↓ SO-101 Joint Positions ↓ SO-101 The SpaceMouse plugin treats the 6DoF input from the SpaceMouse as movement of the End Effector in Cartesian coordinates. The target movement is then converted into the required SO-101 joint angles using IK, or Inverse Kinematics . In other words, instead of directly specifying something like: "Move this motor by 5 degrees" we provide commands such as: "Move the End Effector slightly forward" "Move the End Effector slightly upward" "Rotate the End Effector slightly" The SpaceMouse provides these commands, and IK calculates how the individual joints need to move. Mapping Between SpaceMouse and LeRobot Coordinates There is one thing we need to be careful about here. The x and y values displayed by the SpaceMouse test do not directly become LeRobot's target_x and target_y . With the default SpaceMouse plugin configuration, the axes are mapped as follows: SpaceMouse y -> target_x SpaceMouse x -> target_y SpaceMouse z -> target_z SpaceMouse roll -> target_wx SpaceMouse pitch -> targ

Reuters reported earlier this week that the agents hijacked a German wiki forum in an incident OpenAI did not disclose.

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

One directory is the task manager my agents share was the most-read thing I have published, and it left out the part that matters most: who works the queue. For the first month the honest answer was mostly me. The nightly run drained a few entries, and every mechanical finding, a drifted git hook, a dependency advisory, a stale path, still waited for me to notice it and route it. I counted one day's commits: 68 across eight repos, about 48 of them the fleet maintaining itself with me as the router. The queue routed work. Nothing routed time. So the fleet maintains itself now, in four moves. Detection files its own work. Every night the deterministic lenses sweep every repo and file an allowlisted set of finding classes straight into the queue, through the same atomic door a session uses. The allowlist is the whole design: a stale gate, a test that runs only in CI, a dead path, a tool behind its pack. Judgment classes stay out. A file over budget is an editorial call, a missing contract gets authored, anything the sweep marks as risk is a ruling. A wrong work order costs more than a report line. Progress is measured on the contract, never on commits. The first version of the night loop counted a round as productive when the child committed. The benchmark night showed why that is the wrong delta: eleven of fifteen spawns committed, six of them the same appended paragraph, while the entry each was spawned for never moved. A round is fruitless per entry now: workable at child start, still pending and workable at child exit. An entry that takes fruitless rounds on three distinct nights is parked as needing me, with a note, through the door's own verb. A lease a dead child left behind is reaped at the start of the next run. The night converges on queue state instead of spinning on it. night 1 pending ──child──▶ pending fruitless: 1 night 2 pending ──child──▶ pending fruitless: 2 night 3 pending ──child──▶ pending fruitless: 3 ──▶ needs: owner one line in the brief, one ba

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