jaz-clio 5.24.0 → 5.24.2

package/assets/skills/api/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jaz-api
-version: 5.24.0
+version: 5.24.2
 description: >-
   Use this skill whenever you call, debug, or review code that touches the Jaz
   REST API. Covers field names, response shapes, 158 production gotchas, error

package/assets/skills/cli/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jaz-cli
-version: 5.24.0
+version: 5.24.2
 description: >-
   Use this skill when running Clio CLI commands, building shell scripts with
   Clio, debugging auth issues, understanding --json output, paginating results,

package/assets/skills/conversion/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jaz-conversion
-version: 5.24.0
+version: 5.24.2
 description: >-
   Use this skill when migrating accounting data into Jaz — importing from Xero,
   QuickBooks, Sage, MYOB, or Excel exports. Covers the full conversion pipeline:

package/assets/skills/jaz-pseudo-sql/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jaz-pseudo-sql
-version: 5.24.0
+version: 5.24.2
 description: >-
   Use this skill when answering ad-hoc data questions that aren't covered by
   download_export (canonical reports — anomaly, audit, aging, P&L, BS, GL,

package/assets/skills/jobs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jaz-jobs
-version: 5.24.0
+version: 5.24.2
 description: >-
   Use this skill for recurring accounting workflows — month/quarter/year-end
   close, bank reconciliation, GST/VAT filing, payment runs, credit control,
@@ -75,6 +75,8 @@ Each per-job reference is a **phased checklist** of steps. Each step names:
 - **Verification check** — how to confirm the step was completed correctly
 - **Conditional flag** — steps that only apply in certain situations (e.g., "only if multi-currency org")
 
+Steps that carry real judgment (hold, defer, accept a variance, resume after a failure) also name the jot to record at that moment via the `jot` tool. Mechanical steps never do: a jot marks a choice among real alternatives, not activity.
+
 **For AI agents (hosted or CLI):** walk the phases in the per-job reference and call the named platform tools directly. Use the jaz-api skill for payload shapes.
 **For developers / scripts:** `clio jobs <type> --json` prints the phased checklist as JSON to drive automation pipelines.
 **For accountants:** use the formatted checklist (`clio jobs <type>`) to work through the close systematically.

package/assets/skills/jobs/references/bank-recon.md

@@ -84,6 +84,8 @@ search_bank_records(accountResourceId: B.resourceId, status: 'POSSIBLE_DUPLICATE
 
 Two bank-feed entries with same `valueDate + netAmount + description` = system-flagged duplicate. Review each pair: archive the duplicate via `archive_bank_record(resourceId: <id>)` BEFORE running step 4. If you reconcile a duplicated row, you'll create double cashflow entries.
 
+Record the judgment per archived pair: `jot(kind: MATCH)` naming the kept entry, the archived entry, and the tie-breaker used.
+
 ## Step 4 — Auto-match cascade
 
 For accounts with > ~10 unreconciled rows, use the cascade matcher first:
@@ -145,7 +147,7 @@ search_cashflow_transactions(
 )
 ```
 
-Widen `valueDate` ±7 days for bank processing delays. Match candidate found → invoke matching `reconcile_*` tool.
+Widen `valueDate` ±7 days for bank processing delays. Match candidate found → invoke matching `reconcile_*` tool. Record the judgment: `jot(kind: MATCH)` naming the bank entry, the matched transaction, and the basis (amount, date window, contact).
 
 ## Step 6 — Create missing transactions
 
@@ -204,7 +206,7 @@ Next month's same charge auto-reconciles via `apply_bank_rule`.
 search_bank_records(accountResourceId: B.resourceId, status: 'UNRECONCILED', limit: 1)
 ```
 
-Target: zero rows OR all remaining are documented timing differences (outstanding cheques, deposits in transit clearing next period — practitioner annotates).
+Target: zero rows OR all remaining are documented timing differences (outstanding cheques, deposits in transit clearing next period — practitioner annotates). Record the judgment: `jot(kind: SCOPE)` naming each residual accepted as a timing difference and why it clears next period.
 
 ```
 generate_bank_recon_summary(period_end: '2025-01-31', accountResourceId: B.resourceId)

package/assets/skills/jobs/references/month-end-close.md

@@ -209,7 +209,7 @@ Save both. Assert: BS Total Assets == Total Liabilities + Total Equity. P&L net
 
 ### Step 17 — Prior-month variance + draft gate
 
-Compare against the prior period's close trial balance. Surface to the user the top 3 deltas where `|delta| > materiality threshold`, descending magnitude, with a 1-line possible-explanation.
+Compare against the prior period's close trial balance. Surface to the user the top 3 deltas where `|delta| > materiality threshold`, descending magnitude, with a 1-line possible-explanation. When the practitioner accepts a variance as explained, record the judgment: `jot(kind: RISK)` naming the account, the delta, and the accepted explanation.
 
 ```
 search_journals(filter: {status: {eq: 'DRAFT'}, valueDate: {between: ['2025-01-01', '2025-01-31']}})
@@ -217,7 +217,7 @@ search_invoices(filter: {status: {eq: 'DRAFT'}, valueDate: {between: ['2025-01-0
 search_bills(filter: {status: {eq: 'DRAFT'}, valueDate: {between: ['2025-01-01', '2025-01-31']}})
 ```
 
-All three must return zero. If any rows: classify per practitioner judgment, then `bulk_finalize_drafts` for the keep-set OR delete via `delete_journal` / `delete_invoice` / `delete_bill`.
+All three must return zero. If any rows: classify per practitioner judgment, then `bulk_finalize_drafts` for the keep-set OR delete via `delete_journal` / `delete_invoice` / `delete_bill`. Record the judgment: `jot(kind: SCOPE)` naming which drafts were finalized, which were deleted, and the rule applied.
 
 ## Phase 5 — Lock
 
@@ -229,6 +229,8 @@ update_account(resourceId: <CoA root>, lockDate: '2025-01-31')
 
 Locks the period — prevents accidental backdated entries. Move forward only. Reverse only if posting corrections (and re-lock immediately after).
 
+If residuals were documented at steps 3 or 17, record the judgment after the lock lands: `jot(kind: RISK)` naming the residuals carried into the locked period.
+
 ---
 
 ## Common error classes and recovery

package/assets/skills/jobs/references/payment-run.md

@@ -84,6 +84,8 @@ For each `bankAccountResourceId` you'll pay from: confirm `availableBalance >= s
 
 Apply the org's cash-buffer policy (default: 14 days operating expenses) — never drain to zero. Compute buffer-required from last 30 days' opex via `generate_profit_and_loss(period_start: <-30d>, period_end: <today>)`.
 
+Record the judgment: `jot(kind: SCOPE)` naming the deferred bills and the cash-buffer rule applied.
+
 ## Step 6 — Record payments
 
 For each approved bill (one POST per bill — no batch endpoint):
@@ -140,7 +142,7 @@ Assert: per-account balance reduced by `sum(paymentAmount per accountResourceId)
 | `create_bill_payment` | 422 `currency_mismatch` | `paymentAmount` currency ≠ bank account currency. Either pay from the matching-currency bank account, or model as FX (different `paymentAmount` and `transactionAmount`). |
 | `create_bill_payment` | 422 `bill_already_paid` | Bill went `PAID` since step 2. Re-run `search_bills` for fresh state; remove from batch. |
 | `create_bill_payment` | 422 `lock_date_violated` | `valueDate` is in a locked period. Either lift the lock via `update_account` lock_date OR adjust `valueDate` to the next open period. |
-| `create_bill_payment` | 500 mid-run | Some payments succeeded; others didn't. NOT idempotent — re-running the loop creates duplicates. Use `search_payments` with the run prefix to identify what succeeded; resume from the next unprocessed bill. |
+| `create_bill_payment` | 500 mid-run | Some payments succeeded; others didn't. NOT idempotent — re-running the loop creates duplicates. Use `search_payments` with the run prefix to identify what succeeded; resume from the next unprocessed bill. Record the judgment: `jot(kind: RECOVERY)` naming the resume point and the bills already paid. |
 | `generate_aged_ap` | Total mismatch with `search_bills` | Likely `PARTIALLY_PAID` bills excluded from `search_bills` filter. Add `status: {in: ['UNPAID', 'PARTIALLY_PAID']}` and retry. |
 
 ---

package/assets/skills/transaction-recipes/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jaz-recipes
-version: 5.24.0
+version: 5.24.2
 description: >-
   Use this skill when modeling complex multi-step accounting transactions —
   anything that spans multiple periods, involves changing amounts, or requires
@@ -63,6 +63,8 @@ Jaz schedulers generate **fixed-amount** recurring entries. This determines whic
 - **Variable amounts each period** → Use manual journals inside a capsule (calculated per period)
 - **One-off or two-entry events** → Use manual journals (e.g., dividend declaration + payment)
 
+If a scenario genuinely fits either pattern, record the pick once the entries post: `jot(kind: METHOD)` naming the pattern chosen and the deciding fact.
+
 | Recipe | Pattern | Why |
 |---|---|---|
 | Prepaid Amortization | Scheduler + capsule | Same amount each month |
@@ -132,7 +134,7 @@ Each recipe includes: scenario description, accounts involved, journal entries,
 1. **Read the recipe** for your scenario — understand the accounts, journal entries, and capsule structure.
 2. **Create the accounts** listed in the "Accounts Involved" table (if they don't already exist in the CoA).
 3. **Create the capsule** with an appropriate capsule type.
-4. **Run the calculator** (if available) to generate exact amounts: `clio calc <command> --json` gives you a complete blueprint.
+4. **Run the calculator** (if available) to generate exact amounts: `clio calc <command> --json` gives you a complete blueprint. Where you picked the method yourself (e.g. `--method ddb` over `sl`), record the judgment after the entries post: `jot(kind: METHOD)` naming the method and why.
 5. **Record the initial transaction** (bill, invoice, or journal) — assign it to the capsule.
 6. **For scheduler recipes**: Create the scheduler with the same capsule — it generates all subsequent entries automatically.
 7. **For manual journal recipes**: Record each period's journal using the calculator output or worked example, always assigning to the same capsule.
@@ -144,6 +146,8 @@ The `jaz-clio` CLI includes 13 IFRS-compliant financial calculators. Each produc
 
 All calculators support `--currency <code>` and `--json`.
 
+Inputs the data does not hand you (loss rates, discount rate, salvage value, useful life) are assumptions: once the entries post, lock each with `jot(kind: ASSUMPTION)` naming the value and its source.
+
 Each calculator has a typical context — see the line after each command for the operational workflow that typically invokes it.
 
 ```bash
@@ -317,7 +321,7 @@ See `jaz-api` Rule 143 (silent-null failure mode + diagnosis sequence), Rule 144
 
 1. **Re-run `preview_capsule_recipe`** with the same `recipeName` + `inputs`. The 422 you get back is the exact reason the trigger mutation silently nulled. Fix the input and retry.
 2. **Poll `search_background_jobs --filter '{"baseTransactionResourceId":{"eq":"<id>"}}'`** — if a `FAILED` job exists, `errorDetails` has the publish failure. If no job exists, the publish never queued (validation rejected pre-queue).
-3. **Job status `FAILED`** → `resume_capsule_recipe` (≤3 attempts) OR `rollback_capsule_recipe(dryRun=true)` first, then `rollback_capsule_recipe(dryRun=false)`.
+3. **Job status `FAILED`** → `resume_capsule_recipe` (≤3 attempts) OR `rollback_capsule_recipe(dryRun=true)` first, then `rollback_capsule_recipe(dryRun=false)`. Record the judgment: `jot(kind: RECOVERY)` naming resume or rollback and the basis.
 4. **Capsule wasn't created via the recipe engine** → rollback returns 422 `RECIPE_ROLLBACK_JOB_NOT_FOUND`; use `delete_capsule` for legacy capsules.
 
 **DO NOT** use server-side execution for `fx-reval` — Jaz auto-handles ALL period-end IAS 21.23 FX translation; double-posting risk identical to the offline `execute_recipe(recipe: 'fx-reval')` warning.