# Track 03 — Workflows (SOP & Best Practices)

> GitHub Account Reinstatement: 10 complete SOPs covering the full lifecycle from suspension discovery through appeal, recovery, migration, and prevention.

## Source Manifest

| source_id | url | bucket | last_checked | author/host | one-line note |
|-----------|-----|--------|--------------|-------------|---------------|
| T03-S001 | https://docs.github.com/en/site-policy/acceptable-use-policies/github-appeal-and-reinstatement | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — appeal & reinstatement policy |
| T03-S002 | https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — trade controls & sanctions |
| T03-S003 | https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/recovering-your-account-if-you-lose-your-2fa-credentials | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — 2FA recovery procedures |
| T03-S004 | https://support.github.com/contact/reinstatement | surrogate_primary | 2026-05-23 | support.github.com | vendor docs (GitHub 一手) — reinstatement appeal form |
| T03-S005 | https://support.github.com/contact/cannot_sign_in | surrogate_primary | 2026-05-23 | support.github.com | vendor docs (GitHub 一手) — cannot sign in contact form |
| T03-S006 | https://docs.github.com/en/site-policy/content-removal-policies/guide-to-submitting-a-dmca-counter-notice | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — DMCA counter-notice guide |
| T03-S007 | https://docs.github.com/en/site-policy/content-removal-policies/dmca-takedown-policy | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — DMCA takedown policy |
| T03-S008 | https://transparencycenter.github.com/appeals/ | surrogate_primary | 2026-05-23 | transparencycenter.github.com | vendor docs (GitHub 一手) — appeal & reinstatement statistics |
| T03-S009 | https://pilot2254.github.io/blog/how-github-suspended-me/ | surrogate_primary | 2026-05-23 | pilot2254.github.io | vendor docs (作者一手) — 40-day suspension case study |
| T03-S010 | https://blog.lyc8503.net/en/post/github-account-suspended/ | surrogate_primary | 2026-05-23 | blog.lyc8503.net | vendor docs (作者一手) — Chinese developer suspension case |
| T03-S011 | https://github.com/orgs/community/discussions/177139 | surrogate_primary | 2026-05-23 | github.com | vendor docs (GitHub 一手) — student reinstatement success story |
| T03-S012 | https://github.blog/news-insights/policy-news-and-insights/advancing-developer-freedom-github-is-fully-available-in-iran/ | surrogate_primary | 2026-05-23 | github.blog | vendor docs (GitHub 一手) — Iran OFAC license announcement |
| T03-S013 | https://docs.github.com/en/repositories/archiving-a-github-repository/backing-up-a-repository | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — official backup guide |
| T03-S014 | https://docs.github.com/en/rest/migrations/orgs | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — Migration API |
| T03-S015 | https://about.gitlab.com/blog/2023/07/11/github-to-gitlab-migration-made-easy/ | surrogate_primary | 2026-05-23 | about.gitlab.com | vendor docs (供应商) — GitHub-to-GitLab migration guide |
| T03-S016 | https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — 2FA configuration guide |
| T03-S017 | https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — passkey management |
| T03-S018 | https://sanctionssearch.ofac.treas.gov/ | verified_primary | 2026-05-23 | ofac.treasury.gov | OFAC SDN List Search tool |
| T03-S019 | https://www.trade.gov/consolidated-screening-list | verified_primary | 2026-05-23 | trade.gov | Consolidated Screening List (CSL) |
| T03-S020 | https://ofac.treasury.gov/sanctions-programs-and-country-information | verified_primary | 2026-05-23 | ofac.treasury.gov | OFAC sanctions programs by country |
| T03-S021 | https://www.federalregister.gov/documents/2022/10/13/2022-22233/publication-of-iranian-transactions-and-sanctions-regulations-web-general-license-d-2 | verified_primary | 2026-05-23 | federalregister.gov | GL D-2 Iran internet communications |
| T03-S022 | https://docs.github.com/en/site-policy/acceptable-use-policies/github-acceptable-use-policies | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — Acceptable Use Policies |
| T03-S023 | https://docs.github.com/en/site-policy/github-terms/github-terms-of-service | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — Terms of Service |
| T03-S024 | https://github.com/orgs/community/discussions/134149 | surrogate_primary | 2026-05-23 | github.com | vendor docs (GitHub 一手) — China VPN Copilot concerns discussion |
| T03-S025 | https://devactivity.com/insights/navigating-github-account-suspensions-your-guide-to-reinstatement/ | surrogate_primary | 2026-05-23 | devactivity.com | vendor docs — suspension reinstatement guide |
| T03-S026 | https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — 2FA recovery methods configuration |
| T03-S027 | https://www.eff.org/document/dmca-counter-notice | surrogate_primary | 2026-05-23 | eff.org | vendor docs (协会) — DMCA counter-notice template |
| T03-S028 | https://github.com/github/dmca | surrogate_primary | 2026-05-23 | github.com | vendor docs (GitHub 一手) — DMCA notices repository |
| T03-S029 | https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/countries-where-sms-authentication-is-supported | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — SMS 2FA country support list |
| T03-S030 | https://docs.github.com/en/migrations | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — migrations documentation hub |
| T03-S031 | https://www.softwareheritage.org/ | surrogate_primary | 2026-05-23 | softwareheritage.org | vendor docs (协会) — universal source code archive |
| T03-S032 | https://developer.mozilla.org/en-US/blog/migrating-from-github-to-gitlab-seamlessly-a-step-by-step-guide/ | surrogate_primary | 2026-05-23 | developer.mozilla.org | vendor docs — GitHub-to-GitLab migration MDN guide |
| T03-S033 | https://github.com/orgs/community/discussions/136618 | surrogate_primary | 2026-05-23 | github.com | vendor docs (GitHub 一手) — suspension without notice discussion |
| T03-S034 | https://dev.to/rentierdigital/github-is-not-your-backup-one-suspended-account-proved-it-this-week-2fb3 | surrogate_primary | 2026-05-23 | dev.to | vendor docs (作者一手) — "GitHub is not your backup" essay |
| T03-S035 | https://docs.github.com/en/site-policy/acceptable-use-policies/github-disrupting-the-experience-of-other-users | surrogate_primary | 2026-05-23 | docs.github.com | vendor docs (GitHub 一手) — disruption policy |

