[Mimosa 1.0.3] 固定SQL代理在方法定义处被判SQL注入：完整上下文复现与诊断/账本关联缺口

环境

• Windows，ZCode Desktop；本次未单独核验Desktop版本，因此不填写猜测值。
• 安装插件manifest：mimosa@zcode-plugins-official 1.0.3。
• 官方CLI Native静态扫描；关闭模型复核、依赖扫描及远程规则更新，仅用于隔离诊断，未改变宿主编辑门设置。
• SARIF driver自述0.1.0，这与插件manifest是不同字段。

已观察事实

一次Python测试代理的原生Edit在写入前被拒绝，理由为高危SQL注入。代理只接受有限的完整SQL文本，并分支调用固定字符串SQL；数据通过绑定参数传给SQLite。

我们保留被拒输入、不重放编辑，以官方CLI stdin路径做两次诊断：

1. 精确原始追加片段：219行；因缩进不能独立做Python AST解析；Native扫描exit2，定位片段141行的方法定义def execute(self, sql, *args):。
2. 在内存中补齐原文件上下文，不修改该编辑内容：Python AST解析通过；全部16个属性名为execute的调用，其第一参数均为字符串字面量；Native仍exit2，定位完整文件2669行的同一方法定义。

因此可以排除“只因追加片段不完整”的解释，但不能据此断言引擎内部机制或整体产品安全。SARIF给出sql-injection/CWE-89，没有提供能复核的source、实际SQL sink或数据流说明。相关Hook批次的events、finding IDs和verified files为空，无法从该批次建立拒绝到finding的完整链。

另观察到：项目状态汇总因外部候选文件使用绝对路径而返回partial。此兼容问题与SQL识别是独立问题，不把最后一次报告文件写入的clear解释为源码通过。

已确认的独立代码缺陷

代理把外层*args元素都要求为str，实际合法调用传入一个单元素tuple。这会错误拒绝合法绑定调用。该缺陷已确认，计划修正为检查真实参数容器并原样传递；但它不证明SQL文本受外部数据拼接，也不解释方法定义上的SQL注入定位。

需要维护者回答

1. 该类方法定义被定位为SQL注入时，实际source、sink、参数角色和适用proof profile是什么？能否在诊断中输出足够的证据及输入/坐标身份？
2. 如果固定SQL/绑定参数的识别或定位有误，请提供正式修复版本；回归需同时检出真实SQL拼接，不能按测试文件路径或方法名整体放行。
3. 请确认每次Edit deny是否都应产生可关联的finding/审计事件，以及外部候选目录的受支持scope关联方式。
4. 是否存在保留来源/目标哈希、完整接受正常候选扫描的源码派生流程，以避免重新手工转写未变化的源文件？若当前不支持，请明确说明。

我们保持正常编辑门启用，没有通过替换工具、重命名函数、拆分输入、抑制规则或改变扫描阈值应用被拒编辑。完整复现证据已在本地保存；如需更多材料，将先确认必要范围并脱敏，不上传产品源码或秘密信息。

相关先例与区别

• #300：SQLAlchemy参数化建模报告；本案使用SQLite代理，不能视作同一根因。
• #481：Bash拒绝未进入ledger；本案是Edit审计关联问题。
• #526：安全测试夹具与Git门；本案是写入前门。

这些报告只作关联线索，我们不预设官方已确认本案误报，也不请求关闭全局安全控制。

Start with the official CLI stdin diagnostic path and compare the two reported scans: the 219-line appended fragment and the 2669-line reconstructed file. Review the SARIF output and Hook batch events for source, sink, data-flow, finding IDs, and verified-file associations. Done means documenting the misclassification or its evidence, adding a regression that still detects real SQL concatenation, and clarifying Edit-deny audit linkage and external candidate scope.