Improve temporary mailbox, languages, and interface design

.agents/skills/build-mail-interface/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: build-mail-interface
+description: Use when implementing an agreed cloud-mail UI design in Vue, Element Plus, and SCSS while preserving mailbox behavior, localization, accessibility, and responsive layouts.
+---
+
+# Build the mail interface
+
+Implement a defined screen or visual system in the existing Vue app. Read `map-mail-experience` for a new flow or `shape-mail-design-system` for new visual rules only when that part of the design is unresolved.
+
+## Before editing
+
+- For whole-interface work, read the current accepted experience and visual design before editing. For a bounded page change, read the relevant part. Trace the route, view, shared component, store, request, permission check, and translation keys. Keep mail behavior separate from presentation changes.
+- Record the current states and actions in scope, including public attachment download, local archive, full-message reading, language switching, and installability where present.
+- Identify shared components or tokens before adding one-off page styles.
+
+## Implementation rules
+
+- Use semantic buttons, links, inputs, headings, lists, and dialog behavior. All icon-only actions need an accessible name, visible focus, and a keyboard path.
+- Keep the primary action and recovery state clear at phone width. Support long labels, right-to-left Arabic, and left-to-right email addresses/codes.
+- Add user-facing strings through the existing localization system for every selectable language. Keep placeholders and meaning aligned; validate generated translations and identify any component-level fallback honestly.
+- Represent loading, empty, error, offline, and locally saved data distinctly when the flow can reach them.
+- Preserve permission checks and the public mailbox's address-only access model. Do not add automatic local cleanup; respect existing attachment cache limits and browser storage failure states.
+- Follow existing data and security boundaries for message HTML, attachments, and authentication. Do not weaken them to achieve a visual effect.
+
+## Verification
+
+Run the smallest relevant tests and production build. Exercise the changed flow in a real browser at phone and desktop widths, with keyboard navigation, both themes where applicable, and at least one long-text locale plus Arabic. Verify any touched modal closes and returns focus appropriately. Resolve console errors and overflow before marking the implementation ready. Report what was checked and what remains uncertain.

.agents/skills/map-mail-experience/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: map-mail-experience
+description: Use when planning or restructuring the cloud-mail UI journeys, page hierarchy, navigation, screen states, or task flows across the public mailbox, signed-in mail, and administration.
+---
+
+# Map the mail experience
+
+Turn a UI request into a screen and state specification that another designer or engineer can implement. Base decisions on the current routes, permissions, data states, and rendered pages.
+
+## Scope
+
+- Map the public mailbox at `/find`, sign-in and registration at `/login`, signed-in mail, composition, settings, and administration when they are part of the request.
+- Identify the primary task on each screen, its entry point, next action, and recovery path.
+- Specify navigation, information priority, responsive behavior, and state changes. Leave colors, type styles, and component styling to `shape-mail-design-system`; leave code changes to `build-mail-interface`.
+
+## Product invariants
+
+- The public mailbox can be opened with an address alone. Do not describe it as private to the current device or require an account or secret.
+- A public message must expose its full body and available attachment actions. The app does not automatically clear local history. Attachment caching has 10 MiB per-file and 100 MiB total binary limits, and browser storage can be removed by site-data clearing or storage pressure.
+- Online mail availability and locally saved content are distinct states. Make the source and limitations understandable without hiding either.
+- Language follows the browser by default and can be changed manually. Plan for every selectable language, long labels, and right-to-left scripts; keep addresses and codes left-to-right.
+- Signed-in actions respect existing permissions. Do not put an unavailable action in the primary path.
+
+## Method
+
+1. Read the relevant Vue route, view, store, and translation keys; inspect the rendered screen at desktop and phone width.
+2. Write a task map for a first-time visitor, a returning public-mail visitor, a signed-in user, and an administrator only where those roles are in scope.
+3. For each screen, name the primary action, secondary actions, hierarchy, and navigation back to a safe state.
+4. Cover loading, empty, error, offline, long-content, attachment, and permission states. Include confirmation and focus destination for destructive actions.
+5. Check the specification against the existing API and local archive behavior. Mark genuinely new behavior separately from a presentation change.
+
+## Deliverable
+
+Provide a compact screen matrix with columns for route, user goal, primary action, supporting information, states, and phone priority. Add a flow sketch for any multistep task. Record decisions that affect copy or translation keys. A screen is ready for visual design when its main action and every recovery state are unambiguous.
+
+For example, the public mailbox flow should trace: create or enter address → wait for or retrieve mail → open full message → preview or download attachment → return to inbox; also trace offline access to saved mail and manual clearing.

