FaceKom v2 — Documentation Index

The session-driving entrypoint for the FaceKom v2 knowledge base. Start every FaceKom session here, then jump to the doc that answers your question (see Start here). Every claim in this vault is source-verified against read-only git; provenance lives in VERIFICATION.

What is FaceKom

FaceKom (internal codename vuer) is a KYC / eKYC video-identification platform built by TechTeamer: a polyglot, RabbitMQ-message-bus-centric system whose spine is a Node.js operator/customer web pair (vuer_oss = operator/back-office system-of-record, vuer_css = customer-facing front door), with a Python computer-vision engine (vuer_cv) for face/document/MRZ/liveness ML, Janus carrying the WebRTC media, and a swarm of single-purpose RabbitMQ-RPC microservices (PDF signing, antivirus, timestamping, EU trust-lists, Hungarian ID-registry scraping, reporting, admission control) hanging off the bus. A separate eSign product pair (esign_oss / esign_css) reuses the same shape, and a newer TypeScript janus-sdk monorepo is a v2 WebRTC media plane with its own RabbitMQ + Postgres. The product is delivered as per-partner deployments built from long-running customization/<client> Git branches layered over the devel core (banks and govt eID: K&H, MBH/MKB, Raiffeisen, UniCredit, Cofidis, DAP, …). Source: architecture-overview §1–2, techteamer-org-inventory, customization-clients.

Two names, one product

vuer = the codename used throughout the source (repo names vuer_oss/vuer_css/vuer_cv, app vuer_oss 1.9.11, DB vuer_oss). FaceKom = the product/brand. TechTeamer = the GitHub org / company that owns it.

Start here

For a future Claude session — which doc answers which question:

If you want to do work (not just understand the system), start with working-on-facekom — the senior-engineer onboarding playbook and day-to-day workflows — then drop into the Operations & day-to-day docs as needed.

