Caretaker 0.6.0 development verification status
=================================================

Status date
-----------
2026-08-18

Scope and interpretation
------------------------
This is a transparent development-tree verification status, not a release
certification or guarantee. Caretaker is alpha research software. A tagged
release should receive a fresh run on every supported Python version, an
installed wheel, and an extracted source distribution.

Environment used for this review
--------------------------------
Python: 3.14 (review environment; declared support is CPython 3.11-3.13)
Platform: Linux workspace; full run allowed normal GnuPG-agent and Unix-socket access
Command: PYTHONPATH=src venv/bin/python -m pytest -q

Observed result
---------------
- 300 passed;
- 11 strict expected failures representing known security/assurance debt;
- no unexpected failures.

The complete run included GnuPG key/signature tests and Unix-domain logging and
control-socket tests. Forgejo CI is configured to run the suite on ordinary Linux
for CPython 3.11, 3.12, and 3.13; this local review used Python 3.14 and therefore
supplements rather than replaces the declared-version CI matrix.

Known strict expected failures
------------------------------
The executable debt ledger currently covers:

1. operator override of missing validation isolation;
2. arbitrary pickle-serializable validation request objects;
3. missing mandatory validation-check completeness;
4. dynamically constructed prohibited dunder access;
5. same-UID administrative authorization ambiguity;
6. validation results not bound to candidate/base/policy transaction identity;
7. non-finite validation measurements;
8. missing persisted validation backend/isolation identity;
9. unused StatePolicy.restore_for_validation assurance setting;
10. marker-only Multipass network-isolation assertion;
11. inaccurate ephemeral-workspace capability for persistent VMs.

The prior Guard automatic-baseline-acceptance documentation inconsistency was
corrected in this update and its regression now passes normally.

The authoritative tests are tests/test_validation_trust_boundary.py and
tests/test_security_assurance_regressions.py. The public design and remediation
ledger is docs/FUTURE_WORK.md. A strict expected failure must not be interpreted
as an implemented security property.

Additional checks performed
---------------------------
- Python module and CLI imports succeeded during test collection outside the
  isolated validation facilities.
- Documentation and package metadata were reviewed against the implementation.
- Relative links across root, docs, and example Markdown resolve locally.
- Current operator guides are checked against retired Lab/Console labels and the
  role-oriented signing commands.
- git diff --check is required before the documentation update is committed.

Historical Caretaker 0.5.0a1 verification report
================================================

Historical notice
-----------------
This report records verification performed for 0.5.0a1. It is retained as release
history and is not a verification report for the current 0.6.0 research tree.
Current features, test counts, security debt, and isolation backends differ. Do
not use the results below as evidence that the current checkout has been verified.

Release theme
-------------
This alpha adds the operator-controlled Logging subsystem and its integration
with Guard, Repair, Integrity, and the shared runtime control plane. It also
adds application-scoped multiprocessing collection, supplemental evidence
attachments, system-data capture, historical baselines, interrogation, and
runtime signing with policy-controlled key evolution.

Environment
-----------
Python: 3.13.5
Platform: Linux x86_64
Package baseline: Python 3.11+
Cryptographic test backend: cryptography 46.x with Ed25519 support

Verification performed
----------------------
1. Complete source-tree test suite in one interpreter:

   PYTHONPATH=src python -m pytest -q
   Result: 90 passed

2. Python compilation:

   python -m compileall -q src examples
   Result: passed

3. Installed-wheel test suite from outside the source tree:

   python -m pip install --no-deps --target <temporary-site> \
       caretaker-0.5.0a1-py3-none-any.whl
   PYTHONPATH=<temporary-site> python -m pytest -q
   Result: 90 passed

4. Extracted source-distribution test suite:

   tar -xzf caretaker-0.5.0a1.tar.gz
   cd caretaker-0.5.0a1
   PYTHONPATH=src python -m pytest -q
   Result: 90 passed

5. Command-line interfaces:

   caretaker-logging --help
   caretaker-run --help
   caretaker-guard --help
   caretaker-integrity --help
   Result: passed

