@guanlin4924/devflow-pi 0.1.0

package/plugins/devflow-core/skills/workflow-orchestrator/templates/uat-remediation.yaml

@@ -0,0 +1,143 @@
+schema_version: 1
+id: uat-remediation
+name: Verify Failure Remediation
+description: >
+  Generic remediation flow for failed verification or rejected acceptance checkpoints.
+
+entry:
+  from_flow: feature-development
+  from_step: verify
+  triggers:
+    state_statuses:
+      - failed
+    checkpoint_decisions:
+      - rejected
+      - needs_fix
+    artifact_statuses:
+      - failed
+  initial_step: diagnose
+
+state_contract:
+  source: ".planning/STATE.md"
+  suggested_transition:
+    current_flow: uat-remediation
+    current_step: diagnose
+    status: in_progress
+    completed_steps: []
+    pending_steps:
+      - diagnose
+      - execute-fix
+      - reverify
+      - lesson
+
+variables:
+  feature:
+    source: state.current_feature
+  phase:
+    source: state.current_phase
+
+lessons_policy:
+  sources:
+    - path: ".context/lessons/README.md"
+      required: false
+    - path: ".planning/lessons/README.md"
+      required: false
+  selection:
+    enabled: true
+    max_candidates: 8
+    min_score: 1
+  write:
+    enabled: true
+    default_dir: ".context/lessons"
+    index_path: ".context/lessons/README.md"
+    template_only: true
+
+steps:
+  - id: diagnose
+    order: 10
+    label: Diagnose failure
+    skill: workflow-bug-fix
+    depends_on: []
+    inputs:
+      - ".planning/phases/{phase}/01-UAT.md"
+      - ".planning/phases/{phase}/01-VERIFICATION.md"
+      - ".planning/phases/{phase}/SUMMARY.md"
+      - ".planning/features/{feature}/PROGRESS.md"
+      - ".planning/artifacts/index.yaml"
+    outputs:
+      - path: ".planning/phases/{phase}/REMEDIATION.md"
+        type: remediation-diagnosis
+        required: true
+
+  - id: execute-fix
+    order: 20
+    label: Execute fix
+    skill: workflow-execute-phase
+    depends_on:
+      - diagnose
+    inputs:
+      - ".planning/phases/{phase}/REMEDIATION.md"
+      - ".planning/features/{feature}/变更清单.md"
+      - ".planning/features/{feature}/PROGRESS.md"
+    outputs:
+      - path: ".planning/phases/{phase}/REMEDIATION-SUMMARY.md"
+        type: remediation-summary
+        required: true
+
+  - id: code-index-refresh
+    order: 25
+    label: Code index refresh
+    skill: workflow-code-index
+    depends_on:
+      - execute-fix
+    inputs:
+      - ".planning/phases/{phase}/REMEDIATION-SUMMARY.md"
+      - ".planning/features/{feature}/变更清单.md"
+      - ".planning/features/{feature}/PROGRESS.md"
+    outputs:
+      - path: ".planning/code-index/index.sqlite"
+        type: code-index-sqlite
+        required: true
+      - path: ".planning/code-index/AUDIT.md"
+        type: code-index-audit
+        required: true
+
+  - id: reverify
+    order: 30
+    label: Reverify
+    skill: workflow-verify-work
+    depends_on:
+      - code-index-refresh
+    inputs:
+      - ".planning/phases/{phase}/REMEDIATION-SUMMARY.md"
+      - ".planning/features/{feature}/PROGRESS.md"
+    outputs:
+      - path: ".planning/phases/{phase}/01-UAT.md"
+        type: uat-report
+        required: true
+      - path: ".planning/phases/{phase}/01-VERIFICATION.md"
+        type: verification-report
+        required: true
+    checkpoint: CP-4
+
+  - id: lesson
+    order: 40
+    label: Record lesson if needed
+    action: write-lesson-if-needed
+    depends_on:
+      - reverify
+    inputs:
+      - ".planning/phases/{phase}/REMEDIATION.md"
+      - ".planning/phases/{phase}/01-UAT.md"
+      - ".planning/phases/{phase}/01-VERIFICATION.md"
+    outputs:
+      - path: ".context/lessons/README.md"
+        type: lessons-index
+        required: false
+
+return_to:
+  flow: feature-development
+  step: verify
+  status: waiting_checkpoint
+  checkpoint: CP-4
+  condition: "reverify outputs pass and user confirms CP-4"

