القائمة
Add or modify a captcha mode (digits, picture-pick, etc.) — atomic image render + DB row + sendPhoto + restrictChatMember; deterministic per challenge_id.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Bump the patch version in server/Cargo.toml or website/package.json after completing a major change. Use when the user asks to bump/release a version, or when CLAUDE.md's rule about version bumps after major changes applies.
Before a non-trivial change, list affected systems — DB schema, API contract, Telegram handlers, jobs, TS types, docs. Catch ripple effects upfront, not after CI fails. Use when planning a feature, migration, refactor, or any cross-module touch.
Self-review before push — read the diff as a reader, scan for vixen footguns (token leaks, PII, idempotency, captcha asset overwrites), run validation pipeline, no surprise files. Use before "git push", before opening a PR, or when the user says "ready to commit".
Write a git commit message for vixen-rs following the project's Conventional Commits convention. Use when the user asks to commit, create a commit, or write a commit message.
Reproduce → bisect → root cause → fix → verify. Don't speculate, don't "add more error handling" as a guess. Use when something is broken, when a test fails intermittently, when the user says "this isn't working" or "investigate why".
Write small, fast, reproducible Dockerfiles for the vixen-rs server (Rust) and website (bun) using multi-stage builds, cache mounts, distroless/alpine runtime images, and non-root users. Use when editing server/Dockerfile, website/Dockerfile, docker-compose.yml, or when the user asks to shrink an image or speed up a Docker build.
| name | captcha-pipeline |
| description | Add or modify a captcha mode (digits, picture-pick, etc.) — atomic image render + DB row + sendPhoto + restrictChatMember; deterministic per challenge_id. |
Read first:
seed = xxh3_64(challenge_id). Same challenge_id → same solution → same image.image + ab_glyph from assets in server/assets/captcha/. Run inside tokio::task::spawn_blocking — CPU-bound.INSERT INTO captcha_challenges (chat_id, user_id, challenge_id, solution, asset_version, expires_at, attempts_left).bot.send_photo(...) with inline keyboard, then bot.restrict_chat_member(...) with until_date = now + ttl.SELECT ... FOR UPDATE the challenge → verify → DELETE row → INSERT verified_users → lift restriction via bot.restrict_chat_member with full perms.Render twice with the same challenge_id and assert byte equality. Required for the deterministic-render test suite.
server/src/services/captcha_service.rs — solution gen + render.server/src/telegram/handlers/captcha.rs — issue + callback solve.server/tests/captcha_determinism.rs — byte-equality test.server/docs/captcha.md — mode table.server/assets/captcha/ are immutable. Never overwrite an existing TTF/PNG. New look = new file with version suffix (DejaVuSans-v2.ttf) + bumped asset_version selector.until_date for restrict_chat_member must be ≥ 30s in the future (or 0 for permanent in some contexts) — Telegram silently treats values too close to "now" as permanent.attempts_left decrement uses SELECT ... FOR UPDATE. Without the row lock, two concurrent CallbackQueries from a tap-spam can both see attempts_left = 1 and both decrement.kick, not ban. Kicked users can rejoin and try again; banned users can't, which is the wrong UX for a failed captcha.spawn_blocking. Don't render on the runtime's I/O threads.i64 in the schema (chat_id BIGINT, user_id BIGINT).cargo test captcha.cargo sqlx prepare --check./verify in dev chat, solve, re-issue with same input → identical image bytes.add-migration — captcha_challenges schema additions.add-telegram-handler — CallbackQuery answer-within-30s rule.transaction-discipline — SELECT ... FOR UPDATE patterns.