@www.hyperlinks.space/program-kit 1.2.181818 → 7.8.3

package/research & docs/auth-and-centralized-encrypted-keys-plan.md

@@ -0,0 +1,440 @@
+# Auth + Centralized Encrypted Keys Plan (Supabase)
+
+This document defines a practical implementation plan for:
+
+- Multi-provider login: **Google**, **Telegram**, **GitHub**, and **email + protection code (OTP)**
+- Centralized storage in **Supabase**
+- Wallet secrets stored as **encrypted blobs only** (no plaintext mnemonic/private keys server-side)
+
+---
+
+## 1) Product Goal
+
+Enable users to sign in from multiple platforms and recover wallet access from Supabase by using account credentials plus a user-held decryption secret model.
+
+## 2) Security Goal
+
+- Supabase/backend stores only ciphertext envelopes and metadata.
+- Decryption happens client-side.
+- Server does not receive plaintext mnemonic/private keys.
+
+---
+
+## 3) Trust Model Decision
+
+To avoid custodial key handling by backend, choose one of these decryption models:
+
+1. **Password-derived key model (recommended for centralized sync)**
+   - User sets a wallet passphrase.
+   - Client derives key with Argon2id.
+   - Ciphertext stored in Supabase.
+2. **Device-key model only**
+   - Better local UX, weaker cross-device recovery unless mnemonic re-entry is required.
+
+For this plan, use model (1) as canonical centralized recovery path.
+
+---
+
+## 3.1) What "wrapped decrypt key" means (plain language)
+
+This phrase means we do not store the real decryption key directly in the database.
+
+- **DEK (Data Encryption Key):** key that encrypts wallet secret/mnemonic.
+- **KEK (Key Encryption Key):** key that encrypts ("wraps") the DEK.
+
+So database stores:
+- wallet ciphertext (encrypted by DEK)
+- wrapped DEK (encrypted by KEK)
+
+Database does **not** store:
+- plaintext mnemonic
+- plaintext DEK
+- plaintext KEK
+
+### Why KMS/HSM is mentioned
+
+`KEK` should live in a managed key system (AWS KMS, GCP KMS, Azure Key Vault HSM, etc.), not in app code or DB columns.
+
+When app needs decrypt flow:
+1. User authenticates (Google/Telegram/GitHub/email OTP).
+2. Backend loads `wrapped_dek` + wallet `ciphertext` from DB.
+3. Backend asks KMS/HSM to unwrap DEK (or returns a short-lived tokenized decrypt result, depending on policy).
+4. Decrypt happens in the chosen boundary (client-side or controlled backend flow).
+
+### Tiny analogy
+
+- Wallet data = document in locked box (ciphertext).
+- DEK = key to that box.
+- KEK = key to a safe that contains the DEK.
+- KMS/HSM = guarded safe room.
+
+This way, stealing only DB rows is not enough to decrypt user wallets.
+
+---
+
+## 3.2) Newbie note: "But ciphertext and wrapped key are in the same DB"
+
+This is a common concern and the short answer is:
+
+- Yes, they can be stored in the same row.
+- No, that does not automatically break security.
+
+### Why this can still be safe
+
+Think of three pieces:
+
+1. `ciphertext` (locked wallet data)
+2. `wrapped_dek` (the key to the lock, but itself locked)
+3. `kek` in KMS/HSM (the key that unlocks `wrapped_dek`)
+
+If attacker steals DB only, they get (1) and (2), but not (3).
+Without (3), they cannot recover plaintext keys.
+
+### What actually protects the system
+
+The real protection is **access control to KMS/HSM**, not hiding DB relations.
+
+- Keep KEK outside DB.
+- Restrict KMS permissions to minimum required service path.
+- Audit and rate-limit unwrap operations.
+
+### Optional extra hardening
+
+You can split storage across two databases (ciphertext in one, wrapped key in another), but this is additional defense-in-depth. It does not replace KMS/HSM boundary.
+
+Rule of thumb for beginners:
+**Do not rely on "they cannot match rows"; rely on "they cannot access KEK".**
+
+---
+
+## 3.3) How user session works with KEK (Google/Telegram/GitHub/email OTP)
+
+Important: user login session is an **authorization signal**, not the KEK itself.
+
+- Google/Telegram/GitHub/email OTP proves "this user is authenticated".
+- Backend then decides whether to allow key unwrap path.
+- KEK remains in KMS/HSM and is never replaced by OAuth/session token.
+
+Typical flow:
+
+1. User logs in and gets a valid app session.
+2. App requests wallet unlock/decrypt operation.
+3. Backend verifies session + policy checks (device/risk/rate limits).
+4. Backend reads `wrapped_dek + ciphertext` from DB.
+5. Backend calls KMS/HSM to unwrap DEK.
+6. Decrypt/sign path continues under selected trust boundary.
+
+This is why people say "session gates KEK usage", not "session is KEK".
+
+### Two deployment variants
+
+- **Variant A (more custodial):**
+  - Backend unwraps DEK and performs decrypt/sign server-side.
+  - User gets signed result/tx hash.
+- **Variant B (hybrid):**
+  - Backend authorizes and returns short-lived decrypt material/session token.
+  - Client resolves/decrypts locally for signing.
+
+Choose Variant A only if you explicitly accept custodial responsibility.
+
+---
+
+## 3.4) Why keep both `wrapped_dek` and `ciphertext` in DB (not one encrypted entity)
+
+You can think "why not one giant blob encrypted by KEK directly?".
+Short answer: envelope encryption with separate DEK is safer and more operationally practical.
+
+Reasons:
+
+1. **KMS/HSM usage limits and performance**
+   - KMS is best for wrapping small keys, not encrypting large/high-volume payloads repeatedly.
+   - DEK handles data encryption efficiently.
+
+2. **Key rotation without re-encrypting all wallet data**
+   - Rotate KEK by re-wrapping DEKs.
+   - No need to decrypt/re-encrypt every wallet ciphertext each time KEK rotates.
+
+3. **Cryptographic separation of duties**
+   - DEK protects wallet payload.
+   - KEK protects DEK.
+   - Cleaner blast-radius control and auditing.
+
+4. **Metadata and versioning flexibility**
+   - You can evolve ciphertext formats (AEAD params/version) independently from KEK lifecycle.
+
+5. **Standard industry pattern**
+   - This is standard "envelope encryption" used by major cloud security systems.
+
+So storing both `ciphertext` and `wrapped_dek` is expected architecture, not duplication.
+
+---
+
+## 3.5) KMS/HSM section: what it is and how to operate it
+
+## What is KMS?
+
+**KMS (Key Management Service)** is a managed service that stores and uses cryptographic master keys with strict access controls, logging, and rotation features.
+
+Examples:
+- AWS KMS
+- Google Cloud KMS
+- Azure Key Vault (with HSM-backed options)
+
+## What is HSM?
+
+**HSM (Hardware Security Module)** is specialized hardware designed to keep key material protected and perform crypto operations with strong tamper resistance.
+
+In practice:
+- Many cloud KMS offerings can use HSM-backed keys.
+- Teams usually start with managed KMS and move to stricter HSM policies if required by risk/compliance.
+
+## Why use KMS/HSM here
+
+- Keep `KEK` out of application DB and source code.
+- Centralize key policy and access control.
+- Get immutable audit logs for unwrap/encrypt/decrypt operations.
+- Support controlled key rotation and key disable/emergency revoke.
+
+## How to deal with it (practical checklist)
+
+1. **Create KEK in KMS/HSM**
+   - Mark as non-exportable when available.
+   - Separate key per environment (`dev/stage/prod`).
+
+2. **Restrict IAM permissions**
+   - App service can only call required operations (typically `Decrypt/Unwrap`, maybe `Encrypt/Wrap`).
+   - No broad admin access from runtime services.
+
+3. **Use envelope encryption pattern**
+   - Generate DEK for wallet payload encryption.
+   - Store `ciphertext + wrapped_dek` in DB.
+   - Never store plaintext KEK/DEK at rest.
+
+4. **Add policy checks before unwrap**
+   - Require valid session and account state.
+   - Apply risk checks (IP/device anomalies, rate limits, cooldowns).
+   - Log every sensitive operation.
+
+5. **Implement rotation**
+   - Rotate KEK on schedule.
+   - Re-wrap DEKs in background jobs.
+   - Keep key version metadata in DB.
+
+6. **Prepare incident controls**
+   - Ability to disable key version quickly.
+   - Emergency freeze for high-risk accounts.
+   - Recovery runbook for key compromise scenarios.
+
+## Common mistakes to avoid
+
+- Putting KEK plaintext in `.env` and calling it "KMS-ready".
+- Giving app runtime full KMS admin permissions.
+- Missing unwrap rate limits and anomaly detection.
+- No audit review pipeline for key operations.
+- Designing without key-rotation path from day one.
+
+## Newbie rule
+
+If DB is stolen, attacker should still need **separate KMS/HSM access** to decrypt anything.
+If DB theft alone can decrypt wallets, architecture is wrong.
+
+---
+
+## 4) Authentication Architecture
+
+Use **Supabase Auth** as identity layer:
+
+- Google OAuth
+- GitHub OAuth
+- Email + protection code (OTP / magic code)
+- Telegram login bridge (custom verifier service; link to Supabase user)
+
+### Identity Linking
+
+A single user can link multiple auth methods to one account.
+
+- Primary identity key: `user_id` (Supabase Auth UUID)
+- Linked providers table stores provider identifiers (`google_sub`, `github_id`, `telegram_id`, etc.)
+
+---
+
+## 5) Wallet Encryption Envelope
+
+Store one or more encrypted wallet envelopes per user.
+
+### Envelope format (server-stored)
+
+- `ciphertext` (base64)
+- `nonce/iv`
+- `kdf` params:
+  - `algorithm = argon2id`
+  - `salt`
+  - `memory_kib`
+  - `iterations`
+  - `parallelism`
+  - `dk_len`
+- `aead`:
+  - `algorithm = aes-256-gcm` (or xchacha20-poly1305)
+  - optional `aad`
+- `version`
+- `created_at`, `updated_at`
+
+### Crypto rules
+
+- KDF and encryption run **client-side only**.
+- Never send passphrase to server.
+- Never log secrets/ciphertext in verbose logs.
+
+---
+
+## 6) Supabase Data Model
+
+## `profiles`
+- `id` (uuid, fk -> auth.users.id)
+- `username` (nullable unique)
+- `display_name`
+- `created_at`
+
+## `auth_identities`
+- `id` (uuid)
+- `user_id` (uuid)
+- `provider` (`google|github|telegram|email_otp`)
+- `provider_subject` (string)
+- unique (`provider`, `provider_subject`)
+
+## `wallet_envelopes`
+- `id` (uuid)
+- `user_id` (uuid)
+- `wallet_label`
+- `ciphertext`
+- `kdf_json`
+- `aead_json`
+- `envelope_version`
+- `is_active`
+- timestamps
+
+## `security_events`
+- `id`, `user_id`
+- `event_type`
+- `ip_hash`, `ua_hash`
+- timestamps
+
+---
+
+## 7) Authorization and RLS
+
+Enable Row Level Security:
+
+- user can read/write only rows where `user_id = auth.uid()`.
+- admin/service role separated for backend-only tasks.
+- strict policies for envelope update/delete.
+
+Add rate limits and abuse controls at API edge:
+
+- login attempt throttling
+- envelope fetch/update throttling
+- device/IP anomaly checks
+
+---
+
+## 8) Provider-Specific Notes
+
+## Google / GitHub
+- Use Supabase OAuth providers.
+- Standard callback + session issuance.
+
+## Email + Protection Code (OTP)
+- Use Supabase OTP flow (`signInWithOtp`) with short code expiry.
+- Rate-limit OTP requests and verify attempts.
+- Add anti-abuse checks (per-IP/per-email cooldown).
+- Optional: require email verification before provider linking actions.
+
+## Telegram
+- Verify Telegram login payload (`id_token`/signed data) in backend function.
+- On success, link Telegram identity to existing `user_id` or create new profile.
+- Telegram auth is identity only, not decryption secret.
+
+---
+
+## 9) Client Flows
+
+## Registration
+1. User signs up via any provider.
+2. App prompts wallet passphrase setup (if no envelope exists).
+3. Client generates/imports mnemonic.
+4. Client encrypts mnemonic -> envelope.
+5. Upload envelope to Supabase.
+
+## Login on new device
+1. User authenticates via provider.
+2. App fetches envelope from Supabase.
+3. User enters wallet passphrase.
+4. Client decrypts locally and unlocks wallet.
+
+## Passphrase change
+1. Unlock with current passphrase.
+2. Re-encrypt with new Argon2id salt/params.
+3. Replace envelope atomically.
+
+## Email protection-code recovery
+1. User requests login code by email.
+2. Enters code and gets authenticated session.
+3. If wallet envelope exists, user enters wallet passphrase to decrypt.
+4. If passphrase is forgotten, user must recover with mnemonic and set a new passphrase.
+
+---
+
+## 10) Operational Security Requirements
+
+- CSP hardening and dependency pinning for web/TMA.
+- Secrets scanning and signed CI artifacts.
+- Audit trail for sensitive actions.
+- Incident playbook for account takeover and suspicious activity.
+- User alerts (new login, passphrase changed, provider linked/unlinked).
+- User alerts (new OTP login, passphrase changed, provider linked/unlinked).
+
+---
+
+## 11) Migration Plan (from current model)
+
+1. Keep existing TMA SecureStorage/DeviceStorage path active.
+2. Add optional centralized envelope creation for users.
+3. Backfill on next successful unlock/sign event.
+4. After adoption, use centralized envelope as cross-device recovery path.
+5. Maintain mnemonic-first emergency recovery.
+
+---
+
+## 12) Scope, Non-goals, and Warnings
+
+Non-goals:
+- Backend plaintext key custody
+- Signing in backend with user mnemonic/private key
+
+Warnings:
+- If user forgets both mnemonic and passphrase, recovery is impossible by design.
+- Centralized ciphertext still increases account-takeover pressure; defense must focus on OTP hardening, rate limits, and alerts.
+
+---
+
+## 13) Phase Breakdown
+
+## Phase A: Identity foundation
+- Configure Supabase Auth providers.
+- Add account linking UX.
+- Add RLS and identity tables.
+
+## Phase B: Envelope crypto
+- Implement client Argon2id + AEAD module.
+- Add `wallet_envelopes` APIs and tests.
+
+## Phase C: Recovery UX
+- New device unlock flow.
+- Passphrase reset/re-encrypt flow.
+
+## Phase D: Hardening
+- Abuse controls, telemetry, alerts, and audits.
+
+## Phase E: Rollout
+- Feature flags, gradual rollout, and migration metrics.
+