---

## 总览

10 个完整 SOP, 覆盖 GitHub 账号封禁事件的完整生命周期:

| # | SOP 标题 | 适用场景 | 紧急度 |
|---|---------|---------|--------|
| 1 | 封禁发现与快速分诊 | 发现账号异常/无法登录/收到封禁邮件 | 极高 (立即) |
| 2 | 紧急数据抢救 | 封号后抢救代码和元数据; 封号前预防性备份 | 极高 (前 24h) |
| 3 | 封号原因深度诊断 | 快速分诊后深度排查根因, 为申诉备料 | 高 (前 48h) |
| 4 | 申诉信撰写 | 已明确封号原因, 准备正式提交申诉 | 高 (诊断后) |
| 5 | 申诉提交与跟进 | 提交申诉后的等待/催促/升级策略 | 中 (持续) |
| 6 | 制裁误标专项处理 | 因 IP/VPN/地理位置被标记为制裁区用户 | 高 (专项) |
| 7 | 2FA 丢失恢复 | 丢失二次验证设备/恢复码, 无法登录 | 高 (非封禁) |
| 8 | 申诉成功后的恢复操作 | 账号已解封, 检查和修复数据完整性 | 中 (恢复期) |
| 9 | 申诉失败后的迁移 | 申诉被拒或超时, 需迁移到替代平台 | 中 (长期) |
| 10 | 预防性安全加固 | 未被封禁, 主动降低被封风险 | 低 (日常) |

---

### 1. 封禁发现与快速分诊 (Suspension Discovery & Triage)

**入门 SOP**: 
1. 确认症状类型: 登录后看到"Your account has been flagged/suspended"提示 → 记录准确措辞; 或访问 profile 返回 404 → 说明是 suspension; 或收到 GitHub 邮件通知 → 保存完整邮件含 ticket ID [T03-S009] [T03-S022]
2. 判断严重度: suspension (profile 404, 所有 repo 不可访问, OAuth token 失效) > restriction (仍可登录但功能受限, 常见于制裁标记) > flagging (可登录但被标记审查, 可能要求 SMS 验证) [T03-S022] [T03-S002]
3. 快速分类封号原因 — 按邮件或提示中的关键词: "trade controls/sanctions" → 制裁相关 (转 WF6); "two-factor" → 2FA 问题 (转 WF7); "spam/abuse/disruption" → AUP 违规 (转 WF3); "DMCA" → 版权投诉 (转 WF3 DMCA 分支); "security/compromise" → 账号被盗 (转 WF3); 无任何说明 → 未知原因 (转 WF3 全面诊断) [T03-S001] [T03-S022]
4. 评估紧急度: 有重要代码仅存于该 GitHub 账号? → 立即转 WF2 数据抢救; 有正在运行的 CI/CD / GitHub Pages / npm packages? → 记录受影响服务清单; 有合作者需要通知? → 列出优先通知名单 [T03-S009] [T03-S034]
5. 启动计时: 记录封禁发现的确切时间 — 申诉窗口为 6 个月 (约 180 天), 从 GitHub 做出决定之日起算 [T03-S001]

**资深路径**: 跳过症状确认 (有经验直接看 profile 404 vs 限制提示判断); 优化分类流程 (检查最近操作日志、IP 变动、VPN 切换记录可在 5 分钟内锁定原因); 额外: 如果是组织账号, 立即检查组织其他 admin 是否仍有访问权并让其代为备份

**近期变化**: 2024-2025 年 GitHub 封号通知越来越不及时, 多名开发者报告无任何邮件通知直接封号 [T03-S009] [T03-S033]; GitHub 2024 年起全面强制 2FA, 2FA 丢失导致的锁号案例显著增加 [T03-S016]

**失败模式**: (1) 发现封号后立即开新账号 (ban evasion = 永久封禁, 第一大忌) [T03-S022]; (2) 在 Community Discussions 或 Reddit 发帖但不提交正式 ticket (社区无法解封, 浪费时间) [T03-S009] [T03-S011]; (3) 误判 2FA 丢失为封号, 走了申诉流程而非恢复流程 (白等数周); (4) 慌乱中忘记先备份本地已有的 clone (本地 .git 目录含完整历史, 是第一优先资产) [T03-S034]

### 2. 紧急数据抢救 (Emergency Data Rescue)

**入门 SOP**: 
1. 盘点本地已有资产: 扫描本机所有 `git clone` 目录 — 每个 `.git` 文件夹都是完整历史的备份; 检查是否有 CI/CD secrets、环境变量、GitHub Actions workflow 文件的本地副本; 列出所有仅存于 GitHub 上的数据类型 (Issues, PRs, Discussions, Wikis, Releases, GitHub Pages, npm packages) [T03-S013] [T03-S034]
2. 判断封号后的访问能力: suspension 状态下 — 公开 repo 其他人仍可 clone, 私有 repo 完全不可访问, 你自己的 OAuth token 和 SSH key 已失效; restriction 状态下 — 你仍可 clone 自己的公开 repo, 私有 repo 降级为只读 [T03-S002] [T03-S009]
3. 抢救公开仓库: 让信任的朋友或用另一台机器 (非你的 IP) 执行 `git clone --mirror https://github.com/USERNAME/REPO.git` 对所有公开仓库 — mirror 模式保留所有分支、标签和 refs [T03-S013]
4. 请求合作者帮忙: 对于你是唯一 admin 的私有仓库, 如果有 collaborator 仍有访问权, 请他们立即 clone --mirror 并发给你; 对于组织仓库, 联系其他 org admin 操作 [T03-S009]
5. 导出非 Git 数据: 如果你有存活的 Personal Access Token (封号后 token 通常立即失效, 但 restriction 状态下可能仍有效), 立即用 `gh api` 或 REST API 导出: Issues (`gh issue list --json`), PRs, Discussions; 使用 `gh2md` 工具将 issues 导出为 markdown; 导出 GitHub Actions workflow 文件 (这些在 `.github/workflows/` 目录中, 随 repo clone 一起保存) [T03-S013] [T03-S014]
6. 检查 Software Heritage 存档: 访问 https://archive.softwareheritage.org/ 搜索你的仓库 URL — 该平台自动存档公开 GitHub 仓库, 可能有你代码的副本 [T03-S031]
7. 向 GitHub 正式请求数据导出: 在申诉信中明确要求数据导出权, 引用 GDPR (欧盟用户) 或基本数据访问权利; GitHub 即使拒绝解封, 也可能同意提供数据导出 [T03-S001]

