Moving a chore log to another chore leaves the old chore's last log stale

Context

A chore's last log is field_last_chore_log_ref. ECA process_azwntkf ("Chore log: update chore") keeps it up to date and runs when a chore log is created, updated or deleted. It loads the chore from the log's current field_chore, re-queries the lastest_chore_log view for that chore, and saves it. process_chorenextdue then derives field_last_chore_log_date and field_next_due_date from the reference. See docs/sites/inventory.md → Chore automation.

Deleting: fixed

Since the 2026-10-21 rewrite, deleting a log reverts the chore to its previous latest log. This was verified on chore 90, inside a rolled-back transaction: a new log took the reference, and deleting it put the reference back on #360 (2026-10-14), with the next due date recomputed.

Moving: still broken

Changing field_chore on an existing log from chore A to chore B:

• B is updated correctly, because the update event loads the chore the log points at now.
• A is never looked at. If the moved log was A's latest, A keeps pointing at a log that now belongs to B, and keeps its last and next-due dates.

Reproduced with chore 90 → 67: chore 90's reference stayed on the moved log.

Decision

The last-log recompute moves from ECA to inventory_custom, next to ChoreLogTree (decided by the issue owner, 2026-10-21). process_azwntkf is retired rather than patched, so field_last_chore_log_ref still has one writer. process_chorenextdue stays as it is: it runs on chore presave and derives the dates from the reference.

On update, the PHP side compares $entity->original->field_chore with the new value and recomputes both chores when they differ.

Related

• Moving a log also doesn't move it in the log tree (field_parent_chore_log). It stays attached to a log of A's ancestor, and logs beneath it stay with it. This is listed under Known gaps in the site doc and probably wants its own task. With the recompute in PHP beside ChoreLogTree, both can hang off the same "chore changed" check.

TODO

• [ ] Recompute a chore's field_last_chore_log_ref in inventory_custom on chore log insert, update and delete. Take the latest published log by field_log_date DESC, id DESC, as the lastest_chore_log view does, or clear the reference when there is none. Save the chore only when the reference actually changes.
• [ ] On update, recompute the original chore as well when field_chore changed.
• [ ] Delete process_azwntkf (eca.eca.process_azwntkf, eca.model/modeler_api.data_model.eca_bpmn_io_process_azwntkf). Delete the lastest_chore_log view too if nothing else uses it.
• [ ] Verify on the inventory site, inside a rolled-back transaction (it holds live data):
  • new log, back-dated log and deleted log all behave as they do now;
  • moving a chore's latest log to another chore makes the old chore fall back to its previous log, or clears its reference if it has none;
  • the new chore takes the moved log only if it is newer than its own latest;
  • the old chore is unpinned only if its reference changed.
• [ ] Update docs/sites/inventory.md: the Chore automation diagram and the process_azwntkf section, and remove the matching bullet from Known gaps → Chore logs.