vuer_build — FaceKom Docker Build & Packaging Environment

vuer_build

The Docker build orchestration + release-packaging repository for FaceKom. It is not an application service — it contains no runtime app of its own. Instead it holds Dockerfiles, docker-compose files, per-partner customization configs, bash build drivers, and a Node.js packaging tool that together turn the FaceKom application source repos (vuer_oss, vuer_css, portal_css, vuer_cv, …) into versioned, tagged Docker images and into a shippable ZIP “build package” for customers.

Repo path & branch

Local clone: /Users/levander/coding/facekom/vuer_build. Base branch: main (last commit 341a553, 2026-05-28 on main; the checked-out working branch at survey time was feature/FKITDEV-8868). README is in Hungarian.

See also: architecture-overview · customization-architecture · customization-branch-catalog · vuer_oss

---

1. Purpose & role in FaceKom

vuer_build is the build/release toolchain. README.md:1-3 names it “FaceKom Docker Build Environment — Környezet buildek és átadásra kerülő forráskód-csomagok számára” (“Environment for builds and source-code packages to be handed over”). Concretely it does three jobs:

1. Build base images — clones the FaceKom app source repos at a given git tag and bakes them into UBI8-based Docker images (build.sh -b <tag>; docker-compose-base.yml).
2. Build common infra images — RabbitMQ, TURN, ClamAV, PostgreSQL shared images (build.sh -c; docker-compose-common.yml).
3. Produce a release ZIP — build.sh --build_package runs a Node.js packager (packaging/workspace/create-build-package.js) that re-clones sources, strips JS/TS comments, generates PDF manuals, collects credits/audit reports, exports the built docker images as .tar, and zips everything (optionally AES-256 password-protected) to packaging/workspace/output/FaceKom_build_${VUER_TAG}.zip (README.md:38-48, build.sh:513-536).

The image naming convention throughout is harbor.techteamer.com/${PROJECT_NAME}/<service>:<version>.<build>-<security_number> (docker-compose-base.yml:16-57). harbor.techteamer.com is the TechTeamer container registry.

FaceKom = "Vuer"

The product’s internal/legacy name is Vuer. vuer_oss (operator/server side), vuer_css (client/customer side), portal_css, vuer_cv (computer-vision), janus (WebRTC gateway) are the FaceKom services this repo builds.

---

2. Tech stack & runtime

Aspect	Value	Source
Build drivers	Bash scripts (build.sh, build-openshift.sh, sign-partner.sh)	files at repo root
Orchestration	Docker + docker compose (compose file schema v2.4 / v3)	docker-compose-*.yml
Packaging tool	Node.js, ESM ("type": "module")	packaging/workspace/package.json:4
Packaging deps mgr	Yarn (yarn install in packaging Dockerfile)	packaging/Dockerfile:28
Base OS for all images	registry.access.redhat.com/ubi8/ubi-minimal (RHEL UBI8)	base/vuer_oss/Dockerfile:6,68,143; packaging/Dockerfile:1
Node in app images	Node.js 22.x (also a v20 installer present)	base/vuer_oss/tools/install-nodejs-22.sh:4; base/vuer_oss/Dockerfile:83
Node in packaging image	Node 20.x (nodesource el8)	packaging/Dockerfile:7
JVM in vuer_oss image	Java 11 (openjdk headless) — for emRTD + PDF signer	base/vuer_oss/Dockerfile:210
Image signing	cosign	sign-partner.sh:97

Recommended host environment (README.md:7-12)

Ubuntu 22.04+, Docker 26.1.1+, docker compose plugin 2.27.0+, git 2.34.1+. There is no package.json/engines field at repo root — the only Node manifest is packaging/workspace/package.json, used inside the packaging container. Required Node/JVM versions come from the Dockerfiles, not from an engines manifest.

There is no CI config (no .github/, .gitlab-ci.yml) tracked in the repo; builds are invoked manually via the bash scripts (verified: git ls-files shows no CI files).

---

3. Build & run

Entrypoints