package/plugins/devflow-core/skills/workflow-orchestrator/templates/workflows-README.md

@@ -0,0 +1,10 @@
+# Workflow Runtime Files
+
+These files are generated and validated by the Devflow OMP runtime.
+
+- Inspect state with `devflow_state(action="inspect")`.
+- Initialize a feature with `devflow_bootstrap(feature="...", phase="...")`.
+- Advance only with `devflow_transition`.
+- Rebuild the artifact registry with `devflow_artifact(action="sync")`.
+
+Do not edit workflow state or artifact registry files directly.

package/plugins/devflow-core/skills/workflow-pipeline/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: workflow-pipeline
+description: Use when running or resuming the full .planning delivery pipeline from requirements through implementation, verification, audit, and milestone archive.
+---
+
+<objective>
+全链路研发交付入口。解析用户参数，先确保需求主链“入口分诊 → 探索地图 → 领域建模 → 可实现性审查”完成，再检测当前状态，然后委托 workflow-orchestrator 接管后续所有步骤调度。
+pipeline 本身不包含执行规则——所有门禁、CP 协议、失败分支、并行窗口、lessons 注入规则均由 orchestrator 维护。
+</objective>
+
+<process>
+
+## 0. 解析参数
+
+解析 `$ARGUMENTS`：
+
+- **功能名**：第一个不以 `@` 或 `--` 开头的参数
+- **需求文档**：以 `@` 开头的参数（如 `@prd.md`），去掉 `@` 即为文件路径
+- **`--resume`**：从 state 记录的位置继续
+- **`--step N`**：从以下步骤编号开始
+
+### 步骤编号（双轨制）
+
+| 编号 | 步骤 | 说明 |
+|:----:|------|------|
+| 5 | requirement-triage | 需求入口分诊 |
+| 6 | requirement-wayfinder | 需求探索地图 |
+| 7 | domain-modeling | 领域模型 |
+| 8 | requirement-feasibility-review | 可实现性审查 |
+| 10 | requirement-baseline | 需求基线 |
+| 15 | api-contract | API 契约（分叉前共同事实） |
+| 20 | ui-spec | Track B：UI 设计规范 |
+| 30 | feature-breakdown | Track B：功能点梳理 |
+| 40 | backend-tech-spec | Track A：后端方案 |
+| 45 | api-call-guide | Track A：API 调用指南 |
+| 50 | frontend-tech-spec | Track B：前端方案 |
+| 58 | integration-verify | Merge Gate：契约/后端/前端三方一致性验证 |
+| 60 | change-plan | 变更清单 |
+| 70 | phase-structure | Phase 结构初始化 |
+| 80 | execute | 代码执行 |
+| 84 | code-index-refresh | 刷新机器代码索引并审查 |
+| 85 | code-review | 代码审查（完成标准验证） |
+| 86 | generate-mainflow-cases | 主流程自动化用例生成 |
+| 90 | verify | UAT 验收 |
+| 100 | audit | 里程碑审计 |
+| 110 | update-navigation | 更新导航 |
+| 120 | archive | 里程碑归档 |
+
+- **`--track A`**：后端/API 轨道产物模式。可跑 `requirement-triage → requirement-wayfinder → domain-modeling → requirement-feasibility-review → requirement-baseline → api-contract → backend-tech-spec → api-call-guide`，但不能自动进入 `integration-verify / change-plan / execute`。
+- **`--track B`**：前端/UI 轨道产物模式。要求 `api-contract` 已存在且 approved；新需求从需求主链开始，已有契约可跑 `ui-spec → feature-breakdown → frontend-tech-spec`，但不能自动进入 `change-plan / execute`。
+- **未设置 track**：完整交付模式。必须完成双轨并通过 `integration-verify` 后才能进入 `change-plan`。
+- **`--no-review`**：保留参数位，但当前双轨 workflow 不自动跳过 CP-2。Merge Gate 不能跳过。
+
+双轨制原则：API 契约是分叉前的共同事实，`integration-verify` 是合并前的强门禁。单轨只产出局部轨道文档，不代表完整交付。
+
+如果提供了需求文档但未指定功能名，从文档标题自动提取功能名。
+
+## 1. 需求入口前置路由
+
+当用户提供新的需求、PRD、会议纪要或功能描述时，需求主链按依赖顺序强制执行：
+
+1. `workflow-requirement-triage` 只做轻量分类、查重和历史范围检查；正常需求路由到 `ready_for_wayfinder`。
+2. `workflow-wayfinder` 建立目标、已知事实、边界、迷雾与 ticket；只有活动切片的 L1/L2 迷雾收束后才可完成。
+3. `workflow-domain-modeling` 固化共同语言、所有权、状态和边缘案例。
+4. `requirement-feasibility-review` 以流程证明、代码事实和外部能力检查作为进入基线前的最终门禁。
+5. 仅当审查 meta 的 `baseline_gate = pass` 时，才可进入 `workflow-requirement-baseline`。
+
+若分诊结论为 `already_done`、`wontfix`、`ready_for_human` 或 `needs_info`，停止主链并报告最小下一步。`workflow-demand-clarify` 不再作为固定主链步骤；需要业务问答时，由 Wayfinder 的 Grilling ticket 调用。
+
+如果是 `--resume` 或 STATE.md 已处于 baseline 之后的步骤，不倒灌新增需求主链，除非用户提供了新需求或显式要求重新审查。
+
+## 2. 断点检测
+
+每次启动时，通过 workflow-orchestrator 的程序化 inspector 判断当前状态和下一步动作：
+
+```bash
+devflow_state(action="inspect")
+```
+
+根据返回的 `action` 字段路由：
+
+| `action` | 行为 |
+|----------|------|
+| `run_next_step` | 将控制权交给 orchestrator，由它加载并执行 `next_step.skill` |
+| `run_current_step` | 将控制权交给 orchestrator，由它重新执行 `current_step.skill` |
+| `await_user_confirmation` | 将控制权交给 orchestrator，由它执行 CP 确认流程 |
+| `route_failure_branch` | 将控制权交给 orchestrator，由它切入修复分支 |
+| `run_parallel_window` | 将控制权交给 orchestrator，由它调度并行窗口 |
+| `run_project_context` | 将控制权交给 orchestrator，由它执行项目初始化后重新 inspect |
+| `blocked` | 将阻塞原因报告给用户 |
+| `workflow_complete` | 报告完成，流程结束 |
+
+**降级策略**：如果 `inspect_state.rb` 不可用或 `.planning/STATE.md` 缺少 YAML front matter，回退到手动读取 `.planning/pipeline-state.md`，并提示用户运行 `init_state.rb`。
+
+### 轨道参数传递
+
+`--track A` 或 `--track B` 参数会写入 `.planning/STATE.md` 的 `active_track` 字段。orchestrator 读取该字段后：
+
+- **active_track: A** → 只路由 Track A 允许步骤，Track A 完成后以 `track_scope_complete` 阻断，不进入完整交付。
+- **active_track: B** → 新需求从完整需求主链开始；前端设计步骤依赖 `api-contract` 完成。Track B 完成后以 `track_scope_complete` 阻断。
+- **未设置** → 执行完整双轨交付，`change-plan` 依赖 `integration-verify`。
+
+## 3. 委托 orchestrator
+
+无论 inspect_state 返回什么 action，pipeline 本身的职责到此为止。后续所有调度逻辑由 `workflow-orchestrator` skill 全权处理：
+
+```
+/workflow-orchestrator
+```
+
+orchestrator 读取 `feature-development.yaml` 获取步骤拓扑和 CP 定义，按自己的 Dispatch Rules / Checkpoint Rules / Failure Branch Rules / Parallel Window Rules 执行。
+
+</process>
+
+<output>
+pipeline 本身不产出文件。所有产物由各 workflow-* skill 写入，由 orchestrator 的 `advance_state.rb` 更新 STATE.md。
+</output>

