[Feature] Accept or discard reviewer changes from the CLI

[tiapia00]

It would be useful if olcli provided commands to programmatically accept or discard changes suggested by reviewers in an Overleaf project.

Currently, olcli can retrieve reviewer comments/changes, but workflows that process review feedback from the command line would benefit from being able to resolve the corresponding changes directly.

A possible interface could look like:

olcli changes list --status open --json <project_id>

olcli changes accept <change_id> <project_id>
olcli changes discard <change_id> <project_id>

Alternatively, if reviewer changes are represented as part of the comments/review API:

olcli comments accept-change <comment_id> <project_id>
olcli comments discard-change <comment_id> <project_id>

Ideally, the commands should:

• accept or discard a specific reviewer change using its ID;
• return a non-zero exit code if the operation fails;
• support --json output for scripting and automation;
• expose enough information through the existing list command to associate a reviewer comment/change with the corresponding ID.

Motivation

This would make it possible to build automated review workflows around olcli. For example, an agent could:

1. Retrieve open Overleaf comments and suggested changes.
2. Inspect the corresponding LaTeX source.
3. Propose a fix to the user.
4. Wait for explicit user approval.
5. Apply the modification locally.
6. Accept or discard the corresponding reviewer change/comment through olcli.

This would allow olcli to support human-in-the-loop workflows where an automated tool assists with reviewer feedback while the user retains control over which changes are accepted.

[aloth]

Thanks, this is a well-shaped request - the proposed surface reads like it was written against the existing commands rather than from scratch.

One correction to the premise, because it changes the size of the work: olcli reads comment threads, not tracked changes. The document join decodes ranges.comments and nothing reads ranges.changes, so there is no change id to accept or discard yet. olcli comments today has list, reply and resolve, and all three operate on threads. The first half of this is surfacing tracked changes at all, and olcli comments list is the natural place for it.

I am scheduling this for the October release and will look into the API side before committing to a surface. Accepting and discarding are mutations of someone else's review, so I want to understand what Overleaf actually exposes before designing around it.

The human-in-the-loop workflow you describe is the right motivation and matches where the comments commands were already heading.