There is no main/bin in a manifest. The human entrypoints are the three root bash scripts:

Script	Version const	Purpose	Source
build.sh	0.4.1	Primary driver: build base / portal / common images, build variants, create build package	build.sh:3, :21-58
build-openshift.sh	0.4.1 (labeled build.sh)	OpenShift-targeted variant of build.sh	build-openshift.sh:3-4
sign-partner.sh	0.1.1	cosign-sign a partner’s locally-built images	sign-partner.sh:3

The container entrypoints built into images: vuer_oss runs supervisord (CMD ["/usr/local/bin/supervisord","-n","-c","/etc/supervisor/supervisord.conf"], base/vuer_oss/Dockerfile:273); the packaging container runs node create-build-package.js (packaging/docker-compose-packaging.yml:31).

build.sh CLI (build.sh:21-58)

Commands: -b|--build-base <tag>, -p|--build-portal <tag>, -bv|--build-variant <n>, -pbv|--portal-build-variant <n>. Parameters: -i|--build-image <image> (single image), -c|--build-common, -s|--show-common-versions, -g|--git_source <url>. Options: -d|--debug (set -x), -nc|--no-cleanup, -bp|--build_package, -pw|--password <pw> (encrypt ZIP), plus -h, -v, and an undocumented -l|--list-partners (build.sh:446-451, note: it cd partners/ — wrong dir, the real dir is partner/).

Build stages run in order (build.sh:467-553): init → init_build_pack → base_build → (optional) common_build → custom_build (if partner/<tag>/docker-compose.yml exists) → build_pack (if --build_package) → cleanup.

Typical invocations (README.md:29-48, build.sh:49-56):

# build all base images for a tagged release
./build.sh -b microsec-1.9.11.12 -g git@github.com:TechTeamer
# build a single base image
./build.sh -b microsec-1.9.11.12 -i vuer_oss
# build common infra images
./build.sh -c
# build + produce password-protected release ZIP
./build.sh -b microsec-1.9.11.12 -g git@github.com:TechTeamer --build_package --password "password123"

Scripts inventory

No npm "scripts" block

packaging/workspace/package.json (the only package.json) has no scripts field — only name, version, main: create-build-package.js, type: module, and dependencies. The package is executed via node create-build-package.js / the compose command, not via npm run. (Verified package.json:1-17.) The npm run credits / npm run build calls in base Dockerfiles (base/vuer_oss/Dockerfile:127-128) run scripts defined in the vuer_oss repo, not here.

Dockerfiles present

Root-level + first-party Dockerfiles (all FROM ubi8/ubi-minimal unless noted):

• Base images: base/{vuer_oss,vuer_css,portal_css,janus}/Dockerfile.
• Common images: common/{rabbitmq-base,rabbitmq,turn-base,turn,clamav-base,clamav,postgresql-base,postgresql}/Dockerfile.
• Packaging: packaging/Dockerfile (Node 20 + yarn + git-lfs + zip + fontconfig; runs yarn install).
• Per-partner overrides: partner/<name>/{vuer_oss,vuer_css,portal_css,janus,turn,rabbitmq}/Dockerfile (39 partner dirs; not all have every service).

Start command(s)

This repo does not “start a server”. The produced images are started via the per-partner docker-compose.yml files (e.g. partner/microsec/docker-compose.yml) or downstream by vuer_oss deployment. The build itself is started by running ./build.sh ….

---

4. Top-level structure

