STACK MODEL

STACK
│
├── USE
│   ├── STACKSET-A@1
│   ├── STACKSET-B@1
│   └── ...
│
└── OVERRIDE
    ├── ADD       → local component not present in referenced sets
    ├── REMOVE    → inherited component not used in this context
    ├── REPLACE   → explicit substitution of one component
    └── NOTE      → contextual qualification without changing membership


EFFECTIVE STACK
    = USE(STACKSET...)
    + ADD
    - REMOVE
    + REPLACE
    + NOTE

STACKSETs exist to normalize repeated technical context, not to create a taxonomy entry for every technology that has ever appeared in the work. A new STACKSET should represent either a reusable technical environment that occurs in multiple independent contexts or a stable type of engineering activity with enough internal structure to be meaningful as a unit.

STACKSET CREATION RULE

CREATE STACKSET when
│
├── the same coherent stack recurs across multiple contexts
│
└── OR
    the set represents a stable engineering / production discipline

KEEP AS OVERRIDE when
│
├── the technology is specific to one project or artifact
├── the component merely modifies a broader reusable stack
└── there is not yet enough stable context to define the bundle


COMPOSITION OVER INHERITANCE

preferred:

Node
├── USE → STACKSET-A@1
├── USE → STACKSET-B@1
└── OVERRIDE
    └── local differences

avoid:

STACK-A
└── STACK-B
    └── STACK-C
        └── PROJECT-SPECIFIC-STACK

Overrides are intentionally explicit. They prevent a reusable STACKSET from being duplicated merely because one project adds, removes, or substitutes a small number of components.

OVERRIDE RULES

ADD
│
└── introduces a component that belongs only to this context

REMOVE
│
└── explicitly excludes a component inherited through USE

REPLACE
│
└── records a real substitution rather than pretending that
    both inherited and replacement technologies were used

NOTE
│
└── qualifies scope, responsibility, maturity, or usage without
    changing the effective membership of the stack


EXAMPLE

InterDeadCore
│
└── STACK
    ├── USE → TYPESCRIPT-APPLICATION@1
    ├── USE → NODE-TOOLING@1
    ├── USE → HEXAGONAL-SYSTEMS@1
    │
    └── OVERRIDE
        ├── ADD  → @interdead/identity-core
        ├── ADD  → @interdead/efbd-scale
        ├── ADD  → @interdead/framework
        └── NOTE → web-side shared domain packages;
                   not the C++ Game Core

STACKSET versions are historically stable. Once a version is referenced by a historical role, project, or artifact, a material change creates a new version rather than silently rewriting the old context.

VERSIONING RULE

STACKSET@1
│
└── frozen once historical contexts depend on it

material change
│
└── create STACKSET@2

local difference
│
└── keep STACKSET@1 + OVERRIDE

SUPPORT-WEB@1
│
├── technical support
├── web-platform diagnostics
├── issue reproduction
├── Jira-based task flow
├── code-level troubleshooting
├── user communication
└── technical documentation


QA-WEB@1
│
├── functional testing
├── bug reproduction
├── system-behavior analysis
├── integration testing
├── verification
└── development-team collaboration


EDITORIAL-PM@1
│
├── recruitment
├── onboarding
├── task distribution
├── editorial review
├── team coordination
├── quality control
├── multilingual workflow
└── delivery control


WEB-FULLSTACK@1
│
├── HTML / CSS
├── JavaScript ES6+
├── PHP
├── SQL
├── REST APIs / Webhooks
└── Git


NODE-TOOLING@1
│
├── Node.js
├── JavaScript ES6+
├── ESM / CommonJS modules
├── CLI tooling
├── filesystem automation
├── build / transformation scripts
└── repository automation


TYPESCRIPT-APPLICATION@1
│
├── TypeScript
├── static typing
├── typed contracts
├── modular packages
├── type checking
└── TypeScript → JavaScript build flow


UNIX-OPS@1
│
├── Linux
├── BSD / Unix-like systems
├── Bash
├── SSH
├── deployment / administration
├── TCP/IP configuration
└── firewall / network configuration


WINDOWS-AUTOMATION@1
│
├── PowerShell
├── Windows shell automation
├── filesystem / repository tooling
├── Git workflow automation
└── local development environment scripting


WORDPRESS-WEB@1
│
├── WordPress
├── WooCommerce
├── custom plugin / module development
├── theme / frontend integration
└── production maintenance


WEB-DELIVERY@1
│
├── build processes
├── deployment
├── infrastructure integration
├── CI / CD
└── production verification


CLOUDFLARE-WEB@1
│
├── Cloudflare Pages
├── Cloudflare Workers
├── D1
├── KV
└── edge deployment


CONTAINERS-VIRTUALIZATION@1
│
├── Docker
├── VirtualBox
└── Hyper-V


HEXAGONAL-SYSTEMS@1
│
├── Hexagonal Architecture
├── Ports & Adapters
├── dependency inversion
├── domain / infrastructure separation
├── replaceable adapters
└── explicit system boundaries


GAME-SYSTEMS@1
│
├── gameplay systems
├── narrative systems
├── technical design
├── prototyping
├── quest / progression logic
├── dependency / state modeling
└── project-system architecture


PROCESS-OPTIMIZATION@1
│
├── task decomposition
├── backlog structuring
├── phase planning
├── risk identification
├── acceptance criteria
└── workflow stabilization


RESEARCH-PUBLISHING@1
│
├── research
├── technical writing
├── documentation
├── reproducible publishing
└── research-to-engineering transfer


ENGINEERING-GOVERNANCE@1
│
├── architectural constraints
├── canonical-source discipline
├── documented development rules
├── review / verification
├── repository licensing policy
└── controlled change procedures


LLM-ENGINEERING@1
│
├── bounded task decomposition
├── explicit prompt contracts
├── human-authored planning
├── review / tests / smoke checks
└── traceable acceptance

