rsc-universal 0.1.1

package/skills/fastapi/scripts/verify.sh

@@ -0,0 +1,116 @@
+#!/usr/bin/env bash
+#
+# verify.sh — quality gate for a FastAPI / async Python project.
+#
+# Usage:
+#   ./scripts/verify.sh [TARGET_PATH]
+#
+# Runs lint, format-check, type-check, tests+coverage, and a dependency audit.
+# Auto-detects each tool. If a tool is missing it prints a yellow SKIP and continues
+# (it never FAILs on a missing tool). Prefers `uv run <tool>` when `uv` is present,
+# else the bare tool on PATH. Exits non-zero only if a tool actually ran and reported
+# a failure. The coverage threshold is read from the project's pyproject.toml
+# (--cov-fail-under); this script does not hardcode a second threshold. Idempotent:
+# re-running yields the same result (read-only beyond whatever the project's pytest does).
+#
+# Compatible with stock macOS bash 3.2: no `mapfile`, no associative arrays, and every
+# array access is guarded so `set -u` never trips on an "unbound" empty array.
+
+set -euo pipefail
+
+TARGET="${1:-.}"
+
+# --- color helpers (guarded for non-TTY) ---
+if [ -t 1 ]; then
+  RED=$'\033[0;31m'; GREEN=$'\033[0;32m'; YELLOW=$'\033[0;33m'; RESET=$'\033[0m'
+else
+  RED=''; GREEN=''; YELLOW=''; RESET=''
+fi
+warn() { printf '%s%s%s\n' "$YELLOW" "$*" "$RESET"; }
+ok()   { printf '%s%s%s\n' "$GREEN" "$*" "$RESET"; }
+fail() { printf '%s%s%s\n' "$RED" "$*" "$RESET"; }
+
+PASSED=0; SKIPPED=0; FAILED=0
+
+have() { command -v "$1" >/dev/null 2>&1; }
+
+# Detect-or-skip: a real Python project has a project manifest or at least one *.py
+# under TARGET. With neither, there is nothing to verify, so SKIP (exit 0) instead of
+# letting pytest report "no tests collected" as a FAIL. This guards only the empty case;
+# inside a real project every tool still runs and real failures still surface.
+python_project_present() {
+  if [ -f "$TARGET/pyproject.toml" ] || [ -f "$TARGET/setup.py" ] || [ -f "$TARGET/setup.cfg" ]; then
+    return 0
+  fi
+  # Any .py file under TARGET (bash 3.2: use find, no globstar).
+  if [ -n "$(find "$TARGET" -type f -name '*.py' -print -quit 2>/dev/null)" ]; then
+    return 0
+  fi
+  return 1
+}
+
+if ! python_project_present; then
+  warn "SKIP: no Python project found under '${TARGET}' (no pyproject.toml/setup.py/setup.cfg and no *.py)"
+  ok "verify.sh: ok (nothing to verify)"
+  exit 0
+fi
+
+# Do we have uv? When yes, tools run through `uv run`, which can resolve a tool from the
+# project venv even if it is not on PATH.
+USE_UV=0
+if have uv; then USE_UV=1; fi
+
+# tool_available <tool>
+# True when the tool can actually be invoked: either it is on PATH, or (under uv) it can
+# be resolved and reports a version. Probing under uv is what lets us SKIP (not FAIL) a
+# tool that is genuinely absent from the project's environment.
+tool_available() {
+  local tool="$1"
+  if have "$tool"; then
+    return 0
+  fi
+  if [ "$USE_UV" -eq 1 ]; then
+    if uv run --quiet "$tool" --version >/dev/null 2>&1; then
+      return 0
+    fi
+  fi
+  return 1
+}
+
+# run_step <label> <tool> <args...>
+run_step() {
+  local label="$1"; local tool="$2"; shift 2
+  if ! tool_available "$tool"; then
+    warn "SKIP: ${label} (${tool} not installed)"
+    SKIPPED=$((SKIPPED + 1))
+    return 0
+  fi
+  printf '==> %s\n' "$label"
+  if [ "$USE_UV" -eq 1 ]; then
+    if uv run "$tool" "$@"; then
+      ok "PASS: ${label}"; PASSED=$((PASSED + 1))
+    else
+      fail "FAIL: ${label}"; FAILED=$((FAILED + 1))
+    fi
+  else
+    if "$tool" "$@"; then
+      ok "PASS: ${label}"; PASSED=$((PASSED + 1))
+    else
+      fail "FAIL: ${label}"; FAILED=$((FAILED + 1))
+    fi
+  fi
+}
+
+run_step "ruff check"        ruff check "$TARGET"
+run_step "ruff format check" ruff format --check "$TARGET"
+run_step "mypy"              mypy "$TARGET"
+run_step "pytest + coverage" pytest --cov --cov-report=term-missing
+run_step "pip-audit"         pip-audit
+
+printf '\n%d passed, %d skipped, %d failed\n' "$PASSED" "$SKIPPED" "$FAILED"
+if [ "$FAILED" -gt 0 ]; then
+  fail "verify.sh: failures detected"
+  exit 1
+fi
+ok "verify.sh: ok"
+exit 0

