upd docs

docs/user/03-services-and-dependencies.md

@@ -39,6 +39,13 @@ When you need to do some more complex logic to create a service instance, or
 when you want to provide other service configuration such as a scope or one or
 more service hooks, you can export a _service definition_ from a resource file.
 
+> An explicit service definition overrides a simple class or interface export of
+> the same type, so you can simply `export * from '../services'` at the start of
+> a resource file, and then follow that with explicit definitions for services
+> which need some tweaks - such services won't be registered twice. If you do
+> need to register a given service multiple times, you must provide explicit
+> definitions for each registration.
+
 As briefly mentioned before, a service definition is a special `satisfies`
 expression. This is what it looks like:
 

docs/user/04-config-and-compilation.md

@@ -45,9 +45,20 @@ resources:
 
 Whenever you change service definitions you must re-run the compiler in order
 to get a matching container. This is done using the `dicc` executable shipped
-with DICC. The executable takes a single optional argument, which is the path
-to the DICC config file; by default, it is assumed to be `dicc.yaml` in the
-current working directory.
+with DICC. The executable has the following options:
+
+```
+dicc [-v|--verbose] [-c <file>|--config <file>]
+
+ -v, --verbose
+   Toggle verbose output. Can be specified multiple times to make output even
+   more verbose.
+ -c <file>, --config <file>
+   Load the specified config file, instead of looking for one of the default
+   config files. Config files are always resolved from the current working
+   directory; the default files are 'dicc.yaml', 'dicc.yml', '.dicc.yaml', and
+   '.dicc.yml', in this order.
+```
 
 The compiled container should be a deterministic product of your definitions,
 so you can safely exclude it from version control. But versioning it probably