Path	Role	Source/verified
build.sh	Main build driver (base/portal/common/custom + package)	build.sh:1-554
build-openshift.sh	OpenShift variant of the driver	build-openshift.sh
sign-partner.sh	cosign image-signing helper	sign-partner.sh
docker-compose-base.yml	Build defs for base images (janus, vuer_css, portal_css, vuer_oss)	file
docker-compose-common.yml	Build defs for common images (rabbitmq/turn/clamav/postgresql + -base)	file
base/	Base image build contexts: vuer_oss, vuer_css, portal_css, janus (Dockerfile + nginx/supervisor/yum/dnf/tools configs, TSA/emRTD/PDF assets)	dir listing
common/	Common-infra image contexts + common/settings.cfg global versions	dir listing
partner/	39 partner customization dirs (subdirectories of partner/, excluding the .gitkeep file), each with settings.cfg, docker-compose.yml, and per-service Dockerfile overrides	dir listing
packaging/	Release-ZIP builder: Dockerfile, docker-compose-packaging.yml, workspace/{create-build-package.js,package.json,yarn.lock}, contacts.md	dir listing
build-pack/	Default build-pack.env (all PACK_* flags default false)	build-pack/build-pack.env
features/	oracle/ and debug/ compose fragments — both docker-compose.yml are empty files	cat output (empty)
documentation/	Shipped PDFs (user + ops manuals) + oracle-instantclient.md	dir listing
.agents/	Present; .agents/ao/ exists but is empty (no files)	find output
.buildignore	Excludes partner/**, packaging/**, log/** from the buildcode pack	.buildignore:1-3
.gitignore	Ignores .idea, *.log*, *.key, *.pub	.gitignore:1-4
log/	Build log output dir (gitignored, created at runtime)	build.sh:9,86-87

features/ is a stub

features/oracle/docker-compose.yml and features/debug/docker-compose.yml are zero-byte empty files — no compose content. Don’t assume a working “oracle”/“debug” feature overlay exists here.

---

5. First-party bin/ directories

No first-party shell scripts live under any bin/ directory.

The only bin/ dirs in the repo are base/vuer_oss/emrtd/bin/ and base/vuer_oss/pdf/bin/, and they contain prebuilt platform binaries / launchers, not source scripts:

• base/vuer_oss/emrtd/bin/vuer_emrtd (~11 KB, mode 755) + vuer_emrtd.bat — emRTD (ePassport/eID chip reader) launcher; copied into the image at /opt/facekom/emrtd/ and chmod 755-ed (base/vuer_oss/Dockerfile:218-220).
• base/vuer_oss/pdf/bin/facekom_pdf_signer (~9 KB) + facekom_pdf_signer.bat — FaceKom PDF signer; copied to /opt/facekom/pdf/ (base/vuer_oss/Dockerfile:215-216). Backed by base/vuer_oss/emrtd/vuer_emrtd.jar (Java 11). These are opaque binaries; their internals were not read (and are out of scope).

The actual first-party helper scripts live under tools/, install/, and infra context dirs (read below):

Script	What it does	Source
base/{vuer_oss,vuer_css,portal_css}/tools/install-nodejs-22.sh	Writes a nodesource el8 yum repo for Node 22.x, keyed to $(uname -m), then microdnf makecache it. Removes any pre-existing nodesource repo first.	base/vuer_oss/tools/install-nodejs-22.sh:1-22
…/tools/install-nodejs-20.sh	Same pattern for Node 20.x (sibling of the 22 installer)	file present (per ls)
…/tools/supervisor-health-check.sh	Docker HEALTHCHECK: exits 1 if any supervisorctl status line is not RUNNING, or if any process has been up < 60 s (flap detection).	base/vuer_oss/tools/supervisor-health-check.sh:1-9
…/tools/debug_log	Conditional log filter piped into microdnf/build steps (gated by ARG DEBUG); copied to /usr/local/bin/ in every base Dockerfile	base/vuer_oss/Dockerfile:12,79,153
base/vuer_oss/install/install-tsa.sh	Installs e-Szigno TSA / CSCA trust-anchor certs into the OpenSSL certs dir and creates the OpenSSL hash symlinks (da191bd3.0, e868b802.0, 83094260.0, b978b94e.0). Run via a --mount=type=bind step.	base/vuer_oss/install/install-tsa.sh:1-16; base/vuer_oss/Dockerfile:223
common/rabbitmq-base/rabbitmq.sh	Container PID-1 wrapper for RabbitMQ: traps TERM→rabbitmqctl stop, runs rabbitmq-server & then wait (correct SIGTERM propagation).	common/rabbitmq-base/rabbitmq.sh:1-16
common/{clamav,turn,rabbitmq}-base/tools/supervisor-health-check.sh	Per-common-image supervisor health checks (same idea as above)	dir listing
common/postgresql-base/docker-entrypoint.sh	PostgreSQL container entrypoint	dir listing
partner/otp/rabbitmq/rabbitmq.sh, partner/*/rabbitmq/health_check.py, `partner/*/janus	rabbitmq/supervisor_stdout.py`	Partner-specific infra entrypoints / health checks / supervisor stdout relays

