菜单
The Atelier Auth Law — production-hardened session architecture (rotating refresh tokens, families, grace window, silent refresh, sliding window) plus the anti-patterns that corrupt auth. Load before designing or touching ANY authentication code.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Atelier's native asset tools — image→webp compression, video→webp frame sequences, scrollytelling scaffolding, and AI video generation (Gemini Omni Flash / Veo 3.1) with a graceful no-credentials fallback. Load when handling images, video, storytelling sections, or media generation.
Turn any component site, asset library, or API into something agents can use — a registry entry, a skill, or a full MCP server. Load when the user says "add this site/library to Atelier" or wants to contribute a new integration.
The Atelier operating loop — understand → clarify → plan → execute → review → compare-vs-done-state. Governs when to stop, when to ask, which model tier runs each phase, and when to think deep or compact. Load for ANY nontrivial task.
The thinking protocol — load FIRST on every prompt, before any other skill. Makes any model (Opus, Sonnet, Haiku) reason like a principal engineer - decisive answers, root-cause debugging, security reflexes, outcome-first communication. This is step 0 of the loop.
The design-truth gateway — resolves which design files are authoritative right now (core law + self-learning overlays). Run at the START of any UI/design task, before reading the design law.
The Atelier Clean Code Law — 250-word-per-file budget, DRY via the graph, ponytail minimalism, and the comment policy. Load before writing or refactoring any source code.
| name | auth-law |
| description | The Atelier Auth Law — production-hardened session architecture (rotating refresh tokens, families, grace window, silent refresh, sliding window) plus the anti-patterns that corrupt auth. Load before designing or touching ANY authentication code. |
Distilled from a production system that was broken repeatedly by well-meaning "improvements" and then hardened. If you are about to "improve" auth, your improvement is probably in the anti-pattern list. A genuinely logged-in user must NEVER be bounced to login by normal use.
| Thing | Lifetime | Storage |
|---|---|---|
| Access JWT | 15 min | JS-readable cookie; Authorization: Bearer |
| Refresh token | 30 days, single-use, rotates | HttpOnly cookie + SHA-256 hash in DB |
| Session | 30 days | DB row (truth) + cache |
| expires_at / user cookies | 30 days | JS-readable (schedule timer / routing); not credentials |
Cookie domain .yourdomain.com when multiple subdomains share one session
(central "accounts.*" auth, Google-style) — chosen at intake vs per-app auth.
Every refresh consumes the token and issues a new one. All tokens from one
login share a token_family_id. A rotated-away token presented outside the
60-second grace window = assumed theft → revoke the family. Inside the
window → return the already-issued successor (absorbs tab races). The grace
window is load-bearing; the single-flight mutex is the real fix.
Golden rule: ONE refresh in flight per app. Every trigger (one-shot timer ~2min before expiry, 401 recovery, tab focus, layout mount) funnels through a single module-level in-flight promise/mutex.
Password (+ optional TOTP 2FA before tokens) · OAuth via state-cookie + JSON
callback into user_identities · Passkeys/WebAuthn in user_passkeys ·
Turnstile/captcha on public forms. Never a parallel session mechanism.
Every login/refresh writes an activity log (device, IP) — Google-style
auditable sessions; owner console can list + revoke sessions per user.
