docs: extend contribution guide

ARCHITECTURE.md

@@ -0,0 +1,73 @@
+# Architecture
+
+This codebase is set up as a [Cargo workspace](https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html). The `rover` binary is built from the root `bin` target, which is a thin wrapper around the `rover-client` library crate.
+
+## CLI Design
+
+Great thought and attention has been paid to Rover's design, and any new command surface must be considered holistically.
+
+### Command layout
+
+Rover commands are laid out as `rover [NOUN] [VERB]` to create clear separation of concerns for multiple areas of graph management.
+
+### Designing new commands
+
+Generally, we are hesitant to add a new `NOUN` to Rover's surface area, unless there is a clear and real need. 
+
+An example of a clear need is the `graph` vs. `subgraph` vs. `supergraph` command structure. Each of these nouns has similar associated verbs. 
+
+Let's look at the `fetch` commands as an example. `rover graph fetch` and `rover subgraph fetch` each take a positional required `<GRAPH_REF>` argument, and `subgraph fetch` also has a required `--subgraph` flag. It really looks like there doesn't need to be differentiation between these commands. We could have made this behavior implicit by making `--subgraph` optional, and only returning a subgraph schema if the `--subgraph` argument was provided. 
+
+The problem with this approach is that having two different return types from the same command leads to unexpected results and makes it difficult to understand the mental model needed to work with the graph registry. Additionally, it would have made it difficult to design commands that _only_ exist for `subgraphs`, and vice versa (such as `rover subgraph check`).
+
+In general, it is best to keep related commands together, and to avoid cognitive complexity wherever possible. New commands should either be associated with an existing top-level noun, or a new noun should be proposed.
+
+### Error Handling
+
+
+
+### Project Structure
+
+- `Cargo.toml`: crate metadata, including definitions for both internal and external dependencies
+
+- `Cargo.lock`: an autogenerated lockfile for Rover's dependencies
+
+- `src`: the `rover` CLI
+    - `src/bin/rover.rs`: the entry point for the CLI executable
+    - `src/command`: logic for the CLI commands
+      - `src/command/output.rs`: Enum containing all possible `stdout` options for Rover commands
+      - `src/command/{command_name}/mod.rs`: Contains the definition of Rov
+    - `src/utils`: shared utility functions
+    - `src/error`: application-level error handling including suggestions and error codes
+    - `src/cli.rs`: Module containing definition for all top-level commands
+    - `src/lib.rs`: all the logic used by the CLI
+
+- `tests`: Integration tests
+
+- `crates`
+    - `crates/houston`: logic related to configuring rover
+    - `crates/robot-panic`: Fork of `human-panic` to create panic handlers that allows users to submit crash reports as GitHub issues
+    - `crates/rover-client`: logic for querying apollo services
+    - `crates/sputnik`: logic for capturing anonymous usage data
+    - `crates/timber`: output formatting and logging logic
+    - `crates/xtask`: logic for building and testing Rover
+
+- `.cargo`: Sets up `cargo xtask` commands in the workspace
+
+- `docs`
+    - `source/*.md`: Individual documentation pages
+    - `source/assets`: Images and other resources
+    - `static/_redirects`: [Netlify redirects](https://docs.netlify.com/routing/redirects/)
+
+- `netlify.toml`: Configuration for Rover's [docs](https://apollographql.com/docs/rover)
+
+- `installers`
+    - `binstall`: Rover's cross-platform installer that downloads and installs prebuilt binaries
+    - `npm`: Rover's npm installer that downloads and installs prebuilt binaries
+
+- `.github`
+    - `ISSUE_TEMPLATE`: Issues templates for our GitHub repository
+    - `workflows/lint.yml`: GitHub Action that checks for idiomatic code style, proper formatting, and broken markdown links
+    - `workflows/release.yml`: GitHub Action that builds cross-platform binaries and creates a GitHub release when a version is tagged
+    - `workflows/test.yml`: Runs integration and unit tests on each commit that is pushed to GitHub
+