Modified - [docs] [changelog] [github-links] Converted remaining bare pull-request references in CHANGELOG.md and CHANGELOG-archived.md to explicit GitHub links.

- 1 - I updated `CHANGELOG.md` and `CHANGELOG-archived.md` so bare changelog references of the form `#123` now use explicit Markdown links to `https://github.com/go-gitea/gitea/pull/123`, while preserving the existing local changelog edits already present in the working tree.

.codex-context.md

@@ -11,8 +11,8 @@ Related orientation documents:
 
 1. `./.codex-context.md`
 2. `./.codex-project-map.md`
-3. `./.codex-history.md`
-4. The concrete files involved in the current task
+3. The concrete files involved in the current task
+4. `./.codex-history.md` only through targeted search, tags, or the latest relevant entries
 
 ## High-Value Project Anchors
 
@@ -33,6 +33,8 @@ For detailed request flow, auth flow, extension points, and task-oriented entry
 
 - Update `./.codex-history.md` after real project code changes.
 - Do not add Codex-only preference or memory edits to `./.codex-history.md`.
+- Do not reread unchanged context files within the same session unless the current task explicitly depends on them.
+- Prefer targeted search in `./.codex-history.md` by keyword, tag, or subsystem before reading larger ranges.
 - When the user asks for `revert`:
   - first show the latest 10 commits as a numbered list with short descriptions;
   - wait for the user's numeric choice before doing anything;
@@ -58,3 +60,5 @@ For detailed request flow, auth flow, extension points, and task-oriented entry
 
 - `main.go` defaults `setting.AppVer` to `development`; derive the real build/version string from the repository when writing `./.codex-history.md`.
 - The repository is predictably split across `cmd/`, `routers/`, `services/`, `models/`, `templates/`, and `web_src/`, so changes should normally stay localized to one or two layers plus their tests.
+- For custom release maintenance and repo-sync tasks, consult `./.codex-script-notes.md` before reanalyzing the large helper scripts.
+- New UI-visible functionality in this fork often also requires locale updates, so UI tasks and related history searches should usually consider `options/locale/`, especially `locale_en-US.json` and any actively maintained translated locale files.

.codex-history.md

@@ -1,14 +1,18 @@
 Project Change ID[date-time] - application-version - Type - Summary:
 
+History search guidance:
+- Prefer targeted search by task tag, subsystem keyword, or file/path before reading long ranges.
+- Entries are tagged inline as `[tag] [tag]` to support targeted search and filtering.
 
-0 - [2026-04-16 02:46:18] - v.1.27.0-dev-38-g4b334df6d4 - Type: Modified - Added explicit repository visibility badges to match the requested GitHub-style presentation more closely.
+
+0 - [2026-04-16 02:46:18] - v.1.27.0-dev-38-g4b334df6d4 - Type: Modified - [repo-ui] [visibility] [badges] Added explicit repository visibility badges to match the requested GitHub-style presentation more closely.
 - 1 - I modified `templates/repo/header.tmpl` so the repository page header now always shows a visibility badge on the right side: `Private`, `Internal`, or `Public`.
 - 2 - I modified `templates/shared/repo/list.tmpl` so each repository entry in shared repository lists also shows an explicit visibility badge for `Private`, `Internal`, or `Public`.
 - 3 - I added the `Public` label for repositories that previously had no explicit visibility badge, while preserving the existing archived, template, and sha256 labels.
 - 4 - I reused existing translation keys and existing badge styling so the change stays visually consistent with the current Gitea UI.
 
 
-1 - [2026-04-16 03:31:29] - v.1.27.0-dev-38-g4b334df6d4 - Type: Modified - Refined repository visibility badges with semantic colors, owner-aware navigation, and broader coverage in repository settings views.
+1 - [2026-04-16 03:31:29] - v.1.27.0-dev-38-g4b334df6d4 - Type: Modified - [repo-ui] [visibility] [badges] [repo-settings] Refined repository visibility badges with semantic colors, owner-aware navigation, and broader coverage in repository settings views.
 - 1 - I modified `templates/shared/repo/list.tmpl` so `Public` now uses a basic green badge and `Private` now uses a basic red badge, while `Internal` remains neutral.
 - 2 - I modified `templates/repo/header.tmpl` so the repository header uses the same color-coded visibility badges and keeps the mobile icon behavior unchanged.
 - 3 - I added owner-aware navigation for the `Public` and `Private` badges so they link to the repository `Settings` page only when the signed-in user is the repository owner.
@@ -16,628 +20,625 @@ Project Change ID[date-time] - application-version - Type - Summary:
 - 5 - I preserved the existing archived, template, fork, mirror, and object-format indicators so only the requested visibility presentation changed.
 
 
-2 - [2026-04-16 03:45:08] - v.1.27.0-dev-38-g4b334df6d4 - Type: Fixed - Corrected a template rendering error in /user/settings/repos caused by dereferencing a missing Owner object.
+2 - [2026-04-16 03:45:08] - v.1.27.0-dev-38-g4b334df6d4 - Type: Fixed - [user-settings] Corrected a template rendering error in /user/settings/repos caused by dereferencing a missing Owner object.
 - 1 - I fixed `templates/user/settings/repos.tmpl` so the internal-visibility check now guards against a nil `Owner` before accessing `Owner.Visibility`.
 - 2 - I applied the null-safe visibility guard in both repository list variants rendered by `/user/settings/repos`.
 - 3 - I preserved the new green/red visibility badge styling and owner-aware settings links while removing the nil-pointer render failure.
 
 
-3 - [2026-04-16 04:53:24] - v.1.27.0-dev-38-g4b334df6d4 - Type: Modified - Hid the admin privilege toggle when an administrator edits their own account from the admin user edit page.
+3 - [2026-04-16 04:53:24] - v.1.27.0-dev-38-g4b334df6d4 - Type: Modified - [admin-users] Hid the admin privilege toggle when an administrator edits their own account from the admin user edit page.
 - 1 - I modified `templates/admin/user/edit.tmpl` so the `Is Administrator` checkbox is no longer rendered when the edited user ID matches the signed-in admin ID.
 - 2 - I preserved the existing checkbox behavior for editing other users, so administrators can still grant or revoke admin rights for other accounts.
 - 3 - I kept the change limited to the admin edit UI without altering unrelated fields or backend update logic.
 
-4 - [2026-04-16 03:11:08] - v.1.27.0-dev-38-g4b334df6d4 - Type: Modified - Disabled the self-account deletion option only for the last administrator and aligned the backend rule with that behavior.
+4 - [2026-04-16 03:11:08] - v.1.27.0-dev-38-g4b334df6d4 - Type: Modified - [admin-users] [account-deletion] Disabled the self-account deletion option only for the last administrator and aligned the backend rule with that behavior.
 - 1 - I modified `templates/user/settings/account.tmpl` so the `Delete Your Account` action is disabled and shows the last-admin warning when the signed-in user is the only remaining admin.
 - 2 - I modified `routers/web/user/setting/account.go` so the account settings page now receives an `IsLastAdminUser` flag used by the template.
 - 3 - I updated the self-delete backend flow so it blocks account deletion only when the signed-in user is the last admin, instead of blocking every admin unconditionally.
 
-5 - [2026-04-16 03:26:40] - v.1.27.0-dev-38-g4b334df6d4 - Type: Fixed - Adjusted the shared last-admin detection to count only active administrators so account deletion and admin demotion rules behave correctly in real instances.
+5 - [2026-04-16 03:26:40] - v.1.27.0-dev-38-g4b334df6d4 - Type: Fixed - [admin-users] [account-deletion] Adjusted the shared last-admin detection to count only active administrators so account deletion and admin demotion rules behave correctly in real instances.
 - 1 - I modified `models/user/user.go` so `IsLastAdminUser` now treats only active admins as candidates when deciding whether a user is the last admin.
 - 2 - This aligns the shared last-admin protection used by account deletion and admin privilege update flows with practical instance behavior.
 - 3 - The existing `/user/settings/account` UI and backend guards now work against the refined active-admin definition without additional template changes.
 
-6 - [2026-04-16 03:43:20] - v.1.27.0-dev-38-g4b334df6d4 - Type: Modified - Updated the Delete Your Account panel for the last-admin case so it shows a direct warning message and hides the deletion controls.
+6 - [2026-04-16 03:43:20] - v.1.27.0-dev-38-g4b334df6d4 - Type: Modified - [user-settings] [admin-users] [account-deletion] [ui] Updated the Delete Your Account panel for the last-admin case so it shows a direct warning message and hides the deletion controls.
 - 1 - I modified `templates/user/settings/account.tmpl` so the panel now shows `You cannot remove the last admin. There must be at least one admin.` while keeping the existing alert icon.
 - 2 - I hid the `Password` field for the last-admin case.
 - 3 - I hid the `Confirm Deletion` button for the last-admin case while preserving the normal delete flow for other users.
 
-7 - [2026-04-16 17:37:53] - v.1.27.0-dev-40-gc3b9d21472 - Type: Added - Added administrator notifications for pending account requests and delayed the user activation email until manual approval.
+7 - [2026-04-16 17:37:53] - v.1.27.0-dev-40-gc3b9d21472 - Type: Added - [auth] [account-requests] [mailer] [locale] [en] Added administrator notifications for pending account requests and delayed the user activation email until manual approval.
 - 1 - I added a new `email_notification.new_account_requests` user setting in `models/user/setting_options.go`, with an admin-default enabled preference and helper functions to read the preference consistently.
 - 2 - I modified `routers/web/user/setting/notifications.go`, `routers/web/web.go`, and `templates/user/settings/notifications.tmpl` so administrators now get a `New account request notifications` checkbox in `/user/settings/notifications`, and the last active admin cannot disable it.
 - 3 - I modified `routers/web/auth/auth.go`, `services/mailer/mail_user.go`, `templates/mail/user/auth/new_account_request.tmpl`, and `options/locale/locale_en-US.json` so manual account requests now send notification emails to opted-in active admins with a direct review link.
 - 4 - I modified `routers/web/admin/users.go` so when an administrator activates a manually approved account while registration email confirmation is disabled, the applicant receives the standard account activation email at that approval moment.
 
-8 - [2026-04-16 18:59:58] - v.1.27.0-dev-41-g97eee0a9a8 - Type: Fixed - Corrected the new account request notification rule so at least one active administrator must remain subscribed.
+8 - [2026-04-16 18:59:58] - v.1.27.0-dev-41-g97eee0a9a8 - Type: Fixed - [account-requests] [locale] [en] Corrected the new account request notification rule so at least one active administrator must remain subscribed.
 - 1 - I modified `models/user/setting_options.go` to count active administrators who still have new account request notifications enabled and to detect when the current admin is the last enabled recipient.
 - 2 - I modified `routers/web/user/setting/notifications.go` so the backend now blocks disabling the preference only when the signed-in admin is the last enabled notification recipient, instead of checking whether they are merely the last admin user.
 - 3 - I modified `templates/user/settings/notifications.tmpl` so the checkbox and submit button are disabled only for the last enabled notification recipient.
 - 4 - I updated `options/locale/locale_en-US.json` so the warning message now states the real rule clearly: at least one admin must keep these notifications enabled.
 
-9 - [2026-04-16 20:53:32] - v.1.27.0-dev-41-g97eee0a9a8 - Type: Added - Added automatic notification fallback when deleting the only admin who still receives new account request notifications.
+9 - [2026-04-16 20:53:32] - v.1.27.0-dev-41-g97eee0a9a8 - Type: Added - [account-requests] Added automatic notification fallback when deleting the only admin who still receives new account request notifications.
 - 1 - I added `ShouldEnableNewAccountRequestNotificationsFallback` in `models/user/setting_options.go` so the code can detect when the deleted user is the last active admin with this notification enabled and the acting admin is currently unsubscribed.
 - 2 - I modified `routers/web/admin/users.go` so, after a successful admin-driven user deletion, the acting admin is automatically subscribed to new account request notifications when they deleted the last subscribed admin.
 - 3 - I modified `routers/api/v1/admin/user.go` so the same automatic fallback also applies to admin deletions performed through the API, keeping the behavior consistent across both deletion entry points.
 
-10 - [2026-04-16 23:02:55] - v.1.27.0-dev-42-g81727dd3e9 - Type: Added - Implemented a staged new account request workflow with email validation, admin review, request statuses, and automatic expiry cleanup.
+10 - [2026-04-16 23:02:55] - v.1.27.0-dev-42-g81727dd3e9 - Type: Added - [account-requests] [mailer] [locale] [en] Implemented a staged new account request workflow with email validation, admin review, request statuses, and automatic expiry cleanup.
 - 1 - I added `models/user/account_request.go` to store and manage account request states, validation expiry, retry counting, approval or rejection metadata, validation code generation, and expired pending-request cleanup.
 - 2 - I modified `routers/web/auth/auth.go`, added `routers/web/auth/account_request.go`, and updated `templates/user/auth/signup_inner.tmpl` so registration now creates pending account requests, resends validation mail when appropriate, blocks repeated unconfirmed attempts after five tries, and moves validated requests into administrator review instead of activating them immediately.
 - 3 - I modified `routers/web/admin/users.go`, added `routers/web/admin/account_request.go`, updated `routers/web/web.go`, and updated `templates/admin/user/edit.tmpl` so administrators can see the account request status for a user and explicitly activate, reject, or unblock requests from the admin user edit page.
 - 4 - I modified `services/mailer/mail_user.go`, added the new account request mail templates, updated `options/locale/locale_en-US.json`, and modified `services/user/user.go` with `services/cron/tasks_extended.go` so the workflow now sends dedicated validation, approval, and rejection emails, preserves rejected or blocked accounts from inactive-user cleanup, and automatically deletes only expired requests that never completed email validation.
 
-11 - [2026-04-16 23:18:45] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Added the missing admin dashboard translation entries for the expired account request cleanup cron task.
+11 - [2026-04-16 23:18:45] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [account-requests] [locale] [en] Added the missing admin dashboard translation entries for the expired account request cleanup cron task.
 - 1 - I modified `options/locale/locale_en-US.json` to add `admin.dashboard.delete_expired_account_requests` so the new cron task can be rendered correctly in the admin dashboard task list.
 - 2 - I added `admin.dashboard.delete_expired_account_requests.started` alongside it so the matching task start message is also available and the cron task follows the same translation pattern as the existing dashboard tasks.
 - 3 - I verified the locale file remains valid JSON after the change.
 
-12 - [2026-04-17 00:05:29] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Hardened the account request validation email flow so manual approval registrations do not silently skip or hide validation mail failures.
+12 - [2026-04-17 00:05:29] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [account-requests] [mailer] [signup] Hardened the account request validation email flow so manual approval registrations do not silently skip or hide validation mail failures.
 - 1 - I modified `routers/web/auth/auth.go` so the `RegisterManualConfirm` path now runs before the generic activation shortcut for normal self-registrations, while still preserving the first-user bootstrap exception.
 - 2 - I modified `services/mailer/mail_user.go` so account request validation, approval, and rejection emails now return explicit errors when their templates cannot be rendered instead of failing silently.
 - 3 - I modified `routers/web/auth/account_request.go` and `routers/web/admin/account_request.go` so resend and unblock flows now surface validation-email rendering failures immediately, while approval and rejection actions log mail errors without rolling back the already completed admin decision.
 - 4 - I verified the updated flow builds cleanly after formatting with compile-only Go tests on the touched packages.
 
-13 - [2026-04-17 00:53:04] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Reworked the first-user bootstrap path so manual confirmation sends the validation email instead of bypassing the new account request flow.
+13 - [2026-04-17 00:53:04] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [account-requests] [mailer] Reworked the first-user bootstrap path so manual confirmation sends the validation email instead of bypassing the new account request flow.
 - 1 - I modified `routers/web/auth/auth.go` so the automatic first-user admin bootstrap now only bypasses email handling when manual confirmation is disabled, while manual-confirm registrations still go through the validation email path.
 - 2 - I modified `routers/web/auth/account_request.go` so when the validated account is the only user in the instance, the system activates it directly and grants admin rights immediately instead of sending it into an impossible admin-review deadlock.
 - 3 - I preserved the normal staged workflow for all non-bootstrap registrations, so other users still go from email validation to pending admin review as before.
 - 4 - I formatted the code and verified the touched packages with compile-only Go tests after the bootstrap flow change.
 
-14 - [2026-04-17 01:14:35] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Added - Added an admin-side validation email send indicator with success or failure icon and attempt timestamp.
+14 - [2026-04-17 01:14:35] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Added - [account-requests] [admin-users] [mailer] [locale] [en] Added an admin-side validation email send indicator with success or failure icon and attempt timestamp.
 - 1 - I modified `models/user/account_request.go` to persist the last validation email attempt status and timestamp for each account request.
 - 2 - I modified `routers/web/auth/auth.go`, `routers/web/auth/account_request.go`, and `routers/web/admin/account_request.go` so initial send, resend, and unblock flows now record whether the validation email send function returned success or error.
 - 3 - I modified `routers/web/admin/account_request.go` and `templates/admin/user/edit.tmpl` so the account request panel in the admin user edit page now shows a `✔` or `❌` together with the last validation email attempt timestamp.
 - 4 - I updated `options/locale/locale_en-US.json`, validated the JSON file, formatted the code, and verified the touched packages with compile-only Go tests.
 
