Hats 仍显示持有却失去权限：检查资格、standing和全角色停用
链小知 · 进阶 · 核验 · 依官方文档整理
用既有状态记录和 ERC20 资格参数区分个人资格变化、全角色inactive、历史索引与外部授权，避免重部署或转币试错。
开始前准备
- 准备正确链、Hats部署地址、完整hatId、受影响wearer及原可用权限，已有viewHat/布尔读取、模块参数和故障时刻。
- 若有ERC20资格模块，准备已保存的token地址/最低要求与wearer余额，注明数量单位、精度及同链时间；不要为恢复权限买币、转币、签名、部署或改模块。
1. 先将权限失败绑定到同一角色和地址
从原tree选hat，复制完整tokenID，核对外部权限配置的链、hat、wearer与故障时间。先确认究竟是无法读页面、无法提案还是执行被拒，不能只写“钱包没有权限”。
旧My Hats/索引NFT列表仍显示卡片可能只是事件记录；当前动态balance可因模块条件变化而改变、无需新事件。RPC错误、缺回执和返回false分开保存，不以刷新后消失或截图证明撤销执行。
检查结果：失败动作对应同一hat/主体/时间，索引与动态状态分列。
2. 用 active 判断是否全角色停用
先查看已有viewHat.active或isActive结果以及toggle地址。inactive会使原wearer的动态balance为0，涉及整个hat，不等于每个wearer token都已有烧毁事件。把toggle的人为或时间/逻辑机制记下，而不是先责怪个人ERC20余额。
toggle是显式地址，不是上级adminhat；humanistic EOA/治理推更新，mechanistic按逻辑拉当前状态。依据已有截止/模块配置识别过期或停用，不调用toggleHatStatus或checkHatStatus“修复”，也不承诺停用会自动恢复。
检查结果：全角色active状态与个人资格问题分开，实际toggle控制者已知或待核。
3. 核对 eligibility 与 standing 是否不同
读取已有isEligible、isInGoodStanding与isWearerOfHat的原bool和时间，核对viewHat.eligibility地址。bad standing会失去资格，但not eligible仍可能good standing；不能把false资格直接写成组织处分或质押被罚。
eligibility可EOA/多签/DAO人工决定，也可自动合约；与admin、toggle各不同。开发文档部分函数拼写可能旧，不能根据文字拼一个write调用。明确false、缺结果、modulerevert与不同区块读值，尚未一致时留待核。
检查结果：个人资格、standing和wearing三栏不混淆，也未将查询失败填成false。
4. ERC20 资格只检查已附加模块的 live parameters
如果已确定是ERC20 Eligibility，选hat的eligibility区域查看模块说明与live parameters：ERC20 token地址、最低balance及源码链接。核对原wearer在同链/同token的已保存余额，别用总资产USD或多签个人账户的币余额代替。
本文文档未规定UI最低数量显示为raw还是natural，必须从已有模块/余额记录的单位与decimals对齐后再比较；没有明确单位就停在“阈值待核”。不是ERC20模块时不能套余额规则，组合AND/OR、选举、协议条款或其他hat条件须按原配置逐项查。
检查结果：实际模块、token、最低要求、余额主体和单位有对应，非ERC20或未知单位不猜。
5. 检查既有配置与权限同步，不重部署
原Edit Tree > hat > Revocation & Eligibility界面区分Manually/Automatically；只根据已保存设置或可见的已附加模块读取。Create new Module、Deploy & Return、改eligibility/toggle是部署或权限写入，不能当查看/刷新步骤。
immutable限制管理员改属性/transfer，并不停止既有eligibility/toggle逻辑。若active与eligible有效且wearing已证实，再查外部系统绑定role、具体动作和原grant/claim记录；动态链上结果通过不保证外部缓存/session或全部权限已更新。
检查结果：模块条件、可变性与外部权限同步分开，排查没有修改组织权限。
6. 形成原因分支和最小补证清单
将结果归为全hatinactive、个人不eligible/standing变化、索引过时、外部绑定/动作范围问题或读取仍未知。只对已有明确burn/revoke事件写实际撤销；动态余额0、无事件或模块返回变化本身不足以宣称物理烧毁。
给组织管理员准备链、hatId、wearer、原失败动作/时刻、模块地址、active/eligible/standing结果和ERC20单位缺口。只整理材料，不分享私钥/seed/key，不通过renounce/转hat/改模块试错。平台/API或资格服务费用未核，读取记录无链Gas，部署/修改/交易费用是另外一层。
检查结果：输出可复核分支、缺证与权限/费用边界，未把未知写成必然撤销或自动恢复。
怎样确认完成
- 按同链/同hatId/wearer列出active、eligible、standing、动态wearing、模块条件与外部动作范围。
- 仅documentation，不执行钱包、RPC/SDK读写、模块部署、权限修改、revoke、资金或外部访问验收。
常见错误与边界
- 持有卡片/Mint历史不证明当前wearing；inactive与资格变化不一律等于burn。
- good standing与eligible不同；模块地址、adminhat和toggle不能互替。
- 为了排查点击Deploy、更新状态或转币会改变组织/账户，不能当只读查看。