diff --git a/Design:-Runnable-Project.md b/Design:-Runnable-Project.md
index ddd11ec..a3e6f28 100644
--- a/Design:-Runnable-Project.md
+++ b/Design:-Runnable-Project.md
@@ -1,4 +1,4 @@
-**Note:** Added a branch `runnable-project` to experiment - https://github.com/node-red/node-red/tree/runnable-project
+**Note:** Added a branch `runnable-project` to experiment - https://github.com/node-red/node-red/tree/runnable-project. Currently works as described below... but maybe not final design choices.
 
 One of the goals of the Projects feature is to treat a project as a deployable artefact.
 
@@ -19,6 +19,8 @@ We can't quite do this today. Here are the missing pieces:
 > DCJ: Yes - agree it should be a dependency. Currently not hard to add manually, but could be even easier. It would be a prerequisite dependency for inside a Docker container. 
 
 >DCJ: Added a button to dependencies panel to add node-red core - As it's not "known" it shows as greyed in the list- but I actually think this is good, as it indicates it may not be required also.
+
+>NOL: Not sure a standalone button passes the "why is it there?" test.
 2. it must be possible to point node-red at a project on start-up, without using the editor to do so. Currently we overload the flowFile argument to set the active project - but that only works if the project is 'known'. It would be better to point at a `projectDir` wherever it may exist.
 > DCJ: Are we pointing Node-RED or npm start ? Which are we calling to run it ? If npm start then don't we already have to be in the correct project directory ? (or use npm start --prefix projectDir)
 
@@ -28,6 +30,7 @@ We can't quite do this today. Here are the missing pieces:
       - [DCJ] easy to add to settings.js - `credentialSecret: process.env.NODE_RED_CREDENTIAL_SECRET` and would suit Docker style deploy.
     - command-line flag - `--credentialSecret="..."`
       - [DCJ] added as new command line option to runnable-project dev branch
+>DCJ/NOL: a) If environment variable works do we need command line option ? When would you use it? b) should using env var be baked into core or just via settings file so can be removed if required.
 
 4. Must handle running in a read-only environment. If the package is installed globally (in order to insert a command link into /usr/bin) then the flow file and settings.js will be in root space - which ought not to be writable by the user. Currently even starting Node-RED with -u option pointing somewhere protected will fail. Options include 
     - just handling the error - i.e. log something (useful) - but fail to start.
@@ -37,9 +40,11 @@ We can't quite do this today. Here are the missing pieces:
 The package would provide an npm start script that runs node-red with the appropriate command-line args.
 > DCJ: currently just using `node-red -u . flow.json` - i.e. start Node-RED using the current directory as the base and the current flow file.
 
+>NOL: instead should it use (say) a -p option to specify a package.json file to use instead to read the extra settings from (like flow file etc)
+
 It could also provide a `bin` section that could allow starting via command line if installed globally - but that requires a command to be run (that doesn't take parameters) so in order to do that we would also need to create that script/.js file or provide a template.
 
-> DCJ: Actually by pre-req node-red it automatically adds the node-red command to the node_modules/.bin so the package.json start script can just call node-red and all is good.
+> DCJ: Actually by pre-req node-red it automatically adds the node-red command to the node_modules/.bin so the package.json start script can just call `node-red` and all is good.
 
 ### Runtime settings