# 判断系统是否应该使用 BLOGE

## When to use

在新系统引入 BLOGE 或扩大现有使用范围前使用本任务。某项硬约束与嵌入式 Java 编排引擎不相容时，结论应为 `STOP`；决定性运行事实尚不明确时，应为 `PROBE`；只有约束与证据共同支持一个有限场景时，才给出 `ADOPT`。

## Inspect first

- 确认 Java 与 Maven 基线、部署拓扑、延迟预算和运维所有者。
- 画出当前流程的依赖、并行、分支、失败策略、等待、恢复和外部副作用。
- 判断问题确实需要编排，还是只有一次本地方法调用。
- 阅读[BLOGE 的定位](/zh-CN/v/0.9.8-RC1/01-why-bloge)和[选型比较](/zh-CN/v/0.9.8-RC1/33-migration-and-comparison)。

## Required inputs

取得业务结果、中断上限、持久化要求、预期规模、Operator 所有者、合规约束和回滚路径。不得用功能清单代替这些约束。

## Implementation path

1. 记录无需原型即可否决 BLOGE 的硬约束。
2. 将剩余要求映射到 BLOGE 能力及其证据来源。
3. 把没有测量或来源支撑的 claim 标为未知。
4. 设计最小探针，优先解决影响最大的未知事实。
5. 编写短 ADR，包含结论、证据、放弃的方案和反转条件。
6. 若结论为 `ADOPT`，只选择一个有边界的工作流，延后无关扩展。

## MUST / SHOULD / MAY

- **MUST** 明确给出 `STOP`、`PROBE` 或 `ADOPT`，并说明触发条件。
- **MUST** 区分源码具备能力与目标系统已取得生产证据。
- **MUST** 明确外部副作用语义和运维所有者。
- **SHOULD** 比较架构适配性，而不是比较功能数量。
- **SHOULD** 在全量迁移前使用可回退的探针。
- **MAY** 决定不采用 BLOGE；文档不预设采用结论。

## Failure patterns

- “BLOGE 支持重试，所以适合”：重试只是机制，不是架构结论。
- “示例能运行，所以容量足够”：功能示例没有测量目标负载。
- “所有事实都明确”：把假设改写为具名未知项和探针。
- “全系统采用”：收窄到一个工作流边界和一个负责主体。

## Validation

依据真实仓库和部署约束审查 ADR。结论为 `PROBE` 时，运行具名探针并附上命令、输入、结果和边界。`STOP` 不需要代码改动；证据充分的拒绝也是有效结果。

## Evidence

- [BLOGE 心智模型](/zh-CN/v/0.9.8-RC1/01-why-bloge)
- [迁移与比较](/zh-CN/v/0.9.8-RC1/33-migration-and-comparison)
- [版本与证据参考](/agent/zh-CN/v/0.9.8-RC1/reference/version-and-evidence.md)
- [来源与 claim 纪律](/agent/zh-CN/v/0.9.8-RC1/policies/source-and-claim-discipline.md)