business-compliance

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Business Compliance

业务合规性

Run a fully autonomous domain compliance audit on a page or component of the Hexagone Web application. The skill discovers documented business rules in

docs/domain/

, extracts the entities and bounded context of the target screen, matches applicable rules, detects violations of domain invariants, and prints a structured report with mandatory citations — without modifying any files. This is a report-only skill. It never auto-fixes business rule violations because the semantic and patient-safety impact is too high for machine judgment.

对Hexagone Web应用的某个页面或组件执行完全自主的领域合规性审计。该Skill会发现

docs/domain/

中记录的业务规则，提取目标页面的实体和限界上下文，匹配适用规则，检测领域不变量的违规情况，并打印带有强制引用的结构化报告——不会修改任何文件。这是一个仅报告型Skill。它永远不会自动修复业务规则违规问题，因为这类修改对语义和患者安全的影响过大，无法由机器判断。

When to Use This Skill

何时使用该Skill

Activate when the user:

Says "business-compliance" followed by a URL, component name, or page name
Asks to audit domain rules, business rules, or invariants on a screen
Says "check the business logic", "audit the domain rules", "business review"
Wants to verify that a screen enforces the documented invariants from
```
docs/domain/
```

当用户出现以下情况时激活：

说出“business-compliance”并附带URL、组件名称或页面名称
要求审核页面上的领域规则、业务规则或不变量
说出“检查业务逻辑”、“审计领域规则”、“业务审查”
希望验证页面是否执行了
```
docs/domain/
```
中记录的不变量

Relation to

design-compliance

与

design-compliance

的关系

design-compliance

and

business-compliance

are complementary but separate skills:

	`design-compliance`	`business-compliance`
Audits	Visual / presentation layer	Domain / business logic layer
Source of truth	`hexagone-preset.js` , CLAUDE.md, design rules	`docs/domain/` (DDD structured Markdown)
Mode	Auto-fix all violations	Report only, never fix
Risk profile	Low (cosmetic)	High (patient safety, regulatory)
Reviewer	Frontend devs	Domain experts, clinical PO, compliance

Do not merge them. Run both separately when needed. A unified

screen-compliance

aggregator is out of scope for v1.

design-compliance

和

business-compliance

是互补但独立的Skill：

	`design-compliance`	`business-compliance`
审计对象	视觉/展示层	领域/业务逻辑层
事实来源	`hexagone-preset.js` 、CLAUDE.md、设计规则	`docs/domain/` （DDD结构化Markdown）
模式	自动修复所有违规	仅报告，绝不修复
风险等级	低（外观层面）	高（患者安全、法规层面）
审核人员	前端开发人员	领域专家、临床产品负责人、合规人员

请勿将二者合并。必要时分别运行。v1版本不支持统一的

screen-compliance

聚合器。

Core Principles

核心原则

1. Full Autonomy

1. 完全自主性

The entire pipeline runs without asking questions during execution
If no argument is provided, ask the user what to review — then run autonomously
No files are modified. The report is printed to the terminal only

整个流程运行期间无需提问
如果未提供参数，询问用户要审核的内容——然后自主运行
不会修改任何文件。仅向终端打印报告

2. Report-Only — No Auto-Fix

2. 仅报告——绝不自动修复

Auto-fixing a business rule violation is categorically unsafe in healthcare software. A machine "fix" could:

Turn a warning into a block (halting legitimate care)
Turn a block into a warning (industrializing the shortcut anti-pattern)
Silently change clinical semantics without human review

The skill surfaces, documents, and cites — a human (developer + domain expert) decides the fix.

在医疗软件中，自动修复业务规则违规问题绝对不安全。机器的“修复”可能会：

将警告转为阻断（停止合法诊疗）
将阻断转为警告（固化捷径反模式）
在未经人工审核的情况下悄悄改变临床语义

该Skill仅发现、记录并引用问题——由人类（开发人员+领域专家）决定修复方案。

3. Schema-First

3. 模式优先

The skill requires

docs/domain/

to follow a structured rule schema (see

reference/rule-schema.md

). If the schema is not respected, the skill refuses to audit and emits a migration checklist. Garbage in → hallucinated findings out. This is non-negotiable.

该Skill要求

docs/domain/

遵循结构化规则模式（参见

reference/rule-schema.md

）。如果模式未被遵守，该Skill拒绝执行审计并输出迁移检查清单。输入无效→输出错误结论。这一点不容协商。

4. Deterministic Matching Pipeline

4. 确定性匹配流程

Matching a rule to a screen is done in a deterministic pipeline before any LLM reasoning:

Screen extraction (deterministic) — route, Pinia stores, API endpoints, TypeScript types
Bounded context pre-filter (deterministic) — via
```
api_prefixes
```
in rule frontmatter
Entity lookup (deterministic) — match extracted types against rule
```
entities:
```
lists
Rule reasoning (LLM) — confined to the shortlisted rules

