# Knowledge maintenance

Use this path only when the user explicitly asks to inspect or change workspace knowledge. Keep it separate from every Atomic Article batch. Generic knowledge tools never satisfy an article context receipt.

Follow this order:

1. Confirm the authenticated role is `content_writer`, the intended workspace is granted, and the live tool surface contains the required tools. Require write access before proposing a revision.
2. Call `knowledge_get` for the exact workspace. Locate the workspace-owned document by its returned `id` and `kind`; never invent a document ID.
3. Read the complete returned document and inspect `status`, `revisionId`, `activeRevisionId`, `editable`, and the review queue. Use `knowledge_search` only to find related evidence, never as the replacement text.
4. If a draft already exists, modify it only when the request explicitly targets that draft. Otherwise stop and report the pending draft so a person can resolve it.
5. Preserve every unaffected rule and section. `knowledge_revision_create` stores a complete replacement body, not a patch. For an Offer document, preserve or update the structured facts consistently with the body.
6. Call `knowledge_revision_create` once with the exact workspace ID, document ID, title, complete body, and Offer facts when applicable.
7. Call `knowledge_get` again. Verify the new revision is `draft`, appears in `reviewItems`, contains the requested change, and has not changed the active revision ID.
8. Report the document kind, draft revision ID, requested change, and anything a human should review. State clearly that the change is not active yet.

Never call `knowledge_initialize`, attempt activation, change workspace membership or settings, or claim that a draft is active. If the credential is read-only, the document is followed rather than owned, `editable` is false, the requested base is ambiguous, or any verification fails, stop without writing.