📦 deps(standards): vendor playbook

docs/standards/playbook/.agents/tsl/auth.md

@@ -0,0 +1,33 @@
+# 安全与鉴权（Auth）
+
+本文件定义代理在处理鉴权、安全、敏感数据相关任务时的边界与要求。
+
+## 1. 基本原则
+
+- **最小权限**：只使用完成任务所需的最低权限与最少数据。
+- **默认保守**：不确定是否敏感时按敏感处理。
+- **不扩散秘密**：任何 secret 只在必要范围内出现。
+
+## 2. 凭证与敏感信息
+
+- 不要在代码、日志、注释或文档中写入明文密钥、Token、密码。
+- 如需示例，使用占位符：`<TOKEN>`、`<PASSWORD>`。
+- 避免把敏感信息打印到标准输出或错误日志。
+
+## 3. 鉴权逻辑修改
+
+- 修改鉴权/权限控制时必须说明：
+  - 变更动机
+  - 风险评估
+  - 兼容性/回滚方案
+- 默认保持旧行为兼容，除非明确要求破坏性变更。
+
+## 4. 依赖与第三方
+
+- 禁止无理由新增依赖，尤其是网络、加密、认证相关依赖。
+- 若必须新增，需在 PR 说明理由、替代方案与安全影响。
+
+## 5. 审计与合规
+
+- 任何涉及用户数据/权限边界的改动需可审计：代码清晰、注释说明“为什么”。
+- 发现潜在安全漏洞时，优先修复或明确标注 `FIXME(name): security risk ...`。

docs/standards/playbook/.agents/tsl/code_quality.md

@@ -0,0 +1,32 @@
+# 代码质量（Code Quality）
+
+本文件定义代理对代码质量的最低要求与审查清单（TSL）。
+
+## 1. 总体要求
+
+- 对 `.tsl`/`.tsf` 文件一律按 TSL 规范处理（`.tsf` 也是 TSL 源文件）：遵守标准快照中的 `docs/tsl/code_style.md` 与 `docs/tsl/naming.md`（在目标项目中通常 vendoring 到 `docs/standards/playbook/docs/tsl/`）。
+- 改动聚焦目标；避免“顺手重构”。
+- API 变更要显式说明影响与迁移方式。
+
+## 2. 可读性
+
+- 复杂逻辑拆分为具名函数/变量。
+- 避免深层嵌套与重复代码。
+- 必要注释解释“为什么”而不是“做什么”。
+
+## 3. 错误处理
+
+- 错误必须显式处理；禁止静默吞错。
+- 失败路径要可观测（返回/抛出/日志）。
+
+## 4. 复杂度与规模
+
+- 单函数尽量 ≤ 60 行；超过应说明原因或拆分。
+- 单次 PR 尽量小步提交，便于 review。
+
+## 5. Review 清单
+
+- 是否有无关改动？
+- 是否有清晰的动机与行为说明？
+- 是否保持模块内风格一致？
+- 是否需要补测试/示例？

docs/standards/playbook/.agents/tsl/index.md

@@ -0,0 +1,39 @@
+# TSL 代理规则集（.agents/tsl）
+
+本规则集用于存放 **AI/自动化代理在仓库内工作时必须遵守的规则**（TSL 语言专属）。
+
+## 范围与优先级
+
+- 作为仓库级基线规则集使用；更靠近代码目录的规则应更具体并可覆盖基线。
+- 当代理规则与 `docs` 发生冲突时：
+  1. 安全/合规优先
+  2. 其次保持仓库现有一致性
+
+## 代理工作原则
+
+- 先理解目标与上下文，再动手改代码。
+- 修改要小而清晰；避免无关重构。
+- 任何可能影响行为的改动都要补充或更新测试/示例（若项目有测试体系）。
+- 不要引入新依赖或工具，除非明确要求。
+
+## 子文档
+
+- 安全与鉴权：`auth.md`
+- 性能：`performance.md`
+- 代码质量：`code_quality.md`
+- 测试：`testing.md`
+
+## TSL/TSF 必要约定（必须遵守）
+
+- `.tsl` 与 `.tsf` 都是 Tinysoft Language 源文件；修改它们时统一按 TSL 规范处理（不要把 `.tsf` 当成“另一种语言/无风格约束的脚本”）。
+- 文件级约束：一个文件只能有一个顶层声明，且文件基名必须与该顶层声明同名（推荐 `PascalCase`）；`.tsl` 顶层声明只能是 `function`。
+- 格式：空格缩进（默认 4 空格），关键字用小写，复杂分支/多语句分支用 `begin/end` 块表达结构。
+- 命名：类型/顶层函数/property 用 `PascalCase`；局部变量/参数用 `snake_case`；私有成员变量用 `snake_case_`。
+
+## 与开发规范的关系
+
+- 在本仓库内：`docs/tsl/` 与 `docs/common/`。
+- 在目标项目内（若按 README 推荐的 subtree prefix `docs/standards/playbook`）：
+  - 代码风格：`docs/standards/playbook/docs/tsl/code_style.md`
+  - 命名规范：`docs/standards/playbook/docs/tsl/naming.md`
+  - 提交信息：`docs/standards/playbook/docs/common/commit_message.md`

docs/standards/playbook/.agents/tsl/performance.md

@@ -0,0 +1,31 @@
+# 性能（Performance）
+
+本文件定义代理在做性能相关改动时的准则与检查项。
+
+## 1. 目标与度量
+
+- 明确性能目标：延迟、吞吐、内存、CPU、I/O 等。
+- 没有指标时不要盲目优化；先补充测量或基准。
+
+## 2. 处理流程
+
+1. 先定位瓶颈（profile/trace/log）。
+2. 再提出最小化改动方案。
+3. 最后用数据验证收益与副作用。
+
+## 3. 优化准则
+
+- 优先消除算法/结构性问题，再考虑微优化。
+- 避免引入复杂度换取小收益。
+- 性能优化不应牺牲可读性；必要时加注释说明权衡。
+
+## 4. 常见风险
+
+- 避免重复计算、无界缓存、隐式复制。
+- 注意热路径中的分配与 I/O。
+- 并发优化要考虑正确性与可测试性。
+
+## 5. 验证
+
+- 提供优化前后可复现的对比数据（基准、采样结果或压测报告）。
+- 若无测试体系，至少提供最小可运行的复现脚本/步骤。

docs/standards/playbook/.agents/tsl/testing.md

@@ -0,0 +1,26 @@
+# 测试（Testing）
+
+本文件定义代理在改动代码时的测试策略与要求。
+
+## 1. 测试层级
+
+- **单元测试**：验证函数/模块的独立行为。
+- **集成测试**：验证模块间交互与关键流程。
+- **回归测试**：防止已修复问题复发。
+
+## 2. 何时补测试
+
+- 新功能必须新增对应测试。
+- 修复 bug 必须先写/补回归用例。
+- 仅当改动纯文档/注释/格式时可不加测试。
+
+## 3. 测试可维护性
+
+- 一个用例只验证一个行为点。
+- 测试命名清晰，能从名字看出期望。
+- 避免依赖外部不稳定资源；必要时 mock/stub。
+
+## 4. 运行与失败处理
+
+- 本仓库未来若引入测试命令，需在此补充统一的运行方式。
+- 测试失败时优先定位改动相关原因，不修无关失败。