-15 - [2026-04-17 06:26:17] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Extended the validation email attempt indicator so it is visible in the user-facing registration flow as well as in the admin account request panel.
+15 - [2026-04-17 06:26:17] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [account-requests] [mailer] [ui] [signup] Extended the validation email attempt indicator so it is visible in the user-facing registration flow as well as in the admin account request panel.
 - 1 - I modified `routers/web/auth/account_request.go` and `routers/web/auth/auth.go` so the last validation email attempt status and timestamp are loaded into the user-facing signup retry and activation prompt pages.
 - 2 - I modified `templates/user/auth/signup_inner.tmpl` so the `✔` or `❌` indicator and timestamp now appear next to the pending request message and beside the `Resend` button area.
 - 3 - I modified `templates/user/auth/activate_prompt.tmpl` so the same indicator and timestamp now appear after the initial validation email attempt triggered by account creation.
 - 4 - I adjusted `templates/admin/user/edit.tmpl` so the admin panel also shows the indicator when there is mail-attempt data even if the current account request status line is otherwise absent.
 
-16 - [2026-04-17 07:05:39] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Switched the account request validation email to a real synchronous send path and added logging for silent mail queue enqueue failures.
+16 - [2026-04-17 07:05:39] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [account-requests] [mailer] Switched the account request validation email to a real synchronous send path and added logging for silent mail queue enqueue failures.
 - 1 - I modified `services/mailer/mail_user.go` so `SendAccountRequestValidationMail` now uses a synchronous sender path instead of only enqueueing the message asynchronously.
 - 2 - I modified `services/mailer/mailer.go` to add `SendImmediately`, which uses the initialized configured sender directly and returns the real SMTP or sendmail error back to the caller.
 - 3 - I modified `services/mailer/mailer.go` so `SendAsync` now logs queue initialization and enqueue failures instead of silently discarding them.
 - 4 - This makes the new-user validation mail behave much closer to `SendTestMail`, which was already using direct sending and was one likely reason test emails succeeded while queued validation emails still appeared to disappear.
 
-17 - [2026-04-17 08:20:46] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Switched the remaining user-facing activation emails to synchronous delivery and stopped showing success when the actual send fails.
+17 - [2026-04-17 08:20:46] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [auth] [mailer] Switched the remaining user-facing activation emails to synchronous delivery and stopped showing success when the actual send fails.
 - 1 - I modified `services/mailer/mail_user.go` so `SendActivateAccountMail` and `SendActivateEmailMail` now return real errors and use direct synchronous sending instead of only queueing the message.
 - 2 - I modified `services/mailer/mail_user.go` so account request approval and rejection emails sent to the user now use the same synchronous delivery path for consistent behavior.
 - 3 - I modified `routers/web/auth/auth.go` and `routers/web/user/setting/account.go` so signup and email-confirmation flows stop reporting success when the mail send to the user fails.
 - 4 - I modified `routers/web/admin/users.go` so administrator-triggered account activation now logs and warns when the activation email to the user could not be sent.
 
-18 - [2026-04-17 18:54:53] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Refined the account request resend UX so pending users can retry from both activation and signup pages without losing their entered registration data.
+18 - [2026-04-17 18:54:53] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [auth] [account-requests] [signup] [locale] [en] Refined the account request resend UX so pending users can retry from both activation and signup pages without losing their entered registration data.
 - 1 - I modified `templates/user/auth/activate_prompt.tmpl` so the activation page now shows a separate `Did not receive the email?` prompt, a standalone `Resend` button under the mail status indicator, and a Spam/Junk reminder.
 - 2 - I modified `templates/user/auth/signup_inner.tmpl` so the pending-registration panel now uses plain prompt text plus a dedicated `Resend` button instead of the combined button label, while also preserving the signup form values through the resend action.
 - 3 - I modified `models/user/account_request.go` and `routers/web/auth/account_request.go` so account request validation emails now track up to five resend actions and automatically hide the resend button after that limit is reached.
 - 4 - I modified `routers/web/auth/auth.go` and `options/locale/locale_en-US.json` so the activation prompt receives the same resend controls immediately after registration and the new texts are available consistently across both user-facing flows.
 
-19 - [2026-04-17 22:10:39] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Prevented invalid signup email input from triggering an internal server error in the account request pre-check flow.
+19 - [2026-04-17 22:10:39] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [auth] [account-requests] [mailer] [signup] Prevented invalid signup email input from triggering an internal server error in the account request pre-check flow.
 - 1 - I modified `models/user/account_request.go` so `GetUserByAnyEmail` now trims and validates the email address before querying, reusing the normal email validation behavior instead of treating malformed input like a server-side lookup problem.
 - 2 - I modified `routers/web/auth/account_request.go` so the signup pre-check now treats invalid or unsupported email formats as normal invalid input and lets the standard registration validation flow handle the user-facing error message.
 - 3 - I modified `routers/web/auth/account_request.go` so the resend endpoint also treats malformed email input as unavailable instead of escalating it into a 500 error.
 
-20 - [2026-04-17 23:13:17] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Rolled back newly created self-registration accounts when the initial confirmation email cannot actually be sent.
+20 - [2026-04-17 23:13:17] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [mailer] [signup] [locale] [en] Rolled back newly created self-registration accounts when the initial confirmation email cannot actually be sent.
 - 1 - I modified `routers/web/auth/auth.go` so `createAndHandleCreatedUser` now passes the template and form context into the post-create flow, allowing failed registration emails to return a normal form error instead of a 500 page.
 - 2 - I modified `routers/web/auth/auth.go` so the initial account-request validation mail and the initial standard activation mail both delete the newly created user if sending fails, preventing orphaned accounts from being left in the database.
 - 3 - I added a dedicated `auth.confirmation_mail_failed` user-facing message in `options/locale/locale_en-US.json` so registration now tells the user that the account was not created because the confirmation email could not be sent.
 - 4 - I preserved the existing resend behavior for already created inactive users, so the rollback applies only to the first mail send during new self-registration.
 
-21 - [2026-04-26 22:55:56] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Updated the smart build script for PNPM 10 and the repository frontend build flow.
+21 - [2026-04-26 22:55:56] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [scripts] [smart-build] Updated the smart build script for PNPM 10 and the repository frontend build flow.
 - 1 - I modified `smart-build.sh` to remove the unsupported `--ignore-engines` PNPM option from dependency installation.
 - 2 - I changed the frontend rebuild step to call `make frontend`, matching the Gitea Makefile target instead of calling a missing `pnpm run build` script.
 - 3 - I fixed the architecture menu echo line so `Initialization checks` is no longer appended as stray shell text.
 
-22 - [2026-04-26 23:01:28] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Made the smart build script find the local Go toolchain before running backend builds.
+22 - [2026-04-26 23:01:28] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [scripts] [smart-build] Made the smart build script find the local Go toolchain before running backend builds.
 - 1 - I modified `smart-build.sh` to prepend `/usr/local/go/bin` to `PATH` when the local Go binary exists.
 - 2 - I added an early Go availability check so the script stops with a clear message before invoking `make build` if Go is not installed or visible.
 - 3 - I added explicit failure handling for dependency installation and frontend asset builds so the script does not continue after a failed prerequisite step.
 
-23 - [2026-04-26 23:20:08] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Added a smart build menu option for SQLite-enabled bindata builds.
+23 - [2026-04-26 23:20:08] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [scripts] [smart-build] [bindata] Added a smart build menu option for SQLite-enabled bindata builds.
 - 1 - I modified `smart-build.sh` to add a build-tag selection menu with the existing `bindata` build and a new `bindata sqlite sqlite_unlock_notify` option.
 - 2 - I changed the backend build command to use the selected tag set instead of always passing `TAGS="bindata"`.
 - 3 - I made SQLite builds enable CGO and write artifacts with a `-sqlite` suffix so they are distinguishable from default bindata builds.
 
-24 - [2026-04-27 00:18:15] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Made account request validation links robust after account data changes.
+24 - [2026-04-27 00:18:15] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [account-requests] [auth] Made account request validation links robust after account data changes.
 - 1 - I modified `models/user/account_request.go` so account request validation codes can be stored as hashes and later accepted as a fallback when the stateless code can no longer be recalculated from current user data.
 - 2 - I modified the registration, resend, and admin unblock flows to generate one validation code, send that exact code by email, and store its hash only after the email send succeeds.
 - 3 - I cleared stored validation-code hashes when account requests are reset, validated, or approved so old validation links cannot keep working after the request leaves email validation.
 - 4 - I added focused tests for account request code verification and `/user/activate` handling, including the case where user data changes after the validation email is sent.
 
-25 - [2026-04-27 00:49:34] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Corrected pending account request detection for validation links and repeated registration attempts.
+25 - [2026-04-27 00:49:34] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [account-requests] [signup] [auth] Corrected pending account request detection for validation links and repeated registration attempts.
 - 1 - I modified account request status detection so inactive users with validation markers are treated as pending email validation even if `account_request.status` is missing.
 - 2 - I added a dedicated account-request time-limit code purpose while keeping compatibility with older account-request links, preventing normal activation links from being intercepted by the account request path.
 - 3 - I moved the pending account request pre-check before generic signup form errors so repeated registration attempts show the pending-request message and resend option instead of `The username is already taken`.
 - 4 - I updated the pending signup message to include the email address that received the validation email and added focused tests for missing-status validation, classic activation separation, and repeated registration.
 
-26 - [2026-04-27 01:10:03] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Restored the admin account request review flow link to the page with approval controls.
+26 - [2026-04-27 01:10:03] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [account-requests] Restored the admin account request review flow link to the page with approval controls.
 - 1 - I modified `services/mailer/mail_user.go` so new account request notification emails now link directly to `/-/admin/users/{id}/edit`, where the `Activate Request` and `Reject` controls are rendered.
 - 2 - I added a focused mailer test to ensure future account request notifications keep pointing to the admin edit page instead of the read-only user view page.
 
-27 - [2026-04-27 01:47:34] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Hid admin-side account deletion controls for the last active administrator.
+27 - [2026-04-27 01:47:34] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [admin-users] [account-deletion] Hid admin-side account deletion controls for the last active administrator.
 - 1 - I modified `routers/web/admin/users.go` so the admin user edit page receives `IsLastAdminUser` for the edited user.
 - 2 - I modified `templates/admin/user/edit.tmpl` so `Delete User Account` is replaced by the existing last-admin warning when the edited user is the only active admin.
 - 3 - I hid the admin delete confirmation modal for the last-admin case while preserving the backend `DeleteUser` last-admin guard as the final protection.
 
-28 - [2026-04-27 02:06:06] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Kept last-admin account deletion actions visible but disabled.
+28 - [2026-04-27 02:06:06] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [admin-users] [account-deletion] Kept last-admin account deletion actions visible but disabled.
 - 1 - I modified `templates/admin/user/edit.tmpl` so `Delete User Account` remains visible as a disabled button for the last active admin while showing the existing last-admin warning.
 - 2 - I modified `templates/user/settings/account.tmpl` so the self-delete confirmation button remains visible as disabled for the last active admin while showing the same warning.
 - 3 - I kept delete confirmation modals unavailable for the disabled last-admin actions so blocked actions cannot be submitted from the UI.
 
-29 - [2026-04-27 09:12:11] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Adjusted last-admin delete warning placement and spacing.
+29 - [2026-04-27 09:12:11] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [admin-users] Adjusted last-admin delete warning placement and spacing.
 - 1 - I modified `templates/admin/user/edit.tmpl` so the last-admin warning appears above the disabled `Delete User Account` button with vertical spacing.
 - 2 - I modified `templates/user/settings/account.tmpl` so the disabled self-delete confirmation button has spacing below the warning message.
 
-30 - [2026-04-27 09:28:16] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Restored admin edit action button alignment while keeping the last-admin warning above them.
+30 - [2026-04-27 09:28:16] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [admin-users] [ui] Restored admin edit action button alignment while keeping the last-admin warning above them.
 - 1 - I modified `templates/admin/user/edit.tmpl` so the last-admin warning appears above the action button row.
 - 2 - I kept `Update Profile` and the disabled `Delete User Account` button in the same button row and original order.
 
-31 - [2026-04-27 10:07:15] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Adjusted account request resend button sizing and delivery-state feedback.
+31 - [2026-04-27 10:07:15] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [account-requests] Adjusted account request resend button sizing and delivery-state feedback.
 - 1 - I modified the pending signup and activation prompt templates so the resend button is smaller, blue by default, and spaced away from the spam-folder hint.
 - 2 - I added resend result state rendering so successful sends turn the button green for five seconds and failed sends keep it red.
 - 3 - I changed the resend handler to re-render the current account-request page with a failed send message instead of showing a server-error page when email delivery fails.
 
-32 - [2026-04-27 14:41:33] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Added - Added a build environment configuration script.
+32 - [2026-04-27 14:41:33] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Added - [scripts] [build-env] Added a build environment configuration script.
 - 1 - I added `configure.sh` to install and verify the system packages, Go version, Node version, pnpm version, and frontend dependencies required by this Gitea tree.
 - 2 - I made the script read the required Go, Node, and pnpm versions from `go.mod` and `package.json`, while still allowing environment overrides.
 - 3 - I added an optional `--with-cross-cgo` mode that installs/configures the heavier cross-CGO toolchains needed for SQLite builds targeting linux/armv7 and windows/amd64.
 
-33 - [2026-04-27 14:51:16] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Added an interactive run menu to the build environment configuration script.
+33 - [2026-04-27 14:51:16] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [scripts] [build-env] Added an interactive run menu to the build environment configuration script.
 - 1 - I modified `configure.sh` so running it without arguments in an interactive terminal shows a description of what the script installs and verifies.
 - 2 - I added a run menu with Normal, With cross cgo, Verify only, and Quit options.
 - 3 - I added a `--menu` flag so the same interactive menu can be requested explicitly while keeping the existing command-line options for automated runs.
 
-34 - [2026-04-27 14:59:01] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Made interactive environment verification report missing requirements without failing the menu run.
+34 - [2026-04-27 14:59:01] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [scripts] [build-env] Made interactive environment verification report missing requirements without failing the menu run.
 - 1 - I modified `configure.sh` so the interactive `Verify only` menu option lists all detected missing commands and configuration issues instead of stopping at the first missing requirement.
 - 2 - I kept the direct `./configure.sh --verify-only` mode strict for automated checks, returning a failure when requirements are missing.
 - 3 - I adjusted the final interactive verification message so it recommends rerunning the menu with Normal or With cross cgo instead of suggesting a build when requirements are still missing.
 
-35 - [2026-04-27 15:20:01] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Translated the build environment configuration script text to English.
+35 - [2026-04-27 15:20:01] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [scripts] [build-env] Translated the build environment configuration script text to English.
 - 1 - I modified `configure.sh` so the interactive description is written in English.
 - 2 - I translated the interactive menu option descriptions to English while keeping the existing script behavior unchanged.
 
-36 - [2026-04-27 19:28:55] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Moved test email feedback inline and aligned mail action button states.
+36 - [2026-04-27 19:28:55] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [mailer] [mailer-ui] Moved test email feedback inline and aligned mail action button states.
 - 1 - I modified `routers/web/admin/config.go` so the test email result redirects back to the config page with local test-mail state instead of using the global flash alert.
 - 2 - I modified `templates/admin/config.tmpl` so the test email result appears beside the `Send` button, with the button using primary, green, or red state colors.
 - 3 - I changed the account request `Resend` button default state from `blue` to `primary` so it uses the same visible blue styling as the rest of the Gitea UI.
 
-37 - [2026-04-27 19:56:31] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Forced mail action button colors and refreshed local template bindata.
+37 - [2026-04-27 19:56:31] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [mailer] [mailer-ui] [scripts] [bindata] Forced mail action button colors and refreshed local template bindata.
 - 1 - I modified the admin test mail and account request resend templates so their default, success, and failure colors are set directly with Gitea theme variables.
 - 2 - I updated the success timeout scripts to restore the direct primary-color styling after five seconds.
 - 3 - I regenerated the local ignored `modules/templates/bindata.dat` file so local bindata builds can include the updated templates.
 
-38 - [2026-04-27 20:05:18] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Added bindata freshness checks to the smart build script.
+38 - [2026-04-27 20:05:18] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [scripts] [smart-build] [bindata] Added bindata freshness checks to the smart build script.
 - 1 - I modified `smart-build.sh` so bindata builds check the generated templates, options, public, and migration schema bindata files before compilation.
 - 2 - I made the script regenerate any missing or stale bindata file with `go generate -tags bindata` before running `make build`.
 - 3 - I kept the regeneration step neutral from cross-build environment variables by clearing `GOOS`, `GOARCH`, `CGO_ENABLED`, and `CC` for the go generate command.
 
-39 - [2026-04-27 20:35:07] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Preserved scroll position after sending a test email from the admin config page.
+39 - [2026-04-27 20:35:07] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [mailer] [mailer-ui] [admin-config] [ui] [sticky-layout] Preserved scroll position after sending a test email from the admin config page.
 - 1 - I modified `templates/admin/config.tmpl` so the test email form records the current scroll position before submit.
 - 2 - I modified `routers/web/admin/config.go` so the test email redirect carries the saved scroll position and returns to the local test-email anchor.
 - 3 - I regenerated the local ignored `modules/templates/bindata.dat` file so bindata builds can include the scroll-preserving template update.
 
-40 - [2026-04-27 21:03:25] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Removed page reload and scroll movement from the admin test email action.
+40 - [2026-04-27 21:03:25] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [mailer] [mailer-ui] [admin-config] [ui] Removed page reload and scroll movement from the admin test email action.
 - 1 - I modified `templates/admin/config.tmpl` so the `Send Testing Email` form submits through `fetch` and updates the inline message without changing the page URL or scroll position.
 - 2 - I modified `routers/web/admin/config.go` so inline test email requests return JSON state and message data instead of redirecting.
 - 3 - I regenerated the local ignored `modules/templates/bindata.dat` file so bindata builds can include the no-jump test email behavior.
 
