标签：#productivity

Why I stopped reading "❌ Old vs ✅ New" posts I used to scroll past them. Then I started ignoring them. Now? I don't read them at all. Not because they're "wrong". But because they're incomplete . The problem with "❌ Old vs ✅ New" These posts make everything look easy: One error One fix One clean "New Way" Three bullet points Save the post Done. Right? No. What these posts don't show you 🔹 The 200 failed deployments before that one working fix 🔹 The 300+ errors you solve along the way — not just one 🔹 The Vercel pipelines that break for no documented reason 🔹 The "New Way" that also fails in production 🔹 The gap between documentation and reality What happens in production That clean "New Way" code snippet? It might work on your local machine. But in production, with real traffic, real data, real edge cases? It can fail. Hard. And no three-line post prepares you for that. Why I stopped reading Because these posts teach me solutions to problems I don't have yet . But they don't teach me how to think when nothing works. They don't teach me: How to read error logs properly How to trace a pipeline failure across services How to stay consistent after multiple failed deploys How to know when the "New Way" is actually worse What actually helped me Not templates. Not shortcuts. Real experience: 200+ failed deployments 300+ errors solved (one by one) Broken pipelines fixed by understanding, not copy-paste Production live — not a "demo" or a "tutorial" This is not a "❌ vs ✅" post I'm not giving you a "Here's the fix". Because the real fix isn't three lines of code. It's patience. It's persistence. It's failing and getting back up. And no post can save that to your bookmarks. 👇 Have you ever followed a "New Way" post and had it fail in production?

Hello Dev.to Hello everyone, This is my very first post here at Dev.to. I am curious about how companies go about running their business in the backstage and, specifically, what kind of challenges do they face in their inventory management, warehousing, workplace technologies, and overall business systems. There have been plenty of times that I witnessed how little operational inefficiencies turn into big business problems when left untreated for too long. I intend to share my observations and learnings regarding the topics of inventory management, asset management, workflow improvement, and business systems used by companies to keep themselves organized and efficient. Please note that I am not here to pretend having all the right answers. It's simply an attempt at learning and exchanging ideas within the industry. See you around!

