Update VISION

.vscode/spell.json

@@ -0,0 +1,29 @@
+{
+  "language": "en",
+  "ignoreWordsList": [
+    "GitHub",
+    "GitLab"
+  ],
+  "mistakeTypeToStatus": {
+    "Passive voice": "Hint",
+    "Spelling": "Error",
+    "Complex Expression": "Disable",
+    "Hidden Verbs": "Information",
+    "Hyphen Required": "Disable",
+    "Redundant Expression": "Disable",
+    "Did you mean...": "Disable",
+    "Repeated Word": "Warning",
+    "Missing apostrophe": "Warning",
+    "Cliches": "Disable",
+    "Missing Word": "Disable",
+    "Make I uppercase": "Warning"
+  },
+  "languageIDs": [
+    "markdown",
+    "plaintext"
+  ],
+  "ignoreRegExp": [
+    "/\\(.*\\.(jpg|jpeg|png|md|gif|JPG|JPEG|PNG|MD|GIF)\\)/g",
+    "/((http|https|ftp|git)\\S*)/g"
+  ]
+}

VISION.md

@@ -4,19 +4,22 @@ A year in, [Danger](https://github.com/danger/danger) is doing just fine. See th
 
 The amount of issues we get in comparison to the number of downloads on Rubygems makes me feel pretty confident about her state of production quality and maturity. I wanted to start thinking about the larger patterns in software. At Artsy, we are starting to use JavaScript in many, many places.
 
-I've explored [running JavaScript](https://github.com/danger/danger/pull/423) from the ruby Danger, ([example](https://github.com/artsy/emission/blob/d58b3d57bf41100e3cce3c2c1b1c4d6c19581a68/Dangerfile.js)) but this pattern isn't going to work on the larger scale: You cannot use npm modules, nor work with babel to transpile your `Dangerfile.js`. That isn't going to work.
+I've explored [running JavaScript](https://github.com/danger/danger/pull/423) from the ruby Danger, ([example](https://github.com/artsy/emission/blob/d58b3d57bf41100e3cce3c2c1b1c4d6c19581a68/Dangerfile.js)) but this pattern isn't going to work on the larger scale: You cannot use npm modules, nor work with babel to transpile your `Dangerfile.js` and the requirements on the project to [include are too high](https://github.com/artsy/emission/pull/233). That isn't going to work.
 
-This comes at the same time as thinking about a hosted version of Danger. This time around we can limit the exposed API to only something that can be obtained over the API on a hosted server. 
+This comes at the same time as thinking about a hosted version of Danger. With the NPM version we can limit the exposed API to only something that can be obtained over the API on a hosted server. By doing this, a hosted Danger does not need to clone and run the associated projects. This is essential for my sanity. I cannot run multiple [servers like CocoaDocs](http://cocoadocs.org). So far, I'm calling this Peril. 
 
-One technique for doing this is to lazy load information required, e.g. by default only get the PR metadata, and file changed. 
+I _do not_ know how to deal with babel-y compilation stuff, or danger plugins to work in Peril. Figure I'll know more about the systems as I get there.  
+
+One technique for doing this is to lazy load information required, e.g. by default only get the PR metadata, and file changed. I think memoized get functions in ES6 will be useful there. 
 
 ### So, initial vision?
 
 * As few dependencies as possible
 * Feel native to JS
-* Provide Flow/TypeScript types for Danger objects
-* Be API agnostic from day one
-* If an exposed API can't be done via the APIs, it can't be done for that platform
+* Provide Flow/TypeScript types for Danger API
+* Be platform API agnostic from day one
+* If an exposed end-user API can't be done via the platform APIs, it can't be done for that platform
+  E.g. if GitLab had an API not available on GitHub, then for GitHub we cannot do that same thing. Platform APIs dictates the end-user experience.
 * Re-use abstractions from the Gem when possible, it took a long time to get those
 * Re-use CI source detection from Ruby Danger