Improve Archify Support for BI Dataflows and Metric Analysis/增强 Archify 对 BI 数据流和指标分析场景的支持

[mogesangop]

Hi @tt-a1i,

I use Archify for BI and metric-analysis workflows. In this scenario,
the pipeline usually includes SQL data sources, in-memory aggregation,
remote service calls, data sensitivity boundaries, and persistence.

I have a focused proposal to improve the BI authoring guidance:

• make dataflow diagrams clearer for BI pipelines and metric lineage;
• generate an optional companion SQL file for executable data-source steps;
• represent in-memory aggregation as documented SQL comments;
• explicitly mark remote calls as non-SQL steps;
• keep the existing schema and backward compatibility unchanged.

I have a local implementation based on the latest main branch, together
with examples and validation results.

Would you prefer this as a documentation/Skill PR, or should it be
discussed as a broader BI-oriented feature first?

你好 @tt-a1i，

我在 BI 和指标分析场景中使用 Archify 时发现，这类流程通常同时包含：

• SQL 数据源
• 内存中的数据聚合与计算
• Feign/HTTP 等远程服务调用
• 数据敏感性和流转边界
• 指标结果持久化

目前使用 Dataflow 或 Workflow 描述这类流程时，数据来源、指标计算逻辑和最终落库过程不容易完整表达。尤其是完整 SQL 不适合直接放在卡片内容中，也不方便复制执行。

我准备了一份面向 BI 场景的改进方案：

1. 增强 BI 数据管道和指标血缘的编写指导；
2. 支持可选的伴随式 .sql 文件；
3. 将内存聚合逻辑以等价 SQL 注释的形式记录；
4. 明确标记远程服务调用不是直接 SQL；
5. 保持现有 Schema 和向后兼容性不变。

我已经基于最新的 main 分支完成了本地实现，并准备了脱敏示例和验证结果。

想先请教一下：你更倾向于把它作为一个文档/Skill 改进 PR，还是应该先作为一个更大的 BI 场景功能进行讨论？

如果方向合适，我可以继续整理成一个范围明确的 Pull Request。

[tt-a1i]

Thanks for sharing this. I can see the problem you are trying to solve: in a BI flow, SQL, in-memory computation, remote calls, and persistence can easily look like the same kind of step even though they happen in very different places.

Before we change the docs or the shipped Skill, I would like to check whether most of this can already be handled with a more explicit prompt. The current dataflow model can represent sources, transforms, services, sensitivity boundaries, stores, labels, and classifications, so this may be an authoring issue rather than a missing capability.

Could you share one small sanitized example here in the Discussion and compare:

1. what Archify produces with the current general prompt;
2. what it produces when the prompt explicitly asks it to distinguish executable SQL, in-memory computation, Feign/HTTP calls, sensitivity boundaries, and persistence;
3. what still cannot be expressed after that.

For the companion SQL file, it would also help to clarify who creates it and whether it contains real executable SQL or explanatory pseudocode. We should be careful not to present a SQL-style explanation of application logic as something executable or verified equivalent to the real code.

Let us keep this in the Discussion for now rather than moving directly to a PR. If a focused prompt already gives the intended result, a reusable prompt example may be enough. If not, the before-and-after example should make the actual product gap much clearer.