reliquary/docs/workpad/plans/2026-09-17-remaining-findings-4-5-6.md

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.