**资深路径**: 跳过手动逐个 clone (使用 `ghorg clone USERNAME --token PAT` 批量导出整个用户下所有仓库); 优化非 Git 数据导出 (使用 GitHub Migration API `POST /orgs/{org}/migrations` 一次性导出含 issues/PRs 的完整归档); 额外: 检查 npm registry — 已发布的 npm packages 在账号封禁后可能仍在 npmjs.com 可用, 立即 `npm pack` 下载所有 tarball; 检查 Docker Hub / GitHub Container Registry 镜像是否仍可拉取

**近期变化**: GitHub 2024 年 pilot2254 案例显示: 封号后 GitHub 的自动化系统可能主动删除部分仓库, 即使账号后来解封, 被自动化删除的数据也不一定能恢复 [T03-S009]; "GitHub is not your backup" 成为 2024-2025 社区共识 [T03-S034]

**失败模式**: (1) 以为封号只是暂时的, 不立即抢救, 结果数据被 GitHub 自动化系统清理 [T03-S009]; (2) 用被封账号的 IP 或凭据尝试 clone, 触发额外风控标记; (3) 仅 clone 了 main 分支, 没有用 --mirror, 丢失了其他分支和 tags; (4) 忘记导出 Issues/PRs/Discussions, 这些非 Git 数据没有本地副本; (5) 没有提前设置预防性备份 (见 WF10), 只在出事后才想到备份

### 3. 封号原因深度诊断 (Root Cause Diagnosis)

**入门 SOP**: 
1. 审查 GitHub 通知: 仔细阅读封号邮件/页面提示中的每一个关键词 — "spam" / "abuse" / "trade controls" / "malware" / "impersonation" / "DMCA" / "disruption" / "security" 每个词指向不同原因和不同申诉策略 [T03-S022] [T03-S035]
2. 回溯近 30 天行为: 是否 mass fork 了大量仓库? 是否批量 star 了大量项目? 是否在短时间内创建了大量 Issues/PRs (可能被判定为 spam)? 是否使用了 API 自动化做大量操作 (超过 rate limit)? 是否加入了 "互 star" / "star exchange" 平台? [T03-S022] [T03-S035]
3. 检查 IP/VPN 地理位置: 近期是否使用过 VPN? VPN 出口 IP 是否在制裁区 (克里米亚 / 古巴 / 朝鲜 / 伊朗虽已有 GL D-2 但某些操作仍受限)? GitHub 通过 IP 地址和支付历史判定地理位置, 不基于国籍 [T03-S002]; 中国大陆不是制裁区, 但如果使用了伊朗/俄罗斯出口 IP 的 VPN 则可能被误标 [T03-S024]
4. 确认 2FA 状态: 是否 2FA 设备丢失导致无法登录 (这不是封号而是锁号, 转 WF7)? 是否有未授权的登录尝试触发了安全锁定? 检查绑定邮箱的安全日志 [T03-S003] [T03-S016]
5. OFAC SDN 自查: 访问 https://sanctionssearch.ofac.treas.gov/ 搜索自己的姓名 — 如果你的名字与 SDN 名单上的条目高度相似, 可能是名字误匹配; 同时搜索 https://www.trade.gov/consolidated-screening-list (CSL) 交叉验证 [T03-S018] [T03-S019]
6. DMCA 相关检查: 如果提示 "DMCA", 检查 https://github.com/github/dmca 仓库中是否有针对你仓库的 takedown notice; 确认你的代码是否包含他人版权材料 (即使是 fork 也可能被投诉); 检查是否有人对你提交了虚假 DMCA (可提 counter-notice) [T03-S007] [T03-S028]
7. 第三方集成审计: 是否授权了可疑的 OAuth App 或 GitHub App? 是否使用了 Copilot/第三方解码工具引入了恶意代码? pilot2254 案例中, 仅有 Copilot Chat tokens 的生成记录却触发了安全封号 [T03-S009] [T03-S025]
8. 形成诊断结论: 将发现写成结构化文档 — 最可能原因 / 支撑证据 / 自己的解释, 这份文档直接成为申诉信的核心素材 (转 WF4) [T03-S001]

**资深路径**: 跳过逐项检查 (经验丰富可从封号提示词直接锁定原因); 优化 SDN 自查 (使用 OpenSanctions API 批量查自己及关联人名); 额外: 检查 GitHub Transparency Center 公开数据, 了解当前 GitHub 封号高发原因的统计趋势, 判断自己是否踩中近期严打方向 [T03-S008]

**近期变化**: 2024-2025 年 GitHub 显著加强了反 spam 自动化检测, 多名开发者报告正常使用但被自动化系统误判 [T03-S009] [T03-S033]; GitHub 2024 年起全面强制 2FA, 导致"锁号但误以为封号"的案例激增

