update

Author: ymc9

blog/better-auth/index.mdx

@@ -434,7 +434,7 @@ type Auth {
 }
 ```
 
-Now, we're ready to write the policy rules. You can find more information about access polices [here](https://zenstack.dev/docs/the-complete-guide/part1/access-policy/).
+Now, we're ready to write the policy rules. You can find more information about access policies [here](https://zenstack.dev/docs/the-complete-guide/part1/access-policy/).
 
 #### 1. Tenant segregation
 

docs/faq.md

@@ -60,7 +60,7 @@ The short answer is it works in most cases. Please refer to [this guide](./guide
 
 ### Does the order in which access policies are defined matter?
 
-No. See [here](./the-complete-guide/part1/4-access-policy/4.1-model-level.md#evaluation-of-model-level-policies) for how access polices are evaluated.
+No. See [here](./the-complete-guide/part1/4-access-policy/4.1-model-level.md#evaluation-of-model-level-policies) for how access policies are evaluated.
 
 ### Is Prisma's new "prisma-client" generator supported?
 

versioned_docs/version-3.x/orm/access-control/post-update.md

@@ -14,7 +14,7 @@ In ZenStack v2, post-update rules were implicitly defined with the "update" oper
 
 ## Overview
 
-Among the CRUD operations, "update" is a special one because it has a "pre" state and "post" state. The "update" policies we've seen in the previous parts refer to the "pre" state, meaning that if your polices refer to the model's fields, the fields are evaluated to their values before the update happens.
+Among the CRUD operations, "update" is a special one because it has a "pre" state and "post" state. The "update" policies we've seen in the previous parts refer to the "pre" state, meaning that if your policies refer to the model's fields, the fields are evaluated to their values before the update happens.
 
 However, sometimes you want to express conditions that should hold after the update happens. For example, you may want to ensure that after an update, a post's `published` field cannot be set to true unless the current user is the author. Post-update policies are designed for such scenarios.
 

versioned_docs/version-3.x/reference/plugins/policy.md

@@ -128,7 +128,8 @@ The following functions can be used in policy conditions:
     ```
 
     Returns the name of the model for which the policy rule is defined. If the rule is inherited to a sub model, this function returns the name of the sub model.
-        - `casing`: parameter to control the casing of the returned value. Valid values are "original", "upper", "lower", "capitalize", "uncapitalize". Defaults to "original".
+        
+      - `casing`: parameter to control the casing of the returned value. Valid values are "original", "upper", "lower", "capitalize", "uncapitalize". Defaults to "original".
 
 - `currentOperation()`
 
@@ -137,7 +138,8 @@ The following functions can be used in policy conditions:
     ```
 
     Returns the operation for which the policy rule is defined for. Note that a rule with "all" operation is expanded to "create", "read", "update", and "delete" rules, and the function returns corresponding value for each expanded version.
-        - `casing`: parameter to control the casing of the returned value. Valid values are "original", "upper", "lower", "capitalize", "uncapitalize". Defaults to "original".
+        
+      - `casing`: parameter to control the casing of the returned value. Valid values are "original", "upper", "lower", "capitalize", "uncapitalize". Defaults to "original".
 
 ## Runtime Plugin