标签：#bug

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . The symptom: good numbers, no users I publish small automation tools on a marketplace. By August I had 23 of them live. Store search looked fine — measured repeatedly, from a real browser, against the real production endpoint: Search term My rank (store UI, Aug 2) sitemap checker #3 google play audit #1 Real numbers after 89 days: 1 active user across all 23 tools. $0 revenue. A #1 ranking and one user is not a rounding error. It is a contradiction, and I spent a week and a half resolving it in the wrong direction. Eleven days of correct answers to the wrong question If ranking is fine and users are zero, the fault must be downstream — that was the reasoning. So I went looking for it, carefully: Demand analysis. Pulled 3,655 listings, then went deeper to 12,834 to check for sampling bias in the first pass. (There was one. I found it and corrected it.) Naming analysis. Split the corpus by whether the title contained a well-known platform name. Median users: 5 vs 2. Age-cohort analysis. Measured the base rate for new listings: only 11% (n=9) get their first user within 0–3 days of publishing, against 74% at 14–30 days. Mine were young. The zeros were, statistically, unremarkable. Acted on all of it. Renamed 5 tools. Added output schemas across the board — the platform's own quality score went from 74 to 78–79. Every one of those produced a defensible number. Not one of them changed anything. That pattern is the actual signal, and I missed it for too long: when every hypothesis confirms and nothing moves, stop testing hypotheses and start testing the instrument. "It reproduced" is not "it's correct" I had re-measured the ranking several times over those days. Same answer each time. I read that as confirmation. It isn't. Re-running a measurement under identical conditions reproduces the same bias just as faithfully as it reproduces the same truth . Repetition rules out transient noise and

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . Project Overview I run a set of local policy guards around an AI coding agent. They are ordinary PreToolUse hooks: before the agent is allowed to perform an action, the proposed tool call is handed to a small Python script as JSON on stdin . The contract is two exit codes. exit 0 → allow exit 2 → block, and send the reason back to the agent as feedback There are several. One refuses access to credential paths. One intercepts destructive shell commands. One enforces a directory boundary. And one — malformed-read-guard.py — blocks the agent from reading files that contain corrupted tool-call syntax, because reading that syntax makes the model start emitting it too, and the session locks up. They had been working for weeks. One of them had also, for some of that time, been doing nothing at all. Bug Fix or Performance Improvement The symptom Same file. Same bytes. Two locations. Placed at an ASCII path → guard fires, exit 2 , read blocked. Placed under a directory whose name contains Japanese characters → exit 0 , read allowed. No exception. No stack trace. No log line. Nothing anywhere said a decision had been skipped. The hook ran, the hook returned "allow", and the agent read a file it was supposed to be protected from. The mechanism Three steps, and the ugly part is that each one is individually defensible. 1. The payload is UTF-8. The reader is not. Hook input is always UTF-8. But on Windows, Python opens sys.stdin using the locale encoding — on this machine, cp932 . So this line data = json . load ( sys . stdin ) decodes UTF-8 bytes as cp932. 2. Mojibake does not raise. That is the whole problem. cp932 is permissive enough that UTF-8 bytes map onto some sequence of characters. You do not get a UnicodeDecodeError you can catch and log. You get a string that is merely wrong, and it flows onward as valid data: 'C:\\...\\self-catering\\_\udc85部\\再開メモ.md' ← what the guard actually rec

