> For the complete documentation index, see [llms.txt](https://docs.tryprotege.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tryprotege.com/event-feed/pending-writes.md). # Pending Writes ## What this is A Pending Write is a Protege-authored change that is waiting for human review before it is applied in Hookshot™. Pending writes are created when the write policy for a project or Protege requires approval. ## When to use it Use this page when you need to: * Review changes a Protege wants to make * Approve, reject, or edit a pending change * Understand what happens when a pending write goes stale ## What you need first * A workspace with Proteges that write to the Work Hub under an approval-required policy * Permission to review pending writes (workspace owner, admin, or team lead) ## Steps ### 1. Find pending writes Open **Work Hub** → **Decisions** to see pending writes awaiting review. Each pending write shows: * The Protege that authored it * The target task and project * The operation type (create, update, comment, etc.) * Whether the write will sync to an external provider (Asana or Jira) * The policy reasons why approval was required ### 2. Review the change Open a pending write to see: * **Before snapshot**: The current state of the task before the change * **After snapshot**: What the task will look like if the change is applied * **Edited payload**: If you modify the change before approving, the edited version appears here {% hint style="warning" %} Always review both the before and after snapshots before approving. The Protege may have made assumptions about the current state that are no longer accurate. {% endhint %} ### 3. Approve, reject, or edit | Action | What happens | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **Approve** | The change is applied to the task. If the project has provider sync enabled, the change is also pushed to the external provider. | | **Reject** | The change is discarded. You can optionally provide a reason. | | **Edit then approve** | You modify the payload before approval. The edited version is applied instead of the original. | ### 4. Handle stale writes A pending write becomes **stale** if the underlying task has changed since the write was created. Stale writes are flagged because the before snapshot no longer matches the current state of the task. When you encounter a stale write: * Review whether the change is still appropriate given the new task state * If it is still valid, approve it (the system will apply it against the current state) * If it is no longer valid, reject it ### 5. Reopen a rejected write If you rejected a write by mistake, you can **reopen** it for re-review. The write returns to `pending` status and can be approved or rejected again. ### 6. Understand write policy and pending writes Pending writes are created when the write policy evaluates to `approval_required`. The policy is determined by four sources: 1. **Work Hub default** — the global setting 2. **Project policy** — per-project override 3. **Protege policy** — per-Protege setting 4. **Sensitivity** — the operation type If any source says `approval_required`, a pending write is created instead of applying the change directly. Operations that always require approval: * Approval-sensitive work * Decision requests * Provider sync (writes that will push to Asana or Jira) ### 7. Review provider impact When a pending write targets a project that has provider sync enabled, approving the write will also push the change to the external provider. The pending write view shows whether the write has provider impact so you can consider the external consequences before approving. ## How to verify * Pending writes appear for Protege changes that require approval * Approved writes are applied to tasks and reflected in the task detail view * Rejected writes are discarded and not applied * Stale writes are flagged with a clear indicator * Provider-synced writes update the external provider after approval ## Common failures * Approving a write without checking the after snapshot * Ignoring stale indicators when the task has changed * Approving a provider-projected write without considering the external impact * Rejecting a valid write that could have been edited instead * Assuming direct mode is safe for all projects without reviewing the operations ## Next step * [Work Hub](/event-feed/work-hub.md) * [Audit](/event-feed/audit.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.tryprotege.com/event-feed/pending-writes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.