admin
e03465c398
用户令逐字：「E:/ProgramData/.workbuddy/skills 提交仓库是指的这里」—— 即本目录就是仓库（2026-10-07 已在本目录建仓，见当日日志 §22），本轮把余下未纳管的 9 个技能一并提交。 本次入库（9 个技能，46 个文件）： 1、`AI HOT` 2、`draw-ui` 3、`dsh-diagnose` 4、`dsh-knowledge` 5、`dsh-local-env` 6、`dsh-opensource-release` 7、`dsh-workflow` 8、`oil-motion` 9、`skills-security-check` 提交前核对： · **凭据类扫描**（`*.env` / `*token*` / `*.key` / `*secret*` / `*.pem`）⇒ **零命中** ✓； · 体积合计约 20 MB（`draw-ui` 12M ＋ `oil-motion` 6.5M 是大头，形态为配图/素材 —— 仓库 `.gitignore` 里明写「`assets/*.png` 是内容不是产物」⇒ 属刻意入库）； · 运行产物仍按既定规则排除（`__pycache__` / `logs/` / `tmp/` / `.venv/` / `*.egg-info` / `uv.lock` / `.workbuddy/`）。
6.9 KiB
红线详解 · R7 批量写入门禁 / R8 生产变更知会 / R5 权限扩大门禁
归属：技能
dsh-change-workflow的详情档（按需读，不是每次都要读）。 本档覆盖：R7 批量写入门禁 · R8 生产变更知会 · R5 权限扩大门禁（原行 L414–L480）。 主文件 / 判据与流程主干 =../SKILL.md（§1 六阶段流程 · §2 红线 R1–R8 原文速查 · §3 本机 Git Bash 环境坑 · §4 并行调度结论）。 来源：2026-09-22「技能重组线」把../SKILL.md的 L414–L480 段逐行原样下沉到本文件，未改一字。 跨档引用：正文里的「§N / 见 §8 坑 N / 见下表」等编号，用../SKILL.md末节「详情索引」的原章节列定位。 维护：本文件与../SKILL.md的指针行成对；改内容时同时核对主文件的指针描述是否仍准确。
R7 批量写入门禁（2026-09-12 用户新增红线）
用户原话：「为什么会犯这种错误，容易把服务器搞崩，必须记录在红线中。」
由来（真实事故）：为了让 scp 出去的文件行尾干净，写脚本遍历整个代码库把 147 个文本文件 CRLF→LF。当期被要求的只是一句「把某个 UI 字符串改个名」，操作半径放大了两个数量级。
已经造成的实际损害（不是理论风险）：
- 147 个文件被标记为 M —— 若继续 scp / 提交 / 推送，会覆盖服务器上正确的版本、产生巨型 diff 掩盖真实改动、并与并行会话冲突；
- 随后用
cp -r同步插件目录时，把当期并没有改过的cordis.patch.yml、lib/index.js也用 CRLF 覆盖到了服务器（已发现并恢复）。
规则（硬性）：
- 只做被明确要求的事。执行中发现的额外问题（哪怕看起来"很小、很好修"）一律先报告、后动手，不得顺手改。用户说"按建议处理"只授权那条建议本身，不是授权一切顺带优化。
- 禁止对仓库或生产目录做：全库遍历改写（
os.walk/find -exec/grep -rl | xargs）、通配符重写、批量chmod/chown、批量换行符转换、cp -r整目录覆盖、git add -A。 - 阈值：一次操作若可能影响 >10 个文件，或表述里出现「所有 / 整个 / 全库 / 全部」→ 停下来先问，先产出受影响清单再决定。
- 本机不是沙箱：本机镜像与服务器是两份独立副本；本机的批量改动即便不带任何"部署"动作，也会在下一次 scp 时传导到生产。
- 先用单点验证：任何批量手段先对 1 个对象试，确认后果（
git status、file、md5）符合预期再考虑推广。 - 传播前比对待传清单：scp / 同步前必须
git status确认待传清单只含本次真实改动，不含被工具顺手改动的文件。 - 行尾类问题一律先报告：仓库 blobs 是 LF 而本机工作树因 system 级
core.autocrlf=true呈现 CRLF（D:/Program Files/Git/etc/gitconfig）—— 这是既有环境事实，不构成"需要当场修复"的缺陷；要动必须先与用户确认范围。
R8 生产变更知会（2026-09-12 用户新增红线）
由来：档案 58（内存优化）、59（重连反馈）两次改动都需要重启 dshs，连续两次把在线用户踢下线，直接引发用户"会话连接异常"报障。
规则：
- 以下动作都会中断在线用户，执行前必须先说明「影响谁、断多久、为什么必须现在做」并取得确认：
systemctl restart dshs（drain 全部实例）systemctl stop dsh-*.scope（停某个用户实例）- 批量铺插件 / 改
MemoryMax/ 改实例 env（都要实例重启才生效） - 重建 profile、改 profile patch
- 能选低峰期就不要在用户活跃时做；无法避免时明确告知"会断一次"。
- 改完即验证：重启后必须确认服务 active + 门户 200 + 实例能被拉起，再向用户交代。
- 附带：本机
D:\github下的镜像任何批量改动都视为"可能影响生产"（见 R7 第 4 条）。
R5 权限扩大门禁（2026-09-11 用户新增红线）
先判方向：这次改动是「扩大」还是「收窄」？
| 方向 | 例子 | 处置 |
|---|---|---|
| 收窄 | 减少挂载、去掉白名单项、收紧 nft、收窄 env | 可直接做，但仍须验证（遮蔽类可能让实例起不来 → 档案 42） |
| 扩大 ⚠️ | 新增 bwrap 挂载 / --bind、放开被遮蔽的路径、把平台目录或文件暴露给实例、给实例注入新 env、放宽 ALLOWED_ENV、放松 nft（出网或宿主访问）、提高权限档位或放宽 approval、新增用户可读/可写路径、把 root 执行链路（解压 / chown / pnpm）的对象变成用户可控 |
一律先出「权限影响评估」并等用户明确同意，禁止"顺手做了" |
「权限影响评估」四问（方案里必须逐条写，档案留痕）：
- 扩了什么 —— 逐条列具体路径 / 端口 / env / 权限位（不要写"优化了访问"这种含糊话）；
- 谁受影响 —— 全部租户 / 单租户 / 仅 admin；
- 有没有不扩大也能实现的方案 —— 若有，必须先提；若确实没有，说明为什么；
- 回滚方式 + 验收方式 —— 回滚命令写清楚；验收必须 diff 技能里的「实例可访问路径清单（权威版）」， 逐项确认"新增项都是用户已同意的"。
🔒 安装类操作 = 扩大，必须先出「安装确认清单」并经用户确认（2026-09-11 用户明确要求：
「需要安装哪些依赖和工具，需要确认后才能安装，避免安装有风险的内容」）。
凡是要往平台共享位（/usr/local/dsh-runtime、/usr/local/bin、系统包）装东西，一律不得自动执行，
先列七项等用户点头：① 名称+版本 ② 为什么需要（哪个技能/插件在用）③ 来源与校验方式（官方 URL + sha256）
④ 体积 ⑤ 影响面（全部租户）⑥ 风险点 ⑦ 卸载方式。
技能/插件导入时的依赖体检只做「报告 + 拦截」（缺失即 409），绝不代装。
触发文件（改这些就必须走 R5，无一例外）：
src/supervisor/orchestrator.ts（bwrap args / baseEnv）、src/supervisor/spawn.ts（ALLOWED_ENV）、
/etc/nftables-dsh-egress.nft、src/web/routes/skills.ts、src/web/routes/business-plugins.ts、
ensure-role-profile-patch.cjs（角色 profile patch）。
历史依据：档案 39（
/etc白名单化）、40（bundled-skills 挂载）、41（技能上传/启停）、42（Python 运行时） 里每一次"扩大"都是在用户明确要求下才做的；反例是档案 42 的遮蔽尝试 —— 属"收窄"但因触碰挂载结构 直接让实例起不来，收窄也必须跑真启动验证。