no audit trail for project mutations beyond phase transitions

[physercoe]

Summary

The phase_history field on a project only records phase transitions (from → to). All other state-changing operations — parameter updates, deliverable state changes, goal text edits — leave no trace. There is no general-purpose audit log for project mutations, making it impossible to answer "who changed what and when."

Steps to reproduce

1. projects_update(parameters_json={...}) — change validation_steps from 100 to 200. Succeeds. No history entry.
2. projects_update(goal="new goal text") — change the project goal. Succeeds. No history entry.
3. deliverables_set_state(state="draft") — un-ratify a previously ratified deliverable. Succeeds. No history entry.
4. projects_get(project) — inspect phase_history. Still only the original phase entry.

Actual result after multiple mutations

"phase_history": [
  {
    "from": "",
    "to": "env-setup",
    "at": "2026-06-05T03:07:17Z",
    "by_actor": "system"
  }
]

No record of:

• Who changed parameters_json (and from what → to what)
• Who changed the project goal
• Who un-ratified the env-setup-report deliverable
• When any of these happened

Expected behavior

At minimum, the following operations should produce audit records:

• projects_update — any field mutation
• deliverables_set_state — any state transition
• deliverables_add_component / deliverables_remove_component
• criteria_set_state — met/failed transitions (currently recorded inline on the criterion, which is good)

The audit record should include: actor, timestamp, operation, old value, new value.

Impact

• Compliance/accountability: a ratified deliverable can be silently un-ratified with no way to trace who did it (combined with issue deliverable state transitions have no phase gating; ratified deliverables can be silently un-ratified #23, this is a significant integrity gap)
• Debugging: when a project gets into an unexpected state, there's no way to replay what happened
• Trust: the system has a phase_history field that implies auditing exists, but it's misleadingly narrow

Proposed fix

1. Extend phase_history into a general audit_log or add a separate project_events stream
2. Log: projects_update, deliverables_set_state, deliverables_add_component, deliverables_remove_component
3. Each entry: {actor, timestamp, operation, target, old_value?, new_value?}
4. Expose via audit_read or a new project_audit_log endpoint

Affected project

• Project: test-code-migration (id: 01KTAVZNCZGH1D9TJXAMWA636X)
• Verified by: changing parameters_json, goal, and deliverable states — none recorded

[physercoe]

Partly inaccurate — verified against the code. Mutations beyond phase transitions are audited: recordAudit(... "project.update" ...) fires on every projects_update (hub/internal/server/handlers_projects.go:690), plus project.create (:334), project.phase_set (:338), project.archive (:535); deliverable state changes emit audit rows in apply_deliverable_set_state.go; criteria hydration/marks audit too. The canonical log is the audit_events table — phase_history is just a denormalized column for fast reads, which is the narrow field this issue inspected.

So the accountability backbone exists. Narrowing to the genuine gaps:

1. audit rows don't carry structured old_value/new_value on field mutations.
2. no read endpoint scoped to one project's audit stream (the data is there; it isn't conveniently queryable per-project).

Leaving open for those.