-41 - [2026-04-27 21:14:20] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Shortened admin test email delivery error messages.
+41 - [2026-04-27 21:14:20] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [mailer] [mailer-ui] [admin-config] Shortened admin test email delivery error messages.
 - 1 - I modified `routers/web/admin/config.go` so `Send Testing Email` displays a concise SMTP failure reason instead of the full command chain.
 - 2 - I added normalization for common mail errors such as user unknown, mailbox unavailable, relay access denied, and authentication failure.
 - 3 - I added a focused unit test for the short test mail error formatter.
 
-42 - [2026-04-27 21:47:26] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Added - Added an admin user-list delete account action.
+42 - [2026-04-27 21:47:26] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Added - [admin-users] [account-deletion] Added an admin user-list delete account action.
 - 1 - I modified `templates/admin/user/list.tmpl` so each user row now shows a red trash icon beside the existing User Details and Edit actions.
 - 2 - I added a shared delete-account confirmation modal on the user management list, including the existing purge option and delete-account warning text.
 - 3 - I regenerated the local ignored `modules/templates/bindata.dat` file so bindata builds can include the new list action.
 
-43 - [2026-04-27 22:17:13] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - Matched the admin user-list delete action to the edit-page delete state.
+43 - [2026-04-27 22:17:13] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Modified - [admin-users] Matched the admin user-list delete action to the edit-page delete state.
 - 1 - I modified `routers/web/explore/user.go` so user search pages can receive optional per-user extra data before rendering.
 - 2 - I modified `routers/web/admin/users.go` so the admin user list marks rows where the user is the last active administrator using the same condition as the edit page.
 - 3 - I modified `templates/admin/user/list.tmpl` so the trash icon is disabled with the existing last-admin warning tooltip whenever the edit-page `Delete User Account` button would be disabled.
 
-44 - [2026-04-28 09:12:49] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - Blocked inactive account-request users from getting a signed-in session.
+44 - [2026-04-28 09:12:49] - v.1.27.0-dev-43-gb2b024d0b6 - Type: Fixed - [auth] [account-requests] Blocked inactive account-request users from getting a signed-in session.
 - 1 - I modified the password sign-in flow so inactive account-request users are stopped before session, 2FA, or remember-cookie creation and are shown the activation prompt instead.
 - 2 - I added account-request login prompts for pending email validation, pending admin review, rejected, and blocked states, while keeping the resend button available only for pending email validation.
 - 3 - I modified existing inactive signed sessions on web pages to be signed out before rendering the activation/account-request prompt so the account menu and Sign Out action are not shown.
 - 4 - I added targeted auth tests for pending email validation and pending admin review login attempts, including username and email login for the validation case.
 - 5 - I regenerated the local ignored `modules/options/bindata.dat` file so bindata builds can include the new login prompt locale string.
 
-45 - [2026-04-28 16:01:28] - v1.27.0-dev-47-gf21b6b7a3b - Type: Modified - Added password confirmation to account recovery.
+45 - [2026-04-28 16:01:28] - v1.27.0-dev-47-gf21b6b7a3b - Type: Modified - [auth] [recovery] Added password confirmation to account recovery.
 - 1 - I modified `templates/user/auth/reset_passwd.tmpl` so the account recovery reset form includes a required `Confirm Password` field.
 - 2 - I modified `routers/web/auth/password.go` so reset submissions reject mismatched passwords before two-factor checks or password updates.
 - 3 - I added a focused auth test for mismatched recovery password confirmation and regenerated the local ignored `modules/templates/bindata.dat` file for bindata builds.
 
-46 - [2026-04-28 19:05:06] - v1.27.0-dev-48-g25a1d84c2e - Type: Fixed - Used the reset-password lifetime for account recovery codes.
+46 - [2026-04-28 19:05:06] - v1.27.0-dev-48-g25a1d84c2e - Type: Fixed - [auth] [recovery] Used the reset-password lifetime for account recovery codes.
 - 1 - I modified `models/user/user.go` so reset-password time-limit codes are generated and verified with `RESET_PASSWD_CODE_LIVE_MINUTES` instead of `ACTIVE_CODE_LIVE_MINUTES`.
 - 2 - I kept activation, email activation, and account-request time-limit codes on the existing active-code lifetime.
 - 3 - I added a focused user-model test that proves reset-password codes remain valid when only `RESET_PASSWD_CODE_LIVE_MINUTES` allows them.
 
-47 - [2026-04-28 20:31:34] - v1.27.0-dev-48-g25a1d84c2e - Type: Added - Added admin-created account invitation flow when registration is disabled.
+47 - [2026-04-28 20:31:34] - v1.27.0-dev-48-g25a1d84c2e - Type: Added - [admin-invite] [admin-created-user] [signup] Added admin-created account invitation flow when registration is disabled.
 - 1 - I modified admin user creation so `DISABLE_REGISTRATION = true` creates inactive, sign-in-prohibited accounts and checks `Send User Registration Notification` by default when mail is configured.
 - 2 - I added a 24-hour admin invitation token and email template that lets the invited user accept the account, activate the email, and clear `Disable Sign-In`.
 - 3 - I added targeted tests for invitation token lifetime, invitation acceptance, and disabled-registration admin account creation defaults, then regenerated local ignored template and options bindata.
 
-48 - [2026-04-28 21:56:08] - v1.27.0-dev-48-g25a1d84c2e - Type: Modified - Added smart-build load profile options.
+48 - [2026-04-28 21:56:08] - v1.27.0-dev-48-g25a1d84c2e - Type: Modified - [scripts] [smart-build] Added smart-build load profile options.
 - 1 - I modified `smart-build.sh` so it asks for a build load profile before dependency checks, frontend build, bindata generation, and Go compilation.
 - 2 - I added Moderate and Low Resource profiles that set `GOMAXPROCS`, `MAKEFLAGS=-j1`, and a conservative Node memory limit to reduce CPU and RAM pressure.
 - 3 - I kept the Normal profile available for the existing unrestricted build behavior.
 
-49 - [2026-04-28 23:00:25] - v1.27.0-dev-49-g20405fe5e7 - Type: Added - Notified inviting admins when admin-created invitations are accepted.
+49 - [2026-04-28 23:00:25] - v1.27.0-dev-49-g20405fe5e7 - Type: Added - [admin-invite] Notified inviting admins when admin-created invitations are accepted.
 - 1 - I stored the creator admin ID on disabled-registration admin-created invitation accounts so the invitation acceptance flow knows who to notify.
 - 2 - I added an invitation-accepted email template and mailer function that sends the accepting user's details back to the admin who created the account.
 - 3 - I updated targeted admin/auth tests and regenerated local ignored template and options bindata for the new email template and locale strings.
 
-50 - [2026-04-28 23:52:04] - v1.27.0-dev-50-g8147f7a798 - Type: Modified - Added creator-admin badges to the admin users list.
+50 - [2026-04-28 23:52:04] - v1.27.0-dev-50-g8147f7a798 - Type: Modified - [admin-created-user] [admin-users] [badges] Added creator-admin badges to the admin users list.
 - 1 - I modified the admin user list data loader so users created through the disabled-registration invitation flow include the admin creator name.
 - 2 - I modified `templates/admin/user/list.tmpl` so the Created column shows a `by <admin>` mini badge next to the creation date when creator data exists.
 - 3 - I added a focused admin list test for the creator-admin mapping and regenerated local ignored template bindata.
 
-51 - [2026-04-29 01:55:04] - v1.27.0-dev-51-gcfd7cfa1dc - Type: Fixed - Kept creator-admin badges permanently attached to invited accounts.
+51 - [2026-04-29 01:55:04] - v1.27.0-dev-51-gcfd7cfa1dc - Type: Fixed - [admin-invite] [admin-created-user] [badges] Kept creator-admin badges permanently attached to invited accounts.
 - 1 - I modified the admin invitation acceptance notification flow so it no longer deletes the stored creator-admin ID.
 - 2 - I updated the invitation acceptance test to assert the creator-admin marker remains after the user accepts the invitation.
 
-52 - [2026-04-29 02:04:41] - v1.27.0-dev-52-gcd96c721e0 - Type: Modified - Added persistent admin email tooltip to creator badges.
+52 - [2026-04-29 02:04:41] - v1.27.0-dev-52-gcd96c721e0 - Type: Modified - [admin-created-user] [badges] [mailer] Added persistent admin email tooltip to creator badges.
 - 1 - I modified admin-created invitation account storage so it permanently saves the creator admin ID, username, and email address.
 - 2 - I modified the admin users list creator badge so it shows `by <admin>` and exposes the stored admin email as a hover tooltip.
 - 3 - I updated the focused admin list tests to prove the badge data still renders from stored name/email even without looking up the admin account, then regenerated local ignored template bindata.
 
-53 - [2026-04-29 02:30:55] - v1.27.0-dev-52-gcd96c721e0 - Type: Modified - Added admin activation badges and first-admin GOOD badge.
+53 - [2026-04-29 02:30:55] - v1.27.0-dev-52-gcd96c721e0 - Type: Modified - [auth] [admin-created-user] [badges] Added admin activation badges and first-admin GOOD badge.
 - 1 - I modified the admin users list so the Activated column can show a `by <admin>` badge with the stored admin email as a hover tooltip.
 - 2 - I stored admin activation ID, username, and email address when account requests are approved or inactive users are manually activated by an admin.
 - 3 - I added the special `by GOOD` Created-column badge for the first admin account, updated focused admin list tests, and regenerated local ignored template bindata.
 
-54 - [2026-04-29 08:25:36] - v1.27.0-dev-53-ga3e09bb819 - Type: Fixed - Prevented empty `by` badges in the admin users list.
+54 - [2026-04-29 08:25:36] - v1.27.0-dev-53-ga3e09bb819 - Type: Fixed - [admin-users] [badges] Prevented empty `by` badges in the admin users list.
 - 1 - I changed the admin users list badge maps to use pointer values so missing entries render as empty instead of truthy zero-value structs.
 - 2 - I guarded the Created and Activated badge rendering so badges only appear when a display name exists.
 - 3 - I reran the focused admin badge tests and regenerated local ignored template bindata.
 
-55 - [2026-04-29 09:02:42] - v1.27.0-dev-53-ga3e09bb819 - Type: Modified - Moved account request review controls to the top of the admin user edit panel.
+55 - [2026-04-29 09:02:42] - v1.27.0-dev-53-ga3e09bb819 - Type: Modified - [account-requests] [admin-users] [ui] Moved account request review controls to the top of the admin user edit panel.
 - 1 - I moved the account request status message to the top of the admin user edit segment, immediately under the panel header.
 - 2 - I moved the Activate/Reject/Unblock request controls above the profile edit form so admins can review pending accounts without scrolling down.
 - 3 - I regenerated local ignored template bindata for the updated admin user edit template.
 
-56 - [2026-04-29 09:32:09] - v1.27.0-dev-54-gc7c7af77a1 - Type: Modified - Defaulted admin user purge checkboxes to enabled.
+56 - [2026-04-29 09:32:09] - v1.27.0-dev-54-gc7c7af77a1 - Type: Modified - [admin-users] Defaulted admin user purge checkboxes to enabled.
 - 1 - I set the Purge User checkbox to checked by default in the admin user edit delete modal.
 - 2 - I set the Purge User checkbox to checked by default in the admin users list delete modal.
 - 3 - I regenerated local ignored template bindata for the updated admin templates.
 
-57 - [2026-04-29 09:53:08] - v1.27.0-dev-55-ga8d9e5e659 - Type: Added - Added Disable Sign-In metadata to the admin users list.
+57 - [2026-04-29 09:53:08] - v1.27.0-dev-55-ga8d9e5e659 - Type: Added - [auth] [admin-users] [account-status] Added Disable Sign-In metadata to the admin users list.
 - 1 - I added persistent admin metadata for Disable Sign-In actions, including timestamp, admin ID, admin name, and admin email.
 - 2 - I added a Disable Sign-In column to the admin users list that displays the block date and `by <admin>` badge with email tooltip.
 - 3 - I stored the same metadata when admin-created invitation accounts start disabled, when an admin disables sign-in from the edit form, and when an account request is rejected.
 
-58 - [2026-04-29 10:09:41] - v1.27.0-dev-55-ga8d9e5e659 - Type: Modified - Added inactive marker to the Disable Sign-In admin users column.
+58 - [2026-04-29 10:09:41] - v1.27.0-dev-55-ga8d9e5e659 - Type: Modified - [auth] [admin-users] [account-status] Added inactive marker to the Disable Sign-In admin users column.
 - 1 - I changed the Disable Sign-In column so users without sign-in disabled show the same `octicon-x` marker style as the other status columns.
 - 2 - I kept the block date and `by <admin>` badge for users that do have Disable Sign-In metadata.
 - 3 - I regenerated local ignored template bindata for the updated admin users list template.
 
-59 - [2026-04-29 14:49:39] - v1.27.0-dev-56-g1dcd81b420 - Type: Added - Added admin status-change reasons and user email notifications.
+59 - [2026-04-29 14:49:39] - v1.27.0-dev-56-g1dcd81b420 - Type: Added - [admin-users] [account-status] [mailer] Added admin status-change reasons and user email notifications.
 - 1 - I added reason fields under the admin edit checkboxes for account activation, Disable Sign-In, and restricted status.
 - 2 - I require a reason when an admin newly deactivates an account, enables Disable Sign-In, or enables restricted mode, then email the user with the action, admin name, and reason.
 - 3 - I added the status-change email template, locale strings, regenerated local ignored template/options bindata, and reran the focused admin tests.
 
-60 - [2026-04-29 19:01:39] - v1.27.0-dev-57-g210955465e - Type: Fixed - Corrected admin status reason behavior and reactivation emails.
+60 - [2026-04-29 19:01:39] - v1.27.0-dev-57-g210955465e - Type: Fixed - [auth] [account-status] [mailer] Corrected admin status reason behavior and reactivation emails.
 - 1 - I changed the admin edit form so reason fields belong to the existing checkboxes and only appear for the restrictive state of each checkbox.
 - 2 - I persisted the deactivation, Disable Sign-In, and restricted reasons in user settings so later administrators can see the saved reason.
 - 3 - I changed status-change emails to describe the actual account effect, added notifications when restrictions are lifted, and stopped sending the old activation email on admin reactivation.
 
-61 - [2026-04-29 19:56:22] - v1.27.0-dev-59-gb3204f3db6 - Type: Added - Added restricted-admin badges and reason actor badges.
+61 - [2026-04-29 19:56:22] - v1.27.0-dev-59-gb3204f3db6 - Type: Added - [admin-users] [badges] Added restricted-admin badges and reason actor badges.
 - 1 - I added persistent admin metadata for Restricted actions, including timestamp, admin ID, admin name, and admin email.
 - 2 - I changed the admin users list Restricted column so newly restricted users show the restriction date and `by <admin>` badge with email tooltip.
 - 3 - I added `by <admin>` badges next to the saved Reason labels in the admin user edit panel for deactivation, Disable Sign-In, and Restricted reasons.
 
-62 - [2026-04-29 21:00:30] - v1.27.0-dev-60-g396b15372d - Type: Added - Added Is Administrator reason and admin-grant badges.
+62 - [2026-04-29 21:00:30] - v1.27.0-dev-60-g396b15372d - Type: Added - [admin-users] [badges] Added Is Administrator reason and admin-grant badges.
 - 1 - I added persistent metadata for granting administrator privileges, including timestamp, admin ID, admin name, admin email, and reason.
 - 2 - I changed the admin users list so administrator accounts with grant metadata show an `Admin by <admin>` badge with email tooltip.
 - 3 - I added the Is Administrator reason field, reason actor badge, grant/revoke email notifications, regenerated local ignored bindata, and added focused admin grant tests.
 
-63 - [2026-04-29 21:30:55] - v1.27.0-dev-60-g396b15372d - Type: Fixed - Made Is Administrator reasons apply only when admin rights are revoked.
+63 - [2026-04-29 21:30:55] - v1.27.0-dev-60-g396b15372d - Type: Fixed - [admin-users] Made Is Administrator reasons apply only when admin rights are revoked.
 - 1 - I changed the Is Administrator reason field so it appears only when the checkbox is unchecked.
 - 2 - I stopped requiring or sending a reason when administrator privileges are granted and changed that email to a congratulatory promotion message.
 - 3 - I kept the reason on administrator privilege removal, regenerated template/options bindata, and reran the focused admin grant tests.
 
-64 - [2026-04-29 22:03:18] - v1.27.0-dev-61-g067a09c2ac - Type: Fixed - Disabled critical self-edit account state checkboxes.
+64 - [2026-04-29 22:03:18] - v1.27.0-dev-61-g067a09c2ac - Type: Fixed - [admin-users] Disabled critical self-edit account state checkboxes.
 - 1 - I disabled User Account Is Activated and Is Restricted when an administrator edits their own account, matching the existing self-edit protection for Disable Sign-In.
 - 2 - I hardened the admin user update handler so manually submitted self-edit forms cannot change the current admin's active, restricted, or prohibit-login state.
 - 3 - I regenerated local ignored template bindata and verified the admin package compilation with reduced build pressure.
 
-65 - [2026-04-29 22:37:56] - v1.27.0-dev-62-g3afb4e8afa - Type: Added - Added Codex ChatGPT login helper script.
+65 - [2026-04-29 22:37:56] - v1.27.0-dev-62-g3afb4e8afa - Type: Added - [auth] [scripts] Added Codex ChatGPT login helper script.
 - 1 - I added `.codex_gpt_login`, an interactive helper for completing the local Codex ChatGPT auth callback in code-server environments.
 - 2 - The script accepts either a raw received code or a full URL/query containing `code=...`, calls the local callback endpoint, extracts `id_token`, and completes the `/success` request.
 - 3 - I made the script executable and verified its shell syntax with `bash -n`.
 
