[Lizard]

Obviously, this needs some careful design discussion for how we want to do it in the future. However, for working with OmniPlan as it is now, I'd encourage users to behave as if (1) were true. That is, if you're going to change the completion status of a bug, check to make sure the start and end dates are current also.

I don't know that we can have OmniPlan just auto-move a 2-day task starting tomorrow back to start yesterday if you say it's half done. Maybe it's half-done because you worked on it all day yesterday. Maybe you worked on it this morning for 2 hours and made way more progress than you expected. If OmniPlan tried to guess what happened and moved things around, I think it would be wrong enough to scare users.

"Rules":
1) If you're changing a task's completion percentage from 0 to anything else, double-check the start date and make sure it's accurate.
2) If you're changing a task's completion percentage to 100%, double-check the end date is accurate.
3) If you've got a task that needs to be mostly done before another task can start, you've got 3 options
a) Create the Finish->Start dependency and realize this is a sub-optimal schedule and you'll probably deviate from it.
b) Create a Start->Start dependency instead of a Finish->Start. Also not completely accurate, but depending on how you're looking at the data, might be closer.
c) Break the first task into two separate tasks, such as "roughly plan user interface" and "fine-tune user interface". (Or explicit separate tasks like "layout UI elements" and "design icons") Then make "roughly plan user interface" a F->S pre-requisite for both "fine-tune user interface" and "implement user interface". This not only makes your schedule more accurate, but might help you plan better. For example, you might realize that the fine-tuning will be much more productive after the UI is implemented, when you can actually test drive it.
So you might change your schedule more to look like
Rough design -> Implementation -> Fine-Tuning