---

6. Key modules / services / entities

packaging/workspace/create-build-package.js — the release packager (488 lines)

ESM Node script, the most substantial first-party source. Flow (create-build-package.js:313-488):

1. Opens a write stream to /workspace/output/FaceKom_build_${VUER_TAG}.zip; uses archiver (plain zip) or archiver-zip-encrypted (aes256) when ZIP_PASSWORD is set (lines 316-319).
2. Builds a repositories list from env: known app services (vuer_css, vuer_oss, portal_css) cloned at VUER_TAG; extra services (vuer_cv, vuer_android, vuer_ios_sdk) cloned at name:branch from PACK_EXTRA_SOURCECODE; plus vuer_build@main (buildcode/docs) and vuer_docker@devel (dev env) (lines 25-26, 331-353).
3. For each repo: git clone --single-branch (gitClone, lines 28-42) from $GIT_SOURCE/<repo>.git; strips comments from every .js/.ts via strip-comments (lines 81-90, 376-380); git lfs pull for vuer_cv (lines 44-56, 382-386); removes .git/.github/.vscode (lines 92-101); applies per-repo .buildignore whitelist (getFiles/ignoreFileFilter, lines 286-311, 396-408).
4. Per-service archive placement via switch(service) (lines 410-433): vuer_android → facekom_sdk/selfservice_sdk; vuer_build → buildcode/ + top-level readme.md/contacts.md/instructions.md; vuer_docker → dev_environment/; default → sourcecode/<service>.
5. Optional additions gated by PACK_* env: documentation dirs, exported docker images (output/images), credits/, audit/, generated PDF manuals (collectManual, lines 181-284, driven by each repo’s docs.json), and a YouTrack release.pdf when YOUTRACK_TOKEN is set (youtrack, lines 107-135 → queries youtrack.techteamer.com/api/issues).

Manual generation ( collectManual, lines 159-284)

Reads <service>/docs.json; converts .adoc via asciidoctor, .md/.js via marked, renders to PDF via html-pdf; copies .png/.jpg and declared attachments (e.g. *.openapi.yml) alongside. merge:true concatenates into one PDF.

Base image build mechanism (base/vuer_oss/Dockerfile, 273 lines)

Three-stage multi-stage build illustrating how a FaceKom service becomes an image:

• januscompilestage (lines 6-60): UBI8 + EPEL + RPM Fusion; compiles libnice 0.1.17, libsrtp 2.3.0, and the Janus WebRTC gateway from $JANUS_REPOSITORY at $JANUS_VERSION_COMMIT (configured --disable-data-channels --disable-all-plugins …).
• vuercompilestage (lines 68-135): installs Node 22 + yarn; injects github.key SSH key; git clone --single-branch --branch $VUER_TAG ${GIT_SOURCE}/vuer_oss.git; prunes non-docker supervisor/nginx confs and non-docker|roles JSON configs; yarn install --production, npm run credits, npm run build, writes yarn-audit.txt.
• build stage (lines 143-273): final runtime — Node 22, supervisor (pip), redis (unix-socket, no AOF, 512 MB LRU), nginx, Java 11, FaceKom PDF signer + emRTD binaries, TSA certs; copies Janus binaries/libs from stage 1; HEALTHCHECK → supervisor-health-check.sh; runs as user techteamer; CMD supervisord.

github.key SSH key is baked into the build context

