Chapter 24. 2026-05-11: The Name on the Work

A GitHub comment goes out under whichever account gh has active, and gh does not ask before stamping that identity onto a permanent public record. Mine went out in May 2026 on solana-foundation/awesome-solana-ai#155, an external repo, under the deprecated Suede-AI bot account, and the guard against a repeat is a gh auth status check before every mutating command. Two GitHub accounts sit in this machine’s gh keyring. JasonColapietro is me. Suede-AI is a deprecated bot account, kept around because the Suede repos live under it. The difference between the two was bookkeeping until May 2026, when it became an incident. On 2026-05-11 it became a rename.

The comment that posted under the bot account

A PR comment went out on solana-foundation/awesome-solana-ai#155, an external repo in the Solana ecosystem, under the Suede-AI account. The mechanics were dull: the keyring had the secondary account active, the comment command ran, and nothing in the chain verified which identity was signed in before the mutation. gh does not ask. It stamps whatever account is active onto the record. My log holds the month of the incident, not the day; what it holds with precision is the cost.

On my own repos a wrong byline is cosmetic: I see it, I fix it, no outsider was forming a first impression. On an awesome-list PR in someone else’s ecosystem, that comment was the introduction. A maintainer deciding whether to engage with Suede Labs AI looked at the thread and saw a bot account where a founder should have been. The comment content was fine. The authorship was the defect, and the defect class is the bad kind: a mutating command stamps an identity onto a permanent public record, while a read-only command stamps nothing. The check would have cost one command before posting. The mistake is not retractable after.

Why attribution is a distribution asset

Attribution, for a solo founder, is a distribution asset and not a cosmetic detail. Investors, hiring partners, and collaborators check founder GitHub activity, and they read package metadata. Work published under my name compounds: each public commit, comment, and listing adds to a record those people inspect before they take a founder at his word. The same work published under Suede-AI compounds nothing. The account reads as a faceless bot, and a bot byline builds no founder visibility regardless of the quality of the work behind it.

The rule this produced applies hardest where the wrong byline landed: external and ecosystem contributions, awesome-list PRs included, because those are the surfaces where strangers meet the work before they meet me. I wrote the rule into the agents’ standing instructions the same month, covering git identity and docs attribution both, because a rule that lives in my head does not bind an agent mid-run.

Why jasoncola1 became JasonColapietro

The incident forced a look at the personal account itself, and the look was unflattering. The handle was jasoncola1. A trailing digit on a founder handle reads one way to a stranger: the real name was taken, and this person settled for what was left. That reading was wrong, and it made no difference that it was wrong, because a profile header does not get to explain itself. A founder asking strangers to trust a small company cannot afford a handle that opens with an apology.

On 2026-05-11 I renamed the account from jasoncola1 to JasonColapietro. PascalCase is canonical. The canonical URL for docs, READMEs, and package.json is https://github.com/JasonColapietro; the lowercase form resolves as well. GitHub’s rename mechanics carried most of the migration: old jasoncola1 URLs auto-redirect for as long as that handle stays unclaimed. If a defensive squat-prevention account ever registers the old name, the redirect stops, but profile and PR URLs stay attached to me through the account ID. I recorded that trade-off the day of the rename and left the handle unclaimed.

One piece of matching work stayed pending as of 2026-05-11: the personal Vercel slug still needed a rename to match JasonColapietro. The Suede team slug suede-ai stays as it is; that slug names the brand, not the person, and the brand is the one place the bot-flavored name belongs.

Why the git author email stayed jasoncola1@gmail.com

The global git author identity is Jason Colapietro <jasoncola1@gmail.com>, unchanged. The email contains the old username, which makes it look like leftover cleanup; it is not. The address is Gmail, and Gmail is a separate system from GitHub usernames: the rename touched one system and not the other. The address remains the verified email on the renamed account, so commit attribution still resolves to me. A decade of tooling assumes usernames and emails move together. Here they do not, and the whole point of keeping the email is that the commits keep resolving.

That nuance became its own cleanup rule, because the natural failure mode is a find-and-replace. A sweep for jasoncola1 across repos and docs will match the email address. Replace the username in URLs, link text, and narrative references. Never change jasoncola1@gmail.com. Rewriting the email breaks commit attribution, which is the asset this entire entry exists to protect.

