decay

证据时效性管理

通过识别过时的决策并提供治理操作来管理证据时效性。实现 FPF B.3.4（证据衰减）。

核心原则： 证据会失效。基于过期证据做出的决策会带来隐性风险。

---

快速了解

什么是过时证据？

每份证据都有一个 valid_until 日期。6 个月前的基准测试可能已无法反映当前系统性能。重大依赖项更新之前的安全审计，也未考虑新的漏洞。

证据过期后，它所支持的决策就会变得存疑——不一定是错的，只是未经验证。

什么是“豁免”？

豁免 =“我知道这份证据已过时，但我暂时接受风险。”

适用于以下情况：

• 你即将发布，没有时间重新运行所有测试
• 证据只过期了一小段时间，很可能仍然有效
• 你已安排好重新验证的日期

豁免并非忽视问题，而是明确记录你已知悉风险，并接受风险直到指定日期。

三种操作

情况	操作	作用
证据已过时，但决策仍然有效	刷新	重新运行测试，获取新证据
决策已过时，需要重新考虑	弃用	降低假设等级，重新开始评估
暂时接受风险	豁免	记录风险接受情况和截止日期

---

操作（运行时）

第 1 步：生成时效性报告

1. 列出 .fpf/evidence/ 中的所有证据文件
2. 对每个证据文件：
   • 从 frontmatter 中读取 valid_until
   • 与当前日期进行比较
   • 分类为 FRESH、STALE 或 EXPIRED

第 2 步：呈现报告

## Evidence Freshness Report

### EXPIRED (Requires Action)

| Evidence | Hypothesis | Expired | Days Overdue |
|----------|------------|---------|--------------|
| ev-benchmark-2024-06-15 | redis-caching | 2024-12-15 | 45 |
| ev-security-2024-07-01 | auth-module | 2025-01-01 | 14 |

### STALE (Warning)

| Evidence | Hypothesis | Expires | Days Left |
|----------|------------|---------|-----------|
| ev-loadtest-2024-10-01 | api-gateway | 2025-01-20 | 5 |

### FRESH

| Evidence | Hypothesis | Expires |
|----------|------------|---------|
| ev-unittest-2025-01-10 | validation-lib | 2025-07-10 |

### WAIVED

| Evidence | Waived Until | Rationale |
|----------|--------------|-----------|
| ev-perf-old | 2025-02-01 | Migration pending |

第 3 步：处理用户操作

根据用户的回复，执行以下操作之一：

刷新

用户：“刷新 redis 缓存的证据”

1. 在 .fpf/knowledge/L2/ 中找到对应的假设
2. 重新运行验证以生成新证据

弃用

用户：“弃用 auth 模块的决策”

1. 将假设从 L2 移至 L1（或从 L1 移至 L0）
2. 创建弃用记录：

# In .fpf/evidence/deprecate-auth-module-2025-01-15.md
---
id: deprecate-auth-module-2025-01-15
hypothesis_id: auth-module
action: deprecate
from_layer: L2
to_layer: L1
created: 2025-01-15T10:00:00Z
---

# Deprecation: auth-module

**Reason**: Evidence expired, technology landscape changed

**Next Steps**: Run `/fpf:propose-hypotheses` to explore alternatives

3. 移动假设文件：

mv .fpf/knowledge/L2/auth-module.md .fpf/knowledge/L1/auth-module.md

豁免

用户：“将基准测试豁免至 2 月”

1. 创建豁免记录：

# In .fpf/evidence/waiver-benchmark-2025-01-15.md
---
id: waiver-benchmark-2025-01-15
evidence_id: ev-benchmark-2024-06-15
waived_until: 2025-02-01
created: 2025-01-15T10:00:00Z
---

# Waiver: ev-benchmark-2024-06-15

**Evidence**: ev-benchmark-2024-06-15
**Hypothesis**: redis-caching
**Waived Until**: 2025-02-01
**Rationale**: Migration pending, will re-run after completion

**Accepted By**: User
**Created**: 2025-01-15

**WARNING**: This evidence returns to EXPIRED status after 2025-02-01.

---

自然语言用法

你不需要记住证据 ID。 只需描述你想做什么。

工作流示例

User: /fpf:decay

Agent shows report with stale evidence

User: Waive the benchmark until February, we'll re-run it after the migration.

Agent: Creating waiver for ev-benchmark-2024-06-15 until 2025-02-01.
       Rationale: "Re-run after migration"

       [Creates .fpf/evidence/waiver-benchmark-2025-01-15.md]

User: The vendor API is being discontinued. Deprecate that decision.

Agent: Deprecating hypothesis-vendor-api from L2 to L1.
       [Moves file, creates deprecation record]

       Next step: Run /fpf:propose-hypotheses to explore alternatives.

---

WLNK 原则

如果一个假设的任意一份证据已过期（且未获豁免），该假设即为过时。

这就是最弱环节（WLNK）原则：可靠性 = 所有证据中的最低值。一份过时证据就会让整个决策存疑。

---

审计跟踪

所有操作都会记录：

操作	记录内容
弃用	from_layer、to_layer、reason、date
豁免	evidence_id、until_date、rationale、date

在 .fpf/evidence/ 中创建的文件：

• deprecate-{hypothesis}-{date}.md
• waiver-{evidence}-{date}.md

---

常见工作流

每周维护

/fpf:decay                    # See what's stale
# For each stale item: refresh, deprecate, or waive

发布前

/fpf:decay                    # Check for stale decisions
# Either refresh evidence or explicitly waive with documented rationale
# Waiver rationales become part of release documentation

重大变更后

# Dependency update, API change, security advisory...
/fpf:decay                    # See what's affected
# Deprecate obsolete decisions
# Start new hypothesis cycle for replacements