Base Dockerfiles copy base/<svc>/github.key to /root/.ssh/id_rsa to clone private repos (base/vuer_oss/Dockerfile:104). README.md:22-28 instructs operators to drop their own SSH key there. *.key is gitignored (.gitignore:3) so keys are not committed, but the build will fail without them. (Note: the README’s buildcode/base/... paths are the packaged layout; in-repo the path is base/<svc>/github.key.)

Partner customization model

Each partner/<name>/ provides settings.cfg (env vars sourced by build.sh) + docker-compose.yml (custom build contexts) + optional per-service Dockerfile overrides that FROM the base image and layer partner config. Example partner/microsec/settings.cfg: PROJECT_NAME=microsec-facekom, SERVICES="janus vuer_css vuer_oss", CUSTOM_SERVICES="janus rabbitmq turn vuer_css vuer_oss", Janus repo/commit pins, TT_UID/TT_GID=1030, SECURITY_NUMBER=20220408 (microsec settings.cfg:1-15). This is the same per-partner pattern documented in customization-architecture / customization-branch-catalog.

39 partners (partner/ listing): bankmonitor, barion, bb, cetelem, cib, cofidis, dap, demo, dunatakarek, equilor2, facekompont, fundamenta, generali-atvilagitas, granit, instacash, instant-demo, kh, magnet, mbh, microsec, mkb-instant, mvm, nn, nusz, otp, pmi, polgaribank, qtsp, raiffeisen, raiffeisen-instant, signal, szerencsejatek, takarek-mfszh, telemedicina, unicredit, unicredit-selfservice-v2, unicredit-srb, union, vkta.

---

7. Configuration

Configuration is env-var-file based (sourced by bash via set -a; source …; set +a), not getconfig/AJV.

File	Scope	Key vars	Source
common/settings.cfg	Global infra versions	COMMON_PROJECT_NAME=vuer-common, COMMON_SERVICES="rabbitmq turn clamav postgresql", RABBIT_VERSION_NUMBER=3.10.10, TURN_VERSION_NUMBER=4.6.3, CLAMAV_VERSION_NUMBER=0.103.11, POSTGRESQL_VERSION_NUMBER=16.6, COMMON_TT_UID/GID=1000, COMMON_SECURITY_NUMBER=20250121, GIT_SOURCE="git@github.com:TechTeamer"	common/settings.cfg:1-24
partner/<name>/settings.cfg	Per-partner build	PROJECT_NAME, SERVICES, CUSTOM_SERVICES, JANUS_REPOSITORY/VERSION_NUMBER/BUILD_NUMBER/VERSION_COMMIT, TT_UID/TT_GID, SECURITY_NUMBER	microsec settings.cfg:1-15
build-pack/build-pack.env	Default packaging flags	PACK_DOCUMENTATION/BUILDCODE/DOCKERIMAGES/SOURCECODE/CREDITS/AUDIT/MANUAL — all false by default	build-pack/build-pack.env:1-7
partner/<name>/build-pack.env	Per-partner packaging override (optional)	overrides build-pack defaults; e.g. partner/microsec, partner/raiffeisen, partner/vkta have one	build.sh:295-299; ls

Env vars derived at runtime from the -b <tag> arg (build.sh:363-372): VUER_TAG, VUER_TAG_NAME (tag minus trailing -N.N), VUER_VERSION (regex \d+\.\d+\.\d+), VUER_BUILD_NUMBER. Same for PORTAL_*. DOCKER_BUILDKIT=1, UID, GID exported before packaging (build.sh:529-531).

Packaging container env (packaging/docker-compose-packaging.yml:12-31): forwards host SSH_AUTH_SOCK (ssh-agent), all PACK_* (defaulting to true here, overriding the false file defaults at compose level), GIT_SOURCE, YOUTRACK_TOKEN, ZIP_PASSWORD.

PACK_* default inversion

build-pack/build-pack.env sets every PACK_* to false, but docker-compose-packaging.yml uses ${PACK_*:-true} — so if a var is unset (not just false) at compose time it defaults to true. The effective value depends on whether the bash source exported it. Read both layers before reasoning about what gets packed.

