Have your coding agent describe your Desktop integration

Describe this codebase’s QuickBooks Desktop integration so another team can rebuild it on a JSON API for QuickBooks Desktop. Write one Markdown document. Leave out passwords, keys and customer data.

Cover:
1. Who we are: our company's name and website, what our product does, and who uses it, in a paragraph a non-developer could follow.
2. Our stack: language and version, web framework, the HTTP client library we use, the background job system, and how we receive webhooks.
3. How it reaches QuickBooks: the Web Connector, the SDK (QBFC or qbXML) or another service, which qbXML version, and which QuickBooks editions it supports (Pro, Premier, Enterprise).
4. Every request it sends (CustomerAdd, InvoiceQuery…). For each: the direction, the model of ours it maps to, and the fields it sets or reads.
5. What starts each sync: a user action, an event in our app or a schedule, and how often the Web Connector runs.
6. How it finds records already in QuickBooks (ListID, FullName, RefNumber), and what it does when it finds none or several.
7. The settings our users choose (accounts, items, sales tax codes, classes) and where they’re kept.
8. What happens when QuickBooks returns an error or the Web Connector can’t connect, and what our user sees.
9. Our data models, as JSON Schema, in one ```json block at the end: `$defs` with an entry per model in item 4, keyed by its class name, with every field it reads or writes for QuickBooks (its type, whether it can be null, its `enum` when it has a fixed set of values) and each association as a `$ref` to the other model, or an array of them for a has-many. Generate it from the schema file or the models, don’t write it by hand, and describe the shape only: no real records, no `examples` or `default` values. Leave it out if the models can’t be read.

Works with any agent that can read your repository. It asks how the integration behaves, never for keys, passwords or customer data.