Fiddler2 and web-traffic debugging go hand in hand especially since Fiddler2 can decrypt HTTPS traffic (most of UCWA). Fiddler2 by default will attempt to read all web traffic from all processes which can be a bit overwhelming and unnecessary. It is possible to limit it by choosing Web Browsers in the lower right as seen below:
Once the correct filtering is in place it is easy to capture network traffic and capturing can be started/stopped by pressing F-12. Once the network traffic has been capture it is possible to save the session data for later debugging or sharing with other users. A sample Fiddler2 Archive (.saz) can be loaded up a viewed by selecting a specific call and browsing headers, JSON, raw for both requests and responses. It is a good idea to filter out requests from any saved archive that contain sensitive information such as usernames and passwords. The simple route is to directly delete that web request from the archive prior to saving. Subsequent requests with OAuth Tokens (Authorization Headers) can still be considered somewhat sensitive, but the lifetime of an OAuth Token is ~8 hours.
Hosting Fiddler2 Traces
I'm not sure I have a great answer to this question, but temporarily Dropbox is sufficient. I know there are many hosting options available and don't really care want to invest the time arguing for one over another. The point of hosting these traces online is to prevent posting walls of text when asking a question when possible. Also as the complexity of a UCWA application increases it becomes more important to capture network traffic in order to understand what occurred when the first sign(s) trouble manifested.
Update to CU1 Already...
If you have not upgraded to CU1 I'm not sure how you intended to develop with UCWA. Also take the time to run the bootstrapper in the Lync Server Management Shell.
Issue #1: Service does not allow a cross domain request from this origin.
The hosting location needs to be added to the Lync Server's white-list as described in ITAdmin-Configuration. As stated in the article it is imperative that the domain matches the expected domain and as such http://localhost:1234 != http://localhost. After your specified hosting location has been added to the white-list it can be checked by using a simple Fiddler2 trace with minor modifications. Open the Fiddler2 trace and drag the second request (403 response) into the Composer tab as this will copy that requests data. At this point you will want to change the request to point to your specific Lync Server (https://lyncdiscover.mydomain.com/) and change Request Headers value of X-Ms-Origin to the correct hosting domain (be sure to include port number!):
Issue the request after making the modifications and check the Response to see if it resulted in a 200 (OK) or 403 with an X-Ms-dianostics header. If you receive another 403 you should verify in the hosting environment (IIS, Apache, etc) and check the port against what is stored in the white-list (Get-CsWebServiceConfiguration | select CrossDomainAuthorizationList).
As more issues arise I will attempt to highlight debugging solutions and continue providing suggestions and information on the UCWA Forum. I will also provide more Fiddler2 traces when they are relevant to the issue/debugging.