Lilith checks a game release as it moves from an authoring station to an Arcade gateway.
Engineering / Knowledgebase

TECHNICAL NOTE

The Gynara Legend // gynara.release-engineering

From Maker to Drakima Arcade

Checked artifacts, pinned releases and the current mini-campaign publication policy.

Production Practitioner Updated 2026-11-04

01 / WHAT

What it does

A Gynara release includes browser code, gameplay rules, content and website configuration. Publishing keeps those pieces tied to one reviewed identity.

02 / WHY

Why it works this way

A repeatable release process reduces mismatched code, content and caches and makes a failure traceable to one reviewed artifact.

03 / HOW

How it works

Preparation and publication are separate

Maker's Build & Export → Publish to Arcade invokes the website-owned publishing workflow. Preparation validates content, builds the portable libraries and protected browser player, checks their exact module identities, installs deduplicated assets and verifies that the matching website runtime can admit the release.

Publication then selects the prepared release for the local website. A preparation receipt records what was checked. A changed source generation, conflicting operation or mismatched runtime must be resolved before that receipt is used.

Stage Result What it does not establish
Content validation References and registered content satisfy the loader's contracts Encounter balance or a complete playthrough
Build and module checks Browser and server belong to the intended rule generation Target-browser performance
Cold admission Installed rules and content can be admitted without a running player Public internet deployment or live capacity
Publication The selected release becomes available under website policy Automatic promotion of other campaigns
Owner acceptance A human checks the intended experience Universal device compatibility

Content hashes identify bytes; they are not an unlimited security guarantee. Publication also depends on trusted configuration, account checks and the release owner's validation.

Current Campaign 1 development policy

Only Campaign 1 is currently published for new Gynara attempts. Every development export clears prior Gynara progress and replaces the available game version. Accounts, purchases, wallets and other games are preserved. This is a development policy for the mini-campaign product, not a recommendation to erase unrelated data or future production records.

Players start fresh through Start Campaign. Flight retry remains available within the session. Earlier documentation about four simultaneously available campaigns or a Continue menu describes previous releases.

Standalone exports are a different destination

Maker can also package Windows and standalone browser builds for local review. A ZIP or a working local browser preview does not publish the protected Arcade installation. The website release path must coordinate its server-side rules and private content delivery as well.

Why this matters for future campaigns

Stable publication reduces manual copying and makes failures traceable to a specific prepared release. Campaign 2 should reuse that process while receiving its own content, access policy, performance measurements and owner acceptance. Authored content is not automatically published content.

Read the browser player, Maker, and documentation maintenance.

Implementation evidence: DrakimaCore scripts/Publish-GynaraArcade.ps1, tools/DrakimaCore.ArcadeCurrentTool, and the private release-admission owners; TheGynaraLegend docs/current/arcade-publishing.md and its Build & Export integration. Staff operating instructions are maintained separately from this public explanation.

Further reading: Maintained handbook chapter.

SYSTEM SCHEMATICS

View the diagram and flow
How the responsibilities connect Conceptual ownership flow, not a live status report.
  1. 01
    Prepare

    Build matching browser and simulation artifacts

  2. 02
    Check

    Verify content, pins and release metadata

  3. 03
    Publish

    Install through the canonical publisher

  4. 04
    Confirm

    Check the intended surface and record acceptance limits

IMPLEMENTATION SAMPLES

Inspect the code examples
Contract at a glancetext
Prepare: Build matching browser and simulation artifacts
Check: Verify content, pins and release metadata
Publish: Install through the canonical publisher
Confirm: Check the intended surface and record acceptance limits

Illustrative contract summary. Follow the linked source owners for implementation; this is not an executable script.

AkariLoreKeeper

AKARI-LK // ASK ABOUT THIS TOPIC

Ask a why or how question about this article.

Ask about this system