> ## Documentation Index
> Fetch the complete documentation index at: https://arclux-os.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 🚀 ARCLUX — Vessel Design, Visual Governance & 3D Design Dashboard

> Blueprint detail — ARCLUX Repository War Universe

# 🚀 ARCLUX — Vessel Design, Visual Governance & 3D Design Dashboard

> *Design Proposal — User-generated vessels with creative freedom, coherent
> visual identity, content safety, and real-time 3D authoring.*

Bagian dari blueprint ARCLUX (Repository War Universe).

***

## 1. Vision

ARCLUX memungkinkan repository menjadi source of truth bagi sebuah vessel.

Developer tidak sekadar mendapatkan statistik atau graph, tetapi dapat melihat
repository mereka berkembang menjadi living spacecraft.

```
REPOSITORY
    ↓
ARCLUX ANALYSIS
    ↓
VESSEL MODEL
    ↓
3D DESIGN
    ↓
ARCLUX UNIVERSE
```

ARCLUX menyediakan engine, world rules, validation, dan canvas.

Developer menyediakan repository, architecture, components, dan kreativitas.

**«One engine. Infinite vessels.»**

***

## 2. Core Design Principle

ARCLUX tidak boleh menyeragamkan seluruh vessel menjadi satu model kapal.

Setiap repository dapat menghasilkan vessel dengan karakteristik berbeda.

```
Repository A → 🚀 Vessel A
Repository B → 🛸 Vessel B
Repository C → 🌌 Vessel C
Repository D → 🚀 Vessel D
```

Perbedaan tersebut merupakan bagian dari identitas ARCLUX.

Namun kebebasan tersebut tetap berada dalam ARCLUX Visual Language.

**«Protect the universe's identity, not its creativity.»**

***

## 3. Creative Freedom

User dapat membuat vessel yang:

* asymmetrical
* modular
* geometric
* alien-inspired
* experimental
* compact
* gigantic
* highly specialized
* unconventional

ARCLUX tidak menentukan bahwa semua vessel harus memiliki silhouette yang sama.

Contoh evolusi:

```
BASE         MODULAR         ADVANCED         UNIQUE
 🚀     →      🚀⚙️      →     🚀⚙️🛡️     →    🌌🚀⚙️🛡️
```

### 3.1 Creative Freedom vs Engineering Reality

Kebebasan desain tetap dijunjung, namun ARCLUX membedakan **creative implementation**
dengan **arbitrary technical hallucination**.

ARCLUX tidak menolak desain eksperimental. Tetapi setiap komponen harus mampu
menjelaskan perannya dalam konteks engineering yang realistis:

```
WHAT IT IS
WHAT IT DOES
WHAT IT DEPENDS ON
WHAT IT AFFECTS
HOW IT FAILS
HOW IT INTERACTS WITH THE WORLD
```

Sistem komponen kapal mengikuti model dunia nyata (cross-ref 01 §2.6 hukum fisika
& thermal):

* **STRUCTURAL** — hull, integrity, component mounting
* **PROPULSION** — main propulsion, maneuvering, control interface
* **POWER** — energy source, distribution, emergency power
* **THERMAL** — heat generation, heat transfer, thermal limits
* **NAVIGATION** — orientation & navigation capability
* **DEFENSE** — protection systems
* **DAMAGE CONTROL** — response & recovery

Prinsip: desain sesuka hati **diizinkan**, tetapi komponen yang menyimpang dari
model fisik/mekanis realistis tidak lolos validasi. Kapal adalah engineering,
bukan asal jadi.

***

## 4. ARCLUX Visual Language

Walaupun desain bebas, vessel public harus tetap memiliki spacecraft identity.

Prinsip visual:

```
SPACECRAFT IDENTITY
        │
        ├── Aerospace / sci-fi silhouette
        ├── Mechanical structure
        ├── Functional components
        ├── Propulsion system
        ├── Modular architecture
        └── ARCLUX-compatible rendering
```

Tujuannya bukan membuat semua kapal terlihat sama.

Tujuannya membuat kapal yang berbeda tetap terasa berasal dari universe yang sama.

