← 2.1.16 Primitive tested · runtime-test

Combo Test: Task Metadata for Audit Trails

Task metadata field can store arbitrary structured data, enabling audit trails.

Task metadata in Claude Code 2.1.16 allows storing arbitrary JSON structures alongside task state, enabling runtime audit trails through merging partial updates.

How It Works

Tasks store metadata in ~/.claude/tasks/{session-id}/{task-id}.json under a top-level metadata field. On creation, TaskCreate accepts a metadata object. Updates via TaskUpdate merge new fields into existing metadata: unmentioned keys persist, updated keys replace their values, and new keys get added. The merge strategy preserves audit history without requiring read-before-write ceremonies.

What the Test Found

A four-part runtime test verified the primitive end-to-end. Initial TaskCreate with {"created_at": "...", "audit_log": ["task created"]} stored successfully. A subsequent TaskUpdate adding {"audit_log": [...], "last_update": "..."} merged correctly, keeping the original created_at while replacing the audit_log array and adding last_update. One caveat: TaskGet does not display metadata in its CLI output; inspection requires reading the JSON file directly. The schema stores metadata as an object alongside task id, subject, description, status, and block relationships.

Why It Matters

Audit trails traditionally require external logging systems or mutation-safe versioning. The metadata primitive enables lightweight in-task history: append timestamps on state changes, track event sequences in arrays, and reconstruct causality from stored JSON. Subagents and background routines can read task JSON directly to audit their own work.

Caveats

Array semantics on update replace rather than append: setting "audit_log": [...] overwrites the previous array entirely. No built-in timestamp generation—callers must generate ISO dates manually. The CLI lacks a metadata display command, requiring tooling or direct JSON reads for visibility.

Evidence & receipt
  • file2.1.16/tests/combo-03-task-metadata/TEST-RESULTS.md
◇ ed25519 receipt
idprimitive_88705e40f3732c09295ee09d
alged25519
pubkey9b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd
sig37499d47c3bc61c6d47c3bb9b4e641c092b5be03c4ac8d52eb8c821f042481da563ae882b0bfd2a8ef98b05f53c53eae802dd67c25d2d10a29c1424e963d1706

Signed with an ed25519 key held off the repo. Anyone can verify against the published public key; nobody without the secret key can forge it. Click verify: it recomputes the signature in your browser. The signature proves integrity and authorship of this exact content — not a third-party timestamp or that the underlying claim is objectively true. signedAt is when the @f3/attest pipeline ran, not when the work happened; the evidence refs carry the source dates.

Connected