.agents/skills/review-mail-interface/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: review-mail-interface
+description: Use when auditing or accepting cloud-mail UI changes for visual consistency, task completion, accessibility, responsive behavior, localization, and regressions.
+---
+
+# Review the mail interface
+
+Review the rendered product independently of the implementation author. Read the requested design and the relevant routes first; use code to explain findings, not as a substitute for observing the interface.
+
+## Coverage
+
+- Public mailbox: create or enter address, receive/list mail, open full content, copy code, preview/download attachment, use saved mail offline, switch address, and manually clear local history.
+- Signed-in mail: navigate accounts/folders, compose, read, reply/forward, manage attachments, and access settings within the user's permissions.
+- Administration: inspect dense tables, filters, forms, confirmation, error recovery, and restricted actions when those screens changed.
+- Shared shell: sign-in, navigation, theme, language selector, install action, notifications, and dialogs.
+
+## Matrix
+
+Use representative 320/375 px phones, a 768 px tablet, and a 1440 px desktop. Check both themes where supported. Check Simplified Chinese, English, a long-label language such as German or Russian, and representative Arabic, Devanagari, CJK, Cyrillic, and Southeast Asian scripts. Sample newly added languages across every writing direction, and check language search, browser matching, and generated translation placeholders. Include empty, loading, network error, stale/local, long subject/address, and multiple-attachment states.
+
+## Observe
+
+- Can a person identify and finish the primary task without guessing? Are error and offline states distinct from an empty inbox?
+- Is every action reachable by keyboard, named for assistive technology, and visibly focused? Do dialogs receive focus, retain it, close with Escape where appropriate, and return it to the opener?
+- Do text, controls, status indicators, and disabled states remain understandable at the tested sizes and themes? Is there horizontal overflow or clipped translated copy?
+- Does the UI accurately describe address-only public access and device-local saved mail? Do attachment and clear actions behave as labeled?
+- Are console errors, broken assets, and regressions absent in the changed paths?
+
+## Report
+
+For each finding, give severity, route/state/viewport/locale, reproduction steps, observed versus expected behavior, and a screenshot or code location when available. Separate verified behavior from assumptions. End with a short release recommendation and any untested risk. Do not create a new visual direction during acceptance review.

.agents/skills/shape-mail-design-system/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: shape-mail-design-system
+description: Use when defining or revising cloud-mail's visual direction, design tokens, components, light and dark themes, density, responsive layout, or right-to-left presentation.
+---
+
+# Shape the mail design system
+
+Create a coherent visual language for the public mailbox, sign-in, signed-in mail, and administration. Use the screen priorities from `map-mail-experience` when the task changes page structure.
+
+## Decisions to make
+
+- If direction is open, show three structurally different directions with a short rationale and recommend one. Vary layout and information rhythm as well as color.
+- Define shared foundations: type scale, content widths, spacing, color roles, surface layers, borders, focus rings, radii, icon weight, and motion. Give the public and signed-in entry points a recognizable relationship while respecting their different tasks.
+- Specify reusable states for buttons, fields, language controls, navigation, mail rows, message reading, attachments, dialogs, empty/error/offline notices, and data tables.
+- Define light and dark token values; do not rely on a dark background or color alone to communicate state.
+- Document behavior at 320, 375, 768, 1024, and 1440 px, with long German/Russian text and Arabic right-to-left layout. Email addresses and verification codes stay readable left-to-right.
+
+## Project anchors
+
+Inspect `mail-vue/src/style.css`, `/find`, `/login`, `layout`, and Element Plus overrides before proposing tokens. The current public mailbox uses a dark focused layout while the signed-in app uses a dark sidebar with a lighter workspace. Treat those as design inputs, not mandatory final styling.
+
+## Quality bar
+
+- Main actions stand out from secondary utilities through placement, label, and contrast.
+- Normal text, control boundaries, and focus indicators remain legible in both themes. Keyboard focus is visible; reduced-motion settings are honored.
+- Dense mail lists scan quickly; destructive controls stay distinct and require clear confirmation.
+- Avoid decorative cards, shadows, gradients, or animation that obscure mailbox content.
+- Prefer semantic tokens over isolated hex values. Define how tokens map to Element Plus variables and page-specific styles.
+
+## Deliverable
+
+Provide a visual direction statement, a token table, component-state examples, and desktop/phone compositions for the key screens. Explain any intentional difference between the public and signed-in experiences. Include acceptance checks for contrast, keyboard focus, text expansion, right-to-left order, and both themes. Implementation belongs to `build-mail-interface`.

.github/workflows/deploy-cloudflare.yml

@@ -18,7 +18,8 @@ jobs:
       CUSTOM_DOMAIN: ${{ secrets.CUSTOM_DOMAIN || vars.CUSTOM_DOMAIN }}
       DOMAIN: ${{ secrets.DOMAIN || vars.DOMAIN }}
       ADMIN: ${{ secrets.ADMIN || vars.ADMIN }}
-      JWT_SECRET: ${{ secrets.JWT_SECRET || vars.JWT_SECRET }}
+      JWT_SECRET: ${{ secrets.JWT_SECRET }}
+      INIT_SECRET: ${{ secrets.INIT_SECRET }}
       CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN || vars.CLOUDFLARE_API_TOKEN }}
       CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID || vars.CLOUDFLARE_ACCOUNT_ID }}
       D1_DATABASE_ID: ${{ secrets.D1_DATABASE_ID || vars.D1_DATABASE_ID }}
