Fixed links and a typo in dictionary.md (#810)

docs/dictionary.md

@@ -16,8 +16,8 @@ Several of these have associated type definitions, which you can find in [our ty
 - **single-package repo** - A repository which only contains a single package which is at the root of the repo
 - **multi-package repo/monorepo** - A repository which contains multiple packages, generally managed by [Bolt](https://github.com/boltpkg/bolt) or [Yarn Workspaces](https://yarnpkg.com/lang/en/docs/workspaces/).
 - **release line generators** - The `getReleaseLine` and `getDependencyReleaseLine` functions which are responsible for creating the lines inserted into changelog. A changelog entry for a particular release can be thought of as `releaseLineGenerators(changesets)`
-- **fixed packages** - Fixed packages share a semver categorisation, such that all fixed packages have the same semver version and are always published together. The logistics of this are best left to our [./fixed-packages.md] documentation.
-- **linked packages** - Linked packages share a semver categorisation, such that all published linked packages have consistent new semver ranges. The logistics of this are best left to our [./linked-packages.md] documentation.
+- **fixed packages** - Fixed packages share a semver categorisation, such that all fixed packages have the same semver version and are always published together. The logistics of this are best left to our [fixed-packages](./fixed-packages.md) documentation.
+- **linked packages** - Linked packages share a semver categorisation, such that all published linked packages have consistent new semver ranges. The logistics of this are best left to our [linked-packages](./linked-packages.md) documentation.
 - **release instruction** An object containing an intent to release a single package, consisting of the package name and a bump type
 - **release plan** - A calculated object that shows everything a collection of changesets will release, and at what version, and how. This object includes a calculation of dependencies, and considerations for `linked` packages.
 - **absolutely correct semver** - making semver versioning decisions to ensure nothing less than major is capable of breaking a consumer's code. Because literally any change is technically capable of breaking a user's code, absolutely correct semver requires that all changes are major changes.
@@ -27,7 +27,7 @@ Several of these have associated type definitions, which you can find in [our ty
 - **release** - The combination of versioning and publishing a package or packages which may include a build process before publishing
 - **prereleases** - A pre-release is a release that uses a tag, and is not published as `latest` on npm. This is designed for when you want to share code, but are not yet ready for it to be the main package used by everyone. Pre-releases for packages are common, but pre-releases within a monorepo presents unique problems. You can see our exhaustive pre-release documentation [in our prereleases documentation](./prereleases.md). In addition, there are two different approaches to pre-releases which are defined for use separately.
 - **Release Candidate (RC) prerelease** - An RC prerelease is done before an intended important release, likely a major release. It includes semver information about what the next intended release version is, a tag, and an iterated number for the prerelease. The output of this is intended to be committed, and then further work done on the branch. An example would be if I am on `1.0.0` of a package, and I want to do an RC for the next `major` version we would have: `package-one@2.0.0-my-tag.0`, and then the next publish is `package-one@2.0.0-my-tag.1`.
-- **snapshot prerelease** - A snapshot pre-release is intended to make it easy to test all changes at a particular git commit. It is published at `0.0.0` and uses the git hash as the tag. This should be used as a less formal method than a release candidate to make it easy to install and test changes. An example, if we have a package at `1.0.0`, and have a changeset for it to be `major` bumpred, a snapshot release will be at `0.0.0-ABCDEFGH` (the last github hash). If we add more commits, the next snapshot would be `0.0.0-HIJKLMNOP`.
+- **snapshot prerelease** - A snapshot pre-release is intended to make it easy to test all changes at a particular git commit. It is published at `0.0.0` and uses the git hash as the tag. This should be used as a less formal method than a release candidate to make it easy to install and test changes. An example, if we have a package at `1.0.0`, and have a changeset for it to be `major` bumped, a snapshot release will be at `0.0.0-ABCDEFGH` (the last github hash). If we add more commits, the next snapshot would be `0.0.0-HIJKLMNOP`.
 
 ## Things that we haven't figured out how to explain well yet