**失败模式**: (1) 不做自我诊断直接申诉, 申诉信缺乏针对性, 被驳回概率高; (2) 自查时发现自己确实违规但仍在申诉中否认 (被发现撒谎 = 永封); (3) 忽略 VPN/IP 因素, 明明是制裁误标却按 spam 路径申诉 (错误的策略); (4) 看到"security"关键词就以为是自己被黑, 实际可能是 GitHub 自动化误判 [T03-S009]

### 4. 申诉信撰写 (Appeal Letter Crafting)

**入门 SOP**: 
1. 确定申诉类型: Appeal (我没有违规, 请重新审查) vs Reinstatement (我承认问题, 已改正, 请恢复) — 两者标准完全不同; Appeal 需要证据证明误判, Reinstatement 需要承认违规 + 承诺改正 + 已做的改正措施 [T03-S001]
2. 结构化撰写申诉信 (推荐 5 段结构): 第一段: 自我介绍 + 账号名 + 封号日期 + 申诉类型; 第二段: 账号历史 (注册时间 / 贡献数量 / 参与的重要项目 / 是否是学生或教育用户); 第三段: 针对封号原因的具体回应 (如果是误判 → 提供反驳证据; 如果确实违规 → 承认 + 说明已采取的改正措施); 第四段: 补充证据 (安全日志截图 / ID 证明 / 位置证明 / 代码原创性证明); 第五段: 承诺 + 请求 — 承诺未来合规 + 明确请求恢复访问权 [T03-S001] [T03-S011]
3. 英文撰写要点: 申诉信必须用英文 (GitHub T&S 团队在美国); 语气专业平和 (professional, factual, calm); 避免情绪化、指责或威胁; 句子简短直接 [T03-S001] [T03-S011]
4. 制裁误标的特殊内容 (中国开发者常见): 明确声明"I am located in [城市], China. China (PRC) is not a US-sanctioned country"; 如果使用过 VPN: 解释 VPN 使用的合理原因 (技术需要 / 网络稳定性) + 承诺停用或改用非制裁区 IP; 附上身份证明 (护照/身份证 + 近期公用事业账单或银行对账单证明地址) [T03-S002] [T03-S024]
5. 准备支撑证据附件: 政府签发的身份证件 (带照片 + 当前居住地的证明); selfie (GitHub 部分情况要求自拍与证件对比); 近期的安全日志截图; commit 历史截图 (证明是长期正常用户); 如果涉及 DMCA: 准备原创性证据 (开发过程截图 / 开发时间线 / 原始设计文档) [T03-S001] [T03-S002]
6. 内部审查: 写完后检查 — 是否遗漏了关键事实? 是否有任何不实陈述 (撒谎被发现 = 永封)? 英文语法是否清晰? 是否过长 (控制在 500 词以内, GitHub T&S 每天处理大量 ticket)? [T03-S001] [T03-S009]

**资深路径**: 跳过模板化写法 (直接针对具体封号原因写高度定制的回应); 优化证据准备 (提前准备 GitHub 安全日志、IP 登录历史的结构化表格而非截图); 额外: 如果封号原因涉及合规/法律 (DMCA / 制裁), 考虑让律师审阅申诉信后再提交, 特别是 DMCA counter-notice 含 perjury 声明 [T03-S006] [T03-S027]

**近期变化**: 2024-2025 年成功案例显示: 提供 commit log 证明原创性 + Gmail 安全日志证明账号被盗 是最有效的证据组合 [T03-S011]; GitHub Transparency Center 数据显示大部分合理申诉会被审查, 但审查周期从以前的约 1-3 天延长到约 1-8 周不等 [T03-S008] [T03-S009]

**失败模式**: (1) 在申诉中威胁法律诉讼 ("I will sue GitHub") — 这会让 T&S 团队将案件转交法务而非直接处理, 大幅延长时间; (2) 撒谎或隐瞒已知违规行为 — 被查出 = 永封且无法再申诉; (3) 写过长的情绪化信件 (T&S 每天大量 ticket, 长信反而降低被仔细阅读的概率); (4) 用非注册邮箱发送申诉 (可能无法匹配到你的账号); (5) 抄送大量 GitHub 高管邮箱 (无效且显得不专业)

### 5. 申诉提交与跟进 (Appeal Submission & Follow-up)

