odac 1.4.7 → 1.4.9

package/docs/ai/skills/frontend/forms.md

@@ -42,7 +42,29 @@ Odac.form(
   }
 )
 
-// 5) Manual GET request helper
+// 5) Disable all automatic messages and handle everything in the callback
+Odac.form(
+  {form: 'form[data-odac-form]', messages: false},
+  response => {
+    if (response?.result?.success) {
+      // Custom success: e.g. show a toast, update UI
+    } else if (response?.errors) {
+      // Custom error: manually map errors to DOM
+    }
+  }
+)
+
+// 6) Only show success messages, handle errors manually
+Odac.form(
+  {form: 'form[data-odac-form]', messages: ['success']},
+  response => {
+    if (!response?.result?.success && response?.errors) {
+      // Custom error handling
+    }
+  }
+)
+
+// 7) Manual GET request helper
 Odac.get('/api/status', data => {
   const status = document.querySelector('[data-api-status]')
   if (status) status.textContent = String(data?.status ?? '')

package/docs/backend/04-routing/09-websocket-quick-reference.md

@@ -31,6 +31,7 @@ Odac.Route.ws('/path', Odac => {
 | Property | Description |
 |----------|-------------|
 | `Odac.ws.id` | Unique client ID |
+| `Odac.ws.readyState` | RFC 6455 state: `0` CONNECTING, `1` OPEN, `2` CLOSING, `3` CLOSED |
 | `Odac.ws.rooms` | Array of joined rooms |
 | `Odac.ws.data` | Custom data storage |
 
@@ -169,14 +170,33 @@ const ws = Odac.ws('/chat', {shared: true})
 |------|-------------|
 | `1000` | Normal closure |
 | `1001` | Going away |
-| `1002` | Protocol error |
+| `1002` | Protocol error (e.g. unexpected continuation frame) |
 | `1003` | Unsupported data |
 | `1006` | Abnormal closure |
+| `1008` | Rate limit exceeded |
+| `1009` | Payload too large |
 | `4000` | Middleware rejected |
 | `4001` | Unauthorized |
 | `4002` | Invalid/missing token |
 | `4003` | Forbidden (middleware) |
 
+## readyState Constants
+
+| Value | Constant | Description |
+|-------|----------|-------------|
+| `0` | `CONNECTING` | Handshake done, handler not yet invoked |
+| `1` | `OPEN` | Active — messages can be sent/received |
+| `2` | `CLOSING` | Close frame sent, draining |
+| `3` | `CLOSED` | Fully terminated |
+
+```javascript
+const {READY_STATE} = require('odac')
+
+if (Odac.ws.readyState === READY_STATE.OPEN) {
+  Odac.ws.send({status: 'alive'})
+}
+```
+
 ## Best Practices
 
 1. **Always handle authentication**

package/docs/backend/04-routing/09-websocket.md

@@ -97,9 +97,30 @@ Odac.ws.on('error', err => {})     // Error occurred
 ### Connection Management
 
 ```javascript
-Odac.ws.close()           // Close connection
+Odac.ws.close()           // Close connection (sends close frame, transitions to CLOSED)
 Odac.ws.ping()            // Send ping frame
 Odac.ws.id                // Unique client ID
+Odac.ws.readyState        // Current connection state (0–3)
+```
+
+### Connection State
+
+`Odac.ws.readyState` reflects the RFC 6455 lifecycle. Use the static constants on `WebSocketClient` or the exported `READY_STATE` enum for readable comparisons:
+
+| Value | Constant | Description |
+|-------|----------|-------------|
+| `0` | `CONNECTING` | Handshake complete, handler not yet called |
+| `1` | `OPEN` | Connection active, messages can be sent |
+| `2` | `CLOSING` | Close frame sent, waiting for socket drain |
+| `3` | `CLOSED` | Connection fully terminated |
+
+```javascript
+const {READY_STATE} = require('odac')
+
+Odac.ws.on('message', data => {
+  if (Odac.ws.readyState !== READY_STATE.OPEN) return
+  Odac.ws.send({echo: data})
+})
 ```
 
 ## Rooms

package/docs/backend/08-database/05-write-behind-cache.md

@@ -0,0 +1,230 @@
+# Write-Behind Cache
+
+At high traffic, individual database writes for common operations — like incrementing a page view counter or stamping a user's last-active date — quickly saturate your connection pool. One million page views = one million `UPDATE` queries.
+
+ODAC's **Write-Behind Cache** solves this by buffering writes in memory and flushing them to the database in efficient batches. The only change to your code is adding `.buffer` to the chain.
+
+```javascript
+// Without buffer — 1 DB write per request
+await Odac.DB.posts.where(postId).update({views: Odac.DB.raw('views + 1')})
+
+// With buffer — 1 DB write per flush interval, for all requests combined
+await Odac.DB.posts.buffer.where(postId).increment('views')
+```
+
+---
+
+## How It Works
+
+**Architecture: Ipc-Backed, Driver-Agnostic**
+
+All buffered state is held in `Odac.Ipc`. The active IPC driver determines the scaling model:
+
+| Driver | Scope | When to use |
+|---|---|---|
+| `memory` (default) | Single machine — cluster workers share state via Primary process | Single-server deployments |
+| `redis` | Multi-machine — all servers share state in Redis | Horizontal scaling behind a load balancer |
+
+```
+// Memory driver (default)
+Worker 1 ─┐
+Worker 2 ─┼──→ Primary (Ipc memory store) ──→ DB (batch flush every 5s)
+Worker N ─┘
+
+// Redis driver
+Server A ─┐
+Server B ─┼──→ Redis (Ipc state) ──→ DB (flush — distributed lock prevents duplicate writes)
+Server C ─┘
+```
+
+A **distributed lock** (`Ipc.lock`) guarantees that only one process or server flushes at a time, even across multiple machines.
+
+**Crash Safety via LMDB Checkpoint** *(memory driver only)*
+
+Every 30 seconds, pending buffer data is written to the local LMDB store. On a crash and restart, ODAC recovers this checkpoint and flushes it to the database before accepting any traffic. When using the Redis driver, Redis itself provides durability — LMDB checkpoints are skipped.
+
+---
+
+## Three Operations
+
+### 1. Counter Increment
+
+Accumulates numeric deltas. Multiple increments to the same column merge into a single `UPDATE col = col + delta` at flush time.
+
+```javascript
+// Increment by 1 (default)
+await Odac.DB.posts.buffer.where(postId).increment('views')
+
+// Increment by a custom amount
+await Odac.DB.posts.buffer.where(postId).increment('likes', 5)
+await Odac.DB.downloads.buffer.where(fileId).increment('count', 3)
+```
+
+**Read the current value** — returns `DB base + pending delta`, always accurate:
+
+```javascript
+const currentViews = await Odac.DB.posts.buffer.where(postId).get('views')
+// → 4527 (e.g., 4500 in DB + 27 buffered, not yet flushed)
+```
+
+**Composite primary key:**
+
+```javascript
+await Odac.DB.post_stats.buffer
+  .where({post_id: 123, date: '2026-04-01'})
+  .increment('views')
+```
+
+---
+
+### 2. Last-Write-Wins Update
+
+Buffers column SET operations for a row. If the same row is updated multiple times before a flush, the values are merged — the latest value for each column wins. The entire pending set for a row is written in a single `UPDATE` at flush.
+
+```javascript
+// 50 requests update the same user → 1 UPDATE at flush
+await Odac.DB.users.buffer.where(userId).update({active_date: new Date()})
+await Odac.DB.users.buffer.where(userId).update({last_ip: req.ip})
+// → UPDATE users SET active_date = ?, last_ip = ? WHERE id = ?  (one query for all 50 requests)
+```
+
+**Composite primary key:**
+
+```javascript
+await Odac.DB.user_prefs.buffer
+  .where({user_id: 1, pref_key: 'theme'})
+  .update({pref_value: 'dark'})
+```
+
+**Combine with increment** — both flush in the same cycle:
+
+```javascript
+await Odac.DB.users.buffer.where(userId).increment('login_count')
+await Odac.DB.users.buffer.where(userId).update({active_date: new Date(), last_ip: req.ip})
+```
+
+---
+
+### 3. Batch Insert
+
+Queues rows in memory and inserts them in chunks of 1,000 at flush time. Ideal for audit logs, analytics events, and activity streams where individual inserts are wasteful.
+
+```javascript
+await Odac.DB.activity_log.buffer.insert({
+  user_id: userId,
+  action: 'page_view',
+  meta: req.url,
+  created_at: Date.now()
+})
+```
+
+The queue auto-flushes immediately if it exceeds `maxQueueSize` (default: 10,000 rows).
+
+---
+
+## Manual Flush
+
+Force an immediate flush for a specific table or for all buffered tables:
+
+```javascript
+// Flush a single table
+await Odac.DB.posts.buffer.flush()
+
+// Flush all buffered tables across all connections
+await Odac.DB.buffer.flush()
+```
+
+> Graceful shutdown (`SIGTERM`/`SIGINT`) triggers a final flush automatically before the DB connections are closed. You do not need to call `flush()` in your shutdown handlers.
+
+---
+
+## Configuration
+
+Add a `buffer` section to your `odac.json`:
+
+```json
+{
+  "buffer": {
+    "flushInterval": 5000,
+    "checkpointInterval": 30000,
+    "maxQueueSize": 10000,
+    "primaryKey": "id"
+  }
+}
+```
+
+| Option | Default | Description |
+|---|---|---|
+| `flushInterval` | `5000` | How often (ms) to flush pending data to the database |
+| `checkpointInterval` | `30000` | How often (ms) to write a crash-recovery checkpoint to LMDB *(memory driver only)* |
+| `maxQueueSize` | `10000` | Auto-flush the insert queue when it reaches this many rows |
+| `primaryKey` | `"id"` | Default primary key column name for scalar `where()` values |
+
+---
+
+## Horizontal Scaling
+
+To share buffer state across multiple servers, switch the `ipc` driver to `redis`:
+
+```json
+{
+  "ipc": {
+    "driver": "redis",
+    "redis": "default"
+  }
+}
+```
+
+With the Redis driver active:
+- All `increment`, `update`, and `insert` operations go to Redis atomically.
+- Any server can trigger a `flush()` — the distributed lock ensures no server writes twice.
+- LMDB checkpoints are skipped (Redis persistence provides the durability guarantee).
+
+No code changes are required in your application. The `.buffer` API is identical regardless of driver.
+
+---
+
+## Named Database Connections
+
+The buffer respects your multi-connection configuration. Access it via the named connection, then the table:
+
+```javascript
+// Default connection
+await Odac.DB.posts.buffer.where(postId).increment('views')
+
+// Named connection: 'analytics'
+await Odac.DB.analytics.events.buffer.insert({type: 'click', target: '#cta'})
+```
+
+---
+
+## Guarantees
+
+| Scenario | Behaviour |
+|---|---|
+| Worker crash | No data loss — all state is in the Primary process (memory) or Redis |
+| Primary crash | Pending data recovered from LMDB checkpoint on next startup *(memory driver)* |
+| Server crash (Redis) | Pending data is durable in Redis — recovered on next flush cycle |
+| DB flush error | Data is retained in Ipc and retried on the next flush cycle |
+| Graceful shutdown | Automatic final flush before connections close |
+| `get()` after `increment()` | Returns base + buffered delta — always accurate, no extra DB read |
+| Concurrent workers | Primary serializes all writes (memory) or Redis atomic ops prevent races |
+| Multiple servers | Distributed lock guarantees exactly one flush at a time |
+
+---
+
+## When to Use (and Not Use)
+
+**Use Write-Behind Cache for:**
+- Page/post view counters
+- Download counters, like/upvote counts
+- User last-active timestamps, last IP
+- Activity logs, analytics events, audit trails
+- Any write that is not immediately safety-critical and occurs on every request
+
+**Do not use for:**
+- Operations where the write must be visible to the *same* request that triggered it
+- Inserts that return generated IDs you need immediately (use direct `insert()`)
+
+> [!WARNING]
+> **Never use Write-Behind Cache for financial or safety-critical operations** — payment records, order confirmations, balance changes, inventory decrements, or any write where data loss or a delayed flush would have real-world consequences. The buffer does not guarantee that data reaches the database before a crash. Use direct database transactions for anything that matters immediately.

package/docs/backend/08-database/06-read-through-cache.md

@@ -0,0 +1,206 @@
+# Read-Through Cache
+
+At high traffic, repeatedly querying the same data — blog posts, product listings, settings, categories — generates redundant database round-trips. A page with 10,000 daily visitors reading the same 50 posts means 10,000 identical `SELECT` queries.
+
+ODAC's **Read-Through Cache** solves this by caching `SELECT` results in `Odac.Ipc` and serving subsequent requests from memory. The only change to your code is adding `.cache()` to the chain.
+
+```javascript
+// Without cache — 1 DB query per request
+const posts = await Odac.DB.posts.where('active', true).select('id', 'title')
+
+// With cache — 1 DB query per TTL window, for all requests combined
+const posts = await Odac.DB.posts.cache(60).where('active', true).select('id', 'title')
+```
+
+---
+
+## How It Works
+
+**Architecture: Ipc-Backed, Driver-Agnostic**
+
+All cached data is stored in `Odac.Ipc`. The active IPC driver determines the scaling model:
+
+| Driver | Scope | When to use |
+|---|---|---|
+| `memory` (default) | Single machine — all workers share cache via Primary process | Single-server deployments |
+| `redis` | Multi-machine — all servers share cache in Redis | Horizontal scaling behind a load balancer |
+
+```
+// Memory driver (default)
+Worker 1 ─┐
+Worker 2 ─┼──→ Primary (Ipc memory store) ← cache HIT: O(1) return
+Worker N ─┘                                ← cache MISS: DB query → store → return
+
+// Redis driver
+Server A ─┐
+Server B ─┼──→ Redis (Ipc state) ← shared cache across all servers
+Server C ─┘
+```
+
+**Cache Key Generation**
+
+Each query is identified by a SHA-256 hash of its compiled SQL and bindings. Two identical queries — regardless of which worker or server generates them — always resolve to the same cache key.
+
+```
+rc:{connection}:{table}:{sha256(sql + bindings)}
+```
+
+**Automatic Invalidation**
+
+Any `insert()`, `update()`, `delete()`, or `truncate()` on a table automatically purges all cached queries for that table. You never need to manually invalidate after a write — ODAC handles it.
+
+```javascript
+// This update automatically clears all cached queries on the 'posts' table
+await Odac.DB.posts.where({id: 5}).update({title: 'New Title'})
+```
+
+**Cross-Table Invalidation (JOIN queries)**
+
+When a cached query includes `JOIN` clauses, ODAC automatically registers the cache key in all joined tables' indexes. This means a write to any table involved in the query triggers invalidation.
+
+```javascript
+// This query is registered in BOTH 'posts' and 'users' cache indexes
+const data = await Odac.DB.posts
+  .cache(60)
+  .join('users', 'posts.user_id', '=', 'users.id')
+  .select('posts.title', 'users.name')
+
+// Writing to 'users' invalidates the cached join query above — no stale data
+await Odac.DB.users.where({id: 1}).update({name: 'New Name'})
+```
+
+This works with `join()`, `leftJoin()`, `rightJoin()`, and aliased tables (`users as u`).
+
+---
+
+## Basic Usage
+
+### Cache with TTL
+
+Pass a TTL (in seconds) to `.cache()`. The result is served from cache for that duration, then re-fetched from the database on the next request.
+
+```javascript
+// Cache for 60 seconds
+const posts = await Odac.DB.posts.cache(60).where('active', true).select('id', 'title')
+
+// Cache for 5 minutes (default TTL from config)
+const post = await Odac.DB.posts.cache().where({id: 5}).first()
+
+// Cache a count
+const total = await Odac.DB.posts.cache(300).where('active', true).count()
+```
+
+### Named Connections
+
+```javascript
+// Default connection
+const posts = await Odac.DB.posts.cache(60).select('id', 'title')
+
+// Named connection: 'analytics'
+const stats = await Odac.DB.analytics.events.cache(120).where('date', today).select()
+```
+
+---
+
+## Manual Invalidation
+
+### Table-Level Clear
+
+Purge all cached queries for a table:
+
+```javascript
+// Via table proxy
+await Odac.DB.posts.cache.clear()
+
+// Via global accessor (useful in background jobs or service classes)
+await Odac.DB.cache.clear('default', 'posts')
+
+// Named connection
+await Odac.DB.cache.clear('analytics', 'events')
+```
+
+---
+
+## Automatic Invalidation on Write
+
+You do not need to call `.cache.clear()` after writes. ODAC intercepts all write operations on the proxy and invalidates the table cache automatically.
+
+| Operation | Cache invalidated? |
+|---|---|
+| `insert()` | ✅ Yes |
+| `update()` | ✅ Yes |
+| `delete()` | ✅ Yes |
+| `del()` | ✅ Yes |
+| `truncate()` | ✅ Yes |
+| `buffer.insert()` | ❌ No — buffer writes are deferred; invalidate manually if needed |
+
+> **Note on `buffer` + `cache`:** If you use the Write-Behind Cache (`buffer`) alongside the Read-Through Cache, the buffer's deferred writes do not trigger automatic invalidation. Call `Odac.DB.posts.cache.clear()` after a `buffer.flush()` if you need the cache to reflect the latest state immediately.
+
+---
+
+## Configuration
+
+Add a `cache` section to your `odac.json`:
+
+```json
+{
+  "cache": {
+    "ttl": 300,
+    "maxKeys": 10000
+  }
+}
+```
+
+| Option | Default | Description |
+|---|---|---|
+| `ttl` | `300` | Default cache duration in seconds when `.cache()` is called without an argument |
+| `maxKeys` | `10000` | Maximum number of cached query keys per table. New entries are skipped once the limit is reached — protects against unbounded memory growth |
+
+---
+
+## Horizontal Scaling
+
+To share cache state across multiple servers, switch the `ipc` driver to `redis`:
+
+```json
+{
+  "ipc": {
+    "driver": "redis",
+    "redis": "default"
+  }
+}
+```
+
+With the Redis driver active, all servers share the same cache. A cache invalidation triggered by a write on Server A is immediately visible to Server B. No code changes are required in your application.
+
+---
+
+## When to Use (and Not Use)
+
+**Use Read-Through Cache for:**
+- Blog posts, articles, product listings
+- Navigation menus, category trees, tag lists
+- Site settings, feature flags, configuration values
+- Any data that is read frequently and changes infrequently
+
+**Do not use for:**
+- Data that must always reflect the latest DB state (e.g., account balances, inventory counts)
+- Queries with user-specific filters where caching would leak data across users
+- Queries inside transactions where consistency is critical
+
+> [!TIP]
+> Combine with the Write-Behind Cache for maximum throughput: use `.buffer` for high-frequency writes (view counters, last-active timestamps) and `.cache()` for high-frequency reads (post listings, settings). They operate independently and complement each other.
+
+---
+
+## Guarantees
+
+| Scenario | Behaviour |
+|---|---|
+| Cache MISS | DB query executes, result is stored in Ipc with TTL |
+| Cache HIT | Result returned from Ipc — no DB query |
+| TTL expired | Next request triggers a fresh DB query and re-caches |
+| `insert/update/delete` | All cached queries for that table are purged automatically |
+| Worker crash | No data loss — cache state is in Primary process (memory) or Redis |
+| `maxKeys` reached | New cache entries are skipped; existing entries still served |
+| Ipc not initialized | Invalidation is a no-op — safe for environments without Ipc setup |

package/docs/backend/10-authentication/01-authentication-basics.md

@@ -0,0 +1,53 @@
+## 🔐 Authentication Basics
+
+The `Odac.Auth` service is your bouncer, managing who gets in and who stays out. It handles user login sessions for you.
+
+#### Letting a User In
+
+`Odac.Auth.login(userId, userData)`
+
+*   `userId`: A unique ID for the user (like their database ID).
+*   `userData`: An object with any user info you want to remember, like their username or role.
+
+When you call this, `Auth` creates a secure session for the user.
+
+> **💡 Enterprise Security:** ODAC automatically handles **Token Rotation** every 15 minutes (configurable) and includes built-in **CSRF protection** for all forms. Sessions are persistent across browser restarts by default.
+
+#### Checking the Guest List
+
+*   `await Odac.Auth.check()`: Is the current user logged in? Returns `true` or `false`.
+*   `Odac.Auth.user()`: Gets the full user object of the logged-in user.
+*   `Odac.Auth.user('id')`: Gets a specific field from the user object (e.g., their ID).
+*   `Odac.Auth.token()`: Gets the full auth session record from the token table.
+*   `Odac.Auth.token('id')`: Gets the auth session ID from the token table.
+
+#### Showing a User Out
+
+*   `Odac.Auth.logout()`: Ends the user's session and logs them out.
+
+#### Example: A Login Flow
+```javascript
+// Controller for your login form
+module.exports = async function (Odac) {
+    const { username, password } = Odac.Request.post
+
+    const loginSuccess = await Odac.Auth.login({ username, password })
+
+    if (loginSuccess) {
+        return Odac.direct('/dashboard')
+    } else {
+        return Odac.direct('/login?error=1')
+    }
+}
+
+// A protected dashboard page
+module.exports = async function (Odac) {
+    if (!await Odac.Auth.check()) {
+        return Odac.direct('/login')
+    }
+
+    const username = Odac.Auth.user('username')
+    const authId = Odac.Auth.token('id')  // Auth session ID from token table
+    return `Welcome back, ${username}! (Session: ${authId})`
+}
+```

package/docs/backend/10-authentication/05-session-management.md

@@ -148,11 +148,20 @@ const isLoggedIn = await Odac.Auth.check()
 
 **Get user info:**
 ```javascript
-const user = Odac.Auth.user(null)  // Full user object
-const user = Odac.Auth.user(null)  // Full user object
-const email = Odac.Auth.user('email')  // Specific field
+const user = Odac.Auth.user()          // Full user object
+const email = Odac.Auth.user('email')  // Specific user field
 ```
 
+**Get auth session record:**
+```javascript
+const authRecord = Odac.Auth.token()       // Full token record from auth table
+const authId = Odac.Auth.token('id')       // Auth session ID
+const sessionIp = Odac.Auth.token('ip')    // IP address of the session
+const sessionDate = Odac.Auth.token('date') // When the session was created
+```
+
+> **Note:** `token()` returns `false` if no active session exists. It is populated after a successful `check()` call.
+
 ### Custom Session Data
 
 If you need to store your own data in the session (e.g. shopping cart ID, preferences), use the `Odac.session()` helper:

package/docs/backend/13-utilities/01-odac-var.md

@@ -8,9 +8,6 @@
 // Create a Var instance
 const result = Odac.Var('hello world').slug()
 // Returns: 'hello-world'
-
-// Chain multiple operations
-const email = Odac.Var('  USER@EXAMPLE.COM  ').trim().toLowerCase()
 ```
 
 ### String Validation
@@ -47,19 +44,20 @@ Odac.Var('example.com').isAny('email', 'domain')       // true
 'alphaspace'         // Letters and spaces
 'alphanumeric'       // Letters and numbers
 'alphanumericspace'  // Letters, numbers, and spaces
-'bcrypt'             // BCrypt hash format
+'username'           // Alphanumeric only (no spaces)
+'hash'               // scrypt hash format ($scrypt$)
 'date'               // Valid date string
 'domain'             // Valid domain name (example.com)
 'email'              // Valid email address
 'float'              // Floating point number
-'host'               // IP address
+'host'               // IP address / Host
 'ip'                 // IP address
 'json'               // Valid JSON string
 'mac'                // MAC address
-'md5'                // MD5 hash
+'md5'                // 32-char MD5 hash
 'numeric'            // Numbers only
-'url'                // Valid URL
-'emoji'              // Contains emoji
+'url'                // Valid URL (protocol + domain)
+'emoji'              // Contains emoji characters
 'xss'                // XSS-safe (no HTML tags)
 ```
 
@@ -193,21 +191,18 @@ Odac.Var('<script>alert("xss")</script>').html()
 
 ### Encryption & Hashing
 
-#### hash() - BCrypt password hashing
+#### hash() - Secure scrypt password hashing
 
 ```javascript
-// Hash a password
+// Hash a password using enterprise-grade scrypt
 const hashedPassword = Odac.Var('mypassword').hash()
-// Returns: '$2b$10$...' (BCrypt hash)
-
-// Custom salt rounds
-const hashedPassword = Odac.Var('mypassword').hash(12)
+// Returns: '$scrypt$[salt]$[hash]'
 ```
 
-#### hashCheck() - Verify BCrypt hash
+#### hashCheck() - Verify scrypt hash
 
 ```javascript
-const hashedPassword = '$2b$10$...'
+const hashedPassword = '$scrypt$...'
 const isValid = Odac.Var(hashedPassword).hashCheck('mypassword')
 // Returns: true or false
 ```
@@ -498,7 +493,6 @@ module.exports = async function(Odac) {
 
 ### Notes
 
-- `Odac.Var()` returns the processed string value, not a Var instance (except for chaining)
-- Encryption uses AES-256-CBC with a fixed IV
-- BCrypt hashing is one-way and cannot be decrypted
+- Encryption uses AES-256-CBC with a fixed IV (defined in framework core).
+- scrypt hashing is one-way and computationally expensive to prevent brute-force.
 - Date formatting works with any valid JavaScript date string