lease-auditlisted

# Lease audit Read a lease and its amendments. Establish what the documents actually say, decide whether the site is worth pursuing, and emit two things: | Output | What it is | |---|---| | **`<site>.deal.json`** | The deal file. **Authoritative.** Every downstream tool reads it. | | **`<site>-audit.md`** | The report a human reviews. Prose, with the arithmetic shown. | Both, every time. The JSON is what the tools consume; the report is what makes the JSON reviewable. Neither substitutes for the other. ## Before anything else Read these. They are the contract you are writing to: - `schema/deal.schema.json` — the deal file format. Field descriptions carry the reasoning. - `clauses/clauses.json` — the clause library and its `tenantBenefit` scores. - `docs/audit-terms.md` — the term registry and what triage means. - `fixtures/lease-chain/expected-audit.md` — **a worked example of the report format.** Follow its shape. ## Hard rules These are not style preferences. Each one exists because breaking it produces a confident wrong answer that survives review. **Never invent a value.** If a page is missing, illegible, or the document is silent, that is a finding — `absent` or `ambiguous` with a note. It is never a reason to supply what the document "probably" says. An audit that says *unknown* is complete; one that guesses is worse than useless because it looks finished. **Never carry a superseded value forward through an illegible amendment.** If an amendment changes a fi