Corrected the lint and spelling issues.

Author: cfmitrah

docs/03.reference/01.functions/restinitapplication/_arguments/dirPath.md

@@ -1,5 +1,6 @@
 Path to the directory to be registered or reset.
 
 This folder should contain 
+
 - one or more REST enabled CFCs, i.e. with `rest=true`
 - An `Application.cfc` (if required)

docs/03.reference/02.tags/dbinfo/_usageNotes.md

@@ -2,4 +2,3 @@ Performance tips
 
 - Using `type="columns_minimal"` is dramatically faster than `type="columns"`
 - With `type="table"` using `filter="table"` is also much faster
-

docs/04.guides/04.cookbooks/02.application-context-set-mapping/page.md

@@ -42,7 +42,7 @@ component {
 }
 ```
 
-In difference to `this.mappings`, `this.componentpaths" and `this.customtagpaths` are taking arrays as input and not structs, because in that case there is not "virtual path" that needs to be defined.
+In difference to `this.mappings`, `this.componentpaths` and `this.customtagpaths` are taking arrays as input and not structs, because in that case there is not "virtual path" that needs to be defined.
 
 ## Advanced
 

docs/04.guides/11.developing-with-lucee-server/03.operators/page.md

@@ -104,7 +104,7 @@ description: Mathematical, Logical, Ternary, Comparison, String and Elvis Operat
 | --------- | -------------- | ----------- |
 | EQ        | equals         | Returns true if operands are equal, e.g. `"A" EQ "A"` is true |
 | ==        | equals         | Returns true if operands are equal, e.g. `"A" == "A"` is true |