C++ is intentionally not represented by a reusable STACKSET at this stage. Its absence does not mean that C++ is outside the current work. InterDead is moving toward an independent C++ Game Core, but that runtime is still being formalized as a distinct engineering contour.

The stack model records verified technical contexts rather than broad technology familiarity or intended future use. A useful C++ STACKSET should therefore describe the actual runtime environment around the language — build system, tests, dependency model, WebAssembly boundary, Unreal adapter, runtime contracts, and related tooling — rather than contain only the label “C++”.

C++ STATUS

C++
│
├── current status
│   └── active / emerging game-runtime technology
│
├── known architectural position
│   ├── Scenario
│   │   └── separate linguistic source
│   │
│   └── C++ Game Core
│       ├── Unreal        → projection / adapter
│       └── Web / WASM    → projection / adapter
│
└── STACKSET status
    └── NOT YET DEFINED
        │
        ├── build system not fixed here
        ├── test stack not fixed here
        ├── dependency model not fixed here
        ├── WASM boundary still belongs to runtime design
        └── Unreal integration should be described from
            the implemented adapter rather than assumed


FUTURE

when the implementation contour is stable:

CXX-GAME-RUNTIME@1
│
├── C++
├── build system
├── testing
├── dependency / package model
├── WebAssembly boundary
├── Unreal adapter boundary
└── runtime-specific tooling

This follows the same rule used elsewhere: a technology becomes part of a STACKSET when there is enough concrete, reusable context to define the set honestly. Until then it belongs to the project description or to a local OVERRIDE if a specific artifact already uses it.

Since August 2026, I work through IRON CREED in a role that combines hands-on full-stack engineering with systems architecture, infrastructure, automation, delivery, technical documentation, verification, code review, and engineering mentorship.

The role is broader in engineering scope than my parallel studio role at Zhovten Games. It includes not only implementation, but also technical direction, working methods, architectural decisions, review standards, and the transfer of reusable engineering practices between projects.

ROLE :: SENIOR FULL-STACK WEB ENGINEER / CO-FOUNDER / ENGINEERING MENTOR
│
├── PERIOD
│   └── August 2026 → Present
│
├── CONTEXT
│   └── IRON CREED
│
├── DESCRIPTION
│   ├── end-to-end web engineering
│   ├── systems architecture
│   ├── infrastructure and automation
│   ├── deployment and delivery
│   ├── security-oriented hardening
│   ├── technical documentation
│   ├── internal tooling
│   └── verification
│
├── RESPONSIBILITY
│   ├── hands-on engineering
│   ├── technical direction
│   ├── architectural decisions
│   ├── code review
│   ├── review / verification standards
│   ├── engineering mentorship
│   └── reusable-method transfer across projects
│
├── STACK
│   ├── USE → WEB-FULLSTACK@1
│   ├── USE → UNIX-OPS@1
│   ├── USE → WEB-DELIVERY@1
│   ├── USE → ENGINEERING-GOVERNANCE@1
│   ├── USE → LLM-ENGINEERING@1
│   │
│   └── OVERRIDE
│       ├── NOTE → architecture, review, mentoring and verification
│       │          are role-level responsibilities
│       ├── NOTE → platform-, runtime- and client-specific technologies
│       │          resolve on the corresponding child system,
│       │          project or artifact
│       └── NOTE → this role stack does not absorb the emerging
│                  InterDead C++ Game Core
│
└── SYSTEMS / PROJECTS
    └── IRON CREED
        applied IT and engineering practice

IRON CREED is the applied IT and engineering practice of Zhovten Games and the personified engineering process behind its IT practice.

It connects development, infrastructure, automation, security, research, technical publishing and verification into systems that can be understood, verified and changed deliberately. Implementation, documentation, research and verification are treated as connected parts of the same engineering process rather than as unrelated stages.

IRON CREED
│
├── TYPE
│   └── applied IT / engineering practice
│
├── PARENT
│   └── Zhovten Games
│
├── LEGAL / CONTRACTUAL FRAME
│   └── FOP Oksana Dubinetska
│
├── INSTITUTIONAL LINEAGE
│   └── FOP Oksana Dubinetska → Zhovten Games → IRON CREED
│
├── IDENTITY
│   ├── engineering practice
│   └── personified engineering process
│
├── SCOPE
│   ├── Systems Architecture
│   ├── Full-Stack Web Development
│   ├── DevOps / Infrastructure Engineering
│   ├── Cloudflare / Cloud Infrastructure
│   ├── Automation / CI/CD
│   ├── Security / Configuration Control
│   ├── Technical Documentation
│   ├── Technical Publishing
│   ├── Knowledge Engineering
│   ├── Corporate Knowledge for LLMs
│   ├── Machine-Readable Websites
│   └── Independent Verification
│
├── RESPONSIBILITY :: SAM
│   ├── Senior Full-Stack Web Engineer
│   ├── Co-Founder
│   ├── Engineering Mentor
│   ├── full-stack engineering
│   ├── systems architecture
│   ├── infrastructure
│   ├── automation
│   └── project verification
│
├── STACK
│   ├── USE → WEB-FULLSTACK@1
│   ├── USE → UNIX-OPS@1
│   ├── USE → WEB-DELIVERY@1
│   ├── USE → CLOUDFLARE-WEB@1
│   ├── USE → ENGINEERING-GOVERNANCE@1
│   ├── USE → RESEARCH-PUBLISHING@1
│   ├── USE → LLM-ENGINEERING@1
│   │
│   └── OVERRIDE
│       ├── NOTE → security and independent verification are
│       │          practice-wide concerns; concrete controls
│       │          resolve at project level
│       ├── NOTE → CMS, application runtime, containerization,
│       │          Node.js, TypeScript and other implementation
│       │          stacks are attached only where actually used
│       └── NOTE → game-runtime C++ is intentionally excluded:
│                  it belongs to InterDead under Zhovten Games
│
├── WORKING MODEL
│   ├── Governance
│   │   └── Code Constitution
│   │       project rules / architectural constraints /
│   │       authority / change / verification
│   │
│   ├── Licensing
│   │   └── Repository Licensing Policy
│   │       ownership / authorship / reuse /
│   │       distribution / licensing boundaries
│   │
│   └── LLM-assisted engineering
│       └── Prompt-Literate Workflow
│           bounded generation / review /
│           validation / traceable acceptance
│
├── SYSTEMS / METHODS
│   ├── WARDEN
│   │   independent verification boundary
│   │   ├── route availability
│   │   ├── configuration integrity
│   │   ├── data structure
│   │   ├── security rules
│   │   ├── build correctness
│   │   ├── regressions
│   │   └── project-specific invariants
│   │
│   └── Material Cycle
│       └── Idea or IT case
│           → Research and record
│           → IRON CREED adaptation
│           → Verification and the next change
│
└── REFERENCES
    ├── GitHub organization
    ├── Canonical GitHub profile
    ├── About / public entry point
    ├── LinkedIn
    └── Sam / GitHub