-66 - [2026-04-29 22:55:08] - v1.27.0-dev-62-g3afb4e8afa - Type: Modified - Added admin actor badge beside the Is Administrator option.
+66 - [2026-04-29 22:55:08] - v1.27.0-dev-62-g3afb4e8afa - Type: Modified - [admin-users] [badges] Added admin actor badge beside the Is Administrator option.
 - 1 - I updated the admin user edit panel so the Is Administrator checkbox label shows `by <admin>` when administrator grant metadata exists.
 - 2 - I reused the stored admin email as the badge hover tooltip and regenerated local ignored template bindata.
 
-67 - [2026-04-30 00:30:40] - v1.27.0-dev-63-g4aacf3bd20 - Type: Fixed - Hid Is Administrator reason unless admin rights were revoked.
+67 - [2026-04-30 00:30:40] - v1.27.0-dev-63-g4aacf3bd20 - Type: Fixed - [admin-users] Hid Is Administrator reason unless admin rights were revoked.
 - 1 - I changed the Is Administrator reason field so normal non-admin users do not see it just because the checkbox is unchecked.
 - 2 - The reason field now appears only when a saved admin-revocation reason exists or when an existing administrator is being unchecked during the current edit.
 - 3 - I regenerated local ignored template bindata and verified whitespace with `git diff --check`.
 
-68 - [2026-04-30 01:44:17] - v1.27.0-dev-64-gcff1b46f50 - Type: Added - Added persistent super administrator protection.
+68 - [2026-04-30 01:44:17] - v1.27.0-dev-64-gcff1b46f50 - Type: Added - [admin-users] [super-admin] Added persistent super administrator protection.
 - 1 - I added `SUPER_ADMIN_ENABLED` and `ADMIN_MANAGEMENT_POLICY` configuration options for administrator permission management.
 - 2 - I stored the super administrator role and grant/revoke metadata in persistent user settings, with automatic `by GOOD` bootstrap for the first active admin.
 - 3 - I protected administrator and super administrator changes so regular admins cannot alter existing admins unless the selected policy allows a regular-user promotion.
 - 4 - I added super administrator badges, reason tracking, and status-change emails, then regenerated template and options bindata.
 
-69 - [2026-04-30 02:20:26] - v1.27.0-dev-64-gcff1b46f50 - Type: Fixed - Enabled super administrator bootstrap by default.
+69 - [2026-04-30 02:20:26] - v1.27.0-dev-64-gcff1b46f50 - Type: Fixed - [admin-users] [super-admin] Enabled super administrator bootstrap by default.
 - 1 - I changed `SUPER_ADMIN_ENABLED` to default to `true` so existing installations without the new app.ini key bootstrap the first active administrator automatically.
 - 2 - I updated the app.ini example to document the enabled default and kept `SUPER_ADMIN_ENABLED = false` available as the explicit opt-out.
 - 3 - I made the super administrator list badge fall back to `by GOOD` for the bootstrapped first administrator and regenerated options bindata.
 
-70 - [2026-04-30 04:08:23] - v1.27.0-dev-66-g35b9fa65d3 - Type: Fixed - Blocked regular administrators from editing super administrator accounts.
+70 - [2026-04-30 04:08:23] - v1.27.0-dev-66-g35b9fa65d3 - Type: Fixed - [admin-users] [super-admin] Blocked regular administrators from editing super administrator accounts.
 - 1 - I modified `routers/web/admin/users.go` so non-super-admins are redirected away from super-admin edit actions, including profile edits and avatar changes.
 - 2 - I modified `routers/api/v1/admin/user.go` so the admin user edit API now returns forbidden when a regular admin targets a super admin.
 - 3 - I modified `templates/admin/user/list.tmpl` and `templates/admin/user/view.tmpl` so edit actions are hidden for super-admin accounts when the acting admin is not also a super admin.
 - 4 - I added `TestAdminCannotEditSuperAdminUser` in `tests/integration/admin_user_test.go` to cover the denied web-edit flow.
 
-71 - [2026-04-30 04:19:14] - v1.27.0-dev-67-g0fc6f30a30 - Type: Modified - Kept super administrator Edit and Delete controls visible but disabled for regular admins.
+71 - [2026-04-30 04:19:14] - v1.27.0-dev-67-g0fc6f30a30 - Type: Modified - [admin-users] [super-admin] Kept super administrator Edit and Delete controls visible but disabled for regular admins.
 - 1 - I modified `templates/admin/user/list.tmpl` so super-admin rows still show the `Edit` and `Delete` icons for regular admins, but as disabled muted controls with the super-admin-required tooltip.
 - 2 - I modified `templates/admin/user/view.tmpl` so the `Edit` button remains visible on the super-admin user details page for regular admins, but in a disabled state.
 
-72 - [2026-04-30 04:58:16] - v1.27.0-dev-68-g5da24d2c7b - Type: Modified - Protected GOOD-granted admin accounts and blocked deleting the direct grantor.
+72 - [2026-04-30 04:58:16] - v1.27.0-dev-68-g5da24d2c7b - Type: Modified - [admin-users] [admin-policy] Protected GOOD-granted admin accounts and blocked deleting the direct grantor.
 - 1 - I added `models/user/admin_grant.go` with helpers to read admin and super-admin grantor metadata, detect `by GOOD` bootstrap grants, and check whether a target user is the direct grantor of another admin.
 - 2 - I modified `routers/web/admin/users.go` so GOOD-granted accounts cannot be edited or deleted through admin actions, and regular admins may delete other admin accounts except their direct grantor and protected super-admin cases.
 - 3 - I modified `routers/api/v1/admin/user.go` so the admin API now enforces the same GOOD-protection and direct-grantor deletion rule.
 - 4 - I added locale messages for the new admin restrictions and added focused integration coverage for deleting another admin versus the direct grantor, plus GOOD-protected admin API edits.
 
-73 - [2026-04-30 16:51:42] - v1.27.0-dev-71-g80497e4194 - Type: Modified - Restored normal self-edit access for super admins and disabled only the admin actions that are truly forbidden.
+73 - [2026-04-30 16:51:42] - v1.27.0-dev-71-g80497e4194 - Type: Modified - [admin-users] Restored normal self-edit access for super admins and disabled only the admin actions that are truly forbidden.
 - 1 - I modified `routers/web/admin/users.go` so a GOOD-granted or super-admin user can still edit their own ordinary account fields, while forbidden cross-user edits remain blocked and table action states are computed per target user.
 - 2 - I modified `routers/api/v1/admin/user.go` so GOOD-protection no longer blocks a user from editing their own account through the admin API.
 - 3 - I modified `templates/admin/user/list.tmpl`, `templates/admin/user/view.tmpl`, and `templates/admin/user/edit.tmpl` so `Edit` stays enabled for allowed self-edits, while forbidden `Edit` and `Delete` actions are shown disabled with the specific reason tooltip or warning message.
 
-74 - [2026-04-30 20:11:48] - v1.27.0-dev-72-g43161732e3 - Type: Modified - Added install-time admin management policy choices with direct-grantor and inherited-grantor enforcement.
+74 - [2026-04-30 20:11:48] - v1.27.0-dev-72-g43161732e3 - Type: Modified - [installer] [locale] [en] Added install-time admin management policy choices with direct-grantor and inherited-grantor enforcement.
 - 1 - I modified `modules/setting/admin.go`, `services/forms/user_form.go`, `routers/install/install.go`, `templates/install.tmpl`, and `options/locale/locale_en-US.json` so installation now exposes three administrator-management policies: `super_admin_only`, `grantor_only`, and `grantor_inheritance`, while normalizing the old legacy policy names.
 - 2 - I modified `models/user/admin_grant.go` so the code can resolve the effective admin grantor by walking the admin-grant chain until it finds an active administrator who still has sign-in enabled.
 - 3 - I modified `routers/web/admin/users.go` so regular admins can edit or delete only the administrator accounts allowed by the selected policy, while keeping super-admin protections, GOOD protections, self-edit exceptions, and disabled forbidden actions intact in the admin UI.
 - 4 - I modified `routers/api/v1/admin/user.go` so the admin API now applies the same grantor-based restrictions for editing and deleting administrator accounts.
 - 5 - I added focused integration coverage in `tests/integration/admin_user_test.go` and `tests/integration/api_admin_test.go` for direct-grantor edits, inherited-grantor edits, and API denial for unrelated admins.
 
-75 - [2026-04-30 20:37:01] - v1.27.0-dev-72-g43161732e3 - Type: Modified - Updated the example app.ini documentation for the new administrator management policies.
+75 - [2026-04-30 20:37:01] - v1.27.0-dev-72-g43161732e3 - Type: Modified - [installer] [app-ini-import] [admin-policy] Updated the example app.ini documentation for the new administrator management policies.
 - 1 - I modified `custom/conf/app.example.ini` so the `ADMIN_MANAGEMENT_POLICY` comments now document `super_admin_only`, `grantor_only`, and `grantor_inheritance`, and changed the documented default to `grantor_only`.
 
-76 - [2026-04-30 22:03:50] - v1.27.0-dev-73-g1e13af4d6e - Type: Modified - Updated install-page administrator labels to super administrator wording.
+76 - [2026-04-30 22:03:50] - v1.27.0-dev-73-g1e13af4d6e - Type: Modified - [admin-users] [super-admin] [installer] [locale] [en] Updated install-page administrator labels to super administrator wording.
 - 1 - I modified `options/locale/locale_en-US.json` so the install-page administrator account title, description, and username label now refer to the super administrator role.
 - 2 - I renamed the install-page policy label from `Administrator Management Policy` to `Administration Management Policy`.
 
-77 - [2026-04-30 23:05:46] - v1.27.0-dev-75-gd4a1b88385 - Type: Modified - Added install-page testing email verification using the entered SMTP settings.
+77 - [2026-04-30 23:05:46] - v1.27.0-dev-75-gd4a1b88385 - Type: Modified - [mailer] [installer] [locale] [en] Added install-page testing email verification using the entered SMTP settings.
 - 1 - I modified `routers/install/routes.go`, `routers/install/install.go`, and `templates/install.tmpl` so the install page now has an inline `Send Testing Email` action that posts the current SMTP form values to a dedicated install endpoint.
 - 2 - I modified `services/mailer/mail.go` and `routers/web/admin/config.go` so compact test-mail error formatting is shared and install can send a test message with a temporary mailer configuration instead of relying on saved global settings.
 - 3 - I modified `options/locale/locale_en-US.json` for the install-page test-mail labels and regenerated template and options bindata after verifying the affected Go packages compile.
 
-78 - [2026-04-30 23:25:10] - v1.27.0-dev-75-gd4a1b88385 - Type: Modified - Repositioned install-page Send Testing Email under SMTP Password.
+78 - [2026-04-30 23:25:10] - v1.27.0-dev-75-gd4a1b88385 - Type: Modified - [mailer] [mailer-ui] [installer] Repositioned install-page Send Testing Email under SMTP Password.
 - 1 - I modified `templates/install.tmpl` so the `Send Testing Email` row now appears immediately below the `SMTP Password` field inside `Email Settings`.
 - 2 - I kept the existing selectors, inline message area, and button behavior unchanged while preserving the remaining field order.
 - 3 - I regenerated template bindata and rechecked the install package compile path after the layout-only change.
 
-79 - [2026-04-30 23:48:41] - v1.27.0-dev-75-gd4a1b88385 - Type: Fixed - Aligned install-page Send Testing Email with the standard inline form grid.
+79 - [2026-04-30 23:48:41] - v1.27.0-dev-75-gd4a1b88385 - Type: Fixed - [mailer] [mailer-ui] [installer] Aligned install-page Send Testing Email with the standard inline form grid.
 - 1 - I modified `templates/install.tmpl` so the `Send Testing Email` input, button, and message now render inside the same `right-content` column used by the other install-page inline fields.
 - 2 - I kept the existing selectors and behavior unchanged and only corrected the layout alignment relative to `SMTP Password`.
 
-80 - [2026-05-01 00:36:35] - v1.27.0-dev-75-gd4a1b88385 - Type: Fixed - Matched install-page Send Testing Email row to the target inline layout.
+80 - [2026-05-01 00:36:35] - v1.27.0-dev-75-gd4a1b88385 - Type: Fixed - [mailer] [mailer-ui] [installer] [ui] Matched install-page Send Testing Email row to the target inline layout.
 - 1 - I modified `templates/install.tmpl` so the `Send Testing Email` controls now use an inline wrapper with the same 60 percent content width as the standard install-form inputs instead of the block-style `right-content` helper.
 - 2 - I kept the existing selectors and behavior unchanged and only corrected the horizontal alignment to match the target SMTP Password row layout.
 
-81 - [2026-05-01 00:56:45] - v1.27.0-dev-75-gd4a1b88385 - Type: Modified - Brightened install-page Send Testing Email status message colors.
+81 - [2026-05-01 00:56:45] - v1.27.0-dev-75-gd4a1b88385 - Type: Modified - [mailer] [mailer-ui] [installer] [ui] Brightened install-page Send Testing Email status message colors.
 - 1 - I modified `templates/install.tmpl` so the inline status message now uses `var(--color-green)` for success and `var(--color-red)` for failure instead of the softer Tailwind utility classes.
 - 2 - I kept the existing button behavior unchanged and only adjusted the message text color handling in the install-page JavaScript.
 
-82 - [2026-05-01 13:09:43] - v1.27.0-dev-76-g362d01abbc - Type: Modified - Added install-page Registration Management with coherent mode-driven registration settings.
+82 - [2026-05-01 13:09:43] - v1.27.0-dev-76-g362d01abbc - Type: Modified - [installer] [signup] [locale] [en] Added install-page Registration Management with coherent mode-driven registration settings.
 - 1 - I modified `templates/install.tmpl`, `services/forms/user_form.go`, and `routers/install/install.go` so the install page now exposes a dedicated `Registration Management` section with radio-button registration modes plus dependent local and external sub-options.
 - 2 - I mapped the new UI to the existing service settings by deriving `DISABLE_REGISTRATION`, `ALLOW_ONLY_INTERNAL_REGISTRATION`, `ALLOW_ONLY_EXTERNAL_REGISTRATION`, `REGISTER_EMAIL_CONFIRM`, and `REGISTER_MANUAL_CONFIRM` consistently from the selected mode and sub-options.
 - 3 - I updated `web_src/js/features/install.ts` and `options/locale/locale_en-US.json` so contradictory options are hidden or disabled in the browser, added the new English labels and descriptions, and regenerated template and options bindata.
 
-83 - [2026-05-01 18:14:40] - v1.27.0-dev-77-g19fb194db6 - Type: Modified - Completed install-page admin-managed account modes and aligned locale install sections.
+83 - [2026-05-01 18:14:40] - v1.27.0-dev-77-g19fb194db6 - Type: Modified - [installer] [locale] [en] Completed install-page admin-managed account modes and aligned locale install sections.
 - 1 - I modified `modules/setting/service.go`, `custom/conf/app.example.ini`, `services/forms/user_form.go`, `routers/install/install.go`, `templates/install.tmpl`, and `web_src/js/features/install.ts` so `Registration Management` now includes administrator-managed local versus invitation-based account provisioning, plus a helper for `Enable Email Notifications`.
 - 2 - I updated `routers/web/admin/users.go` and `routers/api/v1/admin/user.go` so disabled-registration account creation follows the configured administrator-created account mode, stores creator metadata for admin-created users, and sends either invitation mail or standard registration notification accordingly.
 - 3 - I aligned every `options/locale/locale_*.json` install section to the new key set and en-US fallback order, regenerated template and options bindata, and verified the affected install, admin web, and admin API packages.
 
-84 - [2026-05-02 00:16:23] - v1.27.0-dev-78-gad0ab4be60 - Type: Modified - Moved admin-created account delivery mode selection from install to the admin new-user form.
+84 - [2026-05-02 00:16:23] - v1.27.0-dev-78-gad0ab4be60 - Type: Modified - [admin-created-user] [admin-users] [installer] [locale] [en] Moved admin-created account delivery mode selection from install to the admin new-user form.
 - 1 - I updated `templates/install.tmpl` and `web_src/js/features/install.ts` to remove the install-page `Administrator-managed accounts only` sub-mode choice so registration mode no longer decides how `/admin/users/new` delivers newly created accounts.
 - 2 - I extended `services/forms/admin.go`, `templates/admin/user/new.tmpl`, `web_src/js/features/admin/common.ts`, and `routers/web/admin/users.go` so `/admin/users/new` now offers mutually exclusive `Send User Registration Notification` and `Send User Registration Invitation` checkboxes, defaults the invitation checkbox when mail is available, preserves checkbox state on form re-render, and sends the matching email flow.
 - 3 - I adjusted `routers/web/admin/users_test.go`, added the new `admin.users.send_register_invite` locale key across `options/locale/locale_*.json`, regenerated template and options bindata, and re-verified the focused admin user flow.
 