@@ -58,6 +59,10 @@ jobs:
         working-directory: ./mail-worker
         run: pnpm wrangler telemetry disable
 
+      - name: ✅ 验证邮件访问边界 / Verify mailbox access boundaries
+        working-directory: ./mail-worker
+        run: pnpm test
+
       - name: 🛠️ 设置环境 / Set up environment
         working-directory: ./mail-worker
         run: |
@@ -119,7 +124,6 @@ jobs:
           sed -i "s|\${CUSTOM_DOMAIN}|${CUSTOM_DOMAIN}|g" "$CONFIG_FILE"
           sed -i "s|\"\${DOMAIN}\"|${DOMAIN}|g" "$CONFIG_FILE"
           sed -i "s|\${ADMIN}|${ADMIN}|g" "$CONFIG_FILE"
-          sed -i "s|\${JWT_SECRET}|${JWT_SECRET}|g" "$CONFIG_FILE"
           sed -i "s|\${R2_BUCKET_NAME}|${R2_BUCKET_NAME}|g" "$CONFIG_FILE"
           sed -i "s|\${PROJECT_LINK}|${PROJECT_LINK}|g" "$CONFIG_FILE"
           sed -i "s|\${ANALYSIS_CACHE}|${ANALYSIS_CACHE}|g" "$CONFIG_FILE"
@@ -211,7 +215,13 @@ jobs:
         working-directory: ./mail-worker
         run: |
           echo "🚀 Starting deployment..."
-          pnpm wrangler deploy -c wrangler-action.toml 2>&1 \
+          umask 077
+          SECRETS_FILE="$RUNNER_TEMP/worker-secrets.env"
+          printf 'jwt_secret=%s\n' "$JWT_SECRET" > "$SECRETS_FILE"
+          if [ -n "$INIT_SECRET" ]; then
+            printf 'init_secret=%s\n' "$INIT_SECRET" >> "$SECRETS_FILE"
+          fi
+          pnpm wrangler deploy -c wrangler-action.toml --secrets-file "$SECRETS_FILE" 2>&1 \
             | tee deploy.log \
             | grep -v "https://.*\.workers\.dev" \
             | sed -E 's/env\.domain .*/env.domain (***)/' \
@@ -221,6 +231,7 @@ jobs:
           if [ $DEPLOY_EXIT_CODE -ne 0 ]; then
             exit 1
           fi
+          rm -f "$SECRETS_FILE"
 
           WORKER_URL=$(grep -o "https://.*\.workers\.dev" deploy.log || echo "")
 
@@ -232,6 +243,7 @@ jobs:
           echo "✅ Setup completed."
 
       - name: ♻️ 初始化数据库 / Initialize database
+        if: env.INIT_SECRET != ''
         run: |
           echo "🛠️ Starting database initialization..."
           sleep 15
@@ -244,7 +256,7 @@ jobs:
             exit 1
           fi
 
-          HTTP_CODE=$(curl -sL -w "%{http_code}" -o response.txt "$WORKER_URL/api/init/${JWT_SECRET}")
+          HTTP_CODE=$(curl -sSL -X POST -H "X-Init-Key: $INIT_SECRET" -w "%{http_code}" -o response.txt "$WORKER_URL/api/init")
           RESPONSE_BODY=$(cat response.txt)
 
           if [ "$RESPONSE_BODY" = "success" ]; then
@@ -253,10 +265,3 @@ jobs:
             echo "❌ Failed. HTTP: $HTTP_CODE, Response: $RESPONSE_BODY"
             exit 1
           fi
-
-      - name: 🗑️ 删除运行记录 / Delete workflow runs
-        uses: GitRML/delete-workflow-runs@main
-        continue-on-error: true
-        with:
-          retain_days: '1'
-          keep_minimum_runs: '0'

.github/workflows/verify.yml

@@ -0,0 +1,48 @@
+name: Verify mail application
+
+on:
+  pull_request:
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  verify:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: pnpm/action-setup@v4.1.0
+        with:
+          version: 11
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '24'
+          cache: pnpm
+          cache-dependency-path: |
+            mail-vue/pnpm-lock.yaml
+            mail-worker/pnpm-lock.yaml
+      - name: Install application dependencies
+        run: pnpm install --frozen-lockfile
+        working-directory: mail-vue
+      - name: Install server dependencies
+        run: pnpm install --frozen-lockfile
+        working-directory: mail-worker
+      - name: Verify application and languages
+        run: pnpm test && pnpm run check:manifests
+        working-directory: mail-vue
+      - name: Verify server and language responses
+        run: pnpm test
+        working-directory: mail-worker
+      - name: Build application
+        run: pnpm run build
+        working-directory: mail-vue
+      - name: Prepare browser checks
+        run: pnpm exec playwright install --with-deps chromium
+        working-directory: mail-vue
+      - name: Verify mail entry points and recovery
+        run: pnpm run check:mail-flows
+        working-directory: mail-vue
+      - name: Validate deployment bundle
+        run: pnpm exec wrangler deploy --dry-run
+        working-directory: mail-worker