标签：#code

We have all been there: you open your editor to write a simple feature, and within ten minutes, your screen is a chaotic mess. You are drowning in squiggly red lines, bright rainbow bracket lines, a crowded sidebar, Git blame popups blocking your text, and terminal notifications screaming for attention. Modern IDEs like VS Code and Cursor are incredibly powerful, but out of the box, they are built to distract you. If you want to achieve true flow state, you need to strip away the noise. Here are 10 minimalist extensions built for both VS Code and Cursor that are explicitly engineered to eliminate clutter, reduce cognitive load, and help you focus on the only thing that matters: the code. Interface and Zen Mode Cleansers 1. Zen Mode (Built-in, but needs tweaking) The Vibe: Complete visual isolation. What it does: While not an external extension, true minimalism starts here. Hitting Cmd+K Z (or Ctrl+K Z) instantly hides the activity bar, status bar, sidebar, and editor tabs, leaving you with nothing but your code centered on the screen. The Focus Trick: Go into your settings and toggle zenMode.hideLineNumbers to true to get rid of the left-hand numbering margin entirely for deep reading sessions. 2. APC Customize UI++ The Vibe: Pixel-perfect control over editor bloat. What it does: If you love the layout of hyper-minimalist editors like Zed but want to keep the power of Cursor or VS Code, this is your holy grail. It allows you to shrink font sizes of the UI independently from your code, hide specific layout borders, trim the massive top title bars, and customize panel padding to give your code room to breathe. 3. Customize UI / Active Bar Hidden The Vibe: Moving target elements out of sight. What it does: The left-hand Activity Bar (with the extensions, search, and source control icons) is a constant source of colorful badge notifications. Use this to hide it entirely. You can easily trigger those panels via keyboard shortcuts (Cmd+Shift+E for explorer, Cmd+Shift+F fo

The call-order change came back pass-with-risk. I read the recommendation, saw it had a name and a reason, and felt the task close. Then I looked at the row under it. How was this verified: not run. Nobody had run the queue. I had a label. I did not have proof. This is Part 6 of The Contract Think produced a brief. Plan produced a gate. Build executed inside it. Review scored every requirement against a verdict instead of an impression. Review reads the diff and the plan and decides whether one satisfies the other. It does not run the queue. It cannot. Its whole job is judgment about what the code should do. Test is where someone finally checks what the code actually does. I had been treating those two as the same step. They are not. Test asks one question, and a verdict is not the answer For every active requirement, Test asks how it was verified. Command run, manual QA, or a comparison against known-good output. One of those three, or a written reason none of them ran. Not a recommendation. Not a risk level. Evidence. I built the matrix against the plan's requirements and filled in each row. Most had a command behind them. The call-order requirement had nothing. The cell read not run, and it sat directly below a pass-with-risk that already carried a name and a reason. That name had almost been enough for me. A named risk feels handled. It is not. It is a risk with a label on it, waiting for someone to actually look. So I ran the queue Three notifications, all with a real reason to fire within the same tick. The scheduler picked them up and ordered them by priority instead of arrival. Two landed in the sequence the requirement wanted. The third jumped ahead of a lower-priority notification that was still mid-processing. The change worked almost every time. Under one timing condition, it did not. That is the gap a verdict cannot see. Review had marked the requirement partial because the wording left the mechanism open. Running it found a real failure inside the mech

Why I Choose Lovable for Building Full-Stack Applications with AI Over the last year, AI-assisted software development has evolved from generating code snippets to building complete web applications. We've all seen tools like Cursor, Claude Code, GitHub Copilot, Replit Agent, Bolt, and many others enter the market. Each has its strengths, but after experimenting with several of them, I keep coming back to Lovable whenever I want to build a new web application from scratch. This isn't a sponsored post—it's simply the workflow that has worked well for me. If you're interested in trying Lovable, you can use my referral link below. Disclosure: new users receive additional signup credits, and I receive referral credits if you sign up through it. Referral: https://lovable.dev/invite/AQ02SOZ Why Lovable Stands Out Most AI coding assistants help you write code. Lovable helps you build an application. Instead of focusing on individual functions or files, it takes a higher-level approach where you describe what you want, and it generates a complete full-stack application that you can continue refining. A typical workflow looks like this: Idea │ ▼ Describe the application │ ▼ Lovable generates • Frontend • Backend • Database • Authentication • API integration │ ▼ Preview instantly │ ▼ Connect GitHub │ ▼ Iterate and Deploy Unlike traditional no-code platforms, you're not locked into a proprietary editor. Lovable supports GitHub synchronization, native Supabase integration for authentication and PostgreSQL-backed data, and deployment options ranging from Lovable-hosted apps to your own infrastructure. Why I Keep Choosing Lovable After building several side projects, these are the reasons I continue to use it. 1. Rapid idea-to-production workflow The biggest productivity gain isn't AI-generated code. It's reducing the number of decisions needed before users can interact with your application. Instead of spending hours creating project structure, authentication, routing, database

You start the morning with four Claude Code agents running, each in its own git worktree, each on a separate task. By mid-afternoon something is off. One agent has re-implemented a helper another already wrote. A second built against an interface that a third changed an hour ago. A fourth made a naming choice that contradicts a decision you made — out loud, to yourself — at 9am. Every diff is reasonable on its own. The system they add up to is not. This is the failure mode that shows up the moment you go from one agent to several. The code each agent produces is fine. What drifts is everything between the agents: the decisions, the conventions, the current shape of the interfaces they all depend on. Running the agents in parallel is the easy part. Keeping them coherent is the hard part, and it's a different problem. Why parallel agents drift An agent's context is per-session. Each Claude Code instance has its own context window, populated by what it has read and done in that session. Nothing about that window is shared with the agent running in the next worktree. There is no common memory they all write to and read from. So when agent A decides "we use the repository pattern for data access," that decision exists in exactly two places: agent A's context, and your head. Agent B never hears about it. Three kinds of state cause the drift, and they're worth separating because they need different handling: Decisions already made. Architecture, naming, conventions, the approach you settled on for a cross-cutting concern. These are durable — once made, they should bind every agent, including ones you spawn tomorrow. The current contract. The shape of the interfaces, types, and APIs that agents share. This changes during the work: agent A edits a signature, and agents B and C are now building against a version that no longer exists. What's in flight. Who is touching which files right now. Two agents editing the same module in separate worktrees won't see each other until th

Introduction When learning JavaScript, one of the first concepts you’ll encounter is functions. Functions are the building blocks of JavaScript. They help you organize code, avoid repetition, and make your programs easier to understand. If variables store data, functions define behavior . You’ll use functions everywhere: handling user input, processing data, calling APIs, and structuring your code. In this article, we’ll cover: What is a function Function declarations Function expressions Parameters vs arguments Return values Arrow Functions Why Functions Matter 1. What is a Function? A function is a reusable block of code designed to perform a specific task. Think of it like a machine: Input → Process → Output function greet () { console . log ( " Hello! " ); } To run the function, you call it: greet (); // Hello! 2. Function Declaration This is the most common way to define a function: function add ( a , b ) { return a + b ; } 💡 Explanation: Defined using the function keyword Can be called before it is declared (because of hoisting) Key parts: function → keyword add → function name a, b → parameters return → output value add (); // ✅ Works! function add ( a , b ) { return a + b ; } 💡 Why does this work? JavaScript reads the code first, and function declarations are stored in memory during the initial phase (hoisting) . That’s why you can call the function even before it’s defined in the code. 3. Function Expressions Functions can also be stored in variables: function add ( a , b ) { return a + b ; } 💡 Explanation: Assigned to a variable Cannot be used before initialization add (); // ❌ Error: Cannot access before initialization const add = function ( a , b ) { return a + b ; }; 💡 Why does this cause an error? Because: const add has not been initialized yet when it is called. The function itself is not in memory at that moment . 4. Parameters vs Arguments This is a common beginner confusion: Parameter: variable in function definition Argument: actual value passed i

Hey everyone! 👋 I'm a complete beginner and today I'm officially kicking off my #100DaysOfCode challenge with Python. I've dabbled with the idea of learning to code for a while, but this time I want to actually commit - so I'm posting daily updates here to keep myself accountable and track my progress over the next 100 days. My plan: Post a short update here every day - what I learned, what I struggled with, and what's next Eventually move into some small real-world projects once I've got the basics down Why I'm doing this: I want to build real skills, not just "watch tutorials and forget everything." Writing it down publicly (even anonymously) keeps me honest and hopefully connects me with others on the same path. If you're also learning Python or doing a 100 days challenge, I'd love any tips, resources, or just to follow along with each other's progress! Day 1 status: Just setting up my environment and going through the basics — nothing exciting yet, but everyone starts somewhere! 100DaysOfCode #Python #Beginner #LearnToCode

CCA-Audit — open source (MIT) AI code review has a trust problem, and it's not that it misses bugs. It's that it invents them. If you've run an LLM over a diff, you've seen it: a "possible null dereference" on a value that's guarded three lines up. A "SQL injection" your ORM already parameterizes. A "race condition" that can't happen. And then — worse — it confidently rewrites working code to "fix" the thing that was never broken. The real bug, meanwhile, sits quietly in the noise. The problem isn't intelligence. It's that most AI reviewers report their first impression as a verdict. A model reads a diff, pattern-matches "this looks like X," and emits a finding — without ever going back to check whether X is actually reachable in this code. Humans do a second pass ("wait, is price validated upstream?"). Most AI-review pipelines skip it. Here are two gates that add that second pass — and a stress test showing what they catch. Gate 1: verify findings before you fix (anti-hallucination) The idea is simple: no finding is allowed into the fix plan until a separate step re-checks it against the real code. After the auditors produce findings, a verification pass takes each one and asks three questions: Does the issue actually exist at the cited line? Is it in the code that changed, or a pre-existing thing outside the diff? Is the stated impact real, or already mitigated elsewhere — a guard upstream, a value validated before this point, a config defined in another module? The key design choice: bias the verifier toward refuting. A wrongly-confirmed finding causes a needless (sometimes harmful) fix; a wrongly-dropped one is cheap to recover. So when the evidence isn't clear, drop it or escalate to a human — don't fix on a hunch. This one step kills the majority of hallucinated findings, because hallucinations rarely survive contact with "show me the exact line, and prove the impact can occur." Gate 2: prove the fix maps to the finding (anti-regression + provenance) Catching

We’ve got another special episode of Decoder today, recorded at the Cannes Lions advertising festival in the South of France. I’m talking with Ali Berman and Raina Penchansky, who run the Creators division at United Talent Agency. UTA is an enormous talent agency. Half the people you’ve ever heard speak or perform or who show […]

In this episode, Alex Zenla (CTO/Co-founder, Edera) challenges the "laissez-faire" attitude toward modern infrastructure. She promotes "spite-driven development", building software to solve genuine technical pain points rather than passively accepting flawed abstractions, as a philosophy of improving the world of software. By Alex Zenla

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

The evening Étienne asked to see the numbers Tuesday evening, end of the day, the open space had cleared except for Étienne. Étienne holds sixty percent of the house and spends his working week at a fund that acquires software publishers, and he looks at ERPs all year the way others read balance sheets. He sat on the edge of my desk, a metal water bottle in hand, and said what he always says when he senses someone is telling themselves a story. "What's that based on?" I was about to answer with a narrative. Sixty days of solo production on Rembrandt with Claude Code, learning the doctrine, the in-flight retractions, the incidents that hardened the rules. The declarative form was ready. But Étienne doesn't ask for a narrative, he asks for the material inventory. So I opened a terminal and let wc -l speak. This article is what I should have given him without waiting for him to ask — the dry, numbered balance, what worked, what didn't, what I would do differently. Not a success story, not a cautionary tale . Just the audit nobody runs on DEV.to because we're all too busy publishing the parts that shine. What's at stake behind Étienne's question is less the performance of a device than the possibility of measuring it honestly. Sixty days of practice with an AI assistant on a production project is a rare object at this stage. Most publications circulating on the subject are either brief demos from a hackathon or marketing announcements from vendors. The field return at sixty days, delivered with its numbers and retractions, barely exists. That's the gap I intend to close here, without more pedagogy than is strictly needed. The dry material inventory Sixty calendar days between the first session and today. Fifty-eight active days out of sixty , meaning two days without a commit and explaining why the rest of my life barely held. Over that window, the repo accumulated nine hundred and eighty-four commits bearing my name — an average of sixteen commits per working day, on d

GA in a sentence GitHub moved its enterprise managed-settings.json to general availability on July 1, giving GitHub Enterprise Cloud admins a single JSON file that overrides Copilot behaviour in VS Code and Copilot CLI for anyone holding a Copilot Business or Copilot Enterprise seat issued from the enterprise or one of its organizations. The changelog frames it as a place to define AI standards for the tenant. In practice it is a supported home for Copilot policy that shipped one setting at a time in beta up to this point. The five keys the file accepts Five keys are documented at GA: extraKnownMarketplaces , enabledPlugins , strictKnownMarketplaces , disableBypassPermissionsMode , and model . Together they configure trust for extra plugin marketplaces, the enabled-plugins list, strict enforcement of the known-good marketplace list, whether Copilot CLI and the VS Code extension can run in bypass-permission mode, and which model a user is allowed to pick. Value shapes are not enumerated in the changelog itself; the docs page is the reference for the schema. How the file reaches a client The file lives at copilot/managed-settings.json inside the .github-private repository of the organization the enterprise nominates for the role. There is a backward-compatible path at .github/copilot/settings.json for tenants already using the older layout. Copilot clients fetch the file from the server on every authentication, hold it in memory, and refresh it hourly, per the changelog. That server-side file takes precedence over the file-based config a user may have on their own machine. Setup runs through the AI Controls tab in enterprise settings, or the equivalent API endpoint, where an admin picks the hosting organization. Anyone who followed the June rollouts of disableBypassPermissionsMode and strictKnownMarketplaces will recognise the same file and the same repo. GA is what turns the plumbing into a supported product surface. Where it will trip you Two operational details are

Alibaba has reportedly classified Claude Code as high-risk software.

If you've ever built a feature that extracts text from PDFs, an Arabic-speaking user has probably filed this bug: "the words come out in reverse order." Not the letters — the words . Every line reads last-word-first. I spent the better part of a year fixing this class of bugs while building Confileo , a free PDF toolkit with first-class Arabic support. Here's what's actually going on, because almost every explanation online is wrong or incomplete. The four distinct failure modes People say "Arabic breaks" as if it's one bug. It's four: 1. Visual vs logical order (the reversed-words bug) A PDF doesn't store text the way a Word file does — it stores positioned glyph runs : "paint these shapes at these coordinates." For left-to-right scripts, the paint order happens to match the reading order, so naive extraction works by accident. Arabic is right-to-left. Many PDF generators emit the glyph runs in visual order — the order they appear on screen, left to right. A naive extractor concatenates the runs as stored and produces every line word-reversed. The text was never "reversed" in the file; your extractor just assumed paint order == reading order. Fix: reconstruct logical order using glyph positions + the Unicode Bidirectional Algorithm (UAX #9), not the content-stream order. Libraries like PyMuPDF already return text in logical order — a common mistake is "fixing" that output by reversing it again, which is how you get double-reversed text. Rule of thumb: never reverse Arabic yourself. If it looks backwards, your rendering layer lacks bidi support; the data is usually fine. 2. Disconnected letters (the ransom-note bug) Arabic letters are contextual: ع renders differently in initial, medial, final and isolated positions, and letters join. That joining is applied at render time by a shaping engine (HarfBuzz being the standard). If any step of your pipeline round-trips text through a non-shaping renderer — a canvas library, a barebones PDF writer, an image caption filter

Bolting an LLM onto your pull requests is a weekend project. Building AI code review that your engineers don't disable within two weeks is the actual problem. The failure mode isn't missing bugs — it's crying wolf. Post twenty nitpicks and three hallucinations on someone's PR and they'll mute the bot forever. This is the pipeline we built on Mattrx to earn — and keep — that trust. Mattrx is our multi-tenant marketing-analytics SaaS: ~95k lines of C#, 11 engineers, and enough pull requests that senior-reviewer time was the bottleneck. We tried the naive thing first — pipe the changed file into a model, post the output — and watched the team stop reading it in nine days . TL;DR Dimension Human-only / naive AI (before) AI review pipeline (after) Coverage selective / whole-file dump every PR, diff-focused First-review latency ~6 hours (wait for a human) ~3 minutes (AI first pass) Context none / a naked file diff + call sites + conventions Reviewers one mega-prompt specialized dimensions, in parallel False positives ~35% (so it gets ignored) ~6% (adversarially verified) Merge control human, or nothing severity gate; human always decides Governance none gateway: audit, cost, secret redaction ~90 PRs/week across 11 engineers; the pipeline reviews 100%. First-pass review latency 6h → 3 min. False-positive rate ~35% → ~6% — the single number that decides whether the bot lives or dies. Escaped defects to production down ~40%; senior-reviewer time down ~30%. ~$0.05 per PR (cheap model for style, frontier only for correctness). The one mental shift: AI code review is not about finding issues — models find plenty. It's about not crying wolf . The product is trust, and trust is a false-positive-rate problem. Verify before you comment; let the AI propose and the human dispose. The naive approach — and why it collapses // BEFORE: dump the whole changed file into one prompt, post whatever comes back. foreach ( var file in pr . ChangedFiles ) { var text = await File . ReadAllTextAsyn

Book: The Complete Guide to Go Programming Also by me: Hexagonal Architecture in Go — the companion book in the Thinking in Go series My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You open a pull request in a Go repo you just joined. Ten minutes later there are six comments on it. None of them are about your logic. They point at a capitalized error string, a receiver named this , a context stored on a struct. Each comment links the same page: the Go Code Review Comments wiki. That page is the closest thing Go has to an official style council. It grew out of the comments Go's own maintainers left on CLs for years, and most Go teams treat it as the default rulebook. The problem is that the wiki tells you what but rarely why , so the rules read like arbitrary taste. They aren't. Each one exists because the alternative bit somebody. Here are ten that reviewers cite the most, with the reason behind each. Everything below is idiomatic on Go 1.23+. 1. Error strings are lowercase and unpunctuated The rule: an error string should not be capitalized and should not end with punctuation. // wrong return fmt . Errorf ( "Failed to open config." ) // right return fmt . Errorf ( "failed to open config" ) The reason is wrapping. Go errors get concatenated. Your string is almost never the whole sentence a user reads; it's a fragment in a chain built with %w : return fmt . Errorf ( "load settings: %w" , err ) // -> "load settings: open config: permission denied" Capitalize your fragment and you get load settings: Open config: permission denied in the middle of a line. End it with a period and you get a period in the middle of a longer message. Lowercase, no trailing punctuation, and every fragment composes cleanly no matter where it lands in the chain. The exception is a string that begins with an exported name or acronym, which keeps its own case ( HTTP , TLS ). 2. Receiver types are consistent ac

If you are still using a vanilla installation of VS Code, you are leaving massive amounts of productivity on the table. We all know the standard extensions: Prettier, ESLint, GitLens. But what about the tools that actually change how you write code? Here are 7 hidden VS Code extensions that feel almost illegal to use because of how much time they save. 1. Error Lens Stop hovering over red squiggly lines. Error Lens highlights the entire line and prints the error message inline, right next to your code. You instantly know what is wrong without moving your mouse. Once you install this, you will never be able to code without it again. 2. Console Ninja Tired of switching back and forth between your browser console and your editor? Console Ninja prints console.log output and runtime errors directly in your editor, right next to the line of code that triggered it. It is like magic. 3. Turbo Console Log Highlight a variable, press Ctrl+Alt+L , and this extension automatically inserts a perfectly formatted console.log statement with the variable name and its value. It saves you hundreds of keystrokes a day. 4. Mintlify Doc Writer Writing documentation sucks. Mintlify uses AI to instantly generate beautiful, accurate JSDoc/Python docstrings for your functions. Just highlight the function and hit a button. 5. CSS Peek If you work with large HTML or React files, CSS Peek allows you to hover over a class name and instantly see (and edit) the CSS attached to it in a floating window. No more hunting through massive .css files. 6. Code Spell Checker There is nothing worse than pushing a PR and having a senior developer point out a typo in a variable name. This extension highlights spelling errors in your code, keeping your codebase looking professional. 7. WakaTime Do you actually know how much time you spend coding? WakaTime generates beautiful dashboards showing exactly which languages, projects, and files you spent your time on each week. It is incredible for tracking your own

leetcode.com Problem Statement Given the root of a binary tree, return its preorder traversal. Preorder Traversal follows: Root ↓ Left ↓ Right Brute Force Intuition In an interview, you can explain it like this: Visit the current node first, then recursively traverse the left subtree followed by the right subtree. Recursion naturally follows the preorder sequence. Complexity Time Complexity: O(N) Space Complexity: O(H) Where: N = Number of Nodes H = Height of Tree Recursive Code class Solution { public List < Integer > preorderTraversal ( TreeNode root ) { List < Integer > ans = new ArrayList <>(); preorder ( root , ans ); return ans ; } private void preorder ( TreeNode root , List < Integer > ans ) { if ( root == null ) return ; ans . add ( root . val ); preorder ( root . left , ans ); preorder ( root . right , ans ); } } Moving Towards the Optimal Iterative Approach Instead of recursion, we can use a stack. Since preorder visits: Root ↓ Left ↓ Right we should process the root immediately. To ensure the left subtree is processed first, push the right child before the left child . Pattern Recognition Whenever you see: Preorder Traversal Simulate Recursion Think: Stack Key Observation Stack follows: LIFO To visit: Left First push: Right First ↓ Left Second so that left is popped first. Optimal Java Solution class Solution { public List < Integer > preorderTraversal ( TreeNode root ) { List < Integer > ans = new ArrayList <>(); if ( root == null ) return ans ; Stack < TreeNode > st = new Stack <>(); st . push ( root ); while (! st . isEmpty ()) { TreeNode node = st . pop (); ans . add ( node . val ); if ( node . right != null ) st . push ( node . right ); if ( node . left != null ) st . push ( node . left ); } return ans ; } } Dry Run 1 / \ 2 3 / \ 4 5 Stack: 1 Visit: 1 Push: 3 2 Visit: 2 Push: 5 4 Traversal: 1 ↓ 2 ↓ 4 ↓ 5 ↓ 3 Answer: [1,2,4,5,3] Why Stack Works? A stack processes the most recently added node first. By pushing: Right Child ↓ Left Child the left child

TL;DR: I set up a Claude Code skill that checks in with me about my workday, asks follow-up questions, and saves a structured markdown file I can use as promotion evidence. Here's why it works, and how to build one in about five minutes. May 6th On May 6th I had an energy level of 2 out of 5. I got my Claude Certified Architect exam score back that day: 717 out of 1000. I needed 720. I missed it by three points. Four lines down in the same entry, my manager had told me: "your leadership is being felt around Artium. You're making a good impact." Here's the thing about that day: the bad number is vivid and self-evident. 717. Three points short. That number was going to live in my head rent-free for weeks. But the recognition? That quietly evaporates. Left to memory, May 6th is the day I failed the exam by three points. On the page, it's also the day my manager told me my leadership was landing across the company. The entry keeps the thing I'd lose otherwise. The Problem With Memory I've been bad at this for years. At performance review time, I'd stare at a blank document trying to remember what I'd actually done. I'd come up with four things instead of forty. My manager would advocate for me based on what she happened to see, which was never the full picture. The thing is, I did good work. I just didn't capture it. A few years ago I tried to solve this with Google Forms , a structured form I'd fill out at the end of each day that fed into a spreadsheet. It worked, kind of. The data was there, but it felt like homework. The form didn't ask follow-up questions. It didn't notice when I was being vague. I had to go somewhere specific to fill it out. And when review time came, I had to go back somewhere else to compile everything, figure out what mattered, and assemble it into something coherent. The friction wasn't just the daily entry. It was the whole chain: capture, retrieve, synthesize, present. I was on my own at every step. So I built something better. What I Built

The original safety gate on the Dolt-over-MCP plugin tried to keep a Claude Code agent harmless by excluding "history-affecting tools" from its MCP grant. It was the wrong granularity, and it did nothing. MCP exposes the entire database through one tool — query / exec — and that tool carries every SQL verb. SELECT rides it. So does CALL DOLT_PUSH , CALL DOLT_RESET('--hard') , DROP DATABASE , and CALL DOLT_BRANCH('-D', 'main') . Excluding "dangerous tools" from the grant accomplishes nothing, because the dangerous verbs live inside the one tool you already granted. The destructive operations were never separate tools to exclude. This is the reframe the whole Phase 0 hardening pass turned on: a tool-name allowlist is meaningless for any tool that carries a sub-language. SQL is a sub-language. So is the shell behind a Bash tool. So is anything behind an eval . If the tool can run arbitrary statements in some grammar, the only boundary that means anything is one that reads the statement. It is the move from tool-name allowlisting to capability-based security: the grant stops being "you may call the query tool" and becomes "you may run these statement classes inside it." Why not just allowlist the safe tools? Because there is exactly one tool, and it is not safe or unsafe — it is whatever statement you hand it. You cannot partition a single door into a safe door and a dangerous door by naming. The same logic kills the next-obvious fix: a denylist of dangerous verbs. Blacklist DOLT_PUSH , DOLT_RESET , DROP ... and miss DOLT_REBASE , or the proc Dolt ships next quarter, or a CALL whose name your regex didn't anticipate. A denylist is only as good as your imagination on the day you wrote it. The fix inverts that. You add safety by enumerating what is safe, not by blacklisting what is dangerous. Anything you cannot positively classify as safe is treated as the most dangerous thing it could be. Default-deny the unknown. It's least privilege applied to a grammar: the agent get