some code block (and related) cleanup

Author: heskew

docs/developers/operations-api/clustering.md

@@ -167,7 +167,8 @@ _Operation is restricted to super_user roles only_
           "lastReceivedRemoteTime": "Wed, 12 Feb 2025 16:49:29 GMT",
           "lastReceivedLocalTime": "Wed, 12 Feb 2025 16:50:59 GMT",
           "lastSendTime": "Wed, 12 Feb 2025 16:50:59 GMT"
-        },
+        }
+      ]
     }
   ],
   "node_name": "server-1.domain.com",

docs/developers/operations-api/components.md

@@ -462,11 +462,12 @@ _Operation is restricted to super_user roles only_
 [
     {
         "name": "harperdb-private-component"
-    },
-    ...
+    }
 ]
 ```
 
+_Note: Additional SSH keys would appear as more objects in this array_
+
 ---
 
 ## Set SSH Known Hosts

docs/developers/replication/sharding.md

@@ -61,10 +61,12 @@ Likewise, you can specify replicateTo and confirm parameters in the operation ob
 
 or you can specify nodes:
 
-```json
-...,
+```jsonc
+{
+  // ...
   "replicateTo": ["node-1", "node-2"]
-...
+  // ...
+}
 ```
 
 ## Programmatic Replication Control

docs/developers/security/users-and-roles.md

@@ -98,7 +98,7 @@ There are two parts to a permissions set:
 
 Each table that a role should be given some level of CRUD permissions to must be included in the `tables` array for its database in the roles permissions JSON passed to the API (_see example above_).
 
-```json
+```jsonc
 {
   "table_name": { // the name of the table to define CRUD perms for
     "read": boolean, // access to read from this table
@@ -113,6 +113,7 @@ Each table that a role should be given some level of CRUD permissions to must be
           "update": boolean // access to update this attribute in the table
         }
     ]
+  }
 }
 ```
 

docs/getting-started/first-harper-app.md

@@ -88,21 +88,20 @@ type Dog @table @export {
 }
 ```
 
-By default the application HTTP server port is `9926` (this can be [configured here](../deployments/configuration#http)), so the local URL would be `http:/localhost:9926/Dog/` with a full REST API. We can PUT or POST data into this table using this new path, and then GET or DELETE from it as well (you can even view data directly from the browser). If you have not added any records yet, we could use a PUT or POST to add a record. PUT is appropriate if you know the id, and POST can be used to assign an id:
+By default the application HTTP server port is `9926` (this can be [configured here](../deployments/configuration#http)), so the local URL would be `http://localhost:9926/Dog/` with a full REST API. We can PUT or POST data into this table using this new path, and then GET or DELETE from it as well (you can even view data directly from the browser). If you have not added any records yet, we could use a PUT or POST to add a record. PUT is appropriate if you know the id, and POST can be used to assign an id:
 
-```json
-POST /Dog/
-Content-Type: application/json
-
-{
-	"name": "Harper",
-	"breed": "Labrador",
-	"age": 3,
-	"tricks": ["sits"]
-}
+```bash
+curl -X POST http://localhost:9926/Dog/ \
+  -H "Content-Type: application/json" \
+  -d '{
+    "name": "Harper",
+    "breed": "Labrador", 
+    "age": 3,
+    "tricks": ["sits"]
+  }'
 ```
 
-With this a record will be created and the auto-assigned id will be available through the `Location` header. If you added a record, you can visit the path `/Dog/<id>` to view that record. Alternately, the curl command curl `http:/localhost:9926/Dog/<id>` will achieve the same thing.
+With this a record will be created and the auto-assigned id will be available through the `Location` header. If you added a record, you can visit the path `/Dog/<id>` to view that record. Alternately, the curl command `curl http://localhost:9926/Dog/<id>` will achieve the same thing.
 
 ## Authenticating Endpoints
 

versioned_docs/version-4.1/security/users-and-roles.md

@@ -102,7 +102,7 @@ There are two parts to a permissions set:
 
 Each table that a role should be given some level of CRUD permissions to must be included in the `tables` array for its schema in the roles permissions JSON passed to the API (_see example above_).
 
-```json
+```jsonc
 {
   "table_name": { // the name of the table to define CRUD perms for
     "read": boolean, // access to read from this table

versioned_docs/version-4.2/developers/security/users-and-roles.md

@@ -47,7 +47,7 @@ When creating a new, user-defined role in a HarperDB instance, you must provide
 
 Example JSON for `add_role` request
 
-```json
+```jsonc
 {
 	"operation": "add_role",
 	"role": "software_developer",
@@ -98,7 +98,7 @@ There are two parts to a permissions set:
 
 Each table that a role should be given some level of CRUD permissions to must be included in the `tables` array for its schema in the roles permissions JSON passed to the API (_see example above_).
 
-```json
+```jsonc
 {
   "table_name": { // the name of the table to define CRUD perms for
     "read": boolean, // access to read from this table

versioned_docs/version-4.3/developers/security/users-and-roles.md

@@ -47,7 +47,7 @@ When creating a new, user-defined role in a HarperDB instance, you must provide
 
 Example JSON for `add_role` request
 
-```json
+```jsonc
 {
 	"operation": "add_role",
 	"role": "software_developer",
@@ -98,7 +98,7 @@ There are two parts to a permissions set:
 
 Each table that a role should be given some level of CRUD permissions to must be included in the `tables` array for its database in the roles permissions JSON passed to the API (_see example above_).
 
-```json
+```jsonc
 {
   "table_name": { // the name of the table to define CRUD perms for
     "read": boolean, // access to read from this table

versioned_docs/version-4.4/developers/operations-api/components.md

@@ -453,11 +453,12 @@ _Operation is restricted to super_user roles only_
 [
     {
         "name": "harperdb-private-component"
-    },
-    ...
+    }
 ]
 ```
 
+_Note: Additional SSH keys would appear as more objects in this array_
+
 ## Set SSH Known Hosts
 
 Sets the SSH known_hosts file. This will overwrite the file.

versioned_docs/version-4.4/developers/replication/sharding.md

@@ -25,7 +25,7 @@ With the REST interface, replication levels and destinations can also specified
 PUT /MyTable/3
 X-Replicate-To: 2;confirm=1
 
-...
+// ... }
 ```
 
 You can also explicitly specify destination nodes by providing a comma-separated list of node hostnames. For example, to specify that data should be replicated to nodes `node1` and `node2`, you can use the following header:
@@ -41,7 +41,7 @@ X-Replicate-To: node1,node2
 
 Likewise, you can specify replicateTo and confirm parameters in the operation object when using the Harper API. For example, to specify that data should be replicated to two other nodes, and the response should be returned once confirmation is received from one other node, you can use the following operation object:
 
-```json
+```jsonc
 {
 	"operation": "update",
 	"schema": "dev",
@@ -57,10 +57,12 @@ Likewise, you can specify replicateTo and confirm parameters in the operation ob
 
 or you can specify nodes:
 
-```json
-...,
+```jsonc
+{
+  // ...
   "replicateTo": ["node-1", "node-2"]
-...
+  // ...
+}
 ```
 
 ## Programmatic Replication Control
@@ -104,7 +106,7 @@ MyTable.setResidencyById((id) => {
 
 Normally sharding allows data to be stored in specific nodes, but still allows access to the data from any node. However, you can also disable cross-node access so that data is only returned if is stored on the node where it is accessed. To do this, you can set the `replicateFrom` property on the context of operation to `false`:
 
-```json
+```jsonc
 {
 	"operation": "search_by_id",
 	"table": "MyTable",