Since October 2025, I work within Zhovten Games on gameplay systems, technical design and the implementation layer that connects narrative structure with executable game logic.

The role focuses on systems architecture and technical implementation: quest and progression logic, state and dependency modelling, prototypes, runtime integration, development constraints, and the translation of design concepts into structures that can be implemented and maintained.

ROLE :: GAME SYSTEMS DESIGNER / CO-FOUNDER
│
├── PERIOD
│   └── October 2025 → Present
│
├── CONTEXT
│   └── Zhovten Games
│
├── DESCRIPTION
│   ├── gameplay systems
│   ├── technical design
│   ├── narrative-system integration
│   ├── quest / progression logic
│   ├── state / dependency modelling
│   ├── prototyping
│   └── technical implementation
│
├── RESPONSIBILITY
│   ├── gameplay systems architecture
│   ├── implementation-ready technical design
│   ├── system-level integration
│   ├── project architecture
│   ├── prototypes / tooling
│   └── engineering constraints for game systems
│
├── STACK
│   ├── USE → GAME-SYSTEMS@1
│   ├── USE → ENGINEERING-GOVERNANCE@1
│   │
│   └── OVERRIDE
│       ├── NOTE → concrete languages and runtimes resolve
│       │          on individual projects and artifacts
│       ├── NOTE → web technologies used by InterDead are not
│       │          promoted to the role-level stack
│       └── NOTE → C++ remains an emerging project runtime
│                  until CXX-GAME-RUNTIME@1 can be defined
│
└── SYSTEMS / PROJECTS
    └── Zhovten Games
        └── InterDead

Zhovten Games is an independent game development studio combining narrative design, production and systems engineering. The studio connects game mechanics, narrative structure and monetisation into coherent, implementable player experiences.

My technical responsibility inside the studio centres on gameplay systems architecture, technical implementation and system-level integration. Concrete runtimes and implementation technologies belong to individual projects rather than being projected onto the studio as a whole.

ZHOVTEN GAMES
│
├── TYPE
│   └── studio / production system
│       independent game development studio
│
├── LEGAL / CONTRACTUAL FRAME
│   └── FOP Oksana Dubinetska
│
├── INSTITUTIONAL CONTINUITY
│   └── FOP Oksana Dubinetska → Zhovten Games
│
├── SCOPE
│   ├── narrative design
│   ├── game systems design
│   ├── production
│   ├── technical implementation
│   ├── game economy / monetisation design
│   ├── prototyping
│   └── research / publication
│
├── RESPONSIBILITY :: SAM
│   ├── Co-Founder
│   ├── Game Systems Designer
│   ├── gameplay systems architecture
│   ├── technical implementation
│   └── system-level integration
│
├── STACK
│   ├── USE → GAME-SYSTEMS@1
│   ├── USE → RESEARCH-PUBLISHING@1
│   ├── USE → ENGINEERING-GOVERNANCE@1
│   │
│   └── OVERRIDE
│       ├── NOTE → studio-level stack describes recurring methods
│       │          rather than every implementation technology
│       └── NOTE → engine, runtime, web and tooling stacks resolve
│                  inside individual studio projects
│
├── PROJECTS
│   └── InterDead
│       narrative horror system / game in development
│
└── REFERENCES
    ├── GitHub organization
    ├── Studio website
    ├── InterDead project record
    ├── itch.io
    └── LinkedIn

InterDead is a co-authored Zhovten Games narrative horror system built across game systems, public interfaces, reusable domain packages, prototypes, canon infrastructure, and supporting research.

The current public web/prototype contour and the emerging game runtime are separate architectural contours. InterDeadCore is not the C++ Game Core: it is the existing TypeScript monorepo for shared web-side domain packages. The future game runtime is centred on an independent C++ Game Core, with Unreal and Web / WASM treated as parallel projections through adapters.

