Skip to content

Issue #40: Lebanese legal + compliance review (affiliate / consumer / privacy)

  • Issue: #40
  • Started: 2026-04-28
  • Completed: in progress

Goal

Produce a Lebanese legal + compliance baseline for 961tech as an affiliate-monetised consumer aggregator. Two artifacts:

  1. docs/reference/legal-compliance.md — a structured per-surface reference (affiliate, consumer, privacy) with concrete obligations, the gap between Lebanese law and EU/US norms, recommended baseline behaviour, and an explicit "needs lawyer review" register.
  2. docs/rfc/0005-compliance-baseline.md — five decisions to take to MASTER (cookie banner timing, affiliate disclosure shape, ToS / privacy policy origin, data retention windows, liability disclaimer placement).

Cross-references to #29 DB architecture, #11 Auth.js, #14 price-drop alerts, #17 affiliate reconciliation. Doc only — no code, no schema.

Out of scope

  • No code or schema changes. Pure docs ticket.
  • No final legal sign-off. This is research-grade. The "needs lawyer review" section is load-bearing — we explicitly flag what a Lebanese lawyer must rubber-stamp before launch.
  • No EU-/US-specific compliance design. GDPR / FTC / CCPA referenced as comparators only; 961tech ships in Lebanon first. Re-visit if EU traffic ≥ 5% of sessions post-launch (mirrors the ADR-0004 i18n revisit trigger shape).
  • No drafting of the actual ToS / Privacy Policy / cookie banner text. That work follows the RFC sign-off; tracked as follow-up issues.
  • No Lebanese commercial registration decision. Whether 961tech needs to incorporate as a Lebanese SAL / SARL is a question for MASTER + a Lebanese lawyer; this doc surfaces the question, doesn't answer it.
  • No tax-residency / personal-income classification. Touches MASTER's salary + side-income tax posture; out of scope for a project doc.

Approach

Three-phase research + synthesis:

  1. Parallel research per legal surface — dispatch three subagents (superpowers:dispatching-parallel-agents), one per surface (affiliate/commerce, consumer protection, privacy/data protection), each with a tight scope, an explicit "Lebanese law specific" priority, and an instruction to flag uncertain findings.
  2. Synthesise into reference doc — pull subagent findings into docs/reference/legal-compliance.md using a fixed per-surface template (statute / what it says / what it requires of an aggregator / gap vs EU/US / 961tech baseline / open questions). Add a top-of-doc "needs lawyer review" register that aggregates the flagged items from all three surfaces.
  3. Write RFC-0005 — distil the five decisions for MASTER (cookie banner, affiliate disclosure, ToS/privacy-policy origin, data retention, liability disclaimer placement). Each decision: options, recommendation, rationale, what's at stake if we get it wrong.
  4. Verify with mkdocs build --strict. One atomic commit. No push, no PR.

Why parallel agents: the three surfaces are research-independent — affiliate / consumer / privacy law lookups don't share state. Sequential would waste wall-clock. Each subagent gets the same hardening rules (don't fabricate citations, prefer primary sources, label uncertainty), but works in isolation against a different statute set.

Per-surface research template (locked before dispatch)

Each subagent returns a markdown section using these fields:

## <Surface name>

### Statutes / official sources

- **<Statute number / law name>** — <one-line description, link to primary source if available>
- ...

### What this requires of 961tech

Concrete obligations, with citations to the statute section if found. If uncertain, flag with `(unverified — needs lawyer review)`.

### Gap vs EU / US norms

Where Lebanese law is silent, looser, or different from GDPR / FTC / CCPA / EU consumer-rights directive. One paragraph.

### Recommended 961tech baseline

What 961tech should do regardless of strict legal requirement, framed as a defensible default. Tie to specific UCs / ADRs / issues where applicable.

### Open questions for MASTER + lawyer

Bullet list. Each item: the question, why it matters, what evidence we'd need to answer it.

### Sources

URLs, statute numbers, official-gazette references.

Steps

  • Step 1: Plan committed (this file)

  • Verification: git status shows the plan added; doc renders under mkdocs serve.

  • Step 2: Dispatch three parallel research subagents

  • One per surface: affiliate/commerce, consumer protection, privacy/data protection.
  • Each subagent has WebFetch + WebSearch and a tight prompt with the template above.
  • Hardening: no fabricated statute numbers; primary sources preferred; uncertain findings flagged.

  • Verification: three structured reports in conversation transcript.

  • Step 3: Synthesise docs/reference/legal-compliance.md

  • Use the per-surface template.
  • Top-of-doc: scope, method, honest limits, "needs lawyer review" register (deduped across surfaces).
  • Each surface section.
  • Cross-reference to #29, #11, #14, #17 + relevant ADRs (0003, 0004) + use-cases (UC-2, UC-G, UC-L).

  • Verification: doc renders cleanly under mkdocs serve; every link resolves.

  • Step 4: Write docs/rfc/0005-compliance-baseline.md

  • Use docs/rfc/_template.md.
  • Five decisions: cookie banner M1-or-defer; affiliate disclosure shape + placement; ToS/privacy policy origin (hand-roll / AI-assisted-then-lawyer-review / hire-lawyer); data retention windows (scraped listings, click logs, email subscribers); liability disclaimer (per-listing vs site-wide).
  • Each decision: options, recommendation, rationale, risk if wrong.

  • Verification: RFC renders; all internal links resolve.

  • Step 5: Update docs/reference/index.md

  • Add row for legal-compliance.md to the "Available" table.

  • Verification: index page reflects new entry.

  • Step 6: Update docs/rfc/index.md

  • Add row for RFC-0005.

  • Verification: index page reflects new entry.

  • Step 7: mkdocs build --strict

  • Verification: zero broken references; clean build.

  • Step 8: One atomic commit

  • docs(reference,rfc): legal + compliance baseline (#40)

  • Verification: git log -1 shows the commit; no push.

  • Step 9: Final report to MASTER

  • Commit SHA, 2-3 sentence summary, top 3 launch obligations + top 3 deferred items, open questions, sources.

Risks

Risk Likelihood Mitigation
Subagent fabricates statute numbers (Lebanese law is poorly indexed online) Medium Hardening rule in subagent prompt; spot-check every cited statute against a primary source; demote unverifiable claims to "needs lawyer review"
Lebanese-law gaps mean we can't answer some questions definitively High Design the doc to surface the gap explicitly. The "needs lawyer review" register is a feature, not a defect
RFC decisions land on MASTER without enough comparable evidence (e.g. cookie banner) Medium Each RFC decision lists options + rationale + risk-if-wrong; MASTER can punt with eyes open
Conflict with ADR-0004 (English-only) — Lebanese consumer law might require Arabic for certain disclosures Medium Subagent #2 (consumer protection) explicitly probes this. If finding contradicts ADR-0004, surface as a STOP-and-ask item per the prompt
Out-of-scope creep into Lebanese tax / commercial registration Low Out-of-scope section is explicit; subagents instructed to flag-and-defer

Tests

No code changes → no test suite changes. The mkdocs build --strict gate catches broken refs. Self-review: read every new page in mkdocs serve once before commit.

Doc updates

  • New: docs/reference/legal-compliance.md
  • New: docs/rfc/0005-compliance-baseline.md
  • New: docs/plans/2026-04-28-issue-40-legal-compliance.md (this file)
  • Modify: docs/reference/index.md (add legal-compliance entry)
  • Modify: docs/rfc/index.md (add RFC-0005 entry)

Rollback

git revert <commit> restores prior state. No production / runtime impact since this is docs-only.