Dream Consistency Hub
Internal documentation hub for Dream Consistency products, platform architecture,
infrastructure, security, secrets management, deployment standards, shared services, and operational decisions.
Dream Consistency Hub is the central internal documentation space for product architecture,
shared platform contracts, infrastructure decisions, operational procedures, deployment flows,
and technical standards.
Rule:
Important architecture, security, data ownership, deployment, and operational decisions
should be documented here before they become long-term standards.
Dream Consistency products each have their own documentation area with product context,
architecture, services, deployment model, operational commands, and change history.
Legislator
Legal practice management platform for law firms, lawyers, legal teams, and case-based operations.
Open Legislator →
Hestino
Digital menu and hospitality platform for restaurants, cafés, bars, and venue menu management.
Open Hestino →
Dream Consistency standardizes shared platform contracts and operational processes while
preserving physical database isolation between products and environments.
Platform Data Contracts
Realm, Management, Billing, and product-specific Tenant ownership boundaries,
physical topology, UUID reference rules, and cross-database transaction principles.
Open Architecture →
Realm Identity & Access
Realm-scoped customer accounts, tenant memberships, authentication authority,
ownership boundaries, invitation activation, and tenant-scoped application sessions.
Open Identity Architecture →
Architecture Decisions
Shared architecture decisions covering service communication, security standards, Realm federation, integration boundaries, and cross-product technical direction.
Open Architecture Decisions →
System Catalog Architecture
Versioned shared catalogs, embedded JSON packages, catalog libraries,
the single installer model, and separation from product catalog packages.
Open System Catalogs →
Environment Provisioning
End-to-end sequence for database schemas, Realm.Foundation, Realm bootstrap,
remaining system catalogs, runtime registration, activation, and product packages.
Open Provisioning Process →
Architecture principle:
Centralize standards, contracts, and versioned tooling—not physical product databases.
Versioned console utilities support controlled environment provisioning, shared system catalog
installation, Realm initialization, and other infrequent platform operations.
System Catalog Installer
Detailed commands and execution order for validating, planning, and installing
Realm, Management, and Billing shared system catalogs.
Open Installer Guide →
Realm Bootstrap
One-time process for verifying Realm.Foundation, creating the self Realm,
and creating the first Core operator.
Open Bootstrap Guide →
| Area |
Current Direction |
| CI/CD |
Jenkins on the Dream Consistency Hub server. Hestino DEV uses separate immutable Core image release and environment-specific deployment pipelines. |
| Docker Registry |
registry.dreamconsistency.com for private Docker images. |
| NuGet |
nuget.dreamconsistency.com using BaGetter for internal .NET package hosting. |
| Documentation |
Wiki.js used as the central internal documentation platform. |
| File Collaboration |
Nextcloud for internal file storage and collaboration where needed. |
| Container Orchestration |
Docker Swarm; Hestino DEV services consume per-service secrets through read-only host mounts. |
| Secrets Management |
HashiCorp Vault OSS with KV v2. In Hestino DEV, a host-level Vault Agent uses AppRole to render restricted, per-service JSON configuration files. |
| Runtime Configuration |
Secrets come from Vault-rendered JSON; non-sensitive environment overrides remain in Docker environment settings, with application defaults in appsettings.json. |
HashiCorp Vault is the central authority for sensitive runtime configuration.
In the Hestino DEV implementation, a host-level Vault Agent authenticates through
AppRole, reads narrowly authorized KV v2 paths, and renders a dedicated JSON file
for each service. Docker Swarm mounts that file read-only, and .NET services consume
it through their configuration providers without receiving Vault credentials.
Implementation status:
Confirmed for Hestino DEV: Hestino.Admin.Api, Hestino.Management.Api, and
DreamConsistency.AccessControl.Api. Reuse across other products and environments
is a documented pattern, not a claim that those environments have already migrated.
Vault Architecture
Central Vault infrastructure, KV v2 conventions, AppRole trust boundaries,
host-level Agent rendering, .NET configuration, security controls, and open decisions.
Reference: DC-VAULT-ARCH-001.
Open Vault Architecture →
Service Onboarding Guide
Step-by-step procedure for classifying configuration, adding KV v2 secrets,
extending policy and Agent templates, verifying host permissions, integrating .NET,
and validating deployment. Reference: DC-VAULT-RUNBOOK-001.
Open Onboarding Guide →
Jenkins & Docker Swarm Integration
Separate immutable Core image releases from environment deployments;
verify secret mounts without exposing values and perform functional release checks.
Open CI/CD Integration →
Vault Operations & Recovery
Agent monitoring, secret rotation, incident diagnostics, backup and recovery
requirements, and the separation of confirmed configuration from items to verify.
Open Operations Guide →
Secrets boundary:
Runtime secrets must not be embedded in Docker images, injected into Jenkins build or
deployment environment variables, printed in pipeline logs, or stored in Docker Swarm
environment specifications. Jenkins verifies safe runtime conditions without reading secret values.
Dream Consistency shared libraries are internal NuGet packages used across backend services,
console tools, and product control planes. They provide reusable infrastructure and shared
data contracts for Legislator, Hestino, and future Dream Consistency products.
Rule:
Shared libraries must stay product-neutral. Legislator-specific and Hestino-specific
business logic remains inside product repositories.
| Area |
Current Direction |
| Internal NuGet Feed |
https://nuget.dreamconsistency.com/v3/index.json |
| Package Hosting |
BaGetter on the Dream Consistency Hub server. |
| Release Jobs |
Manual Jenkins release jobs under DreamConsistency - Packages. |
| Versioning |
Semantic Versioning: MAJOR.MINOR.PATCH. |
| Publishing Credential |
BaGetter API key stored in Jenkins as dreamconsistency-nuget-api-key. |
| Catalog Libraries |
.NET Standard 2.1 libraries with embedded versioned JSON content:
Realm, Management, Billing, and future shared catalog contracts.
|
Standard package release flow
Merge changes to master
↓
Run manual Jenkins package release job
↓
Enter PACKAGE_VERSION
↓
Restore dependencies
↓
Check vulnerable packages
↓
Build Release
↓
Run package validation and tests
↓
Pack .nupkg
↓
Publish to nuget.dreamconsistency.com
↓
Update consuming projects
↓
Promote the versioned consuming artifact
Product and platform deployments must be versioned, repeatable, reviewable, and documented.
Application code and system catalog JSON must not be copied directly to production servers.
Build artifacts are created once and promoted consistently across environments.
Build once, deploy many:
The same immutable package, executable, or Docker image is promoted from DEV to QA,
Staging, and PROD instead of being rebuilt separately for each environment.
Deployment and secrets:
Build artifacts are environment-independent. The target host supplies secrets at runtime
through Vault Agent and read-only Docker mounts, while non-sensitive configuration
remains environment-specific. Successful replicas alone do not replace functional readiness checks.
Source repository
↓
Jenkins build and validation
↓
Versioned NuGet package / executable / Docker image
↓
Internal package or image registry
↓
DEV execution
↓
QA and Staging promotion
↓
PROD execution after approval
¶ Documentation Standards
Product, platform, infrastructure, and operational pages should follow a consistent format
so that decisions, ownership, risks, and commands are easy to find.
Security documentation rule:
Record what is confirmed, what is a recommended pattern, and what still requires verification.
Never publish Vault tokens, RoleID/SecretID values, credentials, or rendered secret contents.
Title
Purpose
Status / Current Decision
Scope and Non-Goals
Architecture / Flow
Ownership
Configuration
Operational Commands
Security and Secrets
Failure / Retry / Recovery
Risks
Change Log
| Area |
Owner |
| Company |
Dream Consistency |
| Product Ownership |
Branko / Dream Consistency |
| Platform Architecture |
Dream Consistency |
| Infrastructure |
Dream Consistency |
| Documentation |
Dream Consistency |
| Operations |
Dream Consistency |
| Shared Libraries |
Dream Consistency |
| System Catalogs |
Dream Consistency |
| Date |
Change |
Author |
| 2026-10-26 |
Added Vault and Secrets Management navigation, Hestino DEV runtime secret architecture,
Jenkins and Docker Swarm separation, and security documentation standards.
|
Dream Consistency |
| 2026-09-09 |
Added Realm Identity & Access architecture documentation covering
Realm-scoped customer accounts, tenant memberships, and authentication boundaries.
|
Branko |
| 2026-06-24 |
Initial Dream Consistency home page created. |
Branko |
| 2026-07-04 |
Added internal shared libraries and NuGet package release information. |
Branko |
| 2026-08-01 |
Added platform data contracts, system catalog architecture,
and environment provisioning documentation.
|
Branko |
| 2026-08-03 |
Added Platform Tools navigation and detailed operational documentation
for the System Catalog Installer and Realm Bootstrap utilities.
|
Branko |