morphiq-rank

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pipeline Position

流水线位置

Step 2 of 4 — consumes morphiq-scan output.

Input: Scan Report (JSON) from morphiq-scan.
Output: Prioritized Roadmap (JSON) → consumed by morphiq-build.
Data contract: See
```
PIPELINE.md
```
§2 for the Prioritized Roadmap schema.

4步中的第2步 — 接收morphiq-scan的输出。

输入： 来自morphiq-scan的扫描报告（JSON格式）
输出： 优先级排序的路线图（JSON格式）→ 供morphiq-build使用
数据契约： 优先级路线图的Schema请参考
```
PIPELINE.md
```
第2节

Purpose

用途

Morphiq Rank transforms raw scan findings into an actionable, prioritized roadmap. It determines severity, assigns progressive discovery tiers, calculates priority scores, and controls how many issues are revealed. The output tells morphiq-build what to fix and in what order.

Morphiq Rank将原始扫描结果转化为可执行的、按优先级排序的路线图。它会确定严重程度、分配递进的发现层级、计算优先级分数，并控制要披露的问题数量。输出内容会告知morphiq-build需要修复什么、按什么顺序修复。

Workflow

工作流程

Step 1: Ingest Scan Report

步骤1：读取扫描报告

Parse the Scan Report JSON. Extract per-page scores, domain-level scores, all identified issues, and the overall pipeline score (0–100).

解析扫描报告JSON，提取单页得分、域名层级得分、所有识别到的问题，以及整体流水线得分（0–100）。

Step 2: Create Issues

步骤2：创建问题

For each finding, create a formal issue:

Field	Description
`id`	Pattern: `{category}-{specific-problem}`
`category`	`agentic_readiness` , `content_quality` , `chunking_retrieval` , `query_fanout` , `policy_files` , `ai_visibility`
`severity`	From issue catalog + escalation rules
`summary`	One-line description
`detail`	Full explanation with AI visibility impact
`affected_urls`	URLs where the issue appears
`remediation_hint`	Actionable fix instruction

For fanout issues, severity depends on parent prompt type fan-out depth.

site:

and citation-producing sub-queries escalate one level.

For

fanout-*

issues, populate

fanout_context

from the scan report's

query_fanout.simulated_queries[]

and

query_fanout.suggested_content[]

. Each simulated query mapping to this issue becomes a

triggering_sub_queries

entry:

```
query
```
← from
```
simulated_queries[].query
```

model_origin

← from

simulated_queries[].model

(rename

model

→

model_origin

)

prompt_type

← from

simulated_queries[].prompt_type

citation_weight

← from

simulated_queries[].citation_weight

```
parent_prompt
```
← for simulated queries, set to
```
"(simulated)"
```
; for
```
suggested_content[]
```
entries, use the
```
suggestion
```
field

If the Delta Report's

content_creation_queue

has entries matching this issue, include their

competitor_sources

fanout_context.competitor_sources[]

Deduplication: Technical issues hash by

brandId + checkCode + pageUrl

. AI visibility issues hash by

brandId + category + title

For all issue types and severity logic, read

references/issue-catalog.md

针对每个发现的问题，创建正式的问题记录：

字段	描述
`id`	格式： `{category}-{specific-problem}`
`category`	`agentic_readiness` , `content_quality` , `chunking_retrieval` , `query_fanout` , `policy_files` , `ai_visibility`
`severity`	来自问题目录 + 升级规则
`summary`	单行描述
`detail`	包含AI可见性影响的完整说明
`affected_urls`	问题出现的URL列表
`remediation_hint`	可执行的修复指导

针对扇出问题，严重程度取决于父提示类型的扇出深度。

site:

类查询和生成引用的子查询会提升一级严重程度。

针对

fanout-*

类问题，从扫描报告的

query_fanout.simulated_queries[]

和

query_fanout.suggested_content[]

中填充

fanout_context

。每个映射到该问题的模拟查询都会成为

triggering_sub_queries

的条目：

```
query
```
← 来自
```
simulated_queries[].query
```

model_origin

← 来自

simulated_queries[].model

（将

model

重命名为

model_origin

）

prompt_type

← 来自

simulated_queries[].prompt_type

citation_weight

← 来自

simulated_queries[].citation_weight

parent_prompt

← 模拟查询设置为

"(simulated)"

；

suggested_content[]

条目使用

suggestion

字段值

如果Delta报告的

content_creation_queue

中有匹配该问题的条目，将其

competitor_sources

加入

fanout_context.competitor_sources[]

。

去重规则： 技术问题按

brandId + checkCode + pageUrl

