| name | warp-run-log |
| description | Maintain the durable, per-ticket run log that warp deploy/update skills append to at every milestone — a Linear-document-by-title primary with single-writer discipline and a local-file fallback, a machine-parseable per-chain row plus prose entry shape, and a surface-the-URL-as-proof hard gate. Referenced by any warp deploy/update skill that must leave a retrospective trail across worker restarts. |
Warp Run Log
Warp deploy/update runs are long, multi-milestone, and frequently interrupted (worker restart, session-restore, context compaction). The run log is the durable trail that lets a run be picked up after an interruption and lets each skill revision be tuned against what actually happened (floors vs actuals, timeouts, retries). Skills invoke this skill's contract instead of restating it, so the storage rules stay consistent everywhere.
Why a dedicated skill
- Single source of truth for the storage target, single-writer rule, entry shape, and proof gate — these must be identical across every skill in the chain or a resumed run reads an inconsistent log.
- The contract had already been copy-pasted into two skills and was missing from the rest that do equally destructive, resumable work; centralizing it closes that drift and makes "add a run log to skill X" a one-line reference.
Input (from the calling skill)
- Calling skill name — used verbatim in each prose entry's header (e.g.
warp-deploy-init-route).
- Milestone list — the specific events this skill must log (the caller supplies its own "log at least" list; see each consumer).
- Ticket ID — the per-ticket key; it names the document.
The storage contract
Every milestone must append an entry to a durable, per-ticket run log — durable meaning it survives a worker restart / session restore. The worker's local filesystem (~/.hyperlane/) does NOT qualify on its own: it is ephemeral and vanishes on restore, which is the exact event the log exists to survive.