-85 - [2026-05-02 01:52:40] - v1.27.0-dev-79-ga6695a6e73 - Type: Modified - Unified classic email-confirmation signup with the resend-based pending validation flow.
+85 - [2026-05-02 01:52:40] - v1.27.0-dev-79-ga6695a6e73 - Type: Modified - [auth] [mailer] [signup] [locale] [en] Unified classic email-confirmation signup with the resend-based pending validation flow.
 - 1 - I updated `routers/web/auth/auth.go` and `routers/web/auth/account_request.go` so classic `REGISTER_EMAIL_CONFIRM` signups now render the same resend-capable activation prompt after account creation, redirect repeated signups with the same unconfirmed email to the resend-capable pending state instead of `The username is already taken`, and show the same resend-capable prompt when an unconfirmed user attempts to sign in.
 - 2 - I added classic activation resend state tracking in `models/user/account_request.go`, re-used the existing resend UI data contract for both signup and activation prompts, and extended `/user/sign_up/resend` to handle classic email-confirmation accounts with a five-resend limit.
 - 3 - I added focused auth tests in `routers/web/auth/auth_test.go`, aligned all `options/locale/locale_*.json` files with the new confirmation-mail keys, regenerated options bindata, and re-verified the affected auth package.
 
-86 - [2026-05-02 02:20:53] - v1.27.0-dev-80-g4ab8063966 - Type: Modified - Added default language selection to the install page initial configuration.
+86 - [2026-05-02 02:20:53] - v1.27.0-dev-80-g4ab8063966 - Type: Modified - [installer] [locale] [en] Added default language selection to the install page initial configuration.
 - 1 - I extended `services/forms/user_form.go`, `routers/install/install.go`, and `templates/install.tmpl` so `General Settings` now includes a `Default Language` selector backed by the existing `AllLangs` list and validated against configured locales.
 - 2 - I wired install submission to persist the selection by reordering `[i18n] LANGS` so the chosen language becomes the first fallback/default locale, while keeping the remaining languages available.
 - 3 - I added focused install tests in `routers/install/routes_test.go`, aligned all `options/locale/locale_*.json` files with the new install language keys, regenerated template and options bindata, and re-verified the install package.
 
-87 - [2026-05-02 02:36:07] - v1.27.0-dev-80-g4ab8063966 - Type: Modified - Disabled forbidden email deletion actions in the admin email list.
+87 - [2026-05-02 02:36:07] - v1.27.0-dev-80-g4ab8063966 - Type: Modified - [mailer] Disabled forbidden email deletion actions in the admin email list.
 - 1 - I extended `routers/web/admin/emails.go` so each listed email now carries explicit delete permission state and, for primary addresses, the existing `admin.emails.delete_primary_email_error` reason for the disabled UI.
 - 2 - I updated `templates/admin/emails/list.tmpl` so the trash icon remains clickable only for deletable addresses and renders as a muted disabled control with a tooltip when deletion is forbidden, such as for a primary email address.
 - 3 - I kept the existing backend deletion guard in place, regenerated template bindata, and re-verified the affected admin package plus whitespace consistency.
 
-88 - [2026-05-02 03:12:25] - v1.27.0-dev-82-gf8f988e85e - Type: Modified - Added a dedicated pending-invitation flow for admin-created invite accounts and pinned the install footer.
+88 - [2026-05-02 03:12:25] - v1.27.0-dev-82-gf8f988e85e - Type: Modified - [admin-invite] [installer] [sticky-layout] [locale] [en] Added a dedicated pending-invitation flow for admin-created invite accounts and pinned the install footer.
 - 1 - I updated `templates/admin/user/new.tmpl`, `routers/web/admin/users.go`, `routers/api/v1/admin/user.go`, `models/user/account_request.go`, and `services/mailer/mail_user.go` so admin-created invitation accounts remain inactive without forcing `Disable Sign-In`, carry explicit pending-invitation state, and show helper text for the notification versus invitation options.
 - 2 - I added the dedicated invitation prompt and resend flow through `templates/user/auth/invite_prompt.tmpl`, `routers/web/auth/auth.go`, `routers/web/auth/account_request.go`, and `routers/web/web.go`, including sign-in redirection for pending invitations, backward-compatible handling for legacy prohibited invite accounts, and resend tracking for invitation emails.
 - 3 - I updated `templates/base/footer_content.tmpl`, `web_src/css/install.css`, and all `options/locale/locale_*.json` files so the install footer stays continuously visible on the install page, the new invitation strings are available across locales, template and option bindata were regenerated, and the affected auth/admin/API packages were re-verified.
 
-89 - [2026-05-02 04:05:54] - v1.27.0-dev-83-gf7bc24d4e8 - Type: Modified - Aligned the admin new-user invitation help text with the install-page help layout.
+89 - [2026-05-02 04:05:54] - v1.27.0-dev-83-gf7bc24d4e8 - Type: Modified - [admin-invite] [installer] [ui] Aligned the admin new-user invitation help text with the install-page help layout.
 - 1 - I updated `templates/admin/user/new.tmpl` so the `Send User Registration Notification` and `Send User Registration Invitation` rows now use a dedicated right-side content wrapper instead of rendering the help text directly under the checkbox.
 - 2 - I extended `web_src/css/admin.css` with scoped layout rules for `.admin-user-mail-option` so the help text sits under the checkbox content in the same visual column style used on the install page, including responsive behavior for narrow screens.
 - 3 - I regenerated template bindata after the markup change and re-verified whitespace consistency for the affected files.
 
-90 - [2026-05-02 12:11:50] - v1.27.0-dev-84-gf60b2af5a6 - Type: Modified - Added an install-page language hint balloon anchored to the footer language selector.
+90 - [2026-05-02 12:11:50] - v1.27.0-dev-84-gf60b2af5a6 - Type: Modified - [installer] [locale] [en] [ui] [sticky-layout] Added an install-page language hint balloon anchored to the footer language selector.
 - 1 - I updated `templates/base/footer_content.tmpl` and `templates/install.tmpl` so the install page now renders a green `Choose a language` hint balloon tied to the footer language selector and dismisses it on the first page click.
 - 2 - I extended `web_src/css/install.css` with fixed-position balloon styling and responsive placement above the install footer so the hint remains visible without overlapping the footer controls.
 - 3 - I added the new `install.language_balloon` locale key to `options/locale/locale_en-US.json`, aligned all `options/locale/locale_*.json` files to include it, and re-generated the template and options bindata assets.
 
-91 - [2026-05-02 12:28:12] - v1.27.0-dev-84-gf60b2af5a6 - Type: Fixed - Delayed the install-page language hint balloon initialization until the footer exists in the DOM.
+91 - [2026-05-02 12:28:12] - v1.27.0-dev-84-gf60b2af5a6 - Type: Fixed - [installer] [locale] [ui] [sticky-layout] Delayed the install-page language hint balloon initialization until the footer exists in the DOM.
 - 1 - I updated `templates/install.tmpl` so the `Choose a language` balloon now initializes on `DOMContentLoaded` instead of running before the footer language selector has been parsed.
 - 2 - I kept the existing dismiss-on-first-click behavior unchanged and only fixed the timing issue that prevented the balloon from appearing at first page load.
 - 3 - I regenerated the template bindata assets and re-verified whitespace consistency after the template-only fix.
 
-92 - [2026-05-02 13:31:45] - v1.27.0-dev-85-g4eaa42bccd - Type: Modified - Added official bootstrap support for the Romanian locale.
+92 - [2026-05-02 13:31:45] - v1.27.0-dev-85-g4eaa42bccd - Type: Modified - [locale] [en] [ro] Added official bootstrap support for the Romanian locale.
 - 1 - I updated `modules/setting/i18n.go` so `ro-RO` is now part of the built-in language list with the display name `Română`.
 - 2 - I updated `custom/conf/app.example.ini` so the example `[i18n] LANGS` and `NAMES` lists now include `ro-RO` and `Română`.
 - 3 - I added `options/locale/locale_ro-RO.json` as an initial bootstrap locale copied from `locale_en-US.json`, so the Romanian locale can be selected and loaded cleanly before the dedicated translation pass.
 
-93 - [2026-05-02 14:41:58] - v1.27.0-dev-86-g414c77278b - Type: Modified - Added a first complete Romanian translation pass for `locale_ro-RO.json`.
+93 - [2026-05-02 14:41:58] - v1.27.0-dev-86-g414c77278b - Type: Modified - [locale] [en] [ro] Added a first complete Romanian translation pass for `locale_ro-RO.json`.
 - 1 - I translated `options/locale/locale_ro-RO.json` from the current `locale_en-US.json` structure, preserving placeholders and HTML fragments, then applied targeted manual overrides for the install, auth, mail, and admin account-management flows customized in this fork.
 - 2 - I normalized key Git and administration terms in Romanian and fixed token-protection artifacts that surfaced during the automated translation pass, including the affected `WebAuthn`, `OpenID`, `CAPTCHA`, `Gitea`, milestone completeness, delete-warning, and GPG warning strings.
 - 3 - I regenerated `modules/options/bindata.dat` so the updated Romanian locale is embedded in the build output.
 
-94 - [2026-05-05 02:30:50] - v1.27.0-dev-86-g414c77278b - Type: Modified - Refined Romanian UI wording in `locale_ro-RO.json`.
+94 - [2026-05-05 02:30:50] - v1.27.0-dev-86-g414c77278b - Type: Modified - [locale] [ro] Refined Romanian UI wording in `locale_ro-RO.json`.
 - 1 - I adjusted Romanian phrasing across the translated locale to improve readability and consistency in general UI strings.
 - 2 - I normalized terminology for navigation, repository, authentication, and administration labels to better match the existing Gitea interface.
 - 3 - I kept placeholders, HTML fragments, and technical tokens intact while polishing the translated text.
 
-95 - [2026-05-06 03:15:10] - v1.27.0-dev-86-g414c77278b - Type: Modified - Corrected Romanian wording and grammar in `locale_ro-RO.json`.
+95 - [2026-05-06 03:15:10] - v1.27.0-dev-86-g414c77278b - Type: Modified - [locale] [ro] Corrected Romanian wording and grammar in `locale_ro-RO.json`.
 - 1 - I fixed a small set of Romanian phrasing and grammar issues identified after the previous translation polish pass.
 - 2 - I kept the scope limited to wording corrections without changing the locale structure or translation coverage.
 - 3 - I preserved existing placeholders, HTML fragments, and technical tokens while applying the text fixes.
 
-96 - [2026-05-06 00:47:16] - v1.27.0-dev-90-g75a9dbf7d7 - Type: Modified - Restyled the organization creation panel and added a cancel action.
+96 - [2026-05-06 00:47:16] - v1.27.0-dev-90-g75a9dbf7d7 - Type: Modified - [org-ui] [ui] Restyled the organization creation panel and added a cancel action.
 - 1 - I updated `templates/org/create.tmpl` so `/org/create` now renders inside a settings-style attached header and segment panel instead of the older standalone form block.
 - 2 - I kept the existing organization creation fields intact, but changed the action row to a right-aligned button group with a new `Cancel` button beside `Create Organization`.
 - 3 - I updated `routers/web/org/org.go` to provide a `CancelLink` back to `/user/settings/organization`, regenerated template bindata, and re-verified the `routers/web/org` package.
 
-97 - [2026-05-06 01:08:23] - v1.27.0-dev-90-g75a9dbf7d7 - Type: Modified - Converted the organization creation page to a modal-style dialog and preserved the caller page for cancel.
+97 - [2026-05-06 01:08:23] - v1.27.0-dev-90-g75a9dbf7d7 - Type: Modified - [org-ui] [modal] Converted the organization creation page to a modal-style dialog and preserved the caller page for cancel.
 - 1 - I updated `templates/org/create.tmpl` so `/org/create` now renders as a visible `ui small modal` dialog with header, content, and actions matching the visual structure used by the Actions secrets and variables modals.
 - 2 - I extended `web_src/css/org.css` with page-scoped layout rules that center the active modal on the standalone page while keeping the styling limited to `page-content.organization.new.org`.
 - 3 - I updated `routers/web/org/org.go` so `Cancel` now returns to a safe current-site `redirect_to` target or same-site referrer instead of always forcing `/user/settings/organization`, regenerated template bindata, and re-verified the `routers/web/org` package.
 
-98 - [2026-05-06 02:02:33] - v1.27.0-dev-91-gba0da47957 - Type: Added - Added persistent Codex project-orientation documents for fast task handoff and recovery.
+98 - [2026-05-06 02:02:33] - v1.27.0-dev-91-gba0da47957 - Type: Added - [codex-docs] Added persistent Codex project-orientation documents for fast task handoff and recovery.
 - 1 - I added `.codex-project-map.md` as a durable project guide that captures the web request flow, authentication architecture, practical extension points, and a restart procedure for new tasks.
 - 2 - I modified `.codex-context.md` so it now points explicitly to `.codex-project-map.md` and documents the recommended read order for resuming work after a blocked session.
 - 3 - I refreshed the repository-derived version reference in `.codex-context.md` so future history updates can use the current application version format consistently.
 
-99 - [2026-05-06 02:18:58] - v1.27.0-dev-91-gba0da47957 - Type: Modified - Reworked organization creation into a real overlay modal on top of the organization settings page and made outside clicks close it.
+99 - [2026-05-06 02:18:58] - v1.27.0-dev-91-gba0da47957 - Type: Modified - [org-ui] [modal] [ui] Reworked organization creation into a real overlay modal on top of the organization settings page and made outside clicks close it.
 - 1 - I modified `templates/user/settings/organization.tmpl` so the `New Organization` action now opens the create dialog with the standard `show-modal` flow while keeping the organization settings page visible in the background.
 - 2 - I converted `templates/org/create.tmpl` into a reusable modal partial and updated `routers/web/org/org.go` so `/org/create` now renders the same organization settings page with that modal auto-opened, preserving `CancelLink` for close and validation-error flows.
 - 3 - I simplified `web_src/css/org.css` to keep only the create-modal helper text styling and removed the previous fake standalone modal layout that replaced the background page.
 
-100 - [2026-05-06 10:13:49] - v1.27.0-dev-91-gba0da47957 - Type: Fixed - Corrected the organization settings cancel-link build regression.
+100 - [2026-05-06 10:13:49] - v1.27.0-dev-91-gba0da47957 - Type: Fixed - [org-ui] [ui] Corrected the organization settings cancel-link build regression.
 - 1 - I fixed `routers/web/user/setting/profile.go` so it uses the `ctx.Req.RequestURI` field instead of calling it like a function.
 - 2 - This removes the compile error in `code.gitea.io/gitea/routers/web/user/setting` that was blocking the Windows build after the organization-create modal refactor.
 
-101 - [2026-05-06 10:54:10] - v1.27.0-dev-91-gba0da47957 - Type: Modified - Made the new-organization modal open in place from the UI and reset its default values consistently.
+101 - [2026-05-06 10:54:10] - v1.27.0-dev-91-gba0da47957 - Type: Modified - [org-ui] [modal] Made the new-organization modal open in place from the UI and reset its default values consistently.
 - 1 - I moved the reusable `create-org-modal` inclusion to `templates/base/footer.tmpl` so signed-in users who can create organizations have the modal available on normal pages without navigating away first.
 - 2 - I updated the `New Organization` triggers in `templates/base/head_navbar.tmpl`, `templates/user/dashboard/navbar.tmpl`, `templates/admin/org/list.tmpl`, and `templates/user/settings/organization.tmpl` to use `show-modal` with `/org/create` as a non-JavaScript fallback, preserving the current page and scroll position when JavaScript is enabled.
 - 3 - I added explicit reset attributes for organization name, `redirect_to`, visibility radios, and the `repo_admin_change_team_access` checkbox so the modal opened from `/user/settings/organization` now uses the same defaults as the one opened from the global create menu.
 
-102 - [2026-05-06 10:55:13] - v1.27.0-dev-91-gba0da47957 - Type: Modified - Extended the in-place new-organization modal behavior to the dashboard organization list component.
+102 - [2026-05-06 10:55:13] - v1.27.0-dev-91-gba0da47957 - Type: Modified - [org-ui] [modal] Extended the in-place new-organization modal behavior to the dashboard organization list component.
 - 1 - I modified `web_src/js/components/DashboardRepoList.vue` so the `New Organization` trigger in the organizations dashboard tab now also uses the shared `show-modal` flow instead of forcing navigation when JavaScript is enabled.
 - 2 - I kept `/org/create` as the fallback `href` in the component so the non-JavaScript path remains available.
 
-103 - [2026-05-06 18:03:33] - v1.27.0-dev-91-gba0da47957 - Type: Modified - Somes correction Romanian wording and grammar in `locale_ro-RO.json`.
-
-104 - [2026-05-06 18:19:21] - v1.27.0-dev-91-gba0da47957 - Type: Modified - Fix align new-user check-boxes help text.
-
-105 - [2026-05-06 18:47:44] - v1.27.0-dev-91-gba0da47957 - Type: Modified - Some new correction Romanian wording and grammar in `locale_ro-RO.json`.
-
-106 - [2026-05-06 15:54:50] - v1.27.0-dev-96-g7c7357f314 - Type: Modified - Reduced the resend button size on the invitation acceptance prompt.
+103 - [2026-05-06 18:03:33] - v1.27.0-dev-91-gba0da47957 - Type: Modified - [locale] [ro] Somes correction Romanian wording and grammar in `locale_ro-RO.json`.
+104 - [2026-05-06 18:19:21] - v1.27.0-dev-91-gba0da47957 - Type: Modified - [ui] Fix align new-user check-boxes help text.
+105 - [2026-05-06 18:47:44] - v1.27.0-dev-91-gba0da47957 - Type: Modified - [locale] [ro] Some new correction Romanian wording and grammar in `locale_ro-RO.json`.
+106 - [2026-05-06 15:54:50] - v1.27.0-dev-96-g7c7357f314 - Type: Modified - [admin-invite] [auth] Reduced the resend button size on the invitation acceptance prompt.
 - 1 - I modified `templates/user/auth/invite_prompt.tmpl` so the `Resend` button on `/user/invitation?email=...` now uses the smaller `ui mini button` size instead of `ui tiny button`.
 - 2 - I kept the existing inline resend states, colors, and success reset behavior unchanged.
 