package/skills/finance-ops/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: finance-ops
+description: "Use when running the money side of a small company on a cash basis — building a rolling cash-flow forecast, reconciling the bank against the books, fixing a messy expense-category map, or driving a month-end close. Triggers: 'are we going to run out of cash', 'what's our runway', '13-week cash flow forecast', 'reconcile the bank statement', 'these two numbers don't match', 'the ending balance doesn't roll into next week', 'everything landed in Other expenses', 'close the books for May', 'what's our burn this month', 'tancar el mes', 'conciliar el banc amb els llibres', 'cuánto runway nos queda al ritmo actual'. NOT recording journal entries or payroll/depreciation postings (that is bookkeeping)."
+tags: [cash-flow, reconciliation, month-close, expense-categories, runway, small-business-finance]
+recommends: [bookkeeping, invoicing, financial-model, unit-economics, cost-tracking, forecasting, spreadsheet-ops]
+origin: risco
+---
+
+# finance-ops
+
+You are the controller for a small company run on a **cash basis**. Your job is not to post the ledger and not to send invoices — it is to answer four questions and leave proof: *is the company solvent, are the books trustworthy, did we close the month, and where will the cash run out.*
+
+Every engagement leaves behind one or more of **three checkable artifacts**:
+
+1. A **13-week rolling cash-flow forecast** (CSV/sheet) — the runway answer.
+2. A **reconciliation report** partitioning every bank line into matched / unmatched / needs-review.
+3. A **month-close checklist** with every gate marked done or blocked.
+
+`scripts/verify.sh` checks the *shape and internal consistency* of those artifacts (columns present, ending balance rolls forward, no unclassified bank lines, no silently-missing close gates). It does not judge whether the dollar figures are right — that is your job.
+
+## Pick the job first
+
+The flow genuinely branches. Decide which of the four you are doing before touching a sheet.
+
+| If the ask is… | You are doing | Artifact you produce | Reference |
+|---|---|---|---|
+| "will we run out of cash", "what's our runway", "13-week forecast", "burn rate" | **Forecast** | 13-week rolling forecast CSV | `references/cash-flow-forecast.md` |
+| "reconcile the bank", "these don't match", "what cleared" | **Reconcile** | matched/unmatched/needs-review report | `references/reconciliation.md` |
+| "set up categories", "everything's in Other", "how do I categorize this" | **Categorize** | tax-return-aligned category map | (inline below) |
+| "close the books for May", "what's left before we close" | **Close** | 5-day gate checklist | `references/month-close.md` |
+
+If the ask is actually about posting entries, sending invoices, or a multi-year model, stop and route — see **Hand-offs** at the bottom. Do not silently do another skill's job.
+
+## Cash-flow forecast
+
+The standard short-horizon tool is the **13-week rolling direct-method forecast**. Use it; do not invent a horizon.
+
+- **13 weeks = one quarter.** Short enough that every line maps to a *named* invoice or bill, not a statistical guess. Why: a week-by-week liquidity view is only trustworthy if each cell traces to real money you can point at.
+- **Rolling, not static.** Each week you drop the oldest week and add a new week 13. Why: a static forecast rots the day it's built; rolling keeps the runway answer current.
+- **Direct method only.** List actual cash receipts and disbursements by counterparty/category. Why: you can see exactly which payment to delay or which collection to chase. The indirect method (start from net income, adjust) is for statements, not weekly liquidity — never use it here.
+- **Enter inflows when cash *clears the bank*, not when the invoice is sent.** This single discipline is what makes the forecast trustworthy.
+  - Bad: book a $12k invoice in the week you emailed it.
+  - Good: read the AR aging, map the $12k to the week that customer's payment pattern says it clears (e.g. net-30 customer who always pays week 5).
+- **AR collections are typically 60–85% of inflows.** Map them from the AR aging report (which `invoicing` produces) to expected-collection weeks by each customer's payment behaviour.
+- **`ending_cash` of week *n* is the `starting_cash` of week *n+1*.** This rolling continuity is mandatory and `verify.sh` enforces it. A forecast where the balance doesn't carry forward is wrong, full stop.
+
+Required columns (the minimal shape `verify.sh` checks):
+
+```csv
+week_start,starting_cash,inflows,outflows,net,ending_cash
+2026-06-01,42000,18500,23100,-4600,37400
+2026-06-08,37400,9200,15800,-6600,30800
+```
+
+Per row: `net = inflows - outflows` and `ending_cash = starting_cash + net`. Break either invariant and the forecast lies.
+
+**Burn and runway are distinct — do not conflate them:**
+
+- **Burn** = net cash spent per month = average monthly `outflows - inflows` (positive number when you're losing cash).
+- **Runway** = `current cash balance ÷ net monthly burn` = months of life left.
+- Compute both from **actual cash transactions**, never from net income. Why: depreciation and unpaid invoices make accounting profit diverge from cash, and you live or die on cash.
+- **Runway < 12 months → flag it and name a lever** (delay an AP payment, accelerate a collection). Don't just report the number.
+
+Full column template, the AR-aging→week mapping recipe, a worked deficit walkthrough, and worked burn/runway numbers live in `references/cash-flow-forecast.md`.
+
+## Reconciliation
+
+Reconciling = compare **every** bank line to the cash-account entry in the books, then resolve the four classic gaps. Reconcile **early** in the close (days 1–2), not last — you need time to investigate exceptions.
+
+The four classic gaps to hunt for:
+
+1. **Outstanding checks** — written, not yet cleared the bank.
+2. **Deposits in transit** — received, not yet posted by the bank.
+3. **Bank charges / fees** — debited by the bank, not yet in your books.
+4. **Interest earned** — credited by the bank, not yet in your books.
+
+**Matching tiers — run them in order:**
+
+| Tier | Rule | Catches |
+|---|---|---|
+| 1. Exact | amount + date + reference all match | clean, identical transactions |
+| 2. Fuzzy | string-similarity score ≥ ~85–90 on description/ref, amount within tolerance | fee/rounding/description drift |
+| 3. One-to-many / many-to-one | one invoice paid in several transfers, or one transfer covering several invoices | split payments |
+
+Exact-only auto-matches ~60–70% of volume; adding fuzzy + many-to-many pushes auto-clear toward ~90%. Set the fuzzy threshold high (≥85) so you don't auto-pair two different vendors.
+
+**Every bank line lands in exactly one bucket — no orphans:**
+
+- **matched** — paired with a book entry (any tier).
+- **unmatched** — no candidate found; needs a book entry created (route the *posting* to `bookkeeping`) or is a true exception.
+- **needs-review** — a fuzzy candidate below auto-clear confidence, or a one-to-many split, awaiting human sign-off.
+
+A line that is silently dropped is a hole in the books. `verify.sh` fails if any line is unclassified. Matching-tier algorithm detail, fuzzy-threshold rationale, the exception decision table, and the report schema are in `references/reconciliation.md`.
+
+## Expense categories
+
+**Mirror the tax return; do not invent categories ad hoc.** For a US sole-prop that's the ~20 Schedule C lines (Advertising L8, Contract labor L11, Office expense L18, Rent L20a/b, Meals L24b, etc.). Why: if every operating category ties to a return line, close and filing reconcile and nothing falls through.
+
+- **No junk-drawer "Other expenses" (Schedule C L27).** Dumping spend there raises audit risk and destroys spend visibility.
+  - Bad: `$4,200 → Other expenses`.
+  - Good: `$4,200 → Advertising (L8) $1,800 + Office (L18) $900 + Contract labor (L11) $1,500`.
+- **Don't invent a category that has no return line.** If you can't map a spend to a line, that's a signal to ask, not to open a new bucket.
+- **Confirm the current-year numbers — never carry last year's.** As of the 2025/2026 anchors:
+  - Business standard mileage: **70¢/mile for 2025** (IRS Notice 2025-5), rising to **72.5¢/mile for 2026**. Re-confirm the year before applying.
+  - Business meals deductible at **50%** (book them at a rate that preserves the 50% haircut, e.g. category L24b).
+  - **1099-NEC required for any contractor paid ≥ $600/yr** — flag contractors crossing that line during categorization so nothing is missed at filing.
+
+Categories are the one job here with no separate reference file — the rule (mirror the return, no junk drawer, confirm current-year numbers) is the whole skill.
+
+## Month-close
+
+Closing is a **sequenced 5-day checklist, not an event.** Target for a small business: books closed in **≤5 days**.
+
+| Day | Gate | Done when |
+|---|---|---|
+| 1–2 | Transaction cleanup + bank/card reconciliation | every account reconciled, report has zero orphans |
+| 3 | Payroll & journal entries (posted by `bookkeeping`, *verified* here) | payroll + recurring journals confirmed posted |
+| 4 | AR/AP review + expense categorization | aging reviewed, no spend left in Other |
+| 5 | Reporting + final close | close package assembled, period locked |
+
+**Reconcile early (days 1–2), not last** — the most common close failure is discovering an unmatched bank line on day 5 with no time to chase it.
+
+The close artifact is a checklist where **every required gate is present and marked done or blocked** — a silently-missing gate is treated as a failure by `verify.sh`. Full day-by-day done-criteria and the close-package contents list are in `references/month-close.md`.
+
+## Anti-patterns
+
+| Anti-pattern | Why it's wrong | Do instead |
+|---|---|---|
+| Indirect method for weekly liquidity | Net-income-derived numbers can't tell you which payment to delay | Direct method: actual receipts/disbursements by counterparty |
+| Booking inflows on the invoice date | Cash you haven't received can't pay bills; the forecast over-states liquidity | Book to the expected-clear week from the AR aging |
+| `ending_cash` that doesn't carry to next `starting_cash` | The runway number is then meaningless | Enforce `ending_cash[n] == starting_cash[n+1]` (verify.sh checks it) |
+| Exact-match-only reconciliation | Leaves ~30–40% of volume unmatched and demoralizing | Run exact → fuzzy (≥85) → one-to-many tiers |
+| Junk-drawer "Other expenses" | Audit risk + zero spend visibility | Map every line to a tax-return category |
+| Carrying last year's mileage rate | 70¢ (2025) vs 72.5¢ (2026) silently mis-states deductions | Re-confirm the current-year IRS rate every time |
+| Computing runway from net income | Depreciation & unpaid invoices make profit ≠ cash | Runway = cash balance ÷ net monthly cash burn |
+| Closing before reconciling | Day-5 surprises with no time to fix | Reconcile on days 1–2, close on day 5 |
+| Posting journal entries here | That's `bookkeeping`'s job; finance-ops only checks the ledger | Route the posting; verify it landed |
+
+## Hand-offs
+
+You consume and check the ledger and AR; you do not own them. Route deliberately:
+
+- **Recording journal entries, payroll postings, depreciation schedules, double-entry** → `../bookkeeping/SKILL.md`. finance-ops *verifies* those landed; it does not post them.
+- **Creating/sending invoices, dunning, AR-collection emails, payment links** → `../invoicing/SKILL.md`. You read the AR aging it produces.
+- **Multi-year projections / scenario model for a raise** → `../financial-model/SKILL.md`. The 13-week forecast is liquidity, not a fundraising model.
+- **CAC / LTV / contribution margin** → `../unit-economics/SKILL.md`.
+- **Per-unit COGS / infra / AI spend tracking** → `../cost-tracking/SKILL.md`.
+- **Demand / revenue projection beyond 13 weeks** → `../forecasting/SKILL.md`.
+- **Sheet mechanics, pivots, formula plumbing** → `../spreadsheet-ops/SKILL.md`.

package/skills/finance-ops/evals/README.md

@@ -0,0 +1,3 @@
+# Evals — finance-ops
+
+Run the cases in `cases.yaml` against the skill. For each `should_trigger` prompt, confirm finance-ops activates and heads for the right one of its four jobs (forecast / reconcile / categorize / close); the non-obvious ones (the rolling-balance symptom, the "Other expenses" dump) and the Catalan/Spanish phrasings are the ones worth watching. For each `should_not_trigger` prompt, confirm the skill *declines* and routes to the named sibling — posting entries goes to `bookkeeping`, invoices/dunning to `invoicing`, the fundraising model to `financial-model`, CAC/LTV to `unit-economics`. The `capability` case is graded against its `must_include` rubric by hand or by an LLM judge. Separately, `scripts/verify.sh <dir>` validates the *emitted artifacts* (forecast CSV, reconciliation report, close checklist) for shape and rolling continuity — that columns exist, `ending_cash` rolls into the next `starting_cash`, every bank line is classified with no orphans, and every close gate is present and marked — not whether the dollar figures themselves are correct. It is read-only and exits 0 on an empty or clean target.

package/skills/finance-ops/evals/cases.yaml

@@ -0,0 +1,39 @@
+skill: finance-ops
+
+should_trigger:
+  - prompt: "Build me a 13-week cash flow forecast so I know if we're going to run out of money."
+    why: Core forecast job — the rolling direct-method runway artifact this skill owns.
+  - prompt: "Reconcile last month's bank statement against our books and flag whatever doesn't match."
+    why: Core reconciliation job — produce the matched/unmatched/needs-review report.
+  - prompt: "Tancar el mes de maig — què em falta abans de tancar els llibres?"
+    why: Catalan month-close phrasing; non-obvious that this is the close checklist, not bookkeeping.
+  - prompt: "Everything got dumped into 'Other expenses' — can you fix our categories?"
+    why: Non-obvious symptom phrasing for the categorize job (mirror the tax return, kill the junk drawer).
+  - prompt: "¿Cuánto runway nos queda al ritmo de gasto actual?"
+    why: Spanish burn/runway phrasing; runway must be computed from actual cash, a finance-ops call.
+  - prompt: "The ending balance in my cash sheet doesn't roll into the next week's starting balance — is the forecast broken?"
+    why: Non-obvious — the rolling-continuity invariant is exactly what finance-ops (and its verify.sh) enforces.
+
+should_not_trigger:
+  - prompt: "Post the May payroll and the depreciation journal entries into the ledger."
+    route_to: bookkeeping
+    why: Recording journal entries and payroll/depreciation postings is bookkeeping; finance-ops only verifies they landed.
+  - prompt: "Send invoices to these 8 clients and chase the three that are overdue."
+    route_to: invoicing
+    why: Creating/sending invoices and dunning is invoicing; finance-ops only reads the AR aging it produces.
+  - prompt: "Build a 3-year financial model with scenarios for our seed round."
+    route_to: financial-model
+    why: Multi-year fundraising projections are financial-model; the 13-week forecast is liquidity, not a raise model.
+  - prompt: "What's our CAC and LTV broken down by acquisition channel?"
+    route_to: unit-economics
+    why: CAC/LTV/contribution margin is unit-economics, not cash-side controllership.
+
+capability:
+  - scenario: "Given a starting cash balance of $42,000, an AR aging snapshot (open invoices by customer with terms and observed days-to-pay), and recurring monthly outflows (payroll, rent, AP, a quarterly tax payment, a loan payment), produce a 13-week rolling cash-flow forecast and identify the first week the company goes cash-negative, with a concrete lever to fix it."
+    must_include:
+      - Uses the direct method with weekly columns (week_start, starting_cash, inflows, outflows, net, ending_cash).
+      - Times inflows to each customer's expected-clear week from the aging, not the invoice date.
+      - Carries ending_cash[n] into starting_cash[n+1] (rolling continuity) and computes net = inflows - outflows per row.
+      - Computes burn and runway from actual cash, not net income; flags runway if under 12 months.
+      - Names the first negative-ending week and proposes a concrete lever (delay an AP payment, move the tax payment, or accelerate a collection).
+      - Routes any request to post ledger entries to bookkeeping rather than doing it.

package/skills/finance-ops/references/cash-flow-forecast.md

@@ -0,0 +1,57 @@
+# Cash-flow forecast — 13-week rolling, direct method
+
+The full template behind the forecast section of `SKILL.md`. Use the direct method: every cell traces to a named invoice or bill.
+
+## Full column template
+
+A practical forecast splits inflows and outflows into named lines so you can see *which* lever to pull. The minimal shape `verify.sh` checks is the six-column rollup (`week_start, starting_cash, inflows, outflows, net, ending_cash`); keep the detail columns alongside and sum them into `inflows`/`outflows`.
+
+```csv
+week_start,starting_cash,AR_collections,other_inflows,inflows,payroll,AP,rent,tax,loan,other_outflows,outflows,net,ending_cash
+2026-06-01,42000,16000,2500,18500,12000,7100,3000,0,1000,0,23100,-4600,37400
+2026-06-08,37400,8200,1000,9200,0,9800,0,0,1000,5000,15800,-6600,30800
+2026-06-15,30800,14500,0,14500,12000,6300,0,4200,1000,0,23500,-9000,21800
+```
+
+Invariants per row:
+- `inflows = AR_collections + other_inflows`
+- `outflows = payroll + AP + rent + tax + loan + other_outflows`
+- `net = inflows - outflows`
+- `ending_cash = starting_cash + net`
+- `ending_cash[n] == starting_cash[n+1]` (rolling continuity — the spine of the forecast)
+
+## AR-aging → week mapping recipe
+
+Inflows are 60–85% of the forecast and the easiest place to lie to yourself. Map them, don't guess.
+
+1. Pull the AR aging report (open invoices by customer, with invoice date and terms) from `invoicing`.
+2. For each open invoice, compute an **expected-clear week** = invoice date + that customer's *observed* days-to-pay, not the contractual terms.
+   - Customer pays net-30 on paper but historically clears at day 44 → use day 44.
+   - A chronically-late customer → push to the conservative end or split across two weeks.
+3. Place the amount in the `AR_collections` cell for that week.
+4. Anything past 90 days with no payment pattern: do **not** book it as an inflow. If you want partial credit, haircut it (e.g. 50%) and footnote the assumption.
+
+Conservative inflow timing is the discipline that makes the runway answer trustworthy. When in doubt, book it a week later.
+
+## Worked deficit walkthrough
+
+From the CSV above, week of 2026-06-15 ends at $21,800 — still positive, but watch the slope: three straight negative-net weeks (-4,600, -6,600, -9,000). Project the next rows and you cross zero around week 6–7.
+
+The direct method tells you the lever immediately because every line is named:
+- The $4,200 **tax** payment in week 3 is the spike. If it's an estimated payment with a later deadline, moving it one week buys headroom.
+- The $9,800 **AP** in week 2 — check which vendors. Two of them are net-45 and could clear in week 4 instead, smoothing -6,600 across two weeks.
+- On the inflow side, the $16k week-1 AR includes one $9k invoice from a customer who has paid early before — a polite nudge from `invoicing` could pull it forward.
+
+Pick the smallest-friction lever that keeps every `ending_cash` positive. Document which lever you pulled in the forecast notes.
+
+## Burn and runway — worked numbers
+
+Use actual cash, not accounting profit.
+
+- Sum the last 3 months of `net` from real cleared transactions. Say it's -$5,400, -$6,100, -$5,800 → average net = **-$5,767/month**, so **burn ≈ $5,767/month**.
+- Current cash balance = $42,000.
+- **Runway = 42,000 ÷ 5,767 ≈ 7.3 months.**
+
+7.3 < 12 → flag it. Report: "Runway ~7 months at current burn. First negative-ending week is ~week 7. Levers: delay the week-3 tax payment, smooth the week-2 AP, or pull the early-paying $9k invoice forward." Never report runway as a bare number without a lever.
+
+If profit and cash disagree (common with depreciation or a big unpaid invoice), trust cash for runway and route the profit question to `bookkeeping`.

package/skills/finance-ops/references/month-close.md

@@ -0,0 +1,59 @@
+# Month-close — the 5-day sequenced checklist
+
+The detail behind the close section of `SKILL.md`. Close is a sequence, not an event. Target: ≤5 days for a small business. Reconcile early so day-5 surprises have nowhere to hide.
+
+## Day-by-day gates with done-criteria
+
+Each gate has a concrete "done when" — the close artifact marks each one `done` or `blocked` (with a reason). A silently-missing gate is a failure, not a pass.
+
+### Day 1–2 — Transaction cleanup + bank/card reconciliation
+- Pull all bank and card statements for the period.
+- Run the reconciliation tiers (see `reconciliation.md`).
+- **Done when:** every account reconciled and the reconciliation report has **zero orphans** (every line matched / unmatched / needs-review). Any unmatched line has an owner and a next action.
+
+### Day 3 — Payroll & journal entries
+- Confirm payroll for the period is run and the payroll journal is posted.
+- Confirm recurring journals (accruals, prepaids, depreciation) are posted.
+- **These postings belong to `bookkeeping`** — finance-ops *verifies* they landed; it does not create them.
+- **Done when:** payroll + all recurring journals confirmed posted; any missing one is `blocked` with the owner named.
+
+### Day 4 — AR/AP review + expense categorization
+- Review AR aging (from `invoicing`): who's overdue, what's collectible, what to write off.
+- Review AP: what's due, what to delay (feed this into the forecast).
+- Categorize the period's spend against tax-return lines.
+- **Done when:** aging reviewed, no spend left in "Other expenses", contractors crossing the 1099-NEC ≥$600 threshold flagged.
+
+### Day 5 — Reporting + final close
+- Assemble the close package (below).
+- Lock the period so no back-dated entries land silently.
+- **Done when:** package assembled and reviewed, period locked, next month's forecast rolled forward one week.
+
+## The close package contents
+
+What "closed" produces — hand this to whoever needs the monthly read:
+
+1. **Reconciliation report** for every bank/card account (matched / unmatched / needs-review, zero orphans).
+2. **The refreshed 13-week forecast** with the just-closed week's actuals folded in and a new week 13 added.
+3. **Burn and runway** for the closed month, computed from actual cash.
+4. **Expense summary by tax-return category** (no "Other" junk drawer).
+5. **AR/AP snapshot** — overdue collections, upcoming payables, anything to write off.
+6. **The close checklist itself** — every gate marked `done` or `blocked` with reasons.
+
+## Close checklist artifact shape
+
+`verify.sh` checks the checklist has every required gate present and marked. Minimal shape:
+
+```csv
+gate,day,status,note
+transaction_cleanup,1,done,
+bank_reconciliation,2,done,zero orphans
+payroll_journals,3,done,posted by bookkeeping
+recurring_journals,3,blocked,depreciation entry pending
+ar_ap_review,4,done,
+expense_categorization,4,done,no Other
+reporting_final_close,5,done,period locked
+```
+
+Rules:
+- Every required gate row is present — a missing gate is treated as a failure, not an implicit pass.
+- `status` is `done` or `blocked`; a `blocked` gate must carry a `note` saying why and who owns it.

package/skills/finance-ops/references/reconciliation.md

@@ -0,0 +1,65 @@
+# Reconciliation — matching tiers, thresholds, report schema
+
+The detail behind the reconciliation section of `SKILL.md`. Goal: every bank line classified, zero orphans, exceptions surfaced early.
+
+## The matching algorithm
+
+Run the tiers in order. A bank line stops at the first tier that produces a confident match; otherwise it falls through to the next.
+
+### Tier 1 — exact
+Match on `amount + date + reference` (or amount + date when no reference). This is the cheap, certain tier and clears the bulk of clean transactions. Auto-matches ~60–70% of volume on its own.
+
+### Tier 2 — fuzzy
+For lines exact-match missed, score candidate book entries by string similarity on description/reference, with amount inside a small tolerance.
+
+- Use a normalized similarity (e.g. Levenshtein-ratio or token-set ratio) scaled 0–100.
+- **Auto-clear threshold ≈ 85–90.** Why this band: below ~85 you start auto-pairing genuinely different vendors ("ACME LLC" vs "ACME LTD" can be different entities); above ~90 you reject legitimate fee/rounding/description drift ("STRIPE PAYOUT" vs "Stripe payout #4821"). 85–90 is the empirical sweet spot.
+- Amount tolerance handles bank fees and FX rounding: allow a few cents or a known fee delta, not arbitrary slack.
+- A fuzzy hit **at or above** threshold → matched. **Below** threshold but plausible → needs-review, never silently matched.
+
+### Tier 3 — one-to-many / many-to-one
+Handles split payments: one invoice paid in several transfers, or one bank deposit covering several invoices.
+
+- Search for subsets of book entries whose sum equals the bank line (and vice versa) within tolerance.
+- A clean sum match can auto-clear; an ambiguous combination → needs-review with the candidate set attached.
+
+Exact + fuzzy + many-to-many together push auto-clear toward ~90%. The remaining ~10% is where a human earns their keep — that's the needs-review pile.
+
+## The four classic gaps
+
+When the bank balance and book balance disagree, the cause is almost always one of these. Resolve them before declaring a discrepancy a real error:
+
+| Gap | Symptom | Resolution |
+|---|---|---|
+| Outstanding checks | Book shows payment, bank doesn't | Leave as timing diff; clears when check is cashed |
+| Deposits in transit | Book shows deposit, bank doesn't yet | Leave as timing diff; clears next statement |
+| Bank charges / fees | Bank debit not in books | Route a fee entry to `bookkeeping`; classify line as unmatched-needs-entry |
+| Interest earned | Bank credit not in books | Route an interest entry to `bookkeeping` |
+
+## Exception decision table
+
+| Situation | Bucket | Next action |
+|---|---|---|
+| Exact or fuzzy ≥ threshold | matched | none |
+| Clean one-to-many sum | matched | none |
+| Fuzzy below threshold, single plausible candidate | needs-review | human confirm/reject |
+| No candidate at all, but is a known fee/interest | unmatched | route posting to `bookkeeping` |
+| No candidate, unrecognized counterparty | unmatched | investigate before close |
+| Duplicate bank line (double charge) | needs-review | dispute / flag to bank |
+| Ambiguous split (multiple subsets sum) | needs-review | human pick the right set |
+
+## Report schema
+
+The artifact `verify.sh` checks. Every bank line appears exactly once with a `status` of `matched`, `unmatched`, or `needs-review` — no line may be absent or carry any other status.
+
+```csv
+bank_line_id,date,amount,description,status,match_ref,note
+B0012,2026-05-03,-1200.00,STRIPE PAYOUT 4821,matched,INV-204,exact
+B0013,2026-05-04,-15.00,MONTHLY SERVICE FEE,unmatched,,fee-needs-entry
+B0014,2026-05-06,-980.00,ACME,needs-review,INV-198?,fuzzy-72-below-threshold
+```
+
+Rules:
+- `status` is one of `matched | unmatched | needs-review` — `verify.sh` rejects anything else and rejects a missing status.
+- `matched` rows should carry a `match_ref`; the others may leave it blank.
+- The three buckets must partition the full bank statement — count of rows in the report equals count of lines on the statement.