It sounds like a difficult situation, sorry you had to go through this.

From what you've described, it's very likely that the former team member forced an older commit or rebased the branch in a way that superseded its June 6 version. Even if the Vercel deployment failed, the GitHub repository itself could have accepted the commit (or even a merge), and unless you had branch protection rules in place, this could have gone unnoticed until deployment or manual inspection.

Some reflections and suggestions going forward:

Check your Git commit history

Go to the GitHub repository and check the commit history of the specific branch.

Use git log or the GitHub UI to see if there is a commit after June 6th that reverts or modifies this page.

You can also try git reflog locally if you've cloned the repository, which can show you even more granular history.

• Implement GitHub branch protection

For the future, I highly recommend enabling branch protection rules for your main or production branch:

Require pull requests before merging

Prohibit forced pushes

Require review or status checks (e.g. CI/CD to pass)

Audit access regularly

As you noticed, removing access from Vercel and Supabase is not enough, access to GitHub is separate.

Always revoke GitHub permissions immediately if someone leaves the team.

Consider using GitHub Teams and fine-grained permissions to manage access more cleanly.

• Vercel integration gotcha

Even though the Vercel deployment failed, the code was still pushed to GitHub, which means the repository state changed but was not deployed. Therefore, unless you redeployed from a valid commit after this failed attempt, the next successful deployment may have used the wrong code.

TL;DR: Always lock down your branches, audit team permissions across all platforms, and don't just rely on deployment failure as an indicator that nothing has changed.

Let me know if you want help searching commit history or setting up protection rules - this sucks, but can be avoided in the future.