[BK5102]

What and why

The first automatic Deploy run (after #9 merged) failed at the publish step:

Error: Could not parse name and email from user option "github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>"

This PR fixes two problems in .github/workflows/deploy.yml:

1. Commit identity. gh-pages -u parses its value as an RFC 5322 address, and [ ] aren't allowed unquoted, so the [bot] name fails. The identity now comes from git config user.name/user.email, which gh-pages reads when -u is absent.
2. Push auth (would have failed next). gh-pages clones the repo into node_modules/.cache/gh-pages. That clone doesn't inherit the auth header actions/checkout stores in the workspace's .git/config, so the push would be rejected. The remote URL now carries GITHUB_TOKEN, as the gh-pages README recommends for Actions. The job already has contents: write. GitHub masks the token in logs.

The site is currently live from a manual npm run deploy off main at 653e123 (the fallback in CONTRIBUTING §7).

How it was tested

• Reproduced the parse failure locally with the email-addresses parser gh-pages uses. Confirmed gh-pages falls back to git config when -u is omitted (lib/index.js getUser()).
• Validated the YAML.
• npm run lint: 0 errors. npm run check-links: no internal dead links. npm run build: OK.
• Not yet run end to end on Actions. To check before merging: Actions → Deploy → Run workflow → branch fix/deploy-workflow. The built site is identical to what's live, since only the workflow changed. Otherwise, the first push to main after merging exercises it.

Performance (Lighthouse, mobile, median of 3, local Edge; no site code changed)

Page	Score	FCP	LCP	TBT	CLS	Weight
#/	98	1.66 s	2.15 s	87 ms	0.000	197 KB
#/about	97	1.58 s	2.53 s	56 ms	0.000	388 KB

After merge

Per the deployment checklist: CI on main → Deploy green → pages-build-deployment green → check https://devilquant.com. Delete fix/deploy-workflow afterwards.

[BK5102]

Local end-to-end test of the publish step (fec3db2)

I ran the step's exact commands against a throwaway local bare repo. The remote was set to the CI-shaped URL https://x-access-token:FAKE_TOKEN@github.com/DevilQuantASU/dq-website.git, and git url.insteadOf redirected it to the bare repo, so nothing touched GitHub. Global git config was disabled, so the identity could only come from the step's git config.

Published
author:    github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
committer: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
gh-pages:  404.html CNAME DQ.png assets discord index.html linkedin logos sundevilcentral
CNAME:     devilquant.com

This confirms that the -u parse error is gone, that the bot identity is used, and that gh-pages accepts the token-in-URL remote. Pushing with a real GITHUB_TOKEN can't be tested locally. It's the pattern the gh-pages README documents for Actions, and the job has contents: write. The first Deploy run after merging will confirm it.

CI on this PR: verify ✅ performance ✅.