Why gh auth status still printed the old username

After 2026-05-11, gh auth status kept displaying jasoncola1. The rename came with a gotcha aimed at the exact verification step the new rule depends on: the one command that is supposed to prove the right account is active was printing the old identity, which looks like the wrong account being active right before a mutating command.

It is a display lag, not an identity problem. gh’s local keyring caches the display name. The OAuth token is bound to the account, not to the name, and it resolves to JasonColapietro whatever the status line prints. The token and the account ID behind it are the authoritative layer; the cached string is cosmetic.

gh auth status                    # may still print the cached name: jasoncola1
gh auth refresh -h github.com     # refreshes the cached identifier
gh auth switch --user jasoncola1  # until refreshed: selects the SAME account via its cached name

The third line is the one worth writing down, because it reads like a bug. To select the renamed account before the cache refreshes, you pass the old username. An agent that knows about the rename and sees jasoncola1 in a switch command will “correct” it and break the switch, so the runbook carries the reason next to the command.

The wider lesson: identity renames leave stale caches in tooling. Know which layer is authoritative (the OAuth token and the account ID) and which is cosmetic (the cached display name), or you chase a non-bug in a system that is working.

The identity rules I run before any mutating gh command

The incident and the rename condensed into a standing rule with four clauses.

Human-facing work carries the human’s name. Commits, gh activity, and the metadata surfaces people read without cloning anything: docs, READMEs, package.json, LICENSE, CITATION.cff, AUTHORS, listing metadata. All of it attributes to JasonColapietro.

Identity gets verified before mutation, not audited after. Before gh pr create, gh pr comment, gh issue create or gh issue comment, gh pr review, gh pr merge, or gh release create, the active account gets checked with gh auth status, with the cache lag above in mind. Read-only commands run under whichever account happens to be active; they stamp nothing.

The split has one surface where the bot name is correct. Suede-AI names repo paths, and it is the right value in the organization entity’s sameAs metadata, the exact opposite of the attribution rule. Contributors, maintainers, and founders attribute to the human. Run the split backwards in either direction and you either erase the founder or misfile the repo.

The bot account keeps a narrow lane. Genuine bot automation, CI tokens, and org-owned actions can act as Suede-AI when I ask for that, and the global git identity gets overridden with git -c user.email=... on explicit request only. An ambiguous case gets asked about, not guessed.

The canonical metadata values, recorded here so no future cleanup pass has to reconstruct them:

Postscript, 2026-05-15: Suede-AI is a User account, not an org

Four days after the rename, the second account produced a correction of its own: my notes had been calling Suede-AI “the org,” and the GitHub API reports it as "type":"User". The two memory files still disagree on paper (the attribution memo says org, the access memo says User account), and I am leaving the disagreement visible here rather than papering over it, because the access mechanics settle which one to act on. A User account has no teams and no org membership. Cross-account access to a private repo it owns works one way: a repository invitation, sent and accepted.

Suede-AI/strumly is private, so granting my personal account write access took a four-step one-time setup, completed 2026-05-15:

gh auth switch --user Suede-AI
gh api repos/Suede-AI/strumly/collaborators/JasonColapietro -X PUT -f permission=push
gh auth switch --user jasoncola1
gh api /user/repository_invitations/<id> -X PATCH

The third command is the keyring lag again: it selects the renamed personal account by its cached name. I verified the result with gh repo view Suede-AI/strumly --json viewerPermission, which returned "WRITE", and applied the same pattern to Suede-AI/suedeai-org on 2026-05-17.

The failure symptoms are worth recording because they lie. If the access lapses, gh repo view returns Could not resolve to a Repository and git push returns Repository not found, which is indistinguishable from the repo not existing at all. The fix is not discoverable from the error, so the exact reproduction steps live in the log, next to the reason the switch command uses an old name.

What is fixed, and what is still public

The comment on awesome-solana-ai#155 is still up there under the bot’s name; public records keep their stamps. Everything since runs through the identity check first. Attribution compounds one byline at a time, and the byline is now a checked invariant instead of an accident of which account was signed in.