-107 - [2026-05-06 18:57:49] - v1.27.0-dev-98-g5f0f52d04f - Type: Fixed - Prevented the new-organization modal from inheriting unrelated global success flashes from the underlying page.
+107 - [2026-05-06 18:57:49] - v1.27.0-dev-98-g5f0f52d04f - Type: Fixed - [org-ui] [modal] Prevented the new-organization modal from inheriting unrelated global success flashes from the underlying page.
 - 1 - I modified `templates/org/create.tmpl` so the modal now renders only its local error flash instead of the full `base/alert` block.
 - 2 - This keeps `/org/create` validation errors visible in the modal while preventing inherited success, info, or warning flash messages from the background page from appearing inside it.
 
-108 - [2026-05-06 21:07:26] - v1.27.0-dev-99-gfc43980a5c - Type: Fixed - Made admin-created user notification and invitation emails use the current page locale.
+108 - [2026-05-06 21:07:26] - v1.27.0-dev-99-gfc43980a5c - Type: Fixed - [admin-invite] [admin-created-user] [mailer] [locale] Made admin-created user notification and invitation emails use the current page locale.
 - 1 - I modified `services/mailer/mail_user.go` to add locale-aware variants for registration-notify and admin-invite emails, while preserving the existing user-language fallback helpers for other call sites.
 - 2 - I modified `routers/web/admin/users.go` and `routers/api/v1/admin/user.go` so admin-created account emails now use `ctx.Locale` from the current request instead of always rendering in the new account's empty or default language.
 
-109 - [2026-05-06 22:11:33] - v1.27.0-dev-100-g70ef46362e - Type: Modified - Personalized the admin-created account notification email with the creator name and a direct set-password link.
+109 - [2026-05-06 22:11:33] - v1.27.0-dev-100-g70ef46362e - Type: Modified - [admin-created-user] [mailer] [locale] [en] [ro] Personalized the admin-created account notification email with the creator name and a direct set-password link.
 - 1 - I modified `services/mailer/mail_user.go` so the registration notification email now accepts the admin user, generates a time-limited `reset_password` token URL for the new account, and passes both values into the mail template.
 - 2 - I modified `routers/web/admin/users.go` and `routers/api/v1/admin/user.go` so the admin-created account notification now includes `ctx.Doer` when sending the non-invite email variant.
 - 3 - I modified `templates/mail/user/auth/register_notify.tmpl`, `options/locale/locale_en-US.json`, and `options/locale/locale_ro-RO.json` so the email explicitly states that the administrator created the account and instructs the recipient to use a personal password-setup link before signing in.
 
-110 - [2026-05-06 22:11:33] - v1.27.0-dev-100-g70ef46362e - Type: Fixed - Corrected the admin-created account password-setup email link to use the public recovery route.
+110 - [2026-05-06 22:11:33] - v1.27.0-dev-100-g70ef46362e - Type: Fixed - [admin-created-user] [mailer] Corrected the admin-created account password-setup email link to use the public recovery route.
 - 1 - I modified `services/mailer/mail_user.go` so the personalized password-setup link now targets `/user/recover_account?code=...`, which is the actual public route mounted for password reset token handling.
 - 2 - This fixes the 404 triggered by the previous `/user/reset_password?code=...` link, because the router exposes `auth.ResetPasswd` on `/user/recover_account` instead.
 
-111 - [2026-05-06 23:43:34] - v1.27.0-dev-102-g146013827c - Type: Modified - Made the admin-created account notification link behave like an invitation by signing the user in through `/user/activate`.
+111 - [2026-05-06 23:43:34] - v1.27.0-dev-102-g146013827c - Type: Modified - [admin-invite] [admin-created-user] Made the admin-created account notification link behave like an invitation by signing the user in through `/user/activate`.
 - 1 - I modified `models/user/user.go` to add a dedicated `TimeLimitCodeAdminAccess` purpose that reuses the password-reset lifetime but remains separate from reset-password and invite tokens.
 - 2 - I modified `services/mailer/mail_user.go` so the `Send User Registration Notification` email now points to `/user/activate?code=...` with the new admin-access token instead of sending the recipient through the recovery form flow.
 - 3 - I modified `routers/web/auth/auth.go` so `auth.Activate` and `auth.ActivatePost` can consume the new token, rotate `Rands`, create the session, refresh locale, update last-login metadata, and then rely on the existing `MustChangePassword` redirect to land the user on `/user/settings/change_password`.
 - 4 - I added `TestActivateAdminAccessSignsInAndInvalidatesCode` in `routers/web/auth/auth_test.go` to cover the new direct-access flow and confirm the token is invalidated after first use.
 
-112 - [2026-05-06 23:43:34] - v1.27.0-dev-102-g146013827c - Type: Modified - Simplified the admin-created account notification email to show only the personalized activation link.
+112 - [2026-05-06 23:43:34] - v1.27.0-dev-102-g146013827c - Type: Modified - [auth] [admin-created-user] [mailer] Simplified the admin-created account notification email to show only the personalized activation link.
 - 1 - I modified `templates/mail/user/auth/register_notify.tmpl` so the mail no longer shows the generic `/user/login` URL and instead displays the personalized admin-access link directly under the username.
 - 2 - I removed the trailing explanatory paragraph below that link to avoid repeating the same password-setup action twice in the same email.
 
-113 - [2026-05-07 01:01:44] - v1.27.0-dev-104-g10495b7cd1 - Type: Modified - Reverted the global fixed-footer behavior and replaced it with a persistent per-user footer preference in `/user/settings/appearance`.
+113 - [2026-05-07 01:01:44] - v1.27.0-dev-104-g10495b7cd1 - Type: Modified - [user-settings] [sticky-layout] [appearance] [locale] [en] [ro] Reverted the global fixed-footer behavior and replaced it with a persistent per-user footer preference in `/user/settings/appearance`.
 - 1 - I modified `templates/user/settings/appearance.tmpl`, `routers/web/user/setting/profile.go`, and `routers/web/web.go` to add a new footer section with a checkbox that saves whether the footer should stay visible at the bottom of the viewport for the current user.
 - 2 - I modified `models/user/setting_options.go`, `routers/common/pagetmpl.go`, `templates/base/head.tmpl`, `modules/web/middleware/cookie.go`, `web_src/css/base.css`, and `web_src/css/home.css` so the preference is stored in `user_settings`, propagated into the page layout, and applied only when the `show-persistent-footer` body class is enabled.
 - 3 - I modified `options/locale/locale_en-US.json`, `options/locale/locale_ro-RO.json`, and `models/user/setting_test.go` to add the new UI strings and a focused test covering the new persisted setting key.
 
-114 - [2026-05-07 09:30:56] - v1.27.0-dev-105-gb3a7692ce9 - Type: Modified - Moved the persistent footer outside the page scroll area.
+114 - [2026-05-07 09:30:56] - v1.27.0-dev-105-gb3a7692ce9 - Type: Modified - [ui] [sticky-layout] Moved the persistent footer outside the page scroll area.
 - 1 - I modified `web_src/css/base.css` so pages with `show-persistent-footer` stop scrolling the whole `body` and instead scroll the `.full.height` content container, keeping the footer in its own fixed viewport slot.
 - 2 - I modified `web_src/css/home.css` so the persistent footer no longer overlays the page with `position: fixed`, but stays permanently visible as a non-scrolling sibling below the main content area.
 
-115 - [2026-05-07 09:54:43] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - Added the persistent sticky side-menu preference and the finalized sidebar behavior for `/user/settings` and `/-/admin`.
+115 - [2026-05-07 09:54:43] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - [user-settings] [sticky-layout] [locale] [en] [ro] Added the persistent sticky side-menu preference and the finalized sidebar behavior for `/user/settings` and `/-/admin`.
 - 1 - I modified `models/user/setting_options.go`, `routers/common/pagetmpl.go`, `templates/base/head.tmpl`, `routers/web/user/setting/profile.go`, `routers/web/web.go`, `templates/user/settings/appearance.tmpl`, `options/locale/locale_en-US.json`, `options/locale/locale_ro-RO.json`, and `models/user/setting_test.go` to add the persisted `ui.sticky_side_menus` preference, expose it to templates as `ShowStickySideMenus`, save it from `/user/settings/appearance`, document it in the UI, and cover it with a focused test.
 - 2 - I modified `templates/user/settings/actions_general.tmpl` so `/user/settings/actions/general` passes the expected `pageClass` and participates in the same sticky-sidebar behavior as the other settings subpages.
 - 3 - I modified `web_src/css/modules/flexcontainer.css` so, when the preference is enabled, the shared left menus on `/user/settings` and `/-/admin` use the current sticky layout: sticky positioning on the inner menu, `top: var(--page-spacing)`, footer-aware `max-height` handling for both persistent and non-persistent footer modes, hidden desktop scrollbars, green overflow hints, local menu scrolling, and the current `/user/settings` item padding.
 - 4 - I modified `web_src/js/features/common-page.ts` so the sticky side menus update their overflow-hint classes dynamically as their scroll position, size, or expanded sections change.
 
-116 - [2026-05-07 20:41:28] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - Added a persistent navigation-bar preference in `/user/settings/appearance`.
+116 - [2026-05-07 20:41:28] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - [user-settings] [sticky-layout] [appearance] [locale] [en] [ro] Added a persistent navigation-bar preference in `/user/settings/appearance`.
 - 1 - I modified `models/user/setting_options.go`, `models/user/setting_test.go`, `routers/common/pagetmpl.go`, `routers/web/user/setting/profile.go`, `routers/web/web.go`, `templates/base/head.tmpl`, `templates/user/settings/appearance.tmpl`, `options/locale/locale_en-US.json`, and `options/locale/locale_ro-RO.json` to add the persisted `ui.persistent_navbar` preference, expose it to templates as `ShowPersistentNavbar`, save it from `/user/settings/appearance`, and document it in the UI.
 - 2 - I modified `web_src/css/modules/navbar.css` so the main `#navbar` becomes sticky at the top of the viewport when the new preference is enabled.
 - 3 - I modified `web_src/css/modules/flexcontainer.css` so sticky side menus take the persistent navbar height into account on desktop, preventing the left menus from sliding underneath the navbar when both preferences are enabled.
 
-117 - [2026-05-07 20:49:16] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - Preserved the `/user/settings` left-menu scroll position across settings-page navigation.
+117 - [2026-05-07 20:49:16] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - [user-settings] [ui] [sticky-layout] Preserved the `/user/settings` left-menu scroll position across settings-page navigation.
 - 1 - I modified `web_src/js/features/common-page.ts` so the sticky `/user/settings` menu saves its current `scrollTop` to `sessionStorage` while scrolling and immediately before clicking a menu link.
 - 2 - I also made the same code restore that saved scroll position after the next settings page renders, keeping the left menu at the same viewport position when navigating between items and subitems.
 
-118 - [2026-05-07 20:57:42] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - Made the footer `Licenses` and `API` links open in a new browser tab and finalized the sticky `User Settings` header plus its top green scroll indicator.
+118 - [2026-05-07 20:57:42] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - [ui] [sticky-layout] Made the footer `Licenses` and `API` links open in a new browser tab and finalized the sticky `User Settings` header plus its top green scroll indicator.
 - 1 - I modified `templates/base/footer_content.tmpl` so both footer links now use `target="_blank"` with `rel="noreferrer"`.
 - 2 - I modified `web_src/css/modules/flexcontainer.css` so the `.header.item` at the top of the `/user/settings` sticky side menu now uses `position: sticky` inside the menu itself, with its own background and bottom separator.
 - 3 - I modified `web_src/css/modules/flexcontainer.css` so, after making the `User Settings` header sticky, the top overflow hint is rendered on the bottom edge of that header and its gradient is drawn by a dedicated `::after` element extending into the scrollable area, while the menu container keeps only the bottom hint when both are active.
 
-119 - [2026-05-07 21:14:11] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - Made the `Admin Settings` menu header sticky while the admin left-menu options scroll.
+119 - [2026-05-07 21:14:11] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - [ui] [sticky-layout] Made the `Admin Settings` menu header sticky while the admin left-menu options scroll.
 - 1 - I modified `web_src/css/modules/flexcontainer.css` so the `.header.item` at the top of the `/-/admin` sticky side menu now uses the same sticky header treatment as `/user/settings`, with its own background and bottom separator.
 - 2 - I modified `web_src/css/modules/flexcontainer.css` so the top green overflow indicator for `/-/admin` is also rendered on the bottom edge of the sticky header, with the gradient drawn by the same dedicated `::after` element used in `/user/settings`.
 
-120 - [2026-05-07 21:31:18] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - Preserved the `/user/settings` left-menu scroll position without the visible reset flicker during navigation.
+120 - [2026-05-07 21:31:18] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - [user-settings] [ui] [sticky-layout] Preserved the `/user/settings` left-menu scroll position without the visible reset flicker during navigation.
 - 1 - I modified `templates/user/settings/navbar.tmpl` to add a small inline restore hook around the menu markup, so a saved `scrollTop` is applied from `sessionStorage` before the menu becomes visible on the next settings page.
 - 2 - I modified `web_src/css/modules/flexcontainer.css` so, while that inline restore is in progress, only the `/user/settings` left menu is temporarily hidden, preventing the brief flash of the menu reset at the top.
 - 3 - I kept `web_src/js/features/common-page.ts` focused on saving the menu scroll position and refreshing the scroll indicators, removing the now-redundant late restore path from the global initializer.
 
-121 - [2026-05-07 21:41:44] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - Restored the agreed `/user/settings` sticky-menu item padding behavior.
+121 - [2026-05-07 21:41:44] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - [user-settings] [sticky-layout] Restored the agreed `/user/settings` sticky-menu item padding behavior.
 - 1 - I also updated the same CSS so the `/user/settings` menu padding is applied at the item level inside `.ui.vertical.menu`, using `0.9em 1.14285714em` instead of relying on a menu-level spacing adjustment.
 
-122 - [2026-05-07 22:11:06] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - Restored the pre-`122` `/user/settings` layout baseline while keeping the current sticky-menu behavior.
+122 - [2026-05-07 22:11:06] - v1.27.0-dev-106-g61a9e4bd06 - Type: Modified - [user-settings] [ui] [sticky-layout] Restored the pre-`122` `/user/settings` layout baseline while keeping the current sticky-menu behavior.
 - 1 - I modified `templates/user/settings/layout_head.tmpl` to return the settings page wrapper from `ui container fluid padded flex-container` to `ui container flex-container`.
 - 2 - I restored the `/user/settings` menu to the same single scroll container structure used before, removing the ineffective inner-body split and keeping the inline restore hook in `templates/user/settings/navbar.tmpl`.
 - 3 - I modified `web_src/css/modules/flexcontainer.css` so the `/user/settings` left menu remains temporarily hidden only during the inline scroll restore, keeps the `/user/settings`-only 24px non-persistent-footer bottom padding on the left navigation column, and supports the small `--sticky-side-menu-correction` transform without affecting admin pages.
 - 4 - I kept the matching logic in `web_src/js/features/common-page.ts`, so the `/user/settings` menu still restores its saved scroll position after navigation, refreshes the green overflow indicators, and applies the modest runtime correction only when the sticky menu drifts slightly above its configured top offset.
 
-123 - [2026-05-09 12:47:10] - v1.27.0-dev-114-gbb77e80bf5 - Type: Modified - Finalized the sticky side-menu bottom-edge behavior by compacting menu items and increasing the viewport reserve.
+123 - [2026-05-09 12:47:10] - v1.27.0-dev-114-gbb77e80bf5 - Type: Modified - [sticky-layout] Finalized the sticky side-menu bottom-edge behavior by compacting menu items and increasing the viewport reserve.
 - 1 - I modified `web_src/css/modules/menu.css` so shared menu items now use `padding: 0.75em 1.14285714em`, reducing vertical item height across the sticky left menus.
 - 2 - I modified `web_src/css/modules/flexcontainer.css` so the sticky side menus in both `/user/settings` and `/-/admin` now reserve `40px` instead of `24px` at the bottom of their `max-height` calculation for the non-persistent-footer case.
 - 3 - This combination keeps the sticky menus from jumping upward at the bottom of the page scroll while preserving the current sticky headers, scroll hints, and `/user/settings` scroll-position restore behavior.
 
-124 - [2026-05-09 15:31:52] - v1.27.0-dev-115-g06b7bd3ca1 - Type: Modified - Highlighted the active submenu entry with the standard active background color.
+124 - [2026-05-09 15:31:52] - v1.27.0-dev-115-g06b7bd3ca1 - Type: Modified - [sticky-layout] Highlighted the active submenu entry with the standard active background color.
 - 1 - I modified `web_src/css/modules/menu.css` so `.ui.vertical.menu .item .menu .active.item` now uses `background-color: var(--color-active)` instead of `transparent`.
 - 2 - I kept the existing medium font weight and text color unchanged, so only the active submenu background treatment changed.
 
-125 - [2026-05-09 15:56:47] - v1.27.0-dev-116-g8a0d319607 - Type: Added - Added column-wide Select all controls to the user access-token permissions table.
+125 - [2026-05-09 15:56:47] - v1.27.0-dev-116-g8a0d319607 - Type: Added - [permissions-table] [locale] [en] [ro] Added column-wide Select all controls to the user access-token permissions table.
 - 1 - I modified `templates/user/settings/applications.tmpl` to add a `Select all` row above the token-scope category rows, with per-column `All` radio buttons for No access, Read, and Write.
 - 2 - I added `web_src/js/features/access-token-settings.ts` and registered it in `web_src/js/index.ts` so selecting one of those top-row radios automatically applies the matching permission choice to every category row in the same column.
 - 3 - I added the `settings.select_all` locale string in both `options/locale/locale_en-US.json` and `options/locale/locale_ro-RO.json` for the new control row label.
 - 4 - I extended the same `web_src/js/features/access-token-settings.ts` logic so each top-row `All` radio now becomes active only when every category row in its column is selected, becomes inactive when the column is no longer fully selected, and can still be reselected to apply that column choice to all rows again.
 - 5 - I corrected the select-all synchronization fallback so no top-row radio stays selected when no permission column is fully matched, instead of incorrectly defaulting back to the `No access` column.
 
