docs: [FUN-449] Add what is it for doc (#507)

* Add what is it for doc

* remove crazy bit

* rename and re-draft doc

* i hate linters

* Update internal/dev_server/manifesto.md

Co-authored-by: Mike Zorn <[email protected]>

* Update internal/dev_server/manifesto.md

Co-authored-by: Mike Zorn <[email protected]>

* minor edit

---------

Co-authored-by: Mike Zorn <[email protected]>

Author: tvarney13

internal/dev_server/README.md

@@ -1,4 +1,4 @@
 # dev server
-The dev server is a go server that ldcli can run. It provides a local-only version of all the APIs that support LaunchDarkly SDKs. You can use it to serve flags to local and ephemeral environments. It copies flag _values_ for a project from a source environment and serves those. There are also APIs that let you override those values so that you can enable a feature just in your dev environment, e.g.
+The dev server is a go server that ldcli can run. It provides a local-only version of all the APIs that support LaunchDarkly SDKs. You can use it to serve flags to local and ephemeral environments. It copies flag _values_ for a project from a source environment and serves those. There are also APIs that let you override those values so that you can enable a feature just in your dev environment.
 
 The build of the dev server is incorporated into the ldcli build itself. The UI provided by the dev server has a [manual build](./ui/README.md).

internal/dev_server/manifesto.md

@@ -0,0 +1,15 @@
+# Dev Server Vision Doc
+
+This doc lays out our vision for what `dev-server` is supposed to do, and why this is the case.
+
+## Purpose of the Dev Server
+
+First and foremost, `dev-server` is meant as a replacement for local dev and CI environments managed in the LaunchDarkly service. Other use cases may exist (and don't hesitate to ask if you think you have one!), but since a `dev-server` environment lacks any targeting, it is best suited to situations where there is only 1 user for the whole environment.
+
+We implemented it this way in order to solve a problem common both internally and amongst our userbase where an environment would get created per developer on a project as well as per CI build. As you could expect, this becomes exponentially harder to maintain as the number of environments scales both technically and from a process perspective - something has to clear out those environments after all!
+
+Another intentional restriction is that flags must first exist in the source environment. We chose to do this in order to minimize any surprises as your code moves from local / CI to a prod / prod-like environment. In our experience, the greatest source of such surprises has been drift between the configuration of a developer's LD environment and our Staging environment. Unless a developer is constantly making sure their flag state matches higher environments as closely as possible, flag state drifts until their local development environment starts to break, neccessitating a painful process of reconciling flag state.
+
+Lastly, do not use the `dev-server` for environments with prod-level traffic. As we designed this with local dev in mind, production throughput has never been tested.
+
+With that said, it's our hope that you enjoy using the `dev-server`, and feedback is more than welcome!