Cleanup of documentation

memory/working/260224-wishlist-custodian.md

@@ -221,5 +221,27 @@ EPs need to be surfaced in `get_state_summary()`.
 | W2 | `register_project.sh` script + `make register-project` | 1 hr | 25K / registration | Before next project |
 | W5 | `TOOLS.md` reference card | 30 min | 2,500 / session | Next custodian session |
 | W4 | Topic IDs in canon charters | 20 min | 200 / registration | Low urgency |
-| W7 | SessionStart hook for API health | 30 min | Indirect | After W2 |
-| W8 | First-class EP entity in state hub (EP-CUST-001) | 2–4 hr | Indirect | When EP count warrants it |
+| W7 | SessionStart hook for API health | 30 min | Indirect | After W2 |
+| W8 | First-class EP entity in state hub (EP-CUST-001) | 2–4 hr | Indirect | When EP count warrants it |
+
+---
+
+## 2026-05-02 Update — Task-Flow Engine Lifecycle Model
+
+CUST-WP-0035 replaced the old assumption that State Hub lifecycle movement is
+only a fixed set of status enums and hardcoded transition tables.
+
+Current model:
+
+- Information objects expose a stored workstation label, still surfaced as
+  `status` for API compatibility.
+- `get_flow_state(entity_type, entity_id)` reports reachable workstations,
+  unreachable workstations, and blocking assertions.
+- `advance_workstation(entity_type, entity_id, target_workstation)` is the
+  preferred lifecycle movement tool when a flow definition exists.
+- Direct status update tools remain useful for bootstrap, legacy workflows, and
+  file-backed consistency sync, but they are no longer the conceptual center of
+  lifecycle management.
+
+Reference spec:
+`state-hub/docs/task-flow-engine-spec.md`