docs: readme - 为功法和法器说明统一v0表格格式 (#166)

* refactor: toolbox - 收口Context Skills Extensions三域资源

* fix: toolbox - 重定向文集中的嵌套标签链接

* fix: toolbox - 保全被ignore遮蔽的原跟踪事实文件

* refactor: toolbox - 退役workflows残留并平铺原定义

* docs: gongfa - 整理Lambda演算正文并冻结首发来源

* docs: gongfa - 登记Lambda演算天级上品并紧随拼好码

* docs: gongfa - 同步Lambda演算AI引用覆盖

* docs: readme - 移除工具箱怎么用整块

* refactor: skills - 删除16个官方引用仅保留自有入口

* refactor: extensions - 退役33个Skill脚本并清理调用

* refactor: maintenance - 迁移校验测试至.github维护层

* chore: extensions - 移除用户点名的八项程序与资料

* refactor: maintenance - 平铺共享模块并移除lib目录

* docs: templates - 登记工具解释模板v0

* docs: readme - 更新非严肃开发工具箱定位

* docs: readme - 优化实现基座与组件编排措辞

* docs: readme - 整理首页区块并迁出贡献者名单

* docs: readme - 移除研究交流区块并调整Star提示位置

* docs: readme - 在字多不看内保持折叠层级

* docs: readme - 按v0表格整理功法与法器说明

README.md

@@ -111,7 +111,7 @@ pi --skill .github/skills
 ### 🗂️ 项目目录结构概览
 
 资源只有三个域；下面列出域边界与Context的全部9个集合，不展开各原生包内部源码。完整对象分别在三个域的README中导航。
-法器与功法的[工具解释模板v0](.github/context/assets/templates/tool-explanation-template-v0.md)已登记：两份原模板按序拼接，保留15项，不自行合并或新增栏目。
+法器与功法的[工具解释模板v0](.github/context/assets/templates/tool-explanation-template-v0.md)已登记：保留15项原名原序；Markdown中每个对象使用一张严格表格，不合并对象或新增栏目。
 Extensions当前保留17个一级对象；用户点名的8项程序/配置/图文文件已移除，历史资料不代表当前可用入口。
 原Actions定义已移入Extensions保全，自动CI、打标签及欢迎流程已停用；本地`make test`保留。
 
@@ -305,11 +305,23 @@ gantt
 
 ## 功法体系
 
-思想、准则、思维模型、方法与工程流程统一从[功法体系](.github/context/gongfa/README.md)按当前问题选用。
-原来的经验、道法术器、实验性方法和哲学保留为同一集合中的原始文集，不再作为首页独立栏目或分库入口。
-
-逐条身份、内容版本、冻结来源与已有意见查看[功法原始资料](.github/context/gongfa/data.json)及[生成总表](.github/context/gongfa/README.md#全部记录)。
-文集归并不等于全部内容已经逐条登记；已有初评也不等于正式效果验证。
+| 序号 | 说明项 | 内容 |
+|:---:|:---|:---|
+| 1 | 工具的名称 | 功法体系。本区块说明的是一组可复用内容，不对应单一功法。 |
+| 2 | 是什么 | 统一导航思想、准则、思维模型、方法与工程流程；经验、道法术器、实验性方法和哲学作为同一集合中的原始文集保留。 |
+| 3 | 为什么 | 让读者按当前问题选用适用内容，避免从首页分散的旧栏目或独立分库中查找。 |
+| 4 | 怎么做 | 先明确当前任务的问题，再从[功法体系目录](.github/context/gongfa/README.md)选择文集或条目；具体用法以条目说明和来源为准。 |
+| 5 | 扩展 | 需要继续阅读时进入相应原始文集；文集归并本身不创建新的功法身份或登记条目。 |
+| 6 | 关联信息 | [工具解释模板 v0](.github/context/assets/templates/tool-explanation-template-v0.md)规定说明结构；具体类型和边界见[功法体系目录](.github/context/gongfa/README.md)。 |
+| 7 | 出处 | [功法原始资料](.github/context/gongfa/data.json)记录逐条身份、内容版本、冻结来源与已有意见；[生成总表](.github/context/gongfa/README.md#全部记录)用于浏览。 |
+| 8 | 相关图书 | 本区块未列集合级书目；具体书目须按对应条目的来源核实，未核实前不补列。 |
+| 9 | 它要解决什么问题？ | 帮助读者从统一入口按任务找到可参考的思想和方法；集合本身不是单一问题求解器，具体问题由各条目说明。 |
+| 10 | 为什么这样设计？ | 把既有内容保留在同一集合中，既维持原文可追溯，也不恢复经验、道法术器、实验性方法和哲学的首页独立栏目或分库入口。 |
+| 11 | 内部如何实现？ | 以`data.json`为维护数据、由生成器生成README浏览视图；逐条身份、内容版本和来源绑定仍按原登记记录维护。 |
+| 12 | 付出了什么代价？ | 现有总览没有集合级成本测量；不能据此认定维护或应用成本为零，具体限制以各条目来源为准。 |
+| 13 | 比较不同技术与方法。 | 应在同一问题和适用条件下比较具体条目；不同任务中的效果或品级不能直接互比。 |
+| 14 | 提炼共同规律。 | 当前可归纳的共同做法是先看问题，再选择方法；不把目录归类或已有初评当作统一效果证明。 |
+| 15 | 明确这些规律成立的前提与适用条件。 | 选择依赖具体任务和条目的适用条件、限制；文集归并不等于全部内容已经逐条登记，已有初评也不等于正式效果验证。 |
 
 </details>
 
@@ -319,14 +331,23 @@ gantt
 
 ## 法器体系
 
-法器总表整理 Vibe Coding 流程中使用或依赖的工具、可调用入口和依赖类别；固定来源实现、当前运行实例、候选对象与抽象类别分别记录。文件级许可线索仅作支持证据，不等于许可批准或再分发授权。
-
-- [法器体系说明](.github/context/faqi/README.md#doc-faqi-system)：分类边界、重要性分级、选用方式与固定 MCP 源码的副作用边界。
-- [法器重要性总表](.github/context/faqi/README.md#法器总表)：30 项的品级、名称、说明与记录状态。
-- [法器登记源](.github/context/faqi/data.json)：唯一可编辑数据源；生成总表不可手改。
-- [法器类型与正式效能规约](.github/context/gongfa/README.md#doc-cultivation-ontology-taxonomy-法器品级规约)：正式任务效果量表仍为草案。
-
-当前 30 项按 Vibe Coding 重要性暂分天阶 4 项、地阶 12 项、玄阶 9 项、黄阶 5 项。重要性不代表实现质量、运行可用性或效能验证；正式效能评级尚未完成。
+| 序号 | 说明项 | 内容 |
+|:---:|:---|:---|
+| 1 | 工具的名称 | 法器体系。本区块说明工具、入口和依赖的集合，不对应单一产品。 |
+| 2 | 是什么 | 整理 Vibe Coding 流程中使用或依赖的工具、可调用入口和依赖类别；固定来源实现、当前运行实例、候选对象与抽象类别分别记录。 |
+| 3 | 为什么 | 帮助读者理解各对象在 Vibe Coding 工作流中的位置；重要性分级不代表实现质量、运行状态或任务效果。 |
+| 4 | 怎么做 | 先明确任务，再核实具体对象的来源、版本、可用性和权限；选用流程见[法器体系说明](.github/context/faqi/README.md#doc-faqi-system)。 |
+| 5 | 扩展 | 新增或延伸说明须先明确对象身份和来源；抽象依赖类别不自动代表具体产品、部署或已启用能力。 |
+| 6 | 关联信息 | [工具解释模板 v0](.github/context/assets/templates/tool-explanation-template-v0.md)、[法器体系说明](.github/context/faqi/README.md#doc-faqi-system)（分类、重要性、选用方式与固定 MCP 源码副作用边界）及[法器类型与正式效能规约](.github/context/gongfa/README.md#doc-cultivation-ontology-taxonomy-法器品级规约)。 |
+| 7 | 出处 | [法器登记源](.github/context/faqi/data.json)是唯一可编辑数据源；[法器重要性总表](.github/context/faqi/README.md#法器总表)是生成视图。固定来源和选区按登记记录核对，不据此推断当前运行。 |
+| 8 | 相关图书 | 本区块未列集合级书目；具体书目须按对应对象的来源核实，未核实前不补列。 |
+| 9 | 它要解决什么问题？ | 帮助读者识别 Vibe Coding 工作流中的工具角色、可调用入口和依赖类别；它不是某个工具，也不保证对象当前可用。 |
+| 10 | 为什么这样设计？ | 将固定来源实现、运行实例、候选对象和抽象类别分开记录，避免把来源、依赖关系或名称相似误当成同一对象。 |
+| 11 | 内部如何实现？ | 登记数据生成浏览总表；具体实现机制须根据各对象对应的固定来源、版本和选区说明，不能从集合摘要推断。 |
+| 12 | 付出了什么代价？ | 本区块没有集合级成本或效能测量；具体资源代价和副作用须按对象来源核实。文件级许可线索仅作支持证据，不等于许可批准或再分发授权。 |
+| 13 | 比较不同技术与方法。 | 30 项分级比较的是 Vibe Coding 重要性，不是质量或效能；方案比较须限定同一任务、对象层级和适用条件。 |
+| 14 | 提炼共同规律。 | 应分别核对对象身份、重要性、当前运行状态、许可和效果证据；其中一项不能替代其他项。 |
+| 15 | 明确这些规律成立的前提与适用条件。 | 当前 30 项按重要性暂分天阶 4 项、地阶 12 项、玄阶 9 项、黄阶 5 项；重要性不代表实现质量、运行可用性或效能验证。正式效能量表仍为草案，评级尚未完成。 |
 
 </details>