**入门 SOP**: 
1. 选择正确的提交渠道: 如果你能登录 → 使用 reinstatement form (https://support.github.com/contact/reinstatement); 如果你无法登录 → 使用 cannot_sign_in form (https://support.github.com/contact/cannot_sign_in); 使用与被封账号绑定的同一邮箱提交, 先退出其他 GitHub 账号 [T03-S004] [T03-S005] [T03-S025]
2. 提交申诉: 填写表单所有必填字段; 在详细描述框粘贴你在 WF4 撰写的申诉信; 附上证据文件; 记录提交时间和获得的 ticket ID (格式通常为 #NNNNNNN) [T03-S001] [T03-S004]
3. 设定等待预期: 首次自动回复通常在数小时内; 人工审查回复 — 快则 1-3 个工作日, 慢则 2-8 周; pilot2254 案例等了 27 天才收到人工回复, 最终 40+ 天才完全解决; 学生案例约 2 个月 [T03-S009] [T03-S011]
4. 跟进策略: 提交后第 7 天无回复 → 在原 ticket 回复一条简短催促 (不开新 ticket); 第 14 天无回复 → 再催一次, 补充任何新发现的证据; 第 21 天无回复 → 在 GitHub Community Discussions 发帖描述情况 (不暴露敏感信息), @GitHubSupport 增加可见度; 第 30 天无回复 → Twitter/X 公开 @github @githubsupport 发帖 (礼貌但坚定, 附 ticket ID) [T03-S009] [T03-S011]
5. 升级路径 (按顺序尝试): 一级: 原 ticket 持续跟进 → 二级: Community Discussions 发帖 → 三级: Twitter/X 公开 @mention → 四级: 尝试 support@github.com / appeals@github.com 邮箱 → 五级: 如果有法律依据 (EU DSA / DMCA counter-notice), 援引法律框架要求回复 → 六级: 联系 EFF / SFC 等组织寻求帮助 (仅限确实涉及权利侵犯的情况) [T03-S001] [T03-S027]
6. 记录所有沟通: 保存每一封来往邮件; 截图每一个交互; 在本地文档中维护时间线 — 这既是证据也是万一需要法律途径时的必要记录 [T03-S009]

**资深路径**: 跳过逐级升级 (如果有 GitHub 内部人脉可直接联系, 但不要绕过正式流程); 优化等待期利用 (等待期间并行执行 WF2 数据抢救 + WF9 迁移准备, 不要干等); 额外: 欧盟用户可援引 DSA 第 20 条要求 out-of-court dispute settlement, 这给 GitHub 增加了合规压力

**近期变化**: 2024-2025 年 GitHub 支持团队响应速度明显下降, 多个社区帖子报告等待数周无回复 [T03-S009] [T03-S033]; Twitter/X 公开发帖仍然是最有效的升级手段之一 [T03-S009]; GitHub Community Discussions 中的回复大量是 AI 生成的模板回复, 不具参考价值 [T03-S009]

**失败模式**: (1) 开多个 ticket 催促 (可能被标记为 spam, 新 ticket 被关闭为 duplicate) [T03-S009]; (2) 在 Community Discussions 发泄情绪而非提供事实 (降低可信度); (3) 仅等待不行动, 错过 6 个月申诉窗口 [T03-S001]; (4) 以为 Twitter 上 @mention 后就能立即解决 (只是增加可见度, 不保证加速); (5) 在公开渠道暴露账号密码、token 或其他敏感信息

### 6. 制裁误标专项处理 (Sanctions Mis-flag Resolution)

**入门 SOP**: 
1. 确认封号确实是制裁相关: 检查封号提示/邮件中是否包含 "trade controls" / "sanctions" / "restricted region" 等关键词; 如果仅提示 "Your account has been flagged" 但无具体原因, 也需排查制裁可能性 (尤其如果你近期使用了 VPN) [T03-S002]
2. 判断你的实际状况: (A) 中国大陆/香港/台湾开发者: 中国 (PRC) 不是美国制裁区, 但使用了伊朗/俄罗斯/克里米亚 IP 出口的 VPN 可能导致被误标 → 属于误判, 可申诉解除; (B) 伊朗开发者: GitHub 已获得 OFAC GL D-2 许可, 可提供全部公开和私有服务 (个人和组织, 免费和付费) → 如果仍被限制, 属于系统未及时更新, 可申诉; (C) 克里米亚/顿涅茨克/卢甘斯克/古巴/朝鲜: 仅允许免费公开仓库和开源项目, 私有仓库和付费服务受限; (D) 俄罗斯/白俄罗斯: 部分服务受限 [T03-S002] [T03-S012] [T03-S021]
3. 准备位置证明文件: 必需: 政府签发的身份证件 (护照 / 身份证 / 驾照) + 自拍照 (与证件对比); 推荐: 近期公用事业账单或银行对账单 (证明当前居住地址); 可选: 雇主证明信 / 大学在读证明 (增强可信度) [T03-S002]
4. VPN 问题说明: 如果使用了 VPN 导致被误标, 在申诉中需要: 说明使用 VPN 的原因 (例如: 访问技术资源 / 网络稳定性需要); 说明 VPN 出口 IP 可能位于制裁区是无意的; 承诺未来使用非制裁区出口 IP 或停用 VPN; 注意: GitHub 政策明确规定"制裁区用户不得使用 IP 代理、VPN 或其他方法掩饰其位置" — 但这针对的是实际位于制裁区的用户, 不在制裁区的用户使用 VPN 本身不违规 (只是可能导致误标) [T03-S002] [T03-S024]
5. 提交专项申诉: 通过 support.github.com/request (GitHub 支持请求) 或 reinstatement form 提交; 明确标注是 trade controls 相关; 附上所有身份和位置证明文件 [T03-S002] [T03-S004]
6. OFAC SDN 自查结果附上: 如果你已在 https://sanctionssearch.ofac.treas.gov/ 搜索并确认自己不在 SDN 名单上, 将搜索结果截图附在申诉中 [T03-S018]

**资深路径**: 跳过 SDN 自查 (如果你明确知道自己与制裁无关, 直接准备位置证明); 优化: 对于中国开发者, 直接在信首声明 "China (PRC) is not subject to comprehensive US sanctions; my account was incorrectly flagged due to VPN IP geolocation" — 简洁有力; 额外: 如果是组织账号被标, 提供公司注册文件 + 公司所在地证明

**近期变化**: GitHub 2021 年获得伊朗 OFAC license 后, 伊朗开发者的限制大幅放松 (全部服务可用) [T03-S012]; 2022 年俄乌冲突后, 俄罗斯/白俄罗斯/克里米亚/顿巴斯地区的限制收紧 [T03-S002]; 2022 年 GL D-2 更新进一步放宽伊朗互联网通信服务授权 [T03-S021]; 中国开发者因 VPN 误标的案例在 2024-2025 持续出现 [T03-S024]

**失败模式**: (1) 在申诉中承认自己实际位于制裁区但要求例外 (GitHub 依法不能给例外, 除非有 OFAC license); (2) 提供虚假的位置证明 (文件伪造 = 永封 + 可能的法律后果); (3) 中国开发者在申诉中不解释 VPN 使用, 让 GitHub 默认你就是在制裁区; (4) 不区分 restriction (制裁限制, 部分服务仍可用) 和 suspension (完全封号) — 制裁通常导致 restriction 而非 suspension, 如果是 suspension 可能有其他叠加原因 [T03-S002]

### 7. 2FA 丢失恢复 (2FA Loss Recovery)

**入门 SOP**: 
1. 评估可用恢复手段 (按优先级从高到低): (A) 有 Recovery Codes → 最快: 登录页面选 "Use a recovery code" 输入任一未使用的恢复码即可登录, 默认保存在 github-recovery-codes.txt 文件中 [T03-S003] [T03-S026]; (B) 有 Passkey 或硬件安全钥匙 (YubiKey 等) → 直接用 passkey 登录, passkey 同时满足密码和 2FA 要求, 无需知道密码 [T03-S003] [T03-S017]; (C) 有 GitHub Mobile 应用 (且已设置) → 通过 app 接收验证请求; (D) 有已验证设备 / SSH key / Personal Access Token → 可作为身份验证因素启动恢复流程 [T03-S003]
2. 如果知道密码但没有以上任何 2FA 凭据: 访问 GitHub 登录页 → 输入用户名密码 → 在 2FA 页面选 "More options" → 选择 "Get a one-time password sent to your verified email" → 收到邮件后开始恢复身份验证流程 → 选择验证因素 (已验证设备 / SSH key / PAT) → GitHub 支持团队在约 3 个工作日内审核 [T03-S003]
3. 如果完全丧失所有恢复手段: 残酷的现实 — GitHub 官方声明: "GitHub Support will not be able to restore access to accounts with two-factor authentication enabled if you lose your two-factor authentication credentials" [T03-S003]; 最后手段: 将绑定邮箱从被锁账号中解绑, 然后将该邮箱绑定到新账号 — 这样 commit 历史中使用该邮箱的提交会自动关联到新账号; 解绑方法: 使用 cannot_sign_in form (https://support.github.com/contact/cannot_sign_in) 联系支持团队协助 [T03-S003] [T03-S005]
4. 恢复成功后的即时操作: 立即生成新的 recovery codes 并安全存储; 重新配置 2FA 设备; 检查是否有可疑登录记录 [T03-S003] [T03-S016]

**资深路径**: 跳过逐级尝试 (经验丰富直接判断手头有哪些凭据, 选最快路径); 优化: 如果有多台已验证设备, 选择最方便的那台启动恢复; 额外: SSH key 验证路径 — 如果你的 SSH key 仍绑定在账号上 (通过 `ssh -T git@github.com` 可测试是否仍被识别), 这是一个强验证因素

**近期变化**: GitHub 2024 年起全面强制 2FA [T03-S016]; Passkey 成为 2024-2025 年推荐的最安全方式, 同时满足密码和 2FA [T03-S017]; GitHub SMS 验证不支持 +86 (中国大陆) 和 +852 (香港) 等多个国家/地区号码 [T03-S029]; GitHub Mobile 应用可作为 fallback 验证方式

**失败模式**: (1) 把 "2FA 锁号" 误判为 "账号被封", 走申诉流程白等数周 (这是最常见的误判); (2) Recovery codes 存储在同一设备上, 设备丢失后 codes 也一起丢失; (3) 仅依赖 SMS 验证, 但换手机号后忘记更新 GitHub (且 +86/+852 本来就不支持 SMS); (4) 开新账号替代被锁账号 (GitHub 视为 ban evasion) [T03-S022]; (5) 不保存 recovery codes 就直接关掉设置页面

### 8. 申诉成功后的恢复操作 (Post-Reinstatement Recovery)

**入门 SOP**: 
1. 验证账号功能完整性: 登录后检查 — profile 是否正常显示 (非 404)? 在隐身窗口中能否看到你的 profile? 贡献图 (contribution graph) 数据是否完整? 是否有 "spammy" 标记残留? pinned repos 是否还在? [T03-S009]
2. 检查数据完整性: 逐一核对仓库列表 — 公开仓库数量是否正确? 私有仓库是否全部恢复? 每个仓库的 branches, tags, commit 历史是否完整? pilot2254 案例显示 GitHub 自动化可能在封号期间删除了部分仓库, 解封后不一定自动恢复 [T03-S009]
3. 检查 CI/CD 和自动化状态: GitHub Actions workflows 是否正常运行 (检查 Actions 页面的最近运行记录)? GitHub Pages 站点是否恢复? Secrets 和 environment variables 是否仍存在 (封号期间可能被清除)? GitHub Apps 和 OAuth Apps 授权是否需要重新配置? [T03-S009]
4. 检查包管理器状态: 如果有发布到 npm registry 的包 → 检查包是否仍可用 (`npm view PACKAGE_NAME`); 如果有 GitHub Packages / Container Registry 镜像 → 检查是否可拉取; 如果有 Homebrew tap 或其他引用你 GitHub 仓库的包管理器 → 检查是否正常 [T03-S009]
5. 安全加固 (立即): 修改密码; 重新配置 2FA (推荐升级到硬件安全钥匙); 撤销并重新生成所有 Personal Access Tokens; 检查 SSH keys — 移除不认识的 key; 检查 OAuth/GitHub App 授权列表 — 移除可疑授权; 生成新的 recovery codes 并安全存储 [T03-S003] [T03-S016]
6. 通知协作者和社区: 通知受影响的 collaborators, org members, 和依赖你仓库的下游用户账号已恢复; 如果在封号期间有合作者帮你维护了 fork, 协调合并回主仓库; 更新相关项目的 README / CHANGELOG 记录此事件 (如果是公开项目) [T03-S009]
7. 建立预防性备份习惯: 立即执行一次完整的本地备份 (WF2 的预防性部分); 设置自动化备份 (转 WF10); 考虑多平台冗余 (mirror 到 GitLab / Codeberg) [T03-S013] [T03-S034]

**资深路径**: 跳过逐仓库检查 (用 `gh repo list USERNAME --limit 1000 --json name,visibility` 批量导出恢复后的仓库列表, 与封号前的备份列表 diff); 优化安全加固 (一次性脚本: 撤销所有旧 token + 生成新 token + 更新所有 CI/CD secrets); 额外: 检查 GitHub Transparency Center 是否有你的封号记录残留 (可能影响账号声誉)

**近期变化**: pilot2254 2024 年案例显示: 恢复后约 800 个 contribution 永久丢失, 多个仓库被 GitHub 自动化删除未恢复 [T03-S009]; GitHub 解封后不会发道歉信或解释具体原因 (多名开发者反馈) [T03-S009] [T03-S033]

**失败模式**: (1) 解封后不检查数据完整性, 数周后才发现某些仓库丢失 (此时可能已无法恢复); (2) 不重新配置安全设置, 如果封号是因为账号被盗, 攻击者可能仍有访问权; (3) 不通知下游用户, 他们继续使用封号期间建立的 fork/mirror; (4) 解封后立即大量操作 (mass push, mass create repos) 可能再次触发自动化风控; (5) 不建立备份习惯, 同样的风险重复发生

### 9. 申诉失败后的迁移 (Post-Failure Migration)

**入门 SOP**: 
1. 评估法律途径: 申诉被拒后, 评估是否有法律依据继续争取 — EU 用户可援引 DSA 第 20 条要求 out-of-court dispute settlement; DMCA 相关可提交 counter-notice (有 10-14 天等待期, 若对方不起诉则自动恢复) [T03-S006]; 制裁误标且有充分位置证明 → 可联系 OFAC 制裁律师 (如 Ferrari & Associates) 评估是否走正式 delisting 程序; 评估成本: 律师费 vs 账号中代码/关系的商业价值 [T03-S001] [T03-S006]
2. 选择替代平台: GitLab.com — 功能最完整, 内置 CI/CD, 免费层足够多数开发者, 有官方 GitHub 导入器 (自动迁移 repos + issues + PRs + wikis + milestones + labels + LFS) [T03-S015]; Codeberg — 非营利 Forgejo 实例, 完全免费, 社区治理, 适合开源项目; self-hosted (Forgejo / Gitea) — 完全自主控制, 但需要运维能力; Gitee / JihuLab — 中国开发者本地选项, 但 Gitee 有内容审查; SourceHut — 极简, 邮件驱动, 适合 hacker; Radicle — P2P 去中心化, 抗审查但生态不成熟 [T03-S015] [T03-S032]
3. 迁移代码仓库: 使用本地已有的 `git clone --mirror` 备份推送到新平台: `git remote add gitlab https://gitlab.com/USER/REPO.git && git push --mirror gitlab`; 如果使用 GitLab, 可用其内置 GitHub 导入器 (Settings → Import Project → GitHub) 自动完成; 批量迁移: `ghorg clone USERNAME` 先全量 clone, 然后脚本循环推送 [T03-S013] [T03-S015]
4. 迁移非 Git 数据: Issues/PRs: 使用工具如 `node-gitlab-2-github` (反向使用) 或 GitLab 导入器自动迁移; Wikis: Git-based wikis 可直接 clone + push (wiki 本身是 Git repo); GitHub Pages: 需要改为 GitLab Pages (配置 .gitlab-ci.yml) 或其他静态托管 (Netlify / Vercel / Cloudflare Pages); Discussions: 无直接迁移工具, 需手动或脚本通过 API 导出 [T03-S015] [T03-S030]
5. CI/CD 迁移: GitHub Actions → GitLab CI: .github/workflows/*.yml 需改写为 .gitlab-ci.yml 格式 (stages/jobs/script 不同); 手动翻译每个 action 为 GitLab 等价配置; GitHub Actions Marketplace 中的第三方 action 没有 GitLab 等价物的, 需要用 shell script 或 GitLab CI template 替代; Secrets/环境变量需要在新平台重新配置 [T03-S015] [T03-S032]
6. 更新依赖和引用: 更新所有引用旧 GitHub URL 的地方 — README 中的 badge / 文档中的链接 / 依赖管理文件 (package.json / go.mod / Cargo.toml) 中的 Git URL; 如果有 npm package, 更新 package.json 的 repository 字段; 域名重定向: 如果有自定义域名指向 GitHub Pages, 更新 DNS 记录 [T03-S015]
7. 社区通知与过渡: 在所有相关渠道 (Twitter/X, Discord, 邮件列表, 博客) 宣布迁移; 提供新仓库 URL; 如果仍有 GitHub 上的 fork (由合作者维护), 在 fork 的 README 中注明已迁移并链接到新地址; 联系重要下游依赖方 (使用你代码的项目) 通知 URL 变更 [T03-S034]

**资深路径**: 跳过平台选型犹豫 (直接用 GitLab.com, 它的 GitHub 导入器最成熟); 优化 CI/CD 迁移 (如果 workflows 复杂, 考虑先用 Drone / Woodpecker 等 CI 做过渡, 它们支持多平台); 额外: 设置 GitHub → new platform 的 webhook 或 mirror, 万一 GitHub 未来解封可自动同步回去; 使用 Software Heritage (https://archive.softwareheritage.org/) 确保代码有公共存档

**近期变化**: GitLab 2023-2025 持续改进 GitHub 导入器, 现支持 PR reviews / LFS / release attachments 的完整迁移 [T03-S015]; Codeberg / Forgejo 2024-2025 快速成长, 成为去中心化替代方案的热门选择; Radicle 仍处于早期但吸引了重视抗审查的开发者 [T03-S032]

**失败模式**: (1) 只迁移了代码, 忘记迁移 issues/PRs/wikis (项目历史断裂); (2) 不更新依赖中的 GitHub URL, 导致下游用户 build 失败; (3) 不通知社区, 用户继续在死掉的 GitHub 仓库提 issue; (4) 同时在多个平台维护导致分裂 (选一个主平台, 其他做 mirror); (5) 迁移到 Gitee 但未考虑其内容审查政策, 可能面临二次删除

### 10. 预防性安全加固 (Preventive Security Hardening)

**入门 SOP**: 
1. 2FA 强化 (按安全等级从高到低): 最高: 硬件安全钥匙 (YubiKey 5 系列 / Google Titan / Feitian), 注册为 FIDO2/WebAuthn 凭据 — 抗钓鱼, 不可被远程窃取; 次高: Passkey (synced across devices), 同时满足密码和 2FA, 2024 年起 GitHub 原生支持; 高: TOTP 应用 (Authy / 1Password / Aegis), 扫码绑定后生成时间码; 低 (不推荐): SMS 验证 — 易被 SIM swap 攻击, 且不支持 +86 / +852 等国家代码 [T03-S003] [T03-S016] [T03-S017] [T03-S029]
2. Recovery Codes 离线存储: 启用 2FA 时生成的恢复码 (默认文件名 github-recovery-codes.txt) 必须安全存储; 推荐: 打印纸质副本放保险箱 + 密码管理器中加密存储一份; 禁止: 仅存在同一台手机/电脑上 (设备丢失则 codes 同时丢失) [T03-S003] [T03-S026]
3. 注册多个验证方式: 至少注册两种不同类别的 2FA 方式 (例如: 一个硬件钥匙 + 一个 TOTP app); 注册 passkey 到至少两个不同设备上 (以防一个设备丢失); 如果使用硬件钥匙, 买两把 (一把日常使用, 一把作为备份存放在不同物理位置) [T03-S003] [T03-S017]
4. 定期备份自动化: 设置 cron job 或 scheduled task 定期执行 `git clone --mirror` (或 `git remote update --prune` 更新已有 mirror); 推荐频率: 重要项目每日, 一般项目每周; 备份应包含非 Git 数据: 使用 `gh issue list --json` + `gh pr list --json` 导出 issues 和 PRs; 使用 GitHub Migration API 定期做完整归档导出; 备份存储在 GitHub 以外的位置 (本地磁盘 + 外部硬盘/NAS/S3) [T03-S013] [T03-S014] [T03-S034]
5. 多平台冗余 (mirror): 设置 Git 仓库自动 mirror 到第二平台 — GitLab (Settings → Repository → Mirroring) 或 Codeberg 支持自动从 GitHub 拉取; 配置方式: `git remote add mirror URL && git push --mirror mirror` 放入 cron; 或使用 GitLab 的 pull mirror 功能 (每 5 分钟自动同步) [T03-S015] [T03-S031]
6. 避免触发风控的行为模式: 不使用 "star exchange" / "互 star" 平台 (直接导致封号) [T03-S022] [T03-S035]; 不在短时间内批量 fork / star / create issues (会被自动化检测为 bot/spam); 不使用来路不明的第三方 GitHub App/OAuth App (可能注入恶意代码或窃取 token) [T03-S025]; 自动化 API 操作遵守 rate limit (5000 requests/hour for authenticated users); 避免 commit message 中包含敏感关键词 (某些过滤器可能误判) [T03-S022]
7. VPN 使用注意事项: 如果你在非制裁区但使用 VPN, 确保 VPN 出口 IP 不在制裁区 (伊朗 / 克里米亚 / 朝鲜 / 古巴); 推荐: 使用知名 VPN 服务商的日本/新加坡/美国/欧盟出口节点; GitHub 通过 IP + 支付历史判断位置, 长期使用同一制裁区 IP 会被标记; 如果必须使用 VPN, 确保 GitHub 账号的支付信息 (如有) 指向你的真实位置 [T03-S002] [T03-S024]

**资深路径**: 跳过基础 2FA 设置 (直接上硬件钥匙 + passkey 双因子); 优化备份 (用 Infrastructure-as-Code 思路: 写一个 backup.sh 脚本 + systemd timer / launchd plist, 自动 clone --mirror 所有 repos + gh api 导出 metadata + 压缩加密 + 推送到 S3); 额外: 设置 GitHub Webhooks 监控自己仓库的关键事件 (repo deleted / member removed / visibility changed), 第一时间发现异常; 额外: 定期审计 OAuth App / GitHub App 授权列表 (Settings → Applications), 移除不再使用的授权

**近期变化**: GitHub 2024 年全面强制 2FA, 不设置 2FA 的账号会被要求设置后才能继续使用 [T03-S016]; Passkey 在 2024-2025 成为 GitHub 推荐的主要验证方式 [T03-S017]; "GitHub is not your backup" 在 2024-2025 成为社区共识, 多个备份工具和服务涌现 [T03-S034]

**失败模式**: (1) 只设置了 2FA 但不存储 recovery codes (账号安全了但自己可能被锁在外面 → 形成 WF7 循环); (2) 备份只包含 Git 数据不包含 issues/PRs/discussions (项目管理数据丢失); (3) mirror 到 GitLab 但 mirror 设置过期后不管 (GitLab free tier mirror 可能有限制); (4) 使用了 "互 star" 平台然后被封, 这是完全可预防的; (5) 安全加固做了一次就不再更新 (新 OAuth 授权积累 / 旧 token 不撤销 / recovery codes 过期)

---

## Phase 2 提炼提示

- 10 个 SOP 中, WF1-WF5 构成主干线 (封禁→诊断→申诉→跟进), WF6-WF7 为特殊分支, WF8-WF10 为善后/预防
- 决策树入口: WF1 分诊结果决定走哪条分支 (制裁→WF6, 2FA→WF7, 其他→WF3→WF4→WF5)
- 失败路径: WF5 申诉失败 → WF9 迁移 (非循环回 WF4, 除非有新证据)
- 中国开发者特殊路径: WF1 分诊 + WF6 制裁误标 + WF4 英文申诉信 (三合一)
- 工具映射: 每个 SOP 步骤对应 Track 02 具体工具编号
- CLI 生成: 每个 SOP 可生成 bash 脚本 (如 `wf02-emergency-backup.sh` 批量 clone --mirror)