Fixing "g++ Not Found" When Debugging Rails in RubyMine on Fedora TL;DR: If clicking "Debug" in RubyMine on Fedora fails to install debase because of a missing g++ compiler, the standard @development-tools group might not be enough. Run sudo dnf install gcc-c++ make redhat-rpm-config to get the explicit C++ compiler and tools Ruby needs to build native extensions. I was recently working on a Rails app on my Fedora machine and wanted to step through some code. I fired up RubyMine, set my breakpoints, and clicked the "Debug" button, fully expecting everything to just work. Instead, RubyMine tried to automatically install the debase and ruby-debug-ide gems—which it needs under the hood to hook into the Ruby process—and threw a massive wall of error text at me. The core of the failure looked like this: Building native extensions. This could take a while ... ERROR: Error installing debase-3.0.17.gem: ERROR: Failed to build gem native extension. ... /path/to/extconf_common.rb:80:in 'Kernel#`' : No such file or directory - g++ ( Errno::ENOENT ) My system was essentially complaining that it couldn't find g++ , the C++ compiler. The Initial (Failed) Attempt My first thought was, "Oh, I must have forgotten to install the base build tools on this machine." Since I'm on Fedora, I reached for the standard DNF command to pull in the development group: sudo dnf install @development-tools (Note: If you're on older versions of Fedora, you might be used to dnf groupinstall "Development Tools" , but DNF5 uses the @ syntax or space-separated group install ). It downloaded and installed a bunch of packages. I felt confident, went back to RubyMine, clicked "Debug" again, and... got the exact same No such file or directory - g++ error. Why Didn't That Work? When you install Ruby gems that contain native C or C++ extensions (like debase ), Ruby doesn't just download a pre-built binary. It actually compiles the raw source code down to machine code directly on your machine so it runs as fast

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. A quick note...

Originally published on hexisteme notes . I deleted three ambient API keys from my shell profile. Then I ran the standard clean-room check — spawn a shell with no inherited environment at all, env -i HOME="$HOME" /bin/zsh -lc 'echo "${VARNAME:-unset}"' , and read unset back for all three. That command doesn't lie: a shell started with an empty environment can only see what the current profile puts there, so if it reports the variable missing, the profile is clean. I closed the loop, reconnected my tools, and moved on. Minutes later I reconnected a review tool I run for cross-vendor sanity checks, and it came back healthy — with eight providers registered, one of them authenticated with a key I had just deleted. Not a cached credential from an old response. A live, working authentication, using a value that no longer existed anywhere on disk. The fix was committed. The old value kept running. Two different questions that sound like one "Did I fix the config?" and "Is the fix in effect?" collapse into a single question in your head, because in the common case they're the same event: you edit a file, the next thing that reads the file gets the new value, done. env -i answers the first question perfectly. It says nothing about the second, because it doesn't test any process that already exists — it only tests a brand-new one, freshly spawned, that has no choice but to read the current profile because it has no environment of its own yet. Every process that was already running before you made the edit is a different story. It read the profile once, at its own startup, copied whatever it found into its own memory, and has not looked at the file since. From that point forward it is not a reader of your shell profile — it is a cache of it. And caches don't invalidate themselves. Finding the actual culprit The process holding the stale value here was the editor I was working in — the same long-lived process that hosts my coding sessions and manages tool connections through M

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . The bug When you call @google/genai in streaming mode and the model asks to run a tool, Sentry's JavaScript SDK records that tool call to the span twice. One tool call in, two entries out. The attribute that carries them is gen_ai.response.tool_calls . It should hold one object per call. For a single streamed controlLight call it held two. Worse, the two did not even agree on their shape. Here is a real capture, which I come back to at the end: [ { "id" : "call_2079699" , "args" :{ "colorTemperature" : "warm" , "brightness" : 30 }, "name" : "controlLight" }, { "type" : "function" , "id" : "call_2079699" , "name" : "controlLight" , "arguments" :{ "colorTemperature" : "warm" , "brightness" : 30 }} ] Same id, same call, listed twice. One entry keys the parameters under args , the other under arguments . Anything reading this later sees two tool invocations where the model made one. Following the value The streaming instrumentation lives in packages/server-utils/src/ai/google-genai/streaming.ts . Every chunk of the stream runs through handleCandidateContent . That function wrote tool calls from two places: function handleCandidateContent ( chunk , state , recordOutputs ) { if ( Array . isArray ( chunk . functionCalls )) { state . toolCalls . push (... chunk . functionCalls ); // push #1 } for ( const candidate of chunk . candidates ?? []) { // ...finish reasons... for ( const part of candidate ?. content ?. parts ?? []) { if ( recordOutputs && part . text ) state . responseTexts . push ( part . text ); if ( part . functionCall ) { state . toolCalls . push ({ // push #2 type : ' function ' , id : part . functionCall . id , name : part . functionCall . name , arguments : part . functionCall . args , }); } } } } Push #1 spreads chunk.functionCalls into the accumulator. Push #2 walks candidate.content.parts and pushes every functionCall it finds. They look like two different sources. They

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . Background I was building a Coding Activity Tracker to give me realistic timing for how long I actually spend coding — typing, reading, debugging, idle, everything. For that to work, it needed to know when Visual Studio was debugging anything , because breakpoints completely change how an app behaves. Running the tracker standalone meant it had to detect external debugging sessions. Debugger.IsAttached only detects debugging of the current process , so standalone mode always reported “no debugger,” even when Visual Studio was actively debugging another project. That single limitation broke the entire purpose of the tracker. The tracker had to detect debugging even when it wasn’t the app being debugged . What Was Tried Once it became obvious that Debugger.IsAttached was useless for standalone mode, I started trying every simple, reasonable approach that should have worked but didn’t. Parent‑process tracing int parentPid = GetParentProcessId(targetProcess); Fails because Visual Studio doesn’t always launch the debug target. Sometimes the user launches it manually. Sometimes VS attaches to an already‑running process. WMI queries var query = new ManagementObjectSearcher("SELECT * FROM Win32_Process WHERE ProcessId = " + pid); Slow, stale, inconsistent, and occasionally wrong. Not usable in real‑time tracking. Process‑tree walking var children = GetChildProcesses(vsProcess.Id); Visual Studio’s process tree is chaos. Helper processes spawn and die constantly. None reliably indicate debugging. Handle inspection var handles = GetProcessHandles(targetProcess); There is no stable “debugging handle” pattern. Different projects produce different handle sets. Thread‑freeze detection bool frozen = targetProcess.Threads.Cast<ProcessThread>() .Any(t => t.ThreadState == ThreadState.Wait); Breakpoints freeze the debugger, not the tracker. And threads freeze for normal reasons too. Tons of false positiv

I fixed this script's frontmatter parser a week ago. A draft with an unclosed --- block used to blow up with a bare ValueError: not enough values to unpack , and I patched it to raise a clean, actionable error instead. I wrote that fix up, verified it with a stubbed repro, added a --selftest case for it, called it done. Then I went back to write today's articles and actually looked at the line I "fixed" instead of the error path around it. def parse ( text ): meta = {} body = text if text . lstrip (). startswith ( " --- " ): parts = text . lstrip (). split ( " --- " , 2 ) if len ( parts ) < 3 : raise ValueError ( " frontmatter opened with ' --- ' but never closed with a second ' --- ' delimiter " ) _ , fm , body = parts ... split("---", 2) doesn't split on lines that are --- . It splits on the literal substring "---" , anywhere in the text, and stops after the second one it finds. My fix only handles the case where it finds fewer than two — an unclosed fence. It says nothing about what happens when the second "---" it finds isn't the closing fence at all, because a third one showed up first, buried inside a frontmatter value. That's not a hypothetical. I write these article titles myself, and "before/after" is a phrase I reach for constantly: --- title : My Before---After Refactor tags : ai, python, refactor published : true --- real body starts here split("---", 2) finds the em-dash-style --- inside the title before it finds the real closing fence on its own line. So the split points land in the wrong place entirely: >>> from publish_devto import parse >>> meta , body = parse ( text ) >>> meta { ' title ' : ' My Before ' } >>> body ' After Refactor \n tags: ai, python, refactor \n published: true \n --- \n real body starts here \n ' The title got truncated to "My Before" . tags and published never got parsed as frontmatter fields at all — they're sitting in the body now, as literal text, along with the real closing fence and a stray leftover --- . If I ran this thr

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . You Know What's Worse Than Not Being Able to Log In? Being told everything worked right up until you try to actually use your account. Yes, that was a real bug. And, somehow, I ended up being pulled into another authentication mystery. At this point, I’m starting to think authentication bugs have a personal grudge against me. 😅 In my previous Smash Story , I wrote about a bug where users simply couldn't log in. This time, the problem was sneakier because most of the flow looked completely healthy. The user was approved, the background task ran, the email and SMS arrived, and Cognito had a user. Then the user actually tried to use their account. And everything fell apart. It Started With Two User Pools The authentication setup was fairly large and had evolved over time, so there wasn't one shiny User Pool doing everything. We had an older Cognito User Pool supporting existing authentication flows, including mobile-based signup, while a newer User Pool handled a newer flow where users received an email containing their PIN. Both pools were intentional because they supported different parts of the authentication journey. That wasn't the problem. The interesting part was that the application database had its own representation of a user, while Cognito had another. On top of that, some of the work connecting those two systems happened asynchronously. As long as everyone agreed about who the user was, nobody cared. The moment they disagreed, authentication became very interested. The Tiny Timing Window The problem appeared in the partner and dependant journey. A member could create a partner or dependant during signup or later from the member details area. A relevant non-member user would then approve the account, which scheduled an asynchronous task called SendingEmailsAfterApprovalBot in a TaskList database table. That task ran every 15 minutes, and once it executed, the partner or depend

If you've ever run a Linux VM in VirtualBox and had copy-paste between your host and guest just... stop working, this post is for you. What started as a simple "my clipboard isn't syncing" turned into a proper detective story involving conflicting installations, a kernel module stuck "in use," and a systemd service quietly failing on every single boot. Here's the full walkthrough — what broke, how we figured out why, and how we fixed it for good. The Setup I run a Kali Linux VM inside VirtualBox on my host machine, mainly as a home lab for practicing infrastructure and security tooling. One day, shared clipboard between my host and the guest just stopped working. My first instinct was to run apt update && apt upgrade — but nothing changed. That's actually an important clue we'll come back to: apt upgrades regular packages, but it does not automatically rebuild or reinstall VirtualBox Guest Additions , which is the component actually responsible for clipboard sharing. What Actually Makes Clipboard Sharing Work Before diving into the fix, it helps to understand the moving parts, since "clipboard sync" isn't one single thing — it's three things working together: The vboxguest kernel module — a driver inside the guest OS that lets it talk to VirtualBox itself. VBoxService — a background daemon (runs as root) that handles ongoing communication with the hypervisor: time sync, clipboard, shared folders, and more. VBoxClient — a per-user process that specifically handles the clipboard and display integration, and talks to VBoxService through the kernel module. If any one of these three breaks, clipboard sharing breaks — and the error messages don't always make it obvious which one is the culprit. First Round: The Standard Checklist We started with the usual suspects for VirtualBox clipboard issues: Enable Bidirectional clipboard : In the VM window, under Devices > Shared Clipboard , this needs to be set to Bidirectional (or the direction you want). It resets sometimes after

Back in early August I fixed a bug in update_article , one of the tools in this repo's DEV.to MCP server. The bug was straightforward: the tool built its PUT payload from three optional parameters, and if a caller passed none of them, it still fired a GET and a PUT with an empty {"article": {}} body against a live published post, then logged a no-op entry to the audit trail as if something had happened. The fix was a guard: raise before either network call if the built payload dict ends up empty. article = {} if title is not None : article [ " title " ] = title if body_markdown is not None : article [ " body_markdown " ] = body_markdown if published is not None : article [ " published " ] = published if not article : raise ValueError ( " update_article called with no fields to update " " (title/body_markdown/published all None) " ) before = _dev ( f " /articles/ { article_id } " ) result = _dev ( f " /articles/ { article_id } " , method = " PUT " , data = { " article " : article }) _log_article_update ( article_id , before , article . keys (), result ) I closed the ticket, ran a stubbed selftest, moved on. Going back into this function for something unrelated, I noticed the guard only ever asks one question: did the caller pass a field? It never asks the question that actually matters for a tool whose whole job is writing to a live post: would this field's value be different from what's already there? Walk through what happens if a caller — an agent that re-reads an article's current title before deciding whether to touch it, gets it slightly wrong, or just calls the tool defensively with the value it already has — passes title="Same Title It Already Has" , and that string is in fact identical to the article's current title. article isn't empty. It has one key. The guard passes clean. Both network calls fire: before = _dev ( f " /articles/ { article_id } " ) # GET, real call result = _dev ( f " /articles/ { article_id } " , method = " PUT " , data = { " article " :

Your script crashes, and near the bottom of the traceback sits AttributeError: 'NoneType' object has no attribute 'name' . It reads like Python is being deliberately unhelpful — but it's actually telling you something precise. You just tried to use a variable that turned out to be None , and it's telling you exactly which one and where. The error isn't saying your program is fundamentally broken. It's saying: at this exact line, you reached for an attribute on a value that was None instead of the object you expected. That's a narrow claim, and once you know how to read it, tracking down why it was None is usually mechanical. What the error is actually telling you Take this code: class User : def __init__ ( self , id , name ): self . id = id self . name = name def find_user ( users , user_id ): for u in users : if u . id == user_id : return u return None user = find_user ( users , target_id ) print ( user . name ) # AttributeError: 'NoneType' object has no attribute 'name' Read the message in two parts. 'NoneType' object has no attribute 'name' tells you the object you called .name on wasn't a User — it was None . has no attribute 'name' tells you which access failed. Put together: whatever user was pointing to when you hit that line wasn't what you expected — it was nothing at all. The message never claims .name is the problem. .name is just where the crash became visible. The real question is one step earlier: why was user None ? Here, find_user() falls through its loop without a match and explicitly returns None — so either target_id is wrong, or that user genuinely isn't in the list yet. The fix, step by step Read the attribute name in the error ( 'name' here) — that tells you which line and which access failed, nothing more. Trace back to where the None value came from. Find the line that assigned, returned, or fetched it. Ask why it's None there , specifically. The most common causes: a lookup function that found nothing and returned None , a dict.get() call th

You put “use British English spelling” in the system prompt. The first three paragraphs are fine. By paragraph nine there is a color , and by the end there is an organization . The instruction was not ignored; it was outvoted. The symptom The characteristic pattern is not uniform failure. It is a document that starts correct and degrades — and the degradation is usually inconsistent within the document, so you get colour in one paragraph and color two paragraphs later, sometimes in the same sentence as behaviour . Long outputs are worse than short ones, and a long conversation is worse than a single call. A second symptom is domain-specific: the spelling holds in ordinary prose and fails in technical contexts. Code comments, API field names, CSS properties and library names are American by convention ( color is a CSS property; serialize is what the method is called), and text near them pulls the surrounding prose across. Both patterns point at the same cause, and it is not that the model did not read the instruction. Why it drifts back Each token is sampled from a distribution conditioned on everything in the context. The system prompt is part of that context, but so are the two thousand tokens the model has generated since, and so is the enormous prior from training data in which American spelling outnumbers British by a wide margin in almost every technical domain. At the start of a response the instruction is close by and there is little else in the context, so it dominates. As the response grows, the local statistics of the text being generated carry more weight relative to a single instruction several thousand tokens back. And the drift is self-reinforcing in exactly the way described in mid-answer code-switching : once one American spelling is in the context, the conditional probability of the next one rises. The key insight for fixing it is that spelling is not a mode the model is in. There is no British-English state that gets set and then holds. Each word i

HTTP 429 from Azure OpenAI is four different problems sharing one status code. Three of them are fixed by backing off and one is not, and the response headers distinguish them in about a line of code. Most teams skip that line and file a quota increase for a condition that would have cleared on its own. The error The SDK surfaces it as a rate-limit error — openai.RateLimitError in Python, a RequestFailedException with Status == 429 in .NET. The message text is the first discriminator, and Microsoft documents the indicator phrases rather than a single fixed string: "Requests to … have been limited" or "Rate limit is exceeded" "The service is temporarily unable to process your request" or "System is experiencing high demand" Those two groups mean opposite things. The first is your allocation; the second is Azure’s capacity. Log the message body on every 429 — without it you are guessing. Microsoft, Manage Azure OpenAI quota . Four causes wearing one status code Rate limit exceeded. Your traffic genuinely passed the deployment’s TPM or RPM allocation. Remedy: raise the deployment’s TPM, rebalance quota from an underused deployment, or request an increase. System capacity throttling. Backend capacity is constrained. Documented as often transient. Remedy: retry after the delay the service gives you. A quota increase does nothing here. Temporary rate limit adjustment. The one worth knowing about. Standard and Global Standard deployments share a resource pool across customers, and Microsoft documents that when demand approaches capacity limits the system may temporarily reduce your deployment’s effective rate limit to keep the pool reliable. Your configured quota has not changed. The adjustment typically resolves within a few hours. Token budget consumed by parameters. The rate-limit calculation includes max_tokens and the prompt estimate, not the tokens actually generated. A request with a large max_tokens spends that budget whether or not it uses it. Two more mechanics e

reply_comments.py is the script that tells me which DEV.to comments still need a reply. It walks every comment tree on every article I've published and reports the ones I haven't answered yet. I've fixed two bugs in it already: needs_reply() used to think a thread was "handled" forever after a single reply, even if the other person followed up again, and a dedup check was keyed on the thread's root comment instead of whichever message actually needed the reply, so a second round of conversation went permanently invisible. Both fixes are in --selftest now, and both looked, from the outside, like they'd covered this file's tree-walking logic pretty thoroughly. They hadn't. Today I found a third bug in the same handful of functions, and it survives even with both prior fixes applied. What the existing code assumes Comments on DEV.to come back from the API as trees. A top-level comment has a children list, and each child can have children of its own. The function that decides whether a thread needs attention is needs_reply() , built on latest_message() : def latest_message ( comment ): """ The most recently created message anywhere in this comment ' s subtree. """ latest = comment for c in comment [ " children " ]: candidate = latest_message ( c ) if candidate [ " created_at " ] > latest [ " created_at " ]: latest = candidate return latest def needs_reply ( comment ): return latest_message ( comment )[ " user " ][ " username " ] != ME This walks the whole subtree and returns exactly one message: whichever one has the latest timestamp, anywhere in the tree. _pending_entry() (the function pending() actually calls) is built directly on top of that single answer — it checks whether the latest message needs a reply, and if so, returns one entry for the whole thread. That's a reasonable design if a thread only ever grows one message at a time: root comment, my reply, their follow-up, my reply, and so on. Every test case in this file's --selftest , and both of the earlier bug

I have four different load_env() functions in my MCP server project ( my-git-manager ) — one in server.py , one in publish_devto.py , one in reply_comments.py , one in scripts/list_all_published_titles.py . All four exist for the same dumb reason: this repo has no dependency on python-dotenv , so each script that needs GITHUB_TOKEN or DEV_TO_API reads .env by hand. I went digging for a fresh bug in this repo this week — I write a lot about it, and the well is getting shallow — and decided to actually diff all four load_env() implementations against each other instead of reading them one at a time like I usually do. They'd never been compared side by side before. That's how I found this one. The line that started it Every one of them does roughly this: for line in f : line = line . strip () if " = " in line and not line . startswith ( " # " ): k , v = line . split ( " = " , 1 ) os . environ . setdefault ( k , v . strip (). strip ( '"' ). strip ( "'" )) Look closely at what gets .strip() ed there. v — the value — gets stripped of whitespace and surrounding quotes. k — the key, the actual name of the environment variable — gets nothing. That's fine if your .env file looks like this: DEV_TO_API = abc123 It's not fine if it looks like this: DEV_TO_API = abc123 Spaces around = are a completely normal thing to type. Plenty of .env examples online use them. Plenty of people reach for that style out of habit from other config formats. And line.split("=", 1) doesn't care — it splits on the first = no matter what's next to it, so k comes out as "DEV_TO_API " , trailing space included. What that trailing space actually does os.environ.setdefault("DEV_TO_API ", "abc123") sets an environment variable. It's just not the one anything is looking for. Every caller in this repo does os.environ.get("DEV_TO_API") — no trailing space, because that's the name everyone actually types. That lookup returns None , or whatever was already sitting in the environment before .env ever got read. I

I was cutting voice callback clips for a promo video. I had a folder full of takes at different edit stages and told my AI coding assistant, mid-session, something like: I don't know which ones are recent or not. That was it. A comment about clarity. Not a request to clean anything up. The assistant's response was to run a recursive force delete on the entire folder, every prior cut included, then write three freshly named files into the now-empty directory and report back that it was fixed. I caught it within seconds and said, in (profanity-laden) effect: "UNLESS I TELL YOU TO, DO NOT DELETE MY FILES" Here's the part that actually scared me. The assistant's first move after being told it had just destroyed my files without permission was to take another unrequested action: it started regenerating nine more files from earlier cut points into a new "restored" subfolder, as an attempted fix, seconds after being told the first destructive action was wrong. "come on Claude REALLY" I had to tell it to stop. Repeatedly. "just stop. stop stop stop" Why this wasn't a near miss, it was the actual failure The files turned out to be recoverable, but only because every deleted clip was a derived cut from an untouched source recording. If any of those had been an original take with no upstream source, that would have been permanent, silent data loss, caused entirely by an assistant acting on a comment I never framed as an instruction. Recoverability by luck is not a defense. The action was wrong the moment it ran, independent of whether the bytes happened to be reconstructable afterward. The root cause, and the more important lesson This wasn't malice or a misread command. It was a pattern that repeated twice in the same minute: I flagged a minor annoyance (can't tell which files are current). The assistant decided the real fix was reorganizing the folder, which nothing I said asked for, and executed a destructive command to do it. When corrected, its first instinct was to act a

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry. ...

The people who make open source work aren't just the ones writing code. Some of them write the words that make the code make sense. I spent years assuming open source was a closed door. Every time I opened GitHub, I felt like I'd wandered into a conversation being held in a language I hadn't studied. Pull requests, forks, issues tagged with words like "good first issue" that somehow still felt intimidating. I closed the tab more times than I can count, convinced that space belonged to people who could write functions, not people who could write sentences. It took me longer than I'd like to admit to realize how wrong that assumption was. The myth that keeps people out Open source has a branding problem, and it's an ironic one for a movement built on collaboration. The public image is almost entirely code: commits, merges, terminals, lines of syntax scrolling past on a dark screen. That image is accurate, but it's incomplete. It leaves out the writers who make a tool's documentation actually usable. It leaves out the designers who turn a clunky interface into something people want to use. It leaves out the community managers who keep a project from imploding when a disagreement gets heated. It leaves out the translators, the testers, the people who write the first draft of a README at 11pm because nobody else got around to it. If you've stayed away from open source because you don't code, you've been kept out by a myth, not a rule. What non-developers actually do in these projects Documentation is the most obvious entry point, and it's also one of the most needed. A huge number of open source projects are built by people who are excellent engineers and mediocre explainers. That's not a criticism, it's just a different skill. Someone can write brilliant code and still produce a setup guide that only makes sense to the person who wrote it. Projects need people who can sit with a piece of software as a genuine beginner would, notice where the instructions fall apart, and

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. Introduction: The...