Problem
Auto Pull and Push is convenient for trusted, low-risk editing, but some teams need a review step before changes reach the canonical knowledge-base branch. Non-technical authors should still be able to edit in the visual editor without having to learn Git, while reviewers need a clear diff and an auditable approval path.
This is related to #1237 (accept/decline for file edits), but focuses on team publishing and protected canonical branches rather than only agent edit approval.
Use case
An author edits an existing document, sees the proposed changes, and submits them for review. A reviewer can inspect the diff, approve or reject the change, and publish it through the repository's normal branch or pull-request controls. Teams that do not need review should be able to keep the current automatic-sync workflow.
Proposed direction
- Add an optional review-safe project mode that keeps author changes out of the canonical branch until approved.
- Provide a clear diff and status such as draft, submitted, approved, rejected, or published.
- Integrate with branch/pull-request workflows where the remote supports them, without requiring authors to use Git directly.
- Preserve automatic sync as an explicit choice for low-risk projects.
- Ensure reviewer identity and the resulting commit remain visible in history.
Acceptance criteria
- A non-technical author can edit and submit a document without using a terminal.
- A reviewer can see exactly what changed before publication.
- Unapproved changes cannot be pushed to a protected canonical branch in review mode.
- Approval/rejection and resulting commits have an attributable history.
- Existing projects retain their current sync behavior unless review mode is enabled.
Please advise whether this belongs in the editor, sync engine, or an integration with repository pull-request providers.
Problem
Auto Pull and Push is convenient for trusted, low-risk editing, but some teams need a review step before changes reach the canonical knowledge-base branch. Non-technical authors should still be able to edit in the visual editor without having to learn Git, while reviewers need a clear diff and an auditable approval path.
This is related to #1237 (accept/decline for file edits), but focuses on team publishing and protected canonical branches rather than only agent edit approval.
Use case
An author edits an existing document, sees the proposed changes, and submits them for review. A reviewer can inspect the diff, approve or reject the change, and publish it through the repository's normal branch or pull-request controls. Teams that do not need review should be able to keep the current automatic-sync workflow.
Proposed direction
Acceptance criteria
Please advise whether this belongs in the editor, sync engine, or an integration with repository pull-request providers.