Lexery - Open Questions and Drift

Purpose

LLM Wiki має не лише збирати знання, а й позначати місця невідповідності. Ця сторінка фіксує саме такі зони.

Drift 1 — Root README vs reality

Observed

  • Root README.md current repo says apps/portal is a reserved placeholder.
  • apps/portal is in fact a real Next.js app with many product surfaces.

Meaning

  • Root orientation docs are stale.

Drift 2 — Plan taxonomy

Observed

  • Backend schema comment: free/pro/enterprise
  • Frontend plan UI: free/starter/mentor/pro

Meaning

  • Subscription model is not normalized across layers.

Drift 3 — Verify/Deliver ownership

Observed

  • Architecture language suggests clean U11 and U12 separation.
  • Current active consumers still live in write/verifyConsumer.ts and write/deliverConsumer.ts.

Meaning

  • Runtime is ahead of folder cleanup.

Drift 4 — Azure docs vs checked code

Observed

  • Azure docs describe api-gateway, agent-gateway, agent-worker split with ROLE=API/WORKER.
  • Current repo does not fully prove that deploy topology in code.

Meaning

  • Azure topology should be read as target architecture unless separately verified live.

Drift 5 — Business model vs billing plumbing

Observed

  • Plans and subscriptions are visible.
  • Payment provider integration is not.

Meaning

  • Monetization semantics exist earlier than billing implementation.

Drift 6 — Docs maturity vs integration maturity

Observed

  • Brain architecture is extensively documented.
  • Product shell is visibly progressing.
  • End-to-end integration between portal/api/brain is still incomplete.

Meaning

  • Documentation completeness in one subsystem can give a false sense of total product integration.

Drift 7 — Legacy naming and repo lineage

Observed

  • Older repos are still named Ukrainan-Lawyer-LLM(-BETA).
  • Current product identity is Lexery.

Meaning

  • Repository naming still reflects historical layers, not current brand/system boundaries.

Key Open Questions

  • Which branch will become the real convergence branch: dev, legal-agent-brain-dev, or a new integration branch?
  • What is the final canonical plan taxonomy?
  • How will payments actually be wired?
  • Which pieces of memory/docs ship in first productized form?
  • Is Azure really the final host shape, or only one planning target?
  • What is the real production path: portal → api → brain, or portal direct route layers plus later migration?
  • add customer / user interview history if it exists locally
  • ingest Figma or frontend design sources if available
  • ingest more Linear documents, especially context packets
  • ingest LLDBI admin reports and runtime forensics as first-class pages

See Also