jaz-clio 5.4.16 → 5.4.18

package/assets/skills/api/SKILL.md

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

package/assets/skills/cli/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jaz-cli
-version: 5.4.16
+version: 5.4.18
 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.4.16
+version: 5.4.18
 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/jobs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jaz-jobs
-version: 5.4.16
+version: 5.4.18
 description: >-
   Use this skill for recurring accounting workflows — month/quarter/year-end
   close, bank reconciliation, GST/VAT filing, payment runs, credit control,

package/assets/skills/jobs/references/audit-prep.md

@@ -27,7 +27,7 @@
 - **`search_journals(filter: {status: {eq: 'DRAFT'}, valueDate: {between: [<FY-start>, <FY-end>]}})`** — step 12: must return zero rows before pack hand-off.
 - **`search_invoices(filter: {status: {eq: 'DRAFT'}, valueDate: {between: [<FY-start>, <FY-end>]}})`** — step 12: same gate, sales side.
 - **`search_bills(filter: {status: {eq: 'DRAFT'}, valueDate: {between: [<FY-start>, <FY-end>]}})`** — step 12: same gate, purchases side.
-- **`bulk_finalize_drafts({kind: 'journal', resourceIds: [...]})`** — step 12 fallback: clear residual drafts before pack hand-off.
+- **`update_journal(resourceId: <each id>, saveAsDraft: false)  // loop per id — no bulk-finalize-journals tool yet`** — step 12 fallback: clear residual drafts before pack hand-off.
 - **`update_account(resourceId: <CoA root>, lockDate: <FY-end>)`** — step 12 final: lock the period to prevent backdated entries during fieldwork.
 
 ### Calculators (cross-check schedules — no API key needed)
@@ -115,7 +115,7 @@ Use `endDate` not `startDate` (rule 36 — point-in-time snapshot). Assert:
 
 If ECL provision feels inadequate for the > 90d bucket, run the ECL recipe immediately:
 ```
-plan_recipe(name: 'ecl', receivables: <aged_ar.buckets converted to ECL input>, ...)
+plan_recipe(recipe: 'ecl', receivables: <aged_ar.buckets converted to ECL input>, ...)
 ```
 And post any top-up provision via `execute_recipe`. This avoids an auditor-proposed adjustment at fieldwork.
 