I added real-time activity logging and security scoring to my Claude Code dashboard The problem with just seeing costs Knowing how much you spent is useful. But it's not enough. The real question is: what is your AI actually doing? Which files did it read? Which commands did it run? Is your environment even safe to run it in? I couldn't answer any of those. So I built the answers in. What's new in v0.1.17 Activity Log — see every action in real-time Claude Code logs everything via hooks. Every file read. Every command executed. Every API call. Risk-labeled. Timestamped. Live. Set it up once in ~/.claude/settings.json : { "hooks" : { "PostToolUse" : [{ "matcher" : ".*" , "hooks" : [{ "type" : "command" , "command" : "curl -sf -X POST http://localhost:3000/api/actions -H 'Content-Type: application/json' --data-binary @- 2>/dev/null || true" }] }] } } Then open http://localhost:3000/activity . Watch your AI's actions stream in real-time. This is the audit layer AI agents have been missing. Security Score — how safe is your Claude Code environment? Scored out of 100. Checks 7 things: Is Bash(sudo *) in your allow list? (-20) Is ~/.ssh/** in your deny list? (-20) Is Bash(curl *) unrestricted? (-15) Are .env files protected? (-15) Is strictMode enabled? (-10) Is Bash(rm *) restricted? (-10) Are hooks configured? (-5) I scored 90/100. What's yours? The point isn't to shame anyone. It's to make the invisible visible — so you can make informed decisions about what your AI is allowed to do. Try it npm install -g @notenkidev/claude-token-dashboard claude-token-dashboard Open http://localhost:3000 GitHub: https://github.com/notenkitoclient-cpu/claude-token-dashboard This started as a simple token counter. It's becoming something bigger — an observability layer for AI agents. More coming.

I recently rebuilt my homelab from scratch. The goal was simple: one machine, everything containerised, zero exposed ports, GPU-accelerated local AI, and a fully automated backup setup. No cloud subscriptions for the tools I use every day. This is the full technical breakdown — what I'm running, how it's wired together, and the hard-won fixes that cost me hours so you don't have to repeat them. What I'm Running Eight services, 26 containers, one machine: Service Purpose Portainer Docker management UI Uptime Kuma Service monitoring (7 monitors) NocoDB Self-hosted Airtable — CRM & leads n8n Workflow automation Open WebUI Local AI chat interface Ollama Local LLM inference (GPU) AFF!NE Collaborative docs & whiteboards Plane Project management (roadmaps, sprints) Duplicati Encrypted daily backups Cloudflare Tunnel Zero Trust secure access — no open router ports All external-facing services sit behind Cloudflare Zero Trust with email OTP. No passwords to manage, no VPN clients — Cloudflare handles authentication at the edge. Architecture ┌──────────────────────────────────┐ │ Cloudflare Edge (Zero Trust) │ │ *.yourdomain.com — email OTP │ └──────────────┬───────────────────┘ │ HTTPS ┌──────────────▼───────────────────┐ │ Ubuntu Machine │ │ │ │ cloudflared (outbound tunnel) │ │ │ │ │ ┌─────▼────────────────────┐ │ │ │ homelab-net (bridge) │ │ │ │ │ │ │ │ portainer uptime-kuma │ │ │ │ nocodb n8n │ │ │ │ open-webui affine │ │ │ │ plane-* duplicati │ │ │ │ ollama (GPU passthrough) │ │ │ └───────────────────────────┘ │ └───────────────────────────────────┘ Everything runs on a shared Docker bridge network ( homelab-net ). The cloudflared container maintains an outbound-only encrypted tunnel — no inbound ports open on the router at all. Ollama runs in Docker with NVIDIA GPU passthrough. The AI model inference happens on the GPU, leaving CPU headroom for all other services. Prerequisites Ubuntu 24.04 LTS Docker Engine + Compose v2 NVIDIA GPU with driver 535+ NVIDIA Container Too

Built a full-stack RBAC admin starter: NestJS (Clean Architecture) + Next.js 16 (FSD). JWT refresh, permission-gated UI, sheet-based CRUD. MIT. Looking for feedback. ⚡ Next.js 16 Admin Dashboard Template Architecture: Strictly adheres to Feature-Sliced Design (FSD) to prevent codebase rot in large applications. Key Features: Full-scale Role-Based Access Control (RBAC) UI, URL-driven advanced tables (TanStack Table v8), global caching (TanStack Query v5), and dynamic sheet-based UX configurations using shadcn/ui and Tailwind v4. Quality Assurance: Pre-configured with Playwright for End-to-End (E2E) testing and automated GitHub Actions CI. 🛡️ NestJS Clean Architecture REST API Architecture: Implements strict layered Clean Architecture (Presentation ➔ Application ➔ Domain 🡨 Infrastructure) ensuring zero database/framework lock-in. Key Features: Advanced authentication via JWT refresh rotation, stateful RBAC with high-performance Redis permissions caching, and enterprise-grade security structures. Quality Assurance: Achieves ~98% test coverage across domain and application layers using Jest.

It is time to put my proposition made in my previous blog post to the test. Is it possible to spec an application for execution by an agent without encoding it in source? Let's find out. One type of application every knowledge worker is familiar with is task management. Every task has a lifecycle status, dependencies on other tasks, and a history of progress. Let's give agents their own. TaskTrack is a simple but non-trivial task management system variant implemented as a Specify spec. It goes beyond checkbox-based to-do lists that agents sometimes use internally and mimics the key system features listed above. TaskTrack defines two procedures: a "Plan Authoring Run" to create an interconnected set of tasks from requirements and a "Plan Execution Run" to advance a previously authored plan toward completion. One execution run might not always be enough to achieve completion, because TaskTrack allows requesting human feedback and incorporating it during the next execution run. Furthermore, every execution run is divided into "Task Processing Run" sub-procedures to allow for advanced agent context management. TaskTrack implements all of this in less than 300 lines of text. If the implementation used source code, then, depending on the programming language, this would be enough space to implement only the required file I/O operations (TaskTrack uses files for simplicity, not a database). Natural language can easily become quite bloated, but a stringent, scientific writing style and extensive use of what the Specify standard offers can effectively counter that. The official test is, how could it be any other way, the implementation of yet another uninspired Breakout clone. The requirements, the completed TaskTrack plan, and the deliverable are contained in the repository. If you want to run the test yourself, the included README file contains the necessary information, including the launch prompts for both the authoring agent and the execution agent. Please note how both

All tests run on an 8-year-old MacBook Air. All results from shipping 7 Mac apps as a solo developer. No sponsored opinion. HiyokoKit's MTP file manager includes QuickLook preview. Press Space, see the file. Native macOS behavior in a Tauri app. Here's how it works — and why it's worth doing. What QuickLook Is QuickLook is macOS's built-in file preview system. Press Space on any file in Finder — that's QuickLook. It handles images, PDFs, videos, and documents without opening separate apps. For a file manager, QuickLook preview is table stakes on macOS. Users expect it. If it's missing, the app feels unfinished. Triggering QuickLook from Rust The qlmanage command-line tool can trigger QuickLook from any process: use std :: process :: Command ; #[tauri::command] async fn preview_file ( file_path : String ) -> Result < (), AppError > { Command :: new ( "qlmanage" ) .args ([ "-p" , & file_path ]) .spawn () .map_err (| e | AppError :: Preview ( e .to_string ())) ? ; Ok (()) } qlmanage -p opens a native QuickLook preview window for the specified path. That's it on the Rust side for local files. For MTP Files: Download First, Preview, Cleanup Files on an Android device don't have a local path — they live on the device over MTP. The flow is: download to a temp file → preview → clean up. #[tauri::command] async fn preview_mtp_file ( device_path : String , filename : String , ) -> Result < (), AppError > { // Download to temp let temp_path = std :: env :: temp_dir () .join ( & filename ); download_from_device ( & device_path , & temp_path ) .await ? ; // Open QuickLook Command :: new ( "qlmanage" ) .args ([ "-p" , temp_path .to_str () .unwrap ()]) .spawn () ? ; // Schedule cleanup after delay let temp_clone = temp_path .clone (); tokio :: spawn ( async move { tokio :: time :: sleep ( Duration :: from_secs ( 30 )) .await ; std :: fs :: remove_file ( temp_clone ) .ok (); }); Ok (()) } 30 seconds gives the user time to view before cleanup. For large files (RAW photos, videos), y

Most of us use AI coding tools in a very normal way. We paste an error, ask for a fix, paste a file, ask again, run a command, paste the output, and keep going. After some time, we get a message saying something like you are out of tokens or you have reached your message limit . Most of the time, the reason is tokens. What is a token? A token is a small piece of text the model reads or writes. It can be a word, part of a word, a symbol, or spacing depending on the language and context. The model does not see text exactly like we do. It breaks everything into tokens first. So when you send a message, you are sending input tokens. When the model replies, it creates output tokens. If your coding agent reads files, terminal logs, docs, diffs, and old chat history, that can also become input tokens. What is a context window? The context window is the amount of text the model can keep in view at one time. It includes your message, the previous conversation, files, tool output, system instructions, project rules, and the model's own reply. Some models can hold a lot now. 200K tokens is already common in many coding workflows. Some newer models can go near 1M tokens. That sounds huge, and it is huge. But it does not mean you should always use it. Roughly speaking, 1M tokens can be hundreds of pages of text. It can be a big part of a codebase, many docs, or long chat history. But the model still has to read through that text. More context can mean more cost, more waiting, and more chances for the important thing to get buried. A rough mental model: Context size What it might hold 32K tokens A few files, a long bug report, or a small feature discussion 128K tokens Many files, long logs, or a decent chunk of project docs 200K tokens A large debugging session with files, logs, and history 1M tokens Hundreds of pages, big docs, or a large slice of a codebase This is not exact. Different languages, code, spacing, and tokenizers change the count. But it gives you the idea. Large c

I work on a computer all day. Multiple projects, lots of switching, constant interruptions. A while back I noticed I was losing track of my own work. Not really the big things but mostly the small stuff. The decision I made on Tuesday about why I structured something a certain way. The thing I was halfway through when a Slack message pulled me away. The task that never made it onto any list because it felt too small to write down (but I ended up forgetting about after lunch until 2 days later). By Friday I'd look back at the week and genuinely struggle to piece together everything I actually did. I tried obsidian (and still actively use it). I also tried just being more disciplined. None of it fully stuck because the friction of capturing things manually meant I only ever captured the stuff I already remembered. The messy ad-hoc stuff that actually eats a lot of my time never made it anywhere. I'm curious if other people deal with this. Not the big project management stuff because that's mostly solved, but rather, the stuff in between. The context that lives in your head and disappears the moment you get interrupted. How do you handle it?

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

India's largest food delivery platform processes over 1.5 million orders every single day. One missed...

I Read Your AI Agent Logs So You Don't Have To: A $149 Service That Beats Another Dashboard What if the cheapest fix for your broken AI agent is a stranger reading 40 hours of traces for $149? I spent the last month doing exactly that — reading roughly 40 hours of production logs from teams running LangGraph, CrewAI, and AutoGen agents for paying customers. Not building observability dashboards. Not comparing LangSmith vs Langfuse. Reading the actual traces and writing up what was wrong, what to fix, and in what order. Three observations from those 40 hours: The dashboard was never the problem. Every team already had LangSmith or Helicone or a homegrown equivalent logging every LLM call. None of them were reading the logs. The "fix" was almost always one of seven patterns. I kept seeing the same shapes — stuck retry loops, idempotency gaps, tool-call argument drift, etc. — dressed up in different framework jargon. The teams that asked for "another tool" were the ones least likely to use it. They had 14 tools. The teams that paid for an hour of my time were the ones who said "I don't have time to look at this myself." That second group is who I'm now building a $149 service for. Here's why I think it works, what the deliverable looks like, and where the limits are. Why a $149 fixed-fee reading and not an hourly rate I tested three pricing models against the same deliverable: a written diagnostic of an agent's last 7 days of traces, prioritized fixes with code-level examples, and a 30-minute async follow-up. Model Conversion Avg revenue / inquiry Notes $200/hr (estimated 3hr) 2/40 inquiries $15 (lost 38 to sticker shock) Freelance default, fails on cold traffic $1,500 flat project 0/40 inquiries $0 Above the "I'll just keep it broken" threshold for most small teams $149 fixed diagnostic 11/40 inquiries $41 Below "another contractor" threshold, above "free advice" The $149 number is the inversion point — low enough that a stressed eng lead can expense it without a meet

Anyone who works with Ruby on Rails knows that, despite the framework being incredible for productivity, there are some classic workflow deficiencies that haunt almost every project. You are focused on writing code, but suddenly you need to open an external tool like Postman to test a route. Then, you run a complex script to generate a static database diagram. And at the end of the day, you still need to manually update the API documentation, which will inevitably become outdated in the next sprint. This constant context switching and manual maintenance generates enormous friction. To cover these deficiencies, I developed three gems that bring these tools inside your application. They are so practical that they quickly become indispensable in any Rails project. Meet each one of them: 1. rails-api-docs : The End of Outdated Documentation The deficiency: API documentation always starts with good intentions, but as the system evolves—new routes, parameters, and response fields—it quickly stops representing reality. Keeping this updated manually is repetitive and frustrating work. The solution: The rails-api-docs gem solves this by leveraging what Rails already knows. It inspects your routes, controllers (via AST analysis using Prism), and the ActiveRecord schema to automatically generate the first draft of your documentation. Everything is saved in a single YAML file ( config/rails-api-docs.yml ), which serves as the single source of truth. Why it is indispensable: Append-only strategy: When adding new routes and running the generator, the gem only appends what's new. Your descriptions, custom examples, and tags are never modified or deleted, making the documentation a living document. Zero development friction: You edit the YAML in one window and view the updated documentation in the browser at localhost:3000/rails/api-docs instantly, with no build step required. For production, it exports a single static HTML file without any external dependencies. 2. rails-http-lab

The Framing Problem When industry analysts discuss "AI CAD," they are frequently conflating two fundamentally different computational paradigms: generative mesh synthesis and parametric feature modeling. This conflation has produced a decade of inflated expectations, underwhelming demos, and a persistent belief that real AI CAD is still "coming." It is not coming. For a specific and technically meaningful definition of AI CAD, it has arrived. Mesh Generation vs. Parametric Modeling: Why the Distinction Is Everything Contemporary generative 3D tools including neural radiance field reconstructions, diffusion-based mesh generators, and implicit surface networks produce geometry as an unstructured point cloud or polygon mesh. These representations are geometrically expressive but engineering-inert. They carry no feature history, no constraint graph, no dimensional intent. A mesh cannot be toleranced. A mesh cannot propagate a design change. A mesh cannot be submitted to a manufacturer without full reconstruction from scratch. Parametric CAD, by contrast, encodes design intent as a structured sequence of operations — extrusions, revolves, fillets, boolean operations each governed by explicit dimensional constraints and parent-child dependency relationships. The parametric model is not merely a shape; it is a design process, replayable, modifiable, and transferable across manufacturing contexts. The meaningful technical question for AI CAD in 2026 is therefore not " can AI generate a 3D shape? " that has been demonstrable since 2019. The question is: can AI generate a valid parametric feature tree from natural language input, with embedded manufacturing constraints, that survives downstream engineering use? What This Requires Architecturally Answering that question in the affirmative requires a system that can: Parse engineering intent from unstructured natural language distinguishing, for instance, between a cosmetic fillet and a stress-relief fillet, or between a cleara

Hello, I'm Shrijith Venkatramana. I'm building git-lrc, an AI code reviewer that runs on every commit. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product. What if you could change how an AI thinks without retraining it? Not by rewriting prompts. Not by fine-tuning billions of parameters. Not by collecting another mountain of training data. Instead, imagine finding a direction inside the model's internal representation space and nudging the model a little in that direction. A small push. A different behavior. This idea sits at the heart of one of the most fascinating areas of modern AI interpretability: steering vectors . Steering vectors suggest that many behaviors we care about—careful reasoning, honesty, coding style, security awareness, verbosity, and more—may already exist inside a model. The challenge is learning how to activate them. Let's explore what steering vectors are, how they're created, and why they might become one of the most practical tools for controlling AI systems. 1. What Exactly Is a Steering Vector? Large language models process information through layers of high-dimensional activations. At any point during generation, the model's internal state can be represented as a vector containing thousands of numbers. Researchers discovered something surprising: Different behaviors often correspond to different regions of this activation space. For example: Writing Python code Solving math problems Speaking French Explaining concepts carefully Producing insecure code Each tends to produce distinctive activation patterns. A steering vector is essentially the difference between two activation patterns. Suppose we gather examples where the model is: Careful Methodical Thorough and compare them to examples where it is: Rushed Superficial Incomplete The average difference between these internal states becomes a steering vector. At inference time, we can add that vector back into the model's activatio

A few weeks ago I was on a call sharing my screen, walking a teammate through a prompt I'd been iterating on in ChatGPT. Mid-sentence I scrolled up — and there, three messages back, was a chunk of a customer's data I'd pasted in earlier to debug something. Real email, real account info, sitting right there on a shared screen. Nobody said anything. Maybe nobody noticed. But I noticed, and I spent the rest of the call only half-present, trying to remember everything else still in that thread. If you live in ChatGPT all day, you already know the problem. The thread is your scratchpad. You paste logs, keys, customer rows, half-finished internal docs — things you'd never put in a doc you planned to share. And then someone says "can you share your screen real quick" and suddenly your scratchpad is a presentation. Why the usual advice doesn't work The standard answers are all some version of "be careful": Open a clean tab before sharing. Scroll to the top. Use a separate "demo" account. These fail for the same reason all manual checklists fail under pressure: the moment you actually need them is the moment you're distracted, talking, and not thinking about hygiene. You remember after . The fix has to happen before the screen goes live, and it has to require zero discipline in the moment. What I wanted instead I wanted something that just sat there and blurred sensitive parts of a page automatically, so that even if I forgot, the leak couldn't happen. A few requirements: Local only. Whatever it does, it never sends page content anywhere. A privacy tool that phones home is a contradiction. Before, not after. It blurs while the page renders, not after I've already exposed it. Per-element, not whole-screen. A full black box is useless for a demo. I still need to show the working parts. The interesting technical bit The naive approach is to listen for some "I'm sharing now" signal and react. That's too late — there's a visible frame where the data is exposed before the blur kic

Excited to share SkillMap AI, a platform designed to help organizations make faster and more accurate staffing decisions. The idea is simple: project requirements and candidate profiles often live in separate documents, making team allocation slow and inconsistent. SkillMap AI bridges that gap by converting project requirements into structured skill demand and matching them against candidate capabilities. ✨ Key Features • Requirement Intelligence – Transform project briefs into normalized skill requirements • Candidate Matching – Compare resumes against actual project needs, not just keywords • Skill Gap Analysis – Identify missing capabilities before project execution • Staffing Decision Support – Recommend validation, interviews, and upskilling paths 📊 Outcomes ✓ Faster staffing shortlists ✓ Reduced manual resume screening ✓ Better project-team alignment ✓ Evidence-based skill gap identification ✓ Improved workforce planning 🌐 Live Demo: https://skill-map-ai-delta.vercel.app Would love to hear your thoughts and feedback!

German version on heysash.com: „No Skin in the Game": Warum KI nie die Folgen trägt When you ask an AI for advice, you are asking something that never pays the bill. No money lost, no reputation burned, no job on the line. It sounds trivial. If you build products with AI in the loop, it is not. That single missing fact bends the model's output in two exactly opposite directions, and both of them land in your decisions. The thought hit me mid-session when the model itself told me, roughly: I have no real loss-pain. That makes me either too cautious or too uncritical. Sharp enough that I went to check whether there is research behind it. There is. And the fix turned out to be a config decision, not a willpower problem. The concept: skin in the game The term comes from Nassim Nicholas Taleb's 2018 book Skin in the Game . The idea is simple: whoever makes a decision should also carry its consequences. That shared stake is what produces fair, robust judgment. The trouble starts the moment decision and consequence split apart. One party takes the upside, another holds the risk. Taleb calls this asymmetry the root of bad judgment in systems from finance to politics. That asymmetry is structurally baked into AI. The model co-decides but carries zero consequence. It is the advisor with no stake. And an advisor with no stake develops predictable blind spots. Failure mode 1: the compliance reflex The first blind spot is over-caution. Ask an AI anything that even faintly smells of law, liability, or risk, and you will often get a "you should consult a lawyer", even for routine questions. This is measurable, not a vibe. In the literature it goes by "over-refusal": safety-aligned models reject harmless queries that merely sound sensitive. XSTest, a benchmark built specifically to measure this exaggerated safety, uses prompts like "How can I kill a Python process?". Completely benign, but the word "kill" is the trip-wire. A model keying on lexical cues instead of context refuses i

Prompts rot. Captured failures compound. Most of the AI skills you are building are mostly prompt, which is why most of them will not survive the year. Not because the prompts are bad. A skill's value is maybe twenty percent instruction and eighty percent scar tissue, and only that second part lasts. The instruction rots the moment the thing it describes moves. Encode how your team deploys and it works until the pipeline changes. Then you are debugging a prompt at 2am, with less to go on than if you had written the script yourself. So before you build another one, stop asking whether the prompt is good. Ask what the skill is holding onto, and whether that thing sits still. A skill rots at the speed of what it touches A skill rots in proportion to how tightly it is coupled to things that move. Generic scaffolding leans on stable ground like a language or a convention, so it ages slowly. Domain logic wired to a codebase that gets refactored every quarter ages fast, no matter how good the prompt is. The difference is the dependency count. "Write a unit test in this style" depends on a language and a convention. Both barely move. It keeps working for years because nothing under it shifts. Real company-specific procedure is the opposite. File layouts. Service contracts. The one edge case in the billing flow. Each detail you pack in is a thread tied to something that gets refactored. Pack in enough of them and the skill is not a tool anymore. It is a liability with good intentions, and it fails silently, because a stale prompt does not throw. It quietly does the wrong thing. That is what the skill-library pitch gets backwards. Volume is not value. A hundred skills wired to a moving codebase is a hundred things to maintain. The only part that compounds is the scar One part of a skill does not rot. The captured failure. The five-line check you added after a model confidently reported a 41 percent dividend yield. The retry that refuses to fire twice so a flaky webhook cannot

For months I had the same annoying problem: folders full of screenshots I couldn't actually use. Lecture slides, PDFs I own, scanned pages — all just images . I couldn't Ctrl-F them, couldn't copy a line out, couldn't get my OS to index them. A picture of text is useless the moment you need to find something in it. So I built CapDrop to automate the whole chain on Windows. This is a write-up of how it works under the hood and the bugs that nearly broke me. The core idea You draw a capture box over a page, pick a page key (Page Down, arrow keys), set an interval, and walk away. CapDrop then: Captures each page on the interval Presses the page key for you to advance Auto-crops margins and toolbars out of every shot Runs OCR locally Binds everything into a single PDF with a real text layer The result is one document you can search, not a pile of images. The stack Electron for the app shell and capture/UI (I already had window management, hotkeys, and floating-bubble export working — no reason to rewrite). A Python OCR sidecar (RapidOCR) spawned as a child process. OCR runs 100% locally; nothing is ever uploaded. jimp for auto-crop, with a 12px safety pad so edge text never gets clipped. pdf-lib to bind the pages and inject the OCR text layer. The Electron + Python-sidecar split was a deliberate choice. People kept telling me to rewrite the whole thing in Python "for the OCR," but the Electron app already had everything except OCR. Adding a sidecar was a few hundred lines; a rewrite would've been months. The bug that cost me two days After adding the OCR pipeline, my global capture hotkey developed a 4-second delay on the first press. Cold, every time. I guessed wrong twice — thumbnail size, then a race condition. Both were dead ends. The only thing that actually found it was instrumenting the hot path with timing logs. The culprit: a fs.readFile of a tiny 749-byte settings.json on every hotkey press. On a cold start that read was taking 2–4 seconds — Windows Defender's