added documentation about terraform.lock and backendless functionality

Author: motatoes

docs/ce/howto/backendless-mode.mdx

@@ -10,7 +10,9 @@ Digger works best as a 2-piece solution:
 You can however still use the most basic features of Digger as a standalone action without a backend. To do that, set the following option in your workflow configuration:
 
 ```
+# add this to .github/actions/digger_backendless_workflow.yml as an argument to the digger step
 no-backend: true
+
 ```
 
 You'd also need to add `pull_request` and `issue_comment` workflow triggers:
@@ -27,10 +29,29 @@ on:
 
 # Limitations
 
-Historically this was the original way of running Digger. The initial version called "tfrun" didn't have any backend, it was just a GitHub action. But it quickly became apparent that without some sort of orchestration there's only so much that can be done:
+Historically this was the original way of running Digger. The initial version called "tfrun" didn't have any backend, it was just a GitHub action.
+But it quickly became apparent that without some sort of orchestration there's only so much that can be done:
 
 - No concurrency; all plans / applies need to run sequentially, which is slow
 - Action starts on every push or comment, often just to detect that there are no changes. That's expensive, especially in large repos.
 - Clashing applies from other jobs will fail as they cannot be queued
 - Buckets / tables for PR-level locks need to be configured manually in your cloud account
 - Comments and status checks will be updated with a delay
+
+For many small teams this is more than enough and it is quite easy to setup, if it works for you please don't hesitate to use digger in this manner.
+
+# How it works
+
+In order to function without a backend digger still needs store information about the PR locks so that it does not run "terraform plan"
+in 2 different PRs for the same digger project (since that would cause them stepping on top of eachother). In order to achieve that, digger will
+create a small resource in your cloud account to store which PR locked which project. The type of resource varies depending on the cloud account, here is what gets created:
+
+| Cloud Provider | Resource Type   |
+|----------------|-----------------|
+| AWS            | DynamoDB        |
+| GCP            | GCP Bucket      |
+| Azure          | Storage Tables  |
+
+In case of AWS, during the first run digger will create this resource for you. However in case of GCP and azure you need to create it yourself and supply it as an argument.
+
+After the resource is created digger will continue to use it for subsequent runs in order to store information about the locks and function correctly.

docs/ce/reference/terraform.lock.mdx

@@ -0,0 +1,32 @@
+---
+title: "handling terraform.lock file"
+---
+
+The `.terraform.lock.hcl` file is an important part of Terraform's dependency management system.
+Digger does not currently take opinions on how you manage .terraform.lock files however please be aware that since digger runs terraform
+ within ephemeral jobs that if terraform.lock file gets updated within a job its not going to be commited back to the PR.
+ Having said that, digger does not pass any `-upgrade` flag during init flag currently. Therefore it is recommended that you use semantic versions
+ in your terraform providers and commit .terraform.local file manually. Then when updating versions of providers you can run another `terraform init -upgrade` file to update the file again,
+ then commit it to the PR where you are upgrading provider versions.
+
+ Here are some general best practices for working with this file:
+
+## Core Best Practices
+
+1. **Always commit to version control** - The lock file should be committed to your version control system (Git, etc.) to ensure all team members and CI/CD pipelines use exactly the same provider versions.
+
+2. **Don't edit manually** - The lock file is generated and maintained by Terraform. Manual edits can break the hashing verification system.
+
+3. **Use in CI/CD pipelines** - Ensure your automation uses the lock file by not running `terraform init -upgrade` in pipelines.
+
+4. **Update deliberately** - Use `terraform init -upgrade` when you intentionally want to update providers, not as part of regular workflows.
+
+## Additional Recommendations
+
+5. **Review changes** - When the lock file changes after an upgrade, review the differences to understand what provider versions have changed.
+
+6. **Test after updates** - After updating provider versions, thoroughly test your infrastructure code to catch any breaking changes.
+
+7. **Use provider constraints** - In your Terraform configuration, specify version constraints for providers to control which versions can be selected during upgrades.
+
+8. **Understand cross-platform hashes** - The lock file contains hashes for different platforms. If your team uses multiple platforms, you may need to run `terraform providers lock` with the `-platform` flag to add hashes for other platforms.

docs/mint.json

@@ -117,7 +117,8 @@
       "pages": [
         "ce/reference/digger.yml",
         "ce/reference/action-inputs",
-        "ce/reference/api"
+        "ce/reference/api",
+        "ce/reference/terraform.lock"
       ]
     },
     {