lostmind84/openscale

Purpose and Entry Points

OpenScale is a self-service grocery weighing station: select a product on a touchscreen, acquire weight, price it, generate EAN-13, and print a label. It is a standalone Go binary with embedded client and administration UIs. CLI composition and operational commands live in cmd/openscale/main.go, cmd/openscale/serve.go, and cmd/openscale/service.go; serve hosts the station and HTTP UI/API.

Composition Root and Runtime Boundary

The CLI loads configuration, data directories, drivers, persistence, station workers, and web server. Configuration and platform-specific paths/services are separated from business logic in cmd/openscale/config.go, internal/platform/paths.go, and internal/platform/service.go. The production runtime is Go without cgo, cross-compiled for Windows, Linux, and Linux ARM64; Node/Svelte is build-time only.

Domain and Station Orchestration

internal/domain/ contains stable business types and rules: products, measurements, tare/safeguards, pricing, barcode generation, label templates, and configuration contracts (internal/domain/product.go, internal/domain/pricing.go, internal/domain/prepare.go). internal/station/ is the application core: it coordinates catalog snapshots, weight events, manual entry, print requests, idempotency, failure handling, and background workers (internal/station/station.go, internal/station/hub.go, internal/station/workers.go). This is the principal boundary between HTTP/hardware adapters and domain decisions.

Weigh-to-Label Flow

A client UI/API request identifies a product; station logic obtains a stable scale measurement or permitted manual weight, applies tare and safeguards, computes price, creates the EAN-13/label payload, records the result, and dispatches printing. HTTP endpoints and streaming state are in internal/web/server.go, internal/web/command.go, and internal/web/stream.go. Scale adapters are registered behind a driver interface, with serial and replay implementations in internal/scale/registry.go, internal/scale/serial/scale.go, and internal/scale/gramxfoc/gramxfoc.go. This allows real GRAM serial hardware, absent/replay modes, and isolated new driver additions.

Printing Pipeline

The printing subsystem transforms domain label data into layout/render output and delivers bytes through configured transports. Core service/driver selection is in internal/printing/service.go and internal/printing/registry.go; SATO-oriented SBPL encoding is in internal/printing/sbpl/sbpl.go; physical delivery supports TCP, files, device files, and Windows spooler via internal/printing/transport/transport.go and internal/printing/transport/winspool_windows.go. PDF and raster paths support preview/diagnostics independently of hardware.

Catalog and Local Persistence

Each station owns its SQLite-backed operational state, catalog, journals, imports, quarantine, and technical metadata. Storage and migrations are in internal/store/store.go, internal/store/migrations/0001_initial.sql, and internal/store/catalog.go. Catalog ingestion is staged: source discovery/fetch, parsing, assembly/qualification, findings/quarantine, then atomic catalog availability (internal/catalog/importer/importer.go, internal/catalog/assemble.go, internal/catalog/quarantine.go). Supported sources include Odoo CSV, local drop folders with deletion-as-acknowledgment, and WebDAV (internal/catalog/csvodoo/csvodoo.go, internal/catalog/localdrop/localdrop.go, internal/catalog/webdav/webdav.go).

Web Interfaces and Operations

Embedded static client/admin assets are served by internal/web/embed.go; source Svelte applications are in web/src/main.ts and web/src/admin/mount.ts. The client consumes catalog and station state; the admin surface controls configuration, catalog, hardware, journal, diagnostics, and updates through server handlers such as internal/web/admin.go and internal/web/update.go. Diagnostics gather machine, hardware, service, and redacted support reports (internal/diag/doctor.go, internal/diag/report.go). Update logic discovers GitHub releases, stages verified artifacts, and coordinates safe application (internal/update/github.go, internal/update/stager.go, internal/update/service.go).

Deployment and External Dependencies

There is no central backend: weighing works offline once installed. External interactions are local serial ports, network/device/spool printing, optional WebDAV catalog access, and GitHub Releases for updates. Windows installation creates a dedicated account, service, scheduled kiosk task, and hardening through deploy/windows/install.ps1 and deploy/windows/openscale-kiosk.xml; Debian uses systemd units and bootstrap scripts in deploy/linux/bootstrap.sh and deploy/linux/openscale.service. Kiosk supervision and recovery are isolated in internal/kiosk/supervisor.go and internal/kiosk/rescue.go.