INTERDEAD
│
├── STATUS
│   └── in development
│
├── ORIGIN
│   └── Zhovten Games
│
├── OWNERSHIP
│   └── co-authored Zhovten Games studio project
│
├── RESPONSIBILITY :: SAM
│   ├── game systems
│   ├── technical architecture
│   ├── implementation
│   ├── web / prototype systems
│   └── system-level integration
│
├── STACK
│   ├── USE → GAME-SYSTEMS@1
│   ├── USE → RESEARCH-PUBLISHING@1
│   ├── USE → ENGINEERING-GOVERNANCE@1
│   │
│   └── OVERRIDE
│       ├── NOTE → the project stack is intentionally broad
│       ├── NOTE → web, prototype and domain-package technologies
│       │          resolve on their respective repositories
│       └── NOTE → C++ runtime technologies remain outside USE
│                  until CXX-GAME-RUNTIME@1 is defined
│
├── 02. CANON / SYSTEM DEFINITION
│   │
│   ├── InterDead Wiki
│   │   Public canon surface.
│   │   Defines entities, terminology, relationships,
│   │   protocols and world-facing canonical structure.
│   │
│   ├── InterDead Reference Library
│   │   Public development-facing reference layer.
│   │   Curated technical notes, standards, primers,
│   │   research materials and safe public references.
│   │
│   └── STACK
│       ├── USE → RESEARCH-PUBLISHING@1
│       ├── USE → ENGINEERING-GOVERNANCE@1
│       └── OVERRIDE
│           ├── ADD  → public wiki
│           ├── ADD  → reference-library structure
│           └── NOTE → public canon and development references
│                      serve different surfaces but remain aligned
│
├── 03. SOURCE CODE / RUNTIME SURFACES
│   │
│   ├── CURRENT WEB / PROTOTYPE CONTOUR
│   │   │
│   │   ├── InterDeadIT
│   │   │   Public website and entry point into the InterDead system.
│   │   │
│   │   │   Responsibilities
│   │   │   ├── landing / public-facing surface
│   │   │   ├── localized content
│   │   │   ├── JavaScript UI controllers / services
│   │   │   ├── mini-game shortcodes
│   │   │   └── host integration for shared domain packages
│   │   │
│   │   │   STACK
│   │   │   ├── USE → CLOUDFLARE-WEB@1
│   │   │   ├── USE → WEB-DELIVERY@1
│   │   │   │
│   │   │   └── OVERRIDE
│   │   │       ├── REMOVE → KV
│   │   │       ├── ADD    → Hugo
│   │   │       ├── ADD    → JavaScript UI layer
│   │   │       ├── ADD    → Twemoji
│   │   │       ├── ADD    → Prettier
│   │   │       └── NOTE   → identity / EFBD domain logic is
│   │   │                    delegated to shared packages
│   │   │
│   │   ├── InterDeadProto / NOIR
│   │   │   Prototype-first foundation and narrative-driven
│   │   │   interface prototype.
│   │   │
│   │   │   Runtime
│   │   │   ├── ES6 modules
│   │   │   ├── deterministic narrative / UI flows
│   │   │   ├── host integration hooks
│   │   │   └── iframe / standalone launch modes
│   │   │
│   │   │   Repository topology
│   │   │   ├── proto-dev  → canonical source implementation
│   │   │   └── proto      → production build / deployment branch
│   │   │
│   │   │   STACK
│   │   │   ├── USE → NODE-TOOLING@1
│   │   │   ├── USE → WEB-DELIVERY@1
│   │   │   │
│   │   │   └── OVERRIDE
│   │   │       ├── ADD  → browser-native ES6 modules
│   │   │       ├── ADD  → Local Build Lab
│   │   │       ├── ADD  → Cloudflare deployment target
│   │   │       ├── ADD  → itch.io deployment target
│   │   │       └── NOTE → deployment compatibility rewrites
│   │   │                  are pipeline-driven and must not
│   │   │                  mutate canonical source semantics
│   │   │
│   │   └── InterDeadCore
│   │       Shared TypeScript domain-package monorepo.
│   │       Presentation-independent identity, EFBD and
│   │       framework logic consumed by downstream hosts.
│   │
│   │       Packages
│   │       ├── @interdead/identity-core
│   │       │   identity / authentication kernel
│   │       │   with pluggable storage
│   │       │
│   │       ├── @interdead/efbd-scale
│   │       │   EFBD scoring domain for adaptive horror design
│   │       │
│   │       └── @interdead/framework
│   │           modular UI framework runtime for host integrations
│   │
│   │       STACK
│   │       ├── USE → TYPESCRIPT-APPLICATION@1
│   │       ├── USE → NODE-TOOLING@1
│   │       ├── USE → HEXAGONAL-SYSTEMS@1
│   │       ├── USE → CLOUDFLARE-WEB@1
│   │       │
│   │       └── OVERRIDE
│   │           ├── REMOVE → Cloudflare Pages
│   │           ├── ADD    → independently versioned packages
│   │           ├── ADD    → object-oriented domain aggregates
│   │           ├── ADD    → shared data contracts
│   │           └── NOTE   → Workers / D1 / KV are
│   │                        host-provided bindings
│   │
│   ├── EMERGING GAME RUNTIME CONTOUR
│   │   │
│   │   ├── Scenario
│   │   │   separate linguistic / narrative source
│   │   │
│   │   └── C++ Game Core
│   │       headless game-system runtime
│   │
│   │       Architecture
│   │       ├── scenario / game data enters the core
│   │       ├── core owns executable game logic
│   │       ├── adapters remain thin
│   │       │
│   │       ├── Unreal
│   │       │   └── native game projection / adapter
│   │       │
│   │       └── Web / WASM
│   │           └── browser projection / adapter
│   │
│   │       STACK
│   │       └── NOT YET NORMALIZED
│   │           ├── C++ is established as the core language
│   │           ├── CXX-GAME-RUNTIME@1 does not yet exist
│   │           ├── build / test stack awaits implementation evidence
│   │           └── Unreal / WASM details remain project-local
│   │
│   └── RUNTIME STACK SUMMARY
│       ├── Web / public surface
│       │   └── InterDeadIT
│       ├── Prototype
│       │   └── InterDeadProto / NOIR
│       ├── Shared web-side domain packages
│       │   └── InterDeadCore
│       └── Game runtime
│           └── emerging C++ Game Core
│
└── 04. RESEARCH / ENGINEERING SUPPORT
    │
    ├── Reference Library / research
    │   Research informing game systems, canon design,
    │   communication models and implementation decisions.
    │
    ├── PsyFramework
    │   Research / tooling environment for experimental
    │   psyche mechanics and fear-model prototypes.
    │
    ├── Literate / Prompt-Literate methodology
    │   Engineering-methodology track for reproducible,
    │   reviewable development workflows.
    │
    └── STACK
        ├── USE → RESEARCH-PUBLISHING@1
        ├── USE → ENGINEERING-GOVERNANCE@1
        └── OVERRIDE
            └── NOTE → concrete research tools and experimental
                       implementations remain attached to the
                       corresponding artifact or repository

