garbage-collection git:20260501.cd7876dA

Immutable. This exact content is served forever at /api/v1/blob/7b4d0ba33553221e.

---
name: garbage-collection
description: This skill should be used when the user asks about "garbage collection rules", "entropy fighting", "documentation staleness", "dead code detection", "convention drift", "periodic checks", "auto-fix rules", or needs guidance on the Garbage Collection section of HARNESS.md.
---

# Garbage Collection

Garbage collection in a harness context means periodic checks that fight
entropy — the slow drift that neither real-time hooks nor PR gates
catch. Documentation goes stale, conventions erode, dead code
accumulates, dependencies fall behind.

This is Boeckeler's third harness component: agents that run
periodically to find inconsistencies and violations, actively fighting
decay.

## Anatomy of a GC Rule

Every GC rule in HARNESS.md has five fields:

- **What it checks** — the specific entropy being detected
- **Frequency** — `daily`, `weekly`, or `manual`
- **Enforcement** — `deterministic` or `agent`
- **Tool** — what runs the check
- **Auto-fix** — `true` (GC agent fixes it) or `false` (create an
  issue instead)

## Choosing Frequency

| Frequency | Use for |
| --- | --- |
| daily | Fast checks with high entropy rate (style drift in active codebases) |
| weekly | Most GC rules — documentation, dependencies, dead code |
| manual | Exploratory checks not yet calibrated for automation |

Start with weekly for most rules. Only move to daily if the entropy
rate justifies the cost.

## The Auto-Fix Decision

Auto-fix is safe when the fix is deterministic, local, verifiable, and
reversible. It is not safe when the fix requires judgement, has ripple
effects, cannot be verified, or is destructive.

For the full safety rubric and detailed examples, consult
`references/gc-catalogue.md`.

**When auto-fix is true**: The `harness-gc` agent applies the fix
directly (with user confirmation in interactive mode) and commits the
result.

**When auto-fix is false**: The agent creates a GitHub issue describing
the finding, with file:line references and a suggested fix.

## Common GC Categories

| Category | Examples | Typical frequency |
| --- | --- | --- |
| Documentation entropy | Stale references, outdated versions | weekly |
| Convention drift | Naming violations, style drift | weekly |
| Dead code | Orphaned files, unused exports | weekly |
| Dependency entropy | Known CVEs, major version lag | weekly |
| Harness entropy | Missing tools, broken hooks | weekly |
| Architectural fitness | Layer violations, coupling trends, complexity hotspots | weekly |
| Learning-driven | Reflection regression detection, assessment gap analysis | weekly |
| Memory entropy | Stale reflections, duplicate entries, contradicted memory | weekly |

For a full catalogue of GC patterns with HARNESS.md entry examples,
consult `references/gc-catalogue.md`.

## Designing a New GC Rule

1. Identify the entropy: what drifts over time in this codebase?
2. Describe the check: what would a reviewer look for?
3. Choose frequency: how fast does this entropy accumulate?
4. Decide enforcement: can a deterministic tool check this, or does it
   need agent reasoning?
5. Apply the auto-fix rubric: is automated correction safe?
6. Add the rule to HARNESS.md's Garbage Collection section

## Architectural Fitness Functions

Fitness functions are GC rules that measure architectural properties
rather than fighting entropy in individual files. Where documentation
staleness or dead code checks look at the state of specific files,
fitness functions assess system-wide properties: layer boundaries,
coupling trends, complexity hotspots.

The concept comes from Ford, Parsons, Kua & Sadalage's *Building
Evolutionary Architectures*. Architecture degrades through accumulated
small violations that no single constraint catches. Fitness functions
detect the accumulation on a weekly cadence.

For the full framework, tool catalogue, and guidance on writing fitness
function GC rules, consult the dedicated skill at
`../fitness-functions/SKILL.md`.

## Learning-Driven GC

Most GC rules scan code or configuration for entropy — stale docs,
dead code, drifting conventions. Learning-driven GC rules take a
different input: compound learning artifacts such as reflections and
assessments. Instead of asking "has the code drifted?", they ask
"has the team learned something that the harness hasn't absorbed yet?"

