# Implementation plan: Findings 4, 5, 6

**Source**: `docs/workpad/reports/2026-09-17-spire-vs-tome-setup-and-learning.md`

---

## Finding 5 — Stale path in `tome.just:6` (quick fix)

**What**: `plugins/tome/tome.just` line 6 still reads:

```
#     mod tome "<path-to-spire-plugin>/skills/tome/tome.just"
```

Since commit `cfd3cfb` tome is its own plugin; the path should reference the tome plugin directory, not spire.

**Steps**:

1. Edit `plugins/tome/tome.just:6` — change the example path from `<path-to-spire-plugin>/skills/tome/tome.just` to `<path-to-tome-plugin>/tome.just`.

One-line fix, no design needed.

---

## Finding 4 — No curator (design needed)

**Current state**: Igor accretes dated refinement sections but explicitly defers compression: "The curator does not exist yet" (`plugins/spire/skills/igor/SKILL.md:59`). Tome's `curate` skill (`plugins/tome/skills/curate/SKILL.md`) has six methods — `seal` and `workpad-graduate` are the closest to what a Spire curator would do, but they operate on the wiki, not on accreted refinement sections in arbitrary docs.

**What the design must resolve**:

- **Scope boundary**: A curator that compresses accreted sections in workpad docs (journals, adept CLAUDEs) is a different operation from Tome's wiki curation. Should the Spire curator be a new skill that calls Tome methods when a wiki is present, or a standalone compression pass?
- **Trigger**: Tome methods are all `disable-model-invocation: true` (human-triggered). Should the curator also be human-triggered, or should Igor's wrap-up be able to invoke it?
- **Safety**: Accretion sections are append-only by design. Compression rewrites them. What is the rollback/audit story — git diff alone, or a pre-compression snapshot?

**Minimal first step (implementable now)**:

1. Create a stub skill at `plugins/spire/skills/curator/SKILL.md` with `disable-model-invocation: true`.
2. Define a single method: **compress-accretions** — takes a file path, reads all dated refinement sections, produces a consolidated replacement, writes it under a `## Compressed <date>` heading that replaces the individual sections.
3. Update `plugins/spire/skills/igor/SKILL.md:59` to reference the new skill instead of saying "does not exist yet."
4. Leave Tome integration (routing graduation candidates to `workpad-graduate`) for a second pass after Finding 6 lands.

---

## Finding 6 — Journal-to-wiki bridge is manual (design needed)

**Current state**: Igor's wrap-up (`plugins/spire/skills/igor/SKILL.md:123`) accretes corrections to existing docs but produces no signal about journal content that might deserve wiki graduation. `workpad-graduate` (`plugins/tome/skills/curate/SKILL.md:158-177`) fires only when a human identifies a note.

**What the design must resolve**:

- **Signal format**: What does a graduation candidate look like? A front-matter tag (`graduate-candidate: true`)? A section heading convention? A separate manifest file?
- **Who decides**: Igor at wrap-up (cheapest, but may over-nominate) vs. the curator in a batch pass (more judgment, but adds another deferred dependency on Finding 4)?
- **Cross-plugin coupling**: The signal originates in Spire (Igor's journal) but is consumed by Tome (`workpad-graduate`). Where does the contract live — in a shared spec, or each plugin documents its half?

**Minimal first step (implementable now)**:

1. Add a `## Graduation candidates` section to `plugins/spire/skills/igor/references/journal-template.md`. Igor fills it at wrap-up: one bullet per journal insight that passes the "earned place" test (would removing it cost thinking work, not just a tool call?).
2. Update `plugins/spire/skills/igor/SKILL.md` wrap-up (line 123) to include: "Review the journal for entries that would earn a place in the wiki. List them under `## Graduation candidates` with a one-line rationale each."
3. This is read-only from Tome's perspective — `workpad-graduate` already works on any note a human points it at. The graduation-candidate list simply makes the human's (or future curator's) triage faster.