Sharing here my checklist that I use for CLI apps (was assembled manually and suffered by real usage).\nYou can feed it to your agent (it will probably forget half of the rules, so use multiple passes or split it).
\nLLM was used only to fix ESL mistakes.
\n154 rules.
\nThe key words MUST, MUST NOT, SHOULD and MAY are to be read as described in RFC 2119 and RFC 8174. A rule about a feature binds only a tool that has that feature: a tool without remote accounts needs no login.
--help and -h on the top level and on every subcommand-h with anything but help--help appended to any invocation, ignoring the rest of the argumentscat, jq)--help for the restcheck-updates command the user invokes explicitly, reporting the current version against the latest released one, unless a package manager owns the tool’s updatesmyapp help and myapp help <subcommand>ERR, WARN) and extra context appear only in verbose mode--verbose and --quiet flags-q suppress all non-essential output, so scripts need no 2>/dev/null--plain (one record per line, no wrapping or decoration: banners, ASCII art, table borders, divider rows, [+]/[-] status prefixes) whenever human-readable formatting breaks machine parsing or a screen reader--json is passed, or one JSON object per line when the output is a stream of recordsNO_COLOR, FORCE_COLOR, TERM=dumb and --color=auto|always|never, and provide a <TOOL>_NO_COLOR override--verbose$PAGER, defaulting to less -FIRX, only when stdin and stdout are both TTYsCan’t write to file.txt. Run chmod +w file.txt.)-a/--all, -d/--debug, -f/--force, -h/--help, -n/--dry-run, -o/--output, -p/--port, -q/--quiet, -u/--user, -V/--version--version flag, and MUST NOT let -v mean both verbose and version- to read from stdin or write to stdout when the input or output is a filerm *.txt; the exception is a memorable primary action like cp <source> <destination>none when a flag takes an optional value, rather than a blank value--no-input to disable every prompt, and MUST fail with the flag to pass when input is required in that modey/yes, and require -f/--force when not interactive--confirm="name"--dry-run for moderate operations (deleting a directory or a remote resource, a bulk change) so the user can see what would happennoun verb shape across object types when the tool manages several, and the same verbs for the same operationsupdate and upgrade side by side is confusing.env) → user config → system config~/.config/<tool>/) rather than scattering dotfiles in $HOMEDEBUG, EDITOR, HTTP_PROXY/HTTPS_PROXY/ALL_PROXY/NO_PROXY, TERM/TERMINFO/TERMCAP, TMPDIR, HOME, PAGER, LINES/COLUMNS.env where appropriate for settings tied to a directoryps and shell history--password-file) or from stdinlogin command for a tool with remote accounts, and treat the CLI’s API calls with the same security practices as the rest of the application0600 file under ~/.config/<tool>/, so it can be revoked without touching the user’s primary loginDO_NOT_TRACK--plain and --json exist for scripts--plain output end to end through a screen reader (Orca, or espeak-ng at the least)DO_NOT_TRACK variableI promised myself to not joke about how ignorefiles were ignored by linters.
\nDetails at the project page
", "summary": "I promised myself to not joke about how ignorefiles were ignored by linters. Details at the project page", "date_published": "2026-09-17T02:59:00.000Z", "tags": [ "Continuous Integration" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M71TVRJWX8GNNXE303665RRF", "url": "https://dbuho.me/post/released-doomsday-clock-exporter/?utm_source=posts&utm_medium=rss", "title": "Released Doomsday Clock Exporter", "content_html": "It works in theory, but we will have the first real life test in around January.\nIt's not the Bulleting Of Hardworking Atomic Scientists, you know.\nDon't wire your household turrets to it yet.
\nMore on project page.
", "summary": "It works in theory, but we will have the first real life test in around January. It's not the Bulleting Of Hardworking Atomic Scientists, you know. Don't wire your household turrets to it yet. More on project page .", "date_published": "2026-07-16T02:59:00.000Z", "tags": [ "Observability", "Nuclear Non-Proliferation" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M71SE4V8EXMC82ZTXGPGY5YG", "url": "https://dbuho.me/post/how-to-sing-to-caged-birds/?utm_source=posts&utm_medium=rss", "title": "How to sing to caged birds", "content_html": "I got the idea for this post when I noticed a couple of issues on the site of one of the resistance groups operating in ruzzia (credit where it’s due: they fixed them fast, and I will not name them).\nThis little guide could be useful for opposition media too.
\nIf you’re making something that is frowned upon by your local Authoritarianism™ franchise, you have a moral obligation to protect not only your cell | group | band | merry wagon, but your visitors too.
\nMaybe even them first, because, not unlike you, they are not prepared and not vigilant enough.
\nSome dictatorships will prosecute them for the visit itself; others will use finesse and make an “aggravating circumstance” out of it when they bake another “high treason” case.
\nYou can slap Cloudflare over your site and give yourself a gold star for security, but that’s only the beginning of your saboteur journey.
\nOr, to be precise, a cop scouring through it.\nYou don’t have to learn what modern forensic hardware can or cannot do, just treat the user’s device as fully transparent to the authorities. Especially those practicing cryptanalysis with the help of a car battery attached to your genitals.
\nCache-Control: no-store.no-store also stops a CDN from caching, and the CDN is your DDoS shield.CDN-Cache-Control: max-age=60 (RFC 9213), which the browser ignores.chrome://serviceworker-internals.localStorage, IndexedDB or long-lived cookies.Secure, HttpOnly, SameSite=Strict (Set-Cookie).Clear-Site-Data: "cache", "cookies", "storage".http:// links, QR codes and messenger links all start on HTTP.Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (MDN, RFC 6797), then submit at hstspreload.org.https:// cannot be stripped: the attacker needs a valid certificate, and gets a full-page warning without one. Unless the device trusts a …Referrer-Policy: no-referrer, so linked sites never learn the reader came from here.Onion-Location and X-I2P-Location headers on the HTTPS site; Tor Browser then offers the onion address by itself.We’ve all seen the blue-and-yellow #StandWithUkraine ribbons on various sites. While they look nice, I wanted something more actionable.
\nI created a small script that displays links to random relevant charities based on the visitor's language, pointing to localized versions whenever available. It also tracks seen charities so visitors never see the same one twice (off by default, yay to GDPR). Highly tuneable.
\nI like projects with a small scope and a single primary metric (CTR in this case), every feature or fix feels more impactful and challenging.
\nMore details on the project page, or check out the demo live on this site.
", "summary": "We’ve all seen the blue-and-yellow #StandWithUkraine ribbons on various sites. While they look nice, I wanted something more actionable. I created a small script that displays links to random relevant charities based on the visitor's language, pointing to localized versions whenever available. It also tracks seen charities so visitors never see the same one twice (off by default, yay to GDPR). Highly tuneable. I like projects with a small scope and a single primary metric (CTR in this case), every feature or fix feels more impactful and challenging. More details on the project page , or check out the demo live on this site.", "date_published": "2026-07-09T02:59:00.000Z", "tags": [ "Ukraine" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M6VBEZV1ANZ88ZNKPNN756DN", "url": "https://dbuho.me/post/released-fork-of-repolinter/?utm_source=posts&utm_medium=rss", "title": "Released fork of repolinter", "content_html": "Released a fork of todogroup/repolinter.\nMigrated it to TypeScript, updated the tests and dependencies, and cleaned up the workflows.\nMajority of the issues of the original were fixed.
\nMy first experience with such necromancy. I'm sure there are good reasons they dropped it, but it costs little to maintain, and I think the "facts/rules" scheme is actually very neat.
\nDetails on the project page.
", "summary": "Released a fork of todogroup/repolinter . Migrated it to TypeScript, updated the tests and dependencies, and cleaned up the workflows. Majority of the issues of the original were fixed. My first experience with such necromancy. I'm sure there are good reasons they dropped it, but it costs little to maintain, and I think the \"facts/rules\" scheme is actually very neat. Details on the project page .", "date_published": "2026-07-09T02:59:00.000Z", "tags": [ "Continuous Integration" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M5XR17NV4BGYBH7B2K1033ZB", "url": "https://dbuho.me/post/why-you-should-care-about-risc-v/?utm_source=posts&utm_medium=rss", "title": "Why You Should Care About RISC-V", "content_html": "I try to support RISC-V everywhere I can, and you should too.
\nChances are (around 60%, actually) that you live in a country without an independent CPU/MCU industry. The consequences of the russian invasion in 2022 showed us that you can't really stop high-tech imports into a country that went batshit crazy, but you can make chips somewhat harder to get.
\nI obviously don't have a problem with sanctions against the axis of evil. But one of these days, some orange clown (or clowns of any color) could decide that Uruguay, Chile, or New Zealand are as bad as North Korea or Iran—because they are too friendly to China, too gay, or something like that. And your country could be next.
\nOne Jacob Feldgoise already whines about RISC-V hindering good old world policing.
\nRISC-V is not the simplest, but it is the most logical way to get closer to an "Uruguayan Xeon" or a "Nigerian STM32." And it doesn't have to be an entirely national project: regional alliances could help lower costs and achieve scale faster. Getting an ARM license is probably easier, but it's another compliance leash from a country that loves exiting things without thinking them through.
\nWithout a stable supply of chips, you will have issues with everything from ATMs to train networks. It won't be immediate—modern silicon is quite durable—but things will break down and require replacement. If you don't have the benefit of a "death cult of living in squalor and constantly overcoming unnecessary self-imposed problems" in your population (like Russia has), it will become an issue very fast. An issue that both internal and external malevolent actors will exploit. Be less gay, have a chip.
\nSovereign RISC-V production is something that feels unnecessary, expensive, and alarmist now. But when it becomes "today's problem," it will be too late.
\nAnd even if you have 30+ CPU suppliers, you can still be enough of an asshole that all of them refuse to sell to you (though things won't change much for the real bad actors).
\nRISC-V is on the rise, but it still suffers from low adoption across both software and hardware — a classic chicken-and-egg issue.
\nHaving a strong alternative architecture will, in the end, benefit all of us.
\n// And after the end too, when we scavenge for RISC-V chips in the wasteland.
\nThis is very dynamic market with some supply chain issues, links will go stale faster than I hit publish.
\nGood keywords to start your search are SiFive and SpacemiT. Or look at the Geekbench
", "summary": "I try to support RISC-V everywhere I can, and you should too. Chances are (around 60%, actually) that you live in a country without an independent CPU/MCU industry. The consequences of the russian invasion in 2022 showed us that you can't really stop high-tech imports into a country that went batshit crazy, but you can make chips somewhat harder to get. I obviously don't have a problem with sanctions against the axis of evil. But one of these days, some orange clown (or clowns of any color) could decide that Uruguay, Chile, or New Zealand are as bad as North Korea or Iran—because they are too friendly to China, too gay, or something like that. And your country could be next. One Jacob Feldgoise already whines about RISC-V hindering good old world policing. RISC-V is not the simplest, but it is the most logical way to get closer to an \"Uruguayan Xeon\" or a \"Nigerian STM32.\" And it doesn't have to be an entirely national project: regional alliances could help lower costs and achieve scale faster. Getting an ARM license is probably easier, but it's another compliance leash from a country that loves exiting things without thinking them through. Without a stable supply of chips, you will have issues with everything from ATMs to train networks. It won't be immediate—modern silicon is quite durable—but things will break down and require replacement. If you don't have the benefit of a \"death cult of living in squalor and constantly overcoming unnecessary self-imposed problems\" in your population (like Russia has), it will become an issue very fast. An issue that both internal and external malevolent actors will exploit. Be less gay, have a chip. Sovereign RISC-V production is something that feels unnecessary, expensive, and alarmist now. But when it becomes \"today's problem,\" it will be too late. And even if you have 30+ CPU suppliers, you can still be enough of an asshole that all of them refuse to sell to you (though things won't change much for the real bad actors). What Can You Do About It?", "date_published": "2026-06-30T02:59:00.000Z", "tags": [ "RISC-V", "Hardware", "Digital Sovereignty", "Continuous Integration" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M5G12P950QYP3MH4XDZCS0JB", "url": "https://dbuho.me/post/another-phpocalypse-cve-2026-109618-and-cve-2026-109619/?utm_source=posts&utm_medium=rss", "title": "Another PHPocalypse: CVE-2026-109618 and CVE-2026-109619", "content_html": "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet.
\nIn short, if you didn't update your PHP on the 21st, you're in danger.
\nYou can check if you're vulnerable via a self-hosted script or the Brandefense ATLAS checker.
\nOther light reading in attached links.
\nI had only one vulnerable service: Matomo Analytics (and Matomo's reaction to most of their users getting screwed is quite underwhelming). Custom image on a custom PHP distribution.
\nAnd even though it's a sad day for the internet, I am quite amused by my OCD paying off:
\ncap_drop and no-new-privilegesThere are some things that definitely need improvement, but overall, it's nice not to be in a panic.
\nIronically, my second specialization after CI/CD/Platform Engineering is the modernization of PHP applications (I've spent 20 years in PHP-related development).
\nIf you need something pulled out of the 7.x bog, help with fixing modern deployments, or assistance in preventing/minimizing damage in the future, send me an email.
\nI would also point out that this won't be the last drama of its kind, so embrace it.
\nBrave new world: people without skills or responsibility wielding one of the most powerful tools in human history.
", "summary": "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet . In short, if you didn't update your PHP on the 21st, you're in danger. You can check if you're vulnerable via a self-hosted script or the Brandefense ATLAS checker . Other light reading in attached links. Personal Experience I had only one vulnerable service: Matomo Analytics (and Matomo's reaction to most of their users getting screwed is quite underwhelming). Custom image on a custom PHP distribution. And even though it's a sad day for the internet, I am quite amused by my OCD paying off:", "date_published": "2026-10-21T19:24:47.163Z", "tags": [ "Language: PHP", "Vulnerabilities", "Security" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M4EXHHXNN36X1HZCTY463WQY", "url": "https://dbuho.me/post/ai-stance/?utm_source=posts&utm_medium=rss", "title": "AI Stance", "content_html": "Inspired by Armin Ronacher's AI Transparency Statement
\nI use coding agents every day, but never use LLMs for writing or anything that's meant to be read by humans.\nI occasionally make a throwaway picture (like an avatar).
\nI do use them to fix idiotic ESL mistakes I sometimes make. I use … and — via the Compose key in Linux since the 2010s.\nI have a background in traditional publishing and believe that three dots (...) are not an ellipsis (…) and never will be.
\nEvery human deserves to know the source of your information, and has the right to ignore an LLM answer without reading it. It's a good rule even for non-AI applications; I am not reading your "russia today" quote, mate.
\nSo, an LLM response should be marked with the same effort as "trigger warnings" or at least use some quoting standard like APA.
\nI make an exception for code, because the clanker that did some menial task doesn't deserve a "Co-Authored" byline.\nAlso, no one reads your code anyway (sad, but true).
\nAn agent/model didn't fuck up. You did.
\nDon't trust them fully; always have a deterministic pipeline to check their work.
\nI dislike the misleading "AI" term and people who are really into it.
\nAlthough, I believe any technology can produce obnoxious zealots. Just look at crypto.
\nMaybe people should look into who raised all of those assholes, instead of screaming at a chain of hashes or matrix multipliers.
\nI accept LLMs as a genie that can't be put back into the bottle. Holy wars about LLMs are boring.
\nI do believe that companies behind so-called "SOTA models" are not to be trusted and LLMs should be self-hosted and sovereign.
\nAt the same time, the whole "they drink all our water" trope is a good way to detect virtue-signalling idiots.\nMost of them can't distinguish an artesian well from an Abyssinian one and have zero interest in the state of local aquifers.
\nI use the "org.projectfile.ai" extension in my projectfile schema, which generates an "AI POLICY.md" document in all my projects.
", "summary": "Inspired by Armin Ronacher's AI Transparency Statement I use coding agents every day, but never use LLMs for writing or anything that's meant to be read by humans. I occasionally make a throwaway picture (like an avatar). I do use them to fix idiotic ESL mistakes I sometimes make. I use … and — via the Compose key in Linux since the 2010s. I have a background in traditional publishing and believe that three dots (...) are not an ellipsis (…) and never will be.", "date_published": "2026-06-23T02:59:00.000Z", "tags": [ "LLM", "Meta", "Standards" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M3DBTSRD9PXWT45MSZS2E5NH", "url": "https://dbuho.me/post/unfeature-request/?utm_source=posts&utm_medium=rss", "title": "Unfeature Request: feature creep is the new code smell", "content_html": "I believe we can add a new item to the list of "code smells / project smells":
\nToo many features
\nMost modern vibe-coded agent-engineered CLI tools have 20, 30, or 40 verbs and internal commands in their TUI.\nOften, these feature duplicate or overlap existing functionality. They include things that could just be a flag on an existing command, things that could be hidden three keypresses away because 1% of users use them 1% of the time, or features that should never have been built in the first place because you could achieve the same result with Unix pipes and a smart use of core tools.
If you are making a tool for real humans, you should consider human nature: a short memory and a limited attention span.\nHumans get tired and bored. Well-established UI principles still hold true: give users fewer options to make choices easier, guide them, keep the learning curve in mind, and treat their attention as a limited resource.
\nOf course, you can also build a tool intended solely for agents. If you're honest about that goal, why not?\nTranslate your help output to Claudespeak, drop all the formatting, and they will be happy.\nJust don't leave your tool stuck in an intermediate state where it is disrespectfully terse and confusing to a human user, yet not structured enough for a clanker.
\nYou may think an intimidating list of two dozen commands makes your tool look sophisticated and professional.\nYet the tools that truly make the world go round usually follow the Unix Way. Look at anything from cp to make for reference.
More code means a bigger attack surface and more things to cover with tests (and let's be honest, even with cheap LLM-generated tests, people still forget or don't care enough to maintain them).\nIn other words: more moving parts to pay attention to, and more things that can go wrong.
\nA pair of smaller, focused tools will almost always be better than one monolithic beast. If you need them to work together, use pipes, the filesystem, or even gRPC.
\nIf your tool benefits from being piped through grep, rg, yq, jq, or dasel, just tell the user how to do it in the docs.
Ask yourself: What can I delete from my project today?
\nWhat will never be used? What lowers my signal-to-noise ratio? What could be done with the help of another tool? (Yes, you will have to set your ego aside.) Maybe when you originally built a feature, a better external solution didn't exist, but it's here now.
\nStart depending on it (with proper precautions). An interlinked ecosystem of focused projects is much healthier than a dozen egotistical developers trying to reinvent the wheel from scratch for 2.5 users.\nYou won't become the next Daniel Stenberg or Fabrice Bellard anyway.
\nI recommend asking yourself this question weekly. Ask your audience, too.\nIf nobody cries about a feature being removed, neither should you.
\nAlmost every discussion about "taste" in software development touches on the mantra of "knowing what not to build."
\nBut once you've already failed with that, the right move is learning how to cut.
", "summary": "I believe we can add a new item to the list of \"code smells / project smells\": Too many features Most modern vibe-coded agent-engineered CLI tools have 20, 30, or 40 verbs and internal commands in their TUI. Often, these feature duplicate or overlap existing functionality. They include things that could just be a flag on an existing command, things that could be hidden three keypresses away because 1% of users use them 1% of the time, or features that should never have been built in the first place because you could achieve the same result with Unix pipes and a smart use of core tools.", "date_published": "2026-06-02T02:59:00.000Z", "tags": [ "Architecture", "Agents", "LLM", "Practices" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M3DBT8KSGE56K90ATV87MDZH", "url": "https://dbuho.me/post/what-is-image-distillation/?utm_source=posts&utm_medium=rss", "title": "What is image distillation?", "content_html": "There are at least four ways to go about building container images:
\ndebian-slim)I use a fifth one.
\nIn my experience, no one really likes building Alpine images, but because they're so lean, people feel forced to. MUSL, busybox, ash, python issues, package names often differ, command flags vary slightly, and so on.
\nI've used Ubuntu/Debian as an image base since 2018 because my developers were Debian-oriented and felt much more confident whenever they had to operate inside containers to debug.
\nIn production, though, Debian-based images are far from perfect. Debian has long confused 'paleolithic' with 'stability.' Meanwhile, Canonical adds useless thingamajigs like Pebble—complete with a bunch of Go stdlib vulnerabilities—or ruins RISC-V compatibility with an unnecessary move to vector extensions.
\nDistroless images are pure and perfect — and also feel like a war crime when you're actually building them. Every single dependency has to be hand-crafted, and you constantly feel phantom pain from missing basic shell tools.
\nDon't get me wrong: I love it, but it's a kink.
\nTo keep a cozy environment while working on a project, while simultaneously stripping down the attack surface of the production image, I use a technique I call image distillation.
\nIt's fairly obvious (I'm pretty sure many people do this, I didn't invent anything), but I haven't found an established term for it yet (I'd be glad to be proven wrong if you know one).
\nCOPY everything you actually need (binary + libraries + runtime data) into a single folder (mine is usually called /export).FROM scratch or FROM distroless, with a single COPY --from=builder /export /.You get the fat-free security of distroless in production with the developer pleasantries of a full OS during build time.
\nYou won't get any progress in understanding the meaning of life or finding true love, though.
\nIt's just a slim container image, what did you expect?
", "summary": "There are at least four ways to go about building container images: Small distributions, like Alpine Cut-down server versions (e.g., debian-slim ) Whatever tf Ubuntu Chiseled is Distroless I use a fifth one.", "date_published": "2026-06-16T02:59:00.000Z", "tags": [ "Developer Experience", "Containerization", "Debian", "Ubuntu", "Docker" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M3DBSDTEQ9SDFATFNBFXEQ7B", "url": "https://dbuho.me/post/what-is-b19/?utm_source=posts&utm_medium=rss", "title": "What is B19 images and how I wrap things in containers", "content_html": "A big part of my portfolio consists of so-called b19-style images.
\n(b19 means nothing—you just can't get a proper namespace these days.)
It started as an internal effort for my personal and commercial projects, but ended up as a set of conventions unified across 100+ various images (both wrappers and originals). I wanted every container to behave in a predictable way, agnostic of the tech stack, whether it's a source-based or upstream-based project.
\nI'm not urging anyone to adopt this directly yet—I need some time in public to polish everything—but if you're tasked with a similar unification job or manage a fleet, feel free to steal the conventions.
\nThe conventions are anchored in B19/Ubuntu and flow organically into all downstream projects.
\nThe conventions are unopinionated (though the defaults can be).
What's inside?
\nRUN commands—one RUN per stageB19-style images expose switches for all kinds of behavior: there's no such thing as "too many switches." Where possible, switches are set via environment variables (relying on various mounts and binds is messy).
\nConfiguration files are generated via Jinja2 templates driven by environment variables.
.dNumbered hooks everywhere. Everything can be extended or overridden via simple drop-in shell scripts in downstream projects. Hooks can be inherited:
\nbuild.dhealthcheck.dentrypoint.dIn other words, a b19 distribution comes with all the things you would end up adding to an official image anyway—right out of the box.
", "summary": "A big part of my portfolio consists of so-called b19-style images. (b19 means nothing—you just can't get a proper namespace these days.) It started as an internal effort for my personal and commercial projects, but ended up as a set of conventions unified across 100+ various images (both wrappers and originals). I wanted every container to behave in a predictable way, agnostic of the tech stack, whether it's a source-based or upstream-based project. I'm not urging anyone to adopt this directly yet—I need some time in public to polish everything—but if you're tasked with a similar unification job or manage a fleet, feel free to steal the conventions. The conventions are anchored in B19/Ubuntu and flow organically into all downstream projects. The conventions are unopinionated (though the defaults can be). What's inside?", "date_published": "2026-06-09T02:59:00.000Z", "tags": [ "Meta", "Containerization", "Docker", "Continuous Integration", "Continuous Deployment" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M38MR8KZMWZW5AFX2WPV1WB6", "url": "https://dbuho.me/post/maintainer-pledge/?utm_source=posts&utm_medium=rss", "title": "About maintenance", "content_html": "This post sets some clear expectations regarding projects I develop and maintain.
\nLet's call it Commitment Pledge.
\nIn short, I don't abandon shit easily and appreciate people's trust.
\nThe repository will clearly display its maintenance state via standard badges (e.g., "Maintained", "Archived", "Open For Adoption", "Sundown").
\nIf I reach burnout, lose interest, or can no longer maintain the codebase, the project will not be silently abandoned. I will update the project's lifecycle badge to "Sundown" or "Open For Adoption" and post instructions about forking or hand-off with at least a month of advance warning.
\nIf a man or an animal or a huge meteor gets the best of me and I become dead, designated person will deal with inheritance and hand-offs.
\nCode updates will strictly serve the project's stated technical function. I will never intentionally inject malware, protestware, console activism, political popups, or code designed to break environments. Although, I will openly and transparently make your life harder if you support evil shit.
\nI will not include tracking, phone-home features, user profiling, or analytics without explicit, transparent, opt-in consent. Not sure if I do it even with consent.
\nPublished releases will remain open source. Future releases will not be retroactively switched to restrictive, commercial, or non-OSI-approved source-available licenses.
\nPublished releases or package registry artifacts will not be arbitrarily deleted or yanked, preventing broken downstream builds, except when required for critical security or legal reasons.
\nAdministrative control, repo ownership, and package-publishing keys will never be sold or handed off to unverified third parties. Any transfer of maintainership will be publicly announced and verified.
\nI reserve the right to decline features, code contributions, or pull requests that do not align with the project’s scope, design philosophy, or maintenance bandwidth.
\nMaintenance is conducted on a best-effort basis; I am not an on-call support team or corporate service desk (but we can discuss it)
\nI do it because I like making and sharing stuff I find useful.
", "summary": "This post sets some clear expectations regarding projects I develop and maintain. Let's call it Commitment Pledge. In short, I don't abandon shit easily and appreciate people's trust.", "date_published": "2026-05-02T02:59:00.000Z", "tags": [ "Meta" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M293G9HFA4ASQY02ZR5M8009", "url": "https://dbuho.me/post/spotlight-humanjson/?utm_source=posts&utm_medium=rss", "title": "Spotlight: human.json", "content_html": "I have human.json on this site.
\n\n\nhuman.json is a lightweight protocol for humans to assert authorship of their site content and\nvouch for the humanity of others. It uses URL ownership as identity, and trust propagates through a\ncrawlable web of vouches between sites.\nhttps://codeberg.org/robida/human.json
\n
I like the idea of establishing trust between people in this slop era.
\nI always felt like such conventions and standards are something that only a bunch of important\ngrayscrotums in very important commitees can do, and human.json actually inspired me to design\nprojectfile, first and foremost for myself, but also to put it out there.
\nAlthough, I believe that any kind of commentless JSON should be only used by Catholic nuns as\npunishment tool, I also believe we need more initiatives like this one. Not only because it's a\nlegitimate attempt to solve a problem, but also because we lately gave up a lot of ground to\ncommittees of aforementioned grayscrotums (corporate or pseudocorporate), and the world kinda sucks\nbecause of it.
\nYou can fuck the right off with your new vibe-coded habit tracker, but if you have an idea for a\nprotocol or a scheme that empowers other people to build, I salute you.\nEven if it's weird or obscure, any such idea is an open invitation to work together, and that's\ncool.
\nP.S. Technically it was just a "Vouch" collection in my Payload CMS backend, and a little renderer\nfor my Astro frontend, so I am not sure that I'll open a human.json consulting agency anytime soon.
", "summary": "I have human.json on this site. human.json is a lightweight protocol for humans to assert authorship of their site content and vouch for the humanity of others. It uses URL ownership as identity, and trust propagates through a crawlable web of vouches between sites. https://codeberg.org/robida/human.json I like the idea of establishing trust between people in this slop era. I always felt like such conventions and standards are something that only a bunch of important grayscrotums in very important commitees can do, and human.json actually inspired me to design projectfile , first and foremost for myself, but also to put it out there.", "date_published": "2026-05-25T02:59:00.000Z", "tags": [ "Standards", "Small Web" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M293G9HA0RNMP03GD6F1CP0Q", "url": "https://dbuho.me/post/released-textlint-rule-ukraine/?utm_source=posts&utm_medium=rss", "title": "Released textlint-rule-ukraine", "content_html": "I am a big fan of textlint, correct quotes, long dashes, and seeing "0 errors" in my logs.
\nAnd I noticed how often Western media mess up correct transliterations of Ukrainian identifiers,\nusing russian-to-English transliterations instead of proper Ukrainian-to-English ones.
\nThere is a nice web app with bots tackling this topic — check it out.\nI used their vocabulary to make a ruleset for Textlint — pretty sure they\nare not interested in doing it themselves.
\nPublished as my first npm package.\nNothing complex or particularly cool — just wanted to experience npm from the other side.
\nExcited to become another supply chain attack vector in the future!
", "summary": "I am a big fan of textlint, correct quotes, long dashes, and seeing \"0 errors\" in my logs. And I noticed how often Western media mess up correct transliterations of Ukrainian identifiers, using russian-to-English transliterations instead of proper Ukrainian-to-English ones. There is a nice web app with bots tackling this topic — check it out. I used their vocabulary to make a ruleset for Textlint — pretty sure they are not interested in doing it themselves. Published as my first npm package . Nothing complex or particularly cool — just wanted to experience npm from the other side. Excited to become another supply chain attack vector in the future!", "date_published": "2026-05-17T02:59:00.000Z", "tags": [ "Continuous Integration", "Ukraine" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M293G9H7T5EGXC59FRWE5A8X", "url": "https://dbuho.me/post/hello-world/?utm_source=posts&utm_medium=rss", "title": "Hello world", "content_html": "\n\nThis is my blog. There are many like it, but this one is mine.
\n
I am going to write about my interests. And sometimes about my experiences.\nAnd about what I do as an independent developer.
", "summary": "This is my blog. There are many like it, but this one is mine. I am going to write about my interests . And sometimes about my experiences. And about what I do as an independent developer.", "date_published": "2026-05-02T02:59:00.000Z", "tags": [ "Meta" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M293G9H2KCQRPKNW808W5TPW", "url": "https://dbuho.me/post/first-pr/?utm_source=posts&utm_medium=rss", "title": "Officialy made it", "content_html": "For the first time in my life, my modest pull request was accepted into a mainstream project\n(AppArmor). That was also my first attempt.
\nAll because of intense hatred for warnings in system logs. And because I read dmesg for fun.
\nThe "who" utility from Rust-based coreutils was triggering AppArmor warnings on my Kubuntu box while\ntrying to access its own localizations. The fix was trivial, and the AppArmor maintainers are\nblazing fast.
\nNow I officially refuse to talk to plebs without comparable legacy in open source.
", "summary": "For the first time in my life, my modest pull request was accepted into a mainstream project (AppArmor). That was also my first attempt. All because of intense hatred for warnings in system logs. And because I read dmesg for fun. The \"who\" utility from Rust-based coreutils was triggering AppArmor warnings on my Kubuntu box while trying to access its own localizations. The fix was trivial, and the AppArmor maintainers are blazing fast. Now I officially refuse to talk to plebs without comparable legacy in open source.", "date_published": "2026-05-12T02:59:00.000Z", "tags": [ "Open Source" ], "authors": [ { "name": "Damián Búho" } ] }, { "id": "01M293G9GXAA3B39G0HNK87ARR", "url": "https://dbuho.me/post/deployed-reseed-server-for-i2p-on-kiota/?utm_source=posts&utm_medium=rss", "title": "Deployed I2P Reseed server on Kiota", "content_html": "Made my own reseed server for I2P.
\n\n\nI2P is a peer-to-peer network which uses “Garlic Routing” to maintain privacy. Reseed nodes help you get connected to I2P for the first time, and even though you should only have to use them once in a great while, they are very important services.
\n
I have my own distribution/image that automates some fuss with installation.
\nFeeling like a very niche Atlas.
", "summary": "Made my own reseed server for I2P . I2P is a peer-to-peer network which uses “Garlic Routing” to maintain privacy. Reseed nodes help you get connected to I2P for the first time, and even though you should only have to use them once in a great while, they are very important services. I have my own distribution/image that automates some fuss with installation. Feeling like a very niche Atlas.", "date_published": "2026-09-02T02:59:00.000Z", "tags": [ "Containerization", "Networking", "I2P", "Censorship" ], "authors": [ { "name": "Damián Búho" } ] } ] }