-126 - [2026-05-09 17:16:12] - v1.27.0-dev-117-gab1135d1c6 - Type: Added - Added header-level Select all controls to the shared Actions maximum-permissions table.
+126 - [2026-05-09 17:16:12] - v1.27.0-dev-117-gab1135d1c6 - Type: Added - [permissions-table] Added header-level Select all controls to the shared Actions maximum-permissions table.
 - 1 - I modified `templates/shared/actions/permissions_table.tmpl` to add a second header row with `Select all` on the left and per-column `All` radio controls for None, Read, and Write.
 - 2 - I extended `web_src/js/features/common-actions-permissions.ts` so those header radios apply the chosen permission to every row in the table and stay synchronized bidirectionally with the current per-row selections.
 - 3 - Because the change is implemented in the shared Actions permissions partial and its existing initializer, the same behavior now applies consistently to `/user/settings/actions/general` and the other pages that reuse that table.
 
-127 - [2026-05-09 17:34:41] - v1.27.0-dev-118-g021f12509f - Type: Modified - Applied the shared sticky side-menu behavior to organization settings pages.
+127 - [2026-05-09 17:34:41] - v1.27.0-dev-118-g021f12509f - Type: Modified - [org-ui] [sticky-layout] Applied the shared sticky side-menu behavior to organization settings pages.
 - 1 - I modified `web_src/css/modules/flexcontainer.css` so the same sticky left-menu layout, hidden scrollbar styling, sticky header behavior, and green overflow indicators used by user settings and admin pages now also apply to `.page-content.organization.settings`.
 - 2 - I modified `web_src/js/features/common-page.ts` so organization settings menus participate in the shared sticky-menu overflow indicator logic.
 - 3 - I modified `templates/org/settings/actions_general.tmpl` to pass `pageClass: "organization settings actions"` into the shared organization settings layout, so the Actions General page also matches the shared organization settings selectors.
 
-128 - [2026-05-09 18:46:07] - v1.27.0-dev-120-g01e3eb1306 - Type: Added - Added password visibility toggles to the login and signup forms.
+128 - [2026-05-09 18:46:07] - v1.27.0-dev-120-g01e3eb1306 - Type: Added - [auth] [password-ui] [signup] [locale] [en] [ro] Added password visibility toggles to the login and signup forms.
 - 1 - I modified `templates/user/auth/signin_inner.tmpl` to add an eye button beside the `/user/login` password field.
 - 2 - I modified `templates/user/auth/signup_inner.tmpl` to add the same eye button beside the `/user/sign_up` password field and marked the `Confirm Password` field for toggle-aware behavior.
 - 3 - I added `web_src/js/features/password-visibility.ts` and registered it in `web_src/js/index.ts` so the eye button toggles between hidden and visible password states.
@@ -646,11 +647,11 @@ Project Change ID[date-time] - application-version - Type - Summary:
 - 6 - I corrected the login and signup password-toggle button templates so their `data-hide-label` attributes close the Go template expression properly, removing the template parsing error that prevented startup.
 - 7 - I added `octicon-eye-closed` to `web_src/js/svg.ts`, fixing the runtime JavaScript error raised when the password toggle switched from the visible-eye icon to the hidden-eye icon.
 
-129 - [2026-05-09 19:36:18] - v1.27.0-dev-121-gbfb584f161 - Type: Modified - Applied the shared sticky side-menu behavior to repository settings pages.
+129 - [2026-05-09 19:36:18] - v1.27.0-dev-121-gbfb584f161 - Type: Modified - [sticky-layout] [repo-settings] Applied the shared sticky side-menu behavior to repository settings pages.
 - 1 - I modified `web_src/css/modules/flexcontainer.css` so the same sticky left-menu layout, hidden scrollbar styling, sticky header behavior, and green overflow indicators used by user settings, organization settings, and admin pages now also apply to `.page-content.repository.settings`.
 - 2 - I modified `web_src/js/features/common-page.ts` so repository settings menus participate in the shared sticky-menu overflow indicator logic.
 
-130 - [2026-05-09 20:07:36] - v1.27.0-dev-122-g652d3c20da - Type: Modified - Applied the shared sticky side-menu behavior to repository Actions pages.
+130 - [2026-05-09 20:07:36] - v1.27.0-dev-122-g652d3c20da - Type: Modified - [sticky-layout] [repo-actions] Applied the shared sticky side-menu behavior to repository Actions pages.
 - 1 - I modified `templates/repo/actions/list.tmpl` to mark the workflow sidebar menu with a dedicated hook class for the shared sticky-menu initializer.
 - 2 - I modified `web_src/css/modules/flexcontainer.css` so the same sticky left-menu layout, hidden scrollbar styling, and green overflow indicators now also apply to `.page-content.repository.actions`.
 - 3 - I modified `web_src/js/features/common-page.ts` so the repository Actions sidebar participates in the shared sticky-menu overflow indicator logic.
@@ -659,118 +660,121 @@ Project Change ID[date-time] - application-version - Type - Summary:
 - 6 - I modified `web_src/css/modules/flexcontainer.css` so the repository Actions sidebar is temporarily hidden only during that inline restore step, preventing the visible reset flicker.
 - 7 - I extended `web_src/js/features/common-page.ts` so the repository Actions sidebar now saves its own scroll position on scroll and before navigation clicks, using the dedicated `sticky-side-menu-scroll:repo-actions` session key.
 
-131 - [2026-05-09 20:54:41] - v1.27.0-dev-123-g0f3876c0b1 - Type: Added - Added pilot partial navigation for the repository Actions sidebar.
+131 - [2026-05-09 20:54:41] - v1.27.0-dev-123-g0f3876c0b1 - Type: Added - [repo-actions] Added pilot partial navigation for the repository Actions sidebar.
 - 1 - I added `web_src/js/features/repo-actions-sidebar.ts` and registered it in `web_src/js/index.ts` to intercept plain left-click navigation on `/<user>/<repo>/actions` sidebar workflow links.
 - 2 - The new client-side flow fetches the target page, replaces only the Actions page `.ui.container` content, updates `document.title`, and pushes the new URL into browser history instead of reloading the full page.
 - 3 - The same logic also handles browser back/forward through `popstate`, keeping the pilot partial navigation limited to repository Actions pages.
 - 4 - I extended the same pilot so, after each partial `.ui.container` swap, the repository Actions sidebar re-runs the shared sticky-menu indicator initializer on the new DOM, restoring the green overflow hints that disappeared after the first in-page navigation.
 
-132 - [2026-05-09 21:10:27] - v1.27.0-dev-123-g0f3876c0b1 - Type: Modified - Added an audio bell for interactive prompts in `smart-build.sh`.
+132 - [2026-05-09 21:10:27] - v1.27.0-dev-123-g0f3876c0b1 - Type: Modified - [scripts] [smart-build] Added an audio bell for interactive prompts in `smart-build.sh`.
 - 1 - I added a small `notify_human_interaction()` helper to `smart-build.sh` that emits a terminal bell only when the script is running on an interactive terminal.
 - 2 - I call that helper immediately before the build-load, architecture, and build-tags interactive menus, so the user gets an audible prompt exactly when human input is needed.
 - 3 - I extended the same helper so VS Code and code-server terminals also get a high-visibility fallback banner when browser-controlled terminal bells do not produce an audible sound.
 - 4 - I extended the same helper again to send a Linux desktop notification through `notify-send` before each interactive menu, while keeping the existing audio and terminal fallbacks for environments where no notification daemon is available.
 
-133 - [2026-05-09 22:32:57] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - Finalized the manual-only password visibility toggle behavior for login and signup.
+133 - [2026-05-09 22:32:57] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - [auth] [password-ui] [signup] Finalized the manual-only password visibility toggle behavior for login and signup.
 - 1 - I removed the static eye button from the login and signup templates and now create it from `web_src/js/features/password-visibility.ts` only when the current password value qualifies for manual reveal.
 - 2 - The final reveal rules are now strict: prefilled or browser-autofilled passwords never show the eye, appending characters to an already non-empty password still keeps it hidden, and the eye appears only after a trusted manual empty-to-non-empty entry or a full manual replacement of a selected existing value.
 - 3 - Once the eye has legitimately appeared, it stays visible through continued typing until the password is cleared again, preserves focus plus caret/selection on click, and keeps the signup confirm-password field synchronized while reveal mode is active.
 - 4 - I converted the toggle into an overlaid control inside the password field, hid the browser-native reveal buttons, and kept the final transparent eye-button background styling that was adjusted manually in `web_src/css/user.css`.
 
-134 - [2026-05-09 23:58:22] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - Ignored the local frontend hash artifact.
+134 - [2026-05-09 23:58:22] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - [build-artifacts] Ignored the local frontend hash artifact.
 - 1 - I added `/.frontend.hash` to `.gitignore` so local frontend rebuild hash churn no longer appears in the repository working tree.
 - 2 - I removed `.frontend.hash` from Git tracking with `git rm --cached`, so the ignore rule now fully suppresses future local hash churn instead of only affecting newly untracked copies.
 
-135 - [2026-05-10 00:06:54] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - Unified the persistent appearance toggles into a single settings group.
+135 - [2026-05-10 00:06:54] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - [user-settings] [appearance] Unified the persistent appearance toggles into a single settings group.
 - 1 - I merged the top navigation bar, side menus, and footer persistence controls in `templates/user/settings/appearance.tmpl` into one shared `Persistent layout` section with a single Save button.
 - 2 - I added `UpdatePersistentLayout` in `routers/web/user/setting/profile.go` and routed `/user/settings/appearance/layout` to save all three preferences in one request while preserving the footer cookie update.
 - 3 - I added the `settings.persistent_layout` and `settings.persistent_layout_desc` locale strings and finalized the section markup so the shared description sits in its own `.field` container and each per-option help paragraph is separated with a `<br>` after the checkbox row.
 
-136 - [2026-05-10 18:40:36] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - Added column-wide Select all controls to the organization team-units permissions table.
+136 - [2026-05-10 18:40:36] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - [org-ui] [permissions-table] Added column-wide Select all controls to the organization team-units permissions table.
 - 1 - I extended `templates/org/team/new.tmpl` so the team-units permissions table in `org/<team_name>/teams/new` gets the same header-level Select row used by the Actions permissions table, with `All` radios for none, read, and write.
 - 2 - I extended `web_src/js/features/org-team.ts` to synchronize those header radios bidirectionally with the per-unit permission rows, while correctly ignoring globally disabled read/write cells when applying or computing a column-wide selection.
 
-137 - [2026-05-10 19:02:14] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - Added the password visibility toggle to the SMTP password field on the install page.
+137 - [2026-05-10 19:02:14] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - [installer] [password-ui] Added the password visibility toggle to the SMTP password field on the install page.
 - 1 - I wrapped the `smtp_passwd` input in `templates/install.tmpl` with the same `js-password-toggle-group` used by login and signup, reusing the existing password-visibility initializer and show/hide labels so the install-page SMTP password field gets the same eye toggle behavior.
 
-138 - [2026-05-10 19:08:32] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - Enabled install-page email notifications by default for fresh setups.
+138 - [2026-05-10 19:08:32] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - [mailer] [installer] Enabled install-page email notifications by default for fresh setups.
 - 1 - I updated `routers/install/install.go` so the install form defaults `mail_notify` to enabled when there is no existing mailer configuration and notify-mail was still unset, while preserving an explicit existing configuration during reinstall/edit scenarios.
 
-139 - [2026-05-10 19:15:41] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - Added the password visibility toggle and confirm-password behavior to the install-page super-admin password fields.
+139 - [2026-05-10 19:15:41] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - [installer] [password-ui] Added the password visibility toggle and confirm-password behavior to the install-page super-admin password fields.
 - 1 - I wrapped the install-page `admin_passwd` field in the same `js-password-toggle-group` used by signup and login, so the super-admin password now gets the same eye toggle UI and manual-entry reveal behavior.
 - 2 - I wired the install-page `admin_confirm_passwd` field into the existing confirm-password flow, so revealing the admin password hides the confirm field and keeps it synchronized just like the signup form.
 - 3 - I refined `web_src/js/features/password-visibility.ts` so confirm-field synchronization is opt-in per toggle group via explicit selectors, preventing the install-page SMTP password toggle from accidentally targeting the super-admin confirm field in the same form.
 - 4 - I adjusted `web_src/css/install.css` so install-page password fields that use the overlaid eye wrapper keep the same 60% inline-field width as the original plain inputs instead of shrinking or stretching when the wrapper is present.
 
-140 - [2026-05-10 19:22:04] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - Added the password visibility toggle to the install-page database password field.
+140 - [2026-05-10 19:22:04] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - [installer] [password-ui] Added the password visibility toggle to the install-page database password field.
 - 1 - I wrapped `db_passwd` in `templates/install.tmpl` with the same `js-password-toggle-group` used by the other install-page password fields, so the database password now gets the same eye control without changing its inline width or reusing any confirm-password logic.
 
-141 - [2026-05-10 19:27:48] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - Added the password visibility toggle and confirm-password behavior to `/user/settings/account`.
+141 - [2026-05-10 19:27:48] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - [user-settings] [password-ui] Added the password visibility toggle and confirm-password behavior to `/user/settings/account`.
 - 1 - I wrapped the `settings.new_password` field in `templates/user/settings/account.tmpl` with the shared `js-password-toggle-group`, reusing the existing eye-toggle logic and show/hide labels.
 - 2 - I wired the `settings.retype_new_password` field into the existing confirm-password flow through dedicated selectors, so revealing the new password hides the confirm field and keeps it synchronized the same way as signup and the install-page super-admin password form.
 
-142 - [2026-05-10 19:43:11] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - Added optional custom branding uploads to the install page.
+142 - [2026-05-10 19:43:11] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - [installer] [branding] Added optional custom branding uploads to the install page.
 - 1 - I finalized the installer `Branding` section with optional uploads for `logo.svg`, `logo.png`, `loading.png`, `favicon.svg`, and `favicon.png`, including clear format/size guidance plus a shared-assets checkbox for using one SVG and one PNG upload for both logo and favicon.
 - 2 - I implemented backend validation and persistence for all branding uploads in `routers/install/install.go` (expected type checks, 1 MB limit, square PNG with minimum 64x64) and save accepted overrides under `custom/public/assets/img/`.
 - 3 - I completed the runtime behavior so uploaded branding files override built-in assets through layered serving, `logo.svg` is mirrored to `gitea.svg` for legacy lookups, post-install progress prefers a custom `loading.png`, and the shared-assets mode hides favicon fields while relabeling logo fields to `Logo & Favicon SVG/PNG`.
 - 4 - I manually updated Romanian locale wording for the final branding texts and labels.
 
-143 - [2026-05-12 00:02:10] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - Finalized Register behavior for admin-created notification accounts without altering the invitation flow.
+143 - [2026-05-12 00:02:10] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - [auth] [signup] [admin-created-user] [locale] [en] [ro] Finalized Register behavior for admin-created notification accounts without altering the invitation flow.
 - 1 - I extended `POST /user/sign_up` in `routers/web/auth/auth.go` for existing active local accounts created by an admin when `username` and `email` match, while explicitly leaving pending admin invitations on their existing flow.
 - 2 - If password is correct, the user is now authenticated into that existing account; when `MustChangePassword` is enabled, the flow redirects directly to `/user/settings/change_password`, otherwise it follows the normal post-auth redirect.
 - 3 - If password is incorrect, the flow now redirects to `/user/forgot_password?email=<email>` and shows a warning to use account recovery plus check Spam/Junk.
 - 4 - I added the locale key `auth.admin_notify_recover_password_spam_hint` in both `options/locale/locale_en-US.json` and `options/locale/locale_ro-RO.json`.
 - 5 - I added regression tests in `routers/web/auth/auth_test.go` for normal sign-in, forced change-password redirect, wrong-password recovery redirect, and a guard that the admin-invitation flow still redirects to `/user/invitation`.
 
-144 - [2026-05-12 00:47:20] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - Added the password visibility toggle to `/user/settings/change_password`.
+144 - [2026-05-12 00:47:20] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - [user-settings] [password-ui] Added the password visibility toggle to `/user/settings/change_password`.
 - 1 - I wrapped the forced-change password field in `templates/user/auth/change_passwd_inner.tmpl` with the shared `js-password-toggle-group`, reusing the existing eye-toggle logic and show/hide labels.
 - 2 - I wired the confirm-password field into the existing toggle sync behavior so revealing the new password hides the confirm field and keeps it synchronized like the other password-update forms.
 
