@aauth/bootstrap - npm Package Compare versions

Comparing version

1.2.1

1.2.2

+1

-1

package.json

		{
		"name": "@aauth/bootstrap",
		"version": "1.2.1",
		"version": "1.2.2",
		"description": "CLI for bootstrapping AAuth agent keys and configuration",
		@@ -5,0 +5,0 @@ "type": "module",

+17

-15

skills/platforms/github-pages-uninstall.md

		@@ -21,15 +21,17 @@ ---

		Look for an existing `username.github.io` clone first (the user may already have one — common locations: `~/github/`, `~/code/`, `~/src/`). If none:
		Ask the user whether they have a local clone (paths vary — don't guess). Store the path as `REPO` for the rest of this skill. If they don't:

		```bash
		gh repo clone username/username.github.io
		```
		gh repo clone username/username.github.io /tmp/username.github.io
		# REPO=/tmp/username.github.io
		```

		Run all git commands with `git -C "$REPO"` so you don't need to `cd`.

		### 2. Sync with the remote

		```bash
		cd username.github.io
		git fetch origin
		git pull --ff-only
		```
		git -C "$REPO" fetch origin
		git -C "$REPO" pull --ff-only
		```

		@@ -40,5 +42,5 @@ Do NOT proceed if the pull fails — investigate first. A non-fast-forward means someone else changed the repo; bring it up to date before deleting anything.

		```bash
		ls -la .well-known/ 2>/dev/null
		```
		ls -la "$REPO/.well-known/" 2>/dev/null
		```

		@@ -51,5 +53,5 @@ - Both files present → continue to step 4.

		```bash
		git rm .well-known/jwks.json .well-known/aauth-agent.json
		```
		git -C "$REPO" rm .well-known/jwks.json .well-known/aauth-agent.json
		```

		@@ -60,5 +62,5 @@ Delete ONLY these two files. Do not touch other content in `.well-known/` or anywhere else in the repo — many users host real content here.

		```bash
		git commit -m "Remove AAuth JWKS and agent metadata (uninstall)"
		```
		git -C "$REPO" commit -m "Remove AAuth JWKS and agent metadata (uninstall)"
		```

		@@ -69,5 +71,5 @@ This exact phrasing is what the `github-pages` publish skill scans for when it decides whether to treat a future install as "first-time" — i.e. to avoid silently resurrecting deleted keys from a stale local clone on another machine. Don't change the wording.

		```bash
		git push origin <default-branch>
		```
		git -C "$REPO" push
		```

		@@ -74,0 +76,0 @@ GitHub Pages can take up to a minute to update its cache. Poll until both URLs return 404 before reporting success — a successful `git push` is NOT proof the world has changed:

+24

-29

skills/platforms/github-pages.md

		@@ -43,45 +43,34 @@ ---

		- Ask the user whether they have a local clone (paths vary by user — don't guess).
		- If they don't, clone to a known location (e.g. `/tmp/username.github.io`) with `gh repo clone username/username.github.io`.
		- Ask the user whether they have a local clone (paths vary by user — don't guess). Store the path as `REPO` for the rest of this skill.
		- If they don't, clone to a known location: `gh repo clone username/username.github.io /tmp/username.github.io` and use `REPO=/tmp/username.github.io`.
		- If the repo doesn't exist on GitHub, create it with `gh repo create username.github.io --public` then clone it.

		Run all git commands with `git -C "$REPO"` so you don't need to `cd` (Claude Code's bash sessions are configured to discourage `cd`).

		### 3a. Sync the local clone with the remote — REQUIRED before editing

		Skipping this step has resurrected uninstalled keys in the past. If the
		remote was modified from another machine (in particular, if `uninstall` ran on a
		different device and deleted `.well-known/jwks.json` / `aauth-agent.json`), the
		local clone is stale, and the "read existing JWKS and append" step below will
		silently re-publish keys the user intentionally removed.
		Skipping this step has resurrected uninstalled keys in the past. If the remote was modified from another machine (in particular, if `uninstall` ran on a different device and deleted `.well-known/jwks.json` / `aauth-agent.json`), the local clone is stale, and the "read existing JWKS and append" step below will silently re-publish keys the user intentionally removed.

		In the clone:

		```
		git fetch origin
		git log --oneline -n 10 origin/HEAD -- .well-known/
		git -C "$REPO" fetch origin
		git -C "$REPO" log --oneline -n 10 origin/HEAD -- .well-known/
		git -C "$REPO" pull --ff-only
		```

		Then:
		Do NOT proceed if the pull fails — investigate first.

		- `git pull --ff-only` (or `--rebase` if needed) so local matches the remote
		default branch. Do NOT proceed if the pull fails — investigate first.
		- Scan the recent commit log printed above for `uninstall`, `Remove AAuth`, or
		any deletion of `.well-known/jwks.json` / `.well-known/aauth-agent.json`. If
		you find any:
		- Treat the current install as a fresh start — do not "merge" the new key
		into a locally-cached JWKS. The intended remote state is "no keys."
		- If `.well-known/` no longer exists on the remote, the local copy after `git
		pull` will also not have it. Recreate from scratch with just the new key,
		not by reading whatever stale tree you remember.
		- Surface what you found to the user before editing anything ("the remote shows
		an uninstall commit at <SHA> — proceeding will set up a fresh identity with
		only the new key, not restore the old ones — confirm?").
		Then decide: are you on a fresh-start path or a merge path?

		- Fresh-start path — after pull, `.well-known/jwks.json` does NOT exist locally (and the log shows it was removed by a prior uninstall). Recreate from scratch with just the new key. No confirm needed — this is exactly what an uninstall+reinstall looks like; the user already opted into a fresh identity by running setup again.
		- Merge path — after pull, `.well-known/jwks.json` exists locally AND the log shows a recent uninstall commit. This is the dangerous case — you'd be merging the new key into a JWKS that the uninstall thought it had cleared. Surface it: "the remote shows an uninstall commit at \<SHA\> but the JWKS is still present locally — proceeding would merge the new key with the existing ones — confirm?"
		- Normal path — no uninstall commits in the log. Continue without confirming.

		### 4. Ensure `.nojekyll` exists

		GitHub Pages uses Jekyll by default, which ignores dotfiles like `.well-known/`. Create an empty `.nojekyll` file in the repo root if it doesn't already exist.
		GitHub Pages uses Jekyll by default, which ignores dotfiles like `.well-known/`. Create `$REPO/.nojekyll` (empty file) if it doesn't already exist.

		### 5. Create or update `.well-known/jwks.json`

		In the GitHub Pages repo:
		- If `.well-known/jwks.json` exists, read it and parse the `keys` array.
		Work with `$REPO/.well-known/jwks.json`:
		- If it exists, read it and parse the `keys` array.
		- If it doesn't exist, create the `.well-known/` directory and start with `{ "keys": [] }`.
		@@ -123,3 +112,9 @@ - Add all public JWKs from step 2 to the `keys` array.

		Commit the changes and push so the files are published at:
		```
		git -C "$REPO" add .nojekyll .well-known/jwks.json .well-known/aauth-agent.json
		git -C "$REPO" commit -m "Publish AAuth agent metadata and JWKS"
		git -C "$REPO" push
		```

		Files will be published at:
		- `https://username.github.io/.well-known/jwks.json`
		@@ -126,0 +121,0 @@ - `https://username.github.io/.well-known/aauth-agent.json`

@aauth/bootstrap - npm Package Compare versions

Improved metrics