Ability for mappers to remap and change the state of a task after completion

Can we add the ability to remap and change the state of a task after they have already marked it as complete (be it in any state). The use cases mostly come from the QC process, but may also come from self-learning.

Some examples of when this may be useful.

For “I fixed it”: An example would be it a user was making edits based on an incorrect understanding of policy, so if a user added 100 street names based on what they thought was an approved resources, but it is discovered it is not an approved resources, they edits would need to be reverted and the tasks changed to “too hard/can’t see”, if no other ground truth were available.

For “too hard/can’t see” the opposite of the above may be true, the mapper was marking tasks as can’t see, but there was an approved resource they could use, and didn’t know about, so they can go back and add the names to streets and change the tasks to “I fixed it”

For “not an issue”, this too may come from a misunderstanding of policy, the mapper may think there is not an issue, but there really is, so in keeping with street names, a new mapper might see that a street name is “Main St” and it is being flagged as needing fixed, and they may not know that the street type needs to be spelled out and not abbreviated, so they will mark they task as “not an issue”, but then discover that street names need to be full spelled out and has to go back and fix the names and mark the tasks as “I fixed it”

The issue names no files, tests, or entry points. Start by tracing how completed tasks, mapper edits, and task states are represented and changed in the backend API. Define which post-completion remaps and state transitions are supported, how existing edits are affected, and tests that demonstrate the requested QC and self-learning scenarios.