-145 - [2026-05-12 01:16:50] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - Added installer support for importing an existing `app.ini`.
+145 - [2026-05-12 01:16:50] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - [installer] [app-ini-import] [locale] [en] [ro] Added installer support for importing an existing `app.ini`.
 - 1 - I added an `Import Existing Configuration` section at the top of `templates/install.tmpl` with an `app.ini` upload control that imports automatically as soon as a file is selected, without a separate `Load app.ini` button.
 - 2 - I kept the dedicated installer route `POST /import_app_ini` in `routers/install/routes.go`, but the page now posts to it via `fetch` and applies the imported values back into the existing form with `DOMParser`, so the browser is not visibly navigated to `/import_app_ini` and the page scripts are not re-executed.
 - 3 - In `routers/install/install.go`, I factored the installer defaults into reusable helpers, added `app.ini` upload parsing with size/error handling, and mapped the imported config into the existing install form fields for database, general server paths, mailer, registration, OpenID, security, and admin policy settings.
 - 4 - I added installer locale strings in both `options/locale/locale_en-US.json` and `options/locale/locale_ro-RO.json` for the new import UI, success message, and import errors, and the success flash now auto-dismisses after 5 seconds both on initial page load and after the AJAX import injects a new flash message.
 - 5 - I added regression coverage in `routers/install/routes_test.go` for the new upload control and the config-to-form mapping behavior.
 
-146 - [2026-05-12 01:30:10] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - Enabled shared branding assets by default in the installer.
+146 - [2026-05-12 01:30:10] - v1.27.0-dev-125-g1525c9c8ee - Type: Modified - [installer] [branding] Enabled shared branding assets by default in the installer.
 - 1 - I updated `routers/install/install.go` so `BrandingUseSharedAssets` starts as enabled on the install form, making `Use the same logo files for favicon assets` checked by default.
 
-147 - [2026-05-12 01:43:10] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - Added optional sensitive-secret import for installer `app.ini` uploads.
+147 - [2026-05-12 01:43:10] - v1.27.0-dev-125-g1525c9c8ee - Type: Added - [installer] [app-ini-import] [secrets] Added optional sensitive-secret import for installer `app.ini` uploads.
 - 1 - I added an explicit installer checkbox for importing sensitive secrets from `app.ini` in `templates/install.tmpl`.
 - 2 - I extended the installer form, submit pipeline, and final config writer so the optional import reuses `LFS_JWT_SECRET`, `INTERNAL_TOKEN`, and `oauth2.JWT_SECRET` from the uploaded `app.ini` instead of generating new values, including a submit-time fallback that re-reads the uploaded file if the checkbox was enabled after the first auto-import.
 - 3 - I finalized secret resolution for both direct values and `LFS_JWT_SECRET_URI` / `INTERNAL_TOKEN_URI` / `JWT_SECRET_URI` file-based references, and added regression coverage for direct imports, URI-based imports, the real `POST /import_app_ini` flow, and the persisted `app.ini` output.
 
-148 - [2026-05-12 22:44:38] - v1.27.0-dev-143-g512e577c3f - Type: Added - Finalized the safe upstream update helper script as `.update-gitea.sh`.
+148 - [2026-05-12 22:44:38] - v1.27.0-dev-143-g512e577c3f - Type: Added - [scripts] [repo-sync] [rollback] Finalized the safe upstream update helper script as `.update-gitea.sh`.
 - 1 - I renamed the updater to `.update-gitea.sh`, documented its purpose and ordered usage steps, including the explicit "dry-run has conflicts" path before any real sync, and added an interactive menu plus direct commands for `sync`, `dry-run`, `fetch`, `backup`, `status`, `list-backups`, `rollback`, `restore-stash`, `restore-snapshot`, and `clean-dry-run`.
 - 2 - I hardened real update actions so they verify repository state, create or offer safety backup branches, retain the original pre-sync stash for rollback, and record the active restore metadata inside `.git`.
 - 3 - I added exact worktree snapshots under `.git/.update-gitea-snapshots`, showed the latest/saved snapshot paths in `status`, and made `rollback` plus `restore-snapshot` restore the saved starting commit, the original local changes, and the exact worktree contents including untracked and ignored files while preserving a fresh safety snapshot of the state being replaced.
 - 4 - I implemented a reusable dry-run workspace under `.git/.update-gitea-dry-run`, added cleanup for both that workspace and legacy temporary dry-run directories, and made dry-run collect and report all detected rebase conflict steps without modifying the real repository.
 - 5 - I improved conflict reporting so package.json conflicts show the upstream scripts block, the conflicting commit side, and the current branch working-tree side, and the final dry-run summary now includes the total conflict-step count, the local commits that conflicted, and the unique conflicted files.
 
-149 - [2026-05-13 00:05:18] - v1.27.0-dev-143-g512e577c3f - Type: Added - Added a dedicated safe upstream import helper based on `cherry-pick`.
+149 - [2026-05-13 00:05:18] - v1.27.0-dev-143-g512e577c3f - Type: Added - [scripts] [repo-sync] [cherry-pick] Added a dedicated safe upstream import helper based on `cherry-pick`.
 - 1 - I added [`.import-upstream-cherry-pick.sh`](/config/workspace/gitea-dev/gitea/.import-upstream-cherry-pick.sh) as a separate helper that fetches upstream, lists importable upstream-only commits, and imports either selected commits or an inclusive upstream range through `git cherry-pick -x` so the imported commits keep a visible reference to the original upstream hashes.
 - 2 - I gave the script the same safety model as the updater flow by creating a fresh backup branch, an exact worktree snapshot, and a saved tracked/untracked stash before every real import action, while recording the active restore metadata in `.git/.import-upstream-cherry-pick-state`.
 - 3 - I added safe recovery commands for `continue`, `rollback`, `restore-stash`, and `restore-snapshot`, so interrupted or unwanted imports can be resumed or reverted back to the saved starting commit and exact worktree state, including untracked and ignored files.
 - 4 - I added both command-line usage and an interactive menu for fetch, list, import, import-range, continue, backup, rollback, restore, and status workflows.
 
-150 - [2026-05-13 00:18:42] - v1.27.0-dev-143-g512e577c3f - Type: Added - Added an interactive custom-release maintenance helper for stable patch lines.
+150 - [2026-05-13 00:18:42] - v1.27.0-dev-143-g512e577c3f - Type: Added - [scripts] [custom-release] [interactive] Added an interactive custom-release maintenance helper for stable patch lines.
 - 1 - I added [`.maintain-custom-release.sh`](/config/workspace/gitea-dev/gitea/.maintain-custom-release.sh) to maintain a persistent custom branch such as `release/v1.26-custom`, starting from a base tag like `v1.26.0-rc0`, importing the missing upstream commits from the real upstream minor release branch such as `release/v1.26`, and then importing only the custom commits from a chosen local source branch.
 - 2 - I made the helper interactive with a menu plus a guided `configure` step, so the base tag, upstream release branch, maintenance branch, custom source branch, upstream compare branch, and custom tag suffix can all be adjusted from prompts instead of only through environment variables, and I added automatic fallback from mistyped patch-style branch names like `release/v1.26.0` to the real upstream branch `release/v1.26` when it exists.
 - 3 - I gave the script the same safety model as the other local Git helpers by creating a fresh backup branch, an exact worktree snapshot, and a saved tracked/untracked stash before every real import action, while also storing pending cherry-pick state so interrupted sequences can be continued.
 - 4 - I added recovery commands for `continue`, `rollback`, `restore-stash`, and `restore-snapshot`, and a `tag` command that creates annotated custom release tags such as `v1.26.0-custom` on the maintained custom release branch.
 
-151 - [2026-05-13 00:34:10] - v1.27.0-dev-143-g512e577c3f - Type: Modified - Narrowed local upstream fetch scope and cleaned unused upstream tracking refs.
+151 - [2026-05-13 00:34:10] - v1.27.0-dev-143-g512e577c3f - Type: Modified - [scripts] [repo-sync] [fetch] Narrowed local upstream fetch scope and cleaned unused upstream tracking refs.
 - 1 - I updated [`.update-gitea.sh`](/config/workspace/gitea-dev/gitea/.update-gitea.sh) and [`.import-upstream-cherry-pick.sh`](/config/workspace/gitea-dev/gitea/.import-upstream-cherry-pick.sh) so they fetch only the explicitly requested upstream branch instead of all upstream branches.
 - 2 - I updated [`.maintain-custom-release.sh`](/config/workspace/gitea-dev/gitea/.maintain-custom-release.sh) so it fetches only the configured upstream release branch, the configured compare branch, and tags, while also normalizing mistaken patch-style release branch names like `release/v1.26.0` to the real upstream branch `release/v1.26`.
 - 3 - I narrowed the local `remote.upstream.fetch` refspec to `upstream/main` and `upstream/release/v1.26`, then removed the other local `upstream/*` remote-tracking refs so Git Graph no longer shows the unused upstream branches by default.
 
-152 - [2026-05-13 20:23:40] - v1.27.0-dev-143-g512e577c3f - Type: Modified - Extended the custom-release maintenance helper with manual restore points and corrected its fetch and interactive configuration behavior.
+152 - [2026-05-13 20:23:40] - v1.27.0-dev-143-g512e577c3f - Type: Modified - [scripts] [custom-release] [restore-points] Extended the custom-release maintenance helper with manual restore points and corrected its fetch and interactive configuration behavior.
 - 1 - I updated [`.maintain-custom-release.sh`](/config/workspace/gitea-dev/gitea/.maintain-custom-release.sh) so it no longer auto-fetches upstream tags during release-branch synchronization, preventing patch tags like `v1.26.1` from being pulled in just because the release branch history was fetched.
 - 2 - I added manual restore-point management commands for `create-restore-point`, `list-restore-points`, `restore-point`, and `delete-restore-point`, each backed by an exact worktree snapshot plus an associated backup branch stored under `.git/.maintain-custom-release-restore-points`.
 - 3 - I integrated the new restore-point workflow into the interactive menu, the `help` text, and `status`, including support for restoring by full path or by the final restore-point directory name, automatically using the latest restore point for the current branch when no target is provided, recognizing the older manual restore points already stored under `.git/.manual-restore-points`, and fixing the interactive configuration prompts so they are shown correctly during `Edit configuration`.
 
-153 - [2026-05-13 21:51:32] - v1.27.0-dev-143-g512e577c3f - Type: Modified - Finalized the custom-release maintenance helper workflow and recovery behavior.
+153 - [2026-05-13 21:51:32] - v1.27.0-dev-143-g512e577c3f - Type: Modified - [scripts] [custom-release] [rollback] Finalized the custom-release maintenance helper workflow and recovery behavior.
 - 1 - I made `bootstrap` a clean branch-creation step from `BASE_TAG`, separated fetch and sync into explicit compare/release-target/custom actions, added `UPSTREAM_RELEASE_TARGET_REF`, and updated the built-in help so the recommended workflow matches the current menu structure.
 - 2 - I hardened recovery so rollback, restore-point, restore-snapshot, restore-stash, and restore-deletion correctly preserve or clean script-managed refs, maintenance branches, state files, backup branches, and snapshots, including rollback from the original entry branch after a bootstrap-created maintenance branch, cleanup of legacy restore-point leftovers, and removal of the correctly paired `backup/maint-*` Git Graph marker when a saved snapshot is deleted.
 - 3 - I finalized the interactive UX by keeping a self-updating runtime copy in `/tmp`, persisting the last-used settings in `/tmp/.maintain-custom-release.env`, and reorganizing the menu into `Manual Backups >`, `Fetch upstreams >`, `Sync >`, `Rollback >`, and `Restore >` submenus, including `Delete Restore >` with numbered stash and snapshot selection, with numbered selections, `b`/`B` or `Enter` for Back, correct return-to-parent behavior from every submenu, and `0` for Exit.
+
+154 - [2026-05-18 17:33:14] - v1.27.0-dev-165-gee30675569 - Type: Modified - [docs] [changelog] [github-links] Converted remaining bare pull-request references in `CHANGELOG.md` and `CHANGELOG-archived.md` to explicit GitHub links.
+- 1 - I updated `CHANGELOG.md` and `CHANGELOG-archived.md` so bare changelog references of the form `#123` now use explicit Markdown links to `https://github.com/go-gitea/gitea/pull/123`, while preserving the existing local changelog edits already present in the working tree.

.codex-project-map.md

@@ -4,7 +4,18 @@ This file is the persistent implementation map for fast project orientation.
 
 Use it after `./.codex-context.md` when a task needs architecture, flow, or extension-point context.
 
-## 1. Repository Map
+## 1. Fast Entry Points Index
+
+- auth -> `routers/web/auth/`, `templates/user/auth/`, `services/auth/`
+- installer -> `routers/install/`, `templates/install.tmpl`, `options/locale/`
+- user settings UI -> `routers/web/user/setting/`, `templates/user/settings/`, `web_src/js/features/`, `web_src/css/modules/`
+- sticky menus / persistent layout UI -> `templates/*/navbar*.tmpl`, `web_src/css/modules/menu.css`, `web_src/css/modules/flexcontainer.css`, `web_src/js/features/common-page.ts`
+- repo settings / actions UI -> `routers/web/repo/`, `templates/repo/`, `templates/repo/settings/`
+- admin UI -> `routers/web/admin/`, `templates/admin/`
+- mail / notifications -> `services/mailer/`, `templates/mail/`, `routers/web/admin/`, `routers/web/auth/`
+- custom release maintenance and repo-sync helpers -> `./.maintain-custom-release.sh`, `./.update-gitea.sh`, `./.import-upstream-cherry-pick.sh`, `./.codex-script-notes.md`
+
+## 2. Repository Map
 
 - Executable entry point: `main.go`
 - CLI lifecycle and command startup: `cmd/`
@@ -18,7 +29,7 @@ Use it after `./.codex-context.md` when a task needs architecture, flow, or exte
 - Server-side templates: `templates/`
 - Browser-side frontend: `web_src/`
 
-## 2. Bootstrap and Request Flow
+## 3. Bootstrap and Request Flow
 
 ### 2.1 Application Bootstrap
 
@@ -84,7 +95,7 @@ Use it after `./.codex-context.md` when a task needs architecture, flow, or exte
 - API:
   - JSON or file responses through helpers in `services/context/`
 
-## 3. Authentication Map
+## 4. Authentication Map
 
 ### 3.1 Where Auth Routes Live
 
@@ -190,7 +201,7 @@ Auth routes are mainly declared in `routers/web/web.go`, especially around:
   - `routers/web/auth/oauth2_provider.go`
   - `services/oauth2_provider/...`
 
-## 4. Change Entry Points
+## 5. Change Entry Points
 
 ### 4.1 New Web Route
 
@@ -269,7 +280,7 @@ Auth routes are mainly declared in `routers/web/web.go`, especially around:
   - support often spans `models/`, `services/`, and `modules/setting/`
   - `templates/admin/`
 
-## 5. Frequent Task Shortcuts
+## 6. Frequent Task Shortcuts
 
 - Login / signup / account recovery:
   - `routers/web/auth/`
@@ -302,7 +313,7 @@ Auth routes are mainly declared in `routers/web/web.go`, especially around:
   - `services/actions/`
   - `models/actions/`
 
-## 6. Technology and Validation Notes
+## 7. Technology and Validation Notes
 
 - Backend: Go
 - Server-side rendering: Go `.tmpl` templates

.codex-script-notes.md

@@ -0,0 +1,62 @@
+# Codex Script Notes
+
+This file is a fast-reference companion for the large local helper scripts.
+
+## `.maintain-custom-release.sh`
+
+Purpose:
+- maintain a custom stable branch such as `release/v1.26-custom`
+- start from `BASE_TAG`
+- fetch and sync upstream compare / release-target refs explicitly
+- cherry-pick selected custom work from a local source branch
+
+Current interaction model:
+- interactive menu with submenus:
+  - `Manual Backups >`
+  - `Fetch upstreams >`
+  - `Sync >`
+  - `Rollback >`
+  - `Restore >`
+- submenu navigation:
+  - `Enter` or `b` / `B` => Back
+  - `0` => Exit
+
+Persistent runtime state:
+- runtime copy: `/tmp/.maintain-custom-release.sh`
+- persisted settings: `/tmp/.maintain-custom-release.env`
+- restore points: `.git/.maintain-custom-release-restore-points/`
+- snapshots: `.git/.maintain-custom-release-snapshots/`
+- active state file: `.git/.maintain-custom-release-state`
+
+Recommended order:
+1. `Bootstrap maintenance branch`
+2. `Fetch upstream/main compare ref`
+3. `Fetch upstream release target ref`
+4. `Show import plan`
+5. `Sync` actions as needed
+
+Important behavior:
+- `bootstrap` should only create/switch the maintenance branch from `BASE_TAG`; it should not fetch automatically
+- `rollback` should remove bootstrap-created maintenance branches and clean script-managed refs/artifacts
+- deleting a saved exact snapshot should also remove its paired `backup/maint-*` Git Graph marker
+
+## `.update-gitea.sh`
+
+Purpose:
+- safe upstream sync helper for the working tree
+- create safety backups before real sync actions
+- provide `dry-run`, `rollback`, `restore-stash`, and `restore-snapshot`
+
+Key safety expectations:
+- `dry-run` must not modify the real repository
+- real sync actions must preserve enough state for exact rollback
+
+## `.import-upstream-cherry-pick.sh`
+
+Purpose:
+- import upstream commits through `git cherry-pick -x`
+- support commit-by-commit or range-based import
+
+Key safety expectations:
+- save backup branch, snapshot, and stash before real import actions
+- support `continue`, `rollback`, `restore-stash`, and `restore-snapshot`

.frontend.hash

@@ -1 +0,0 @@
-34a58393847d8354e1a401512d0e56138e53bcae

AGENTS.md

@@ -16,6 +16,7 @@
 
 - DO NOT read full files unless they are explicitly targeted with `@filename`, referenced from instruction `*.md` files, or required to complete the user's task.
 - Assume the workspace structure described in `./.codex-context.md` and `./.codex-project-map.md` is the current baseline unless the user indicates otherwise.
+- DO NOT read `./.codex-history.md` end-to-end by default; search by keyword, subsystem, tag, or read only the latest relevant entries first.
 
 ## Project Context