القائمة
Manage evidence freshness by identifying stale decisions and providing governance actions
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Review your local uncommitted working-tree changes (git diff plus untracked files) and return actionable improvement suggestions. Use before committing, when nothing has been pushed yet.
Review an existing GitHub pull request and post inline review comments on its diff. Use when the changes are on an opened PR rather than your local working tree.
Add missing test coverage for your local code changes by generating new test files (covers uncommitted and untracked changes, or the latest commit if everything is committed). Use when you want write tests for new logic or increase test coverage.
Run independent tasks concurrently across multiple files or targets using parallel sub-agents, with per-task model selection and LLM-as-a-judge verification. Use when tasks do not depend on each other and can run side by side.
Execute one complex task as ordered, dependent steps run sequentially, passing context from each step to the next, with per-step LLM-as-a-judge verification. Use when later steps depend on the results of earlier ones.
Verify what PR review comments have been addressed (committed/pushed OR uncommitted local changes) and resolve the threads that are genuinely fixed or no longer relevant.
| name | decay |
| description | Manage evidence freshness by identifying stale decisions and providing governance actions |
Manages evidence freshness by identifying stale decisions and providing governance actions. Implements FPF B.3.4 (Evidence Decay).
Key principle: Evidence is perishable. Decisions built on expired evidence carry hidden risk.
Every piece of evidence has a valid_until date. A benchmark from 6 months ago may no longer reflect current system performance. A security audit from before a major dependency update doesn't account for new vulnerabilities.
When evidence expires, the decision it supports becomes questionable - not necessarily wrong, just unverified.
Waiving = "I know this evidence is stale, I accept the risk temporarily."
Use it when:
A waiver is NOT ignoring the problem - it's explicitly documenting that you know about the risk and accept it until a specific date.
| Situation | Action | What it does |
|---|---|---|
| Evidence is old but decision is still good | Refresh | Re-run the test, get fresh evidence |
| Decision is obsolete, needs rethinking | Deprecate | Downgrade hypothesis, restart evaluation |
| Accept risk temporarily | Waive | Record the risk acceptance with deadline |
.fpf/evidence/valid_until from frontmatter## 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 |
Based on user response, perform one of:
User: "Refresh the redis caching evidence"
.fpf/knowledge/L2/User: "Deprecate the auth module decision"
# 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
mv .fpf/knowledge/L2/auth-module.md .fpf/knowledge/L1/auth-module.md
User: "Waive the benchmark until February"
# 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.
You don't need to memorize evidence IDs. Just describe what you want.
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.
A hypothesis is STALE if any of its evidence is expired (and not waived).
This is the Weakest Link (WLNK) principle: reliability = min(all evidence). One stale piece makes the whole decision questionable.
All actions are logged:
| Action | What's Recorded |
|---|---|
| Deprecate | from_layer, to_layer, reason, date |
| Waive | evidence_id, until_date, rationale, date |
Files created in .fpf/evidence/:
deprecate-{hypothesis}-{date}.mdwaiver-{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