***

## 5. Visual Governance

Karena vessel dibuat oleh user, ARCLUX membutuhkan visual/content governance.

Governance digunakan untuk menjaga:

* reputasi ARCLUX
* kualitas public universe
* visual consistency
* community safety
* platform integrity

ARCLUX harus mencegah desain yang sengaja dibuat untuk:

* explicit sexual content
* sexually suggestive representations
* hateful/extremist imagery
* intentionally offensive imagery
* konten lain yang dilarang oleh community policy

Desain yang sekadar aneh atau eksperimental tidak otomatis ditolak.

***

## 6. Public vs Private Vessel

ARCLUX dapat membedakan antara development lokal dan public universe.

**Private / Local** — Developer mendapatkan ruang eksperimen yang lebih luas.

```
LOCAL DESIGN
     ↓
Developer Experimentation
     ↓
Private Vessel
```

**Public** — Vessel harus melewati validation.

```
PUBLIC DESIGN
     ↓
Validation
     ↓
Moderation
     ↓
ARCLUX UNIVERSE
```

Dengan demikian experimentation tidak harus berarti setiap desain langsung
menjadi bagian dari public universe.

***

## 7. Vessel Validation Pipeline

```
VESSEL DEFINITION
        ↓
SCHEMA VALIDATION
        ↓
GEOMETRY VALIDATION
        ↓
VISUAL POLICY
        ↓
CONTENT MODERATION
        ↓
TECHNICAL VALIDATION
        ↓
┌───────┴───────┐
↓               ↓
PASS            FLAG
↓               ↓
PUBLIC          REVIEW
UNIVERSE
```

Validation harus membedakan:

* unusual design

dengan

* intentionally inappropriate design.

#### 7.1 ARCLUX Universal Baseline (baseline yang tidak bisa dihapus)

Setiap repository kapal berisi **kode universal ARCLUX** di bagian awal, yang
**TIDAK BISA DIHAPUS/diubah inti** oleh pemain. Ini yang membuat sebuah repo dapat
"menjadi kapal" dan "bisa angkasa" — baseline yang menjamin:

* **Imun gravitasi** (01 §2.6): kapal tidak ditarik gravitasi skala system.
* **Sistem dasar** kapal (identitas, baseline stat, kerangka).
* **Validasi wajib**: tanpa baseline ini, repo TIDAK diterima sebagai vessel
  (`connectRepository` D-007 menolak / FLAG).

```
REPOSITORY (repo pemain)
├── ARCLUX UNIVERSAL BASELINE   ← kode wajib, tidak bisa dihapus
│     (imun gravitasi · identitas · sistem dasar · batas)
└── KONTEN KAPAL                 ← bebas disain user (mesh, component, capability,
                                   strategi, dll)
```

Pemisahan ini penting: **konten kapal = kreativitas user** (poin 3 Creative
Freedom), **baseline = fondasi universal ARCLUX** yang konsisten untuk semua
pemain, dan menjadi level "penyangga" yang sama. Dalam validasi pipeline, baseline
divalidasi sebagai bagian "TECHNICAL VALIDATION" — kehilangan/kerusakan baseline
(dampak kerusakan kapal, lihat 06 §18.5) berarti kapal "hilang kemampuan
angkasa/dasar".

Baseline ini tidak hanya memberikan identitas — ia juga membawa **bahasa
engineering bersama** (Vessel Engineering Quickstart): struktur component yang
realistis, dependency antar subsystem, dan titik awal canonical blueprint. Dengan
demikian pemain baru tidak perlu mulai dari repository kosong dan menebak-nebak
seluruh arsitektur kapal (lihat §21 Canonical Vessel Model).

***

## 8. Automated Visual Validation

ARCLUX dapat menggunakan beberapa signal:

```
Vessel Definition
      +
Geometry
      +
Visual Representation
      +
Metadata
      ↓
Visual Risk Analysis
```

Hasil:

```
LOW RISK
   ↓
AUTO PASS

MEDIUM RISK
   ↓
REVIEW

HIGH RISK
   ↓
REJECT / REDESIGN
```

