Today — Thursday 30 July 2026

High priority

• HIGHFO83patrimonia / incard webhook · **Add the CF Access bypass Application for `ledger.patrimonia.co.uk/api/incard/webhook`** (policy Bypass + Everyone, same recipe as the existing "FO Inbound Webhook" exception) — this is the one manual step left from the 2026-07-24 production wiring (bank-feed.md § Incard). Confirmed still missing 2026-07-25: a real £1,250 USD `ochrana LLC` credit arrived signature-valid at the tap but never reached `incard_tx_raw` because the forward hit the Access login wall; manually replayed straight to localhost as a workaround (now staged + showing in the review queue), but every future Incard event will silently sit in the tap's KV-only inspection log until this Access Application exists.2026-07-25
• HIGHFO80folium / VAT · **VAT number arrived 2026-07-24: 523486976.** (1) ✅ done 2026-07-24: `vatNumber` set on folium-ltd in `entities.ts` SEED + reconciled (`estate:init`) — invoice docs now automatically render as full VAT invoices (breakdown + "VAT No. 523486976"). (2) ✅ done 2026-07-24: FS-2026-011 (Eden Brooke) + FS-2026-016 (Hoban Design) — both already emailed+paid gross during the pending window, so needed a "paid in full, no payment due" reissue rather than a fresh bill. Built `alreadyPaid` mode into `invoice-renderer.ts`/`invoice-send.ts` (write-app.md § Paid-in-full VAT reissue) and sent both via `src/dev/send-vat-reissue-2026-07-24.ts` — landed correctly (£111.60, £90.00, VAT No. printed, no payment instructions). (2b) ⚠️ **reverted 2026-07-24:** FS-2026-012 (£2,265 → £2,718) and FS-2026-013 (£275 → £330) were uplifted, then the uplift itself exposed that both were raised 8-9 months before their real due dates (2027-02-27 / 2027-03-01 — recurring-billing placeholders from FO22 that were never properly scheduled) — a premature tax point was inflating Q3 output VAT by £508 for services not due until next year. **Fully voided instead** (uplift journal reversed, then the raise itself, via `src/dev/void-fs-2026-012-013-premature-2026-07-24.ts`) — Q3 output VAT confirmed back to £33.60 (Hoban + Brooke only). See FO82 for the proper fix. FS-2026-008/009/010 are pre-reg — **stay flat, never uplift**. **Still open:** (3) first return: pre-reg reclaims — services 6 months back, goods 4 years (incl. the planned PCs, which must be bought **in Folium's name**); the 1180 balance is the running claim. (4) **FS-2026-017 raised 2026-07-24** (£4,247.00 + £849.40 VAT = £5,096.40, dated 2026-08-01, `src/dev/raise-fs-2026-017-vitacol-2026-07-24.ts`) — the first Vitacol invoice at full VAT rate. **Vitacol confirmed VAT-registered (owner, 2026-07-24)** — the recoverability concern is resolved. Still not actually emailed — send is a separate step (heads-up conversation may already be owner's job outside this system). (5) Set `vat_scheme` with the accountant — **standard/accrual, NOT Flat Rate** (limited-cost-trader 16.5% loses ~£166/mo; full analysis in compliance.md).2026-07-11
• HIGHFO74inveritate-uk / tenancy · **3 Moyle Hill — set tenant fields before go-live.** `raise-rent.ts` skips this property because `detail.tenancy` is missing `tenantContactId`, `rentAccountId`, `active`, `startDate`, and `dayOfMonth`. When the new tenant moves in, update the asset via the API: add those five fields (model: 34 Brooklands — `tenantContactId: <CRM contact id>`, `rentAccountId: "acc_inveritate-uk_4000"`, `active: true`, `startDate: "YYYY-MM-DD"`, `dayOfMonth: 1`). Without them, no rent invoices will auto-generate each month. Monthly rent is £650 (`monthlyMinor: 65000`) — already in the asset.2026-07-01
• HIGHFO73ledger / payroll · **When PAYE reference arrives (~2 weeks):** run first payroll for Jody (Folium) + Diana (Shinepics) covering June/July; post salary journals (Dr Wages / Cr DLA) to reverse the 2026-06-29 £500 advance each; pay HMRC PAYE/NI via bank transfer; check whether DLA net positions need any further adjustment. See write-app.md § "Pre-PAYE salary advances" for the reversal pattern + account refs (folium 1200, shinepics 1201). **Also at this checkpoint (added 2026-07-05): Miabella — a wage was paid as a DL from Wise, leaving books Wise (GBP) −£55.92 and Cash −£214.89 after the £2,000 Wise→Monzo transfer posted; reverse and re-post as wages from Monzo when registered as employer. Wise is forex-only going forward — expect these negatives to clear here, else revisit.**2026-06-29
• HIGHFO72crm / invoices · when an invoice is raised for a brand-new contact, `contacts.counterparty_id` is not written back — causes the deposit-payment auto-advance to `booking` to silently skip (lookup `contacts WHERE counterparty_id = ?` returns nothing). Fix at invoice-creation time: after resolving/creating the counterparty, update the contact row. See crm-spine.md § "Gotcha — auto-advance requires contacts.counterparty_id". **2026-07-08:** two more affected contacts backfilled manually (Christine Preston, Mairead Roberts); the pipeline *value* lookup now has an email+entity fallback so display self-heals, but the deposit-payment auto-advance still needs the real back-link — root fix still open. **2026-07-15:** root fix shipped — `POST /api/invoices` now back-links any orphan contact (matched by email) when it creates a new counterparty (done alongside the invoice→booking work, crm-spine.md § import gap); verified on a scratch DB. Awaiting owner sign-off on a real raise before closing.2026-06-27
• HIGHFO67shinepics-ltd / ledger · ensure raising journal + paid_minor are GL-backed on all new invoices — fix going forward, NOT a backfill of historic. Symptom found on WP-2026-005 (Luke and Ruth): invoice header carries paid_minor £50 + total £285 but `invoices.journal_id IS NULL` and no journal_lines reference the invoice (raising journal + £50 deposit both off-book in the GL). The £235 cash receipt posted 2026-06-16 is the only Luke/Ruth row in the GL; AR for that counterparty reads net Cr £235 because there's no offsetting Dr from the raise. Going-forward fix: assert invoice.journal_id NOT NULL on insert + invariant `paid_minor == SUM(journal_lines.credit_minor WHERE account_id=AR AND invoice_id=invoice.id)` at sync time. Don't patch existing rows.2026-06-16
• HIGHFO42crm / clients · add edit capability to clients — currently read-only (just headings, not fully readable); need full CRUD for client contact/profile data2026-06-13
• HIGHFO22CRM / billing · clients need invoices raised and recurring billing set up — 9 counterparties seeded 2026-06-12 from Customers.csv (andrew@waglandtextiles.com, bedatec, CW Make A Difference, Eden Brooke, Jackson Toms, PMC Rentals, Samantha Carbon, Staffs Council, We Are Lumina) via `src/dev/import-folium-customers.ts`. First invoices done. Remaining: test recurring billing setup + decide recurring cadence/product line per the amounts in Customers.csv.2026-06-12
• HIGHFO18property / rental deposit · start process of refund against rental deposit scheme2026-06-12

