- kigi-env: update_base_url defaults to
api.github.com/repos/ELY-Open-Source/Kigi-CLI/releases.
- install.sh / install.ps1: resolve releases from the same API.
- /feedback and the no-session feedback fallback open GitHub issues/new;
/docs opens the README on GitHub.
- SECURITY, NOTICE, AGENTS, CONTRIBUTING: GitHub repo, issues and fork-based
pull requests replace git.zacharyzhang.com and AGit.
Co-Authored-By: Claude <noreply@anthropic.com>
The GitHub account is gone again, so git.zacharyzhang.com/ZacharyZhang-NY/Kigi-CLI
is the canonical repo. Reverse f7a4cb6:
- .gitea/workflows/release.yml: restore the Gitea edition retired in f7a4cb6
(draft release, per-target upload, SHA256SUMS, then publish). The Windows
leg runs on the windows-amd64 label the current runner advertises.
- .github/workflows/{release,warm-cache}.yml: drop them; they target hosted
GitHub runners and softprops, and Gitea ignores them once .gitea exists.
- kigi-env: update_base_url defaults to the Gitea Releases API again.
- install.sh / install.ps1: resolve releases from git.zacharyzhang.com.
- feedback, /docs, SECURITY.md, frontend worker + site: repo, issues and
raw-file links point at git.zacharyzhang.com.
- docs/RELEASE.md: Gitea edition of the checklist with the current runners.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The GitHub account is restored, so github.com/ZacharyZhang-NY/Kigi-CLI is
the canonical repo again. Reverse the 2026-08 Gitea migration:
- .github/workflows/{release,warm-cache}.yml: restore the GitHub-hosted
pipeline dropped in 3e1652c, unchanged — hosted runners, rust-cache,
softprops release with every asset attached atomically.
- .gitea/workflows/release.yml: retire the Gitea edition (the runners are
being deregistered; git.zacharyzhang.com keeps the v0.1.12/v0.1.13
releases for old clients).
- kigi-env: update_base_url now defaults to the GitHub Releases API. The
updater already speaks GitHub wire format and sends a User-Agent; v0.1.14
is published to BOTH forges with identical assets so pre-0.1.14 installs
polling Gitea self-update onto the GitHub channel.
- install.sh / install.ps1: resolve releases from api.github.com.
- feedback, /docs, SECURITY.md, frontend worker + site: repo, issues and
raw-file links point at github.com / raw.githubusercontent.com.
- docs/RELEASE.md: GitHub edition of the checklist; Gitea runner sections
retired.
- version: 0.1.13 -> 0.1.14 (the cross-forge transition release).
Claude-Session: https://claude.ai/code/session_01A6RcwHhhsFYYrNdQB4ASuP
The canonical repo is git.zacharyzhang.com now, so every URL a user can
actually reach had to move with it.
Self-updater: `PRODUCTION_ENDPOINTS.update_base_url` targets Gitea's
`/api/v1/repos/.../releases`, which serves the same wire format GitHub's
releases API did — `Release`/asset deserialisation is unchanged. The alpha
channel requests `?per_page=30&limit=30` because GitHub reads the page size
from `per_page` and Gitea from `limit`, and each ignores the other's, so one
URL stays correct on either.
Installers: same API base, and the documented one-liners become
`https://kigicli.dev/install.{sh,ps1}`. That domain's Worker proxies both
files from Gitea raw `main`, so the published install command survives any
future forge move without being reprinted everywhere. install.ps1 also drops
the GitHub-specific `Accept: application/vnd.github+json`.
Everything else user-facing: `/feedback` and the shell's feedback fallback
point at the Gitea issue tracker, `/docs` at the Gitea-rendered README, and
web_fetch's User-Agent at kigicli.dev. SECURITY.md now routes reports to the
issue tracker with a warning to withhold exploitable detail, because Gitea
has no equivalent of GitHub's private vulnerability reporting. Comments
naming `.github/workflows/release.yml` name `.gitea/` now.
Tests assert against these constants rather than literal URLs, so they
follow automatically; the one URL-shape assertion (production endpoints are
https) still holds.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ZacharyZhang-NYandClaude