SKILL.md · jhustle44/jcr-guide-pro

Code Commits Issues Pulls Cloud Agent CI/CD

copilot/create-zip-file-again

copilot/add-firebase copilot/change-app-name-to-jcrguru copilot/create-zip-file copilot/create-zip-file-again copilot/merge-any-updates main master

md 977 lines 38.1 KB

Rendered Raw

1	---
2	name: legal-contract
3	description: Draft, review, or explain legal documents — NDAs, contracts, privacy policies, and more.
4	---
5
6	# Legal Contract Assistant
7
8	Full-stack legal platform with three core capabilities: (1) draft and review any type of legal document — NDAs, service agreements, LOIs, purchase agreements, privacy policies, terms of service, and more; (2) manage documents on a dashboard with owner-scoped access; (3) run interactive due diligence rooms for M&A transactions with file uploads, status tracking, comments, participant access control, and activity logging.
9
10	## IMPORTANT DISCLAIMER: This provides general information and templates only. It does NOT constitute legal advice. Always consult a qualified attorney for legal matters
11
12	## Platform Capabilities
13
14	This skill powers a full legal platform with three major capability areas. When the user arrives, guide them to the right capability based on their need:
15
16	### 1. Document Drafting & Review
17
18	Generate any type of legal document from templates and review existing contracts for red flags.
19
20	#### What users can do
21
22	- Draft NDAs, service agreements, freelancer contracts, LOIs, term sheets, asset/stock purchase agreements, operating agreements, board resolutions, leases, privacy policies, terms of service — or any other legal document type
23	- Review contracts they've received and get a plain-language analysis with flagged risks
24
25	- Generate multi-document packages for transactions (e.g., LOI + NDA for an acquisition)
26	- Export documents as PDF and DOCX for signing and redlining
27
28	##### How it works
29
30	1. User describes the document they need or pastes a contract for review
31	2. For drafting: start from open-source templates (Bonterms/Common Paper for NDAs/service agreements) or standard clause structures (for M&A documents). See "Open-Source Template Libraries" and "M&A / Transaction Documents" sections below.
32
33	3. For reviews: run the red-flag checklist and playbook checks, then output using the "Review Output Format"
34	4. Store the document in the platform via the Documents System (any `documentType` string — the system is type-agnostic)
35
36	5. Deliver PDF + DOCX exports using the generation pipeline in "Output: Always Produce PDF & DOCX"
37
38	### 2. Document Management (Dashboard)
39
40	Store, organize, and manage all legal documents with owner-scoped access.
41
42	#### What users can do (2)
43
44	- View all their documents on the dashboard with type badges and status indicators
45	- Open any document to view its full content
46
47	- Delete documents they no longer need (with confirmation)
48	- Link documents to DD rooms for transaction context
49
50	##### How it works (2)
51
52	- Documents are stored in the `documents`table with a flexible`documentType` field — supports any type, not just LOIs
53	- All access is owner-scoped: users only see their own documents
54
55	- See the "Documents System" section below for schema and API details
56
57	### 3. Due Diligence Rooms
58
59	Interactive workspaces for managing M&A due diligence checklists with file uploads, comments, and team collaboration.
60
61	#### What users can do (3)
62
63	- Create DD rooms pre-populated with 8 standard M&A categories and 57 checklist items
64	- Add custom categories and items beyond the standard template
65
66	- Upload files against checklist items (directly to object storage via presigned URLs)
67	- Download uploaded files with room-level authorization
68
69	- Track item status through the workflow: notstarted → uploaded → underreview → approved/flagged
70	- Comment on items for team discussion
71
72	- Invite participants by email with role-based access (viewer, contributor, admin)
73	- Monitor progress via per-category and overall completion statistics
74
75	- Review a full activity feed of all room actions
76
77	##### How it works (3)
78
79	- Room creation auto-populates from the `DD_TEMPLATE`in`dd-rooms.ts`
80	- All routes are protected by room-level access control middleware
81
82	- Files go through a presigned URL upload flow (request URL → upload to storage → register in DB)
83	- See the "Due Diligence Room Platform" section below for full architecture and API details
84
85	## When to Use
86
87	- User needs any type of legal document drafted — NDA, service agreement, freelancer contract, consulting agreement, partnership agreement, operating agreement, LLC agreement, board resolution, employment agreement, offer letter, non-compete, non-solicitation agreement, equity/stock option agreement, SLA, DPA, or any other contract
88	- User needs a Letter of Intent (LOI), term sheet, earnout agreement, or asset/stock purchase agreement
89
90	- User wants a plain-language review of a contract they received ("review this contract", "what does this clause mean", "help me understand this agreement", "is this contract fair")
91	- User needs to understand specific legal terms or clauses
92
93	- User wants a lease or rental agreement reviewed for red flags
94	- User needs multiple related transaction documents (e.g., LOI + NDA for an acquisition)
95
96	- User needs a Privacy Policy or Terms of Service for a web app or SaaS product
97	- User asks to "draft a contract", "write me a contract", or "create an agreement"
98
99	- User wants to manage and organize their legal documents on a dashboard
100	- User needs to set up or work within a due diligence room, data room, or deal room for an M&A transaction
101
102	- User wants an M&A checklist, acquisition checklist, or due diligence checklist
103	- User wants to upload, track, or review due diligence documents with a team
104
105	## When NOT to Use
106
107	- Complex litigation or regulatory compliance
108	- Employment law disputes
109
110	- International trade agreements
111	- Anything involving criminal law
112
113	- Situations requiring jurisdiction-specific legal analysis
114
115	## Open-Source Template Libraries (Use These First)
116
117	Never draft from scratch. Start from committee-vetted open-source agreements released under CC BY 4.0:
118
119	\| Source \| Documents \| Style \| Get it \|
120
121	\|--------\|-----------\|-------\|--------\|
122
123	\| Bonterms \| Mutual NDA, Cloud Terms (SaaS), SLA, DPA, PSA, AI Standard Clauses \| US; "cover page + standard terms" \| `github.com/Bonterms` \|
124
125	\| Common Paper \| Mutual NDA, Cloud Service Agreement, DPA, Design Partner Agreement \| US; standards committee of 40+ attorneys \| `commonpaper.com/standards` \|
126
127	\| oneNDA \| NDA (777 words), oneDPA \| UK/EU; strict variable-only edits \| `onenda.org` \|
128
129	Workflow: `webFetch("https://bonterms.com/forms/mutual-nda/")` → extract the standard terms → build a cover page with the user's deal-specific variables (parties, effective date, term, governing law, jurisdiction). Don't modify the body; that's the whole point of standards.
130
131	Note: These libraries cover NDAs and SaaS/service agreements well, but do not include M&A documents (LOIs, term sheets, purchase agreements). For those document types, draft using the standard clause structures in the "M&A / Transaction Documents" section below.
132
133	## M&A / Transaction Documents
134
135	When a user needs documents for buying/selling a business, these are the common document types and their standard clause structures:
136
137	### Letter of Intent (LOI)
138
139	Standard sections for an LOI:
140
141	1. Transaction Structure — asset purchase vs. stock/equity purchase
142	2. Purchase Price — total price, payment structure (cash at closing, earnout, seller financing, escrow holdback)
143
144	3. Earnout provisions — if applicable: percentage, performance milestones, measurement period, payment schedule
145	4. Due Diligence — period length (typically 30-60 days), scope, access to records, extension rights
146
147	5. Exclusivity / No-Shop — period length (typically 60-90 days), binding on seller
148	6. Closing Timeline — target closing date
149
150	7. Conditions to Closing — due diligence completion, definitive agreement, reps & warranties accuracy, third-party consents, no MAE, ancillary agreements
151	8. Representations and Warranties — reference to customary reps in definitive agreement
152
153	9. Confidentiality — binding obligation
154	10. Expenses — each party bears own costs; binding
155
156	11. Non-Binding Nature — clearly state which sections ARE binding (typically: exclusivity, confidentiality, expenses, non-binding clause itself) and which are non-binding
157	12. Governing Law — leave as fill-in-the-blank for jurisdiction
158
159	13. Expiration — LOI expires if not signed within X days (typically 10-15)
160
161	Key variables to collect from user: buyer name, seller/target name, purchase price, deal structure (asset vs. stock), due diligence period, exclusivity period, closing timeline, earnout terms (if any).
162
163	### Mutual NDA (Transaction-Specific)
164
165	When drafting an NDA for a specific transaction (vs. a general-purpose NDA), include these additional elements:
166
167	- WHEREAS clauses that reference the specific transaction and any related LOI
168	- Permitted Purpose scoped specifically to evaluating/negotiating the transaction
169
170	- Non-Solicitation of the other party's employees (typically 12 months)
171	- No Obligation to Proceed — neither party is obligated to complete the transaction
172
173	- Cross-reference the LOI or term sheet by name in the recitals
174
175	Standard NDA sections: definition of confidential information, exclusions, receiving party obligations, no license/warranty, return/destruction, term (typically 2 years), remedies (injunctive relief), governing law, miscellaneous (entire agreement, amendments, assignment, severability, waiver, counterparts, notices).
176
177	### Multi-Document Transactions
178
179	When a transaction requires multiple related documents (e.g., LOI + NDA):
180
181	1. Maintain consistent definitions — party names, defined terms ("Transaction," "Business," "Purchased Assets"), and entity references must match across all documents
182	2. Cross-reference between documents — the NDA should reference the LOI in its recitals; the LOI's confidentiality section should note that a separate NDA governs
183
184	3. Align timelines — the NDA's term should cover at least the LOI's exclusivity + due diligence + closing periods
185	4. Use the same governing law placeholder in all documents
186
187	5. Draft and present together — generate all documents in a single session so the user has a complete package
188
189	## Privacy Policy & Terms of Service (Web Apps / SaaS)
190
191	Privacy Policies and Terms of Service are among the most common legal documents a web app needs. They are not contracts between two parties — they are public-facing declarations. Treat them as a separate document type from the contract/NDA/LOI workflow.
192
193	### Key questions to ask before drafting
194
195	1. Legal entity name — Always ask for the exact registered legal name separately from the brand name. The brand is what users see ("NiDO"); the legal entity is what appears in formal documents ("NiDO Finanzas S.A.S."). Never assume they are the same.
196	2. Country of incorporation — Determines which data protection law applies (GDPR for EU, LGPD for Brazil, Ley 172-13 for Dominican Republic, CCPA for California, etc.).
197
198	3. What data is collected — Account info (name, email), financial/transactional data, uploaded files, usage/analytics?
199	4. Third-party data processors — Ask the user to enumerate every service that touches user data: auth provider, database host, AI/ML services, payment processor, analytics, email provider, CDN. Each must be disclosed in the Privacy Policy.
200
201	5. Are there paid plans? — If yes, the Terms must cover payment terms, auto-renewal, cancellation, and refund policy.
202	6. Minimum age — Typically 18 for financial apps, 13 for general consumer apps.
203
204	7. Contact email for privacy/legal — Often different from the support email. Ask explicitly.
205
206	### Third-party processor disclosure pattern
207
208	For every integration the app uses, include a line in the Privacy Policy. Format:
209
210	```text
211
212	- [Provider] ([function]): [What they receive and why]. [Link to their privacy policy if possible.]
213
214	```
215
216	Example:
217
218	```text
219
220	- Neon (base de datos): almacenamiento seguro de sus datos financieros en servidores PostgreSQL.
221	- Google Gemini (IA): genera categorías y análisis. Solo recibe descripciones de transacciones; nunca datos personales identificables.
222
223	- Stripe (pagos): procesa pagos con tarjeta. NiDO no almacena datos de tarjetas.
224	- Replit Auth (autenticación): gestiona el inicio de sesión vía Google/GitHub.
225
226	```
227
228	If the app uses analytics, advertising pixels, or session recording (Hotjar, FullStory, etc.), these MUST be disclosed and typically require explicit consent in GDPR jurisdictions.
229
230	### Privacy Policy required sections
231
232	1. Who we are (legal entity name, contact email for privacy)
233	2. What data we collect (account info, user-generated data, uploaded files, usage logs)
234
235	3. How we use it (provide service, personalization, legal compliance)
236	4. Third-party processors (enumerate all — see above)
237
238	5. Data storage and security (encryption at rest/in transit, access controls)
239	6. User rights (access, correction, deletion, export)
240
241	7. Cookies (session-only vs. tracking; consent requirements if in GDPR territory)
242	8. Minors (minimum age, what happens if a minor's data is discovered)
243
244	9. Changes to the policy (notice method and timing — typically 15–30 days)
245	10. Governing law (jurisdiction's data protection statute)
246
247	### Terms of Service required sections
248
249	1. Acceptance (clicking/using = agreement)
250	2. Service description (what it does and does NOT do)
251
252	3. Account registration (age requirement, accurate info, responsibility for activity)
253	4. Acceptable use (prohibited behaviors: fraud, scraping, reverse engineering, illegal activity)
254
255	5. Financial/medical disclaimer — if the app gives any advice-like output (budget suggestions, AI analysis), include an explicit "not financial/legal/medical advice" clause
256	6. User data ownership (user owns their data; limited license to operator to run the service)
257
258	7. Payments (if applicable: billing cycle, auto-renewal, cancellation, refunds, payment processor)
259	8. Service availability (no uptime guarantee unless SLA offered)
260
261	9. Limitation of liability (cap at fees paid in last 12 months or a fixed floor like $100)
262	10. IP ownership (brand, code, design belong to the operator)
263
264	11. Termination (user can delete account; operator can suspend for violations; data deletion timeline)
265	12. Changes to terms (notice period — typically 15 days for material changes)
266
267	13. Governing law and jurisdiction
268
269	### Delivery format for web apps — routed pages, not PDFs
270
271	For web apps, the best delivery format for Privacy Policy and Terms of Service is routed pages within the app itself, not PDFs or DOCX files. This is the standard for all modern SaaS products.
272
273	#### Pattern
274
275	- Create `client/src/pages/Privacy.tsx`and`client/src/pages/Terms.tsx`
276	- Register them as public routes— accessible without authentication. Place the route checkbefore the auth loading state in `AppContent`:
277
278	```tsx
279
280	function AppContent() {
281
282	const { isLoading, isAuthenticated } = useAuth();
283
284	const [location] = useLocation();
285
286	// Public legal pages — always accessible, no auth required
287
288	if (location === "/privacidad") return <Privacy />;
289
290	if (location === "/terminos") return <Terms />;
291
292	// Auth guard below
293
294	if (isLoading) return <LoadingScreen />;
295
296	return isAuthenticated ? <AuthenticatedLayout /> : <Landing />;
297
298	}
299
300	```
301
302	##### Page layout pattern
303
304	- Minimal header: logo + "Back to home" link
305	- Amber disclaimer banner at the top: "Este documento es una plantilla informativa y no constituye asesoramiento legal."
306
307	- Clean `max-w-3xl mx-auto`prose layout,`text-sm leading-relaxed`
308	- Footer with cross-links: Privacy ↔ Terms ↔ Contact ↔ Home
309
310	- No sidebar, no app navigation — these are public documents
311
312	After creating the pages, always update the footer links in the landing page or marketing page. Footer links that point to `href="#"`are broken. Replace with`href="/privacidad"`and`href="/terminos"`, and change the "Contact" link to`mailto:` rather than another dead hash.
313
314	Consistency check after any company name change: If the user changes the legal entity name, search ALL files — not just the legal pages. Invoice templates, billing pages, and email footers often also contain the company name and will need updating too.
315
316	### Disclaimer banner (always include on the rendered page)
317
318	Every rendered legal page should display a visible disclaimer. Do not only warn the user in chat — put it on the page itself:
319
320	```tsx
321
322	<div className="bg-amber-50 dark:bg-amber-950/30 border border-amber-200 dark:border-amber-800 rounded-md px-4 py-3 mb-10 text-sm text-amber-800 dark:text-amber-300">
323
324	Este documento es una plantilla informativa y no constituye asesoramiento legal.
325
326	Consulte un abogado calificado para asuntos legales específicos.
327
328	</div>
329
330	```
331
332	## Red-Flag Language to Grep For
333
334	When reviewing, search the document text for these exact phrases — each is a known risk pattern:
335
336	\| Phrase \| Why it's dangerous \| Suggested fix \|
337
338	\|--------\|-------------------\|---------------\|
339
340	\| `"any and all claims"` \| Unlimited indemnity scope \| "claims arising directly from [Party]'s breach of Section X" \|
341
342	\| `"indemnify, defend, and hold harmless"` \| "Hold harmless" blocks your counterclaims even if they caused the loss \| Strike "and hold harmless"; keep "indemnify and defend" \|
343
344	\| `"sole discretion"`/`"absolute discretion"` \| One party can act arbitrarily (block settlements, reject deliverables) \| "consent not to be unreasonably withheld, conditioned, or delayed" \|
345
346	\| `"including but not limited to"` in IP assignment \| Open-ended IP grab beyond deliverables \| Enumerate specific deliverables; add "excluding pre-existing IP" \|
347
348	\| No liability cap stated \| Courts default to unlimited liability \| "Aggregate liability capped at fees paid in the 12 months preceding the claim" \|
349
350	\| `"time is of the essence"` \| Any delay = material breach \| Delete, or limit to payment obligations only \|
351
352	\| Indemnity carved out of liability cap \| Your cap doesn't protect you where exposure is highest \| "Indemnification obligations are subject to the cap in Section X" \|
353
354	\| Auto-renewal with <30-day opt-out window \| Easy to miss; locked in another term \| 60–90 day notice window; email notice permitted \|
355
356	\| `"perpetual"`+`"irrevocable"` license \| Can never be revoked even after breach \| Term-limited; terminable on material breach \|
357
358	Indemnity forms (escalating risk): Limited= you cover only your own negligence.Intermediate= everything except their sole negligence.Broad = you cover losses even when caused entirely by them. Flag intermediate and broad as Critical.
359
360	## Playbook Checks (What Harvey/Spellbook Actually Run)
361
362	AI contract tools run a fixed checklist per document type. For a Service Agreement run these checks and grade each Pass/Flag/Missing:
363
364	1. Is there a liability cap? Is it mutual? Is it tied to fees paid (1x, 2x)?
365	2. Is indemnity mutual or one-way? Subject to the cap or carved out?
366
367	3. Does IP assignment exclude contractor's pre-existing tools/libraries?
368	4. Is there a cure period (typically 30 days) before termination for breach?
369
370	5. Are "consequential damages" (lost profits, lost data) excluded? Mutually?
371	6. Payment terms: Net 30 or better? Late fee specified?
372
373	7. Can the client terminate for convenience? If so, is there a kill fee?
374	8. Governing law + venue: neutral, or the other party's home court?
375
376	For a Letter of Intent run these checks:
377
378	1. Are binding vs. non-binding sections clearly identified?
379	2. Is there an exclusivity/no-shop clause? Is it binding?
380
381	3. Is the purchase price clearly stated with payment structure?
382	4. Is the due diligence period defined with access rights?
383
384	5. Are conditions to closing enumerated?
385	6. Is there a confidentiality obligation (binding)?
386
387	7. Does the LOI have an expiration date?
388	8. If there's an earnout, are the metrics and measurement methodology specified (or deferred to the definitive agreement)?
389
390	## Review Output Format
391
392	```text
393
394	# Contract Review: [Document Type]
395
396	NOT LEGAL ADVICE — for informational purposes only. Consult an attorney before signing.
397
398	## Summary
399
400	[2–3 sentences: what this is, who it favors, biggest concern]
401
402	## Critical — Do Not Sign Without Addressing
403
404	1. [Clause §X.Y]: [quote the exact language]
405
406	- Risk: [plain English]
407	- Suggested redline: "[replacement text]"
408
409	## Warnings — Negotiate If You Have Leverage
410
411	## Notes — Standard But Be Aware
412
413	## Missing Protections
414
415	[clauses that should be here but aren't — e.g., no liability cap, no cure period]
416
417	## Overall: [Fair / Favors Counterparty / Consult Attorney Before Signing]
418
419	```
420
421	## Output: Always Produce PDF & DOCX
422
423	Every drafted contract MUST be delivered as both a PDF and a DOCX file. Clients need PDF for signing and DOCX for redlining — always provide both.
424
425	### Architecture: React + Vite → Puppeteer PDF + python-docx DOCX
426
427	Build the contract as a React web artifact first (source of truth for layout), then export:
428
429	#### PDF via Puppeteer
430
431	Install `puppeteer-core`in the`scripts`package:`pnpm --filter @workspace/scripts add puppeteer-core`
432
433	```typescript
434
435	// scripts/src/generate-contract.ts
436
437	import puppeteer from 'puppeteer-core';
438
439	// Find Chromium — pick the latest version from the list:
440
441	// ls /nix/store/chromium/bin/chromium \| sort -V \| tail -1
442
443	const CHROMIUM_PATH = "/nix/store/FIND_LATEST_PATH/bin/chromium";
444
445	// Use the artifact's actual URL, not localhost
446
447	const CONTRACT_URL = `https://${process.env.REPLIT_DEV_DOMAIN}/ARTIFACT-ROUTE`;
448
449	const browser = await puppeteer.launch({
450
451	executablePath: CHROMIUM_PATH,
452
453	headless: true,
454
455	args: ['--no-sandbox', '--disable-setuid-sandbox'],
456
457	});
458
459	const page = await browser.newPage();
460
461	await page.setViewport({ width: 816, height: 1056 }); // Match page container dimensions
462
463	await page.goto(CONTRACT_URL, { waitUntil: 'networkidle0' });
464
465	// IMPORTANT: Set document.title for correct PDF metadata title.
466
467	// Without this, the PDF viewer title bar shows the HTML <title> from index.html,
468
469	// which may be wrong when generating multiple documents from the same app.
470
471	await page.evaluate(() => { document.title = "Your Document Title Here"; });
472
473	await page.pdf({
474
475	path: 'contract.pdf',
476
477	format: 'Letter',
478
479	printBackground: true,
480
481	// IMPORTANT: Use zero margins — the page containers already include internal padding.
482
483	// Non-zero Puppeteer margins + fixed-height containers = blank overflow pages.
484
485	margin: { top: '0', bottom: '0', left: '0', right: '0' },
486
487	});
488
489	await browser.close();
490
491	```
492
493	Add a script entry in `scripts/package.json`:`"generate-contract": "tsx ./src/generate-contract.ts"`
494
495	Run via: `pnpm --filter @workspace/scripts run generate-contract`
496
497	##### DOCX via python-docx
498
499	Python may not be available via `pip`in the Replit environment. Use`nix-shell`to get`python-docx`:
500
501	```bash
502
503	nix-shell -p python3Packages.python-docx --run "python3 scripts/src/generate-contract.py"
504
505	```
506
507	```python
508
509	# scripts/src/generate-contract.py
510
511	from docx import Document
512
513	from docx.shared import Pt, Inches, RGBColor
514
515	from docx.enum.text import WD_ALIGN_PARAGRAPH
516
517	doc = Document()
518
519	# Set default font
520
521	style = doc.styles['Normal']
522
523	font = style.font
524
525	font.name = 'Times New Roman'
526
527	font.size = Pt(12)
528
529	# Set margins
530
531	for section in doc.sections:
532
533	section.top_margin = Inches(1)
534
535	section.bottom_margin = Inches(1)
536
537	section.left_margin = Inches(1.25)
538
539	section.right_margin = Inches(1.25)
540
541	# Title
542
543	title = doc.add_paragraph()
544
545	title.alignment = WD_ALIGN_PARAGRAPH.CENTER
546
547	run = title.add_run('DOCUMENT TITLE')
548
549	run.bold = True
550
551	run.font.size = Pt(18)
552
553	# Preamble
554
555	doc.add_paragraph(
556
557	'This Agreement is entered into as of [DATE] by and between:'
558
559	)
560
561	# Parties table
562
563	table = doc.add_table(rows=1, cols=2)
564
565	table.style = 'Table Grid'
566
567	# ... populate with party details
568
569	# Sections with numbered clauses
570
571	heading = doc.add_paragraph()
572
573	run = heading.add_run('1. Section Title')
574
575	run.bold = True
576
577	doc.add_paragraph('Section body text...')
578
579	# Signature block
580
581	sig_table = doc.add_table(rows=5, cols=2)
582
583	# Row 0: labels (BUYER / SELLER)
584
585	# Rows 1-4: Signature, Printed Name, Title, Date lines
586
587	doc.save('contract.docx')
588
589	```
590
591	### Styling for Legal Documents
592
593	- Font: Times New Roman 12pt (standard for legal docs) or similar serif
594	- Margins: 1" top/bottom, 1.25" left/right
595
596	- Line spacing: 1.5 or double-spaced (jurisdiction dependent)
597	- Section numbering: Use hierarchical numbering (1, 1.1, 1.1.1)
598
599	- Page numbers: Bottom center, "Page X of Y"
600	- Headers: Document title and date on each page
601
602	- Signature blocks: Two-column layout with lines for signature, printed name, title, date
603
604	### Page-Aware Layout (Preventing Blank PDF Pages)
605
606	Use fixed-height page containers that map 1:1 to physical letter pages. This ensures content stays within page boundaries on screen and in PDF output.
607
608	#### Page container constants (letter size at 96 DPI)
609
610	- `PAGE_W = "816px"` (8.5 inches)
611	- `PAGE_H = "1056px"` (11 inches)
612
613	- Internal padding: `48px`top/bottom,`72px` left/right
614
615	##### Page container component pattern
616
617	```tsx
618
619	<div
620
621	className="page-container mx-auto bg-white shadow-lg print:shadow-none mb-8 print:mb-0 flex flex-col overflow-hidden"
622
623	style={{
624
625	width: PAGE_W,
626
627	height: PAGE_H,
628
629	pageBreakAfter: pageNum < TOTAL_PAGES ? "always" : undefined,
630
631	breakAfter: pageNum < TOTAL_PAGES ? "page" : undefined,
632
633	}}
634
635	>
636
637	{/* Page header with "Page X of Y" */}
638
639	{/* Content area with internal padding */}
640
641	</div>
642
643	```
644
645	###### Critical CSS for print/PDF — add to your global stylesheet
646
647	```css
648
649	@page {
650
651	size: letter;
652
653	margin: 0;
654
655	}
656
657	@media print {
658
659	html, body {
660
661	margin: 0 !important;
662
663	padding: 0 !important;
664
665	background: white !important;
666
667	}
668
669	.page-container {
670
671	box-shadow: none !important;
672
673	margin: 0 !important;
674
675	}
676
677	}
678
679	```
680
681	Why blank pages happen: If Puppeteer adds its own margins (e.g., `margin: { top: "0.5in" }`) on top of 1056px containers, each container exceeds the physical page height. The overflow creates a blank page before the next`breakAfter: "page"`fires. The fix: always use`margin: { top: "0", bottom: "0", left: "0", right: "0" }`in Puppeteer and`@page { margin: 0 }` in CSS, since the page containers already include their own internal padding.
682
683	Do NOT override `height: auto` in print media — removing the fixed height lets containers expand beyond one page, defeating the 1:1 page mapping. Keep the fixed height; the CSS page breaks handle pagination.
684
685	###### Outer wrapper must neutralize screen-only styles for print
686
687	```tsx
688
689	<div className="min-h-screen bg-gray-100 py-8 px-4 print:bg-white print:py-0 print:px-0 print:min-h-0">
690
691	```
692
693	Viewport must match page width in Puppeteer: `page.setViewport({ width: 816, height: 1056 })` so content renders at the correct scale.
694
695	Content balancing: Use `breakInside: "avoid"` on sections and distribute content across pages so no page overflows. Check the rendered layout in the browser at 816px width before generating PDFs.
696
697	### Contract Review Output
698
699	For reviews (not drafting), output the review analysis directly as text using the Review Output Format above. Do not generate PDF/DOCX for reviews — the review is commentary, not a document.
700
701	### Multi-Document Routing
702
703	When generating multiple documents for the same transaction (e.g., LOI + NDA), use a single React artifact with separate routes for each document:
704
705	```tsx
706
707	// App.tsx
708
709	<Route path="/" component={LOIDocument} />
710
711	<Route path="/nda" component={NDADocument} />
712
713	```
714
715	Then generate separate PDF/DOCX files for each document by pointing Puppeteer at each route and running a separate python-docx script per document. Present all files together so the user receives the complete package.
716
717	IMPORTANT: Since all routes share the same `index.html`, the HTML`<title>`tag applies to every document. Each PDF generation script must call`page.evaluate(() => { document.title = "Correct Document Title"; })`before`page.pdf()` to set the correct PDF metadata title. Otherwise the PDF viewer's title bar will show the wrong document name.
718
719	## Drafting Rules
720
721	1. Always include the disclaimer at the top of every output — this is not legal advice
722	2. Start from Bonterms/Common Paper for NDAs and service agreements; use the clause structures in "M&A / Transaction Documents" for LOIs and purchase agreements
723
724	3. Quote exact problem text with section numbers, then give replacement language
725	4. Flag jurisdiction dependencies — non-compete enforceability, anti-indemnity statutes, and consumer protection vary wildly by state/country
726
727	5. When stakes are high (>$50K, equity, exclusivity, personal guarantees) → recommend attorney review explicitly
728	6. For multi-document transactions, ensure consistent terminology and cross-references across all documents
729
730	## Documents System
731
732	The platform includes a generic document management system for any type of legal document. Documents are owner-scoped and can optionally be linked to a DD room.
733
734	### Schema (`documents` table)
735
736	\| Column \| Type \| Description \|
737
738	\|--------\|------\|-------------\|
739
740	\| `id` \| text (UUID) \| Primary key \|
741
742	\| `ownerId` \| text \| Clerk user ID of the document owner \|
743
744	\| `title` \| varchar(500) \| Document title \|
745
746	\| `documentType` \| varchar(100) \| Flexible type field (e.g., "LOI", "NDA", "APA", "Employment Agreement", "Lease") \|
747
748	\| `content` \| text \| Full document content (Markdown/plain text) \|
749
750	\| `status` \| varchar(50) \| Document status, default "draft" \|
751
752	\| `ddRoomId` \| text \| Optional link to a DD room \|
753
754	\| `createdAt` \| timestamp \| Auto-set on creation \|
755
756	\| `updatedAt` \| timestamp \| Auto-set on creation and update \|
757
758	### Key Design Principles
759
760	- Type-agnostic: The `documentType` field is a free-text string, not an enum. Any document type can be stored — LOIs, NDAs, asset purchase agreements, operating agreements, board resolutions, etc.
761	- Owner-scoped: All document endpoints filter by the authenticated user's `ownerId`. Users can only see, edit, and delete their own documents.
762
763	- Room linkable: Documents can optionally reference a `ddRoomId` to associate them with a due diligence room (e.g., the LOI for an acquisition).
764
765	### API Endpoints
766
767	\| Method \| Path \| Description \|
768
769	\|--------\|------\|-------------\|
770
771	\| GET \| `/documents` \| List all documents owned by the current user \|
772
773	\| GET \| `/documents/:documentId` \| Get a single document (owner-only) \|
774
775	\| DELETE \| `/documents/:documentId` \| Delete a document (owner-only) \|
776
777	### Frontend
778
779	- Dashboard: Document cards appear below the DD rooms section. Each card shows title, type badge, status, and creation date. Hovering reveals a delete button with inline confirm/cancel.
780	- Document view: `/documents/:documentId` renders the full document content.
781
782	## Due Diligence Room Platform
783
784	The legal platform includes an interactive Due Diligence (DD) room for M&A transactions. This is a full-stack feature with its own database schema, API endpoints, and React UI.
785
786	### Architecture
787
788	- Frontend: `artifacts/legal-platform/src/pages/dd-room.tsx` — React + shadcn/ui
789	- API: `artifacts/api-server/src/routes/dd-*.ts` — Express REST endpoints
790
791	- DB: PostgreSQL via Drizzle ORM — tables in `lib/db/src/schema/dd-*.ts`
792	- Auth: Clerk; middleware at `artifacts/api-server/src/middlewares/requireAuth.ts`
793
794	- Room Auth: `artifacts/api-server/src/middlewares/requireRoomAccess.ts` — room-level authorization
795	- File Storage: Replit Object Storage via `@google-cloud/storage`
796
797	- OpenAPI: `lib/api-spec/openapi.yaml`with codegen to`@workspace/api-client-react`and`@workspace/api-zod`
798
799	### Database Tables
800
801	\| Table \| Purpose \|
802
803	\|-------\|---------\|
804
805	\| `dd_rooms` \| Room metadata: name, buyer/seller, purchase price, deal structure, ownerId \|
806
807	\| `dd_categories` \| Checklist categories (8 auto-created from template, plus custom) \|
808
809	\| `dd_items` \| Individual checklist items with status tracking \|
810
811	\| `dd_files` \| Uploaded documents linked to items (object storage paths) \|
812
813	\| `dd_comments` \| Item-level discussion threads \|
814
815	\| `dd_activity` \| Audit log of all actions \|
816
817	\| `dd_participants` \| Room access control (email + role: viewer/contributor/admin) \|
818
819	### Standard Checklist Template
820
821	When a room is created, 8 categories with 57 items are auto-populated from `DD_TEMPLATE`in`dd-rooms.ts`:
822
823	1. Corporate & Organizational (7 items) — Formation docs, bylaws, minutes, cap table, good standing, org chart, jurisdictions
824	2. Financial (8 items) — Audited/interim statements, tax returns, debt schedule, AR/AP aging, revenue breakdown, projections, bank accounts
825
826	3. Contracts & Agreements (7 items) — Customer/vendor/partnership/distribution/franchise/government contracts, change-of-control provisions
827	4. Intellectual Property (8 items) — Patents, trademarks, copyrights, domains, software licenses, IP assignments, open-source audit, trade secrets
828
829	5. Employees & Benefits (9 items) — Census, employment agreements, contractors, handbook, non-competes, benefits, stock options, workers' comp, OSHA
830	6. Litigation & Legal (6 items) — Pending litigation, settlements, consent decrees, investigations, insurance claims, regulator correspondence
831
832	7. Insurance (4 items) — All policies, claims history, broker info, certificates
833	8. Technology & Data (8 items) — Architecture docs, data flows, SOC 2, breach history, BCP/DR, SLA reports, vendor assessments, privacy policy
834
835	Custom categories and items can be added per-room via the API.
836
837	### Item Status Workflow
838
839	Items track progress through these statuses:
840
841	```text
842
843	not_started → uploaded → under_review → approved
844
845	→ flagged (with note)
846
847	```
848
849	#### Automatic transitions
850
851	- Uploading a file to a `not_started`item changes its status to`uploaded`
852	- Deleting all files from an `uploaded`item reverts its status to`not_started`
853
854	- All other transitions (under_review, approved, flagged) are manual via the UI
855
856	### Access Control
857
858	Room-level authorization is enforced via `requireRoomAccess`middleware (`artifacts/api-server/src/middlewares/requireRoomAccess.ts`) and its variants. Each variant looks up the resource chain to find the parent room, then checks if the user is the room owner or an active participant.
859
860	\| Middleware \| Lookup Chain \| Used On \|
861
862	\|-----------\|-------------\|---------\|
863
864	\| `requireRoomAccess(roomIdParam)` \| Direct roomId \| Room detail, update, stats, activity, participants, categories \|
865
866	\| `requireCategoryRoomAccess(categoryIdParam)` \| category → room \| Delete category, create items \|
867
868	\| `requireItemRoomAccess(itemIdParam)` \| item → category → room \| Update/delete items, list/create files, list/create comments \|
869
870	\| `requireFileRoomAccess(fileIdParam)` \| file → item → category → room \| Delete files \|
871
872	\| `requireCommentRoomAccess(commentIdParam)` \| comment → item → category → room \| Delete comments \|
873
874	#### Privilege levels
875
876	- Room owner: Full access to everything including participant management
877	- Admin participant: Can manage participants (add/remove) and all room content
878
879	- Contributor/Viewer participant: Can access room content but cannot manage participants
880	- Non-participant: Receives 403 on all room-scoped endpoints
881
882	The `GET /dd-rooms` listing only returns rooms where the user is owner or participant (no cross-tenant leakage).
883
884	Private file downloads (`GET /storage/objects/*`) also enforce room access by looking up the file's parent room through the`dd_files → dd_items → dd_categories` chain.
885
886	### Activity Feed Events
887
888	All significant actions are logged to `dd_activity` with the following event types:
889
890	\| Action \| Trigger \|
891
892	\|--------\|---------\|
893
894	\| `file_uploaded` \| File registered on an item \|
895
896	\| `file_deleted` \| File removed from an item \|
897
898	\| `comment_deleted` \| Comment removed from an item \|
899
900	\| `participant_removed` \| Participant removed from room \|
901
902	\| `status_changed` \| Item status updated \|
903
904	Each activity entry records: `roomId`,`userId`,`userName`,`itemId`(optional),`action`,`details`,`createdAt`.
905
906	### File Upload Flow
907
908	1. Frontend requests presigned upload URL via `POST /api/storage/uploads/request-url` (sends file name, size, contentType as JSON)
909	2. Frontend uploads file directly to object storage using the presigned URL (PUT to GCS)
910
911	3. Frontend registers the file via `POST /api/dd-items/:itemId/files` with the returned storage URL
912	4. Backend normalizes the GCS URL to an object entity path (`/objects/<entityId>`) and validates:
913
914	- URL must normalize to `/objects/` prefix format
915	- URL must not already be registered (prevents duplicate registration / IDOR)
916
917	1. File downloads served via `GET /api/storage/objects/*path` with room-level authorization
918
919	### API Endpoints (2)
920
921	\| Method \| Path \| Auth \| Description \|
922
923	\|--------\|------\|------\|-------------\|
924
925	\| GET \| `/dd-rooms` \| requireAuth \| List rooms (filtered by owner/participant) \|
926
927	\| POST \| `/dd-rooms` \| requireAuth \| Create a new DD room (auto-populates 8 categories) \|
928
929	\| GET \| `/dd-rooms/:roomId` \| requireAuth + roomAccess \| Get room with categories and items \|
930
931	\| PUT \| `/dd-rooms/:roomId` \| requireAuth + roomAccess \| Update room metadata \|
932
933	\| POST \| `/dd-rooms/:roomId/categories` \| requireAuth + roomAccess \| Add a custom category \|
934
935	\| DELETE \| `/dd-categories/:categoryId` \| requireAuth + categoryRoomAccess \| Delete a category and its items \|
936
937	\| POST \| `/dd-categories/:categoryId/items` \| requireAuth + categoryRoomAccess \| Add an item to a category \|
938
939	\| PUT \| `/dd-items/:itemId` \| requireAuth + itemRoomAccess \| Update item (name, status, notes) \|
940
941	\| DELETE \| `/dd-items/:itemId` \| requireAuth + itemRoomAccess \| Delete an item \|
942
943	\| GET \| `/dd-items/:itemId/files` \| requireAuth + itemRoomAccess \| List files for an item \|
944
945	\| POST \| `/dd-items/:itemId/files` \| requireAuth + itemRoomAccess \| Register an uploaded file \|
946
947	\| DELETE \| `/dd-files/:fileId` \| requireAuth + fileRoomAccess \| Delete a file \|
948
949	\| GET \| `/dd-items/:itemId/comments` \| requireAuth + itemRoomAccess \| List comments for an item \|
950
951	\| POST \| `/dd-items/:itemId/comments` \| requireAuth + itemRoomAccess \| Add a comment \|
952
953	\| DELETE \| `/dd-comments/:commentId` \| requireAuth + commentRoomAccess \| Delete a comment \|
954
955	\| GET \| `/dd-rooms/:roomId/stats` \| requireAuth + roomAccess \| Get completion statistics \|
956
957	\| GET \| `/dd-rooms/:roomId/activity` \| requireAuth + roomAccess \| Get activity feed \|
958
959	\| GET \| `/dd-rooms/:roomId/participants` \| requireAuth + roomAccess \| List participants \|
960
961	\| POST \| `/dd-rooms/:roomId/participants` \| requireAuth + roomAccess (owner/admin) \| Add a participant \|
962
963	\| DELETE \| `/dd-participants/:participantId` \| requireAuth + roomAccess (owner/admin) \| Remove a participant \|
964
965	\| POST \| `/storage/uploads/request-url` \| requireAuth \| Get presigned upload URL \|
966
967	\| GET \| `/storage/objects/*` \| requireAuth + fileRoomAccess \| Download a file \|
968
969	## Limitations
970
971	- NOT a substitute for legal advice from a licensed attorney
972	- Cannot account for jurisdiction-specific laws
973
974	- Cannot verify legal enforceability of any clause
975	- Cannot handle litigation, regulatory filings, or court documents
976
977	- Templates are starting points, not final legal documents