Pact中模块治理的具体保护范围是什么？

官方文档提到的「升级模块、直接写入模块表触发治理校验」只是典型场景举例，没有覆盖全部保护范围。不管是配置静态keyset治理，还是用自定义治理函数做广义模块治理，默认强制触发校验的操作和资源如下：

• 模块自身的代码与配置变更操作
  包括模块升级（新增/修改/删除模块内的函数、表结构、常量、能力定义、跨模块导入声明、持久化pact逻辑等所有模块代码层面的调整）、修改模块本身的治理规则（比如更换治理绑定的keyset、把keyset治理切换为自定义治理函数），所有这类操作必须通过治理校验才能执行。
• 模块名下数据表的外部直接写入操作
  模块内通过deftable定义的链上表，如果外部代码绕开模块内部封装的业务逻辑，直接对表执行insert、update、delete类写入操作，会强制触发治理校验。
  这里有两个容易混淆的点：一是对表的读操作（比如select、keys、按key读取记录）不会触发治理校验；二是模块内部封装的函数执行表写入时，属于模块自身逻辑范畴，不会重复触发顶层治理校验。
• 模块内置治理能力的授权场景
  每个Pact模块都有和模块同名的内置治理能力（capability），除了系统默认触发校验的上述场景外，如果模块作者在业务代码里手动声明需要持有该治理能力才能执行某段逻辑，触发该能力授权时也会执行治理规则校验。

常见误区：调用模块对外导出的普通公开函数不会触发模块治理校验，这类函数的访问权限由模块作者在函数内部通过自定义能力、业务逻辑自行控制，不属于模块治理的默认管控范围。

keyset治理和自定义治理函数的保护范围完全一致，唯一区别是自定义治理函数支持实现更灵活的校验规则（比如多签门槛、持币权重校验、时间锁限制等），不需要受固定keyset的规则限制。

内容的提问来源于stack exchange，提问作者trh