Automated moderation sebaiknya menjadi first layer, bukan satu-satunya mekanisme.

***

## 9. Community Reporting

Public universe dapat menyediakan reporting system.

```
PUBLIC VESSEL
      ↓
REPORT
      ↓
MODERATION QUEUE
      ↓
REVIEW
      ↓
ACTION
```

Possible actions:

* approve
* request redesign
* temporarily hide
* restrict visibility
* reject

***

## 10. 3D Vessel Design Dashboard

ARCLUX membutuhkan 3D Vessel Design Dashboard sebagai visual bridge antara
repository dan vessel.

Dashboard bukan game editor biasa.

Dashboard adalah:

**«Real-time authoring + inspection + preview environment.»**

```
REPOSITORY
    ↓
ARCLUX ANALYSIS
    ↓
VESSEL MODEL
    ↓
3D DESIGN DASHBOARD
```

***

## 11. Dashboard Layout

```
┌─────────────────────────────────────────────────────────────┐
│ ARCLUX    VESSEL: PROJECT AURORA        [SYNC] [VALIDATE] │
├───────────────┬─────────────────────────────┬───────────────┤
│               │                             │               │
│   VESSEL      │                             │   INSPECTOR   │
│   TREE        │        3D CANVAS             │               │
│               │                             │ Hull          │
│  Hull         │          🚀                 │ Engine        │
│  Engine       │       ╱       ╲              │ Defense       │
│  Reactor      │      ╱  VESSEL  ╲            │ Weapons       │
│  Weapons      │                             │ Lighting      │
│  Defense      │                             │ Materials     │
│               │                             │               │
├───────────────┴─────────────────────────────┴───────────────┤
│ Repository │ Components │ Systems │ State │ History │ Events │
└─────────────────────────────────────────────────────────────┘
```

***

## 12. 3D Canvas

Canvas menjadi pusat visual development.

Fitur:

* orbit camera
* pan
* zoom
* rotate
* focus selected component
* reset camera
* free camera
* cinematic camera
* grid/spatial reference
* selectable components
* subsystem highlighting

Contoh shortcuts:

```
W / A / S / D → camera movement
Q / E         → vertical movement
R             → reset camera
F             → focus selection
Z / X         → zoom
ESC           → clear selection
```

*(Usulan shortcut — dapat dikonfigurasi pada tahap berikutnya.)*

***

## 13. Component Selection

Setiap component dapat dipilih langsung dari 3D vessel.

```
3D COMPONENT
      ↓
SELECT
      ↓
INSPECTOR
      ├── Component ID
      ├── Capability
      ├── Health
      ├── Repository source
      ├── Related files
      └── Provenance
```

Ini membuat hubungan:

```
visual → component → repository
```

menjadi eksplisit.

***

## 14. Code ↔ Vessel Navigation

ARCLUX harus memungkinkan navigasi dua arah.

**Vessel → Code**

```
Select Reactor
      ↓
SystemState
      ↓
ComponentBinding
      ↓
Repository File
      ↓
CodeNavigator
```

**Code → Vessel**

```
Open Repository File
      ↓
ARCLUX identifies affected subsystem
      ↓
3D component highlighted
```

Developer dapat memahami software architecture melalui dua representasi:

* code representation
* spatial representation

***

## 15. Visual Configuration

User dapat mengontrol aspek visual vessel melalui `.arclux/` dan dashboard.

Contoh:

```
HULL
├── geometry
├── material
├── texture
└── decals

LIGHTING
├── intensity
├── color
├── emissive
├── engine glow
└── subsystem indicators

EFFECTS
├── engine trails
├── particles
├── shield effects
└── damage effects
```

Visual customization **tidak boleh** menjadi sumber authoritative gameplay
statistics.

***

## 16. Lighting System

Lighting menjadi bagian dari visual layer.

User dapat menentukan style lighting vessel:

* hull illumination
* engine glow
* navigation lights
* subsystem indicators
* emissive components
* interior/exterior lighting
* decorative lights

