Auto-log HAND.toml SHA-256 hash to Merkle audit chain on reload

[dancingclaw]

Upstream issue: Auto-log HAND.toml SHA-256 hash to Merkle audit chain on reload

Repository: https://github.com/RightNow-AI/openfang
Affects: OpenFang v0.6.4 (SHA 3cce1eb3fb19ad590a0937e039a8bf8bc09aba13)
Filed by: assistant project / Phase 7 (personal-family pilot)
Decision provenance: D-A12 issue 3
Phase 3 carry-forward: RV-04 / DV-06

Summary

The Merkle audit chain in crates/openfang-runtime/src/audit.rs
(AuditLog::record at line 180; compute_entry_hash at lines 61-79)
records boot-time HAND.toml hash entries correctly. However, HAND.toml
reload events (the live-reload path used to apply config changes
without restart) do not append a fresh hash entry. Result: the
audit trail can drift away from the on-disk config without leaving an
auditable record of when the change took effect.

Phase 3 RV-04 verified the boot-time path passes; DV-06 (HAND.toml
hash-audit) folded into RV-04 confirmed the post-boot reload-side gap;
see threat-models/personal-family/verification/rv-04.md.

Context

The personal-family pilot edits HAND.toml during operations (HAND B
extension, schedule changes). Without a reload-time hash record, the
operator cannot answer "which HAND.toml was active at 14:32?" from the
audit trail alone. Pilot wraps reloads in
instances/personal-family/wrappers/hand-reload, which computes the
SHA-256 + appends an audit entry (via this issue's POST /api/audit/append
companion — see openfang-7-05) before signalling the daemon.

Reproduction

# Boot openfang; capture audit chain tip
openfang start &
openfang security verify   # exit 0
openfang security audit --json | jq '.[-1].hash'   # H_1

# Edit HAND.toml; trigger reload (e.g., SIGHUP — actual reload syscall TBD)
$EDITOR /etc/openfang/HAND.toml
kill -HUP $(pidof openfang)

# Re-check audit tip — expect a new entry recording the new HAND.toml SHA-256.
openfang security audit --json | jq '.[-1].hash'   # H_2 ?
# In v0.6.4, H_2 == H_1 — no new entry is appended on reload.

Proposed fix

In the HAND.toml reload code path (whichever signal/IPC handler triggers
it), compute SHA-256 of the new on-disk HAND.toml and call
AuditLog::record(AuditAction::ConfigChange, detail = format!("HAND.toml reload sha256={}", new_hash), outcome = "ok") BEFORE swapping the
in-memory HandDefinition. Mirror the boot-time hash log already emitted
by the kernel.

Affected upstream files

• runtimes/openfang-agent/crates/openfang-runtime/src/audit.rs (lines
  61-79 hash compute, line 180 record entry — already correct)
• runtimes/openfang-agent/crates/openfang-runtime/src/kernel.rs (reload
  path — needs the pre-swap hash + record call)

Workaround removal trigger

On upstream merge of reload-time hash logging, drop
instances/personal-family/wrappers/hand-reload per the P-15 floor.

[jaberjaber23]

Fixed in 2323cd5.

• crates/openfang-hands/src/registry.rs:25-33 add HandAuditCallback + SHA-256 helper
• crates/openfang-hands/src/registry.rs:62-87 set_audit_callback + emit_hand_loaded_audit invoked on every load path (bundled, workspace, install_from_path, install_from_content, upsert_from_content)
• crates/openfang-kernel/src/kernel.rs:1226-1259 kernel wires the callback to AuditLog::record(ConfigChange, ...) and backfills bundled hashes at boot
• crates/openfang-hands/src/registry.rs:1148-1248 two new unit tests cover the load and reload paths

Reload now appends HAND.toml reload hand=<id> sha256=<hex> to the Merkle chain before the in-memory swap.