URTH Landscaping

Handoff — the state of the app, in one page.

Everything a person or an AI needs to pick the work up mid-stream: what exists, what was decided, why, and what happens next.

Last updated 2026-08-15

Paste this link into any new Claude chat to bring it fully current on URTH:

https://apps.urthlandscaping.com/handoff.html
If you are the AI reading this: you are picking up ongoing work, not starting fresh. Read this page fully before acting, and follow the working rules in section 6.
1What URTH isthe business and the app, in plain words

URTH Landscaping is a landscape design and build company in Miami. It measures a property, designs the planting, and prices the job.

The app does that whole chain in order: measure the property → read the site (sun, tree canopy, drainage, terrain) → produce a planting plan → produce a priced proposal. Every later step is fed by the measurement, so nothing downstream is guessed.

It lives at apps.urthlandscaping.com. It is an internal working tool, with two client-facing faces (the property report and the designer mood board) that hide the internal detail.

2The mapevery tool and what it actually does

Think of it as one workshop with a front door, a measuring bench, and a set of specialised benches around it.

HomeThe front door. Every tool grouped by what you are trying to do.home.html
Property BrainThe measure engine, and the core of everything. Turns a measured property into the numbers the rest of the app spends.brain.html
Properties / RegistryEvery property on file, as rows you can search and open. The registry is where a new property gets added.properties.html · brain.html?tab=reg
Site MarksThe field walk. You walk the property with a phone and tag what is there — plants, drainage, problems, conditions.site-marks.html
Property ReportThe full read of one property. Add ?view=client and it becomes the clean client-facing version with the internal detail stripped out.urth-report.html
Planting planThe live plant schedule and the plan drawing for a property.plan.html
Client DesignerThe mood-board picker the client uses to choose a look. Only offers plants that suit the real conditions on their lot.designer.html
Plant Library393 South Florida species with sun, water, salt and scorch data.library.html
Sun SweepWhere the light falls on the ground, hour by hour, across the year.sun-sweep.html
Sun 3DThe shape of the light over the whole lot. This one is also the aesthetic bar — the look everything else is being pulled up to.sun3d.html
3D massingGround-aware three-dimensional view — measured canopy, house and beds.massing.html
ProcurementOne hub, three tabs: suppliers, equipment rentals, and the supplier map.procurement.html
Estimate and JobsScaffolds — the shells are built and honest about being empty. No invented prices, no fake job feed.estimate.html · jobs.html
TodayThe landing page: lead inbox, pipeline, recent properties, and the build checklist.today.html
System mapThe generated picture of how every page connects — built automatically from the page specs, never hand-drawn.status.html?view=map
3The stackwhere the code lives and how it ships
  • Repo: aharveyrianhard-stack/urth-property-brain, branch main.
  • Deploy: Vercel, automatic on every push to main. Live in roughly 60 seconds. There is no build step and no manual deploy.
  • Database: Supabase project wadinxqplrggagkvrdag. It is shared with a separate trading project called "scintilla" — URTH is in the process of being separated onto its own home on Fly.io under the personal Google account (aharveyrianhard@gmail.com).
  • Domains: 8 in play; the app itself is apps.urthlandscaping.com.
  • The database address lives in one file: urth-config.js. Pages read it from there — no page hardcodes the address any more. The keys in it are the public browser keys, public by design; a service key must never go in that file.
  • The cache proxy: api/c.js. Heavy pages ask it for a pre-made answer instead of rebuilding one.
  • The cache table: urth_cache holds those precomputed heavy renders, so a page that used to take tens of megabytes now fetches a small file.
4Where things standwhat was recently finished

All of the following is done, pushed, and live.

The 10-step front reorganizationThe scattered page suite pulled into one shell with one navigation vocabulary. Reorganization, not redesign.
Precompute + gzip cacheHeavy renders are computed once and stored, then served compressed.
The field walk is wiredSite Marks now feeds the property report and the planting plan. Before this, nothing at all read what the field walk wrote — it was the single biggest dead end in the system.
Page-spec footers on every pageEach page carries its own spec, fed from page-specs.js.
The generated system mapBuilt from the specs, so it cannot drift away from the truth.
Supplier-map source recovered into the repoIt was living outside version control; it is back in.
The Supabase address pulled out of every pageOne file — urth-config.js — now holds it. Migration becomes a one-file change instead of a page-by-page hunt.
Plant-library safety now FAILS CLOSEDIt used to fail open: if the invasive / do-not-use exclusion list did not load, the error was swallowed and every plant came back looking vetted. A banned species was indistinguishable from an approved one. Now, if the list does not load, nothing is presented as safe.