ARCLUX tetap dapat menetapkan technical constraints seperti:

* effect budget
* light count
* performance limits
* mobile rendering profile

Dengan demikian:

```
USER
  ↓
LIGHTING STYLE
  ↓
ARCLUX RENDERER
  ↓
DEVICE-OPTIMIZED OUTPUT
```

***

## 17. Real-Time Preview

Perubahan `.arclux/` atau visual configuration dapat dipreview secara langsung.

```
USER CHANGE
     ↓
ARCLUX WATCHER
     ↓
VALIDATION / ANALYSIS
     ↓
VESSEL MODEL UPDATE
     ↓
3D CANVAS UPDATE
```

Developer tidak perlu membangun seluruh application hanya untuk melihat
perubahan vessel.

***

## 18. Design Modes

Dashboard menyediakan beberapa mode.

**DESIGN**

```
Hull
Components
Materials
Lighting
Effects
```

**INSPECT**

```
Architecture
Dependencies
Components
Health
Impact
```

**COMBAT PREVIEW**

```
Target lock
Weapon visualization
Shield effects
Damage states
Disabled systems
```

**HISTORY**

```
Commit A → Commit B → Commit C
    ↓          ↓          ↓
 Vessel      Vessel      Vessel
```

***

## 19. Damage Preview

Developer dapat mensimulasikan damage dalam sandbox.

```
Engine       ████████░░
Defense      █████░░░░░
Weapons      ███████░░
Reactor      █████████░
```

3D representation kemudian berubah sesuai subsystem state.

Contoh:

```
Defense ↓   → Shield visual degradation
Engine  ↓   → Engine output changes
Weapons ↓   → Weapon modules disabled
```

**Preview tidak mengubah real world-state.**

***

## 20. Visual vs Simulation Separation

Ini harus menjadi architectural boundary.

```
┌──────────────────────┐
│ AUTHORITATIVE STATE  │
│                      │
│ health               │
│ capability           │
│ damage               │
│ physics              │
│ combat               │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│ VISUAL REPRESENTATION│
│                      │
│ mesh                 │
│ lighting             │
│ particles            │
│ animation            │
│ effects              │
└──────────────────────┘
```

Mengubah mesh, lighting, atau particle effect **tidak boleh** meningkatkan:

* damage
* armor
* defense
* weapon capability
* combat authority

***

## 21. Canonical Vessel Model

ARCLUX harus memiliki canonical representation sebelum vessel dipublish.

```
USER DEFINITION
      ↓
ARCLUX VALIDATOR
      ↓
CANONICAL VESSEL
      ↓
CLIENT RENDERER
```

Client hanya menggambar validated representation.

Dengan demikian visual client tidak dapat digunakan untuk mengubah
authoritative state.

### 21.1 Canonical Blueprint ≠ Final Vessel

Canonical vessel model bukan kapal jadi — ia adalah **engineering foundation**.
Setiap vessel dapat dimulai dari canonical blueprint universal (Vessel Engineering
Quickstart, cross-ref §7.1 gambaran baseline).

```
CANONICAL BLUEPRINT
       │
  ┌────┼────────┬─────────┐
  ↓    ↓        ↓         ↓
RECON HEAVY  CARRIER  EXPERIMENTAL
```

**SAME FOUNDATION ≠ SAME VESSEL.**  Satu blueprint dapat menghasilkan ribuan
desain. Engineer bebas:

* mengubah arsitektur & redundancy
* membuat sistem modular
* mengembangkan komponen baru
* membuat konfigurasi khusus
* mengoptimalkan subsystem
* menciptakan teknologi komunitas

Selama berada dalam batas: **world rules + technical validation + component
constraints** (cross-ref §3.1).

Progressive engineering membantu pemain belajar bertahap (Foundation → Systems →
Architecture → Advanced) tanpa harus menguasai seluruh arsitektur dalam satu hari.

***

## 22. Rendering & Performance

Visual freedom tetap harus mempertimbangkan hardware.

**HIGH-END PC**

```
Maximum Detail
    ├── particles
    ├── lighting
    ├── effects
    └── geometry
```

