If you saw this account cold, you would scroll past it. FarzamHabibi. Bio: Product Designer. 7 followers. 9 public repos. Account created 2022-08-27. The repo in question, pre-production-checklist, was created 2026-08-27, so it is about a week old. 10 stars, 1 fork, last push 2026-09-03. Nothing here signals authority. Nothing here should make you stop scrolling.
I want to walk through what happened anyway, because the exchange is a better argument for taking feedback seriously than any bio could be, and because it is fully public. Every claim below has a permalink. Click them.
On 2026-08-30 I opened issue #11 on his repo, pointing out that his post-launch section was thin on regression and monitoring content, and mentioning Muraqib, the QA tool I build, as one way to satisfy that kind of check. This is the part I need to be direct about: he said no. His CONTRIBUTING.md is explicit about this. "This is a checklist, not a directory. Items describe a check, something to verify about your own system. They do not name a product as the way to satisfy it, and requests to add a tool, service or vendor are declined as a matter of policy rather than judgment." That is not a judgment call he made about Muraqib specifically. It is a blanket rule, 88% of the checklist's items name no product at all, and it is what keeps the thing stack-agnostic. So this is not a story about a product getting listed. It never did.
What he did instead, on 2026-09-02, was more interesting. He replied that the underlying question was a fair hit, searched his own checklist for regression, smoke, synthetic, and end-to-end coverage, found exactly one unrelated item, and added a new six-item subsection to post-launch/01-readiness.md called "Will you notice before a customer does." (https://github.com/FarzamHabibi/pre-production-checklist/issues/11#issuecomment-5513548917)
I took those six items and pointed them at my own project. On 2026-09-03 I replied with two real bugs, found by testing Muraqib's own systems against his new checklist. First: Muraqib's own nightly Playwright run had been cancelled 81 of 164 times since late June, the last 60-plus of those consecutively, discovered only in September, because a GitHub Actions runner timeout produces a conclusion of "cancelled" rather than "failure," so failure-keyed alerting never fired. Second, found while fixing the first: all three of the project's notification paths, a weekly digest, a fix-workflow email, and an auto-rollback alert, handled a missing alerting credential by silently doing nothing and still reporting success. Twelve consecutive green Mondays of a weekly digest that sent nothing. None of the curl calls used --fail either, so even a valid key returning a 401 would have exited 0. (https://github.com/FarzamHabibi/pre-production-checklist/issues/11#issuecomment-5520186746)
His reply, a few hours later, called it "the best thing anyone has sent this project," and specifically praised that these were live bugs found and written up, not just a suggestion that checks were missing. He added another six-item subsection, "When the thing that watches stops watching," then turned it on his own repo and found two of his own bugs: curl calls in his own pre-push gate with no --fail, and zero scheduled runs anywhere in his CI, everything push-triggered, meaning weeks without a push would mean weeks unchecked with no visibility. Both fixed in the same commit as the new items. (https://github.com/FarzamHabibi/pre-production-checklist/issues/11#issuecomment-5523306654)
That prompted a deeper pass on my end. Not a quick check, a multi-pass adversarial review of Muraqib's workflows, every finding re-verified by hand against the raw code before any fix. I found a notification email hardcoded to muraqib@yourdomain.com and you@yourdomain.com instead of reading configured secrets, meaning that specific email had never worked since the project's first commit, and had survived three earlier security passes because it fails loudly rather than silently. I found no concurrency group and no deduplication on automated issue creation, confirmed live: one flaky test had produced 19 open, never-closed duplicate issues in 4.5 days. A test-counting bug fixed once had been reintroduced in a sibling file. A path traversal issue in muraqib init --dir. And a watchdog script with no try/catch around its own body, so a network error while it checked would silently skip its own alert, the same shape of bug one layer out. All fixed and live on main, full suite 96 of 96 green afterward. (https://github.com/FarzamHabibi/pre-production-checklist/issues/11#issuecomment-5526455379) I later confirmed the referenced merge commit, c3cdae24b292530793831f12b194f5eecfb336ba, actually exists in the history, touching five files across 162 insertions and 36 deletions.
His final reply called it "the most useful thing anyone has sent back," but said the most valuable part was the distinction drawn, a check that structurally cannot fail versus a check that is simply broken, not the bugs themselves. He found four of his own cannot-fail checks as a result: a staleness check comparing file mtime, which git does not preserve, so it could only ever report one answer; a gate counting files instead of comparing contents; a link checker treating an empty result as a pass; a curl piping a 500 error page into a JSON parser without --fail. He specifically called out a cancel-in-progress: false setting I'd added, with the reason documented next to it, as an example of the lesson being used as a forward design constraint rather than only a retrospective fix, "further than I expected anyone to take it." Checklist grew from 322 to 325 checks, 4,352 total items, released as version 1.17.0. He closed with "Good luck with the rest of it." (https://github.com/FarzamHabibi/pre-production-checklist/issues/11#issuecomment-5531221545)
I closed by agreeing the design-constraint framing was the most durable part of the exchange, and that his own four cannot-fail checks are a better outcome than anything landing in a published list, since it travels past the specific bug. (https://github.com/FarzamHabibi/pre-production-checklist/issues/11#issuecomment-5535511286)
His own CONTRIBUTING.md has a section called War stories: "If an item here would have caught a bug you actually shipped, say so in an issue. That is the strongest possible argument for keeping an item, and it helps everyone prioritize." That is what this was, on both sides, twice each.
None of this required either of us to be anyone. He did not list my product, on principle, and I would not want him to. What he did instead was harder to fake: he read the reasoning, applied it to his own code twice, and found bugs of his own each time, two and then four. Follower counts do not predict that. Reading the diff does.
This article was originally published by DEV Community and written by holistis.
Read original article on DEV Community