fix: fix broken doc links

The URLs that were updated here were pointing to non-existent paths at
docs.garden.io.

README.md

@@ -37,13 +37,13 @@ Garden is also designed to be pluggable and modular, with Kubernetes being just
 Over time we will add native support for a variety of platforms, including AWS (Lambda, ECS, Fargate and more),
 GCP, Heroku, OpenFaaS... and the list will continue growing.
 
-Please read the [Motivation](https://docs.garden.io/introduction/motivation) section in our documentation
+Please read the [Motivation](https://docs.garden.io/home#motivation) section in our documentation
 for a brief discussion on why we're building Garden.
 
 
 ## Usage
 
-Head over to our [Getting Started guide](https://docs.garden.io/introduction/getting-started) for details
+Head over to the [Basics](https://docs.garden.io/basics) section in our documentation for details
 on how to set up and use Garden, or look through our [Simple Project](https://docs.garden.io/examples/simple-project)
 guide to get a quick sense of how it works.
 

docs/basics/README.md

@@ -2,10 +2,10 @@
 
 The following articles cover the basics of installing and using Garden:
 
-  * Installation instructions for your platform: [Installation](./basics/installation.md).
-  * A very brief guide on the main commands you should be familiar with, and an example project to test them in: [Quick Start](./basics/quick-start.md).
-  * An overview of the framework's main concepts, to help get you started using Garden with your own projects: [Concepts](./basics/concepts.md).
+  * Installation instructions for your platform: [Installation](./installation.md).
+  * A very brief guide on the main commands you should be familiar with, and an example project to test them in: [Quick Start](./quick-start.md).
+  * An overview of the framework's main concepts, to help get you started using Garden with your own projects: [Concepts](./concepts.md).
 
-If you're already familiar with the basics, feel free to move on to the next chapter: [Using Garden](./using-garden/README.md). 
+If you're already familiar with the basics, feel free to move on to the next chapter: [Using Garden](../using-garden/README.md).
 
-Or dive right in by exploring our [Guides](./guides/README.md) and [Example projects](./examples/README.md).
+Or dive right in by exploring our [configuration files](../using-garden/configuration-files.md) and [Example projects](../examples/README.md).

docs/examples/simple-project.md

@@ -307,4 +307,4 @@ module:
 
 And that's it! Our services are up and running locally, dependencies are resolved, and tests are ready to run.
 
-Check out some of our other [Example projects](./examples/README.md) for more of an in-depth look.
+Check out some of our other [Example projects](./README.md) for more of an in-depth look.

docs/home.md

@@ -1,7 +1,7 @@
 [![CircleCI](https://circleci.com/gh/garden-io/garden/tree/master.svg?style=svg&circle-token=ac1ec9984d093f91e594e5a0a03b34cec2c2a093)](https://circleci.com/gh/garden-io/garden/tree/master)
 
 
-![](docs/garden-banner-logotype-left-2.png)
+![](./garden-banner-logotype-left-2.png)
 
 *Welcome! Garden is a full-featured development framework for containers and serverless backends, designed to make
 it easy to develop and test distributed systems.*
@@ -36,7 +36,7 @@ Garden is also designed to be pluggable and modular, with Kubernetes being just
 
 ## Usage
 
-Head over to our [Quick Start guide](https://docs.garden.io/basics/getting-started/quick-start), and then look through our [Simple Project](https://docs.garden.io/examples/simple-project) guide to get a quick sense of how everything works.
+Head over to our [Quick Start guide](./basics/quick-start.md), and then look through our [Simple Project](./examples/simple-project.md) guide to get a quick sense of how everything works.
 
 For a more in-depth approach, just keep reading this documentation.
 
@@ -48,40 +48,40 @@ We welcome any and all contributions to Garden! What we're trying to achieve is
 developers have a lot of diverse needs, so we need and appreciate your input, whether it's through
 code, docs, issues, or developing plugins to better support your particular technology stack.
 
-For more detailed guidelines, see [CONTRIBUTING.md](CONTRIBUTING.md).
+For more detailed guidelines, see [CONTRIBUTING.md](../CONTRIBUTING.md).
 
 
 # Motivation
 
 The landscape of server-side development has changed immensely over the last decade.
-This has partly been driven by evolving needs — **scalability has become table-stakes for most 
+This has partly been driven by evolving needs — **scalability has become table-stakes for most
 projects and companies** — and also by the rapid development and proliferation of new technologies
 like containers.
 
-From an operations standpoint, all of this is fantastic. Scaling out is increasingly simple 
+From an operations standpoint, all of this is fantastic. Scaling out is increasingly simple
 and cost-effective, and managing production systems is easier than ever. So much so, that the
 notion of DevOps has caught on — if ops is so easy, why not have the developers do it
 themselves?
 
-And the promise of it all is great. Microservices, immutable infrastructure, continuous 
-integration and deployment, all that jazz. Trouble is, all this tends to come at the expense 
-of application developer productivity. In embracing these new technologies and tools, we've 
+And the promise of it all is great. Microservices, immutable infrastructure, continuous
+integration and deployment, all that jazz. Trouble is, all this tends to come at the expense
+of application developer productivity. In embracing these new technologies and tools, we've
 _over-optimized for ops, and in turn made it more difficult and tedious to work on the actual
 application code_.
 
 Now, rather than lament and pine for the good ol' monolith days, we at Garden feel that this can
 be addressed by **a new generation of developer tooling**. So that's what we've set out to make.
-It's certainly not a trivial task, but we truly believe that it's possible to not only reclaim the 
+It's certainly not a trivial task, but we truly believe that it's possible to not only reclaim the
 rapid feedback loops we're used to when developing individual services, but to go further and
 leverage the benefits of modern backend platforms to make development easier and faster than ever.
 
 So think of Garden as the missing layer on top of Kubernetes, AWS, GCP, etc., that focuses purely
 on the **developer experience**, makes it trivial to work across multiple platforms, and closes the
 gap between infrastructure and application development.
 
-We do this by frameworking around the basic primitives of development — building, testing, 
+We do this by frameworking around the basic primitives of development — building, testing,
 debugging and deploying — and making the _how_ of each of those pluggable and configurable.
 This allows the framework to grow with you and adapt as your needs evolve in terms of how you
 architect and run your code in production, and allows us to easily tie together all the amazing
-open-source tools that are being developed in the ecosystem, into an **integrated, consistent 
+open-source tools that are being developed in the ecosystem, into an **integrated, consistent
 and easy-to-use development framework**.

docs/reference/config-files-reference.md

@@ -1,7 +1,7 @@
 ## garden.yml reference
 
 Below is the full schema for the `garden.yml` configuration files. For an introduction,
-please look at our [configuration guide](../guides/configuration.md).
+please look at our [configuration guide](../using-garden/configuration-files.md).
 
 Note that individual module types, e.g. `container`, add additional configuration keys. The built-in module types
 are listed in the [Built-in module types](#built-in-module-types) section. Please refer to those for more details

docs/reference/glossary.md

@@ -9,12 +9,12 @@ Several named environment configurations may be defined (e.g. _dev_, _testing_,
 
 #### Module
 The basic unit of configuration in Garden. A module is defined by its
-[`garden.yml` configuration file](../guides/configuration.md#module-configuration), located in the module's top-level
+[`garden.yml` configuration file](./config-files-reference.md), located in the module's top-level
 directory,
 which
 is a subdirectory of the [project](#project) repository's top-level directory.
 
-Each module has a [plugin](#plugin) type, and may define one or more [services](#service).
+Each module has a plugin type, and may define one or more [services](#service).
 
 Essentially, a project is organized into modules at the granularity of its *build* steps. A module's build step may
 depend on one or more other modules having already been built, as specified in its `garden.yml`, in which case those modules will be built
@@ -25,16 +25,16 @@ A [module's](#module) plugin type defines its behavior when it is built, deploye
 
 #### Project
 The top-level unit of organization in Garden. A project consists of one or more [modules](#module), along with a
-project-level [`garden.yml` configuration file](../guides/configuration.md#project-configuration).
+project-level [`garden.yml` configuration file](./config-files-reference.md).
 
 Garden CLI commands are run in the context of a project, and are aware of all its modules and services.
 
 #### Provider
-An implementation of a [plugin type](#plugin) (e.g. `local-kubernetes` for the `container` plugin).
+An implementation of a plugin type (e.g. `local-kubernetes` for the `container` plugin).
 
 #### Service
 The unit of deployment in Garden. Services are defined in their parent [module](#module)'s `garden.yml`, each
-exposing [one or more ingress endpoints](../guides/configuration.md#services).
+exposing [one or more ingress endpoints](./config-files-reference.md#container).
 
 Services may depend on services defined in other modules, in which case those services will be deployed first, and
 their deployment output made available to the requiring service's deploy step.

docs/using-garden/features-and-usage.md

@@ -1,6 +1,6 @@
 # Features and Usage
 
-Now that you've had a glimpse of the basic Garden commands in the [Quick Start](./basics/quick-start.md) guide, and a brief look at the main [Concepts](../basics/concepts.md) we'll be dealing with, let's go through what some typical Garden workflows look like.
+Now that you've had a glimpse of the basic Garden commands in the [Quick Start](../basics/quick-start.md) guide, and a brief look at the main [Concepts](../basics/concepts.md) we'll be dealing with, let's go through what some typical Garden workflows look like.
 
 ## Starting a new project
 

garden-service/src/docs/templates/config.hbs

@@ -1,7 +1,7 @@
 ## garden.yml reference
 
 Below is the full schema for the `garden.yml` configuration files. For an introduction,
-please look at our [configuration guide](../guides/configuration.md).
+please look at our [configuration guide](../using-garden/configuration-files.md).
 
 Note that individual module types, e.g. `container`, add additional configuration keys. The built-in module types
 are listed in the [Built-in module types](#built-in-module-types) section. Please refer to those for more details

support/install.ps1

@@ -86,7 +86,7 @@ $ErrorActionPreference = "Stop"
 # Start here.
 Write-Host("
 Hi! This script will install the Garden CLI, after checking and installing missing dependencies.
-Please refer to our Getting Started guide at https://docs.garden.io/introduction/getting-started for details.
+Please refer to the Basics section of our documentation at https://docs.garden.io/basics for details.
 
 Please note that you may need to answer prompts during the installation.