From September 2021 to August 2026, I worked independently across client-side and server-side web development, integrations, deployment, existing infrastructure, and ongoing production support.

This period became the bridge between employment-based engineering and the later IRON CREED practice. The work remained client- and project-oriented, but expanded from implementation into consulting, code review, onboarding, technical decisions, delivery, and practical knowledge transfer.

ROLE :: MIDDLE FULL-STACK WEB ENGINEER
│
├── PERIOD
│   └── September 2021 → August 2026
│
├── CONTEXT
│   └── Self-Employed / Freelance
│
├── DESCRIPTION
│   ├── client-side development
│   ├── server-side development
│   ├── web application maintenance
│   ├── third-party integrations
│   ├── API / webhook integration
│   ├── existing-infrastructure support
│   ├── build / deployment work
│   └── production troubleshooting
│
├── RESPONSIBILITY
│   ├── end-to-end implementation
│   ├── technical consulting
│   ├── code review
│   ├── onboarding
│   ├── practical knowledge sharing
│   └── project-specific technical decisions
│
├── STACK
│   ├── USE → WEB-FULLSTACK@1
│   ├── USE → WORDPRESS-WEB@1
│   ├── USE → WEB-DELIVERY@1
│   │
│   └── OVERRIDE
│       ├── ADD  → Laravel
│       ├── NOTE → exact framework and infrastructure mix
│       │          varied by client and project
│       ├── NOTE → APIs and webhooks are recurring integration
│       │          mechanisms rather than a single project stack
│       └── NOTE → later IRON CREED practices should not be
│                  projected backward onto this period
│
└── CONTEXT / INTERSECTIONS
    ├── Freelance
    ├── LEBENSBUND
    └── FOP Oksana Dubinetska
        legal / contractual frame that continues into later systems

Freelance represents the independent client-work context of the 2021–2026 period rather than a company or separate organization.

Projects differed in platform and scope, but the recurring pattern was end-to-end web engineering: understanding an existing system, implementing or repairing the required layer, integrating external services, and bringing the result through deployment or production support.

FREELANCE
│
├── TYPE
│   └── independent client work / professional context
│
├── PERIOD
│   └── September 2021 → August 2026
│
├── STATUS
│   └── historical / superseded by IRON CREED as the
│       primary branded engineering practice
│
├── SCOPE
│   ├── web applications
│   ├── websites / CMS systems
│   ├── backend implementation
│   ├── frontend implementation
│   ├── third-party integrations
│   ├── API / webhook work
│   ├── deployment
│   ├── production support
│   └── technical consulting
│
├── STACK
│   ├── USE → WEB-FULLSTACK@1
│   ├── USE → WORDPRESS-WEB@1
│   ├── USE → WEB-DELIVERY@1
│   │
│   └── OVERRIDE
│       ├── ADD  → Laravel
│       ├── NOTE → WordPress and Laravel represent recurring
│       │          environments, not mandatory components
│       │          of every engagement
│       ├── NOTE → operating-system and cloud technologies
│       │          remain project-local unless independently
│       │          evidenced for a specific engagement
│       └── NOTE → client-specific technologies belong to
│                  their project or artifact nodes
│
└── TRANSITION
    └── independent freelance practice
        → shared methods / standards / public identity
        → IRON CREED

FOP Oksana Dubinetska is the legal and contractual frame that enters the BERUF map on the 2021 independent-work line and continues through the later co-founded systems. Its placement records where this institutional branch intersects the chronology; it does not imply that the frame ends with the 2021–2026 role.

The institutional sequence is deliberately asymmetric: FOP Oksana Dubinetska provides the legal / contractual frame; Zhovten Games develops as the studio / production system; IRON CREED develops inside Zhovten Games as its applied IT / engineering practice. The connection from LEBENSBUND to FOP records a shared-life and professional intersection, not ownership or derivation of the business from LEBENSBUND.

FOP OKSANA DUBINETSKA
│
├── TYPE
│   └── legal / contractual frame for independent professional activity
│
├── OWNERSHIP
│   └── Oksana Dubinetska
│
├── MAP ENTRY
│   └── 2021 · Middle Full-Stack Web Engineer
│       institutional intersection with the independent-work line
│
├── RELATION TO BERUF
│   ├── enters the chronology at the 2021 professional line
│   ├── persists across later roles and systems
│   └── intersects the shared-life axis through
│       LEBENSBUND without being owned by it
│
├── INSTITUTIONAL DERIVATION
│   └── FOP Oksana Dubinetska
│       └── Zhovten Games
│           studio / production system
│           └── IRON CREED
│               applied IT / engineering practice
│
└── REFERENCE
    └── GitHub organization

From November 2019 to August 2021, I worked with ZIPY HOLDINGS LTD. on a WordPress-based subscription-commerce platform for premium spirits.

The work combined backend and frontend development with production responsibility: custom WooCommerce functionality, subscription logic, implementation from Figma, performance optimization, security hardening, SEO, localization, and ongoing support.

ROLE :: JUNIOR FULL-STACK WEB ENGINEER — WORDPRESS
│
├── PERIOD
│   └── November 2019 → August 2021
│
├── CONTEXT
│   └── ZIPY HOLDINGS LTD.
│
├── DESCRIPTION
│   ├── WordPress development
│   ├── WooCommerce development
│   ├── custom subscription logic
│   ├── frontend implementation
│   ├── production maintenance
│   ├── performance optimization
│   ├── security hardening
│   ├── SEO
│   └── localization
│
├── RESPONSIBILITY
│   ├── custom WooCommerce implementation
│   ├── subscription-module development
│   ├── Figma → frontend implementation
│   ├── production support
│   └── performance / security improvements
│
├── STACK
│   ├── USE → WEB-FULLSTACK@1
│   ├── USE → WORDPRESS-WEB@1
│   │
│   └── OVERRIDE
│       ├── ADD  → Figma → frontend implementation
│       ├── ADD  → custom subscription module
│       ├── NOTE → WordPress / WooCommerce were the
│       │          principal production environment
│       └── NOTE → optimization, security, SEO and localization
│                  were production responsibilities rather than
│                  separate global STACKSETs
│
└── ORGANIZATION
    └── ZIPY HOLDINGS LTD.