package/plugins/devflow-core/skills/workflow-pipeline/references/pipeline-flow.md

@@ -0,0 +1,167 @@
+# 研发交付全链路流程
+
+```
+workflow-pipeline 启动
+         │
+         ▼
+┌─────────────────────────────────────┐
+│ Step 0: 断点检测                     │
+│ 读取 pipeline-state.md 恢复进度      │
+└─────────────────────────────────────┘
+         │
+         ▼
+┌─────────────────────────────────────┐
+│ Step 1: 项目初始化                   │
+│ workflow-project-context                     │
+│ 输出: .planning/PROJECT.md          │
+└─────────────────────────────────────┘
+         │
+         ▼
+┌─────────────────────────────────────┐
+│ Step 2: 需求完善                     │
+│ workflow-requirement-baseline                 │
+│ 输出: .planning/requirements/baseline.md │
+│ 门禁: 冲突/复用/过度工程/替代方案已拍板 │
+└──────────────┬──────────────────────┘
+         │             ↑
+         ▼             │ 用户拒绝
+┌─────────────────────────────────────┐
+│ 🔴 CP-1: 需求基线人工确认             │
+│ ask 强制暂停              │
+│ 确认: FP/BR/BC 准确完整              │
+└──────────────┬──────────────────────┘
+         │ 用户确认
+         ▼
+┌─────────────────────────────────────┐
+│ Step 3: 三文档并行生成                │
+│                                    │
+│  ┌──────────┐ ┌──────────┐ ┌──────┐ │
+│  │ feature- │ │frontend- │ │back- │ │
+│  │breakdown │ │tech-spec │ │end-  │ │
+│  │          │ │          │ │tech- │ │
+│  │ 功能点   │ │ 前端方案 │ │spec  │ │
+│  │ 梳理.md  │ │ .md      │ │后端  │ │
+│  └──────────┘ └──────────┘ └──────┘ │
+└─────────────────────────────────────┘
+         │             ↑
+         ▼             │ 用户拒绝
+┌─────────────────────────────────────┐
+│ 🟡 CP-2: 技术方案人工确认             │
+│ ask 强制暂停              │
+│ --no-review 可跳过                    │
+│ 确认: DB/API/架构决策合理可行         │
+└──────────────┬──────────────────────┘
+         │ 用户确认
+         ▼
+┌─────────────────────────────────────┐
+│ Step 4: 变更清单                     │
+│ workflow-change-plan                         │
+│ 输入: 前端+后端技术方案               │
+│ 输出: .planning/features/{功能名}/变更清单.md │
+└──────────────┬──────────────────────┘
+         │             ↑
+         ▼             │ 用户拒绝
+┌─────────────────────────────────────┐
+│ 🔴 CP-3: 变更清单人工确认             │
+│ ask 强制暂停              │
+│ 不可跳过                              │
+│ 确认: DDL/代码/上线步骤可执行         │
+└──────────────┬──────────────────────┘
+         │ 用户确认
+         ▼
+┌─────────────────────────────────────┐
+│ Step 4.5: Phase 结构初始化           │
+│ phase-init                           │
+│ 创建 ROADMAP.md + .planning/phases/  │
+│ 桥接 workflow 产物到 phase 结构      │
+└─────────────────────────────────────┘
+         │
+         ▼
+┌─────────────────────────────────────┐
+│ Step 5: 代码执行                     │
+│ workflow-execute-phase                   │
+│ Wave1: DDL → Wave2: Domain/Service  │
+│ Wave3: API → Wave4: 前端 → Wave5: 联调│
+│ 输出: SUMMARY.md 写入 phases/ 目录   │
+└──────────────┬──────────────────────┘
+	         │             ↑
+	         ▼             │ 修复后重试
+┌─────────────────────────────────────┐
+│ Step 5.5: 代码索引刷新               │
+│ workflow-code-index                  │
+│ 刷新 Symbol/Relation/Call Graph      │
+│ 输出 .planning/code-index/ + AUDIT   │
+└──────────────┬──────────────────────┘
+	         │             ↑
+	         ▼             │ 索引审查失败
+┌─────────────────────────────────────┐
+│ Step 5.6: 代码审查 + 主流程用例      │
+│ code-review + generate-mainflow-cases│
+│ 基于 code-index + 源码 evidence       │
+└──────────────┬──────────────────────┘
+	         │             ↑
+	         ▼             │ 审查失败/用例生成失败
+┌─────────────────────────────────────┐
+│ Step 6: UAT 验证                     │
+│ workflow-verify-work                 │
+│ 按功能点逐条验证                     │
+│ 失败 → 诊断 → 修复 → 回 Step 5       │
+└──────────────┬──────────────────────┘
+	         │             ↑
+	         ▼             │ 用户拒绝
+┌─────────────────────────────────────┐
+│ 🔴 CP-4: 验收人工确认                 │
+│ ask 强制暂停              │
+│ 不可跳过                              │
+│ 确认: UAT/5门gate通过,可归档         │
+└──────────────┬──────────────────────┘
+         │ 用户确认
+         ▼
+┌─────────────────────────────────────┐
+│ Step 7: 里程碑审计                   │
+│ workflow-audit-milestone             │
+│ gaps → Bug 修复或人工拆分后重审       │
+└──────────────┬──────────────────────┘
+         │             ↑
+         ▼             │ 补齐后重试
+┌─────────────────────────────────────┐
+│ Step 7.5: 更新导航                   │
+│ workflow-update-navigation           │
+│ 增量同步 navigation 到代码结构       │
+└──────────────┬──────────────────────┘
+         ▼
+┌─────────────────────────────────────┐
+│ Step 8: 里程碑归档                   │
+│ workflow-complete-milestone              │
+│ 归档 → 更新 PROJECT.md → git tag    │
+└─────────────────────────────────────┘
+         │
+         ▼
+           完成 ✓
+```
+
+## 断点续接
+
+每次启动时，workflow-pipeline 先读 `.planning/pipeline-state.md`：
+
+```
+1. 解析 state 文件
+2. 跳过所有 done 的步骤
+3. 从第一个 pending/in_progress 的步骤继续
+4. 如果 state 文件不存在，从头开始
+```
+
+## 简化流程门禁
+
+只有单文件/单方法/单文档、无跨层影响、无未拍板需求决策时，才允许向用户提议简化流程。用户未明确同意时，继续完整 pipeline。
+
+## 需求拍板门禁
+
+Step 2 之后必须检查 `.planning/requirements/baseline.md`：
+
+- `待确认事项`
+- `反向审视与用户拍板`
+- `下游输入契约`
+- `.planning/requirements/baseline.meta.json` 中 `review_status` 必须为 `passed`，且 `blocking_pending_count`、`critical_image_missing_count`、`challenge_pending_count`、`code_reality_missing_count` 必须全为 0
+
+影响 scope、语义、归属、兼容性或实现成本的未确认项是阻塞项。不能把它们传入技术方案或变更清单当成已确认范围。