LLM is used only in step 4. Steps 1-3 are mechanical.

在进行任何LLM推理之前，规则与页面的匹配通过确定性流程完成：

页面提取（确定性）——路由、Pinia存储、API端点、TypeScript类型
限界上下文预过滤（确定性）——通过规则前置元数据中的
```
api_prefixes
```
实体查找（确定性）——将提取的类型与规则的
```
entities:
```
列表匹配
规则推理（LLM）——仅针对入围规则

LLM仅用于第4步。第1-3步为机械操作。

5. Sensitivity Over Specificity

5. 敏感度优先于特异性

In healthcare, false negatives are catastrophic, false positives are annoying. The skill tunes for sensitivity: when uncertain, it reports with status

NEEDS_CLINICAL_REVIEW

rather than dropping the rule silently.

在医疗领域，假阴性是灾难性的，假阳性只是麻烦。该Skill优先调优敏感度：当存在不确定性时，会以

NEEDS_CLINICAL_REVIEW

状态报告，而非悄悄忽略规则。

6. Citation-Mandatory

6. 强制引用

Every finding MUST cite:

The exact rule file + line (or heading anchor) in
```
docs/domain/
```
The exact code file + line for the violation
The stable
```
rule_id
```
(e.g.,
```
ADM-001
```
,
```
PRESC-014
```
)

A finding without all three citations is rejected from the report. No citation = no finding.

每个发现必须引用：

```
docs/domain/
```
中确切的规则文件+行号（或标题锚点）
违规代码的确切文件+行号
稳定的
```
rule_id
```
（例如：
```
ADM-001
```
、
```
PRESC-014
```
）

缺少这三项引用的发现会被排除在报告之外。无引用=无发现。

Source of Truth (Priority Order)

事实来源（优先级）