ZIPY HOLDINGS LTD. is the historical organization attached to the 2019–2021 WordPress engineering period.

My documented work there centres on a subscription-commerce product for premium spirits, with Glenbotal preserved as the selected public example of that work.

ZIPY HOLDINGS LTD.
│
├── TYPE
│   └── historical organization / contract context
│
├── PERIOD
│   └── November 2019 → August 2021
│
├── STATUS
│   └── completed / historical
│
├── RESPONSIBILITY :: SAM
│   ├── Junior Full-Stack Web Engineer — WordPress
│   ├── WordPress / WooCommerce development
│   ├── subscription-commerce implementation
│   ├── frontend implementation
│   ├── optimization / hardening
│   └── production support
│
├── STACK
│   ├── USE → WEB-FULLSTACK@1
│   ├── USE → WORDPRESS-WEB@1
│   │
│   └── OVERRIDE
│       ├── ADD  → custom WooCommerce subscription logic
│       ├── ADD  → Figma-driven frontend implementation
│       ├── NOTE → platform-specific optimization,
│       │          security, SEO and localization
│       └── NOTE → technologies not independently documented
│                  for this period are intentionally omitted
│
└── SELECTED WORK
    └── Glenbotal
        premium-spirits subscription-commerce platform

From October 2017 to September 2018, I built and operated a copywriting team across two language tracks, covering recruitment, onboarding, task distribution, editorial review, coordination, quality control, and delivery stability.

The role was primarily organizational and editorial rather than technical. I managed a team of more than twenty writers, editors, and contributors and was responsible for keeping the production process coherent, consistent, and predictable.

ROLE :: PROJECT MANAGER / COPYWRITING TEAM
│
├── PERIOD
│   └── October 2017 → September 2018
│
├── CONTEXT
│   └── Scuba Space
│
├── DESCRIPTION
│   ├── team formation
│   ├── recruitment
│   ├── onboarding
│   ├── task distribution
│   ├── editorial review
│   ├── multilingual production
│   ├── quality control
│   └── delivery coordination
│
├── RESPONSIBILITY
│   ├── team of 20+ writers / editors / contributors
│   ├── process stability
│   ├── content consistency
│   ├── production coordination
│   └── timely delivery
│
├── STACK
│   ├── USE → EDITORIAL-PM@1
│   │
│   └── OVERRIDE
│       ├── NOTE → this is a process / editorial stack,
│       │          not a software-development stack
│       └── NOTE → specific software tooling is intentionally
│                  omitted until historically verified
│
└── ORGANIZATION
    └── Scuba Space

Scuba Space is the historical contract context attached to the 2017–2018 editorial project-management period.

SCUBA SPACE
│
├── TYPE
│   └── historical organization / contract context
│
├── PERIOD
│   └── October 2017 → September 2018
│
├── STATUS
│   └── completed / historical
│
├── RESPONSIBILITY :: SAM
│   ├── Project Manager, Copywriting Team
│   ├── team formation
│   ├── editorial workflow
│   ├── coordination
│   ├── quality control
│   └── delivery stability
│
└── STACK
    ├── USE → EDITORIAL-PM@1
    │
    └── OVERRIDE
        └── NOTE → organization-level tooling remains omitted
                   unless supported by a historical source

From October 2015 to September 2017, I moved from technical support into software testing within the same broader product environment, with the uKit product becoming the primary testing context.

The work covered functional testing, bug reproduction, system-behavior analysis, integration testing, verification, and direct collaboration with development. This period shifted my perspective from user-facing support toward product logic, engineering constraints, and systematic verification.

ROLE :: SOFTWARE TEST ENGINEER
│
├── PERIOD
│   └── October 2015 → September 2017
│
├── CONTEXT
│   └── uKit
│
├── DESCRIPTION
│   ├── functional testing
│   ├── bug reproduction
│   ├── system-behavior analysis
│   ├── integration testing
│   ├── verification
│   └── development-team collaboration
│
├── RESPONSIBILITY
│   ├── product-behavior verification
│   ├── reproducible defect reporting
│   ├── integration-level checks
│   └── engineering-feedback loop
│
├── STACK
│   ├── USE → QA-WEB@1
│   │
│   └── OVERRIDE
│       ├── NOTE → specific testing tools are intentionally
│       │          omitted until independently verified
│       └── NOTE → this role marks the transition from
│                  support-oriented diagnosis to systematic QA
│
└── PRODUCT CONTEXT
    └── uKit

uKit is the product context attached to the 2015–2017 QA period and continues the broader product environment in which the earlier uCoz support work took place.

uKIT
│
├── TYPE
│   └── historical product / employment context
│
├── PERIOD
│   └── October 2015 → September 2017
│
├── STATUS
│   └── historical
│
├── RELATION
│   └── product-environment continuity with uCoz
│
├── RESPONSIBILITY :: SAM
│   ├── Software Test Engineer
│   ├── functional / integration testing
│   ├── bug reproduction
│   ├── system-behavior analysis
│   └── verification
│
└── STACK
    ├── USE → QA-WEB@1
    │
    └── OVERRIDE
        └── NOTE → tooling details remain intentionally narrow;
                   only verified work context is represented

Marriage appears on the BERUF carrier because this map models the allocation of finite lifetime rather than employment alone. It marks the origin point of LEBENSBUND, a continuing shared-life axis that persists across several professional periods.