Med

• MEDFO82folium / crm / billing · **Build proper recurring billing — raise-at-due-date, not raise-8-months-early.** FO22 seeded 9 recurring invoices in one batch (`seed-folium-clients.ts`, 2026-06-14) including two set for 2027 renewal dates (FS-2026-012 Andrew Wagland 2027-02-27, FS-2026-013 Staffs Council 2027-03-01) — raised immediately instead of at their actual due date, which pulled a false VAT tax point into the current quarter once VAT-uplifted (found + fixed 2026-07-24, see FO80). Need an actual scheduling mechanism: each recurring product/counterparty carries its cadence + next-due-date; a job raises the invoice a sane window before that date (e.g. 30 days), not all at once at seed time. Scope: (1) design the cadence model (annual/monthly, anchor date) — probably a `recurring_billing` table keyed by counterparty+product; (2) a cron/dev-triggered job that raises due invoices in the window and skips the rest; (3) re-raise FS-2026-012 (Exchange mailboxes ×16 £1,840 + Promotional email £425, due ~2027-01-28) and FS-2026-013 (Annual web hosting £275, due ~2027-01-30) through the new mechanism once built, rather than by hand.2026-07-24
• MEDFO81miabella / payroll · **When the Miabella PAYE reference arrives:** reverse the pre-PAYE salary advances to Mia and run the real payroll. Mia is the only payroll musician; until PAYE exists Jody has been paying her **from his own pocket, logged through 1010 Cash** with the director's loan (1200) as the other leg — e.g. 2026-07-01 Dr 1200 £500 / Cr 1010 £400 + Cr 1030 £100. **The Miabella cash account is therefore ~£214.89 NEGATIVE and that is EXPECTED, not a bug — do not 'tidy' it** (owner confirmed 2026-07-20); it unwinds when the advances reverse against salary. Per-gig performer fees (Colm, Aaron) are unrelated: outside PAYE, tagged person+booking, already clean. Mechanism: ledger.md § pre-PAYE salary advances. Owner will review properly once the ref is in hand.2026-07-20
• MEDFO80operator-app / entity dashboard · build the entity **Inbox tab** as an OPERATIONAL work-queue, not a feed of the dev `_inbox.md` items (agreed 2026-07-09: those stay in the cross-project /today rollup). Sources, all per-entity from data we already hold: bank-feed statement lines awaiting review · open AR invoices due / AP bills payable · `compliance.json` items filtered by the existing `entity` field · period-close checklist. Stub + intent already marked in `master/app/src/views/Dashboard.jsx` header comment. Possible later: /today or the Hub shows a one-line-per-entity rollup ("Patrimonia: 4 unmatched lines, 1 bill due, VAT in 12d") linking into each entity's Inbox tab.2026-07-09
• MEDFO78crm / pipeline · sibling-delete only fires on advance to `won` — leads sent to `lost` (e.g. QuoteComposer "Already booked" / unavailable-send.ts) strand their duplicate enquiry at the enquiry stage. Fix: run the same same-contact+entity sibling sweep on advance to `lost` and `booking` too (incl. inside unavailable-send). Related but probably not worth automating: mangled-email double-submits (partial form fire) create a *different* contact so contact-keyed dedup can't see them — manual cleanup per crm-spine.md § "Known gaps in the sibling-delete".2026-07-08
• MEDFO79entities / compliance · **Register MIABELLA MUSIC LIMITED (Co. 17313977) in the estate** — new UK Ltd, registered office: Unit 29 Highcroft Industrial Estate, Enterprise Road, Horndean, Waterlooville, Hampshire, PO8 0BT. Add to the entities.ts SEED (registration facts live there, not DB edits) + compliance store (CT/accounts/CS deadlines once confirmation statement dates known). miabella.uk footer/terms/privacy already present the Ltd as site operator + data controller (updated 2026-07-08).2026-07-08
• MEDFO77ar / selftest · `src/ar/selftest.ts` has ONE pre-existing failure: "ageing @06-30: 6000 outstanding in 31-60" gets all-zero buckets. Confirmed NOT caused by the 2026-07-07 invoice changes (fails identically on unmodified code via git stash). Suspect `arAgeing` as-of-date logic or the test's fixture dates. 21/22 pass. NOTE for FO67's future invariant: since 2026-07-07 a fully-free (£0-total) invoice legitimately has `journal_id IS NULL` — the "assert journal_id NOT NULL on insert" check must allow `total_minor = 0`.2026-07-07
• MEDFO76ledger / bank feed · **"Receive payment" on money-in review lines** — the AR mirror of the Pay-bill panel: list open invoices fitting the line amount (same FX tolerance max(3%, 50p), same exact/part ranking), one click settles the invoice via the AR machinery + posts the journal FROM the line (born confirmed, nothing to match later) + optional **"send confirmation email"** tick reusing the Clients-flow send path. Why: today the Clients screen is the only place that settles+emails, so every customer receipt is marked paid there first and becomes a match-chore in the feed queue (Atmosphere MM-2026-004, 2026-07-05). Makes the feed the PRIMARY place incoming payments are processed; email timing then tracks money actually arriving. **2026-07-18:** the settle panel is live and grew a multi-invoice arm (one Stripe payout bundling several invoices — tick-to-combine, one combined journal; write-app.md § multi-invoice settle). Still outstanding from this item: the optional "send confirmation email" tick.2026-07-05
• MEDFO68shinepics-ltd / ledger · record £50 cash deposit dated 2026-06-01 for WP-2026-005 (Luke and Ruth) — the deposit lives in `invoices.paid_minor` but has NO GL journal backing it (manual post needed: Dr 1010 Cash £50 / Cr 1100 Debtors £50, journal_date 2026-06-01, link `invoice_id` on the AR line). Pairs with FO67 (the going-forward fix) — this is the one historical patch we'll do for this invoice; everything else stays as-is per FO67's no-backfill stance.2026-06-16
• MEDFO64published / thoughts · scaffold `/published/thoughts` in the FO published shell + Patrimonia voice — an annual "letter to the kids on why we are doing this" (ethical will / statement of intent); index holds one entry per year (e.g. "2026 — Why we began"). Doubles as a documented non-tax motive for defensibility. Architecture: patrimonia.co.uk = outward face · /published/thoughts = inward/family face · letter-of-wishes + deed = private. Claude scaffolds the page/index; the letter content stays the owner's to write.2026-06-16
• MEDFO69ledger / inter-co · **METHODOLOGY SETTLED 2026-06-20** — intercompany pass-through invoicing: Miabella invoices Shinepics (not the other way; original entry had the direction wrong). Pattern: SP invoices the client for the full package (photo/video + music addon at cost); Mia invoices SP for the exact same music line-item amount — SP takes zero margin on the music booking. Only exception: evening band bookings where Mia invoices the client direct. Settled answers to original open questions: **(a) VAT** — Mia is NOT VAT-registered so her invoice to SP carries no VAT; clean, no recovery question. **(b) Transfer pricing** — no arm's-length problem: SP takes zero margin, so profit if anything flows toward Mia not away; below-market rate is legitimate (shared marketing, transport, brand — real structural cost advantage, not artificial); document once (not per-invoice) that Mia's rate reflects shared family-entity cost base; if Mia subs out a musician that is Mia's cost, SP never sees those third-party suppliers. **(c) Counterparty records** — add Miabella-uk-ltd as a supplier under `shinepics-ltd` + SP as a client under `miabella-uk-ltd`, both flagged `intercompany=1`. **(d) Journal mirror** — Mia: Dr 1100 Debtors (SP) / Cr 4000 Revenue; SP: Dr 6xxx Intercompany recharge — music / Cr 2100 Creditors (Mia); SP's client invoice: Dr 1100 Debtors (client) / Cr 4000 Revenue (full package); settlement: Dr 2100 / Cr 1010 Cash. SP CoA needs `6xxx Intercompany recharge — music` nominal adding. **(e) Elimination** — tag both legs `intercompany=1` (or `counterparty=related-entity` flag on journal_lines); consolidated view nets AR↔AP and Mia revenue↔SP expense to zero; only client-facing SP revenue survives. **Remaining implementation work:** ~~(1) add intercompany supplier/client counterparty records~~ ✅ done 2026-06-20; ~~(2) add SP nominal `6xxx Intercompany recharge — music`~~ ✅ done 2026-06-20 (nominal 6200); (3) add `intercompany` flag to counterparties + journal_lines (or a derived elimination view); (4) add one-off rate-setting note to docs/CONTEXT.md or entities.md; (5) wire up the AP bill path in SP + AR invoice path in Mia for this class of booking via UI (currently requires dev script).2026-06-16
• MEDFO63ledger / banking · add inter-bank transfer UI to operator app — currently manual dev scripts only; add UI to post balanced transfers between nominals (e.g. Patrimonia Revolut → ANNA). **2026-07-26:** another manual instance — the £700 Revolut→Incard transfer (`transfer-revolut-to-incard-gbp-2026-07-22.ts`) that surfaced the Incard webhook gap now has evidence on BOTH sides (incard-feed + gocardless-feed) sitting unmatched in the review queue; posted the journal + matched both lines by script since there's still no UI path for "this staged line is one leg of a transfer I need to post the other leg of." A transfer UI would ideally do this in one step: pick two accounts + an amount, post the journal, auto-offer matching against any staged lines it satisfies.2026-06-15
• MEDFO62crm / enquiries · handle enquiries where dates are taken — exclude from quote-counting metrics, auto-move to archive (date-taken status)2026-06-15
• MEDFO56crm / quotes · venue reviews in quotes — capture review/testimonial data per venue so shinepics quotes pull relevant social proof (e.g. "Emma & Daniel · Belfast Castle" instead of generic "Emma & Daniel"). Default to generic testimonial if no venue-specific reviews exist. Unlock: populate a `venues` table (reference from bookings/enquiries) + optional `reviews` table (venue_id, quote, attribution) — quotes builder prefills from that data on preview. Low-friction capture: operator adds review directly in quotes UI or via admin.2026-06-14
• MEDFO59miabella · email / migrations · mailchimp → Resend migration — use mail-chim-mia-import.csv to migrate contacts and send pure HTML emails2026-06-14
• MEDFO38CRM / comms · cannot start a new comms thread from a client — no "New message" / compose button exists outside of invoice-send flow2026-06-13
• MEDFO55crm / venues · central venue listing — first-class `venues` table (name + address + optional contact details) so booking entry picks from a canonical list instead of re-typing. Bookings reference a `venue_id`; address captured once and reused everywhere it's needed. Direct unlock for FO54 (calendar address sync) and a cleaner data source for FO53 (cross-brand calendar).2026-06-13
• MEDFO53crm / calendar · cross-brand calendar view — single visual showing bookings/events across every brand. Placement TBD (portfolio tab / operator-app shell / dedicated published page). Now unblocked: the Google Calendar integration is live, so the data is there to fan out.2026-06-13
• MEDFO46crm / weddings · send run sheet to bride 7 days before wedding for last-minute changes — automated email with event details/timeline2026-06-13
• MEDFO41crm / bookings · "On The Day" PWA — small JSON-driven standalone site per booking, renders client wishlist as checklist so items can be marked off; prevents post-event "you didn't do this" disputes2026-06-13
• MEDFO37ledger / chatbot · add a chatbot to the ledger that has access to the full corpus2026-06-13
• MEDFO31CRM / operator-app · add Bookings section to daily inbox showing per-client booking workflow stages (quote → book → invoice → payment received → thank you → what to expect) as horizontal progress bars with completion status2026-06-12
• MEDFO27Global / dashboard · new dashboard — visual here /home/jody/repos/family-office/docs/archive/pipeline-todo/design/master-overview-dashboard.html2026-06-12
• MEDFO17dashboard · change primary dashboard visuals2026-06-12
• MEDFO26Inveritate UK / payments · chase UC for payment from Ballywalter2026-06-12
• MEDFO3ledger / holding-structure · **Monthly DLA sweep — holdco assumes each sub's director's loan** so subs carry no DLA, just an intercompany balance with Patrimonia; Jody's loan consolidates to one central line at `patrimonia-uk · 1200`. Per sub (credit balance B): sub posts Dr 1200 / Cr 2210, Patrimonia posts Dr 1210 / Cr 1200. Scope = UK subs only (folium, shinepics, miabella-uk, vidi); **exclude miabella-wy**. ✅ Accounts ready 2026-06-11 (2210 seeded on miabella-uk + vidi via `coa:init`; all 4 subs now have 1200 + 2210). **Remaining = build the routine:** idempotent monthly sweep keyed `dla-sweep:<sub>:<YYYY-MM>` with preview/confirm; **flag overdrawn DLAs (s.455)** rather than pooling silently (clean-up = net against the DL Patrimonia owes Jody, not cash repayment). Full design in `explainers/holding-structure.md` § "Monthly DLA sweep".2026-06-11
• MEDFO15structure / vidi-systems-ltd · **J30 stock transfer Jody → Patrimonia before vidi starts billing** (part of the Web9→Vidi rename). Vidi incorporated 2026-05-25, BEFORE Patrimonia existed — legally Jody's until the J30; the seed's `parent_id` (and the Shareholders view) states the TARGET structure ahead of legal fact. On transfer: Patrimonia cost of investment = consideration → Dr 1500 (via DLA if no cash moves); vidi's own incorporation fee stays Jody's personal cost.2026-06-11
• MEDFO16global · infrastructure · Sort out BackBlaze per project2026-06-11