If you need to know…	Read
The whole system: services, processes, what-talks-to-what, ports, topology diagram	architecture-overview
How transports work (RabbitMQ RPC/PubSub/work-queue pairs, HTTP, Socket.IO, Janus, queue-name catalog)	inter-service-comms
How one core becomes N per-client builds (the DI service container + hook/override engine + customization/ overlay)	customization-architecture
What a specific partner actually customizes + cross-client patterns (22 client findings synthesized)	customization-clients
Which customization/* branch exists, who owns it, how many, how stale	customization-branch-catalog
The flow engine (self-service v2 step machine) + per-flow catalog	flows
Login / SAML / WebAuthn / TOTP / JWT-JWE / ACL authorization	auth
The Postgres schema (Sequelize models, relations)	data-model
How the app is built, dockerized, and released from source (vuer_build / vuer_docker / vuer-release)	build-deploy-release
What a given bin/ CLI or helper script does (cross-repo)	bin-and-scripts
Naming conventions, acronyms (KKSZB, eMRTD, PAD, KAÜ…), glossary	conventions-and-glossary
Every repo in the TechTeamer org, what’s local vs not, what to clone next	techteamer-org-inventory
A single repo in depth (role, layout, entrypoints, config, customization seam)	the matching vuer_oss-style doc (see )
How any of this was verified / what’s unverified	VERIFICATION

Repository map

One repos/<name>.md per repository. 🟢 local = checked out under /Users/levander/coding/facekom/; 🔵 clone = under /Users/levander/coding/facekom-v2-clones/ (cloned for analysis). Source: techteamer-org-inventory §Local-vs-org-reconciliation.

facekom-core (🟢 local):

• vuer_oss — operator/back-office server; system-of-record, owns Postgres + crypto + WebRTC record→convert pipeline; 40+ RPC servers. (vuer_oss 1.9.11)
• vuer_css — customer-facing web/socket front door (homepage→system-check→waiting-room→videochat + self-service); no DB, bridges to OSS over RabbitMQ.
• portal_css — Customer Portal front end (login/registration/personal-data); proxies to OSS via RPC.
• esign_oss — eSign operator-side server + bank-webhook API; owns the eSign DB (Offers/Contracts/Signatures/App registry).
• esign_css — eSign customer signing UI; no DB.

computer-vision / backend-services:

• vuer_cv (🔵) — Python CV/ML engine (face/doc/MRZ/barcode/liveness/PAD/hologram); HTTP REST + streaming WS + Redis-RPC worker fleet.
• pdfservice (🔵) — Kotlin PDF signing/validation (PDFBox, EU DSS); RPC-only (pdf-* queues).
• antivirus_service (🔵) — Node AV scanning gateway; RPC-only (anti-virus-scanner quorum queue).
• timestamp_service (🔵) — RFC3161 trusted-timestamp client library.
• trust_list_proxy (🔵) — Kotlin EU trusted-list (LOTL/TL) fetch/cache/validate library.
• nyilvantarto_scraper (🔵) — Hungarian official ID-registry (KKSZB) verification; RPC-only (kkszb-rpc).
• report-engine (🔵) — metrics/report aggregation over RPC (logger-report-request) + TimescaleDB.
• resource-manager (🔵) — admission-control / capacity FIFO for the identification flow; RPC + Postgres.
• vuer_emrtd (🔵) — Kotlin eMRTD/NFC passport-chip parsing + passive auth; CLI (JSON in→out).

SDK / WebRTC:

• janus-sdk (🔵) — TypeScript pnpm monorepo: v2 WebRTC media plane (signaling-server + room-state-server + media-converter) orchestrating Janus over RabbitMQ; own Postgres.
• janus-api (🔵) — @techteamer/janus-api Janus WebRTC-Gateway client (videoroom/streaming/videocall); isomorphic.
• vuer_web_sdk (🔵) — browser-embeddable FaceKom Web SDK (React/Vite IIFE), self-service v2.
• video-processor (🔵) — @techteamer/video-processor browser virtual-background/blur lib (MediaPipe); copy-paste distribution.

shared libraries:

• mq (🔵) — @techteamer/mq RabbitMQ wrapper (RPC/PubSub/work-queue/gathering); backbone of all RPC.
• cert_utils (🔵) — @techteamer/cert-utils certificate parsing utilities; in-process, no network.
• acl (🔵) — @techteamer/acl access-control-list logic; in-process.

build / deploy / release (🟢 local):

• vuer_build — Docker build orchestration + release-ZIP packaging.
• vuer_docker — Docker runtime/image assets.
• vuer-release — declarative release descriptors (release.json) + OS install scripts.

Cross-cutting docs

• architecture-overview — end-to-end system topology, service/process table, per-transport connection details.
• customization-architecture — the DI service container + ServiceBus hook/override engine + customization/ overlay tree, and the core-file-override upgrade risk.
• customization-clients — per-client synthesis of the 22 client findings + cross-client patterns (email/SMS/flows/SOAP/Oracle/upgrade-risk).
• customization-branch-catalog — verified inventory of customization/* branches across all repos (+ vuer_css GitHub-API view).
• flows — the flow engine (self-service v2 step machine) and flow catalog.
• inter-service-comms — RabbitMQ/HTTP/Socket.IO/Janus message paths and the full queue-name catalog.
• auth — authentication & authorization across vuer/esign OSS+CSS + the acl lib (Passport/SAML/WebAuthn/TOTP/JWT-JWE).
• data-model — vuer_oss Sequelize data model (Postgres schema).
• build-deploy-release — build, dockerize, and release from source (UBI/Harbor; vuer_build · vuer_docker · vuer-release).
• bin-and-scripts — cross-repo catalog of bin/ CLIs and helper scripts.
• conventions-and-glossary — naming conventions, acronyms, and glossary.
• techteamer-org-inventory — full 90-repo TechTeamer org inventory with local/clone marks and clone shortlist.

Operations & day-to-day

For actually doing the work — onboarding, running the stack, testing, and shipping client updates.

• working-on-facekom — the senior-engineer onboarding playbook / day-to-day workflows (the new “start here for doing work” doc).
• dev-environment — Tailscale SSH dev box, local checkout vs SSHFS mount, DNS, containers, registry (operational/env).
• running-the-stack — how to bring up the full stack (vuer_localdev bin/facekom, vuer_docker bin/vuer.sh, per-service supervisord dev/docker profiles, process model, ports).
• testing — unit (Jest) / e2e (Playwright) / lint / CI pipelines per repo (+ the e2e DB-wipe gotcha).
• devel-update-workflow — the dated update/customization/<client>-<date> devel→client sync branches and how to test them.

Key numbers

All confirmable from the docs/source listed:

• 19 topic docs in this vault after adding the 5 operations docs (working-on-facekom, dev-environment, running-the-stack, testing, devel-update-workflow) to the cross-cutting set.
• 90 repositories in the TechTeamer GitHub org; 24 checked out locally (8 under facekom/, 16 under facekom-v2-clones/), 66 not local. 13 archived, 23 forks. (techteamer-org-inventory §Counts)
• 242 customization/* branches on vuer_oss origin (customization-architecture §6); local-refs view counts 154 for vuer_oss, 15 esign_css, 15 esign_oss, 10 portal_css (customization-branch-catalog). vuer_css authoritative (GitHub API): 162 branches matching customization (the local clone is fetch-restricted to 2).
• 22 per-client findings synthesized: 19 vuer_oss + 2 portal_css + 1 esign_oss (customization-clients). 21 of 22 clients edit CORE files (upgrade risk); only instacash is config-only.
• 61 Sequelize models in vuer_oss / Postgres vuer_oss @ :5432 (architecture-overview §3.6, techteamer-org-inventory).
• 40+ RabbitMQ RPC pairs between vuer_css and vuer_oss (matched by identical queue name) (architecture-overview §3.1).
• vuer_oss runs ≥8 supervised processes (server.js, convert.js, media.js, background.js, cron.js, storage.js, integrationLog.js, nginx, redis) (architecture-overview §5).
• vuer_cv HTTP API: ~24 routes across /api/v1, /api/v2, /api/v3 (architecture-overview §3.2).
• vuer_oss customization/ overlay tree: e.g. ui/=199, test/=84, email/=71, listeners/=55, flow/=48, ocr/=40 files (customization-architecture §5).
• App version line clusters at vuer_oss 1.9.11.x across partner branches (customization-clients, techteamer-org-inventory).

Customization model in brief

devel is the core product; each partner deployment is a long-running customization/<client> Git branch that layers code into a parallel customization/ overlay tree, applied last in every boot through a process-wide serviceContainer DI singleton plus a ServiceBus hook (addHook/callHooks/callOnlyHook) and override (registerOverride/callOverride) registry. A well-behaved partner change touches zero core files (new flow/email/SMS/CV-recipe = new overlay folder; new behaviour = a hook or override), so the same core boots unmodified with any subset of customizations. In practice most partner branches also rewrite shared core files (server.js, config/*.json, engines/**, bin/**), which is the central maintenance hazard — forward-merging devel into 200+ partner branches conflicts in core, not in the isolated overlay. Full mechanism: customization-architecture; per-client reality: customization-clients; branch inventory: customization-branch-catalog.

How this was generated

This vault was produced by the facekom-v2 discovery workflow (_workflow/complete-facekom-v2.workflow.js): for each repo and cross-cutting topic, a subagent read the actual source read-only via git -C <repo> show <ref>:<path> / git ls-tree / git grep / git for-each-ref / git diff (no checkout, no build, no writes to any source repo), verified default branches (devel/master/main), and cited every claim to repo/path:LINE. Customization facts come from merge-base (three-dot) diffs of customization/<client> against origin/devel. Org-wide facts come from gh repo list TechTeamer / gh api. Anything that could not be proven from opened source is segregated under each doc’s Gaps / Unverified section. Cross-doc provenance and the full verification ledger: VERIFICATION.

Snapshot date

All docs are verified: 2026-05-30. Branch counts, tip dates, and the org repo list are snapshots from that date and will drift — re-run the source commands (cited in each doc’s Sources) to refresh.