Build with AI prompt library

You are auditing my application so I can integrate LedgerLine accounting workflows.

Do not make code changes yet.
Do not install packages yet.
Do not create migrations yet.
Do not expose or print real secrets.
Do not paste real API keys into your response.
Inspect the codebase and produce a structured integration audit.

I need you to identify:

1. App basics
- framework
- package manager
- deployment platform
- frontend routes
- backend/server routes
- API conventions
- server-only code locations

2. Auth and tenant model
- auth provider
- user model
- organization/team/workspace model
- customer/client model
- role/permission model if present

3. Database and data models
- database/provider
- ORM/query layer
- existing models/tables for customers, invoices, estimates, orders, payments, vendors, bills, documents, reports, or ledger entries
- any fields that map to accounting workflows

4. Payments and billing
- payment provider
- checkout/payment flow
- webhook flow
- existing payment status states
- refund/void/cancel behavior if present

5. Documents and storage
- document generation
- file upload/storage provider
- private/public access model
- customer-facing share links if present

6. Environment variables and secrets
- local env files used
- deployment secret location
- existing payment/auth/database env vars
- where LedgerLine env vars should be added
- any client-side files that must never receive LedgerLine API keys

7. Workflows I may need from LedgerLine
Choose all that apply and explain why:
- customers
- invoices
- estimates
- customer payments
- vendors
- bills
- vendor payments
- documents
- customer portal
- reports
- accounts receivable
- accounts payable
- 1099 support
- webhooks
- exports
- accounting impact/ledger views

8. Recommended integration plan
Return:
- recommended LedgerLine modules
- required env vars using fake placeholders only
- files likely created or modified
- API calls needed
- server-only client plan
- webhook plan if needed
- test data plan
- smoke test checklist
- risks
- missing questions I need to answer before implementation

Output format:

Use markdown with these headings:

# LedgerLine Integration Audit

## App Summary
## Current Stack
## Existing Relevant Models
## Existing Workflows
## Recommended LedgerLine Modules
## Required Environment Variables
## Server-Only Integration Plan
## Files Likely Touched
## API Calls Needed
## Webhook Plan
## Test Data Plan
## Smoke Test Checklist
## Risks and Unknowns
## Questions Before Build

Remember:
Use fake placeholders only.
Do not reveal secrets.
Do not change code.
Do not run migrations.
Do not implement anything until I approve the plan.

You are helping me plan a LedgerLine integration before editing code.

Do not edit files yet. First inspect the target app and return a safe, reviewable implementation plan.

LedgerLine is API-first accounting infrastructure for SaaS apps and custom software. It should stay server-side, source-aware, idempotent, and explicit about accounting impact.

Use these fake placeholders only:
LEDGERLINE_BASE_URL=https://your-ledgerline-domain.com
LEDGERLINE_API_KEY=ll_test_replace_me
LEDGERLINE_WEBHOOK_SECRET=whsec_test_replace_me

Plan output required:
1. Identify the app framework, server runtime, route/server-action pattern, and env-var loading pattern.
2. List the exact files you would create or modify.
3. Describe the server-only LedgerLine client module and how it keeps API keys out of browser/mobile/static code.
4. Describe the first read-only smoke check using GET /api/v1/auth/check.
5. Describe the read-only report or starter path to verify the integration before write workflows.
6. Describe optional test-mode money-in and money-out helpers only after read-only checks pass.
7. Describe webhook receiver needs, signature verification, idempotency, fast 2xx behavior, and durable replay protection if outbound LedgerLine webhooks are needed.
8. Explain which operations are operational-only and which operations post accounting impact.
9. Explain idempotency-key and external-id usage for mutating calls.
10. Explain how generated code should parse LedgerLine's standard error envelope.
11. List local checks or smoke steps the developer should run.
12. List any questions that block safe implementation.

Safety rules:
- Do not paste, request, log, or commit real LedgerLine API keys.
- Do not expose LedgerLine API keys in browser code, mobile clients, static bundles, or logs.
- Do not commit .env files.
- Use fake placeholders in generated examples.
- Use test keys before any live-mode workflow.
- Do not create production data during setup.
- Do not assume Stripe Checkout/payment collection, SendGrid, Plaid, OCR/AI parsing, IRS e-filing, or payroll integrations are live.
- Do not claim production readiness.

Return the plan first. Wait for approval before editing code.

You are helping me integrate LedgerLine into my app.

