Locking entries
Knowledge base entries support custom fields, so LH Post Locking can lock them. A locked entry can only be changed, trashed or deleted by an account with the lock capability (manage_options by default). Lock entries whose content drives unattended agent runs, so that an account with only edit_posts cannot rewrite the instructions an agent will follow. The daily health check procedure, workflows/health-check and workflows/health-check/baselines, is locked for this reason.
Per-entry permission checks
The write abilities’ permission callback checks edit_posts, which is type-level and cannot see restrictions on a single entry. So update-entry also checks edit_post on the entry and trash-entry checks delete_post. When the entry is locked, the refusal says so and includes locked: true. If a write still reaches WordPress and LH Post Locking’s backstop refuses it, the ability replaces core’s “Content, title, and excerpt are empty” message with the same locked error. Any new ability that writes to one entry should use the same check.
create-entry can still add a child under a locked entry, since that does not change the locked entry itself.
Reading entries that are not active
The read abilities need only read, so any signed-in user can use them. list-entries only ever returns active entries. get-entry returns an active entry to anyone with read, but a draft, pending, private or trashed one only to a user with edit_post on it; anyone else gets “Entry not found.”, so the call does not reveal that the entry exists. Before 1.8.0, any signed-in user could read such entries by ID, slug or path.