哈希去重。AI可见性问题按

brandId + category + title

哈希去重。

所有问题类型和严重程度逻辑请查阅

references/issue-catalog.md

。

Step 3: Assign Tiers

步骤3：分配层级

Tier	Name	Primary Categories
1	Foundation — Crawlability & Policy	`policy-*`
2	Structure — Schema & Metadata	`agentic-*`
3	Content — Depth & Coverage	`content-` , `fanout-` , `visibility-*`
4	Optimization — Retrieval Quality	`chunking-*`

Edge cases:

fanout-wrong-page-type

→ Tier 2. Multi-tier issues → lowest applicable tier.

For tier definitions and dependency logic, read

references/tier-progression.md

层级	名称	主要分类
1	基础层 — 可爬取性与政策	`policy-*`
2	结构层 — 模式与元数据	`agentic-*`
3	内容层 — 深度与覆盖度	`content-` , `fanout-` , `visibility-*`
4	优化层 — 检索质量	`chunking-*`

边缘情况：

fanout-wrong-page-type

→ 层级2。跨层级问题 → 适用的最低层级。

层级定义和依赖逻辑请查阅

references/tier-progression.md

。

Step 4: Calculate Priority Scores

步骤4：计算优先级分数

priority = (severity_weight × 0.4) + (page_impact × 0.3) + (citation_potential × 0.2) + (effort_inverse × 0.1)

severity: critical=100, high=75, medium=50, low=25. page_impact: % pages affected. effort_inverse: low=100, medium=50, high=25.

priority = (severity_weight × 0.4) + (page_impact × 0.3) + (citation_potential × 0.2) + (effort_inverse × 0.1)

严重程度权重：critical=100, high=75, medium=50, low=25。page_impact：受影响页面占比。effort_inverse：低工作量=100, 中工作量=50, 高工作量=25。

Step 5: Apply Progressive Reveal

步骤5：应用递进披露规则

Score-based: <30 → fundamental only, ≥30 → +intermediate, ≥60 → +advanced, ≥80 → all tiers.

Page-based: First run = homepage only. Each subsequent run unlocks one more page (home → pricing → features → product → solutions → about → blog → other → docs).

Backlog cap: Max 10 issues in

identified

state.

基于分数： <30 → 仅披露基础问题，≥30 → 增加中级问题，≥60 → 增加高级问题，≥80 → 披露所有层级问题。

基于页面： 首次运行 = 仅披露首页问题。后续每次运行解锁一个更多页面（首页 → 定价页 → 功能页 → 产品页 → 解决方案页 → 关于页 → 博客 → 其他 → 文档）。

待办上限：

identified

状态的问题最多保留10个。

Step 6: Set Dependencies

步骤6：设置依赖关系

Cross-tier:

T1 → T2 → T3 → T4

. Higher-tier issues on same URLs only become actionable when lower-tier issues are resolved. Within-tier explicit dependencies also apply.

跨层级依赖：

T1 → T2 → T3 → T4

。相同URL上的更高层级问题，只有在更低层级问题解决后才会变为可执行状态。同层级内的显式依赖也适用。

Step 7: Produce Prioritized Roadmap

步骤7：生成优先级路线图

Assemble JSON (

PIPELINE.md

§2): issues by tier, sorted by priority, with severity, remediation hints, affected URLs, dependencies, and reveal state metadata.

组装JSON（符合

PIPELINE.md

第2节规范）：按层级分组的问题，按优先级排序，包含严重程度、修复提示、受影响URL、依赖关系和披露状态元数据。

Reconciliation (Re-runs)

对账（重复运行）

On subsequent scans with existing issues:

Auto-close issues where the check now passes (unless PR-linked)
Escalate worsened issues
Create new issues for new findings
Detect regressions (previously completed issues re-appearing)

For issue lifecycle and auto-close logic, read

references/tier-progression.md

后续扫描存在已有问题时：

自动关闭当前检查已通过的问题（除非关联了PR）
升级恶化的问题严重程度
为新发现的问题创建新记录
检测回归问题（之前已完成的问题再次出现）

问题生命周期和自动关闭逻辑请查阅

references/tier-progression.md

。

Reference Files

参考文件

File	Purpose
`references/issue-catalog.md`	All issue types (50+), severity logic, deduplication, check code mapping
`references/tier-progression.md`	4-tier model, dependencies, priority formula, reveal thresholds, lifecycle

文件	用途
`references/issue-catalog.md`	所有问题类型（50+）、严重程度逻辑、去重规则、检查代码映射
`references/tier-progression.md`	4层级模型、依赖关系、优先级公式、披露阈值、生命周期