Low

• LOWFO89explainers / docs · **Recurring: re-check explainers/ monthly for oversized multi-topic files and split them.** Today's session split 4 monoliths that had grown from normal use — `write-app.md` (73KB), `bank-feed.md` (28KB), `crm-spine.md` (19KB), `operator-app.md` (19KB) — into slim 2-7KB indexes + 14 focused sub-explainers (commit `39c6fa0`), because a session working on one narrow feature was reading the whole file. Same approach next time: scan explainers/ file sizes, read the structure of any outlier, propose a cluster-to-file split (propose-then-confirm, don't just execute), apply on approval.2026-07-29
• LOWFO13Global & In Veritate W, Orchrana · item =ledger; · Dashboard should see the Full Value, not just cash on hand2026-07-09
• LOWFO70ledger / GL view · some SP journals still show raw `source_ref` in the Ref column after backfill + caller wiring (e.g. `pay:e8ac8425-…`, `interco:mia-sp:music:…`, `travel:sp:henry-…`). Mia entries resolved correctly. Likely the `ref` column is NULL for these rows despite the backfill reporting 127 updates — suspect the narrowed immutability trigger or a WAL snapshot issue at update time. Fix: run `SELECT id, source_ref, ref FROM journals WHERE entity_id='shinepics-ltd' AND ref IS NULL` to confirm, then re-run backfill or patch directly. Non-critical — display only; GL totals are correct.2026-06-20
• LOWFO20capture/today · make today.html a PWA (manifest + service worker) — installable on phone, offline2026-06-12