This node is not an employer, job title, or project. Its purpose is to show that long-lived personal structures can shape where time is invested and can later intersect with professional systems without being reduced to them.

MILESTONE :: MARRIAGE
│
├── PERIOD
│   └── 2015 → Present
│
├── TYPE
│   └── personal milestone / shared-life origin
│
├── CONTEXT
│   └── LEBENSBUND
│
├── BERUF SEMANTICS
│   ├── consumes and organizes the same finite time resource
│   │   represented by the carrier
│   ├── persists across multiple professional periods
│   └── may intersect with later shared professional systems
│       without becoming an employment node
│
└── STACK
    └── NOT APPLICABLE
        technical STACK / STACKSET rules apply to engineering,
        production, project, and artifact contexts

LEBENSBUND represents the enduring shared-life and future-building axis that begins with marriage and continues through family relocation, parenthood with Tykhon, and the later professional trajectory.

It is shown above the carrier because it outlives individual roles and periods. The later FOP Oksana Dubinetska frame provides a concrete business and contractual intersection on that line, while LEBENSBUND itself remains distinct from any single professional or technical structure. The link marks intersection rather than ownership: the institutional line continues through FOP Oksana Dubinetska → Zhovten Games → IRON CREED.

LEBENSBUND
│
├── TYPE
│   └── enduring shared-life / future-building context
│
├── ORIGIN
│   └── 2015 · Marriage
│
├── STATUS
│   └── active / continuing
│
├── RELATION TO BERUF
│   ├── long-lived structure above the chronological carrier
│   ├── continues through family relocation and parenthood with Tykhon
│   ├── intersects the later business contour through
│   │   FOP Oksana Dubinetska
│   └── continues alongside later co-founded systems
│
├── FAMILY / SHARED-LIFE COMMITMENTS
│   ├── Family Relocation to Spouse's Home Country
│   └── 2017 · Parenthood · Tykhon
│
├── PROFESSIONAL INTERSECTIONS
│   ├── FOP Oksana Dubinetska
│   ├── Zhovten Games
│   └── IRON CREED
│
└── STACK
    └── NOT APPLICABLE
        this node describes a life structure rather than
        a technical or production system

From December 2011 to October 2015, I worked in technical support at uCoz, resolving both standard and non-standard user issues and handling tasks that sometimes required code-level intervention.

The work also included Jira-based task handling, communication quality, internal alignment, technically oriented materials, and selected layout/content tasks for company projects.

ROLE :: TECHNICAL HELP DESK SPECIALIST
│
├── PERIOD
│   └── December 2011 → October 2015
│
├── CONTEXT
│   └── uCoz
│
├── DESCRIPTION
│   ├── technical support
│   ├── user-issue diagnosis
│   ├── issue reproduction
│   ├── Jira-based task handling
│   ├── code-level troubleshooting
│   ├── communication quality
│   └── technical materials
│
├── RESPONSIBILITY
│   ├── standard / non-standard user cases
│   ├── escalation and reproducibility
│   ├── technically oriented support work
│   └── selected layout / content tasks
│
├── STACK
│   ├── USE → SUPPORT-WEB@1
│   │
│   └── OVERRIDE
│       ├── NOTE → code-level intervention occurred where required
│       ├── NOTE → selected layout / content work is recorded
│       │          as responsibility rather than promoted to
│       │          WEB-FULLSTACK@1
│       └── NOTE → later hosting / infrastructure competencies
│                  are not projected backward onto this period
│
└── ORGANIZATION
    └── uCoz

uCoz is the historical company and product environment attached to the 2011–2015 technical-support period and the earlier side of the transition into the later uKit QA role.

uCOZ
│
├── TYPE
│   └── historical company / product environment
│
├── PERIOD :: SAM
│   └── December 2011 → October 2015
│
├── STATUS
│   └── historical
│
├── RESPONSIBILITY :: SAM
│   ├── Technical Help Desk Specialist
│   ├── technical support
│   ├── diagnostics / reproduction
│   ├── Jira-based task flow
│   └── code-level troubleshooting where required
│
├── STACK
│   ├── USE → SUPPORT-WEB@1
│   │
│   └── OVERRIDE
│       └── NOTE → only historically supported technologies
│                  and responsibilities are represented
│
└── CONTINUITY
    └── uKit
        later QA / product-testing context

