In this particular case, the Deliver operation is adding a new component to the stream.  When you do that, RTC does not check all of the change sets in the component as part of the deliver.  It just adds the component to the stream with the same contents as what is in your repository workspace.  Though the behavior is wrong in this case, it makes sense in many other cases.  Normally when you add a component to a stream, the component has been around for a long time and already has lots of stuff in it.  You wouldn't want RTC to run the preconditions on the thousands of change sets that are already in the component, because there is nothing you can do to fix them if they fail the precondition.  I don't see an easy way for RTC to distinguish the change sets that were newly created in your workspace (that you do want to be checked) from the change sets that were already in the component when you added it to your workspace (that you don't want to be checked).

If you want the preconditions to be run on your change set, then you should modify your steps slightly.  Rather than creating a new component as part of sharing your project, create an empty component first.  Add the component to both your workspace and the stream.  Then choose the component as the place to put your project when you share the project.  If you do that, the deliver operation will be a normal delivery of change sets, not the addition of a new component.

I don't know if a work item already exists for this.  If you can't find one, I suggest creating one.  I don't know that it will ever get fixed, but the behavior does seem odd enough that it is at least worth discussing.

-- David Olsen, IBM Rational, Jazz Process Team