The performance win — measured, before → after

  • Sun 3D: 43.7 MB → 1.5 MB
  • Designer: 43.7 MB → 2.3 MB
  • Report field walk: 4.9 MB → 23 KB
5The decision → reason maphow context survives between sessions

One file, page-specs.js, carries a spec for each page: what it is for, what it reads, what it writes — and a list of decision → reason pairs. Right now that is 106 decision → reason pairs across 27 pages.

Each pair records a call that was made and the reason behind it. Not "we pinned the species count to 393", but "we pinned it to 393 because 393 is what the plant library actually returns when you count it, and the old 540 was a number nobody had measured".

Those pairs render in two places automatically: a collapsible Page spec footer at the bottom of the page itself, and inside each node on the generated system map. The footer is hidden on the client-facing views, so a client never sees it.

This is the context-handover mechanism. Whenever anything changes, the decision and its reason get written into page-specs.js. That is what stops the next session from undoing a deliberate choice because it looked like a bug — and it is why "why did we do it this way?" has an answer that outlives the chat it was decided in.

See it all in one place: the generated system map.

6How Alan worksthe standing rules — read these before touching anything
Execute, do not ask — for anything reversibleIf it can be undone quickly, do it and report what you did. Save the questions for the things that cannot be taken back.
Never claim done without live verificationDone means: committed → pushed → live on the public URL → measured. Show before and after. A thing that works locally is not done.
No localhost, no local-file deliverablesEvery deliverable is a public URL Alan can open on any device. Never a file path he has to find, never a server he has to start.
Nothing gets deleted without his explicit OKDeletion is always a question, never an assumption.
Harvest before retireBefore any page is retired, take out what is good in it — the exports, the running order, the taxonomy, the badges. Retiring a page that still held something useful is not cleanup, it is loss.
Explain in plain wordsAlan is not technical and dictates by voice. Say what a thing is, what it does, and why it matters. A bare technical name on its own is not communication.
Keep the page specs current — including the WHYAny change to a page updates its entry in page-specs.js, with the reason, not just the decision. See section 5.
No Supabase edge functions — write real codeSettled decision. Do not re-propose them.
Build mode now, security at the endRow-level security is deliberately off. This is a known, intentional state for the build phase — do not "fix" it, and do not raise it as a finding.
One canonical file per job, no sprawlEdit the existing file in place. No dated copies, no _v2_final. Version history is what git is for.
7What is nextthe live queue

a · Reskin the CAD and planting-plan outputs

This is the visual language work, and it is the front of the queue. The mood board is at proto-moodboard.html — the same sample property drawn three ways:

  • Architect — a real stamped drawing set. Cream paper, hairline ink, hatching instead of colour, dimensions, keynotes, north arrow, title block.
  • Nocturne — the Sun 3D language brought down to a plan. Dark atmospheric ground, glowing linework, gold used only as light.
  • Field — not a drawing but a product. Light ground, one bold flat colour per material, legend chips, readable on a phone in glare.

The agreed direction: Architect's shapes with Field's colour, and Nocturne for on-screen. The report re-skin prototype is proto-report-v6.html.

b · Rebuild Sun Sweep in full 3D

Bring Sun Sweep up to the Sun 3D bar rather than leaving it as the flat view.

c · Migrate to Fly.io

Move URTH off the shared Supabase project onto its own home. One thing needs Alan's hands: signing into Fly with Google, once. Everything after that is automatable.

d · Clean subdomain URLs

maps.urthlandscaping.com/suppliers needs a DNS CNAME record before it will resolve.

e · Small crumbs

  • The classic launcher (index.html) has 2 stale tiles — Estimate and Jobs still point into the old Property Brain tabs (brain.html?tab=est and ?tab=job), but those are their own pages now.
  • Procurement borrows the Jobs icon — it needs its own.
  • The Designer has 8 Supabase-storage image URLs that must be repointed at migration time, or the images go blank.
8Key linkseverything worth opening