Relocated inline images

Updated links to primer

Signed-off-by: Terry Cox <terry@bootstrap.je>

.github/pull_request_template.md

@@ -8,7 +8,7 @@
 
 As the author of this PR, please check off the items in this checklist:
 
-- [ ] Has the [primer doc](https://github.com/cdevents/spec/blob/main/primer.md) been updated if a design decision is involved
+- [ ] Has the [primer doc](https://github.com/cdevents/spec/blob/main/primer/_index.md) been updated if a design decision is involved
 - [ ] Have the [JSON schemas](https://github.com/tektoncd/community/blob/main/standards.md#tests) been updated if the specification changed
-- [ ] Has spec version and event versions been updated according to the [versioning policy](https://github.com/cdevents/spec/blob/main/primer.md#versioning)
+- [ ] Has spec version and event versions been updated according to the [versioning policy](https://github.com/cdevents/spec/blob/main/primer/_index.md#versioning)
 - [ ] Meets the [CDEvents contributor standards](https://github.com/cdevents/.github/blob/main/docs/CONTRIBUTING.md)

README.md

@@ -43,7 +43,7 @@ The latest release of the specification on is
 continuously follow the latest updates of the specification on [the `main`
 branch](./spec.md).
 
-The concepts and ideas that have formed the current specification are outlined in the [CDEvents Primer](./primer.md).
+The concepts and ideas that have formed the current specification are outlined in the [CDEvents Primer](./primer/_index.md).
 ## CDEvents SDKs
 
 CDEvents is developing as set of SDKs:

primer.md → primer/_index.md

@@ -316,7 +316,7 @@ limitation can be worked-around by adding the missing data in the tool output.
 This solution may be brittle, because the tool output may not be a stable
 interface for the tool, and it may change over time without notice.
 
-![watcher-producer](images/watcher-producer.svg)
+![watcher-producer](watcher-producer.svg)
 
 This approach is certainly valid to build a proof-of-concept or to experiment
 with events in an existing environment.
@@ -330,7 +330,7 @@ tool itself and the process of generating events.
 If a tool does produce events, it may be possible to use an external adapter
 component to convert the existing events into CDEvents.
 
-![adapter](images/adapter.svg)
+![adapter](adapter.svg)
 
 Similar to the [previous case](#external-event-producer), incoming events may be
 missing data required by CDEvents. If the events come from a tool that we do not
@@ -347,7 +347,7 @@ solved on the producer side by sending both format of events in parallel.
 In some cases it may be possible to use a single broker for both event types,
 for instance if both formats are CloudEvents based.
 
-![multiple-produced](images/multiple-produced.svg)
+![multiple-produced](multiple-produced.svg)
 
 ### Consumer-side architectures
 
@@ -362,7 +362,7 @@ produces only one format of events, which is sent to the broker. The adapter
 subscribes to the events, converts them and publishes them back to the broker.
 Consumer may then subscribe to the type of events that they prefer.
 
-![original-adapter](images/original-adapter.svg)
+![original-adapter](original-adapter.svg)
 
 With this architecture, the adapter may even be able to convert messages from
 different tools, instead of just one.
@@ -375,15 +375,15 @@ An adapter can be used to convert a CDEvent into the consumer specific format or
 to extract data from a CDEvent and use it to invoke an API for the receiving
 side.
 
-![consumer-adapter](images/consumer-adapter.svg)
+![consumer-adapter](consumer-adapter.svg)
 
 #### Multiple event formats consumed
 
 In this scenario, a new tool is added that produces CDEvents. An existing
 consumer wants to benefit from existing events as well as the events from the
 new tool.
 
-![multiple-received](images/multiple-received.svg)
+![multiple-received](multiple-received.svg)
 
 A single consumer may receive events from heterogenous sources.
 

roadmap.md

@@ -20,11 +20,11 @@ The continuous delivery ecosystem is quite large as it includes tools and servic
 from the design of software, through its implementation, build, test, release, deployment and
 operation.
 
-In 2022 we want to focus on a few [key use cases](primer.md#use-cases) and make sure that we can fully support
+In 2022 we want to focus on a few [key use cases](./primer/_index.md#use-cases) and make sure that we can fully support
 them with the protocol specification. More specifically:
 
-- Capture our key use cases and design decisions in the [CDEvents primer](primer.md) document
-- Develop the spec to fully support our [key use cases](primer.md#use-cases)
+- Capture our key use cases and design decisions in the [CDEvents primer](./primer/_index.md) document
+- Develop the spec to fully support our [key use cases](./primer/_index.md#use-cases)
   - Create our first [release v0.1](https://github.com/orgs/cdevents/projects/1)
   - Define the specification versioning and stability policy
   - Define our requirements for a v1.0

spec.md

@@ -80,7 +80,7 @@ The specification is structured in two main parts:
   dedicated document in the spec.
 
 For an introduction see the [CDEvents README](README.md) and for more background
-information please see our [CDEvents primer](primer.md).
+information please see our [CDEvents primer](/docs/primer).
 
 ## Notations and Terminology
 
@@ -190,7 +190,7 @@ defined in the [vocabulary](#vocabulary):
   All event types should be prefixed with `dev.cdevents.`. One occurrence may
   have multiple events associated, as long as they have different event types.
   *Versions* are semantic in the *major.minor.patch* format.  For more details about versions
-  see the the see [versioning](primer.md#versioning) documentation.
+  see the the see [versioning](/docs/primer#versioning) documentation.
 
 - Constraints:
   - REQUIRED
@@ -211,7 +211,7 @@ defined in the [vocabulary](#vocabulary):
   to the same application.
 
   When selecting the format for the source, it may be useful to think about how
-  clients may use it. Using the [root use cases](./primer.md#use-cases) as
+  clients may use it. Using the [root use cases](/docs/primer#use-cases) as
   reference:
 
   - A client may want to react only to events sent by a specific service, like
@@ -256,7 +256,7 @@ defined in the [vocabulary](#vocabulary):
 - Description: The version of the CDEvents specification which the event
   uses. This enables the interpretation of the context. Compliant event
   producers MUST use a value of `0.1.1` when referring to this version of the
-  specification. For more details see [versioning](primer.md#versioning).
+  specification. For more details see [versioning](/docs/primer#versioning).
 
 - Constraints:
   - REQUIRED