**MOBILE**

```
Adaptive Rendering
    ├── reduced effects
    ├── adaptive resolution
    └── reduced render distance
```

**Simulation tidak bergantung pada FPS.**

**«Graphics quality changes the presentation, not reality.»**

***

## 23. Git-Native Design Workflow

Vessel design tetap mengikuti filosofi Git.

```
DESIGN CHANGE
      ↓
.arclux/ CHANGE
      ↓
GIT DIFF
      ↓
COMMIT
      ↓
ARCLUX ANALYSIS
      ↓
NEW VESSEL STATE
```

Dashboard dapat menyediakan comparison:

```
CURRENT VESSEL
       VS
AFTER COMMIT
```

Developer dapat melihat konsekuensi perubahan sebelum commit.

Setiap evolusi vessel tetap dapat dilacak melalui Git, dan Git History menjadi
jembatan antar lapisan:

```
GIT HISTORY
    ↔
VESSEL GENERATION HISTORY
    ↔
WORLD HISTORY
```

Contoh garis waktu generasi:

```
COMMIT #1      Basic vessel
   ↓
COMMIT #42     Thermal upgrade
   ↓
COMMIT #97     Redundant power system
   ↓
COMMIT #183    Battle-damage recovery architecture
```

Repository adalah catatan evolusi engineering kapal (cross-ref 08 §6 & §16 untuk
incident/service history pada sisi dunia).

***

## 24. Visual History

Setiap validated vessel state dapat dikaitkan dengan repository history.

```
Commit #102
     ↓
Vessel v1
     ↓
Commit #138
     ↓
Vessel v2
     ↓
Commit #201
     ↓
Vessel v3
```

Perubahan dapat dibandingkan berdasarkan:

* silhouette
* components
* subsystem state
* visual configuration
* architecture
* health

***

## 25. Design Evolution

Vessel tidak harus statis.

Repository yang berkembang dapat menghasilkan vessel yang berevolusi.

```
Repository
     ↓
Architecture changes
     ↓
New components
     ↓
New capabilities
     ↓
Vessel evolution
```

Dengan demikian vessel menjadi representasi visual dari living software project.

Evolusi membentuk **engineering loop** yang berkelanjutan:

```
BLUEPRINT
   ↓
IMPLEMENT
   ↓
VALIDATE
   ↓
ENTER WORLD
   ↓
BATTLE / EXPLORATION
   ↓
DAMAGE / FAILURE
   ↓
LESSON
   ↓
REDESIGN
   ↓
NEW ARCHITECTURE
```

Tidak ada "final perfect vessel". Setiap iterasi adalah generasi baru yang
membawa pelajaran dari generasi sebelumnya (cross-ref 08 §16 Persistent
Consequence Loop & 04-wreckage-history).

***

## 26. Proposed Architecture

```
                    REPOSITORY
                        │
                        ▼
                 ARCLUX ANALYSIS
                        │
              ┌─────────┴─────────┐
              ▼                   ▼
        VESSEL MODEL          WORLD STATE
              │                   │
              └─────────┬─────────┘
                        ▼
                 3D DESIGN MODEL
                        │
                        ▼
                 THREE.JS CANVAS
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
       DESIGN        INSPECT       PREVIEW
          │             │             │
          └─────────────┴─────────────┘
                        │
                        ▼
                  PUBLIC UNIVERSE
```

**Validation layer:**

```
USER DESIGN
     ↓
TECHNICAL VALIDATOR
     ↓
VISUAL VALIDATOR
     ↓
CONTENT MODERATION
     ↓
CANONICAL VESSEL
     ↓
ARCLUX UNIVERSE
```

***

## 27. Core Philosophy

ARCLUX tidak perlu membuat ribuan vessel secara manual.

ARCLUX menyediakan:

```
engine + rules + validation + canvas + tools
```

Developer menyediakan:

```
repository + architecture + components + creativity
```

Hasilnya:

**«One engine. Infinite vessels.»**

Dan governance memastikan:

**«Infinite creativity does not require infinite chaos.»**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.