Deduplicate data we save to the files, tweak formatting

docs/decisions/007_getting_and_storing_logs.md

@@ -37,7 +37,7 @@ Use fs.appendFileSync with node's `util.inspect`. In future, we might explore ca
 
 ### Listen for write to `stdout`
 
-We'd listen for `stdout` and `stderr` events. We haven't yet experimented with detecting which logs are cucumber's and storing only those.
+We'd listen for `stdout` and `stderr` events. We haven't yet experimented with detecting which logs are cucumber's and storing only those. See pseudo code in the supplementary material section.
 
 **Pros:**
 
@@ -157,4 +157,23 @@ log.with_flush( run );
 
 `Log` would handle creating the promises. `log.with_flush()` would handle the try/catch logic to wait for the listeners and close the streams.
 
+### Listen for write to `stdout`
+
+For capturing console output, look into how to get the `stdin` for capturing various console output. https://stackoverflow.com/a/54202970:
+
+```js
+const stdin = process.openStdin()
+
+process.stdout.write('Enter name: ')
+
+stdin.addListener('data', text => {
+  const name = text.toString().trim()
+  console.log('Your name is: ' + name)
+
+  stdin.pause() // stop reading
+})
+```
+
+We couldn't figure out how to handle decoding emoji.
+
 [^3]: I'm not sure of good names to differentiate the code in run_cucumber.js, which triggers the rest of the test running, but is separate from it, and the code that handles the nitty gritty - like index.js, steps.js, scope.js, etc. "Running cucumber" is ambiguous. I'm calling run_cucumber.js code the "cucumber runner" and I'm calling the code that handles the actual tests the "tests handler".

docs/decisions/008_keep_setup_run_takedown_separate.md

@@ -0,0 +1,31 @@
+# Keep setup run takedown separate
+
+## Context and Problem Statement
+
+We have multiple environments in which ALKiln runs. Some need to always install the author's package code, others only need to install the code sometimes, some don't install the code at all. How often do different kinds of environments use the setup, install, and takedown commands?
+
+**Always:** GitHub actions always need to install the package onto a server. There are two kinds of ways to run ALKiln in GitHub hidden under this umbrella. Both ways copy the current branch's code and then install the package on a server (setup).
+
+Option 1: One action installs the package on the server itself (a temporary docassemble server hosted on GitHub).
+
+Option 2: The other installs in an individual author's account (their Playground) on the docassemble server[^1].
+
+Then our GitHub action runs the tests using that installed package (run). When the test suite is done, the GitHub action either destroys the temporary server (option 1) or just deletes the package from the author's server (takedown).
+
+**Sometimes:** Internal developers of ALKiln install the feature branch they're working on onto a server with `setup` (install). They run tests multiple times using that installed package with `run_cucumber` (many runs). When they're done with their feature, they delete the project from the server with `takedown`. The server might be local or might be remote.
+
+**Never:** ALKilnInThePlayground is a package an author can install on their own servers. It is a form the author can use to run ALKiln test on the server as they develop their package[^1]. It gives them a faster iteration cycle. Since it is on their server, it has access to information about the author's account and the packages they have installed on their account. They control creating and deleting the package they want to test. Since they run the ALKiln tests for a package that they've already installed on their server (run), ALKilnInThePlayground doesn't need the setup or takedown steps.
+
+[^1]: A docassemble server can have multiple purposes. One is to contain the packages for online forms which end users then use. Those packages are stored in a special place on the server and admins configure the server to give end users a list of those forms. Another purpose of the docassemble server is to be a development environment in which to create the forms. An author/developer of the forms has a developer account on the server. That account can store multiple packages and versions of packages. It also has an IDE that authors can use to work on those packages. They can push those files to GitHub from that IDE. They can also pull those packages from GitHub using that IDE.
+
+
+## Considered Options
+
+- ALKiln could have one script to contain all setup, run, and takedown functionality.
+- Internal devs can manually install packages onto servers (local or remote) in whatever way they want using the command prompt to handle setup and takedown separately from running.
+- ALKiln could have individual scripts for setup, run, and takedown. GitHub actions would use all three.
+
+## Decision Outcome
+
+
+