This category exists because the harness should grow from experience.
When REFLECTION_LOG.md records the same type of surprise repeatedly,
that pattern is a missing constraint. A learning-driven GC rule
detects the gap and proposes the constraint — closing the loop between
compound learning and harness evolution.

### Reflection-driven regression detection

The primary example of learning-driven GC. This rule reads
REFLECTION_LOG.md, groups surprises by theme, and flags any theme
appearing in 2+ entries that is not already covered by a HARNESS.md
constraint. When an uncovered pattern is found, the GC agent creates
a GitHub issue proposing a new constraint with evidence (reflection
dates and quotes), suggested enforcement type, and suggested scope.

See the HARNESS.md template for the rule entry and
`references/gc-catalogue.md` for the full catalogue entry.

### Memory entropy (Dream Consolidation)

Compound learning artifacts accumulate their own entropy. REFLECTION_LOG.md grows with duplicates. AGENTS.md collects entries that contradict later experience. Convention files drift from the codebase they describe. Memory that is never pruned becomes noise — the agent loads context that contradicts current practice or references reversed decisions.

**Dream Consolidation** (from the framework's Appendix J) addresses this at two timescales:

- **Session-end**: check new reflections for duplicates or contradictions with existing entries. Merge duplicates. Flag contradictions for human resolution. Update the Tier 1 memory index if new topics were added.
- **Periodic deep consolidation** (weekly or quarterly): review the full memory corpus. Prune entries superseded by code changes. Promote recurring patterns into durable conventions. Archive reflections older than two quarters that have not been promoted.

A memory entropy GC rule in HARNESS.md:

- **What it checks**: Whether REFLECTION_LOG.md or AGENTS.md contain duplicate, contradicted, or stale entries
- **Frequency**: weekly
- **Enforcement**: agent
- **Tool**: harness-gc agent
- **Auto-fix**: false (contradictions require human judgment)

## Additional Resources

### Reference Files

- **`references/gc-catalogue.md`** — Complete catalogue of common GC
  patterns with HARNESS.md entry examples, detection approaches, and
  the auto-fix safety rubric
- **`../fitness-functions/SKILL.md`** — Architectural fitness functions
  skill with framework, tool catalogue, and GC rule mapping guidance
- **`../fitness-functions/references/fitness-catalogue.md`** — Concrete
  HARNESS.md GC rule entries for each fitness function type

## Reflection log archival — two GC rules with safety asymmetry

The plugin ships two related GC rules that share a schema (the
`Promoted` line per reflection entry) but differ in safety profile:

### Path 1: `Reflection log archival of promoted entries`

- **Deterministic**, **auto-fix true**.
- Fires weekly via `gc.yml`.
- Operates on entries with an explicit `Promoted` line.
- Pre-archive verification: the script verifies the Promoted line's
  right-hand side resolves to actual AGENTS.md or HARNESS.md content
  before archiving. Skips with a warning otherwise — recovers on the
  next run after the curator reconciles.
- Auto-fix is safe because the signal (a `Promoted` line) is explicit
  AND verified against current tree state.

### Path 2: `Reflection log aged-out review`

- **Agent-enforced**, **auto-fix false**.
- Fires monthly. **Opt-in** via the GC-rule declaration in HARNESS.md.
- Operates on entries older than the configured threshold (default
  180 days) that lack a `Promoted` line.
- Emits **evidence** (recurrence count, AGENTS.md/HARNESS.md
  text-overlap matches with quoted excerpts, single-instance signal),
  **NOT pre-classified labels**. Curator interprets the evidence.
- Auto-fix is not safe because the absence of a `Promoted` line is
  ambiguous — the entry might still be relevant or might warrant
  promotion the curator hasn't got around to.

The asymmetry is deliberate: explicit signal + verification → safe to
auto-act; absence of signal → human judgement gates the move. See
`docs/superpowers/specs/2026-04-30-reflection-log-archival-design.md`
for the full design rationale.

## Read-side filtering policy

Independent of archival, every reader of `REFLECTION_LOG.md` should
bound its default intake. See the HARNESS.md `## Read-side filtering`
section for the configured defaults and the per-reader policy.