lifeloop-cli 0.4.0

Provider-neutral lifecycle abstraction and normalizer for AI harnesses
Documentation
# Renewal Reset Capability Boundary

## Status

Accepted for issue #3.

## Decision

Lifeloop models renewal as adapter capability and receipt evidence, not as a
client renewal protocol.

The adapter manifest may expose `renewal.reset.{native,wrapper_mediated,manual}`
and `renewal.continuation.{observation,payload_delivery}`. It may also expose
`renewal.profiles` when the claim depends on a specific host integration
profile. These fields answer only whether the harness integration can prove a
reset/continuation lifecycle path and whether it can deliver opaque client
facts across that boundary.
Omitting `renewal` means the adapter has not made an evaluated renewal claim;
an explicit all-`unavailable` renewal object means the adapter did evaluate the
path and found no safe reset/continuation support.

Lifeloop receipts carry reset-prepare and continuation evidence through normal
`payload_receipts` provenance. The payload body and any continuation token
semantics remain opaque to Lifeloop.

As of issue #20, Codex is the first positive renewal claim. The original proof
used the opt-in `ccd-renewal` host-hook profile; the current greenfield CCD flow
uses Lifeloop's subprocess callback contract with `ccd lifeloop client`.
CCD prepares renewal state through
`ccd renewal prepare --adapter codex --reset-path wrapper`, writes a
CCD-owned `renewal-state` blob through `lifeloop continuation put`, and consumes
that blob on the next top-level lifecycle start through `ccd lifeloop client`.
This proves wrapper-mediated reset/continuation delivery without making
Lifeloop the owner of CCD renewal leases, thread binding, or token validation.

## Boundary

Lifeloop owns:

- manifest capability claims for reset and continuation delivery;
- negotiation names for renewal capabilities;
- receipt evidence for reset-prepare and post-reset continuation facts;
- failure-class mapping for unsupported, stale, manual-only, or lost-delivery
  renewal paths.

Clients own:

- renewal leases;
- continuation token issuance and validation;
- thread binding;
- policy deciding whether renewal is allowed;
- recovery state mutation after a reset.

CCD issue https://github.com/nantobv/ccd/issues/705 can depend on this
Lifeloop capability layer without importing CCD renewal policy into Lifeloop.