-| ===       | identical      | Returns true if operands are the same object in memory, false if they are not, (Note this is different than how JavaScript's `===` operator works). **Lucee 6 === works like javascript, comparing type and value, however, prior to 6.2.3.34, it was senstive to the underlying java types [LDEV-5806](https://luceeserver.atlassian.net/browse/LDEV-5806)** |
+| ===       | identical      | Returns true if operands are the same object in memory, false if they are not, (Note this is different than how JavaScript's `===` operator works). **Lucee 6 === works like javascript, comparing type and value, however, prior to 6.2.3.34, it was sensitive to the underlying java types [LDEV-5806](https://luceeserver.atlassian.net/browse/LDEV-5806)** |
 | NEQ       | does not equal | Returns true if operands are not equal, e.g. `"A" NEQ "B"` is true |
 | \<\>        | does not equal | Returns true if operands are not equal, e.g. `"A" <> "B"` is true |
 | !=        | does not equal | Returns true if operands are not equal, e.g. `"A" != "B"` is true |

docs/04.guides/12.deploying-lucee-server-apps/page.md

@@ -105,7 +105,6 @@ You can pre warm a lucee installation, by setting the env var `LUCEE_ENABLE_WARM
 
 Lucee Docker images are already pre-warmed and Lucee 6.2 includes several improvements which make deployment faster.
 
-
 ## Admin and Docs extensions
 
 You will see extensions, Lucee Admin and Lucee Docs, these simply install mappings to make them available. The admin is tightly coupled to the Lucee Version, so they aren't separately deployed

docs/recipes/breaking-changes-6-2.md

@@ -111,7 +111,7 @@ Workaround, create an Application.cfc which extends the parent Application.cfc
 
 [LDEV-5323](https://luceeserver.atlassian.net/browse/LDEV-5323)
 
-## Strict Equality Operator was senstive to underlying java types
+## Strict Equality Operator was sensitive to underlying java types
 
 Lucee 6 improved the `===` operator to compare type and value, but was checking only the underlying java type, rather than cfml type, so numbers might fail
 

docs/recipes/cfschedule-bulk-update.md

@@ -1,6 +1,6 @@
 <!--
 {
-  "title": "Scheduled Tasks - efficently updating in a single operation",
+  "title": "Scheduled Tasks - efficiently updating in a single operation",
   "id": "cfschedule-bulk",
   "description": "How to update scheduled tasks in a single operation",
   "since": "6.2.3.16",
@@ -19,7 +19,7 @@
 }
 -->
 
-## Efficently and reliably updating scheduled tasks in a single operation
+## Efficiently and reliably updating scheduled tasks in a single operation
 
 Using the [[tag-schedule]] to update all tasks on application start has always been a bit slow, as each update reloads the config which is slow when updating many tasks.
 
@@ -31,7 +31,7 @@ Note, this approach only works reliably since 6.2.3.16, as the config import / m
 
 ### Updating tasks in a single transaction
 
-An alternative and far more efficent approach is to 
+An alternative and far more efficient approach is to 
 
 1. Extract the **scheduledTasks** from `.CFConfig.json`, 
 2. Check and modify the array of tasks if needed (i.e. track changes)
@@ -76,7 +76,7 @@ Loop over the array and modify it as needed.
 
 ### Tip: avoid updates when there is no change
 
-It's good to avoid updating the config if there is no change, but not so important when using this efficent approach.
+It's good to avoid updating the config if there is no change, but not so important when using this efficient approach.
 
 An easy way is to simply compare the source tasks array with the updated tasks array.
 

docs/recipes/hooks-and-monitors.md

@@ -321,6 +321,7 @@ You can define monitors directly in your `.CFConfig.json` configuration file und
 ```
 
 **Configuration Properties:**
+
 - `name`: Unique identifier for the monitor (required)
 - `type`: Monitor type - `action`, `request`, or `interval` (required)
 - `class`: Full Java class name (required unless using component)
@@ -332,6 +333,7 @@ You can define monitors directly in your `.CFConfig.json` configuration file und
 - `async`: Run request monitors asynchronously (optional, request monitors only, default: false)
 
 **Class Definition Resolution Order:**
+
 1. **OSGi Bundle** - If `bundleName` is provided
 2. **Maven Dependency** - If `maven` is provided  
 3. **CFML Component** - If `component` is provided (and `class` is null)
@@ -412,6 +414,7 @@ public class MyActionMonitor implements ActionMonitor {
 ### Use Cases
 
 Action monitors are ideal for:
+
 - Database query performance tracking
 - Lock contention analysis
 - Mail delivery monitoring
@@ -488,6 +491,7 @@ public class MyRequestMonitor implements RequestMonitor {
 ### Use Cases
 
 Request monitors are ideal for:
+
 - Application performance monitoring (APM)
 - Error rate tracking
 - User behavior analysis
@@ -566,6 +570,7 @@ public class MyIntervalMonitor implements IntervallMonitor {
 ### Use Cases
 
 Interval monitors are ideal for:
+
 - System resource monitoring
 - Memory leak detection
 - Performance baseline establishment
@@ -633,16 +638,19 @@ When implementing hooks and monitors, consider these security aspects:
 ## Common Issues
 
 **Hook Not Loading**
+
 - Verify class name and path are correct
 - Check bundle/Maven dependencies are available  
 - Review Lucee logs for error messages
 
 **Monitor Not Triggering**
+
 - Ensure monitoring is enabled in `.CFConfig.json`
 - Check that the monitor interface is implemented correctly
 - Verify the extension manifest syntax is valid
 
 **Performance Issues**
+
 - Keep monitor logic lightweight
 - Use asynchronous processing for expensive operations
 - Implement proper error handling to prevent monitor failures

docs/recipes/query-result-threshold.md

@@ -32,11 +32,13 @@ This feature provides early warning when queries return unexpectedly large datas
 Query result logging is configured using a single environment variable or system property:
 
 **Environment Variable:**
+
 ```bash
 LUCEE_QUERY_RESULT_THRESHOLD=100000
 ```
 
 **System Property:**
+
 ```bash
 -Dlucee.query.result.threshold=100000
 ```
@@ -157,10 +159,10 @@ When large result sets are logged:
 2. Check that queries actually exceed the threshold
 3. Ensure `warn` level logging is enabled for the `datasource` category
 
-
 ### False Positives
 
 If logging captures expected large result sets:
+
 - Adjust the threshold higher
 - Use different thresholds for different environments
 - Consider the business logic requirements

docs/recipes/thread-dump-startup.md

@@ -169,6 +169,7 @@ function analyzeThreadDump(path, threadName) {
 ```
 
 This function provides:
+
 - **Thread filtering**: Focus on specific threads by name (case-insensitive partial matching)
 - **Relative timing**: Shows elapsed time from the first captured snapshot
 - **Stack trace limiting**: Displays only the top stack frames for better readability