@fx-data/ai-diagnostics 0.1.20261107142011 → 0.1.20261109015953
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENT_SETUP.md +1 -1
- package/README.md +1 -1
- package/content/docs/index.md +1 -0
- package/content/knowledge/common/workflow.md +1 -1
- package/content/knowledge/component/workflow.md +1 -1
- package/content/knowledge/dashboard/workflow.md +16 -6
- package/content/knowledge/dataset/workflow.md +1 -1
- package/content/knowledge/engine/queries.md +3 -1
- package/content/knowledge/engine/topics/metric-fields.md +1 -1
- package/content/knowledge/signal-index.md +1 -1
- package/content-manifest.json +10 -10
- package/package.json +1 -1
package/AGENT_SETUP.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# FX 数据诊断：Agent 安装与管理
|
|
2
2
|
|
|
3
|
-
本文供执行安装与管理的 Agent 读取，不作为日常诊断的前置上下文。包版本为 `0.1.
|
|
3
|
+
本文供执行安装与管理的 Agent 读取，不作为日常诊断的前置上下文。包版本为 `0.1.20261109015953`，需要 Node.js `>=22` 及 npm。用户只需表达安装、使用、更新或卸载意图，环境准备和客户端登记由 Agent 完成。
|
|
4
4
|
|
|
5
5
|
用户明确要求安装、更新、回退、卸载或检查 FX 数据诊断时，也会触发薄 Skill，并直接执行对应管理命令，不先运行 `context` 或读取诊断规则；只有开始诊断时才按薄 Skill 加载内容。普通聊天不主动加载。
|
|
6
6
|
|
package/README.md
CHANGED
|
@@ -38,4 +38,4 @@
|
|
|
38
38
|
|
|
39
39
|
---
|
|
40
40
|
|
|
41
|
-
**给 Agent：** 按 [Agent 执行说明](https://unpkg.com/@fx-data/ai-diagnostics@0.1.
|
|
41
|
+
**给 Agent：** 按 [Agent 执行说明](https://unpkg.com/@fx-data/ai-diagnostics@0.1.20261109015953/AGENT_SETUP.md) 完成安装与管理。已有本地包时，优先读取包内 `AGENT_SETUP.md`；本地 `.tgz` 只需读取 `package/AGENT_SETUP.md`。按命令结果简短反馈，成功即结束；只有失败或结果不完整时才排错。
|
package/content/docs/index.md
CHANGED
|
@@ -30,6 +30,7 @@
|
|
|
30
30
|
| 某个场景域的入手提示、候选假设与易错点 | 各域 `workflow.md`，见[知识目录](../knowledge/README.md) |
|
|
31
31
|
| 安装、配置或恢复 SigNoZ MCP | [配置 SigNoZ MCP](../knowledge/common/topics/setup-signoz-mcp.md) |
|
|
32
32
|
| 引擎任务定位、MetricOuts 正文获取与复用 | [Metric 获取](../knowledge/engine/queries.md) |
|
|
33
|
+
| 慢或失败的引擎执行何时必须读取 Metric、跳过条件 | [Metric 获取](../knowledge/engine/queries.md) |
|
|
33
34
|
| Metric 字段含义 | [Metric 解读](../knowledge/engine/conclusions.md) |
|
|
34
35
|
| 常见引擎性能问题的判断方法 | [常见引擎性能问题](../knowledge/engine/topics/patterns.md) |
|
|
35
36
|
| 分析表 / 组件 / 仪表板的业务概念、入口 span 与 attribute | [分析表](../knowledge/dataset/README.md)、[组件](../knowledge/component/README.md)、[仪表板](../knowledge/dashboard/README.md) |
|
|
@@ -15,7 +15,7 @@
|
|
|
15
15
|
|
|
16
16
|
- OOM、超时、行数上限是直接失败条件，不是根因。报错位置多半在引擎，原因多半在业务场景：在引擎里看清撞了什么线以后，回到场景域找是什么让计算变得这么大：分析表是哪个步骤放大了数据，更新是哪个节点或哪个上游，组件和仪表板是查询、筛选、参数或绑定。建议也要落在这一层。
|
|
17
17
|
- 已取消或没提交的执行（比如日志里有 `not submitted, skip finish`）根本没开始计算，有 task ID、Metric 链接或一个整数超时时长都证明不了算过。这时该解释的是取消链、等待或准入，没必要再去找计算统计。
|
|
18
|
-
-
|
|
18
|
+
- 选定慢或失败的引擎执行后，按[Metric 获取要求](../engine/queries.md)主动取数并分析。如果只看到业务层的 `polars query timeout`，先补读这次执行的属性，或者从同一个 trace 的提交日志里找回 task，别急着认定 Metric 拿不到。
|
|
19
19
|
- 用户说“之前没超限”“以前正常”，但近几天找不到这个对象成功的记录时，就直接告诉用户：近 N 天没找到成功记录，和“之前正常”对不上，请他确认是哪张表、什么时候开始异常。不要顺着用户的说法去解释“为什么这次变了”。
|
|
20
20
|
- 单次失败不需要成功样本。用户要求对比，或者手上正好有可比的成功执行，再去对比，目标和基线各自固定自己的范围。
|
|
21
21
|
- 业务解释和 Metric 谁也替代不了谁：慢 span 只告诉你慢在哪一段，Metric 只解释进入引擎以后的事。
|
|
@@ -7,7 +7,7 @@
|
|
|
7
7
|
- 先分清是图表编辑时的预览、仪表板里的组件请求，还是仪表板以外的图表预览。仪表板组件预览入口按[来源判定](../common/signals.md#仪表板组件预览入口)确认；来自仪表板的，直接转到[仪表板知识](../dashboard/workflow.md)。用户只说“图表慢、超时”时，第一步就是做这个区分。
|
|
8
8
|
- 记下组件、绑定表、筛选、联动和权限上下文、环境、时间窗，以及用户感觉到的耗时。用精确 ID、请求上下文和时间窗缩小候选执行，不要按最慢的 span 挑。
|
|
9
9
|
- 主要看三件事：一次是不是触发了多个查询，或者带了复杂的筛选、联动、聚合、排序；trace 里耗时集中在哪个阶段；绑定分析表的资源版本或更新状态和这次有没有关系。
|
|
10
|
-
-
|
|
10
|
+
- 选定慢或失败的引擎执行后，进入[引擎排查](../engine/workflow.md)，按[Metric 获取要求](../engine/queries.md)补齐执行分析；线索指向分析表或更新时，转到对应的域。
|
|
11
11
|
|
|
12
12
|
## 常见现象与候选假设
|
|
13
13
|
|
|
@@ -6,26 +6,36 @@
|
|
|
6
6
|
|
|
7
7
|
- 报错落在引擎里（超时、内存超限）时，引擎只说明撞了什么线，原因回到下面还原的业务计算里找。
|
|
8
8
|
- **先分清是哪类取数**：筛选器取候选值只看它怎么算候选值、别的筛选器带来什么影响；组件取数看组件自己的查询。组件请求里带着筛选条件，不代表是筛选器自身取数。
|
|
9
|
+
- **组件最终只显示少量数据，不代表只计算这些数据**：筛选器、参数、动态字段和行列权限都可能改变本次计算，使组件不能直接读取已有结果，而要展开来源表、关联、汇总等上游计算。重点看条件作用在哪张表、涉及哪些路径、实际多算了什么，不只看组件绑定表的大小或条件个数，见下面的[计算范围为何变大](#计算范围为何变大)。
|
|
9
10
|
- **优先用 trace 的 span attribute 还原本次具体业务计算**：组件算哪些查询、用了哪些字段、聚合和排序；根表、绑定表、筛选字段所在表及它们之间的完整路径；筛选、参数、权限、自动联动、组件间联动各加了什么；数据范围有没有被父表路径、无关字段、重复分支或不合理的绑定放大。先据此判断计算复杂度，再看引擎，别一上来就按慢 span 找 Metric。
|
|
10
11
|
- 筛选树多层或多分支时还原成完整的树，见[筛选树还原与交付](topics/filter-tree.md)；筛选器或动态字段只剩 ID 时见[名称关联取证](topics/name-binding.md)；怀疑上游被重算见[动态字段覆盖](topics/dynamic-fields.md)；默认详情缺业务 attribute 时按[取证例子](queries.md)定向补。
|
|
11
12
|
- **筛选值变化后变慢**：能看出属于同一次筛选、或落在可靠时间边界内的组件请求，算这次受影响的集合；全部受影响组件刷新完成才是用户感觉的“好了”。分清是“影响范围大”还是“某一个算得慢”。没看到其他组件请求，不等于配置上绝对没有其他目标，要确认按[核对配置影响范围](conclusions.md#核对配置影响范围)读 targets。
|
|
12
|
-
-
|
|
13
|
-
- 慢或失败的引擎执行看[引擎知识](../engine/workflow.md)，业务上解释通了也最好补上。关键组件、绑定表或更新状态可疑时转[分析表](../dataset/workflow.md)或[更新](../update/workflow.md)。
|
|
13
|
+
- 选定慢或失败的引擎执行后，进入[引擎排查](../engine/workflow.md)，按[Metric 获取要求](../engine/queries.md)补齐执行分析，再结合业务计算解释原因。关键组件、绑定表或更新状态可疑时转[分析表](../dataset/workflow.md)或[更新](../update/workflow.md)。
|
|
14
14
|
|
|
15
15
|
## 组件取数先做对照
|
|
16
16
|
|
|
17
17
|
认出是仪表板里的组件计算后，主动去找这个组件单独预览的记录，不用等用户说“单独看是好的”。查找范围见[仪表板内外组件对照](../common/topics/baseline-comparison.md#仪表板内外组件对照)，可比性和成功判定见[组件计算对照怎么判断](topics/component-comparison.md#组件计算对照怎么判断)。
|
|
18
18
|
|
|
19
|
-
-
|
|
19
|
+
- 单独预览成功、仪表板里失败或变慢：逐项核对下面四类条件和联动，比较两侧直接读已有结果还是展开了上游计算；只因入口不同不能下结论。
|
|
20
20
|
- 两边都异常：先查共同部分，即组件查询、输入数据和计算链。
|
|
21
21
|
- 没找到对照：照样分析手上的异常 trace，同时提醒用户看看单独预览时是否也异常。仪表板里很快成功的请求只说明有另一条计算路径，不能当单独预览。
|
|
22
22
|
|
|
23
|
+
## 计算范围为何变大
|
|
24
|
+
|
|
25
|
+
筛选器、参数、动态字段、行列权限都要核对，不能看到其中一项就停止检查其他项。它们可能同时作用，也可能不增加计算；按本次请求、条件所在表和实际计划判断。
|
|
26
|
+
|
|
27
|
+
- **筛选器**：筛选条件绑在较上层父表，或经多条路径影响组件时，可能需要展开来源表、关联和汇总，带来额外计算。看筛选绑定和最终条件树，核对条件所在表到组件查询表的完整路径；联动带来的条件也要计入。不能因筛选后返回更少，就认定计算一定更少。判断与展示见[筛选树](topics/filter-tree.md)，绑定调整的前提见[配置影响范围](conclusions.md#核对配置影响范围)。
|
|
28
|
+
- **参数**：参数改变上游计算的输入或表达式，可能使已有结果无法直接复用；绑定越靠上游，受影响的计算链可能越长。核对本次参数、页面上的绑定表和实际展开的路径；筛选树为空也不能排除参数影响。深层绑定的候选现象与建议前提见[参数案例](../cases/dashboard-parameter-deep-binding.md)。
|
|
29
|
+
- **动态字段**：替换上游计算字段后，下游可能需要按新字段重新展开计算。先确认本次是否有覆盖、覆盖在哪条表路径上，再核对实际计划；普通参数统计为空不能排除动态字段。取证与停止边界见[动态字段覆盖](topics/dynamic-fields.md)。
|
|
30
|
+
- **行列权限**：权限条件及可见字段可能改变本次可读取的数据和查询计划；权限作用于上游表时，也可能带入额外的计算路径。核对本次权限上下文、作用表和实际计划，不把“有权限条件”直接当作重算原因。入口只有权限标记、没有作用位置时，保留为上下文，不猜挂到某张表，见[筛选树中的权限边界](topics/filter-tree.md#名称绑定与展示)。
|
|
31
|
+
|
|
32
|
+
把条件带来的计算变化与资源压力对上：先看两侧直接读已有结果还是展开了上游，再看查询长度、涉及的表路径和对应 Metric 中的计划、数据规模、耗时及内存。查询变长、路径变深只是线索，不能单独证明是哪项条件导致超时或内存超限。建议落到已核实的绑定或计算上；调整筛选、参数、动态字段或权限前，都要确认结果口径和权限语义。
|
|
33
|
+
|
|
23
34
|
## 常见现象与候选假设
|
|
24
35
|
|
|
25
36
|
- **筛选器自身取数慢**：来源表或绑定字段多、自动解析读的范围大；别的筛选器带进的条件让查询变大；来源表的上游状态成了关键路径。对比读进来的数据量和最后的候选值数量。配了多个字段不一定慢，“按钮组绑了几个大字段又是自动解析”只是假设，不直接建议改手动解析。
|
|
26
|
-
-
|
|
27
|
-
-
|
|
28
|
-
- **单独预览正常，仪表板里展开上游后超限**：核查过的案例里，单独预览直接读几行保存好的汇总；仪表板里失败那次带了上游动态字段覆盖，展开了几路明细、关联和缓存后撞上内存上限。同一仪表板也有很快成功的请求，“在仪表板里”本身解释不了差异。先看有没有动态字段覆盖、覆盖所在表到组件查询表的路径；名称映射补不出失败那次选的值，历史请求也不能冒充失败 trace 的属性。
|
|
37
|
+
- **组件取数慢**：先区分组件自身查询重，还是上述条件扩大了计算范围；一次动作触发多个组件时，再分清影响范围与关键慢组件，不把请求数直接当作计算复杂度。
|
|
38
|
+
- **查询语句很长、优化器超时或内存超限**：按[查询规模信号](../engine/signals.md#查询规模信号)看 `dax length`、上游查找和实际计划，再沿四类条件核对触发因素，不只查参数。优化器超时看对应错误中的 limit；内存超限看同 task 错误，不仅凭查询长度或内存峰值判定。
|
|
29
39
|
|
|
30
40
|
## 易错点
|
|
31
41
|
|
|
@@ -8,7 +8,7 @@
|
|
|
8
8
|
- 记下表、选中的步骤、环境、时间窗和配置版本。手上有精确的 trace 或请求，就围绕它分析。
|
|
9
9
|
- 现象比较笼统时，把候选执行按类型和成功、失败粗分一下。不要从最慢的成功预览直接推断用户目标。
|
|
10
10
|
- 报错落在引擎里（内存超限、行数超限、超时）时，引擎只说明撞了什么线，原因要回到步骤里找：哪一步把数据放大了，或者要攒齐整批数据，见[分析步骤](topics/steps.md#哪些步骤容易慢或爆内存)。
|
|
11
|
-
-
|
|
11
|
+
- 选定慢或失败的引擎执行后，进入[引擎排查](../engine/workflow.md)，按[Metric 获取要求](../engine/queries.md)解释物理上怎么算的；线索指向后台更新或组件、仪表板，就转到[更新](../update/workflow.md)或对应的域。
|
|
12
12
|
|
|
13
13
|
## 常见现象与候选假设
|
|
14
14
|
|
|
@@ -1,6 +1,8 @@
|
|
|
1
1
|
# 引擎 · 查询方法
|
|
2
2
|
|
|
3
|
-
engine Metric 用来解释已经锁定的执行：这次计算处理了多少数据、耗时和内存花在哪、因为什么失败。这里写怎么从 trace 找到任务、怎么取 Metric 正文；字段含义见[Metric 字段速查](topics/metric-fields.md)，判读口径见[能下什么结论](conclusions.md)。环境、时间、预算和大结果遵守[公共查询规则](../common/queries.md)
|
|
3
|
+
engine Metric 用来解释已经锁定的执行：这次计算处理了多少数据、耗时和内存花在哪、因为什么失败。这里写怎么从 trace 找到任务、怎么取 Metric 正文；字段含义见[Metric 字段速查](topics/metric-fields.md)，判读口径见[能下什么结论](conclusions.md)。环境、时间、预算和大结果遵守[公共查询规则](../common/queries.md)。
|
|
4
|
+
|
|
5
|
+
选定慢或失败的引擎执行后，主动获取并分析对应 Metric，业务上的候选原因不能替代这一步。已有正文直接复用；只有明确未提交、用户不允许查询或按本页方法仍取不到时才跳过，并说明原因和结论限制。离线材料缺 Metric 时，明确列为待补材料，不把它写成可选建议。
|
|
4
6
|
|
|
5
7
|
## 目录
|
|
6
8
|
|
|
@@ -45,7 +45,7 @@
|
|
|
45
45
|
| 字段 | 是什么 | 诊断时怎么用 |
|
|
46
46
|
|---|---|---|
|
|
47
47
|
| `node_id` | 在哪个引擎节点上跑 | 同节点多个任务一起慢时，可以按它归类 |
|
|
48
|
-
| `query_peak_memory`、`query_memory_limit` | 这个任务的内存峰值和上限 |
|
|
48
|
+
| `query_peak_memory`、`query_memory_limit` | 这个任务的内存峰值和上限 | 贴近上限表示内存压力大；是否超限以同 task 的错误为准 |
|
|
49
49
|
| `query_memory_allocated`、`query_memory_deallocated` | 累计申请、释放的内存 | 是累计量，不是峰值，不能拿来和上限比 |
|
|
50
50
|
| `global_current_memory`、`global_memory_limit` | 整个引擎节点当前占用和上限 | 任务自己不大、节点整体很满时，可能是被同节点的别的任务挤的 |
|
|
51
51
|
| `spillBytes` | 吐磁盘的字节数 | 不为 0 说明写过磁盘 |
|
|
@@ -105,7 +105,7 @@
|
|
|
105
105
|
| `taskName`、`metric`、`polars.taskId`、`QueryExecutor`、`v2.execute.query` | trace 上的引擎任务标识与统计链接 | [已有 trace 时取哪些字段](engine/queries.md#已有-trace-时取哪些字段) |
|
|
106
106
|
| `elapsed_time`、`optimizer_cost`、`query_memory_limit`、`morsel_blocked_time`、`scanned_rows_num`、`table_scan_cache_result_queue_size` | MPP Metric 各层字段：任务总耗时、优化耗时、内存上限、执行单元挂起、读表行数、读表瓶颈 | [Metric 字段速查](engine/topics/metric-fields.md) |
|
|
107
107
|
| `MetricOuts` | 引擎统计日志的 logger，按 task 和时间窗取 | [Metric 链接与任务日志](engine/queries.md#metric-链接与任务日志) |
|
|
108
|
-
| `queryCount`、`rowCount`（查询埋点） | V1
|
|
108
|
+
| `queryCount`、`rowCount`（查询埋点） | V1 查询埋点：尝试序号、计数值及适用限制 | [V1 查询埋点与完成边界](engine/queries.md#v1-查询埋点与完成边界) |
|
|
109
109
|
| `compute.retry.pipeline_parallelism_reduced` | 数据源湖写入内存不足后降并行度重试 | [更新 Write 链路](engine/queries.md#更新-write-链路) |
|
|
110
110
|
|
|
111
111
|
## 通用
|
package/content-manifest.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schema_version": 1,
|
|
3
|
-
"version": "0.1.
|
|
4
|
-
"source_commit": "
|
|
3
|
+
"version": "0.1.20261109015953",
|
|
4
|
+
"source_commit": "408a99053c5d8a3974331e546f154cb06d081cb8",
|
|
5
5
|
"source_dirty": false,
|
|
6
6
|
"cli_sha256": "08aa66f145e51627bf71c9e12ec7ae01907e130ad9ce6056b2ea37262ce92be0",
|
|
7
7
|
"files": {
|
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
"docs/architecture.md": "6a0d602927789ee6d463f26a7eab45661a730c3a87164ab44aae63235a191fb0",
|
|
11
11
|
"docs/diagnostic-feedback.md": "6ebade7a0fc65171e0075a63f5d1f526407a5a30789fa7941df48995dab56918",
|
|
12
12
|
"docs/diagnostic-report.md": "8cf3f19051062a44ecc23635d1ac4ad210863521290be11d808ec2d14c53ca84",
|
|
13
|
-
"docs/index.md": "
|
|
13
|
+
"docs/index.md": "3ebe2ea38f9378d9b8740d7eb6da9fd0f4612ca615f42d52f4ff71ffc059865e",
|
|
14
14
|
"docs/scenario-guide.md": "d8e8ac19b40fdc395a4433d6be47b93885472f6ac535936c0cc2f3f6672f97fa",
|
|
15
15
|
"knowledge/README.md": "b0ac5f8865b93947a79f9991c4310164536f69e26c884486b8080fa51c3c2fe4",
|
|
16
16
|
"knowledge/cases/README.md": "43dc70f8e69ee64617e8af23234fb9729b3c45675cee768ba43acb218d4b3c62",
|
|
@@ -27,13 +27,13 @@
|
|
|
27
27
|
"knowledge/common/topics/query-example.md": "1f94c3d1f5dac77936ecb88f023a123fcaae228dd00303801a62ee94a3706cd1",
|
|
28
28
|
"knowledge/common/topics/setup-signoz-mcp.md": "f5de34eed827f338bc8733eae8dc1faf0f78eb3ff88a8fc2cee54eff73160242",
|
|
29
29
|
"knowledge/common/topics/start-and-anchors.md": "97fc86edd62eff227274e8a027a19a23dce60cfd999f7b5e480fdd4f8adee254",
|
|
30
|
-
"knowledge/common/workflow.md": "
|
|
30
|
+
"knowledge/common/workflow.md": "dc8dbcefa4967fc7f3dfcd575753486149068644bffb86fba5cb6541b9841336",
|
|
31
31
|
"knowledge/component/README.md": "d0d99e14f9f36d74216306c892730f3fba838a01e40c7565e5bec53d28f09fda",
|
|
32
32
|
"knowledge/component/concepts.md": "6e8c4c7a29fe1e3bc7ab964f6a8c59f6702a139c9640b2b7cf0c181f506fa9c5",
|
|
33
33
|
"knowledge/component/conclusions.md": "dfcc38a6a36ca0e89bfeb5d300a2be00447d894de3879ecf508dead9ecd35343",
|
|
34
34
|
"knowledge/component/queries.md": "c641ce3de9019c78462cc6bb152926908bfb3e2d3857f1d34d39df714fd281a9",
|
|
35
35
|
"knowledge/component/signals.md": "e7c38f5b9d5b0a2220dd37f980c7c23db00982d598551c437d0a0b87de68b9d5",
|
|
36
|
-
"knowledge/component/workflow.md": "
|
|
36
|
+
"knowledge/component/workflow.md": "5217899817ff5e9b17ceb9989dc0021e34f5c58ff7deb861b64c4198aaa8fc96",
|
|
37
37
|
"knowledge/dashboard/README.md": "a9454cdf63c3df04b142df39f19f6d422d1e0db67fdb8129c7dd51d07850f1b3",
|
|
38
38
|
"knowledge/dashboard/concepts.md": "4694f2366c1112f2aaeaf22d298d9195ef77ee969b9a9dc6bf4457c771cd319a",
|
|
39
39
|
"knowledge/dashboard/conclusions.md": "08541d4e3b678c5da0faa348d9ba8bedb23a6ad2ed67a13f4bd3f329df426420",
|
|
@@ -43,23 +43,23 @@
|
|
|
43
43
|
"knowledge/dashboard/topics/dynamic-fields.md": "577e72a22ef6216f3278a6d7c5ee67c74274aba9cd825d1fff79d0293e6817aa",
|
|
44
44
|
"knowledge/dashboard/topics/filter-tree.md": "53a8edc62b2554a8fb3cd385aafaf60c671cdaa88107d120e9f193e4d1306dd5",
|
|
45
45
|
"knowledge/dashboard/topics/name-binding.md": "280cbebbd672746968b9a8100c40f552e46d214a72917928a7db6dc49eb339a9",
|
|
46
|
-
"knowledge/dashboard/workflow.md": "
|
|
46
|
+
"knowledge/dashboard/workflow.md": "bbea78ffd6c18ac5ea908091a958811dd3fda8e8abf6e3ecf91112a28e1a5146",
|
|
47
47
|
"knowledge/dataset/README.md": "2d2e36262da86d920b4c09f57fe67b0957aedc13f2d1d3d49d3c8bfad0266c21",
|
|
48
48
|
"knowledge/dataset/concepts.md": "87f90d101f20d0233ca4f524eabd9c128d6060c9a22e940b903708e411c698aa",
|
|
49
49
|
"knowledge/dataset/conclusions.md": "010389c78d6d78aef9f4792e21ba5c78eecce4da2fe2b47e9ee35602babb8dcc",
|
|
50
50
|
"knowledge/dataset/queries.md": "3bb528f46d9c9b692c1893c9a1cf91f5a5667ae2efd6adf603b635c515e2c4ef",
|
|
51
51
|
"knowledge/dataset/signals.md": "ce6b2d7874d22b914ba6af958f7b57aa5abaa69788a7a1c57a64e7de59419a2b",
|
|
52
52
|
"knowledge/dataset/topics/steps.md": "dbff53413a0d4e5da5da99453c13cafa21c59238abc8197d948804d484cd21a6",
|
|
53
|
-
"knowledge/dataset/workflow.md": "
|
|
53
|
+
"knowledge/dataset/workflow.md": "c92bde69195eb6cdec34d3cf025524a4a6a7af6fabade2d937fa78bd5840948b",
|
|
54
54
|
"knowledge/engine/README.md": "d76b005708218863fc4fd6657bf731a430cdcb896db7883bf240c5e820ac1ea7",
|
|
55
55
|
"knowledge/engine/concepts.md": "544988cada6afad13ce1ea4f19869cfb39e76730b8cfe3f6fde06b86991130fc",
|
|
56
56
|
"knowledge/engine/conclusions.md": "ae1e2c805bf19143ebc3e92ae14ec81f3f094acd3ca120069442a3bbb1ae2128",
|
|
57
|
-
"knowledge/engine/queries.md": "
|
|
57
|
+
"knowledge/engine/queries.md": "bbbdc523be86fd98b6df98958ff6fe03e2656673a20e1f27fb3e72861a058936",
|
|
58
58
|
"knowledge/engine/signals.md": "02ab7e88dc3ae155a0623108d3023149229e5c64cf358e383df419e4983278b5",
|
|
59
|
-
"knowledge/engine/topics/metric-fields.md": "
|
|
59
|
+
"knowledge/engine/topics/metric-fields.md": "2171f383a7c49b38ecf49ed9a0a726b87eaaac6da9f48f00140f6758dd26f458",
|
|
60
60
|
"knowledge/engine/topics/patterns.md": "c45555888c59f6b485343587bfe949c1b8fd198bbd65ba3d29cb296cc343869b",
|
|
61
61
|
"knowledge/engine/workflow.md": "9f2036a4f65e50b02879fbb261d1f51b56a0fbae54b5ceeedd645912ec1d20e8",
|
|
62
|
-
"knowledge/signal-index.md": "
|
|
62
|
+
"knowledge/signal-index.md": "0e0d0dafe88bc17443a2b3d874703ed41a15e50f43a050070c93277cdbcae69e",
|
|
63
63
|
"knowledge/update/README.md": "c20401cf360a424a974e52bb40ae80e760c5584fa557ab3e3712035a33a8ba4a",
|
|
64
64
|
"knowledge/update/concepts.md": "e77334a69a5d85a0b12090143a4da7e4d727e78ef6f8235b6221b433f0a6bd1c",
|
|
65
65
|
"knowledge/update/conclusions.md": "3c0ae1de501ec4794b036c44d5c920245870db46c49839779356a951e3757e90",
|