← graph

research-archival-behavior

Research: archival behavior + cross-graph overlay design

Metadata

Statusdone
Assignedagent-918
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Created2026-04-28T20:16:32.616770236+00:00
Started2026-04-28T20:18:30.813767450+00:00
Completed2026-04-28T20:22:42.410863625+00:00
Tagseval-scheduled
Eval score0.78
└ blocking impact0.80
└ completeness0.80
└ coordination overhead0.85
└ correctness0.85
└ downstream usability0.82
└ efficiency0.75
└ intent fidelity0.89
└ style adherence0.78

Description

Description

Survey + design task — output is a markdown design doc, NO code changes.

User question: 'do we have archive graphs that work back... and can these just be overlayed to get a big graph of past stuff?' They want to understand what's already there for archival and what a 'big graph of past stuff' would look like.

What to investigate

  1. What exists today for archival in wg:
    • graph.jsonl format — how are archived/done tasks represented? Soft-delete tag, or moved to a separate file?
    • refs/archive/* git refs — referenced in cherry-pick-valuable task; what writes them, what reads them?
    • .workgraph/log/ — agent archives, what's in there
    • retire-compact-n retired .archive-N cycle scaffolding — what was removed, what remains?
    • The wg sweep and wg gc commands — what do they actually move/delete?
  2. What overlay would mean:
    • Mounting a past archival graph alongside the current live graph
    • Visualizing both in wg viz, wg tui, the upcoming HTML view
    • Querying across them (wg list --include-archived)
    • Export/import format (single archive bundle? per-task files? git refs?)
  3. Tradeoffs:
    • Single graph.jsonl with archived tasks tagged, vs separate archive files
    • Time-bounded archives (per-month bundles?) vs single growing archive
    • Performance impact on graph reads when overlay is active

Output (the deliverable)

A markdown file at docs/archival-design.md (or similar) covering:

  • Current state map (one paragraph per existing mechanism)
  • Recommended target shape — picking concrete answers for each fork above with rationale
  • Migration path from current to target
  • Open questions to bring back to the user before implementation

Out of scope

  • Any code changes
  • Implementing overlay
  • Touching graph.jsonl format

Validation

  • Design doc exists at the proposed path
  • All five 'what exists today' bullets are accurately answered (cite file paths / commands)
  • Target shape is concrete enough that a follow-up impl task could be written from it
  • Open questions section explicitly lists forks the user should weigh in on
  • No code changes (git diff main shows only the new doc file)

Depends on

Required by

Log