Rule files in
docs/domain/
— the only source of authoritative business rules
Rule schema —
```
reference/rule-schema.md
```
(this skill's contract for rule structure)
Ubiquitous language —
```
UBIQUITOUS_LANGUAGE.md
```
if present, used to reconcile entity naming

The skill does NOT invent rules. If a rule is not documented in

docs/domain/

, it does not exist for this skill.

docs/domain/
中的规则文件——权威业务规则的唯一来源
规则模式——
```
reference/rule-schema.md
```
（该Skill的规则结构约定）
通用语言——如果存在
```
UBIQUITOUS_LANGUAGE.md
```
，用于协调实体命名

该Skill不会凭空创建规则。如果规则未在

docs/domain/

中记录，则对该Skill而言不存在此规则。

Input Modes

输入模式

Same three input modes as

design-compliance

与

design-compliance

相同的三种输入模式：

URL Mode

URL模式

/business-compliance http://localhost:5173/hexagone-etab/vue/prescriptions/123

Use the URL to resolve the route in the router config
Find the component file for that route
Recursively resolve the component tree

/business-compliance http://localhost:5173/hexagone-etab/vue/prescriptions/123

使用URL解析路由器配置中的路由
查找该路由对应的组件文件
递归解析组件树

Component Name Mode

组件名称模式

/business-compliance PrescriptionEditor

Glob for matching files:

**/PrescriptionEditor.vue

**/prescription-editor.vue

Resolve the route (if any) for bounded-context inference
Recursively resolve the component tree

/business-compliance PrescriptionEditor

全局匹配文件：

**/PrescriptionEditor.vue

、

**/prescription-editor.vue

解析路由（如果存在）以推断限界上下文
递归解析组件树

Page Name Mode

页面名称模式

/business-compliance Prescriptions

Search router config for route name or path match
Find the assigned component
Recursively resolve the component tree

/business-compliance Prescriptions

在路由器配置中搜索路由名称或路径匹配项
查找分配的组件
递归解析组件树

No Argument

无参数

/business-compliance

Ask the user what to audit. Do not assume.

/business-compliance

询问用户要审核的内容。请勿自行假设。

Workflow

工作流程

Step 1: Validate Rule Schema

步骤1：验证规则模式

Before doing anything else, validate that

docs/domain/

follows the required schema:

Locate
docs/domain/
in the project. If it does not exist, abort with:
"No
```
docs/domain/
```
directory found.
```
business-compliance
```
requires documented domain rules. See
```
reference/rule-schema.md
```
for the required format."
Parse each
.md
file in
```
docs/domain/
```
and verify the frontmatter:
- Required fields:
```
bounded_context
```
  ,
```
entities
```
  ,
```
api_prefixes
```
  (can be empty list),
```
rule_id
```
  OR a list of rules with
```
rule_id
```
  each,
```
severity
```
  ,
```
layer
```
- Acceptable values for
```
severity
```
  :
```
P1
```
  ,
```
P2
```
  ,
```
P3
```
  ,
```
P4
```
- Acceptable values for
```
layer
```
  :
```
client
```
  ,
```
server
```
  ,
```
both
```

If any file fails validation, abort the audit and emit a migration checklist:

docs/domain/ schema violations — audit aborted

| File | Missing fields | Action |
|------|----------------|--------|
| docs/domain/prescriptions.md | severity, layer | Add frontmatter fields |
| ... | ... | ... |

Fix the rule files before re-running. See skills/business-compliance/reference/rule-schema.md.

If all files validate, build the normalized in-memory rule index:
- Keyed by
```
(bounded_context, entity, rule_id)
```
- Each entry holds: rule text, severity, layer, api_prefixes, source file + line

在执行任何操作之前，验证

docs/domain/

是否遵循要求的模式：

定位项目中的
docs/domain/
。如果不存在，终止并提示：
“未找到
```
docs/domain/
```
目录。
```
business-compliance
```
需要记录的领域规则。请参见
```
reference/rule-schema.md
```
了解所需格式。”
解析
docs/domain/
中的每个
.md
文件并验证前置元数据：
- 必填字段：
```
bounded_context
```
  、
```
entities
```
  、
```
api_prefixes
```
  （可以是空列表）、
```
rule_id
```
  或每个规则都带有
```
rule_id
```
  的规则列表、
```
severity
```
  、
```
layer
```
- ```
severity
```
  的可接受值：
```
P1
```
  、
```
P2
```
  、
```
P3
```
  、
```
P4
```
- ```
layer
```
  的可接受值：
```
client
```
  、
```
server
```
  、
```
both
```

如果任何文件验证失败，终止审计并输出迁移检查清单：

docs/domain/ 模式违规——审计终止

| 文件 | 缺失字段 | 操作 |
|------|----------------|--------|
| docs/domain/prescriptions.md | severity, layer | 添加前置元数据字段 |
| ... | ... | ... |

修复规则文件后重新运行。请参见skills/business-compliance/reference/rule-schema.md。

如果所有文件验证通过，构建规范化的内存规则索引：
- 按
```
(bounded_context, entity, rule_id)
```
  建立索引
- 每个条目包含：规则文本、严重程度、层级、api_prefixes、源文件+行号

Step 2: Resolve Target Files

步骤2：解析目标文件

Same resolution strategy as

design-compliance

Parse the user's input to determine the mode (URL, component name, page name)
Find the entry-point file(s):
- URL → parse path, search router files (
```
**/router/**/*.{js,ts}
```
  ,
```
**/router.{js,ts}
```
  ) for matching route, get component
- Component name → glob for
```
**/<name>.vue
```
  ,
```
**/<name-kebab>.vue
```
  ,
```
**/<Name>/**
```
- Page name → search router config for route name or path match
Recursively resolve the component tree:
- Read each
```
.vue
```
  file
- Extract all local imports (skip
```
primevue/*
```
  ,
```
vue
```
  ,
```
vue-router
```
  ,
```
pinia
```
  ,
```
node_modules
```
  ,
```
@hexagone/shared
```
  )
- Follow each import, repeat until no new local components
Report the discovered tree to the user

与

design-compliance

相同的解析策略：

解析用户输入以确定模式（URL、组件名称、页面名称）
找到入口文件：
- URL → 解析路径，在路由器文件（
```
**/router/**/*.{js,ts}
```
  、
```
**/router.{js,ts}
```
  ）中搜索匹配路由，获取组件
- 组件名称 → 全局匹配
```
**/<name>.vue
```
  、
```
**/<name-kebab>.vue
```
  、
```
**/<Name>/**
```
- 页面名称 → 在路由器配置中搜索路由名称或路径匹配项
递归解析组件树：
- 读取每个
```
.vue
```
  文件
- 提取所有本地导入（跳过
```
primevue/*
```
  、
```
vue
```
  、
```
vue-router
```
  、
```
pinia
```
  、
```
node_modules
```
  、
```
@hexagone/shared
```
  ）
- 跟踪每个导入，重复直到没有新的本地组件
向用户报告发现的组件树

Step 3: Extract Screen Artifacts

步骤3：提取页面工件

For each file in the component tree, extract the artifacts needed for rule matching:

Route information:
- Route path (e.g.,
```
/prescriptions/:id
```
  )
- API prefix derived from the route (e.g.,
```
/api/prescriptions
```
  )
Pinia stores:
- ```
import { usePrescriptionStore } from '...'
```
- Store names are strong hints for bounded context
API endpoints:
- Grep for
```
axios.*
```
  ,
```
fetch('...')
```
  ,
```
useFetch(...)
```
  ,
```
$api.*
```
- Capture full URLs and HTTP methods
- Capture error handling:
```
catch (err)
```
  blocks, 4xx/5xx handlers
TypeScript types:
- Types imported from
```
@/types/
```
  ,
```
@hexagone/shared/types
```
  , or local
```
types.ts
```
- Focus on entity-like types:
```
Prescription
```
  ,
```
Admission
```
  ,
```
Patient
```
  ,
```
Order
```
  , etc.
Form fields and bindings:
- ```
v-model
```
  bindings
- Form validation rules (
```
required
```
  ,
```
rules
```
  ,
```
schema
```
  , Zod/Yup/Valibot schemas)
- ```
:disabled
```
  ,
```
v-if
```
  ,
```
v-show
```
  on action buttons (state machine signals)
Action handlers:
- Click handlers on buttons whose label matches a state transition (
```
save
```
  ,
```
validate
```
  ,
```
discharge
```
  ,
```
sign
```
  ,
```
cancel
```
  )
- Capture what state change they trigger via the API

Output a per-file extraction summary:

PrescriptionEditor.vue:
  route: /prescriptions/:id
  api_prefixes: [/api/prescriptions, /api/allergies]
  stores: [usePrescriptionStore, usePatientStore]
  types: [Prescription, AllergyCheck, Patient]
  actions: [save, validate, sign]

针对组件树中的每个文件，提取规则匹配所需的工件：

路由信息：
- 路由路径（例如：
```
/prescriptions/:id
```
  ）
- 从路由派生的API前缀（例如：
```
/api/prescriptions
```
  ）
Pinia存储：
- ```
import { usePrescriptionStore } from '...'
```
- 存储名称是限界上下文的重要提示
API端点：
- 搜索
```
axios.*
```
  、
```
fetch('...')
```
  、
```
useFetch(...)
```
  、
```
$api.*
```
- 捕获完整URL和HTTP方法
- 捕获错误处理：
```
catch (err)
```
  块、4xx/5xx处理器
TypeScript类型：
- 从
```
@/types/
```
  、
```
@hexagone/shared/types
```
  或本地
```
types.ts
```
  导入的类型
- 重点关注类实体类型：
```
Prescription
```
  、
```
Admission
```
  、
```
Patient
```
  、
```
Order
```
  等
表单字段与绑定：
- ```
v-model
```
  绑定
- 表单验证规则（
```
required
```
  、
```
rules
```
  、
```
schema
```
  、Zod/Yup/Valibot模式）
- 操作按钮上的
```
:disabled
```
  、
```
v-if
```
  、
```
v-show
```
  （状态机信号）
操作处理器：
- 标签与状态转换匹配的按钮点击处理器（
```
save
```
  、
```
validate
```
  、
```
discharge
```
  、
```
sign
```
  、
```
cancel
```
  ）
- 捕获它们通过API触发的状态变化

输出每个文件的提取摘要：

PrescriptionEditor.vue:
  route: /prescriptions/:id
  api_prefixes: [/api/prescriptions, /api/allergies]
  stores: [usePrescriptionStore, usePatientStore]
  types: [Prescription, AllergyCheck, Patient]
  actions: [save, validate, sign]

Step 4: Match Rules to Screen

步骤4：将规则与页面匹配

For each file's extracted artifacts, match applicable rules:

Bounded context filter: for each
```
api_prefix
```
in the screen, collect rules whose
```
api_prefixes
```
frontmatter overlaps
Entity filter: intersect with rules whose
```
entities
```
list contains any extracted TS type name
Ubiquitous language reconciliation: if
```
UBIQUITOUS_LANGUAGE.md
```
exists, use it to map code-level names to domain-level names before matching (e.g.,
```
Rx
```
→
```
Prescription
```
)

Output the rule shortlist per file:

PrescriptionEditor.vue: 7 applicable rules
  - PRESC-001 (P1) — Allergy check required before validation
  - PRESC-002 (P1) — Electronic signature required on save
  - PRESC-014 (P2) — Signature requires audit log entry
  - ADM-008 (P3) — Patient must have active admission
  - ...

针对每个文件的提取工件，匹配适用规则：

限界上下文过滤：针对页面中的每个
```
api_prefix
```
，收集前置元数据
```
api_prefixes
```
与之重叠的规则
实体过滤：与
```
entities
```
列表包含任何提取的TS类型名称的规则相交
通用语言协调：如果存在
```
UBIQUITOUS_LANGUAGE.md
```
，在匹配前使用它将代码级名称映射到领域级名称（例如：
```
Rx
```
→
```
Prescription
```
）

输出每个文件的规则入围清单：

PrescriptionEditor.vue: 7个适用规则
  - PRESC-001 (P1) — 验证前需完成过敏检查
  - PRESC-002 (P1) — 保存时需电子签名
  - PRESC-014 (P2) — 签名需要审计日志条目
  - ADM-008 (P3) — 患者必须处于有效入院状态
  - ...

Step 5: Static Analysis — Detect Violations

步骤5：静态分析——检测违规

For each (file, applicable rule) pair, check the 5 violation categories:

针对每个（文件，适用规则）对，检查5类违规情况：

Category 1: Missing Precondition Check

类别1：缺失前置条件检查

Rule states a precondition that must hold before an action (
```
X requires Y verified
```
)
Check: does the UI guard the action (via
```
:disabled
```
,
```
v-if
```
, form validation, or API precondition)?
Evidence required: code location of the action + absence of the guard
Severity inherits from the rule

规则规定操作前必须满足前置条件（
```
X需要验证Y
```
）
检查：UI是否通过
```
:disabled
```
、
```
v-if
```
、表单验证或API前置条件保护该操作？
所需证据：操作的代码位置 + 保护机制缺失
严重程度继承自规则

Category 2: Forbidden Transition Exposed

类别2：暴露禁用的状态转换

Rule states a state transition is forbidden (
```
Discharged cannot return to Active
```
)
Check: does the UI expose a button/action that can trigger the forbidden transition?
Evidence: button handler + API call that would cause the forbidden state change

规则规定某个状态转换是禁用的（
```
已出院状态无法返回活跃状态
```
）
检查：UI是否暴露了可触发禁用转换的按钮/操作？
证据：按钮处理器 + 会导致禁用状态变化的API调用

Category 3: Required Field Absent

类别3：缺失必填字段

Rule mandates a field must be collected/displayed (e.g., "INS mandatory for clinical action")
Check: is the field present in the form template + bound via v-model + enforced by validation?
Evidence: template search + validation schema inspection

规则要求必须收集/显示某个字段（例如：“临床操作必须提供INS”）
检查：表单模板中是否存在该字段 + 通过v-model绑定 + 验证规则强制执行？
证据：模板搜索 + 验证模式检查

Category 4: Cross-Entity Invariant Unenforced

类别4：跨实体不变量未执行

Rule spans entities (e.g., "Prescription must reference active AllergyCheck")
Check: does the screen load/reference both entities, and does it gate the action on the cross-entity condition?
Evidence: both stores/types present + conditional on the cross-entity relationship

规则涉及多个实体（例如：“处方必须引用有效的AllergyCheck”）
检查：页面是否加载/引用了两个实体，并且是否基于跨实体条件限制操作？
证据：存在两个存储/类型 + 基于跨实体关系的条件判断

Category 5: Workflow Gap

类别5：工作流程缺口

Rule defines a workflow step (e.g., "Verbal order requires countersignature within 24h")
Check: is the step surfaced in the UI, even as a reminder or follow-up action?
Evidence: presence or absence of the UI artifact mapped to the workflow step

规则定义了工作流程步骤（例如：“口头医嘱需在24小时内完成副签”）
检查：UI是否显示了该步骤，即使只是提醒或后续操作？
证据：与工作流程步骤对应的UI工件存在或缺失

Server-Side Rule Handling

服务器端规则处理

When a rule has

layer: server

layer: both

The UI is NOT expected to fully enforce the rule
The UI IS expected to handle the server rejection gracefully (catch 409/422, show user-visible error)
Check: does the API call site include a proper error handler?
A missing error handler on a server-enforced rule is itself a violation (Category 1 — missing precondition handling)

当规则的

layer

为

server

或

both

时：

不要求UI完全执行规则
要求UI优雅处理服务器拒绝（捕获409/422错误，显示用户可见的错误信息）
检查：API调用站点是否包含适当的错误处理器？
服务器强制执行规则但缺少错误处理器本身就是违规（类别1——缺失前置条件处理）

Step 6: Handle Uncertainty

步骤6：处理不确定性

When the skill cannot confidently determine if a rule applies or is violated:

Do not drop the rule silently
Emit a finding with status
```
NEEDS_CLINICAL_REVIEW
```

Include a structured question for the reviewer:

NEEDS_CLINICAL_REVIEW — PRESC-007
Rule: Prescriptions require electronic signature.
Screen: PrescriptionEditor.vue uses usePrescriptionStore.save() but signature step not clearly detected.

Please confirm:
(a) Rule applies, step missing → fix required
(b) Rule applies, step present but undetected → add code annotation or test anchor
(c) Rule does not apply → document why in commit message or rule exclusion

当Skill无法确定规则是否适用或是否违规时：

不要悄悄忽略规则
以
```
NEEDS_CLINICAL_REVIEW
```
状态输出发现

包含给审核人员的结构化问题：

NEEDS_CLINICAL_REVIEW — PRESC-007
规则：处方需要电子签名。
页面：PrescriptionEditor.vue使用usePrescriptionStore.save()但未明确检测到签名步骤。

请确认：
(a) 规则适用，步骤缺失 → 需要修复
(b) 规则适用，步骤存在但未被检测到 → 添加代码注释或测试锚点
(c) 规则不适用 → 在提交信息或规则排除中记录原因

Step 7: Track Non-Evaluable Rules

步骤7：跟踪无法评估的规则

After analysis, list any rule that was in the shortlist but could NOT be evaluated (e.g., code too complex, dynamic dispatch, external library call). This prevents "no violations found" from being confused with "not audited":

Non-evaluable rules (5):
  - PRESC-022 — dynamic dispatch on action name, cannot trace
  - ADM-014 — relies on backend orchestration not visible in screen code
  - ...

分析完成后，列出入围但无法评估的规则（例如：代码过于复杂、动态调度、外部库调用）。这可以避免将“未发现违规”与“未审计”混淆：

无法评估的规则（5个）：
  - PRESC-022 — 操作名称动态调度，无法跟踪
  - ADM-014 — 依赖后端编排，页面代码中不可见
  - ...

Step 8: Generate Report

步骤8：生成报告

Print a structured report to the terminal:

markdown

undefined

向终端打印结构化报告：

markdown

undefined

Business Compliance Report

业务合规性报告

Target: [component/page name or URL] Files analyzed: [count] Rules indexed: [count from docs/domain/] Rules applicable to target: [count] Violations detected: [count] Uncertain findings (NEEDS_CLINICAL_REVIEW): [count] Non-evaluable rules: [count]

目标： [组件/页面名称或URL] 分析文件数： [数量] 索引规则数： [来自docs/domain/的数量] 目标适用规则数： [数量] 检测到的违规数： [数量] 不确定发现（NEEDS_CLINICAL_REVIEW）： [数量] 无法评估的规则数： [数量]

Rule Index Summary

规则索引摘要

Bounded Context	Rules	Files
prescriptions	14	docs/domain/prescriptions.md
admissions	8	docs/domain/admissions.md
...	...	...

限界上下文	规则数	文件
prescriptions	14	docs/domain/prescriptions.md
admissions	8	docs/domain/admissions.md
...	...	...

Files in Component Tree

组件树中的文件

#	File	Applicable Rules	Violations
1	`frontend/gap-mf/src/views/PrescriptionEditor.vue`	7	2
2	`frontend/gap-mf/src/components/AllergyBanner.vue`	2	0
...	...	...	...

#	文件	适用规则数	违规数
1	`frontend/gap-mf/src/views/PrescriptionEditor.vue`	7	2
2	`frontend/gap-mf/src/components/AllergyBanner.vue`	2	0
...	...	...	...

Violations by Severity

按严重程度分类的违规

P1 — Patient Safety ([count])

P1 — 患者安全 ([数量])

PRESC-001 — Allergy check required before validation
- Rule source:
```
docs/domain/prescriptions.md:42
```
- Code location:
```
frontend/gap-mf/src/views/PrescriptionEditor.vue:118
```
- Category: Missing precondition check
- Evidence:
```
validate()
```
  handler calls
```
prescriptionStore.validate()
```
  without prior check on
```
allergyCheckStore.verified
```
  .
- Suggested action (NOT applied): add
```
:disabled="!allergyChecked"
```
  to the Validate button, or guard inside the handler.

PRESC-001 — 验证前需完成过敏检查
- 规则来源：
```
docs/domain/prescriptions.md:42
```
- 代码位置：
```
frontend/gap-mf/src/views/PrescriptionEditor.vue:118
```
- 类别：缺失前置条件检查
- 证据：
```
validate()
```
  处理器调用
```
prescriptionStore.validate()
```
  ，未先检查
```
allergyCheckStore.verified
```
  。
- 建议操作（未应用）：为验证按钮添加
```
:disabled="!allergyChecked"
```
  ，或在处理器内添加保护逻辑。

P2 — Regulatory / Compliance ([count])

P2 — 法规/合规 ([数量])

...

P3 — Clinical Workflow Integrity ([count])

P3 — 临床工作流程完整性 ([数量])

...

P4 — Data Quality / Interoperability ([count])

P4 — 数据质量/互操作性 ([数量])

...

NEEDS_CLINICAL_REVIEW ([count])

NEEDS_CLINICAL_REVIEW ([数量])

PRESC-007 — [structured question as in Step 6]

PRESC-007 — [如步骤6中的结构化问题]

Non-Evaluable Rules ([count])

无法评估的规则 ([数量])

PRESC-022 — dynamic dispatch on action name, static trace impossible

PRESC-022 — 操作名称动态调度，无法静态跟踪

Drift Signals

漂移信号

Rule files unchanged in > 6 months while referenced entities evolved: [list]
Rules with no applicable screen in this audit: [list]

引用实体已演变但规则文件超过6个月未修改：[列表]
本次审计中无适用页面的规则：[列表]

Summary

摘要

Total violations: [count] (P1: [n], P2: [n], P3: [n], P4: [n])
Waivable by developer alone: [count] (P3 + P4)
Require clinical / compliance sign-off: [count] (P1 + P2)
No files modified. Review the report, discuss with domain experts, apply fixes manually.

undefined

总违规数： [数量]（P1: [n], P2: [n], P3: [n], P4: [n]）
可由开发人员单独豁免： [数量]（P3 + P4）
需要临床/合规人员签字确认： [数量]（P1 + P2）
未修改任何文件。请审核报告，与领域专家讨论，手动应用修复。

undefined

Violation Reference

违规参考

5 Violation Categories

5类违规

#	Category	Typical Rule Phrasing	Evidence Required
1	Missing precondition check	"X requires Y verified"	Action handler + absence of guard
2	Forbidden transition exposed	"Cannot transition from A to B"	Action handler + forbidden state change
3	Required field absent	"Field F is mandatory"	Template + validation schema
4	Cross-entity invariant unenforced	"X must reference Y"	Both entities present + conditional
5	Workflow gap	"Step S must occur within T"	UI artifact for step S

#	类别	典型规则表述	所需证据
1	缺失前置条件检查	"X需要验证Y"	操作处理器 + 保护机制缺失
2	暴露禁用的状态转换	"无法从A转换到B"	操作处理器 + 禁用的状态变化
3	缺失必填字段	"字段F为必填项"	模板 + 验证模式
4	跨实体不变量未执行	"X必须引用Y"	存在两个实体 + 条件判断
5	工作流程缺口	"步骤S必须在T时间内完成"	步骤S对应的UI工件

Severity Classification

严重程度分类

Severity	Meaning	Escalation
P1	Patient safety — direct harm pathway (allergy, dose, wrong-patient, signature bypass)	Blocks merge. Clinical PO sign-off required.
P2	Regulatory / compliance — HDS, MDR, CNIL, audit log, traceability	Blocks merge. Compliance officer sign-off required.
P3	Clinical workflow integrity — state machine, orphan entities, workflow gaps	Blocks merge. Waivable by clinical PO with written justification.
P4	Data quality / interoperability — optional fields, code systems, labels	Warns. Does not block. Dev may waive.

P1 and P2 cannot be waived by a developer alone. The skill must require a named clinical or compliance reviewer in the waiver metadata when such a waiver is requested.

严重程度	含义	升级流程
P1	患者安全——直接伤害路径（过敏、剂量、错误患者、签名绕过）	阻止合并。需要临床产品负责人签字确认。
P2	法规/合规——HDS、MDR、CNIL、审计日志、可追溯性	阻止合并。需要合规人员签字确认。
P3	临床工作流程完整性——状态机、孤立实体、工作流程缺口	阻止合并。可由临床产品负责人书面说明后豁免。
P4	数据质量/互操作性——可选字段、代码系统、标签	警告。不阻止合并。开发人员可豁免。

P1和P2不能仅由开发人员豁免。当请求此类豁免时，Skill必须要求在豁免元数据中指定临床或合规审核人员。

Healthcare Rule Examples (Hexagone Context)

Hexagone场景下的医疗规则示例

See

reference/rule-schema.md

for concrete examples. Common rule categories in Hexagone:

Safety interlocks: allergy / contraindication / dose range / drug-drug interaction
Identity: INS (Identité Nationale de Santé) verification before clinical action
Prescription integrity: electronic signature, modification audit trail, verbal order countersignature
State machines: admission/discharge flow, order/result flow, care pathway steps
Interoperability: HL7/FHIR/PAM message completeness, segment ordering (Hexaflux domain)
Regulatory: audit log on writes, break-glass justification, data retention
Billing cascades: act codes blocking discharge, GHS requiring main diagnosis

请参见

reference/rule-schema.md

获取具体示例。Hexagone中常见的规则类别：

安全联锁：过敏/禁忌症/剂量范围/药物相互作用
身份验证：临床操作前需验证INS（全国健康身份标识）
处方完整性：电子签名、修改审计跟踪、口头医嘱副签
状态机：入院/出院流程、医嘱/结果流程、护理路径步骤
互操作性：HL7/FHIR/PAM消息完整性、段排序（Hexaflux领域）
法规要求：写入操作的审计日志、紧急权限使用理由、数据保留
计费连锁：行为代码阻止出院、GHS要求主诊断

Edge Cases

边缘情况

docs/domain/

Does Not Exist

docs/domain/

不存在

Abort audit. Emit:

"No
docs/domain/
directory found. This skill requires documented domain rules following the schema in
reference/rule-schema.md
. Create the directory and add rule files before running."

终止审计。输出：

“未找到
docs/domain/
目录。该Skill需要遵循
reference/rule-schema.md
中模式的已记录领域规则。请创建目录并添加规则文件后再运行。”

docs/domain/

Exists but Schema Fails

docs/domain/

存在但模式验证失败

Abort audit. Emit a migration checklist of schema violations per file (see Step 1.3). Do not attempt partial audit — partial data leads to false confidence.

终止审计。输出每个文件的模式违规迁移检查清单（参见步骤1.3）。请勿尝试部分审计——部分数据会导致错误的信心。

Rule References an Unknown Entity

规则引用未知实体

If a rule's

entities:

list contains a name not found anywhere in the codebase:

Keep the rule in the index
Flag in the drift signals section of the report: "Rule X references entity Y, but no usage found in codebase"
This indicates either stale docs or a server-only entity

如果规则的

entities:

列表包含代码库中未找到的名称：

将规则保留在索引中
在报告的漂移信号部分标记：“规则X引用实体Y，但代码库中未找到使用记录”
这表明文档过时或仅存在于服务器端的实体

Screen Matches No Rules

页面未匹配任何规则

Report "0 applicable rules" — explicitly state that this is not the same as "compliant". The screen may operate on an undocumented bounded context (which is itself a drift signal to report).

报告“0个适用规则”——明确说明这与“合规”不同。页面可能在未记录的限界上下文下运行（这本身就是需要报告的漂移信号）。

Conflicting Rules

规则冲突

If two rules in the index share the same

rule_id

or make contradictory claims about the same entity:

Report the conflict in the Drift Signals section
Do not attempt to resolve it — this is a domain expert decision

如果索引中的两个规则共享相同的

rule_id

或对同一实体做出矛盾声明：

在漂移信号部分报告冲突
请勿尝试解决——这是领域专家的决策

Dev Server Not Running

开发服务器未运行

This skill does NOT require a dev server. It is a static analysis + doc-parsing skill. Visual inspection is out of scope — business rules are about code behavior, not rendering.

该Skill不需要开发服务器。它是静态分析+文档解析Skill。视觉检查不在范围内——业务规则关注代码行为，而非渲染效果。

Large Component Tree (20+ files)

大型组件树（20+文件）

Process all files. Organize report by file for readability. Use parallel sub-agents only if the tree exceeds 10 files AND the rule index exceeds 30 rules, to keep LLM reasoning context manageable.

处理所有文件。按文件组织报告以提高可读性。仅当组件树超过10个文件且规则索引超过30个规则时，使用并行子Agent，以确保LLM推理上下文可控。

Mixed Micro-Frontends

混合微前端

Apply the same rule index to all files regardless of MF. Note MF membership per file in the report.

对所有文件应用相同的规则索引，无论所属微前端。在报告中注明每个文件的微前端归属。

Waiver Requested

请求豁免

The skill does NOT manage waivers. If a finding must be waived, the developer does so in the PR description or a dedicated waiver log outside this skill's scope. The skill always re-reports the finding on next run — it's not the skill's job to remember waivers (memory of waivers is a human-process concern).

该Skill不管理豁免。如果发现需要豁免，开发人员需在PR描述或该Skill范围外的专用豁免日志中进行操作。Skill在下次运行时总会重新报告该发现——记住豁免不是Skill的职责（豁免记忆是人工流程问题）。

Important Notes

重要说明

This skill does NOT modify files. It is strictly report-only. If the user says "fix them", explain that business rule violations are not mechanically fixable — the report provides suggested actions that a human must apply.
Every finding cites rule_id + doc:line + code:line. A finding without all three is a bug in the skill — do not emit it.
P1 / P2 violations require named sign-off from a clinical or compliance reviewer. The skill calls this out in the report.
Tune for sensitivity, not specificity. Better to raise 10 possible findings and let the team dismiss 9 than to miss 1 P1.
Uncertain findings →
NEEDS_CLINICAL_REVIEW
. Never silently drop a rule.
Drift signals are first-class. Rules that haven't been touched while their entities have changed → surface in the report. Rules referencing unknown entities → surface.
Non-evaluable rules are first-class. "No violations found" must not be confused with "not audited". Always list non-evaluable rules explicitly.
No auto-fix. Ever. No v2 auto-fix. If requested, push back: healthcare semantic changes require human judgment.
Pilot first. In a fresh rollout, start with ONE bounded context (suggest: prescriptions — highest stakes, clearest invariants) before expanding. Validate signal-to-noise on that pilot before adding domains.

该Skill不会修改文件。它严格是仅报告型。如果用户说“修复它们”，请说明业务规则违规无法机械修复——报告提供了建议操作，需由人类应用。
每个发现都必须引用rule_id + 文档:行号 + 代码:行号。缺少这三项的发现是Skill的bug——请勿输出。
P1/P2违规需要临床或合规人员的签字确认。Skill会在报告中强调这一点。
优先调优敏感度，而非特异性。提出10个可能的发现让团队排除9个，比遗漏1个P1违规更好。
不确定发现→
NEEDS_CLINICAL_REVIEW
。永远不要悄悄忽略规则。
漂移信号是一等公民。引用实体已变化但未修改的规则→在报告中显示。引用未知实体的规则→在报告中显示。
无法评估的规则是一等公民。“未发现违规”不能与“未审计”混淆。始终明确列出无法评估的规则。
绝不自动修复。永远不会。v2也不会自动修复。如果被请求，拒绝：医疗语义修改需要人工判断。
先试点。首次推出时，先从一个限界上下文开始（建议：处方——风险最高，不变量最清晰），然后再扩展。在添加其他领域之前，验证试点的信噪比。