InterceptCard

intercept-card

拦截卡 · 「某个动作被规则挡下了」的完整交代：规则/出处/违反点/改法/要不要放行 · block-confirm-notice 三档强度(左缘色条是唯一锚点·不整卡染色免成列糊成色块) + 溯源槽 + 放行理由强制必填(为空则按钮禁用·onOverride 根本不被调用) + 已放行态展示既有理由 · 区别 Alert(单纯通知)

用法

完整拦截交代

规则是什么 · 出处在哪 · 违反点在哪 · 该怎么改，四件事齐了用户才会遵守而不是关掉它。

已拦截

并行子任务上限

同一会话最多允许 2 个并行子任务（≥ 3 视为过度拆分）

违反点

本次为第 3 个子任务：「梳理历史根因」

建议改法

先让前两个跑完再派；或把三件事合并成一个更明确的任务。

依据：团队约定 · 硬约束 4

tsx

<InterceptCard
  severity="block"
  title="并行子任务上限"
  message="同一会话最多允许 2 个并行子任务"
  source="团队约定 · 硬约束 4"
  violation="本次为第 3 个子任务"
  suggestion="先让前两个跑完再派"
/>

带放行入口（理由必填）

点放行不会直接生效，先要写理由。理由为空时确认按钮禁用——没写理由的放行等于没有治理。

已拦截

并行子任务上限

同一会话最多允许 2 个并行子任务（≥ 3 视为过度拆分）

违反点

本次为第 3 个子任务：「梳理历史根因」

建议改法

先让前两个跑完再派；或把三件事合并成一个更明确的任务。

依据：团队约定 · 硬约束 4

tsx

<InterceptCard
  {...rule}
  onOverride={async (reason) => {
    await api.override(event.id, reason);
  }}
/>

三档强度并列

左缘色条是严重度的唯一视觉锚点。不给整卡染色——成列出现时整卡染色会糊成色块。

已拦截

并行子任务上限

同一会话最多允许 2 个并行子任务（≥ 3 视为过度拆分）

违反点

本次为第 3 个子任务：「梳理历史根因」

建议改法

先让前两个跑完再派；或把三件事合并成一个更明确的任务。

依据：团队约定 · 硬约束 4

待确认

元产物写入需确认

不主动写「踩坑记录 / 候选标记 / 漂移说明」等元产物（用户问起再写）

违反点

~/.config/notes/skills/xxx/NOTE.md

建议改法

确认这是用户明确要求的产出，再放行。

依据：团队约定 · 硬约束 5

提醒

样式补丁提醒

本项目的 UI 应全部由设计系统组件承载，避免局部覆写

违反点

apps/console/src/app/custom.css

依据：工程规范 · §7.1

tsx

<InterceptCard severity="block" ... />
<InterceptCard severity="confirm" ... />
<InterceptCard severity="notice" ... />

什么时候用

策略 / 权限拦截的说明与放行
风控命中项的人工复核
合规检查、审批驳回、告警确认

什么时候不用

场景	用什么	为什么
一句话提示	`Alert`	无出处、无动作、看完即走
整页结果态	`Result`	占满视野，是页面主体
表单字段级校验	`Field` 自带错误态	就地反馈，不需要卡片

用法

tsx

import { InterceptCard } from "@hulianui/ui";

<InterceptCard
  severity="block"
  title="并行子任务上限"
  message="同一会话最多允许 2 个并行子任务"
  source="团队约定 · 硬约束 4"
  violation="本次为第 3 个子任务"
  suggestion="先让前两个跑完再派"
  onOverride={async (reason) => api.override(id, reason)}
/>

Props

名称	类型	默认	说明
`severity`	`"block" \| "confirm" \| "notice"`	—	拦截强度
`title`	`ReactNode`	—	规则名或事由
`message`	`ReactNode`	—	规则原文或说明
`source`	`ReactNode`	—	溯源。强烈建议给
`violation`	`ReactNode`	—	具体违反了什么（等宽渲染）
`suggestion`	`ReactNode`	—	建议的合规改法
`onOverride`	`(reason: string) => void \| Promise<void>`	—	给了才渲染放行入口
`overrideLabel`	`ReactNode`	`"放行本次"`	放行按钮文案
`overridePlaceholder`	`string`	见默认值	理由输入占位符
`overridden`	`{ reason, at? }`	—	已放行，展示既有理由

设计取舍

溯源是一等公民。 一条说不清出处的拦截，用户第一反应是关掉它而不是遵守它。source 虽是可选，但缺了它这个组件就失去大半价值。

放行理由必填，且由组件强制。 理由为空时确认按钮禁用，onOverride 根本不会被调用。这是刻意的硬约束——一次没写理由的放行，半年后没人记得当时为什么放行，那等于没有治理。

左缘色条是严重度的唯一视觉锚点。 不给整卡染色：拦截卡常成列出现，整卡染色会让列表糊成一片色块，反而失去分级作用。

放行是两步的。 点「放行本次」先展开理由输入，不直接生效。破坏性动作不该一击即中。

Playground

强度可放行

已拦截

并行子任务上限

同一会话最多允许 2 个并行子任务（≥ 3 视为过度拆分）

违反点

