fkit-audit

name	fkit-audit
description	审查 FlutterKit 项目或指定模块的架构边界、命名、注释、TDesign 与设计系统使用、预览、测试、生成文件和多端配置。用户要求全盘扫描、代码审查、架构检查、注释检查、预览完整性检查或质量报告时使用。

FKit Audit

审查原则

默认只读取、诊断和报告；只有用户明确要求修复时才修改代码。先阅读 AGENTS.md 与 docs/flutter-kit/README.md，再按发现的问题加载对应专题，避免一次读取所有文档。

使用结构化查询确认声明、调用和影响范围；使用文本搜索检查注释、硬编码、注解和路径。不要仅凭文件名、正则命中或 lint 数量断定问题。

审查维度

1. 架构：Core/Feature/Routes/Bootstrap 依赖方向、单页与模块级数据边界、View/Logic/State/Binding 职责。
2. UI：TDesign 组件复用、完整布局规范、主题语义、硬编码、链式扩展顺序、Obx 范围和响应式适配。
3. 数据：Model/DataSource/Repository/Result/Service 链路、异常与持久化边界。
4. 导航：模块 Navigator、参数/结果类型、Guard、路由唯一性和状态保持。
5. 预览：页面和组件注解、Logic 注入、静态数据、真实请求风险和多屏覆盖。
6. 代码质量：命名、中文文档注释、生成文件、测试覆盖、格式与分析诊断。
7. 原生与资源：图标、启动页、配置源图、生成结果及平台一致性。

输出格式

• 按严重级别和影响范围排序问题，先给结论，再给文件、行号、证据和建议。
• 区分确定问题、潜在风险和文档差异；没有证据时继续调查，不写猜测性结论。
• 明确列出已检查范围、未检查范围、执行的命令和失败原因。
• 若没有问题，直接说明未发现问题，不为填充报告制造建议。

修复模式

用户要求修复时按目录或问题类型分批实施，保留已有工作区修改。每批运行最小相关验证，最后执行 flutter analyze、相关测试和 git diff --check；不要顺带修复任务外问题。