chore: corrections and edits while reviewing docs

docs-src/architecture/pinning.md

@@ -56,7 +56,7 @@ Based on the semantics, it makes sense to have:
 3. pinning backends aggregator - responsible for pinning commits using multiple pinning backends simultaneously,
 4. pin store aggregator - responsible for storing state and pinning dependent commits.
 
-![Pinning Design](media://pinning-design.png)
+![Pinning Design](../media/pinning-design.png)
 
 Legend:
 - filled arrow - call,
@@ -96,6 +96,6 @@ For CLI defined in `ceramic-cli` package, we add additional `--pinning` option.
 
 For example, this would start ceramic daemon with three backends. One is on Powergate, that is Filecoin, another is on operational IPFS node used by Ceramic node, and the third one uses additional IPFS node, for redundancy.
 
-```
-$ ceramic daemon --pinning "powergate+http://localhost:6002?token=940a1a4d-ce97-459d-996e-461209e9c863" --pinning "ipfs://__context" --pinning "ipfs+https://remote.cloud.com:5006"
+```sh
+ceramic daemon --pinning "powergate+http://localhost:6002?token=940a1a4d-ce97-459d-996e-461209e9c863" --pinning "ipfs://__context" --pinning "ipfs+https://remote.cloud.com:5006"
 ```  

docs-src/architecture/state-management.md

@@ -46,13 +46,13 @@ So, at any time, we are sure we start subscription with the latest available sta
 
 ### Stream and State
 
-As part of state refactor effort we have decided to maintain a certain semantics for how Stream updates state. After created, Stream maintains just the state it was initialized with. It only updates state after being manually changed or when subscribed. In the latter case, the state gets continuously updated. If looked from the inside, one could notice a Stream relies on `RunningStateLike` instance to maintain the state. One could see `RunningStateLike` as either an [Observable](https://rxjs.dev/guide/observable) of DocState with an access to the current value, or as [BehaviorSubject](https://rxjs.dev/guide/subject#behaviorsubject) with some additional getters. The reason for this, is we want to avoid explicit memory management in Stream instances. Anyway `RunningStateLike` is a kind of [Subject](https://rxjs.dev/guide/subject), that has to be explicitly closed, and as one could see from sections above managing document state life cycle is complicated. Ceramic instance performs that closing behavior when the CeramicAPI instance itself is closed, and that frees a developer from closing every Stream manually. However, the more open and subscribed Stream instances there, the more memory is used, as having lots of subscribed Stream instances can cause the in-memory cache to grow behind the configured max cache size.
+As part of state refactor effort we have decided to maintain certain semantics for how Stream updates state. After creation, Stream maintains just the state it was initialized with. It only updates state after being manually changed or when subscribed. In the latter case, the state gets continuously updated. If looked at from the inside, one could notice a Stream relies on a `RunningStateLike` instance to maintain the state. One could see `RunningStateLike` as either an [Observable](https://rxjs.dev/guide/observable) of DocState with an access to the current value, or as [BehaviorSubject](https://rxjs.dev/guide/subject#behaviorsubject) with some additional getters. The reason for this, is we want to avoid explicit memory management in Stream instances. Anyway, `RunningStateLike` is a kind of [Subject](https://rxjs.dev/guide/subject), that has to be explicitly closed, and as one could see from sections above managing document state life cycle is complicated. Ceramic instance performs that closing behavior when the CeramicAPI instance itself is closed, and that frees a developer from closing every Stream manually. However, the more open and subscribed Stream instances there, the more memory is used, as having lots of subscribed Stream instances can cause the in-memory cache to grow beyond the configured max cache size.
 
 ![Relationship between doctype and state](../media/state-management/doctype-and-state.png)
 
 ## Components
 
-The main concept behind component structure is running document. Let's call a *running document* (or _running state_) an entity that has its state in memory, as opposed to *sleeping document* that is stored in a persistent storage. We want to make sure that there is always at max one instance of document running. We want to provide same access pattern for a document be it running or sleeping, or even if it is to be loaded from network.
+The main concept behind component structure is a "running document". Let's call a *running document* (or _running state_) an entity that has its state in memory, as opposed to a *sleeping document* that is stored in a persistent storage. We want to make sure that there is always at max one instance of a document running. We want to provide same access pattern for a document be it running or sleeping, or even if it is to be loaded from network.
 
 ### RunningState
 

docs-src/guides/create-doctype.md

@@ -19,14 +19,13 @@ One interface worth noting is the `CeramicAPI` interface which lets the develope
 
 # Stream
 
-The [[Stream]] interface extends the `EventEmitter` interface which means that the developer can subscribe to events emitted from the Ceramic node like the `change` event (*more events will be defined in the future*).
+The [Stream](../../packages/common/src/stream.ts) interface extends the [Observable](https://rxjs.dev/guide/observable) interface which means that the developer can subscribe to events emitted from the Ceramic node (*more events will be defined in the future*).
 
-The method `change` is more or less sugar coating for the developer since all the operations can be implemented using the [[CeramicApi]] interface. For example the [[TileDocument]] included in the Ceramic node out-of-the-box.
+The event based design is more or less sugar coating for the developer since all the operations can be implemented using the [CeramicApi](../../packages/common/src/ceramic-api.ts) interface. See [TileDocument](../../packages/stream-tile/src/tile-document.ts) or [ModelInstanceDocument](../../packages/stream-model-instance/src/model-instance-document.ts) for examples of streams included in the Ceramic node out-of-the-box.
 
 
 # StreamHandler
 
-The [[StreamHandler]] interface is used for determining the next **state** of the document. The method worth noting is `applyCommit` which is used for that *state transition*. For example the [[TileDocumentHandler]] is included in the Ceramic node out-of-the-box as well.
-
-The [[StreamHandler]] uses [[CeramicApi]] which is included in the [[Context]] instance.
+The [StreamHandler](../../packages/common/src/stream.ts) interface is used for determining the next **state** of the document. The method worth noting is `applyCommit` which is used for that *state transition*.
 
+The `StreamHandler` uses `CeramicApi` which is included in the [Context](../../packages/common/src/context.ts) instance.