@@ -198,7 +198,7 @@ search_invoices(filter: {status: {eq: 'DRAFT'}, valueDate: {between: ['2025-01-0
 search_bills(filter: {status: {eq: 'DRAFT'}, valueDate: {between: ['2025-01-01', '2025-12-31']}})
 ```
 
-ALL three must return zero. If any return rows: collect `resourceId`s, classify (delete vs finalize) per practitioner judgment, and `bulk_finalize_drafts({kind, resourceIds: [...]})` for the keep-set.
+ALL three must return zero. If any return rows: collect `resourceId`s, classify (delete vs finalize) per practitioner judgment, and `update_<entity>(resourceId, saveAsDraft: false)  // per-id; bulk_finalize_drafts only supports invoice/bill/CN, not journal/cash` for the keep-set.
 
 Then lock the period:
 ```

package/assets/skills/jobs/references/building-blocks.md

@@ -54,8 +54,8 @@ Recipe engine creates ALL future-dated journals upfront as DRAFT (loan: 60 month
 
 Monthly action per recipe-managed capsule:
 ```
-search_journals(filter: {capsuleResourceId: <id>, valueDate: {between: [<period-start>, <period-end>]}, status: {eq: 'DRAFT'}})
-bulk_finalize_drafts({kind: 'journal', resourceIds: [<this period's pre-emitted journal>]})
+search_journals(filter: {capsuleResourceId: {eq: <id>}, valueDate: {between: [<period-start>, <period-end>]}, status: {eq: 'DRAFT'}})
+update_journal(resourceId: <this period's pre-emitted journal>, saveAsDraft: false)
 ```
 
 For Jaz-scheduler-driven recurrences (`create_scheduled_journal`, `create_scheduled_invoice`, `create_scheduled_bill`, subscriptions): scheduler templates auto-fire and create new ACTIVE entries each period. Different primitive — the recipe engine doesn't use these.

package/assets/skills/jobs/references/credit-control.md

@@ -9,10 +9,10 @@
 - **`generate_aged_ar(period_end: <date>)`** — step 1: AR aging report with bucket breakdown.
 - **`search_invoices(filter: {status: {eq: 'UNPAID'}, dueDate: {lt: <date>}, contactResourceId: <customer>}, sort: 'dueDate:asc', limit: 200)`** — step 2: per-customer overdue detail. Paginate.
 - **`get_contact(resourceId: <customer id>)`** — step 2: pull contact info (email, phone, primary contact).
-- **`get_contact_signals(contactResourceId: <id>, businessTransactionType: 'SALE')`** — step 3: pull cadence + outlier signals + outstanding balance for the customer. Mid-7 endpoint.
+- **`get_contact_signals(resourceId: <id>, btType: 'SALE')`** — step 3: pull cadence + outlier signals + outstanding balance for the customer. Mid-7 endpoint.
 - **`apply_credit_to_invoice(...)`** / **`create_customer_credit_note(...)`** — step 6: write-off path A for stage-3 specific impairment.
 - **`create_invoice_payment(... paymentMethod: 'DEBT_WRITE_OFF' ...)`** — step 6: write-off path B (direct).
-- **`plan_recipe(name: 'ecl', ...)` + `execute_recipe(...)`** — step 7: ECL collective top-up if material change in aging.
+- **`plan_recipe(recipe: 'ecl', ...)` + `execute_recipe(...)`** — step 7: ECL collective top-up if material change in aging.
 - **`download_export(exportType: 'analysis-receivables-customer-risk', startDate, endDate)`** — step 8: pre-empt audit by surfacing high-risk customers.
 
 ### Cross-references
@@ -61,7 +61,7 @@ For each customer build a chase record: `{customerName, totalOverdue, oldestDays
 ## Step 3 — Contact-signals pull (Mid-7)
 
 ```
-get_contact_signals(contactResourceId: <customer id>, businessTransactionType: 'SALE')
+get_contact_signals(resourceId: <customer id>, btType: 'SALE')
 ```
 
 Returns: `{ cadence, outlierFlags[], severitySummary, patternDivergenceFlags, outstandingSnapshot, revealedPatterns[] }`. High-signal data for collection prioritization:
@@ -148,9 +148,9 @@ clio calc ecl --current <c> --30d <30> --60d <60> --90d <90> --120d <120> --rate
 
 If `topUpRequired > CLIENT.materiality_threshold`:
 ```
-plan_recipe(name: 'ecl', ..., capsuleResourceId: <credit-control capsule OR new ECL Provision capsule>)
+plan_recipe(recipe: 'ecl', ..., capsuleResourceId: <credit-control capsule OR new ECL Provision capsule>)
 execute_recipe(...)
-bulk_finalize_drafts({kind: 'journal', resourceIds: [...]})
+bulk_finalize_drafts({kind: 'journal'}, resourceIds: [...]})
 ```
 
 Note: monthly ECL is typically a mental check; formal ECL provision recompute is quarterly (per `quarter-end-close.md` Q2). Trigger this monthly only on material shifts.
@@ -170,7 +170,7 @@ Returns XLSX with high-risk customer flags (rising aging trends, recently-defaul
 | Source | Error | Recovery |
 |--------|-------|----------|
 | Step 2 | `search_invoices` returns 0 despite aging shows overdue | Aging report may include `PARTIALLY_PAID` invoices; expand filter `status: {in: ['UNPAID', 'PARTIALLY_PAID']}`. |
-| Step 3 | `get_contact_signals` returns `{ unavailable: true }` | The freshness layer is offline; skip the signals step and use aging alone. Don't halt the job. |
+| Step 3 | `get_contact_signals` returns `null` | The freshness layer is offline; skip the signals step and use aging alone. Don't halt the job. |
 | Step 6 Path A | `apply_credit_to_invoice` 422 `credit_exceeds_balance` | Split the credit across multiple invoices, OR reduce the credit amount to match the bill balance. |
 | Step 6 Path B | `paymentMethod: 'DEBT_WRITE_OFF'` rejected | Verify the enum value via `jaz-api/SKILL.md` (some orgs may have custom payment-method config; default supports DEBT_WRITE_OFF). |
 | Step 7 ECL recipe | Top-up causes Bad Debt Expense to spike | Expected — material aging shift = material P&L impact. Surface to practitioner; potentially split across multiple periods if it's a known one-off (rare). |

package/assets/skills/jobs/references/fa-review.md

@@ -12,8 +12,8 @@
 - **`generate_fa_recon_summary(period_start: <year-start>, period_end: <year-end>)`** — step 3: reconcile movement (opening + additions − disposals − depreciation = closing).
 - **`generate_general_ledger(accountResourceId: <FA category GL>, period_start, period_end)`** — step 4: per-FA-category GL movement vs FA register.
 - **`update_fixed_asset(resourceId: <id>, status: 'DISPOSED' | 'WRITTEN_OFF', disposalDate, disposalProceeds)`** — step 5: status updates for disposals. Mirror endpoints `POST /api/v1/mark-as-sold/fixed-assets` (sale) / `POST /api/v1/discard-fixed-assets/{id}` (scrap).
-- **`plan_recipe(name: 'asset-disposal', ...)` + `execute_recipe(...)`** — step 5: invoke per disposal identified during review (per `asset-disposal.md` recipe).
-- **`bulk_finalize_drafts({kind: 'journal', resourceIds: [...]})`** — step 5 / 6: finalize disposal journals + any pending DDB / 150DB depreciation DRAFTs from `declining-balance.md` recipe.
+- **`plan_recipe(recipe: 'asset-disposal', ...)` + `execute_recipe(...)`** — step 5: invoke per disposal identified during review (per `asset-disposal.md` recipe).
+- **`update_journal(resourceId: <each id>, saveAsDraft: false)  // loop per id — no bulk-finalize-journals tool yet`** — step 5 / 6: finalize disposal journals + any pending DDB / 150DB depreciation DRAFTs from `declining-balance.md` recipe.
 
 ### Calculators (cross-check, no API key needed)
 - **`clio calc depreciation --cost --salvage --life --method --frequency annual --json`** — step 4 per-asset cross-check.
@@ -71,8 +71,8 @@ For each ACTIVE SL asset (Jaz auto-depreciates):
 - Should match within rounding ($0.12 tolerance for full-year SL).
 
 For each ACTIVE DDB / 150DB asset (recipe-managed, see `declining-balance.md`):
-- Per capsule: `search_journals(filter: {capsuleResourceId: <dep capsule>, valueDate: {between: [<year-start>, <year-end>]}, status: 'DRAFT'})`. Should be zero — all 12 months' DRAFT depreciation journals should already be FINALIZED via monthly-close.
-- If non-zero: `bulk_finalize_drafts({kind: 'journal', resourceIds: [...]})` for each remaining DRAFT.
+- Per capsule: `search_journals(filter: {capsuleResourceId: {eq: <dep capsule>}, valueDate: {between: [<year-start>, <year-end>]}, status: 'DRAFT'})`. Should be zero — all 12 months' DRAFT depreciation journals should already be FINALIZED via monthly-close.
+- If non-zero: `update_journal(resourceId: <each id>, saveAsDraft: false)  // loop per id — no bulk-finalize-journals tool yet` for each remaining DRAFT.
 
 Cross-check via `clio calc depreciation --frequency annual --json` per asset; auditor will sample-test.
 
@@ -82,7 +82,7 @@ For each disposal identified in step 2:
 
 ```
 plan_recipe(
-  name: 'asset-disposal',
+  recipe: 'asset-disposal',
   cost, salvageValue, usefulLifeYears, acquisitionDate, disposalDate, proceeds, method,
   ...,
   fixedAssetResourceId: <asset id>,
@@ -90,7 +90,7 @@ plan_recipe(
   capsuleName: 'Disposal — <asset name> — <disposal date>'
 )
 execute_recipe(...)
-bulk_finalize_drafts({kind: 'journal', resourceIds: [<disposal journal id>]})
+update_journal(resourceId: <disposal journal id>, saveAsDraft: false)
 ```
 
 Then the manual FA-register status update (engine-skipped — see `asset-disposal.md` step 5):

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

@@ -12,13 +12,13 @@
 - **`generate_aged_ar(period_end: <date>)` / `generate_aged_ap(period_end: <date>)`** — steps 4-5: aging reports tied to TB AR / AP balances.
 
 ### MCP tools — accruals + valuations
-- **`plan_recipe(name: 'accrued-expense', ...)` / `execute_recipe(...)`** — step 6: per `CLIENT.recurring_accruals[]` whose `last_posted < period_end`.
-- **`plan_recipe(name: 'prepaid-expense', ...)`** — step 7: only for new prepaid setup; ongoing recognition runs from the scheduler created at setup.
-- **`plan_recipe(name: 'deferred-revenue', ...)`** — step 8: same setup-vs-recognition note as prepaid.
-- **`plan_recipe(name: 'depreciation', ...)`** — step 9: only when an asset uses non-SL method (DDB, 150DB) — Jaz native FA handles SL automatically. Verify FA register first.
-- **`plan_recipe(name: 'leave-accrual', ...)` / `execute_recipe(...)`** — step 10: monthly leave accrual; the engine creates the scheduler so it auto-fires next month.
-- **FX revaluation** — step 12: **Jaz auto-handles**. The recipe is verification-only via `clio calc fx-reval`; do NOT invoke `execute_recipe(name: 'fx-reval', ...)` (would double-post).
-- **`plan_recipe(name: 'ecl', ...)`** — step 13: top-up bad-debt provision based on `generate_aged_ar` buckets.
+- **`plan_recipe(recipe: 'accrued-expense', ...)` / `execute_recipe(...)`** — step 6: per `CLIENT.recurring_accruals[]` whose `last_posted < period_end`.
+- **`plan_recipe(recipe: 'prepaid-expense', ...)`** — step 7: only for new prepaid setup; ongoing recognition runs from the scheduler created at setup.
+- **`plan_recipe(recipe: 'deferred-revenue', ...)`** — step 8: same setup-vs-recognition note as prepaid.
+- **`plan_recipe(recipe: 'depreciation', ...)`** — step 9: only when an asset uses non-SL method (DDB, 150DB) — Jaz native FA handles SL automatically. Verify FA register first.
+- **`plan_recipe(recipe: 'leave-accrual', ...)` / `execute_recipe(...)`** — step 10: monthly leave accrual; the engine creates the scheduler so it auto-fires next month.
+- **FX revaluation** — step 12: **Jaz auto-handles**. The recipe is verification-only via `clio calc fx-reval`; do NOT invoke `execute_recipe(recipe: 'fx-reval', ...)` (would double-post).
+- **`plan_recipe(recipe: 'ecl', ...)`** — step 13: top-up bad-debt provision based on `generate_aged_ar` buckets.
 
 ### MCP tools — reconciliation execution
 - **`view_auto_reconciliation(bankAccountResourceId: <id>)`** — step 3: READ-ONLY suggestions (does NOT write).
@@ -30,7 +30,7 @@
 - **`generate_profit_and_loss(period_start, period_end)`** — step 15.
 - **`generate_balance_sheet(period_end)`** — step 16.
 - **`search_journals(filter: {status: 'DRAFT', valueDate: {between: [<period-start>, <period-end>]}})`** — step 17: gate on zero drafts.
-- **`bulk_finalize_drafts({kind: 'journal', resourceIds: [...]})`** — step 17: clear residual drafts before lock.
+- **`update_journal(resourceId: <each id>, saveAsDraft: false)  // loop per id — no bulk-finalize-journals tool yet`** — step 17: clear residual drafts before lock.
 - **`update_account(resourceId: <CoA root>, lockDate: <period-end>)`** — step 18: lock the period.
 
 ### Calculators (cross-check, no API key needed)
@@ -103,11 +103,11 @@ For each `CLIENT.recurring_accruals[]` where `last_posted < '2025-01-31'`:
 
 1. Compute amount per `estimation_method` (`prior_month` via `search_journals`, `trailing_3m_avg`, `budget`, `fixed_amount`).
 2. Cross-check: `clio calc accrued-expense --amount <computed> --periods 1 --json`.
-3. `plan_recipe(name: 'accrued-expense', amount: <computed>, glAccount: <CLIENT.recurring_accruals[i].gl_account>, vendor: <CLIENT.recurring_accruals[i].vendor>, valueDate: '2025-01-31', reversalDate: '2025-02-01')`.
+3. `plan_recipe(recipe: 'accrued-expense', amount: <computed>, glAccount: <CLIENT.recurring_accruals[i].gl_account>, vendor: <CLIENT.recurring_accruals[i].vendor>, valueDate: '2025-01-31', reversalDate: '2025-02-01')`.
 4. Resolve `requiredAccounts` + `needsContact` (search/create as needed).
 5. `execute_recipe(...)`. Engine emits dual-entry accrual + reversal scheduler.
 6. `validate_journal_draft(resourceId: <id>)` for each draft journal.
-7. After all accruals processed: `bulk_finalize_drafts({kind: 'journal', resourceIds: [...]})`.
+7. After all accruals processed: `update_journal(resourceId: <each id>, saveAsDraft: false)  // loop per id — no bulk-finalize-journals tool yet`.
 
 Cross-check: `generate_trial_balance(period_end: '2025-01-31')`. Sum credit movements against accrual liability accounts. Verify `|sum - expected| ≤ CLIENT.materiality_threshold`.
 
@@ -117,12 +117,12 @@ For each existing `Prepaid Expenses` capsule (via `search_capsules(filter: {caps
 
 1. `search_journals(filter: {capsuleResourceId: {eq: <capsule.id>}, valueDate: {between: ['2025-01-01', '2025-01-31']}, status: {eq: 'DRAFT'}})`. The recipe pre-emitted this period's recognition journal as DRAFT at recipe-execution time.
 2. If empty: either the recipe was set up wrong (no journal for this period — investigate via `search_journals` without status filter to see if it's already ACTIVE, then skip), OR the practitioner went off-recipe. Surface to practitioner.
-3. If found: collect resourceIds, then `bulk_finalize_drafts({kind: 'journal', resourceIds: [...]})`.
-4. New prepaid setups during this period (a new prepaid started this month): invoke `plan_recipe(name: 'prepaid-expense', ...)` per `prepaid-amortization.md` — this creates the bill + N future-dated DRAFT journals; the current period's journal is then in the bulk_finalize_drafts queue above.
+3. If found: collect resourceIds, then `update_journal(resourceId: <each id>, saveAsDraft: false)  // loop per id — no bulk-finalize-journals tool yet`.
+4. New prepaid setups during this period (a new prepaid started this month): invoke `plan_recipe(recipe: 'prepaid-expense', ...)` per `prepaid-amortization.md` — this creates the bill + N future-dated DRAFT journals; the current period's journal is then in the bulk_finalize_drafts queue above.
 
 ### Step 8 — Deferred revenue recognition
 
-Mirror of step 7. Existing `Deferred Revenue` capsules: search for this period's DRAFT journal in each, then `bulk_finalize_drafts`. New deferred setups: `plan_recipe(name: 'deferred-revenue', ...)` then handle the current period's journal in the same bulk_finalize.
+Mirror of step 7. Existing `Deferred Revenue` capsules: search for this period's DRAFT journal in each, then `bulk_finalize_drafts`. New deferred setups: `plan_recipe(recipe: 'deferred-revenue', ...)` then handle the current period's journal in the same bulk_finalize.
 
 ### Step 9 — Depreciation
 
@@ -130,14 +130,14 @@ Mirror of step 7. Existing `Deferred Revenue` capsules: search for this period's
 search_fixed_assets(filter: {status: {eq: 'ACTIVE'}, depreciationMethod: {in: ['ddb', '150db']}})
 ```
 
-For Jaz-native SL assets: depreciation auto-posts; verify via `generate_fa_summary(period_end: '2025-01-31')` showing month's depreciation movement. For non-SL methods returned above: `plan_recipe(name: 'depreciation', method: 'ddb' | '150db', cost, salvage, life, ...)` per asset, then `execute_recipe`.
+For Jaz-native SL assets: depreciation auto-posts; verify via `generate_fa_summary(period_end: '2025-01-31')` showing month's depreciation movement. For non-SL methods returned above: `plan_recipe(recipe: 'depreciation', method: 'ddb' | '150db', cost, salvage, life, ...)` per asset, then `execute_recipe`.
 
 ### Step 10 — Employee benefit accruals
 
 If `CLIENT.headcount > 0` and `CLIENT.tracks_leave_balances == true`:
 
 ```
-plan_recipe(name: 'leave-accrual', headcount: <CLIENT.headcount>, daysPerEmployee: <CLIENT.leave_days_per_year>, dailyRate: <avg-daily-rate>, startDate: '2025-01-01', termMonths: 12)
+plan_recipe(recipe: 'leave-accrual', headcount: <CLIENT.headcount>, daysPerEmployee: <CLIENT.leave_days_per_year>, dailyRate: <avg-daily-rate>, startDate: '2025-01-01', termMonths: 12)
 ```
 
 On first month of FY only — engine creates the scheduler and posts the first accrual. Subsequent months: scheduler emits automatically. Cross-check via `clio calc leave-accrual`.
@@ -148,16 +148,16 @@ For each active loan capsule (via `search_capsules(filter: {capsuleType: {eq: 'L
 
 1. `search_journals(filter: {capsuleResourceId: {eq: <loan-capsule-id>}, valueDate: {between: ['2025-01-01', '2025-01-31']}, status: {eq: 'DRAFT'}})`. The `loan` recipe pre-emitted all `termMonths` future-dated DRAFT journals at execution time — this period's repayment is one of them.
 2. Should return exactly one DRAFT journal per active loan. Each is a 3-line entry (debit Loan Payable, debit Interest Expense, credit Cash) with the correct amortization split for the period.
-3. Collect resourceIds, then `bulk_finalize_drafts({kind: 'journal', resourceIds: [...]})`.
+3. Collect resourceIds, then `update_journal(resourceId: <each id>, saveAsDraft: false)  // loop per id — no bulk-finalize-journals tool yet`.
 4. Do NOT post manual loan-interest accruals — the recipe already emitted the journal with the correct split per `clio calc loan` schedule.
 
-If a loan was newly disbursed this period: invoke `plan_recipe(name: 'loan', ...)` then `execute_recipe`; the disbursement (cash-in) and this period's repayment journal are both included in the engine output.
+If a loan was newly disbursed this period: invoke `plan_recipe(recipe: 'loan', ...)` then `execute_recipe`; the disbursement (cash-in) and this period's repayment journal are both included in the engine output.
 
 ## Phase 3 — Valuations
 
 ### Step 12 — FX revaluation (verification only — Jaz auto-handles)
 
-**Jaz auto-handles FX revaluation for ALL foreign-currency monetary balances** (AR, AP, cash, bank, intercompany journals, term deposits, FX provisions). Period-end translation per IAS 21.23 happens inside the platform automatically. **DO NOT invoke `execute_recipe(name: 'fx-reval', ...)` — would double-post.**
+**Jaz auto-handles FX revaluation for ALL foreign-currency monetary balances** (AR, AP, cash, bank, intercompany journals, term deposits, FX provisions). Period-end translation per IAS 21.23 happens inside the platform automatically. **DO NOT invoke `execute_recipe(recipe: 'fx-reval', ...)` — would double-post.**
 
 This step is a verification cross-check. If `CLIENT.multi_currency == true`:
 
@@ -183,7 +183,7 @@ Per memory rule [Bank FX is Revaluation, not Realized]: bank/cash FX uses `FX Ba
 Mental check on AR aging > 90d bucket changes. If material change vs prior month: invoke ECL recipe.
 
 ```
-plan_recipe(name: 'ecl', receivables: <generate_aged_ar.buckets>, ratesPerBucket: <CLIENT.ecl_rates>)
+plan_recipe(recipe: 'ecl', receivables: <generate_aged_ar.buckets>, ratesPerBucket: <CLIENT.ecl_rates>)
 ```
 
 For most SMBs, formal ECL adjustment runs in `quarter-end-close.md`. Skip in routine monthly close unless a major customer default / dispute occurred.

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

@@ -11,11 +11,11 @@
 ### MCP tools — quarterly extras
 - **`generate_vat_ledger(period_start: <Q-start>, period_end: <Q-end>)`** — Q1 GST/VAT filing prep: full quarterly tax ledger.
 - **`generate_aged_ar(period_end: <Q-end>)`** — Q2 ECL formal review input.
-- **`plan_recipe(name: 'ecl', ...)` + `execute_recipe(...)`** — Q2 ECL top-up if material.
+- **`plan_recipe(recipe: 'ecl', ...)` + `execute_recipe(...)`** — Q2 ECL top-up if material.
 - **`search_journals(filter: {tag: 'bonus-accrual', valueDate: {between: [<Q-start>, <Q-end>]}})`** — Q3 bonus YTD pull.
 - **`create_journal(...)`** — Q3 bonus true-up adjustment (manual one-off).
 - **`search_capsules(filter: {capsuleType: {eq: 'Intercompany'}})`** — Q4 IC reconciliation per pair of entities (multi-org coordination — see `intercompany.md` recipe).
-- **`search_capsules(filter: {capsuleType: {eq: 'Provisions'}})` + `bulk_finalize_drafts({kind: 'journal', resourceIds: [...]})`** — Q5 finalize each provision capsule's quarter-end DRAFT unwinding journals.
+- **`search_capsules(filter: {capsuleType: {eq: 'Provisions'}})` + `update_journal(resourceId: <each id>, saveAsDraft: false)  // loop per id — no bulk-finalize-journals tool yet`** — Q5 finalize each provision capsule's quarter-end DRAFT unwinding journals.
 - **`generate_trial_balance(period_end: <Q-end>)`** — verification.
 - **`update_account(resourceId: <CoA root>, lockDate: <Q-end>)`** — final lock.
 
@@ -80,9 +80,9 @@ clio calc ecl --current 100000 --30d 50000 --60d 20000 --90d 10000 --120d 5000 -
 If `topUpRequired > CLIENT.materiality_threshold`:
 
 ```
-plan_recipe(name: 'ecl', receivables: <buckets>, ratesPerBucket: <rates from CLIENT.ecl_loss_rate_matrix>, ...)
+plan_recipe(recipe: 'ecl', receivables: <buckets>, ratesPerBucket: <rates from CLIENT.ecl_loss_rate_matrix>, ...)
 execute_recipe(...)
-bulk_finalize_drafts({kind: 'journal', resourceIds: [<ecl journal>]})
+update_journal(resourceId: <ecl journal>, saveAsDraft: false)
 ```
 
 Document the analysis in `recurring/quarterly/2025-Q1/ecl-review.json`. Auditor will request this each quarter.
@@ -120,8 +120,8 @@ search_capsules(filter: {capsuleType: {eq: 'Provisions'}, status: {eq: 'ACTIVE'}
 Per capsule: this period's quarter-end unwinding DRAFT journals (3 monthly DRAFTs from `provisions.md` recipe execution) should already be in the capsule. Verify and finalize:
 
 ```
-search_journals(filter: {capsuleResourceId: <provision capsule id>, valueDate: {between: ['2025-01-01', '2025-03-31']}, status: {eq: 'DRAFT'}})
-bulk_finalize_drafts({kind: 'journal', resourceIds: [...]})
+search_journals(filter: {capsuleResourceId: {eq: <provision capsule id>}, valueDate: {between: ['2025-01-01', '2025-03-31']}, status: {eq: 'DRAFT'}})
+update_journal(resourceId: <each id>, saveAsDraft: false)  // loop per id — no bulk-finalize-journals tool yet
 ```
 
 If practitioner determines remeasurement is needed (cash-flow estimate changed, discount rate moved): see `provisions.md` step 6 — recompute, post adjustment, reverse remaining DRAFT unwinding journals, re-execute recipe with new inputs.

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

@@ -15,8 +15,8 @@
 - **`update_fixed_asset(resourceId: <id>, status: 'ACTIVE'|'DISPOSED'|'WRITTEN_OFF')`** — Y1 fallback if any FA has incorrect status at FY-end.
 - **`search_journals(filter: {tag: 'leave-accrual', valueDate: {between: [<FY-start>, <FY-end>]}})` / `search_journals(filter: {tag: 'bonus-accrual', ...})`** — Y2 true-up: pull all FY accrual journals to compare against actuals.
 - **`create_journal(...)`** — Y2 true-up adjustment journals (manual one-off, not recipe-driven).
-- **`plan_recipe(name: 'dividend', ...)` + `execute_recipe(...)`** — Y3 dividend declaration + payment (engine emits the 2-step pattern: declaration journal + payment cash-out).
-- **`plan_recipe(name: 'ecl', ...)` + `execute_recipe(...)`** — Y4 IFRS 9 ECL year-end true-up against `generate_aged_ar`.
+- **`plan_recipe(recipe: 'dividend', ...)` + `execute_recipe(...)`** — Y3 dividend declaration + payment (engine emits the 2-step pattern: declaration journal + payment cash-out).
+- **`plan_recipe(recipe: 'ecl', ...)` + `execute_recipe(...)`** — Y4 IFRS 9 ECL year-end true-up against `generate_aged_ar`.
 - **`update_account(resourceId: <CoA root>, lockDate: <FY-end>)`** — Y8 final lock.
 
 ### MCP tools — current/non-current reclassification (manual annual journals)
@@ -71,7 +71,7 @@ generate_fa_recon_summary(period_start: '2025-01-01', period_end: '2025-12-31')
 
 For Jaz native straight-line depreciation: should be automatic and correct. Verify the 12-month aggregate against `generate_general_ledger(accountResourceId: <Depreciation Expense>, period_start, period_end)`.
 
-For non-SL assets (DDB, 150DB) where `plan_recipe(name: 'depreciation', method: 'ddb' | '150db')` was used: each capsule pre-emitted 12 future-dated DRAFT journals at recipe-execution time. Confirm all 12 are FINALIZED via `search_journals(filter: {capsuleResourceId: <dep capsule>, status: {eq: 'DRAFT'}, valueDate: {between: [<FY-start>, <FY-end>]}})` — should be empty. If non-empty: route back to `month-end-close.md` step 9.
+For non-SL assets (DDB, 150DB) where `plan_recipe(recipe: 'depreciation', method: 'ddb' | '150db')` was used: each capsule pre-emitted 12 future-dated DRAFT journals at recipe-execution time. Confirm all 12 are FINALIZED via `search_journals(filter: {capsuleResourceId: {eq: <dep capsule>}, status: {eq: 'DRAFT'}, valueDate: {between: [<FY-start>, <FY-end>]}})` — should be empty. If non-empty: route back to `month-end-close.md` step 9.
 
 Reconcile `generate_fa_recon_summary` formula: `openingNbv + additions − disposals − depreciation == closingNbv == TB[Fixed Assets].balance`. Mismatch beyond `CLIENT.materiality_threshold` → investigate (likely a disposal posted without `update_fixed_asset(status: 'DISPOSED')` — auditor will catch this).
 
@@ -109,7 +109,7 @@ If `CLIENT.dividend_policy.declared_for_FY > 0`:
 
 ```
 plan_recipe(
-  name: 'dividend',
+  recipe: 'dividend',
   amount: <gross-dividend>,
   withholdingRate: <CLIENT.dividend_policy.withholding_rate>,
   declarationDate: '2025-12-31',
@@ -141,7 +141,7 @@ clio calc ecl --current <c> --30d <30> --60d <60> --90d <90> --120d <120> --rate
 If top-up needed > `CLIENT.materiality_threshold`:
 
 ```
-plan_recipe(name: 'ecl', receivables: <buckets>, ratesPerBucket: <rates>, existingProvisionAccount: <Allowance for Doubtful Debts>, glBadDebtExpense: <Bad Debt Expense>, valueDate: '2025-12-31', capsuleType: 'ECL Provision', capsuleName: 'FY2025 ECL Year-End True-Up')
+plan_recipe(recipe: 'ecl', receivables: <buckets>, ratesPerBucket: <rates>, existingProvisionAccount: <Allowance for Doubtful Debts>, glBadDebtExpense: <Bad Debt Expense>, valueDate: '2025-12-31', capsuleType: 'ECL Provision', capsuleName: 'FY2025 ECL Year-End True-Up')
 ```
 
 Then `execute_recipe(...)`. Engine emits 1 journal: Dr Bad Debt Expense / Cr Allowance for Doubtful Debts for the top-up amount. ECL recipe is one-shot per FY (no ongoing schedule) — capsule closes on execution.
@@ -156,7 +156,7 @@ For each existing IAS 37 provision capsule (warranty, legal, decommissioning):
 search_capsules(filter: {capsuleType: {eq: 'Provision'}, status: 'ACTIVE'})
 ```
 
-Per capsule, recompute the present value at FY-end (`clio calc provision`). Top-up via additional `plan_recipe(name: 'provision', ...)` + `execute_recipe` if required, OR reverse via `create_journal` if the obligation reduced.
+Per capsule, recompute the present value at FY-end (`clio calc provision`). Top-up via additional `plan_recipe(recipe: 'provision', ...)` + `execute_recipe` if required, OR reverse via `create_journal` if the obligation reduced.
 
 ### Y6 — Current/non-current reclassification (manual journals)
 
@@ -194,7 +194,7 @@ search_invoices(filter: {status: {eq: 'DRAFT'}, valueDate: {between: ['2025-01-0
 search_bills(filter: {status: {eq: 'DRAFT'}, valueDate: {between: ['2025-01-01', '2025-12-31']}})
 ```
 
-ALL three must return zero. If any: `bulk_finalize_drafts({kind, resourceIds: [...]})` for the keep-set; `delete_*` for the discards.
+ALL three must return zero. If any: `update_<entity>(resourceId, saveAsDraft: false)  // per-id; bulk_finalize_drafts only supports invoice/bill/CN, not journal/cash` for the keep-set; `delete_*` for the discards.
 
 ### Y8 — Lock the year
 

package/assets/skills/practice/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jaz-practice
-version: 5.4.16
+version: 5.4.18
 description: >-
   Use this skill whenever an accounting practitioner is doing client work in
   Jaz — closing the books, filing GST, year-end statutory, onboarding a new

package/assets/skills/practice/references/annual-statutory.md

@@ -26,12 +26,12 @@ Canonical playbook the agent walks through when the practitioner says "year-end
 - `export_records` / `download_export` — used in step 5: deliverable XLSX exports for auditor pack.
 
 ### Recipes (jaz-recipes)
-- `plan_recipe(name: 'depreciation', …)` — used in step 4: annual depreciation true-up for non-SL assets.
-- **FX revaluation** — used in step 4c as VERIFICATION ONLY (Jaz auto-handles year-end FX translation per IAS 21.23). Independent recompute via `clio calc fx-reval`; do NOT invoke `execute_recipe(name: 'fx-reval', ...)` — would double-post.
-- `plan_recipe(name: 'asset-disposal', …)` — used in step 4: disposals surfaced during FA review.
-- `plan_recipe(name: 'ecl', …)` — used in step 4: IFRS 9 year-end true-up over `generate_aged_ar`.
-- `plan_recipe(name: 'provision', …)` — used in step 4: IAS 37 remeasurement.
-- `plan_recipe(name: 'dividend', …)` — used in step 8: declaration after profit finalization (per jaz-recipes annual-statutory context).
+- `plan_recipe(recipe: 'depreciation', …)` — used in step 4: annual depreciation true-up for non-SL assets.
+- **FX revaluation** — used in step 4c as VERIFICATION ONLY (Jaz auto-handles year-end FX translation per IAS 21.23). Independent recompute via `clio calc fx-reval`; do NOT invoke `execute_recipe(recipe: 'fx-reval', ...)` — would double-post.
+- `plan_recipe(recipe: 'asset-disposal', …)` — used in step 4: disposals surfaced during FA review.
+- `plan_recipe(recipe: 'ecl', …)` — used in step 4: IFRS 9 year-end true-up over `generate_aged_ar`.
+- `plan_recipe(recipe: 'provision', …)` — used in step 4: IAS 37 remeasurement.
+- `plan_recipe(recipe: 'dividend', …)` — used in step 8: declaration after profit finalization (per jaz-recipes annual-statutory context).
 
 ### Calculators (jaz-cli)
 - `clio calc loan` — used in step 4: independent verification of loan schedules at FY-end.
@@ -90,20 +90,20 @@ This is the largest step and runs through the recipe set in this order:
 
 Invoke `generate_fa_summary(period_end: <FY-end>)`. For every active asset:
 - If `depreciationMethod == STRAIGHT_LINE`: Jaz native FA already posted monthly. Verify the year's accumulated depreciation per the report. Cross-check via `clio calc depreciation --cost <c> --salvage <s> --life <l> --method sl --frequency annual --currency <CLIENT.base_currency> --json`. Tolerance: `CLIENT.materiality_threshold`.
-- If `depreciationMethod ∈ { DDB, 150DB }`: confirm the 12 monthly close engagements posted via `plan_recipe(name: 'depreciation', …)`. Year-end true-up only if a remeasurement of `usefulLife` happened during FY.
+- If `depreciationMethod ∈ { DDB, 150DB }`: confirm the 12 monthly close engagements posted via `plan_recipe(recipe: 'depreciation', …)`. Year-end true-up only if a remeasurement of `usefulLife` happened during FY.
 
 #### 4b — FA disposals discovered during review
 
 For each asset where `search_fixed_assets` returns `status: DISPOSED` but no asset-disposal capsule exists, OR the practitioner identifies a missed disposal during review:
 1. `clio calc asset-disposal --cost <c> --salvage <s> --life <l> --acquired <YYYY-MM-DD> --disposed <YYYY-MM-DD> --proceeds <p> --method <sl|ddb|150db> --currency <CLIENT.base_currency> --json` for verification.
-2. `plan_recipe(name: 'asset-disposal', cost: <c>, accumulated: <accumulated-to-disposal-date>, disposalDate: <YYYY-MM-DD>, proceeds: <p>, glAccountCost: <FA gl>, glAccountAccumulated: <accumulated gl>, glAccountGainLoss: <P&L line>, …)`.
+2. `plan_recipe(recipe: 'asset-disposal', cost: <c>, accumulated: <accumulated-to-disposal-date>, disposalDate: <YYYY-MM-DD>, proceeds: <p>, glAccountCost: <FA gl>, glAccountAccumulated: <accumulated gl>, glAccountGainLoss: <P&L line>, …)`.
 3. `execute_recipe`. Inspect `notes` — typically includes a `note` action to deregister the asset in the FA module.
 
 **On 422 from `plan_recipe` with `disposal_after_period_end`:** the disposal date is later than `<FY-end>`. The disposal belongs to next FY; halt and confirm with practitioner.
 
 #### 4c — Year-end FX revaluation (verification only)
 
-**Jaz auto-handles year-end FX translation per IAS 21.23.** All foreign-currency monetary balances (AR, AP, cash, bank, intercompany, term deposits, FX provisions) translate to base currency at the FY-end closing rate automatically. **DO NOT invoke `execute_recipe(name: 'fx-reval', ...)` — would double-post.**
+**Jaz auto-handles year-end FX translation per IAS 21.23.** All foreign-currency monetary balances (AR, AP, cash, bank, intercompany, term deposits, FX provisions) translate to base currency at the FY-end closing rate automatically. **DO NOT invoke `execute_recipe(recipe: 'fx-reval', ...)` — would double-post.**
 
 This sub-step is a year-end verification (auditor will sample-test the rates used):
 
@@ -127,13 +127,13 @@ This sub-step is a year-end verification (auditor will sample-test the rates use
 1. `generate_aged_ar(period_end: <FY-end>)`.
 2. Bucket receivables by aging band per CLIENT historical loss-rate matrix.
 3. `clio calc ecl --current <c> --30d <30> --60d <60> --90d <90> --120d <120> --rates <r1>,<r2>,<r3>,<r4>,<r5> --existing-provision <ep> --currency <CLIENT.base_currency> --json`.
-4. If top-up > `CLIENT.materiality_threshold`: `plan_recipe(name: 'ecl', …)` then `execute_recipe`.
+4. If top-up > `CLIENT.materiality_threshold`: `plan_recipe(recipe: 'ecl', …)` then `execute_recipe`.
 
 #### 4e — IAS 37 provisions remeasurement
 
 For each capsule from step 3 with `tag: 'provision'`:
 1. `clio calc provision --amount <pv> --rate <discount-rate> --term <remaining-months-to-FY-end> --currency <CLIENT.base_currency> --json` to verify cumulative discount unwinding.
-2. If best-estimate has changed materially during FY: re-run `plan_recipe(name: 'provision', …)` with new amount; the recipe creates a remeasurement journal.
+2. If best-estimate has changed materially during FY: re-run `plan_recipe(recipe: 'provision', …)` with new amount; the recipe creates a remeasurement journal.
 
 #### 4f — Bonus accrual true-up
 
@@ -205,7 +205,7 @@ Practitioner submits on myTax Portal manually. Capture submission reference into
 
 If the board declares a dividend post profit-finalization (per jaz-recipes annual-statutory context):
 1. `clio calc dividend --amount <amt> --declaration-date <YYYY-MM-DD> --payment-date <YYYY-MM-DD> [--withholding-rate <r>] --currency <CLIENT.base_currency> --json`.
-2. `plan_recipe(name: 'dividend', amount: <amt>, declarationDate: <YYYY-MM-DD>, paymentDate: <YYYY-MM-DD>, withholdingRate: <r>, …)` then `execute_recipe`. Recipe creates declaration journal (reduces retained earnings) + payment journal + optional WHT journal.
+2. `plan_recipe(recipe: 'dividend', amount: <amt>, declarationDate: <YYYY-MM-DD>, paymentDate: <YYYY-MM-DD>, withholdingRate: <r>, …)` then `execute_recipe`. Recipe creates declaration journal (reduces retained earnings) + payment journal + optional WHT journal.
 3. `bulk_finalize_drafts`.
 
 For cross-border WHT obligations: see jaz-api § Withholding Tax (rules 45, 98).
@@ -254,7 +254,7 @@ If any fails: do NOT mark `filed`. Surface the failed check.
 | Error class | Where | Recovery |
 |---|---|---|
 | 422 `prior_year_not_locked` | `generate_year_end_blueprint` | Close prior FY first; halt. |
-| 422 `disposal_after_period_end` | `plan_recipe(name: 'asset-disposal', …)` | Disposal date > FY-end; belongs to next FY. |
+| 422 `disposal_after_period_end` | `plan_recipe(recipe: 'asset-disposal', …)` | Disposal date > FY-end; belongs to next FY. |
 | 422 `journal_unbalanced` | `bulk_finalize_drafts` | Recipe regression; halt without retry. |
 | 404 `currency_rate_missing` | step 4c FX reval | `bulk_upsert_currency_rates` to load FY-end rates; auto-enables currencies (jaz-api rule 39). |
 | 422 `account_locked` | step 4 recipe execution | A monthly close already locked the account; lift lock for that specific account, post adjustment, re-lock. |

package/assets/skills/practice/references/client-md-schema.md

@@ -11,7 +11,7 @@ The per-client master file. Lives at `~/Documents/Jaz Practice/clients/<slug>/CL
 | `uen` | string (Singapore) | annual-statutory | ACRA filings reference this. If `country: SG` and this is empty, surface to practitioner before annual-statutory deliverables. |
 | `registered_address` | string | annual-statutory | Stamped on financial statements lodgment. |
 | `country` | ISO-3166 alpha-2 | every playbook | Routes jurisdiction-specific guidance. `SG` triggers IRAS/ACRA paths; future codes (MY, PH, HK) route their equivalents. |
-| `base_currency` | ISO-4217 | every playbook | Functional currency. Period-end FX revaluation against this is auto-handled by Jaz (IAS 21.23) — agent verifies via `clio calc fx-reval` cross-check, never invokes `execute_recipe(name: 'fx-reval', ...)`. Stamped onto reports. |
+| `base_currency` | ISO-4217 | every playbook | Functional currency. Period-end FX revaluation against this is auto-handled by Jaz (IAS 21.23) — agent verifies via `clio calc fx-reval` cross-check, never invokes `execute_recipe(recipe: 'fx-reval', ...)`. Stamped onto reports. |
 | `fy_end` | MM-DD | annual-statutory | Drives period boundaries: `annual-statutory` engagement period spans `<previous fy_end + 1 day>` to `<this fy_end>`. |
 | `gst_scheme` | `quarterly` \| `monthly` \| `not-registered` | quarterly-gst | If `not-registered`, agent skips quarterly-gst engagement scheduling. Otherwise: cadence drives F5 period (e.g., quarterly = `2026-Q1`). |
 | `gst_registration_number` | string | quarterly-gst | Stamped onto F5 submission tracker. Required when `gst_scheme != not-registered`. |
@@ -20,7 +20,7 @@ The per-client master file. Lives at `~/Documents/Jaz Practice/clients/<slug>/CL
 | `jaz_org_id` | UUID | every API tool call | Pinned at `practice_onboard_client` time. Subsequent tool invocations scope to this org so cross-client mix-ups don't happen. |
 | `materiality_threshold` | number (in `base_currency`) | monthly-close, annual-statutory | Threshold for surfacing variance / reconciliation gaps. Compared against `|current - prior|` after `generate_trial_balance`. |
 | `bank_accounts[]` | array | monthly-close | Each entry: `{name, account_number_ref?, currency, jaz_resource_id?}`. Iterated before invoking `search_bank_records(accountResourceId: …, status: UNRECONCILED)`. After first reconciliation, `jaz_resource_id` should be populated to skip future name-lookup. |
-| `recurring_accruals[]` | array | monthly-close | Each entry: `{name, gl_account, vendor?, estimation_method?, fixed_amount?}`. Drives one `plan_recipe(name: 'accrued-expense', amount: <computed>, glAccount, vendor, valueDate: period_end, reversalDate: next_period_start)` invocation per row. `estimation_method` values: `prior_month` (use prior period's amount), `trailing_3m_avg` (average of last 3 months), `budget` (read from CLIENT body / ENGAGEMENT inputs), `fixed_amount` (use `fixed_amount` field). |
+| `recurring_accruals[]` | array | monthly-close | Each entry: `{name, gl_account, vendor?, estimation_method?, fixed_amount?}`. Drives one `plan_recipe(recipe: 'accrued-expense', amount: <computed>, glAccount, vendor, valueDate: period_end, reversalDate: next_period_start)` invocation per row. `estimation_method` values: `prior_month` (use prior period's amount), `trailing_3m_avg` (average of last 3 months), `budget` (read from CLIENT body / ENGAGEMENT inputs), `fixed_amount` (use `fixed_amount` field). |
 | `recurring_engagements[]` | array | practice_load_client surfacing | Each entry: `{type, cadence}`. Agent checks: for each entry, does an active engagement exist for the current period? If not, prompt practitioner to create it. |
 | `key_contacts[]` | array | annual-statutory, ad-hoc questions | `{name, role, email}`. Used in correspondence routing and "ask the client" prompts. |
 

package/assets/skills/practice/references/monthly-close.md

@@ -20,12 +20,12 @@ Canonical playbook the agent walks through when the practitioner says "close `<p
 - `search_journals(status: ACTIVE, valueDate: <period_end>)` — used in step 11: confirm period-end journals are all `ACTIVE` (NOT `FINALIZED` — see jaz-api rule on journal status, jaz-jobs note in `references/month-end-close.md`).
 
 ### Recipes (jaz-recipes — IFRS-compliant transaction modeling)
-- `plan_recipe(name: 'accrued-expense', …)` — used in step 4: per `CLIENT.recurring_accruals[i]` whose `last_posted < period_end`. Two-scheduler accrue + reverse pattern.
-- `plan_recipe(name: 'depreciation', …)` — used in step 5: only when an asset uses a non-SL method (DDB, 150DB) — Jaz native FA already handles SL. Cross-check with `clio calc depreciation`.
-- **FX revaluation** — used in step 6 as VERIFICATION ONLY (Jaz auto-handles all FX reval per IAS 21.23; do NOT invoke `execute_recipe(name: 'fx-reval', ...)` — would double-post).
-- `plan_recipe(name: 'prepaid-expense', …)` — used in step 7: only on initial setup of a new prepaid; ongoing recognition runs from the scheduler created at setup.
-- `plan_recipe(name: 'deferred-revenue', …)` — used in step 7: same setup-vs-recognition note as prepaid.
-- `plan_recipe(name: 'provision', …)` — used in step 7: monthly discount-unwinding journal for any active IAS 37 provision capsule.
+- `plan_recipe(recipe: 'accrued-expense', …)` — used in step 4: per `CLIENT.recurring_accruals[i]` whose `last_posted < period_end`. Two-scheduler accrue + reverse pattern.
+- `plan_recipe(recipe: 'depreciation', …)` — used in step 5: only when an asset uses a non-SL method (DDB, 150DB) — Jaz native FA already handles SL. Cross-check with `clio calc depreciation`.
+- **FX revaluation** — used in step 6 as VERIFICATION ONLY (Jaz auto-handles all FX reval per IAS 21.23; do NOT invoke `execute_recipe(recipe: 'fx-reval', ...)` — would double-post).
+- `plan_recipe(recipe: 'prepaid-expense', …)` — used in step 7: only on initial setup of a new prepaid; ongoing recognition runs from the scheduler created at setup.
+- `plan_recipe(recipe: 'deferred-revenue', …)` — used in step 7: same setup-vs-recognition note as prepaid.
+- `plan_recipe(recipe: 'provision', …)` — used in step 7: monthly discount-unwinding journal for any active IAS 37 provision capsule.
 
 ### Calculators (jaz-cli / `clio calc`)
 - `clio calc accrued-expense` — used in step 4: independently compute accrual amount before invoking the recipe (cross-check).
@@ -87,7 +87,7 @@ For each row in `CLIENT.recurring_accruals[]` where `last_posted < <period>-end`
    - `budget`: read from `CLIENT.recurring_accruals[i].budget_amount` (NOT `fixed_amount`).
    - `fixed_amount`: use `CLIENT.recurring_accruals[i].fixed_amount`.
 2. Cross-check: `clio calc accrued-expense --amount <computed> --periods 1 --start-date <period>-end --currency <CLIENT.base_currency> --json`.
-3. Invoke `plan_recipe(name: 'accrued-expense', amount: <computed>, glAccount: <CLIENT.recurring_accruals[i].gl_account>, vendor: <CLIENT.recurring_accruals[i].vendor>, valueDate: <period>-end, reversalDate: <next-period>-01)`.
+3. Invoke `plan_recipe(recipe: 'accrued-expense', amount: <computed>, glAccount: <CLIENT.recurring_accruals[i].gl_account>, vendor: <CLIENT.recurring_accruals[i].vendor>, valueDate: <period>-end, reversalDate: <next-period>-01)`.
 4. Inspect `plan_recipe` output: `requiredAccounts`, `needsContact`. If `needsContact` and the vendor doesn't yet exist: invoke `search_contacts(filter: {name: {eq: <vendor>}})`; if empty, halt and surface "Accrual vendor `<vendor>` not in Jaz contacts — create via `create_contact` or remap CLIENT.md before retry."
 5. If `requiredAccounts` includes a GL account not in the org's CoA: surface "Accrual `<accrual.name>` references GL account `<glAccount>` not in `CLIENT.coa_mapping` / Jaz CoA; create via `create_account` or remap before retry." Halt.
 6. Invoke `execute_recipe(...)` with the same args as `plan_recipe` plus the resolved `accountMap` and `contactId`. The recipe creates a capsule + the dual-entry accrual + reversal scheduler. The journals are returned in DRAFT.
@@ -104,7 +104,7 @@ For each row in `CLIENT.recurring_accruals[]` where `last_posted < <period>-end`
 
 1. Invoke `search_fixed_assets(filter: {status: {eq: 'ACTIVE'}}, limit: 200)`. For each asset:
    - If `depreciationMethod = STRAIGHT_LINE`: Jaz auto-posts via the FA module. No journal needed. Cross-check that the period's journal exists via `search_journals(filter: {tag: <asset.tagName>, valueDate: <period>-end, type: DEPRECIATION})`.
-   - If `depreciationMethod ∈ { DDB, 150DB }`: Jaz native FA does NOT handle. Invoke `plan_recipe(name: 'depreciation', cost: <asset.cost>, salvage: <asset.salvage>, life: <asset.usefulLifeMonths>, method: <ddb|150db>, frequency: monthly, valueDate: <period>-end, …)` then `execute_recipe`.
+   - If `depreciationMethod ∈ { DDB, 150DB }`: Jaz native FA does NOT handle. Invoke `plan_recipe(recipe: 'depreciation', cost: <asset.cost>, salvage: <asset.salvage>, life: <asset.usefulLifeMonths>, method: <ddb|150db>, frequency: monthly, valueDate: <period>-end, …)` then `execute_recipe`.
 2. Independent cross-check per asset: `clio calc depreciation --cost <cost> --salvage <salvage> --life <life> --method <method> --frequency monthly --currency <CLIENT.base_currency> --json`. Compare per-period journal output to what Jaz posted.
 3. For any asset where Jaz-posted ≠ calc-output by > `CLIENT.materiality_threshold`: surface to practitioner.
 
@@ -112,7 +112,7 @@ For each row in `CLIENT.recurring_accruals[]` where `last_posted < <period>-end`
 
 ### Step 6 — FX revaluation
 
-**Jaz auto-handles FX revaluation for ALL foreign-currency monetary balances.** AR, AP, cash, bank, intercompany, term deposits, FX provisions — period-end translation per IAS 21.23 is automatic. **DO NOT invoke `execute_recipe(name: 'fx-reval', ...)` — would double-post.** This step is verification + variance investigation.
+**Jaz auto-handles FX revaluation for ALL foreign-currency monetary balances.** AR, AP, cash, bank, intercompany, term deposits, FX provisions — period-end translation per IAS 21.23 is automatic. **DO NOT invoke `execute_recipe(recipe: 'fx-reval', ...)` — would double-post.** This step is verification + variance investigation.
 
 1. Confirm the period-end closing rate is loaded for each foreign currency: `list_currency_rates(filter: {sourceCurrency: <fcy>, valueDate: <period>-end})`. If empty: halt and surface "Closing rate for `<fcy>` on `<period>-end` not in Jaz — Jaz used the most recent rate as a fallback. Load the actual closing rate via `add_currency_rate` or `bulk_upsert_currency_rates`, which will trigger Jaz to re-translate; confirm via re-running step 6 verification before close." (See jaz-api rule 39.)
 
@@ -134,7 +134,7 @@ Per memory rule [Bank FX is Revaluation, not Realized]: bank/cash FX uses `FX Ba
 For each scheduler-driven recipe whose unwinding journal is due this period:
 
 1. Invoke `search_capsules(filter: {tag: {in: ['prepaid', 'deferred-revenue', 'provision', 'lease', 'loan']}, status: ACTIVE})`.
-2. For each capsule, the unwinding/recognition journal is auto-emitted by the scheduler — verify it exists via `search_journals(filter: {capsuleResourceId: <id>, valueDate: <period>-end})`.
+2. For each capsule, the unwinding/recognition journal is auto-emitted by the scheduler — verify it exists via `search_journals(filter: {capsuleResourceId: {eq: <id>}, valueDate: <period>-end})`.
 3. If missing: the scheduler is paused or mis-dated. Surface to practitioner: "Capsule `<title>` has no period-end journal — confirm scheduler status before close."
 4. For provision capsules: cross-check unwinding amount via `clio calc provision --amount <pv> --rate <rate> --term <remaining-months> --json` and verify the period slice matches.
 

package/assets/skills/practice/references/onboarding.md

@@ -32,7 +32,7 @@ Canonical playbook the agent walks through when the practitioner says "onboard `
 
 ### Recipes (jaz-recipes)
 - Not used during onboarding setup itself. Onboarding's job is to populate `CLIENT.md` so subsequent recurring engagements can drive recipes from it.
-- After step 8 hand-off, the first `monthly-close` engagement uses `plan_recipe(name: 'accrued-expense', …)` per `CLIENT.recurring_accruals[]` etc. — see `jaz-practice/references/monthly-close.md`.
+- After step 8 hand-off, the first `monthly-close` engagement uses `plan_recipe(recipe: 'accrued-expense', …)` per `CLIENT.recurring_accruals[]` etc. — see `jaz-practice/references/monthly-close.md`.
 
 ### Calculators (jaz-cli)
 - Not used during setup. Used in subsequent engagements after onboarding closes.

package/assets/skills/practice/references/quarterly-gst.md

@@ -17,7 +17,7 @@ Canonical playbook the agent walks through when the practitioner says "prep GST
 - `download_export` — used in step 7: download the generated CSV/XLSX for IRAS submission attachment.
 
 ### Recipes (jaz-recipes)
-- None for F5 prep itself. Exception (per jaz-recipes guidance): if ECL review is bundled with F5 prep cycle (since AR aging is already pulled), `plan_recipe(name: 'ecl', …)`.
+- None for F5 prep itself. Exception (per jaz-recipes guidance): if ECL review is bundled with F5 prep cycle (since AR aging is already pulled), `plan_recipe(recipe: 'ecl', …)`.
 
 ### Calculators (jaz-cli)
 - `clio calc ecl` — only if ECL review is bundled (typically the case for quarterly cadence).
@@ -146,7 +146,7 @@ If the practitioner has scoped ECL into this engagement (typical for quarterly c
 2. Bucket receivables by aging band (current, 30, 60, 90, 120+ days).
 3. Read `CLIENT` decisions log for the historical loss-rate matrix.
 4. Invoke `clio calc ecl --current <c> --30d <30> --60d <60> --90d <90> --120d <120> --rates <r1>,<r2>,<r3>,<r4>,<r5> --existing-provision <ep> --currency <CLIENT.base_currency> --json`.
-5. If the calc surfaces a top-up provision > `CLIENT.materiality_threshold`: invoke `plan_recipe(name: 'ecl', …)` then `execute_recipe`.
+5. If the calc surfaces a top-up provision > `CLIENT.materiality_threshold`: invoke `plan_recipe(recipe: 'ecl', …)` then `execute_recipe`.
 6. `bulk_finalize_drafts` for the journal(s) created.
 
 ### Step 9 — Sign-off + transition

package/assets/skills/practice/references/troubleshooting.md

@@ -47,8 +47,8 @@ When the agent invokes Jaz tools inside an engagement context, common error clas
 
 | Symptom | Cause | Recovery |
 |---------|-------|----------|
-| `plan_recipe(name: 'accrued-expense', …)` returns negative amount | Estimation method picked up a credit balance | Surface "Accrual `<name>`: prior_month estimation produced a credit. Switch CLIENT.md.recurring_accruals[i].estimation_method to `fixed_amount` for this row this period, or pull `trailing_3m_avg`." |
-| `clio calc fx-reval` (verification) returns very different gain/loss vs Jaz's auto-posted | Closing rate stale or wrong direction; or settlement-realized FX shifted the book rate mid-period | Verify `list_currency_rates(currencyCode, valueDate: <period-end>)` is current. Confirm rate direction (`SOURCE_TO_FUNCTIONAL`). Check for settlement events: `search_payments(filter: {valueDate: {between: [<period-start>, <period-end>]}, currency: {ne: <CLIENT.base_currency>}})`. NEVER `execute_recipe(name: 'fx-reval', ...)` to "correct" — would double-post against Jaz's auto-emitted FX journals. |
+| `plan_recipe(recipe: 'accrued-expense', …)` returns negative amount | Estimation method picked up a credit balance | Surface "Accrual `<name>`: prior_month estimation produced a credit. Switch CLIENT.md.recurring_accruals[i].estimation_method to `fixed_amount` for this row this period, or pull `trailing_3m_avg`." |
+| `clio calc fx-reval` (verification) returns very different gain/loss vs Jaz's auto-posted | Closing rate stale or wrong direction; or settlement-realized FX shifted the book rate mid-period | Verify `list_currency_rates(currencyCode, valueDate: <period-end>)` is current. Confirm rate direction (`SOURCE_TO_FUNCTIONAL`). Check for settlement events: `search_payments(filter: {valueDate: {between: [<period-start>, <period-end>]}, currency: {ne: <CLIENT.base_currency>}})`. NEVER `execute_recipe(recipe: 'fx-reval', ...)` to "correct" — would double-post against Jaz's auto-emitted FX journals. |
 | `clio calc <name>` validation error | Required option missing | The CLI prints which required option is missing. Match against the engagement-type playbook's specified arguments. |
 
 ## Workspace integrity