My First Published Article Links to a GitHub User That Doesn't Exist. It's Been Live and Broken for 45 Days.

A developer discovered that their second-ever published article on DEV.to has contained a broken GitHub link for 45 days, pointing to a nonexistent user 'enjoy-kumawat' instead of the correct 'enjoykumawat'. The typo, baked into the source markdown, went unnoticed because no pipeline re-checks previously published articles. The developer verified the dead link using 'git ls-remote', which cleanly distinguishes nonexistent repos from GitHub's anti-bot 403 responses.

Ninety-two articles into this account, every fix I've written up has been about this repo's code — a urllib call with no except block, a path that resolves differently depending on which of two documented install methods you used, a dedup check keyed on the wrong id. What none of the 92 ever did was go back and re-read one of the 92 themselves. So I did that today, and the account's second-ever article — "I Fixed the 'AI Commit Messages' Problem in 20 Lines of Python," published 2026-06-21, still live — has had a broken GitHub link in it for 45 days. Nobody caught it because nothing in this repo's pipeline, or in any of the 91 posts published after it, ever re-checks a previously-published article's own body. The article's closing line: Full project: github.com/enjoy-kumawat/my-git-manager https://github.com/enjoy-kumawat/my-git-manager enjoy-kumawat — with a hyphen. My real GitHub username, documented in this repo's own key facts.md , is enjoykumawat — no separator at all. This isn't the underscore-vs-no-separator bug this repo already fixed once bugs.md , 2026-06-21, "Username Underscore Mismatch" — .env 's GITHUB USERNAME held the DEV.to-style value enjoy kumawat with an underscore, and ADR-003 hardcoded the correct GitHub username as a constant to stop it leaking into API calls . That fix touched exactly one thing: the GITHUB USERNAME constant gh builds URLs from in server.py and publish devto.py . It never touched, and had no way to touch, a URL typed directly into an article's prose. This is a third spelling of the same handle — not the correct one, not the DEV.to one — sitting in a file no code path ever reads. article draft.md , still sitting at the repo root, is the source markdown for that exact article — key facts.md 's own Project Files table says so: "Source for DEV.to article published 2026-06-21 — post article.py, the script that posted it, was removed 2026-07-16 as a superseded duplicate of publish devto.py." The typo is baked into the source file itself: bash $ grep -n "enjoy-kumawat" article draft.md 93:Full project: github.com/enjoy-kumawat/my-git-manager https://github.com/enjoy-kumawat/my-git-manager post article.py posted this file back on day one, before publish devto.py existed, before there was a tag-truncation rule, before there was a duplicate-title check — before basically every hardening pass this account has ever written about. The typo went live with it and has outlived the script that shipped it by seven weeks. My first instinct was to curl the URL and check the status code. That's the wrong tool here, and it cost me a false positive later in this same investigation more on that below — GitHub's anti-bot layer 403s plenty of pages that are completely real, including, as I found out, github.com/modelcontextprotocol/python-sdk fetched with a browser-style User-Agent. A 403 from curl proves GitHub is suspicious of the client, not that the repo doesn't exist. git ls-remote doesn't have that problem — it's the actual protocol a clone uses, and GitHub's response for a genuinely nonexistent or private-and-inaccessible repo has a distinct, unambiguous shape: bash $ git ls-remote https://github.com/enjoy-kumawat/my-git-manager.git fatal: could not read Username for 'https://github.com': terminal prompts disabled $ git ls-remote https://github.com/enjoykumawat/my-git-manager.git f31350f69d45bcde886043f0e5f42228777d2465 HEAD f31350f69d45bcde886043f0e5f42228777d2465 refs/heads/main I ran the hyphenated URL against a control — a deliberately made-up repo name enjoykumawat/definitely-fake-xyz999 — three separate times. All three gave the identical could not read Username failure, with the identical exit code 128. The real repo, same command, same session, resolves cleanly every time. That's about as close to "verified live" as a dead link gets without an HTTP status code to point at. The article has a sibling problem I initially thought I'd found too: the account's very first article, "I built an MCP server that lets Claude manage my GitHub profile and DEV.to articles," links to github.com/enjoykumawat/developer-presence-mcp — a repo name this project hasn't gone by since before I started tracking it in key facts.md . Same curl 403 pattern I'd just decided not to trust for the first bug. I almost fixed it anyway, on the theory that the repo had been renamed to my-git-manager and the old link just never got updated — that's a plausible story, and it's the kind of thing this account's whole publishing pipeline does elsewhere README paths, hooks paths, .env paths all drifted this same way at some point . I ran git ls-remote on it before touching the live article, expecting the same "could not read Username" failure I'd just gotten for the actual bug. Instead: bash $ git ls-remote https://github.com/enjoykumawat/developer-presence-mcp.git 729c41d145d0a2a4542de5b76d9ecbc21d7d2958 HEAD 729c41d145d0a2a4542de5b76d9ecbc21d7d2958 refs/heads/main A real SHA, a real main branch. Pulling the README off it confirmed it's a genuine, separate, still-live repo — an earlier snapshot of this same project under its original name, apparently never deleted when the newer my-git-manager repo took over. I'd already PUT a "fix" to that article's live body before running this check swapping developer-presence-mcp for my-git-manager everywhere , caught it was wrong, and PUT the original text straight back: a2 = get article 3954657 body2 = a2 "body markdown" reverted = body2.replace "my-git-manager", "developer-presence-mcp" r2 = put article 3954657, reverted Confirmed via a follow-up GET that the article matches its original body exactly. No harm done, but it's a clean illustration of why "the fetch 403'd" isn't evidence of anything on its own — it would have replaced one working, correctly-owned link with an unrelated repo, based on a hunch that happened to be wrong, verified by the same shallow check that gave me the false lead in the first place. For the one link that really is dead, I didn't touch server.py or publish devto.py — there's no code bug here, just a stale live document. update article 's whole reason for existing bugs.md , 2026-07-27: "a wrong or hallucinated article id used to silently overwrite whatever it pointed at with no trace" is exactly the tool for this, so I used the same PUT-with-diff shape it implements, directly against the live article: a1 = get article 3954807 body1 = a1 "body markdown" fixed1 = body1.replace "enjoy-kumawat", "enjoykumawat" r1 = put article 3954807, fixed1 Then re-fetched the article and confirmed the string enjoy-kumawat no longer appears anywhere in the live body, and that git ls-remote against the corrected URL resolves cleanly. Also fixed the same typo in article draft.md , the local source, so a future re-read of that file doesn't reintroduce it. Before treating this as an isolated typo, I pulled every published article's body all 92, paginated and extracted every github.com/... link across the entire account. After the fix, there are exactly three distinct GitHub links used anywhere in 92 articles — this project's repo, the MCP Python SDK, and one OSS PR link — and all three now resolve. The hyphenated typo was the only dead one, and it was there from the account's second post onward, never touched by anything published after it. The pattern here isn't "check your links once." It's that a repo that spends this much effort hardening its own code — except blocks, idempotency guards, path resolution across install methods — has zero mechanism pointed at the thing it actually ships: the published articles themselves. Ninety-one follow-up posts audited server.py , reply comments.py , publish devto.py , three different hook-path arithmetic bugs. Not one re-read what article 2 actually says.