Sesame-AG 的维护目标是学习研究、代码整理、调试辅助与公开协作，不是商业化产品支持仓库。
在提交 Issue 或 Pull Request 之前，请先阅读 README.md 和 LEGAL.md。如果你的诉求与项目定位、法律边界或现有模板明显冲突，相关内容可能会被直接关闭或忽略。
为避免滥用，确保模块以学习研究为主的定位，目前仅对以下环境组合提供支持维护：
LSPosed API 101+已 RootAndroid 16+
这意味着：
- 超出上述范围的兼容性问题、环境适配诉求或功能异常，默认按 best effort 看待，不承诺修复、跟进或持续维护。
- 如果问题只在非官方支持环境中出现，请在 Issue 或 PR 描述中明确说明，避免误判优先级和处理预期。
以下方向通常更适合当前仓库：
- 可复现 Bug 的修复与回归说明。
- 文档完善、注释澄清、结构整理与低风险重构。
- 调试工具、日志工具、构建流程、模块元数据的改进。
- 与现有任务模块、Hook 入口、配置模型一致的小步增量改进。
请先完成这些基本检查：
- 确认当前没有相同或高度相似的 Issue。
- 确认你已经更新到当前可获取的最新版本或最新提交环境。
- 确认你已经阅读 README，尤其是项目定位、兼容性和相关文档入口。
- 确认你愿意在后续继续补充信息、协助测试，而不是只抛出一句结论后失联。
这部分要求与仓库现有的 Bug 模板保持一致；如果你完全不打算配合补充信息，Issue 很难被有效处理。
提交 Bug 时，至少请提供以下信息：
- 使用环境：Android 版本、Xposed 框架类型、模块版本或提交、目标应用版本。
- 复现步骤：从打开什么、点击什么、配置什么，到最终出现什么问题。
- 预期结果与实际结果。
- 相关日志、截图或报错信息。
- 是否使用了 Root / Shizuku、是否改过源码、是否使用第三方分发包。
日志要求：
- 请尽量使用可复现时段的原始日志，不要只截取一句“报错了”。
- 提交前请自行脱敏，不要泄露账号、Token、设备标识、路径隐私等信息。
- 不要破坏日志格式，便于后续检索和比对。
如果缺少复现步骤、环境信息和日志，Issue 通常没有足够上下文被处理。
当前仓库已经存在“功能建议”模板，建议提交时至少说明：
- 建议类型：功能型增强、优化型增强或强迫症增强。
- 具体使用场景。
- 期望行为与现有行为的差异。
- 对兼容性、配置项、日志或 UI 的影响。
请避免提交以下类型的“建议”：
- 带有明显商业用途、售卖诉求或闭源分发诉求的需求。
- 需要规避法律、平台规则或安全边界的需求。
- 没有使用场景、没有验收标准、只有一句“顺手加一下”的模糊愿望。
如果你准备提交 PR，请遵循这些基本约束：
- 基于
dev分支发起。 - 保持变更聚焦，不要把无关格式化、重命名、清理和功能修改混在一起。
- 修改行为、配置或边界时，同时更新相关文档。
- 尽量遵循当前仓库已经存在的命名、目录和模块划分方式。
- 如果你的改动依赖特殊环境、Root / Shizuku、外部服务或特定目标应用版本，请在描述里写清楚。
- 不要提交密钥、账号、Token、抓包数据或其他敏感内容。
建议在 PR 描述中写清楚：
- 改动目的。
- 主要改动点。
- 影响范围。
- 已做的静态自检或手工验证方式。
- 可能的风险点或回滚点。
以下内容通常不会被优先处理，严重时会直接关闭：
- 重复 Issue。
- 缺少环境信息、复现步骤和日志的 Bug 报告。
- 与项目学习研究定位明显不符的商业支持请求。
- 涉及闭源售卖、定制打包、灰色用途或规避边界的请求。
- 与当前仓库无关的上游历史争议，但没有给出具体提交、具体文件或具体版本。
- 大范围无解释重构，或明显破坏现有结构的一次性巨型 PR。
如果你希望沟通更高效，最有效的方式通常是：
- 先阅读仓库文档和现有模板。
- 再给出最小可复现信息。
- 明确你是在反馈 Bug、提出建议，还是已经准备好提交修复。
维护者精力有限。信息完整、范围清晰、能持续跟进的问题，通常更容易得到有效响应。