本次为第 3 个子任务：「梳理历史根因」

建议改法

先让前两个跑完再派；或把三件事合并成一个更明确的任务。

依据：团队约定 · 硬约束 4

<InterceptCard
  severity="block"
  title="并行子任务上限"
  message="同一会话最多允许 2 个并行子任务"
  source="团队约定 · 硬约束 4"
  violation="本次为第 3 个子任务"
  onOverride={(reason) => api.override(id, reason)}
/>

用法

完整拦截交代

规则是什么 · 出处在哪 · 违反点在哪 · 该怎么改，四件事齐了用户才会遵守而不是关掉它。

已拦截

并行子任务上限

同一会话最多允许 2 个并行子任务（≥ 3 视为过度拆分）

违反点

本次为第 3 个子任务：「梳理历史根因」

建议改法

先让前两个跑完再派；或把三件事合并成一个更明确的任务。

依据：团队约定 · 硬约束 4

tsx

<InterceptCard
  severity="block"
  title="并行子任务上限"
  message="同一会话最多允许 2 个并行子任务"
  source="团队约定 · 硬约束 4"
  violation="本次为第 3 个子任务"
  suggestion="先让前两个跑完再派"
/>

带放行入口（理由必填）

点放行不会直接生效，先要写理由。理由为空时确认按钮禁用——没写理由的放行等于没有治理。

已拦截

并行子任务上限

同一会话最多允许 2 个并行子任务（≥ 3 视为过度拆分）

违反点

本次为第 3 个子任务：「梳理历史根因」

建议改法

先让前两个跑完再派；或把三件事合并成一个更明确的任务。

依据：团队约定 · 硬约束 4

tsx

<InterceptCard
  {...rule}
  onOverride={async (reason) => {
    await api.override(event.id, reason);
  }}
/>

三档强度并列

左缘色条是严重度的唯一视觉锚点。不给整卡染色——成列出现时整卡染色会糊成色块。

已拦截

并行子任务上限

同一会话最多允许 2 个并行子任务（≥ 3 视为过度拆分）

违反点

本次为第 3 个子任务：「梳理历史根因」

建议改法

先让前两个跑完再派；或把三件事合并成一个更明确的任务。

依据：团队约定 · 硬约束 4

待确认

元产物写入需确认

不主动写「踩坑记录 / 候选标记 / 漂移说明」等元产物（用户问起再写）

违反点

~/.config/notes/skills/xxx/NOTE.md

建议改法

确认这是用户明确要求的产出，再放行。

依据：团队约定 · 硬约束 5

提醒

样式补丁提醒

本项目的 UI 应全部由设计系统组件承载，避免局部覆写

违反点

apps/console/src/app/custom.css

依据：工程规范 · §7.1

tsx

<InterceptCard severity="block" ... />
<InterceptCard severity="confirm" ... />
<InterceptCard severity="notice" ... />

场景

用什么

为什么

一句话提示

Alert

无出处、无动作、看完即走

整页结果态

Result

占满视野，是页面主体

表单字段级校验

Field 自带错误态

就地反馈，不需要卡片

import { InterceptCard } from "@hulianui/ui"; <InterceptCard severity="block" title="并行子任务上限" message="同一会话最多允许 2 个并行子任务" source="团队约定 · 硬约束 4" violation="本次为第 3 个子任务" suggestion="先让前两个跑完再派" onOverride={async (reason) => api.override(id, reason)} />

Props

名称	类型	默认	说明
`severity`	`"block" \| "confirm" \| "notice"`	—	拦截强度
`title`	`ReactNode`	—	规则名或事由
`message`	`ReactNode`	—	规则原文或说明
`source`	`ReactNode`	—	溯源。强烈建议给
`violation`	`ReactNode`	—	具体违反了什么（等宽渲染）
`suggestion`	`ReactNode`	—	建议的合规改法
`onOverride`	`(reason: string) => void \| Promise<void>`	—	给了才渲染放行入口
`overrideLabel`	`ReactNode`	`"放行本次"`	放行按钮文案
`overridePlaceholder`	`string`	见默认值	理由输入占位符
`overridden`	`{ reason, at? }`	—	已放行，展示既有理由

设计取舍

溯源是一等公民。 一条说不清出处的拦截，用户第一反应是关掉它而不是遵守它。source 虽是可选，但缺了它这个组件就失去大半价值。

左缘色条是严重度的唯一视觉锚点。 不给整卡染色：拦截卡常成列出现，整卡染色会让列表糊成一片色块，反而失去分级作用。

放行是两步的。 点「放行本次」先展开理由输入，不直接生效。破坏性动作不该一击即中。

Playground

强度可放行

已拦截

并行子任务上限

同一会话最多允许 2 个并行子任务（≥ 3 视为过度拆分）

违反点

本次为第 3 个子任务：「梳理历史根因」

建议改法

先让前两个跑完再派；或把三件事合并成一个更明确的任务。

依据：团队约定 · 硬约束 4

<InterceptCard
  severity="block"
  title="并行子任务上限"
  message="同一会话最多允许 2 个并行子任务"
  source="团队约定 · 硬约束 4"
  violation="本次为第 3 个子任务"
  onOverride={(reason) => api.override(id, reason)}
/>