COMPLETED WORK
│
├── PROJECTS
│   │
│   └── 003 · Process Optimization — Elaris Studio Games
│       │
│       ├── TYPE
│       │   └── completed consulting project
│       │
│       ├── PERIOD
│       │   └── October 2025 → September 2026
│       │
│       ├── CONTEXT
│       │   └── Elaris Studio Games
│       │
│       ├── SCOPE
│       │   ├── task decomposition
│       │   ├── backlog structuring
│       │   ├── phase planning
│       │   ├── risk identification
│       │   ├── acceptance criteria
│       │   └── workflow stabilization
│       │
│       ├── RESULT
│       │   └── a more explicit and predictable development workflow
│       │       during a period of organizational difficulty
│       │
│       └── STACK
│           ├── USE → PROCESS-OPTIMIZATION@1
│           └── OVERRIDE
│               └── NOTE → project-management tooling is omitted
│                          where it is not independently documented
│
└── ARTIFACTS
    │
    ├── Glenbotal
    │   │
    │   ├── ORIGIN
    │   │   └── ZIPY HOLDINGS LTD.
    │   │
    │   ├── TYPE
    │   │   └── production web / subscription-commerce platform
    │   │
    │   ├── STATUS
    │   │   └── historical contribution / public selected-work reference
    │   │
    │   ├── RESULT
    │   │   ├── custom WooCommerce subscription logic
    │   │   ├── Figma-driven frontend implementation
    │   │   ├── performance / security work
    │   │   └── SEO / localization / production support
    │   │
    │   └── STACK
    │       ├── USE → WEB-FULLSTACK@1
    │       ├── USE → WORDPRESS-WEB@1
    │       └── OVERRIDE
    │           ├── ADD  → custom subscription module
    │           └── NOTE → implementation details remain scoped
    │                      to the historical ZIPY context
    │
    ├── Safe / Blind Zones — Live Tester
    │   │
    │   ├── ORIGIN
    │   │   └── Zhovten Games
    │   │
    │   ├── TYPE
    │   │   └── browser-based interface utility
    │   │
    │   ├── STATUS
    │   │   └── released / active project
    │   │
    │   ├── RESULT
    │   │   ├── recalculates safe / blind / inner zones
    │   │   ├── device presets and orientation switching
    │   │   ├── layered visual preview
    │   │   ├── PNG export
    │   │   └── UA / EN interface
    │   │
    │   └── STACK
    │       ├── USE → WEB-FULLSTACK@1
    │       └── OVERRIDE
    │           ├── REMOVE → PHP
    │           ├── REMOVE → SQL
    │           ├── REMOVE → REST APIs / Webhooks
    │           ├── ADD    → browser-only JavaScript runtime
    │           ├── ADD    → client-side i18n
    │           └── ADD    → PNG export
    │
    ├── Code Constitution: Software Architecture as a Normative Order
    │   │
    │   ├── ORIGIN
    │   │   ├── Zhovten Games research
    │   │   └── IRON CREED adaptation
    │   │
    │   ├── TYPE
    │   │   └── research publication / governance model / repository
    │   │
    │   ├── STATUS
    │   │   └── released / maintained
    │   │
    │   ├── RESULT
    │   │   └── explicit model for project rules, authority,
    │   │       canonical sources, architectural constraints,
    │   │       change procedures and verification evidence
    │   │
    │   ├── REFERENCE
    │   │   ├── DOI → 10.5281/zenodo.21894242
    │   │   └── The Constitution That Runs
    │   │
    │   └── STACK
    │       ├── USE → RESEARCH-PUBLISHING@1
    │       ├── USE → ENGINEERING-GOVERNANCE@1
    │       └── OVERRIDE
    │           └── ADD → DOI-backed public research artifact
    │
    ├── Literate Programming: Donald Knuth, WEB, and Contemporary Workflows
    │   │
    │   ├── ORIGIN
    │   │   └── Zhovten Games research
    │   │
    │   ├── TYPE
    │   │   └── methodological research publication / repository
    │   │
    │   ├── STATUS
    │   │   └── released / research track maintained
    │   │
    │   ├── RESULT
    │   │   └── reconstruction of literate-programming principles
    │   │       through WEB and contemporary reproducible workflows,
    │   │       including LLM-assisted development as a boundary case
    │   │
    │   ├── REFERENCE
    │   │   └── DOI → 10.5281/zenodo.20608558
    │   │
    │   └── STACK
    │       ├── USE → RESEARCH-PUBLISHING@1
    │       └── OVERRIDE
    │           └── NOTE → Prompt-Literate Workflow emerged as
    │                      a separately maintained applied method
    │
    ├── Prompt-Literate Workflow
    │   │
    │   ├── ORIGIN
    │   │   └── IRON CREED
    │   │
    │   ├── TYPE
    │   │   └── engineering methodology / repository
    │   │
    │   ├── STATUS
    │   │   └── released / maintained
    │   │
    │   ├── RESULT
    │   │   └── bounded human-authored workflow for LLM-assisted
    │   │       generation, review, testing and traceable acceptance
    │   │
    │   └── STACK
    │       ├── USE → LLM-ENGINEERING@1
    │       └── OVERRIDE
    │           └── NOTE → method artifact rather than application runtime
    │
    ├── Canon Horror Series
    │   │
    │   ├── ORIGIN
    │   │   └── Zhovten Games
    │   │
    │   ├── TYPE
    │   │   └── connected research / working-paper corpus
    │   │
    │   ├── STATUS
    │   │   └── published corpus / active series
    │   │
    │   ├── RESULT
    │   │   └── research on language, perception and media channels
    │   │       as systems of vulnerability in horror / science fiction
    │   │
    │   └── STACK
    │       ├── USE → RESEARCH-PUBLISHING@1
    │       └── OVERRIDE
    │           ├── ADD → Markdown + YAML
    │           ├── ADD → Pandoc
    │           └── ADD → XeLaTeX
    │
    ├── ZG Journal Template
    │   │
    │   ├── ORIGIN
    │   │   └── Zhovten Games publishing / Canon Horror pipeline
    │   │
    │   ├── TYPE
    │   │   └── reproducible publishing pipeline / repository
    │   │
    │   ├── STATUS
    │   │   └── released / maintained
    │   │
    │   ├── RESULT
    │   │   └── Markdown + YAML → Pandoc → XeLaTeX workflow
    │   │       for typography-controlled PDF with global or
    │   │       sectioned bibliography modes
    │   │
    │   └── STACK
    │       ├── USE → RESEARCH-PUBLISHING@1
    │       └── OVERRIDE
    │           ├── ADD → Pandoc 3.1.x
    │           ├── ADD → pandoc-crossref 0.3.16.x
    │           ├── ADD → XeLaTeX / TeX Live 2024+
    │           ├── ADD → PowerShell 7.4+
    │           └── ADD → custom LaTeX classes / style layers
    │
    └── InterDeadProto / NOIR
        │
        ├── ORIGIN
        │   └── InterDead
        │
        ├── TYPE
        │   └── released narrative-driven interface prototype
        │
        ├── STATUS
        │   └── released prototype / active development
        │
        ├── RESULT
        │   └── playable concept space for narrative loops,
        │       UX experiments, system experiments and host integration
        │
        └── STACK
            ├── USE → NODE-TOOLING@1
            ├── USE → WEB-DELIVERY@1
            └── OVERRIDE
                ├── ADD  → browser-native ES6 modules
                ├── ADD  → Local Build Lab
                ├── ADD  → Cloudflare deployment target
                └── ADD  → itch.io deployment target