你的项目组合不是"很多项目"，是"三个在跑的生产线 + 一堆停在半路的资产"。41 个仓库里，13 个一周内动过，12 个超过 90 天没动（29%），中间几乎没有温区。真正在迭代的是 Jenkins 插件链、微信小店/内容工具、以及 nanshanju 站点群这三条线。
提交量高度集中在少数仓库：10,101 个提交里，Jenkins 族 8 个仓库占 6,509（64%）；web 族的 2,617 里 ps-src 一个就 2,169（那是带 55 个分支的外部大工程，不能算你的产出）。也就是说「项目数量」和「真实工作量」几乎没关系。
工程化底座几乎空白：CI 覆盖 11/41（27%），AGENTS.md 4/41（10%），CHANGELOG 0/41（0%）。这是"每次迭代都要重新解释一遍上下文、发布不可追溯"的根因，也是我上次提的迭代单+项目上下文方案要解决的东西。
内容族是同一套模板复制的 9 份：9 个平台 CLI（抖音/微博/知乎/闲鱼/淘宝优惠/微信小店×3）里 5 个在同一天（09-11）留下最后一次提交，最大的才 12 MB，全部无 CI 无测试、且共享同一类"cookie/登录态"依赖 → 合并成一个 monorepo + 共享认证模块，是收益最高的重构。
有 5 个工作区带着未提交改动，其中 1 个是正在活跃开发的仓库：jenkins-atom-plugin（5 个文件）、wxstore-web（11 个，已放置 46 天）、devops-monitor（3）、认知（2）、devops-dev-kit（1）。
| 窗口 | 仓库数 | 占比 | 说明 |
|---|---|---|---|
| ≤ 7 天 | 13 | 32% | 真实在推进的三条线：jenkins-atom-*、wxstore-mms / 内容站、nanshanju-infra / noteweb / reports |
| 8–30 天 | 4 | 10% | hummerstudio.github.io、rpu、gitcode-issue-cli、tc-service-docs |
| 31–90 天 | 12 | 29% | 内容 CLI 的集体静默（09-11 那一批）、thelm / ttf、hermes-opencode-acp |
| > 90 天 | 12 | 29% | 从 111 天到 788 天，最长的是 devops-private-document（788 天） |
| 族 | 仓库 | 提交 | 30 天 | 90 天 | 中位静止 | 脏工作区 | 有 CI |
|---|---|---|---|---|---|---|---|
| content 内容创作 | 13 | 213 | 72 | 145 | 46 天 | 1 | 1 |
| web 站点 | 6 | 2,617 | 36 | 359 | 28 天 | 0 | 0 |
| jenkins 插件体系 | 8 | 6,509 | 120 | 228 | 149 天 | 1 | 7 |
| infra 底座 | 5 | 170 | 45 | 170 | 6 天 | 0 | 1 |
| legacy 历史资产 | 8 | 590 | 22 | 25 | 421 天 | 2 | 2 |
「中位静止」= 该族所有仓库"距最后一次提交天数"的中位数，比平均值更能反映真实节奏（会被 788 天的极端值拉偏）。
| 仓库 | 角色 | 最后提交 | 体积 | 状态 |
|---|---|---|---|---|
| wxstore-mms | 微信小店后台（Python + JS） | 10-26 | 384M | 活跃，30 天 41 提交，唯一有 AGENTS.md 的内容仓库 |
| hacker-path / books / reader-card | 知识类产物 + 阅读卡片 | 10-21~23 | 60–96M | 活跃，但内容型仓库（Docs 为主） |
| wxstore-web | 小店前端/数据站 | 09-11 | 79M | ⚠ 11 个未提交改动，已放置 46 天 |
| douyin-cli / weibo-cli / zhihu-cli / xianyu-cli / tuiyouhui-cli / wxstore-cli / wxstore-api-cli | 7 个平台 CLI | 08-07 ~ 09-11 | 140K–12M | 全部静默；无 CI、无测试、无 AGENTS.md |
| quan | 音韵资料站 | 2025-10 | 38M | 369 天未动（有 CI，是历史遗留） |
判断：这 7 个 CLI 是同一母题的 7 次复制——都是「登录态 + 抓取/发布 + 落盘」，每个只提交 1–7 次就停了。它们的维护成本不在代码量（最大的 12 MB 里大半是资产），而在每个平台各自一套 cookie 过期、扫码、风控处理。合并成 content-clis monorepo，把认证抽成 platform_auth/（每个平台一个 adapter），收益是：升级一次依赖、跑一套 CI、改一次登录逻辑全线生效。真实风险是扫码——容器没有屏幕，这条线留在 Mac 或走 cookie 注入，必须显式定义。
| 仓库 | 角色 | 最后提交 | 提交 | 分支 | 状态 |
|---|---|---|---|---|---|
| nanshanju-infra | 站点群基础设施（nginx / launchd / 隧道配置） | 10-27 | 27 | 2 | 今天还在动，30 天 27 提交——最健康的一个 |
| noteweb | note.nanshanju.com 记事（Flask + 数据） | 10-21 | 62 | 4 | 活跃，数据在 data/notes.json |
| reports | 本报告站（静态化 + Pages 部署） | 10-27 | 3 | 2 | 本次迁移到 Pages，已脱本地依赖 |
| hummerstudio.github.io | 个人/团队主页（GitHub Pages） | 10-13 | 355 | 7 | 低频维护 |
| tc-service-docs | 腾讯云服务文档集 | 09-29 | 3 | 1 | 文档型 |
| ps-src | 外部大工程（Java，2,169 提交） | 09-18 | 2,169 | 55 | ⚠ 55 个分支，不是自研代码，别按"你的项目"统计 |
| yuetool-com.github.io | 工具站 | 2025-10 | 1 | 5 | 372 天未动 |
判断：这条线的架构已经从「Mac 上的 launchd + 隧道」演进到「静态站 + Cloudflare Pages」，今天这次发布就是实证。nanshanju-infra 里还留着大量主机/隧道配置，建议把「谁是源站、谁是边缘」写成仓库里的一页 docs/TOPOLOGY.md——否则下次还会出现"我以为是 Mac 在服务"这种误判（我自己今天就踩了）。
| 仓库 | 角色 | 最后提交 | 提交 | 分支 | 状态 |
|---|---|---|---|---|---|
| jenkins-atom-plugin | 生产插件 | 10-27 | 68 | 2 | 主力在推进；⚠ 5 个未提交改动；有 CI |
| jenkins-atom-sdk | 插件 SDK | 10-26 | 10 | 2 | 活跃；有 CI |
| jenkins-atom-demo | SDK 用法示例 | 10-26 | 12 | 2 | 活跃；有 CI，可作兼容性回归 |
| rpu | repository-permissions-updater（fork） | 10-15 | 4,506 | 10 | 上游大仓，你只推了少量提交 |
| jenkins-shared-library | 共享库 | 05-31 | 1,458 | 21 | 149 天未动，21 个分支 |
| ci_scripts | CI 脚本集 | 05-17 | 412 | 25 | 163 天未动，25 个分支 |
| agentic-devops | Agent 化 DevOps 尝试 | 05-30 | 9 | 3 | 150 天未动，更像一次试验 |
| pkr-step | 上游 pipeline-keep-running-step | 2025-06 | 34 | 6 | 489 天未动；本地领先上游 9 个提交未开 PR |
判断：这是唯一一条同时具备「活跃开发 + CI + 多仓库版本耦合」的线，也是 64% 提交量的来源。它的问题不是节奏，而是版本治理：SDK 改了接口，插件和 demo 靠人肉同步，没有 CHANGELOG、没有 tag 纪律（41 个仓库的 tag 全是 0），发布只能靠记忆。pkr-step 那 9 个直接躺在本地、没有上游 PR 的提交，是典型的"做完就忘"资产。
hermes-agent-data：备份仓库，30 天 36 提交，实测远端已含最新提交（本地 remote-tracking 引用 46 天没 fetch，git status 会误报 68 个未推送）reports：报告站，今天迁移到 Pagesyue-hidpi：626 MB 的 HiDPI 工具，4 次提交gitcode-issue-cli / hermes-opencode-acp：各 2/25 提交devops-private-document 788 天 / 14 分支build-analyzer 721 天 / 6 分支devops-dev-kit 425 天 / 28 分支 / 1 个未提交devops-monitor 421 天 / 22 分支 / 3 个未提交ChinaTextbook 374 天 / 3.6 GBthelm / ttf（腾讯云 helm/terraform 资料）/ ios-src（Momenta iOS，7 天前还在动）| 缺口 | 现状 | 具体证据 | 后果 |
|---|---|---|---|
| 项目上下文缺失 | 4 / 41 | 只有 wxstore-mms、reader-card、ps-src、ios-src 有 AGENTS.md | 每次开新会话（人或 Agent）都要重新讲一遍构建/发布/禁区 |
| 变更不可追溯 | 0 / 41 | 没有任何仓库有 CHANGELOG；tag 数全部为 0 | Jenkins 插件发版靠记忆；出问题无法回答"哪一版引入的" |
| 缺少自动验证 | 11 / 41 | CI 集中在 jenkins 族（7/8）；content 族 1/13，web 族 0/6 | 内容族和站点族的改动全靠手测，回归成本高 |
| 分支膨胀 | 276 个 | ps-src 55、devops-dev-kit 28、ci_scripts 25、devops-monitor 22、jenkins-shared-library 21 | 已停项目的分支还挂着，真在做的分支反而难找 |
| 工作区不收口 | 5 个 | wxstore-web 11 个改动放 46 天；jenkins-atom-plugin 5 个（活跃开发中） | 改动与后续提交缠在一起，回滚和 review 都失去基线 |
| profile | 承接仓库 | 仓库数 | 技能数 | 主要风险 |
|---|---|---|---|---|
| content | 7 个平台 CLI + wxstore-mms / -web / -api-cli + reader-card / books | 13 | ~40 | 扫码登录（容器无 GUI）+ cookie 生命周期 |
| web | nanshanju-infra / noteweb / reports / hummerstudio.github.io / yuetool / tc-service-docs | 6 | ~18 | 源站拓扑不清（今天已踩一次）+ 无 CI |
| jenkins | atom-sdk / atom-plugin / atom-demo / shared-library / ci_scripts / pkr-step / rpu | 7–8 | ~15 | 版本耦合 + 无 CHANGELOG |
| ops | 公司运维类（阿里云 / Devtron / LDAP / Jumpserver / 云桌面 / 成本），多在 work profile | — | ~55 | 凭据与内网依赖，不能与个人项目混 |
技能数按家族归类估算（content 取 social-media/creative，web 取 web/noteweb/jekyll，jenkins 取 devops/jenkins-* 与 github/*，ops 取 work 里的公司运维域）。
这条組合的瓶颈不是"项目太多做不过来"，而是停摆没有仪式、收尾没有记录。29% 的仓库超过 90 天没动，但既没有归档标记也没有"已完成"的结论，于是它们持续占用你的注意力（每次想起都得重新判断它还活着吗）。
最高杠杆的三件事，按投入产出排：① 5 个脏工作区收口（半天，消掉最实际的丢失风险）；② 3 个活跃仓库补 AGENTS.md（每份 20 分钟，之后每次开新会话都省一遍解释）；③ content 族合并 monorepo（一周，把 13 个仓库的心智负担压到 1 个）。Jenkins 那条线节奏已经很好，只需要补版本纪律，不要动结构。
本报告本身是流程验证的一部分：从容器侧生成 → 静态构建 → Pages 部署 → 公网验收。全程实测，不是描述。
| 验收项 | 期望 | 实测 |
|---|---|---|
| 报告页状态码 | 200 | 200 |
| 字节一致性 | 本地 = 公网 | 一致（按 md5 校验） |
| 索引页含新条目 | 在首位，带标题/时间/体积 | 已在首位 |
| 边缘缓存 | 新文件不回旧缓存 | cf-cache-status: MISS → HIT（部署后） |
上一份《Mac Hermes 迁移方案》也是同一链路发布的（/mac-hermes-migration-2026-10-27.html），说明索引重建与文件上传可重复。
~/Codes、~/PycharmProjects、~/hermes-agent-data，目录深度 ≤ 3；排除 node_modules / dist / venv / .git 等。WorkBuddy 临时工程与 ~/.hermes 内部仓库未计入。ps-src（2,169）、rpu（4,506）、ChinaTextbook（1）是外部仓库/fork，把自己推的提交算进去才合理；本报告在族级汇总里保留了这些数字，但结论不依赖它们。hermes-agent-data 显示"68 个未推送"，实测 git ls-remote 远端已有全部提交，原因是本地 remote-tracking 引用 46 天没 fetch。结论：这类数字必须先 ls-remote 校验再引用。