The star history chart was broken due to GitHub stargazer API restrictions. Update the chart URLs in README.md, README_CN.md and README_JA.md so the chart renders again.
PR #1463 removed the Sora platform, but some references survived:
- README/README_CN/README_JA kept the 'Sora status (temporarily
unavailable)' sections and gateway.sora_* docs that the removal PR
never touched.
- deploy/config.example.yaml still documented ~130 lines of sora_*
gateway keys, the top-level sora: direct-client/storage block, and
token_refresh.sync_linked_sora_accounts - none of which map to any
field in the config structs anymore.
- The OIDC login PR (02a66a01c, branched off pre-removal main and
merged 4 days after #1463) re-added the dead
PublicSettings.SoraClientEnabled field, which no code ever sets.
- A release sync (748a84d87) re-introduced sora i18n keys that the
later i18n split (d9e514f98) faithfully carried into
locales/{zh,en}/admin/{overview,settings}.ts. No component references
any of these keys.
This drops all of the above. Pure deletions, no behavior change.
DEV_GUIDE.md and the three READMEs still advertise Go 1.25.7 and
golangci-lint v2.7, but CI has since moved on:
- backend/go.mod declares go 1.26.5, and backend-ci.yml / release.yml /
security-scan.yml all resolve the toolchain via
`go-version-file: backend/go.mod` and then hard-assert
`go version | grep -q 'go1.26.5'`.
- backend-ci.yml pins golangci-lint to v2.9.
So a contributor following DEV_GUIDE.md installs a linter two minor
versions behind CI (different findings locally vs. in CI) and expects a
Go version that the workflow's own assertion step rejects.
Update all ten stale references, and note in the CI section which files
the Go version assertion lives in so future bumps don't miss one.
Docs only, no code or workflow changes.
Method 3 (source compile) instructs users to pre-create config.yaml,
but does not mention that doing so disables the setup wizard — the
only code path that creates the initial admin account. Users following
the README end up with a running server and an empty users table, and
login fails with "invalid email or password".
The default.admin_email / default.admin_password fields in config.yaml
are loaded into the config struct but never read by any code path
(setup.SetupConfig.Admin is tagged yaml:"-"), so they cannot serve as
an alternative way to seed the admin.
Add a "Creating the Admin Account" subsection to Method 3 in all three
language READMEs (EN/CN/JA), explaining the wizard dependency and two
workarounds: let the wizard generate config.yaml, or temporarily move
config.yaml aside to trigger the wizard on first run.
Related: #521 (docker variant of the same symptom), #2617, #2350.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
shaw