Build-package env knobs (README.md:58-104)

PACK_EXTRA_SOURCECODE="vuer_cv:2.3.0 vuer_android:master vuer_ios_sdk:master" (space-separated repo:branch), PACK_DEV_ENVIRONMENT (pulls vuer_docker@devel), and YOUTRACK_TOKEN (export YOUTRACK_TOKEN="perm:...") to attach the release ticket PDF.

---

8. Tests

No test suite.

There is no test framework, no test directory, and no test files in this repo (verified: git ls-files shows no *.test.*/*.spec.*, no test//__tests__/, and packaging/workspace/package.json has no scripts/devDependencies). Validation is done by actually running ./build.sh and inspecting log/<tag>/*.log. The closest thing to an automated check is the per-image Docker HEALTHCHECK wired to supervisor-health-check.sh (base/vuer_oss/Dockerfile:266-267) and the yarn audit report captured during the app build (base/vuer_oss/Dockerfile:130).

---

9. Dependencies on other FaceKom services / infra

Evidenced in code:

• Git source server (GIT_SOURCE, default git@github.com:TechTeamer): every build clones FaceKom app repos (vuer_oss, vuer_css, portal_css, vuer_cv, vuer_android, vuer_ios_sdk, vuer_build, vuer_docker) over SSH. (common/settings.cfg:24; base/vuer_oss/Dockerfile:112; create-build-package.js:29.) Uses host ssh-agent forwarded into the packaging container (packaging/docker-compose-packaging.yml:11).
• Harbor registry harbor.techteamer.com: target for all built image tags (every compose image: line).
• YouTrack https://youtrack.techteamer.com/api/issues: optional release-note PDF fetch, Bearer YOUTRACK_TOKEN (create-build-package.js:108-118).
• Common infra images built here (consumed by the FaceKom stack at runtime, not by the build): RabbitMQ 3.10.10, TURN (coturn) 4.6.3, ClamAV 0.103.11, PostgreSQL 16.6 (common/settings.cfg). The RabbitMQ message-broker, Redis (baked into vuer_oss), and PostgreSQL are the data-plane deps of the FaceKom services this repo packages — see architecture-overview for the runtime queue/DB topology.
• External package mirrors baked at build time: nodesource (Node RPMs), RPM Fusion / EPEL (ffmpeg, Janus deps), Oracle Instant Client repos (only for partners bb, kh via RPM; mkb-instant via tar.gz — README.md:142-154; documentation/oracle-instantclient.md).

This repo has no runtime queues/endpoints of its own.

vuer_build does not connect to RabbitMQ/HTTP/DB at run time — it only produces the images that do. The infra dependencies above are build-time (git/registry/youtrack) or are the versions of services it bakes for downstream use.

---

10. Verified gotchas

build-openshift.sh has its build stages commented out

In build-openshift.sh:453-473 the base_build and common_build invocations are commented out (# if ! base_build…). As written it runs only init + custom_build + build_pack. It is a partial/work-in-progress variant — do not assume it builds base images. (build-openshift.sh:442-473.)

build.sh -l/--list-partners is broken

It does cd partners/ (build.sh:447) but the directory is partner/ (singular). The flag will error. Use ls partner/ directly.

Hungarian-only docs + legacy "microsec/foobar" naming

README.md is Hungarian; usage examples use placeholder tags like microsec-1.9.11.12 / foobar-1.9.10.3. The packaged top-level docs referenced by the packager (packaging/readme.md, packaging/instructions.md) are created at clone time / shipped in the package, not all present in the working tree (create-build-package.js:417-419 references them; only packaging/contacts.md is tracked).

.agents/ and features/ are empty

.agents/ao/ exists but is empty (no files); features/oracle/docker-compose.yml and features/debug/docker-compose.yml are empty. Don’t rely on them.

Image tag = VERSION.BUILD-SECURITY

Three numbers drive every tag: app version (x.y.z from the git tag), a build number (last dotted segment), and a per-partner SECURITY_NUMBER (a date-like int, e.g. 20250121). -bv N appends _N to the build number to rebuild an existing tag with a new image id (build.sh:393-400).

Oracle Instant Client is layered, not in base

Only bb/kh (RPM) and mkb-instant (tar.gz, partner/mkb-instant/vuer_oss/oracle.tar.gz) layer Oracle on top of the base vuer_oss image, to keep the base small (README.md:140-154). Relevant to the OL10/UBI10 work tracked in FKITDEV-8252.

---

Unverified / gaps

• Surveyed structurally, not line-by-line: the 39 partner/<name>/ trees were mapped via full git ls-files and one representative partner (microsec: settings.cfg + docker-compose.yml) was read in full; the other 38 partners’ per-service Dockerfile/supervisor_*/temp_path.conf overrides were not read individually. Same for the non-vuer_oss base Dockerfiles (vuer_css, portal_css, janus) and all common/*/Dockerfiles — listed and their purpose inferred from compose wiring, but their RUN steps were not read line-by-line.
• Binary internals: vuer_emrtd, facekom_pdf_signer, vuer_emrtd.jar, and the bundled PDF/cert assets are opaque binaries — not decompiled (out of scope).
• build-openshift.sh vs build.sh diff: confirmed build-openshift.sh comments out base/common builds and drops the -bv/-pbv variants from usage; a full line diff was not produced.
• OTP RabbitMQ definitions: partner/otp/rabbitmq/definitions/rabbitmq-facekom.defs.json (queue/exchange definitions) exists but was not opened — it likely encodes the FaceKom RabbitMQ topology for that partner. Worth reading for queue-level detail.
• vuer_docker / dev environment: referenced (vuer_docker@devel) but lives in a separate repo, not surveyed here.

---

Sources

Files read in full or in relevant part during verification:

• /Users/levander/coding/facekom/vuer_build/README.md
• /Users/levander/coding/facekom/vuer_build/build.sh
• /Users/levander/coding/facekom/vuer_build/build-openshift.sh
• /Users/levander/coding/facekom/vuer_build/sign-partner.sh
• /Users/levander/coding/facekom/vuer_build/docker-compose-base.yml
• /Users/levander/coding/facekom/vuer_build/docker-compose-common.yml
• /Users/levander/coding/facekom/vuer_build/.buildignore, .gitignore
• /Users/levander/coding/facekom/vuer_build/packaging/workspace/create-build-package.js
• /Users/levander/coding/facekom/vuer_build/packaging/workspace/package.json
• /Users/levander/coding/facekom/vuer_build/packaging/Dockerfile
• /Users/levander/coding/facekom/vuer_build/packaging/docker-compose-packaging.yml
• /Users/levander/coding/facekom/vuer_build/common/settings.cfg
• /Users/levander/coding/facekom/vuer_build/common/rabbitmq-base/rabbitmq.sh
• /Users/levander/coding/facekom/vuer_build/build-pack/build-pack.env
• /Users/levander/coding/facekom/vuer_build/base/vuer_oss/Dockerfile
• /Users/levander/coding/facekom/vuer_build/base/vuer_oss/tools/install-nodejs-22.sh
• /Users/levander/coding/facekom/vuer_build/base/vuer_oss/tools/supervisor-health-check.sh
• /Users/levander/coding/facekom/vuer_build/base/vuer_oss/install/install-tsa.sh
• /Users/levander/coding/facekom/vuer_build/partner/microsec/settings.cfg
• /Users/levander/coding/facekom/vuer_build/partner/microsec/docker-compose.yml
• /Users/levander/coding/facekom/vuer_build/features/oracle/docker-compose.yml, features/debug/docker-compose.yml (empty)
• Directory listings: git ls-files (full repo), find over base/ common/ partner/ packaging/ features/ .agents/, base/vuer_oss/{emrtd,pdf}/bin/ (binary inventory)
• Git metadata: git -C … branch -a, git log --oneline, git for-each-ref (branch/commit dates)