A software release includes more than the source files developers review. Build output, source maps and packaging rules decide what customers can actually download. Those artefacts deserve their own checks.
The Claude Code incident is a useful prompt to review that process. GitHub’s 31 March 2026 takedown record says the notice was applied to a network of 8 100 repositories. A partial retraction dated 1 April requested reinstatement of repositories beyond the parent and the specifically listed forks.
Those records establish the takedown and correction. They do not substantiate every claim circulating about internal features, customer impact or the company’s motives.
Inspect the package you will publish
Build the release in a clean environment and inspect the resulting archive. Check for internal configuration, test records, credentials, debugging files and source maps that are not intended for distribution.
A repository can be tidy while the published archive contains unexpected files. Review packaging rules and compare the archive with the previous release. Make that check part of the release process, with a named person responsible for exceptions.
Decide how to handle source maps
Source maps help developers connect compiled code to its original source during debugging. Decide deliberately whether they belong in public assets, private error-reporting systems or neither.
Check the actual production output against that decision. Frontend configuration, deployment scripts and monitoring integrations can each change what is uploaded. Also assume that code deliberately sent to a browser can be inspected by its users; keep secrets and privileged decisions on the server.
Communicate what you can verify
When a release goes wrong, separate the observed facts from the investigation. Tell affected people which product and versions are involved, what action they need to take and where the next update will appear.
Avoid claiming that customer information is safe or exposed before you have evidence. If an earlier statement was wrong, publish a clear correction in the same place as the original update. Quietly changing the wording leaves readers working from different accounts.
Rehearse recovery before you need it
Keep a tested rollback procedure and a record of who can pause releases, revoke credentials and contact affected customers. Preserve evidence before removing the affected artefact from circulation.
For a small South African software team, this can be a short release checklist and a practical rehearsal. Test whether another person can follow it without the original developer in the room. Contact webrack if you need help reviewing a website or application’s release process.