Caretaker 0.6.5 development verification status
=================================================

Status date
-----------
2026-09-10

Scope and interpretation
------------------------
This is a transparent development-tree verification status, not a release
certification or guarantee. Caretaker is pre-version-1 alpha research
software. This verification covers the accepted application-local scope. A
published release should still 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.4 (review environment; declared support is CPython 3.11-3.14)
Platform: Linux workspace; full run allowed normal GnuPG-agent and Unix-socket access
Commands: make check; make package-check; git diff --check

Observed result
---------------
- 1031 passed;
- no unexpected test failures;
- source, test, example, and script compilation succeeded;
- the 0.6.5 source distribution and wheel built, passed exact payload parity,
  and passed Twine metadata checks.

The complete run included GnuPG key/signature tests, the real installed-shape
supervisor lifecycle regression coverage, 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 the additionally
supported Python 3.14 and supplements rather than replaces the CI matrix.
The exact Python 3.14.4 development and release-tool environment is recorded
in `constraints/caretaker-0.6.5-py3.14.txt`.

Known assurance debt
------------------------------
The executable regression coverage and roadmap continue to document these
known limitations. Passing the current suite does not mean these assurance
properties are complete:

1. arbitrary pickle-serializable validation request objects;
2. dynamically constructed prohibited dunder access;
3. same-UID administrative authorization ambiguity;
4. unused StatePolicy.restore_for_validation assurance setting;
5. marker-only Multipass network-isolation assertion;
6. inaccurate ephemeral-workspace capability for persistent VMs.

Required validation isolation is now non-overridable. Validation results are
bound to the candidate, base, target, policy, authority, requested isolation,
backend identity, and mandatory check set; measurements are finite and backend
and isolation identity are retained in repair attempts. The signed-wheel gate
remains separately blocked until release-station artifacts are regenerated for
the current development version.

These limitations are intentionally outside the accepted pre-version-1 sprint
boundary unless a deployment requires stronger assurance.

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 documented limitation 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.
- The real `caretaker.run` supervisor entrypoint was exercised through a
  subprocess with an importable probe application and a missing-module startup
  failure; readiness, child policy propagation, endpoint ownership, and cleanup
  were asserted in `tests/test_run_entrypoint.py`.
- `make package-check` passed for the final release artifacts
  `caretaker-0.6.5.tar.gz` and `caretaker-0.6.5-py3-none-any.whl`.
- `make verify-wheel` intentionally failed closed: the committed signed wheel
  manifests still describe the prior 0.6.1 publication and omit newer modules.
  Regenerating and re-signing those manifests is a separate release-station
  task; this release-version update does not modify signed publication
  material or weaken installed integrity verification.
- `git diff --check` passed before this verification update.

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.5 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.
