README.md in teapot-1.0.0.pre.rc9 vs README.md in teapot-1.0.0.pre.rc10

@@ -7,10 +7,11 @@
 - Generators can simplify the construction of new projects as well as assist with the development of existing ones.
 - The build subsystem provides a simple set of canonical operations for building libraries and executables to minimise configuration overhead.
 
 [![Build Status](https://secure.travis-ci.org/ioquatix/teapot.png)](http://travis-ci.org/ioquatix/teapot)
 [![Code Climate](https://codeclimate.com/github/ioquatix/teapot.png)](https://codeclimate.com/github/ioquatix/teapot)
+[![Coverage Status](https://coveralls.io/repos/ioquatix/teapot/badge.svg)](https://coveralls.io/r/ioquatix/teapot)
 
 ## Installation
 
 Ensure that you already have a working install of Ruby 1.9.3+
 
@@ -31,11 +32,11 @@
 
 	$ teapot list
 
 To build your project:
 
-	$ teapot build Application/MyProject variant-debug
+	$ teapot build Application/MyProject
 
 When you build, you need to specify dependencies. If you haven't specified all dependencies, they will be suggested to you.
 
 The resulting libraries will be framework dependent, but are typically located in
 
@@ -61,9 +62,10 @@
 ## Open Issues
 
 - Should packages be built into a shared prefix or should they be built into unique prefixes and joined together either via install or `-L` and `-I`?
 	- Relative include paths might fail to work correctly if headers are not installed into same directory.
 - Should packages expose the tools required to build themselves as dependencies? e.g. should `build-cmake` as required by, say, `OpenCV`, be exposed to all who depend on `OpenCV`? Should there be a mechanism for non-public dependencies, i.e. dependencies which are not exposed to dependants?
+- Should packages have some way to expose system requirements, e.g. installed compiler, libraries, etc. Perhaps some kind of `Package#valid?` which allows custom logic?
 
 ## Contributing
 
 1. Fork it
 2. Create your feature branch (`git checkout -b my-new-feature`)