Audit & rollback

If it happened, you can explain it. If a patch was applied, you can roll it back. hash-chained

What you’ll get

• How the event log and hash chain work
• Exact CLI for audit, verify, report, export
• Patch list / show / apply / rollback

Event flow

Gated side effects always land on the chain.

Audit guarantees

• Append-only log; every event has timestamp + session id
• Side-effect events reference their permission decision id
• No raw media bytes in transcript/audit — only content-hash MediaRefContent-addressed media reference; bytes stay in the object store.s
• File history is queryable: which agent, task, patch, when
• Allow/deny is explainable: policy + reason on the decision
• Targets: intercept out-of-workspace access, zero secret plaintext in logs, every side effect audited

CLI — inspect

audit-cli.sh

carina sessions
carina audit SESSION              # raw event stream
carina audit verify SESSION       # hash-chain integrity
carina audit last                 # most recent session summary
carina report SESSION             # violations, files, commands
carina export SESSION             # full audit bundle
carina items SESSION              # normalized UI/SDK item stream
carina session review SESSION     # governance-oriented projection

CLI — patches

File mutations should go through the patch pipeline when policy requires it:

1. Propose (workspace.patch.propose / agent patch tool / carina patch propose)
2. Kernel evaluates PatchApply (may require approval)
3. Apply → verify → commit with rollback pointer
4. No half-applied state

patch-cli.sh

carina patch list SESSION
carina patch show SESSION PATCH_ID
carina patch propose SESSION PATH   # content on stdin
carina patch apply SESSION PATCH_ID
carina patch rollback SESSION PATCH_ID

Transaction review

next

The Fullscreen /changes workbench mirrors the transaction boundary rather than inventing a Git-only review model:

patch transaction
  -> affected files (A / M / D, additions, deletions)
     -> numbered hunks with attribution and verification evidence
        -> rollback preview for the same patch + transaction identity

The visible diff is a bounded review projection. A continuation row means more lines remain outside the viewport or source cap; it does not weaken verification or truncate the daemon’s rollback transaction. Confirmation is allowed only when the preview says the workspace is unchanged and its patch and transaction identifiers still match.

For keys, density, narrow-screen behavior, and accessibility, see CLI & TUI.

Recipe: after a bad edit

1. Find the session

   carina sessions
   carina audit last

2. List patches

   carina patch list SESSION

3. Roll back

   carina patch rollback SESSION PATCH_ID

4. Confirm chain still valid

   carina audit verify SESSION

Not a Git replacement

Audit and patches explain agent work inside a session. They do not replace Git history, PR review, or branch policy. Use both: Git for collaboration history, Carina for governance of agent effects.

If it fails

Symptom	Try
verify fails	Treat as integrity incident; do not ignore — export bundle and investigate
Empty patch list	Agent may not have written files, or used a path that did not create a txn
Cannot find SESSION	carina sessions / carina audit last

Related streams▾

• Raw audit — carina audit for forensics
• Items — carina items for product UIs
• Watch — carina watch SESSION live events

Source of truth

• docs/security-model.md (audit guarantees)
• Event / media rules in protocol + control plane
• CLI: carina --help · CLI reference
• Related: Policy · Observability traces

Next

• Common workflows — inspect / rollback recipes
• Method catalog — session.* / audit-related RPC