LedgerLine is an API-first accounting infrastructure platform for SaaS apps and custom software. Use LedgerLine APIs for accounting workflows, but keep all LedgerLine API keys server-side.

Goals:
- Add server-side LedgerLine environment variables.
- Add a small server-side LedgerLine API client module.
- Call GET /api/v1/auth/check.
- Add a safe read-only smoke/check path.
- Follow the LedgerLine quickstart order: auth check, read-only starter pattern, then opt-in test-mode workflow helpers.
- Do not expose LedgerLine API keys in browser code.
- Do not commit .env files.
- Use test keys first.
- Use fake placeholders in examples.
- Do not assume deferred providers are live.

Environment variables to add as placeholders:
LEDGERLINE_BASE_URL=https://your-ledgerline-domain.com
LEDGERLINE_API_KEY=ll_test_replace_me
LEDGERLINE_WEBHOOK_SECRET=whsec_test_replace_me

Implementation instructions:
1. Inspect this app's framework and server-side environment pattern.
2. Add or document server-only env vars for LEDGERLINE_BASE_URL, LEDGERLINE_API_KEY, and LEDGERLINE_WEBHOOK_SECRET.
3. Create a server-only LedgerLine client module.
4. The client should read env vars only on the server.
5. Attach Authorization: Bearer LEDGERLINE_API_KEY on API requests.
6. Do not import the API key into client/browser components.
7. Do not log the API key, Authorization header, webhook secret, request bodies containing secrets, or provider secrets.
8. Implement a checkLedgerlineAuth function that calls GET /api/v1/auth/check.
9. Handle LedgerLine's standard error envelope.
10. Add clear setup notes explaining that operators must create a LedgerLine connected app and API key first.
11. Add a local smoke instruction that runs read-only checks before write workflows.

Product boundaries:
- Do not assume Stripe Checkout/payment collection is enabled.
- Do not assume SendGrid real email sending is enabled.
- Do not assume Plaid/bank feeds are enabled.
- Do not assume OCR/AI parsing is enabled.
- Do not assume IRS e-filing is enabled.
- Do not claim production readiness without setup, migrations, private buckets, RLS/Storage review, smoke/security QA, and rollout planning.

You are helping me integrate LedgerLine into my app as a server-side accounting API.

What LedgerLine is:
- LedgerLine is API-first accounting infrastructure for SaaS apps and custom software.
- Connected apps send customers, invoices, payments, vendors, bills, documents, reports, and webhooks.
- LedgerLine handles ledgers, Accounts Receivable, Accounts Payable, reports, documents, and 1099 support.
- LedgerLine API keys must stay server-side.

Use these fake placeholders in examples:
LEDGERLINE_BASE_URL=https://your-ledgerline-domain.com
LEDGERLINE_API_KEY=ll_test_replace_me
LEDGERLINE_WEBHOOK_SECRET=whsec_test_replace_me

Safety rules:
- Never expose LedgerLine API keys in browser code, mobile clients, static bundles, logs, or committed files.
- Do not commit .env files.
- Use test keys first.
- Do not log Authorization headers.
- Do not log webhook secrets.
- Do not expose storage paths.
- Do not create production data during setup.

Server-side client:
1. Inspect this app and choose the correct server-only module location.
2. Create a LedgerLine API client that reads LEDGERLINE_BASE_URL and LEDGERLINE_API_KEY server-side.
3. Attach Authorization: Bearer LEDGERLINE_API_KEY on API requests.
4. Parse the standard LedgerLine error envelope and throw/use typed errors.
5. Keep request/response examples fake and minimal.
6. Add checkLedgerlineAuth() for GET /api/v1/auth/check.

Workflow guidance:
- Money-in: customers, invoices, invoice posting, payments, and A/R reports.
- Estimates: pre-accounting proposals and reviewed conversion to invoice.
- Money-out: vendors, bills, bill posting, vendor payments, and A/P reports.
- Documents: server-routed private evidence and rendered document workflows.
- Reports: summary, A/R, A/P, and 1099 support reads.
- Webhooks: signature checks, fast 2xx, idempotency, and durable replay protection.

Smoke checks:
- Start with GET /api/v1/auth/check.
- Use read-only checks before mutating workflows.
- Use test mode and fake data only.
- Do not create production data by accident.
- Do not upload files until storage setup is verified.

Return files changed, checks run, smoke results, and unresolved risks.

Use /build-with-ai to select workflows, stack, and tool. The generated setup pack will create the personalized implementation prompt.