6. Logging demonstration:

   PYTHONPATH=src python examples/logging_demo.py
   Result: passed; emitted the expected late-start warning, function result,
   append-only segment, compressed closed segment, manifest, and SQLite index.

7. Multiprocessing and supervised-runtime paths:

   Covered by the test suite, including multiple local Unix-socket emitters,
   remote attachments, work and worker registries, application-scoped system
   collection, and control-plane interactions.
   Result: passed

8. Runtime signing and key evolution:

   Ed25519 ephemeral signer tests cover signed manifests, policy-driven epoch
   rotation, transition signatures from the old key to the new public key,
   public identity publication, and the absence of private-key disclosure from
   public interfaces. The default maximum epoch duration is 86,400 seconds.
   Result: passed

9. Record and recovery behavior:

   Tests cover the 4 KiB primary record limit, versioned TLV fields, skipping
   unknown fields, truncated-tail recovery, cross-segment hash chains,
   compressed supplemental attachments, and rate-driven attachment sampling.
   Result: passed

10. Persistent private-key material scan:

   Source, wheel, and source-distribution archives contain no recognizable
   armored private-key blocks or fixed private-key material. The package does
   intentionally contain runtime ephemeral key-generation and signing code.
   Result: passed

New subsystem coverage includes
-------------------------------
- standard Python logging-handler compatibility and structured direct events;
- operator-owned unsigned policy loading and attributable policy snapshots;
- explicit higher-mode policy reconciliation and reversible mode leases;
- policy-driven buffering, backpressure, rotation, compression, retention,
  storage-emergency behavior, and high-priority evidence preservation;
- application, Guard, Repair, Integrity, audit, and emergency log channels;
- decorator masking before persistence or LLM analysis;
- 4 KiB versioned record framing and separately compressed large attachments;
- hash-chained segments and optional ephemeral or external signing contracts;
- daily-by-default ephemeral key evolution with signed key transitions;
- local Unix-domain event and administrative control sockets;
- peer process identity, active-work tracking, worker health, and watchdog
  restart accounting;
- application-scoped /proc and /sys collection with synchronized cycle times,
  process-tree selection, and independent rotation and retention;
- application, module, and function baselines, multiple accepted anchors,
  per-unit-of-work comparisons, trend and slow-drift findings;
- deterministic interrogation and structured advisory Ollama assessments;
- manual proposal/approval Repair authority and stale-policy deployment gates;
- hard prohibition on generated modification of Caretaker's own code.

Security interpretation
-----------------------
Caretaker remains application-scoped research software. It runs with
the application's privileges and is not a kernel or hostile-code security
boundary. Python audit hooks, decorators, runtime introspection, and local Unix
socket credentials provide useful evidence and control points, but native
extensions, ctypes, subprocesses, a compromised interpreter, or a same-user
attacker may bypass or alter them.

Hash chaining without an independent commitment does not prevent a capable
attacker from replacing an entire local corpus. Ephemeral signing improves
post-run resistance if private key material was not recovered during runtime,
but self-recorded public keys can also be replaced with the corpus. External
public-key anchoring, an external signer, or shipping records through an
independent logging agent to a separate collection system materially improves
security because an attacker must compromise more than one evidence location.

The LLM is advisory for logging interrogation and root-cause hypotheses. It may
participate in candidate selection only under explicitly enabled automatic
Repair authority. Deterministic policy, integrity, validation, regression,
behavioral, and observation gates remain authoritative.

Known limitations and deferred work
-----------------------------------
- system-data parsers and semantic metric extraction are intentionally deferred;
- the built-in sink is local; remote shipping uses a future LogSink implementation;
- Python cannot prove complete in-memory zeroization of ephemeral private keys;
- external public-key witnessing and external manifest signing require an
  operator-provided process or agent;
- async repair and async-generator handling remain deferred;
- hard interruption of arbitrary hanging functions remains deferred;
- container, VM, kernel, or hardware-enforced isolation remains deferred;
- cross-host ordering and distributed baseline aggregation remain future work;
- general live replacement of already imported third-party modules remains
  restricted to approved routing plus supervised restart.