package/research & docs/github-gitlab-bidirectional-mirroring.md

@@ -0,0 +1,154 @@
+# GitHub and GitLab Repository Mirroring
+
+This document describes how to keep a Git repository synchronized between GitHub and GitLab, including **bidirectional** setups, the problems that appear in practice, **automation guards** that reduce loops and wasted work, and **automatic escalation** when the automation must not guess (for example, divergent histories).
+
+It is guidance for operators and automation authors; it is not specific to application code in this repository.
+
+## Terminology
+
+- **Canonical remote:** The single place where humans are expected to push day-to-day changes (or where merge commits land after review). Everything else is a **mirror**.
+- **One-way mirror:** After a push to A, automation updates B. Humans do not push to B for the same branches (or B is protected so only the mirror bot can push).
+- **Bidirectional mirror:** Automation tries to propagate pushes from A→B and B→A. This is workable only with strict guards and a clear policy when histories **diverge**.
+- **Escalate:** Stop silent auto-fix; surface the condition to people or ticketing (failed job, alert, issue). See [Automatic escalation](#automatic-escalation).
+
+## Recommended default: one canonical remote + one-way mirror
+
+For most teams, the lowest-risk approach is:
+
+1. Choose **one** platform as the source of truth for each protected branch (usually `main`).
+2. Mirror to the other platform with **fast-forward-only** pushes and **short-circuit** when tips already match.
+
+Typical implementations (pick **one** row: canonical host is where humans push; the arrow is where commits are **copied** next):
+
+| Canonical | Replication direction | How |
+|---|---|---|
+| **GitHub** | GitHub → GitLab | GitHub Actions on `push`: fetch GitLab, compare SHAs, `git push` to GitLab using a [GitLab deploy key](https://docs.gitlab.com/ee/user/project/deploy_keys/) or [project access token](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html). |
+| **GitLab** | GitHub ← GitLab | [GitLab repository push mirroring](https://docs.gitlab.com/ee/user/project/repository/mirror/) so GitLab pushes to GitHub after receiving commits. |
+
+The two directions are **not** used together for the same branch in this pattern: they are **alternatives** depending on which platform is source of truth. (Using both at once without guards is how bidirectional mirroring starts.)
+
+Official overview: [GitLab repository mirroring](https://docs.gitlab.com/ee/user/project/repository/mirror/), [GitHub Actions push trigger](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#push).
+
+This gives **near-instant** propagation from the moment the canonical host accepts the push, without fighting bidirectional edge cases.
+
+## Bidirectional mirroring: when it is used and what breaks
+
+Bidirectional setups appear when both platforms must accept pushes (different teams, migration, or CI only on one side). They are **not** “set and forget.”
+
+| Risk | What goes wrong | Why it matters |
+|---|---|---|
+| **Loop / ping-pong** | A push to GitHub triggers sync to GitLab; GitLab triggers sync back to GitHub; repeat or duplicate work | Duplicate CI, wasted API calls, flaky pipelines |
+| **New objects from automation** | Mirror job merges, rebases, or force-pushes to “fix” state | New commits or rewritten history; harder audits; can feed loops |
+| **Divergence** | Two different commits on `main` at each host, neither is ancestor of the other | `git push` rejects (non-fast-forward) unless someone force-pushes |
+| **Duplicate CI** | Same tree built twice because both hosts run pipelines on the same logical change | Cost and noise; confusing status checks |
+| **Credential exposure** | Tokens in logs, overly broad PATs, shared user accounts | Security and compliance issues |
+
+## Guards in automation (layered)
+
+Use several of these together; one guard rarely covers every failure mode.
+
+### 1. Event and scheduling guards
+
+- **SHA equality short-circuit:** After fetching both remotes, if `github/main` and `gitlab/main` are the **same commit OID**, exit successfully without pushing.
+- **Ancestor / fast-forward check before push:** Only push from A to B if B’s tip is an **ancestor** of A’s tip (pure fast-forward). If not, do not force-push; treat as divergence and [escalate](#automatic-escalation).
+- **Mirror bot identity:** Perform mirror pushes with a **dedicated** bot user or deploy key. On the receiving side, webhook or pipeline logic can **skip enqueuing reverse sync** when the actor matches the mirror bot (where the platform exposes this).
+- **Idempotency:** Persist “last mirrored OID per branch” (CI cache, KV, issue comment, etc.) and skip if the incoming event’s `after` SHA was already mirrored.
+- **Debounce / concurrency:** One in-flight sync per branch (GitHub Actions `concurrency`, GitLab `resource_group`, or a lock) to avoid stacked identical jobs from webhook retries.
+
+### 2. Git protocol guards
+
+- **No `--force` on mirrored branches** unless you have an explicit, rare break-glass procedure. Non-fast-forward should **fail** and escalate.
+- **Narrow refspecs:** Mirror only agreed branches (for example `refs/heads/main`, `refs/heads/release/*`), not all refs.
+- **Atomic multi-ref push** when supported (`git push --atomic`) to avoid half-updated mirror state.
+
+### 3. Loop-specific logic
+
+- **Directional rule:** GitHub→GitLab runs only when GitHub is strictly ahead of GitLab (fast-forward). GitLab→GitHub runs only when GitLab is strictly ahead. If **both** are ahead of the common ancestor (diverged), **neither** direction should force-sync; escalate.
+- **Cooldown:** If the same `(branch, OID)` was mirrored within N seconds, exit (reduces double webhook storms).
+
+### 4. CI noise controls
+
+Mirroring duplicates pipelines if both hosts run on every push.
+
+- Prefer **one** platform for **required** checks; treat the other as informational or limit runs (for example scheduled smoke only).
+- Where policy allows, use host-specific **skip directives** for mirror-only pushes (conventions vary; confirm org rules).
+- **Path filters** help only when mirror commits change nothing meaningful; usually both sides see the same files.
+
+### 5. Security guards
+
+- **Least privilege:** Repo-scoped tokens or deploy keys; no org-wide admin tokens for mirroring.
+- **Branch protection** on both sides: block force-push to mirrored branches; restrict who may push to protected branches.
+- **Secrets hygiene:** Mask remotes in logs; disable interactive prompts (`GIT_TERMINAL_PROMPT=0`); store credentials only in CI secrets.
+
+## Automatic escalation
+
+**Escalate** means: the automation **detects a condition it must not resolve alone**, marks the run as failed or blocked, and **notifies** or **files a ticket** with enough context for a human to decide.
+
+This is the opposite of silently force-pushing or auto-merging without policy.
+
+### When to escalate automatically
+
+Typical conditions:
+
+- **Divergence:** `main` on GitHub and GitLab point to different commits and neither is an ancestor of the other (merge-base exists but both tips have unique commits).
+- **Non-fast-forward push rejected:** Mirror push fails with non-FF; do not retry with force.
+- **Repeated failures:** Same branch fails N times in a row (may indicate permission, quota, or hook problems).
+- **Unexpected ref state:** Missing branch, empty repo, or OID mismatch after push (verify step fails).
+
+### What “automatic escalation” can do (concrete patterns)
+
+Implement one or more of the following from the same job that detected the problem:
+
+1. **Fail the pipeline** with a clear title and non-zero exit code so the default branch protection and dashboards show breakage.
+2. **Post a structured comment** on a pinned tracking issue (GitHub Issues / GitLab issue) including: branch name, both OIDs, link to the failed pipeline, and a one-line `git` hint (`git merge-base`, `git log --left-right`) for the on-call engineer.
+3. **Send chat or email** via webhook (Slack incoming webhook, Microsoft Teams, email SMTP API) with the same summary fields.
+4. **Open a new issue** (if API token allows) with label `mirror-divergence` so work is tracked and deduplicated (search for open issues with the same branch before creating).
+5. **Set a repository flag** (for example GitHub Actions variable or GitLab CI variable via API) `MIRROR_HALTED=true` and have sync jobs check it at the start so you do not amplify divergence while humans fix it.
+
+### Content to include in escalation messages
+
+- Repository identifiers (both URLs or slugs).
+- Branch (or ref) name.
+- **OID on side A** and **OID on side B** (full hashes avoid ambiguity).
+- **Pipeline run URL** and job name.
+- Short **runbook pointer** (internal doc link) for “how we pick canonical history” and “who may force-push if ever.”
+
+### After humans resolve divergence
+
+Runbook should require:
+
+1. Agreement on which tip (or merged result) is correct.
+2. A single deliberate push to the **canonical** remote (or fast-forward merge on one side then sync).
+3. Clear `MIRROR_HALTED` reset and verification that both tips match before re-enabling bidirectional automation.
+
+## Implementation sketches (non-prescriptive)
+
+### GitHub Actions (push to GitLab)
+
+- Trigger: `on: push` for selected branches.
+- Steps: clone with depth sufficient for ancestry check (or full clone for simplicity), add GitLab remote with token in secret, `fetch` GitLab, compare OIDs / ancestry, `git push` only on fast-forward.
+- On divergence or push failure: exit 1 and call a small script that opens an issue or posts to Slack.
+
+### GitLab push mirror to GitHub
+
+- Configure in GitLab project settings; use a GitHub **fine-grained PAT** or deploy key with write access to the target repo.
+- Complement with **branch protection** on GitHub and monitoring for mirror errors in GitLab.
+
+### Webhook-driven bidirectional
+
+- Each side receives push webhooks; each handler runs the same **guarded** sync script (SHA short-circuit, bot skip, fast-forward only, escalate on divergence).
+- **Do not** run two independent scripts that both force-push without shared policy.
+
+## Summary
+
+- **Best default:** one canonical remote, **one-way** mirror with fast-forward-only pushes and OID short-circuit.
+- **Bidirectional** is possible with **layered guards** (ancestor checks, bot identity, concurrency, no force).
+- **Escalate automatically** on divergence and non-FF: fail visibly, notify, optionally open issues and halt further sync until humans reconcile.
+
+## References
+
+- [GitLab: Repository mirroring](https://docs.gitlab.com/ee/user/project/repository/mirror/)
+- [GitHub Actions: Workflow triggers](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows)
+- [GitLab: Deploy keys](https://docs.gitlab.com/ee/user/project/deploy_keys/)
+- [GitLab: Project access tokens](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html)
+- [GitHub: Fine-grained personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token)