Problem: there's deadlink in docs (#530)

* Problem: there's deadlink in docs

Solution:
- fix deadlink
- fix deadlink check workflow

* fix deadlink

.github/workflows/linkchecker.yml

@@ -2,6 +2,15 @@ name: Check Markdown links
 on:
   schedule:
     - cron: "* */24 * * *"
+  pull_request:
+    paths:
+      - 'docs/**'
+  push:
+    paths:
+      - 'docs/**'
+    branches:
+      - main
+      - release/**
 jobs:
   markdown-link-check:
     runs-on: ubuntu-latest

docs/api/json-rpc/events.md

@@ -17,7 +17,7 @@ messages and index transactions. {synopsis}
 
 ### SDK and Tendermint Events
 
-It is possible to subscribe to `Events` via Tendermint's [Websocket](https://tendermint.com/docs/app-dev/subscribing-to-events-via-websocket.html#subscribing-to-events-via-websocket).
+It is possible to subscribe to `Events` via Tendermint's [Websocket](https://docs.tendermint.com/v0.35/app-dev/indexing-transactions.html#subscribing-to-transactions).
 This is done by calling the `subscribe` RPC method via Websocket:
 
 ```json

docs/architecture/adr-template.md

@@ -0,0 +1,36 @@
+# ADR {ADR-NUMBER}: {TITLE}
+
+## Changelog
+* {date}: {changelog}
+
+## Context
+
+> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. 
+## Decision
+
+> This section explains all of the details of the proposed solution, including implementation details.
+It should also describe affects / corollary items that may need to be changed as a part of this.
+If the proposed change will be large, please also indicate a way to do the change to maximize ease of review.
+(e.g. the optimal split of things to do between separate PR's)
+
+## Status
+
+> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
+
+{Deprecated|Proposed|Accepted}
+
+## Consequences
+
+> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones.
+
+### Positive
+
+### Negative
+
+### Neutral
+
+## References
+
+> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here!
+
+* {reference link}