lifeloop-cli 0.3.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, and that claim is
structurally scoped to the opt-in `ccd-renewal` integration profile. The profile
renders Codex hooks that invoke
`lifeloop --output hook-protocol host-hook ... --client-cmd "${CCD_BIN:-ccd}"`.
On `Stop`, Lifeloop observes CCD's renewal recommendation, calls
`ccd session renew prepare --adapter codex --reset-path wrapper`, and stores the
opaque continuation token in Lifeloop runtime state rather than hook stdout. On
the next Codex `SessionStart`, Lifeloop consumes that token with
`ccd start --refresh --continuation <token>` and verifies that CCD reports the
same thread binding. This proves wrapper-mediated reset/continuation delivery
without making Lifeloop the owner of CCD renewal leases 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/session 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.