[CI skip] updated advanced section, jsons sub-section about the --ful…

…l option.

packages/docs/docs/docs/advanced.md

@@ -231,6 +231,6 @@ The most important thing to see here are the proxies and contracts' addresses, `
 
 Another thing to notice in these files are the version numbers. The `<appVersion>` keeps track of the latest app version, and matches `<version>` from `zos.json`. The `<proxy-i-version>`s, on the other hand, keep track of which version of the contracts the proxies are pointing to. Say you deploy a contract in your app version 1.0, and then bump the version to 1.1 and push some upgraded code for that same contract. This will be reflected in the `<contract-i-address>`, but not yet in the proxy, which will display 1.0 in `<proxy-i-version>` and the old logic contract address in `<implementation-i-address>`. Once you run `zos update` to your contract, `<proxy-i-version>` will show the new 1.1 version, and `<implementation-i-address>` will point to the new `<contract-i-address>`.
 
-Also, notice the fields `<app>` and `<package>`. These contain the addresses of contracts that ZeppelinOS uses to facilitate the creation of proxies and the management of different versions of your contracts. Unless ZeppelinOS is used in "light" mode (using the `--light` option when running the `zos init` command), it will make use of these two contracts. An `App` contains a `Package`, which keeps track of versioned `ImplementationDirectory`'s using semantic versioning. An `ImplementationDirectory` simply provides different implementations for each of your app's contracts. Note that both `<app>` and `<package>` will not exist if the ZeppelinOS is initialized in light mode. 
+Also, notice the fields `<app>` and `<package>`. These contain the addresses of contracts that ZeppelinOS uses to facilitate the creation of proxies and the management of different versions of your contracts. These contracts will only be deployed when ZeppelinOS is used in "full" mode (using the `--full` option when running the `zos init` or `zos push` commands). That is, your project will not have an app or package unless explicitely using the `--full` option. Note that this mode is required for projects that produce an EVM package. For more info on the architecture of the "full" mode, see the [Contract Architecture](https://docs.zeppelinos.org/docs/architecture.html) section.
 
 Finally, the `stdlib` field stores information about a linked standard library. Its address is stored in `<stdlib-address>`, and its name in `<stdlib-name>`, matching that in `zos.json`. The `custom-deploy` field will be present only when a version of the stdlib is deployed using the `--deploy-stdlib` flag of the `push` command, in which case `<custom-deploy>` will be `true`. The remaining addresses, `<app-address>`, `<package-address>`, and `<provider-address>` store the addresses of the `App`, the `Package`, and the current `ImplementationProvider` respectively.