package/plugins/devflow-core/skills/workflow-pipeline/references/slice-safety-guide.md

@@ -0,0 +1,125 @@
+# 大需求分片安全指南
+
+Use this guide when a requirement is broad enough that one document can hide broken traceability. This is a pipeline-level rule: the same slice must flow from requirement baseline to feature breakdown, API contract, technical specs, change plan, execution, and verification.
+
+## 1. First Principles
+
+The executable unit is not "the whole PRD" and not necessarily one FP. The executable unit is a slice that can be reasoned about, implemented, and verified without losing the chain from user outcome to code task.
+
+A valid slice has:
+
+- One primary business outcome.
+- A bounded actor/entry set.
+- A closed write/read/state chain.
+- Clear dependencies on earlier slices.
+- A test anchor that can prove the slice works.
+- A failure boundary: what is explicitly not included.
+
+If a slice cannot be explained in one short table row, it is probably still too large.
+
+## 2. Oversize Triggers
+
+Split the requirement before downstream generation when any trigger applies:
+
+| Trigger | Threshold |
+|---------|-----------|
+| FP count | More than 8 current-slice FP |
+| Codebase count | More than 2 codebases with code changes |
+| High-risk chains | More than 3 high-risk chains from `trace-integrity-guide.md` |
+| Migration scope | Old-system migration plus new user workflow in the same PRD |
+| Runtime scope | Async job/callback/polling plus user-facing CRUD/list pages |
+| Contract replacement | A new field/config source replaces an old one across multiple callers |
+| Document size | Any planning artifact is projected to exceed about 500 lines before examples |
+| Review failure | Reviewer cannot verify FP -> BR/BC -> tech-spec -> task traceability in one pass |
+
+Oversize does not mean reject the requirement. It means create a slice plan and process one slice at a time.
+
+## 3. Slice Design Rules
+
+Prefer slices in this order:
+
+1. Foundation slice: schema/config/shared contract needed by later slices, only when independently verifiable.
+2. Core user journey slice: the smallest path that produces user-visible value.
+3. Integration/runtime slice: async jobs, callbacks, polling, external platform sync.
+4. Existing-entry compatibility slice: old callers, old pages, permission/menu reachability.
+5. Secondary management slice: CRUD/config/reporting pages.
+6. Hardening slice: observability, cleanup, migration backfill, performance if not needed for core correctness.
+
+Do not create a slice that only says "frontend" or "backend". Slice by business outcome and chain closure; each slice may contain frontend and backend work.
+
+## 4. Slice Plan Schema
+
+Write this table into the baseline and carry `SL-*` IDs downstream:
+
+| Slice ID | Name | Outcome | Included FP/BR/BC | Depends on | Entry/chain | Excluded/deferred | Gate |
+|----------|------|---------|-------------------|------------|-------------|-------------------|------|
+| SL-001 | Core path | User can complete X | FP-001, BR-001, BC-001 | none | page -> API -> table -> list | reporting | UAT path |
+
+Rules:
+
+- Each FP belongs to exactly one primary slice.
+- A BR/BC may be referenced by multiple slices, but one slice owns its first implementation.
+- Dependencies must be acyclic.
+- Cross-slice shared work must be an explicit foundation slice or a named prerequisite task in the later slice, not hidden inside a broad task.
+
+## 4.5 Coverage Conservation Gate
+
+Splitting is allowed to defer implementation, but it must never delete scope silently. Every source item and every decomposed object must have an explicit disposition.
+
+Required ledgers:
+
+1. Source coverage ledger: every raw requirement/source row maps to one of `FP-*`, `BR-*`, `BC-*`, `Q-*`, `OUT-*`, or `DUP-*`.
+2. Slice assignment ledger: every current-feature `FP-*` has exactly one primary disposition: `active slice`, `deferred slice`, or `out of scope`.
+3. Rule/case ownership ledger: every `BR-*` and `BC-*` has an owner slice or a referenced-slice list plus first-implementation slice.
+4. Deferred ledger: every deferred item has a reason, dependency, re-entry condition, and gate. "后续处理" without a trigger is not valid.
+
+Count checks:
+
+| Check | Required result |
+|-------|-----------------|
+| Raw source rows | all mapped to FP/BR/BC/Q/OUT/DUP |
+| Current-feature FP | active + deferred + out-of-scope = total current-feature FP |
+| Active slice FP | all appear in downstream feature-breakdown traceability |
+| Deferred FP | none appear in implementation tasks; all appear in deferred ledger |
+| Out-of-scope items | all have source and user/project reason |
+
+Review fails if:
+
+- A source row disappears instead of being mapped.
+- A deferred item lacks a re-entry condition.
+- A downstream artifact implements a deferred item without changing the active slice.
+- An item is marked out of scope without source-backed reason or user decision.
+- The count check does not balance.
+
+## 5. Downstream Contract
+
+Every downstream artifact must include:
+
+- Active slice ID and name.
+- Included FP/BR/BC.
+- Excluded/deferred FP/BR/BC.
+- Cross-slice dependencies read as context only.
+- Slice gate: what must pass before the next slice starts.
+
+Downstream skills must fail review when:
+
+- They include FP from another slice as implementation scope without marking it as dependency context.
+- They generate tech-spec or change-plan tasks for deferred slice content.
+- They merge multiple slice gates into one "all done" checklist.
+- They omit the active slice ID from traceability tables or task sources.
+- Their traceability count does not match the active slice FP/BR/BC count.
+
+## 6. Adversarial Review
+
+Ask these questions before accepting a slice plan:
+
+| Attack | Question | Failure signal |
+|--------|----------|----------------|
+| Scope smuggling | Can a later slice's work sneak in as "shared setup"? | Shared task has no independent gate |
+| Dependency fog | Can a slice pass without its prerequisite really working? | Depends on vague module names, not gates |
+| Orphan output | Does any generated page/API/task have no slice outcome? | Task maps only to "migration" or "cleanup" |
+| Cross-layer drift | Can frontend/backend/change-plan pick different FP sets? | No active slice ID in artifacts |
+| Review fatigue | Is the document too long for reviewer to trace all chains? | More than 500 lines or >8 FP without split |
+| False completeness | Can "all FP covered" pass while core chain is broken? | No write/read/test anchor per slice |
+
+If any failure signal is present, split again or mark the baseline review as not passed.