fix: markup to be riki compantible

riki is my re-implementation of a subset of ikiwiki. some of ikiwiki's
markup doesn't work with riki's markdown parser.

Sponsored-by: author

5 files changed, 49 insertions, 79 deletions

diff --git a/architecture.mdwn b/architecture.mdwn
index 19d8419..c94685c 100644
--- a/architecture.mdwn
+++ b/architecture.mdwn
@@ -134,51 +134,36 @@ Subplot](#acceptance).
 Each requirement here is given a unique mnemnoic id for easier
 reference in discussions.
 
-**UnderstandableTests**
+* **UnderstandableTests** Acceptance tests should be possible to express
+  in a way that's easily understood by non-programmers.
 
-: Acceptance tests should be possible to express in a way that's
-  easily understood by non-programmers.
+* **EasyToWriteDocs** The markup language for writing documentation
+  should be easy to write.
 
-**EasyToWriteDocs**
+* **AidsComprehension** The formatted human-readable documentation
+  should use good layout and typography to enhance comprension.
 
-: The markup language for writing documentation should be easy to
-  write.
+* **CodeSeparately** The code to implement the acceptance tests should
+  not be embedded in the documentation source, but be in separate
+  files. This makes it easier to edit without specialised tooling.
 
-**AidsComprehension**
+* **AnyProgammingLanguage** The developers implementing the acceptance
+  tests should be free to use a language they're familiar and
+  comfortable with. Subplot should not require them to use a specific
+  language.
 
-: The formatted human-readable documentation should use good layout
-  and typography to enhance comprension.
+* **FastTestExecution** Executing the acceptance tests should be fast.
 
-**CodeSeparately**
+* **No Deployment** The acceptance test tooling should assume the system
+  under test is already deployed and available. Deploying is too big
+  of a problem space to bring into the scope of acceptance testing,
+  and there are already good tools for deployment.
 
-: The code to implement the acceptance tests should not be embedded in
-  the documentation source, but be in separate files. This makes it
-  easier to edit without specialised tooling.
-
-**AnyProgammingLanguage**
-
-: The developers implementing the acceptance tests should be free to
-  use a language they're familiar and comfortable with. Subplot should
-  not require them to use a specific language.
-
-**FastTestExecution**
-
-: Executing the acceptance tests should be fast.
-
-**NoDeployment**
-
-: The acceptance test tooling should assume the system under test is
-  already deployed and available. Deploying is too big of a problem
-  space to bring into the scope of acceptance testing, and there are
-  already good tools for deployment.
-
-**MachineParseableResults**
-
-: The tests should produce a machine parseable result that can be
-  archived, post-processed, and analyzed in ways that are of interest
-  to the project using Subplot. For example, to see trends in how long
-  tests take, how often tests fail, to find regressions, and to find
-  tests that don't provide value.
+* **MachineParseableResults** The tests should produce a machine
+  parseable result that can be archived, post-processed, and analyzed
+  in ways that are of interest to the project using Subplot. For
+  example, to see trends in how long tests take, how often tests fail,
+  to find regressions, and to find tests that don't provide value.
 
 # Subplot architecture
 
@@ -321,19 +306,15 @@ The language understood by Subplot has the following general structure:
 
 The keywords have the following meanings:
 
-**assuming**
-
-:   A condition for the scenario. If an ASSUMING step fails, the
-    scenario is skipped.
+* **assuming:** A condition for the scenario. If an ASSUMING step
+    fails, the scenario is skipped.
 
     This is used for skipping test scenarios that require specific
     software to be installed in the test environment, or access to
     external services, but which can't be required for all runs of the
     acceptance tests.
 
-**using**
-
-:   Indicate that the scenario uses a resource such as a
+* **using:** Indicate that the scenario uses a resource such as a
     database, that's constrained and can't be used by all scenarios if
     they run concurrently. When scenarios declare the resource, Subplot can
     limit which scenarios run concurrently.
@@ -350,37 +331,29 @@ The keywords have the following meanings:
     The actual management of resources belongs to the generated test
     program at runtime, not the Subplot compiler.
 
-**given**
-
-:   Set up the test environment for the action (WHEN). This
+* **given:** Set up the test environment for the action (WHEN). This
     might create files, start a background process, or something like
     that. This also sets up the reversal of the setup, so that any
     background processes are stopped automatically after the scenario
-    has ended. The setup and cleanup must succeed, or the scenario will
-    fail.
+    has ended. The setup and cleanup must succeed, or the scenario
+    will fail.
 
     The cleanups are executed in the reverse order of the GIVENs, and
     they're done always, whether the scenario succeeds or not.
 
-**when**
-
-:   Perform the action that is being tested. This must succeed. This
-    might, for example, execute a command line program, and capture
-    its output and exit code.
-
-**then**
-
-:   Test the results of the action. This would examine the output and
-    exit code of the program run in a WHEN step, or examine current
-    content of the database, or whatever is needed.
+* **when:** Perform the action that is being tested. This must
+    succeed. This might, for example, execute a command line program,
+    and capture its output and exit code.
 
-**and**
+* **then:** Test the results of the action. This would examine the
+    output and exit code of the program run in a WHEN step, or examine
+    current content of the database, or whatever is needed.
 
-:   This keyword exists to make scenarios "read" better in English.
-    The keyword indicates that this step should use the same keyword
-    as the previous step, whatever that keyword is. For example, a
-    step "THEN output is empty" might be followed by "AND the exit
-    code is 0" rather than "THEN the exit code is 0".
+* **and:** This keyword exists to make scenarios "read" better in
+    English. The keyword indicates that this step should use the same
+    keyword as the previous step, whatever that keyword is. For
+    example, a step "THEN output is empty" might be followed by "AND
+    the exit code is 0" rather than "THEN the exit code is 0".
 
 The order of steps is somewhat constrainted: first any ASSUMING steps,
 then any USING steps, at least one WHEN must come before a THEN.
diff --git a/blog/2019/09/22/subplot_and_requirement_tracking.mdwn b/blog/2019/09/22/subplot_and_requirement_tracking.mdwn
index 312d9d0..74cf418 100644
--- a/blog/2019/09/22/subplot_and_requirement_tracking.mdwn
+++ b/blog/2019/09/22/subplot_and_requirement_tracking.mdwn
@@ -10,11 +10,8 @@ First, assign each requirement a unique mnemonic id. In this example,
 it is the word in the definition list below. The "Req" suffix is just
 a convention.
 
-**SecureReq**
-: System must be sequre.
-
-**FastReq**
-: The system must be fast.
+* **SecureReq:** System must be sequre.
+* **FastReq:** The system must be fast.
 
 # First scenario tests SequreReq only {#first .SequreReq}
 
@@ -41,8 +38,8 @@ and it still serves all legitimate users
 Subplot will then annotate the output so that each requirement has
 links to the scenarios that test them, something like this: 
 
-**SecureReq** ([first](#first), [second](#second))
-: System must be sequre.
+* **SecureReq:** ([first](#first), [second](#second))
+  - System must be sequre.
 
-**FastReq** ([second](#second))
-: The system must be fast.
+* **FastReq:** ([second](#second))
+  - The system must be fast.
diff --git a/blog/2021/01/02/_iteration_planning_meeting_january_2nd.mdwn b/blog/2021/01/02/_iteration_planning_meeting_january_2nd.mdwn
index 889ebd0..3a735c8 100644
--- a/blog/2021/01/02/_iteration_planning_meeting_january_2nd.mdwn
+++ b/blog/2021/01/02/_iteration_planning_meeting_january_2nd.mdwn
@@ -41,7 +41,7 @@ need for more flexibility in Subplot. We haven't filed an issue about
 this yet, as it'd be too woolly.
 
 We finished [[!milestone 19]], having fixed [[!issue 130]], [[!issue
-129]], [[!issue 123]], [[!issue 101].
+129]], [[!issue 123]], [[!issue 101]].
 
 Progress was made on [[!issue 131]], [[!issue 108]], [[!issue 22]].
 
diff --git a/blog/2021/07/30/meeting.mdwn b/blog/2021/07/30/meeting.mdwn
index 4a90f6c..b10204e 100644
--- a/blog/2021/07/30/meeting.mdwn
+++ b/blog/2021/07/30/meeting.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Iteration planning: July 31"]]
 [[!tag meeting]]
-[[!meta date="2021-07-31 18:00 +0300"]]
+[[!meta date="2021-07-31 18:00:00 +0300"]]
 
 [[!toc levels=2]]
 
diff --git a/blog/2022/06/18/planning.mdwn b/blog/2022/06/18/planning.mdwn
index 59d5b37..d94a0b7 100644
--- a/blog/2022/06/18/planning.mdwn
+++ b/blog/2022/06/18/planning.mdwn
@@ -1,5 +1,5 @@
 [[!meta title="Iteration planning: June 18 – July 2"]]
-[[!meta date="Sat, 18 June 2022 13:50:00 +0100"]]
+[[!meta date="2022-06-18 13:50:00 +0100"]]
 [[!tag meeting]]
 
 [[!toc levels=2]]