> ## 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 β€” Community, Social Connection & Battlefield Ownership > Blueprint detail β€” ARCLUX Repository War Universe # πŸ›°οΈπŸ€ ARCLUX β€” Community, Social Connection & Battlefield Ownership > A battle should not simply determine who wins. It should determine what > survives, who owns it, what knowledge is lost, what knowledge is gained, > who trusts whom, who joins whom, and what history remains. Bagian dari blueprint ARCLUX (Repository War Universe). Extension V2 + V3 β€” Community Governance, Access, Vessel Identity & Persistent Social World. > **V3 (bagian ini):** memperkuat konsep trust, information access, > ownership, provenance, station governance, safe zones, intelligence leaks, > persistent history, dan repository-derived vessels dengan mekanika > eksplisit untuk: **governance roles, asset classification, access expiry & > revocation, community-specific exclusion (no auto-confiscation), multi-signature > governance, emergency lockdown, dynamic safe-zone/gate state, community splits, > governance event model, vessel identity, dan pemisahan visual 3D dari state > authoritative.** > > Prinsip yang dijaga: ARCLUX menyediakan **mekanisme**; komunitas menentukan > aturannya sendiri. ARCLUX tidak menilai apakah pemain secara moral "baik" > atau "buruk" β€” ia melestarikan konsekuensi dari keputusan komunitas. *** ## 1. Prinsip Inti: Konsekuensi Persisten Warfare di ARCLUX tidak boleh dibaca sebagai: ``` SHIP β†’ BATTLE β†’ DESTROYED β†’ RESPAWN ``` Melainkan sebagai rantai konsekuensi persisten: ``` COMMUNITY β†’ STATION β†’ VESSELS β†’ WAR β†’ DAMAGE/DESTRUCTION β†’ WRECKAGE β†’ COMPONENTS/INTELLIGENCE β†’ RECOVERY/CLAIM β†’ OWNERSHIP β†’ NEW VESSEL β†’ NEW COMMUNITY HISTORY ``` Warfare harus menghasilkan: history, engineering consequences, strategic assets, social conflict, collaboration, trust, intelligence, ownership, dan persistent stories. Dunia dibentuk bukan hanya oleh ARCLUX, tapi oleh repository, developer, komunitas, dan konflik yang ikut di dalamnya. > **Design goal:** Code creates the vessel. The vessel creates gameplay. > Gameplay creates conflict. Conflict creates wreckage. Wreckage creates > assets. Assets create ownership. Ownership creates diplomacy. Diplomacy > creates trust and betrayal. Trust creates communities. Communities create > collaboration. Collaboration creates new software. All of it creates > persistent history. *** ## 2. Yang Sudah Ada (cross-reference) Bagian ini TIDAK mengulang β€” ia memperkuat apa yang sudah didokumentasikan: | Topik | Sudah di | | - | - | | Community station, facilities, customization, evolution | [02-station-infrastructure.md](https://github.com/GSF-001/ARCLUX/blob/main/02-station-infrastructure.md) Β§2-7 | | Safe zone (radius 1km, weapons disabled, transition) | [02-station-infrastructure.md](https://github.com/GSF-001/ARCLUX/blob/main/02-station-infrastructure.md) Β§8-9 | | Component market, engineering bay, analysis lab | [02-station-infrastructure.md](https://github.com/GSF-001/ARCLUX/blob/main/02-station-infrastructure.md) Β§11-13 | | Community hub, permissions (public/community/fleet/private) | [02-station-infrastructure.md](https://github.com/GSF-001/ARCLUX/blob/main/02-station-infrastructure.md) Β§10,14 | | Component identity metadata (id, origin, owner, provenance) | [04-wreckage-history.md](https://github.com/GSF-001/ARCLUX/blob/main/04-wreckage-history.md) + `packages/universe/types.ts` | | Wreckage as resource, recovery, ownership via provenance | [04-wreckage-history.md](https://github.com/GSF-001/ARCLUX/blob/main/04-wreckage-history.md) | | Provenance survives integration | [04-wreckage-history.md](https://github.com/GSF-001/ARCLUX/blob/main/04-wreckage-history.md) | | Catastrophic damage β†’ wreckage | [03-combat.md](https://github.com/GSF-001/ARCLUX/blob/main/03-combat.md) I.3 | | Repair = commit (effort, bukan magic) | Blueprint utama Layer F | | Component authorization / license 3-tier | `packages/universe/license.ts` + [03-combat.md](https://github.com/GSF-001/ARCLUX/blob/main/03-combat.md) I.6 | | Community trust / access keys / expiry / revocation (concept) | lihat Β§3.2-3.4 di bawah | | Safe zone statis (radius, weapons disabled, transition) | [02-station-infrastructure.md](https://github.com/GSF-001/ARCLUX/blob/main/02-station-infrastructure.md) Β§8-9 | | Repository-derived vessel (source of config) | [05-vessel-design-dashboard.md](https://github.com/GSF-001/ARCLUX/blob/main/05-vessel-design-dashboard.md) + `packages/universe` | | Wreckage / provenance survives integration | [04-wreckage-history.md](https://github.com/GSF-001/ARCLUX/blob/main/04-wreckage-history.md) | | Gameserver authoritative (WorldRegion / Validator / Sim / Combat) | `packages/gameserver` (dasar implementasi Β§13-16 di bawah) | *** ## 3. Information & Trust ### 3.1 Information as a Community Asset Komunitas memiliki informasi berharga tentang vessel mereka: capability, subsystem, architecture, known weaknesses, component info, battle history, engineering config, strategic capability. **Prinsip:** > ARCLUX menyediakan mechanisms; komunitas menentukan trust & information > policies mereka sendiri. ### 3.2 Information Access Levels Komunitas mendefinisikan kelas akses informasi (kategori dapat dikonfigurasi): ``` PUBLIC ↓ MEMBER ↓ TRUSTED ↓ STRATEGIC ↓ RESTRICTED ``` Komunitas memutuskan informasi mana yang public, mana yang hanya untuk anggota terpilih. ### 3.3 Community Access Keys Informasi sensitif dapat dilindungi oleh access keys. Komunitas menentukan: * siapa yang menerima key; * berapa banyak yang memegangnya; * apakah butuh multi-approval; * kapan akses kedaluwarsa (expiry); * bagaimana key di-rotate; * informasi apa yang tiap key bisa akses. ``` COMMUNITY β†’ SENSITIVE INFORMATION β†’ ACCESS POLICY β†’ ACCESS KEY β†’ AUTHORIZED MEMBERS ``` Ini menciptakan **social trust system** β€” ARCLUX tidak perlu memutuskan sendiri siapa yang layak dapat akses. ### 3.4 Trust as Gameplay Sistem akses menciptakan social consequences yang muncul alami: ``` COMMUNITY β†’ TRUSTED MEMBER β†’ STRATEGIC ACCESS β†’ MEMBER LEAVES β†’ ACCESS REVOKED/ROTATED ``` Ini memproduksi secara organik: alliances, diplomacy, internal disputes, intelligence leaks, leadership conflicts, reputation, changing loyalties. > Sistem tidak perlu scripted drama. Players create the drama themselves. ### 3.5 Security Boundary (Penting) ARCLUX membedakan tegas antara: ``` IN-UNIVERSE INTELLIGENCE β‰  PRIVATE CREDENTIALS β‰  SECRET KEYS β‰  UNAUTHORIZED SOURCE ACCESS ``` * In-universe intelligence = representasi permainan dari info vessel. * **Private credentials / secrets / source access TIDAK** otomatis menjadi gameplay objects yang bisa ditransfer. * Komunitas menentukan secara eksplisit informasi apa yang direpresentasikan atau diekspos di dalam universe. Ini memungkinkan intelligence warfare **tanpa** mengubah credential pribadi atau informasi sensitif lain menjadi aset gameplay yang bisa dipindahtangankan. ### 3.6 Intelligence Leaks Komunitas bisa mengekspos informasi vessel β€” sengaja atau tidak: ``` VESSEL CAPABILITY β†’ MEMBER KNOWLEDGE β†’ SHARED β†’ OTHER COMMUNITY β†’ STRATEGIC ADVANTAGE ``` Informasi menjadi strategic resource. Komunitas yang gagal melindungi informasi bisa menampakkan weakness sebelum perang. ### 3.7 Community Reputation (Multi-Dimensional) Reputasi BUKAN satu skor universal. Signal potensial: * project participation * engineering contributions * successful recovery operations * community service * diplomatic history * completed collaborations * battle history * reliability Komunitas yang berbeda menghargai kontribusi yang berbeda. *** ## 4. Assets & Ownership ### 4.1 Component Identity Setiap recoverable component punya persistent identity: ``` Component ID Original Vessel Original Owner Current Owner Component Type Origin Provenance Battle History Recovery Status Integration Status ``` Component menjadi **historical object**, bukan disposable loot. ### 4.2 Ownership Transfer & Owner Loss ``` ORIGINAL OWNER (A) β†’ VESSEL DESTROYED β†’ WRECKAGE β†’ RECOVERED β†’ CLAIMED BY (B) β†’ CURRENT OWNER (B) ``` * Ownership transfer dicatat sebagai permanent historical event. * Setelah legitimate transfer, pemilik lama **tidak lagi otomatis mengontrol** aset tersebut. * Komunitas bisa kehilangan: rare components, strategic systems, historical artifacts, valuable engineering assets. * Ini membuat destruction **materially meaningful**. ### 4.3 Component Integration & Cross-Community History Recovered component dapat diintegrasi ke vessel lain jika compatibility rules memenuhi, dan **history-nya tetap menempel** setelah integrasi. ``` VESSEL BETA β”œβ”€β”€ Component A β†’ Original: Community B β”œβ”€β”€ Component B β†’ Original: Community C └── Component C β†’ Original: Community A ``` Sebuah vessel bisa jadi record dari sejarah universe. Component bisa bercerita menembus beberapa perang. ### 4.4 Component Value Value muncul dari kombinasi: ``` RARITY + CAPABILITY + COMPATIBILITY + PROVENANCE + HISTORY + DEMAND + STRATEGIC IMPORTANCE ``` > **Engineering significance should matter more than physical size.** Sebuah subsystem kecil bisa jadi salah satu artifact paling berharga di universe jika menyediakan capability penting. Component dari flagship terkenal yang hancur bisa bernilai karena sejarahnya, bukan hanya fungsinya. *** ## 5. Fleet & Recovery Operations ### 5.1 Fleet Mass-Casualty Perang besar memungkinkan komunitas kehilangan banyak vessel: ``` COMMUNITY FLEET (50 VESSELS) β†’ 40 DESTROYED β†’ 10 SURVIVE ``` Konsekuensi melampaui battlefield: wreckage recovery, component recovery, engineering workload, reconstruction, loss of strategic/historical assets, perubahan fleet capability. **Perang terus memengaruhi komunitas setelah combat berakhir.** ### 5.2 Recovery as a Community Effort Operasi recovery besar menjadi community projects: ``` 40 WRECKS β†’ SCOUTING β†’ RECOVERY β†’ ENGINEERING β†’ RECONSTRUCTION β†’ VALIDATION ``` Anggota berbeda berkontribusi dalam peran berbeda β€” memungkinkan programmer dan non-programmer berpartisipasi dalam ekosistem yang sama. ### 5.3 Player Roles (Non-Programmer Friendly) Universe tidak mengharuskan semua player jadi programmer: * **Explorer** β€” menjelajahi universe, menemukan lokasi * **Scout** β€” mengumpulkan info battlefield & environment * **Analyst** β€” mempelajari vessel intelligence * **Community Member** β€” partisipasi life station * **Engineer** β€” mengerjakan sistem vessel/software * **Developer** β€” mengubah repository/code representation * **Recovery Specialist** β€” mencari & recover battlefield assets * **Commander** β€” mengoordinasi operasi komunitas ### 5.4 Non-Coder Participation & Progression Player dengan pengetahuan programming dasar tetap punya gameplay berarti lewat: communities, stations, exploration, events, diplomacy, intelligence, scouting, recovery, dan social systems. Progression opsional: ``` PLAYER β†’ COMMUNITY β†’ COLLABORATION β†’ LEARNING β†’ ENGINEERING β†’ DEVELOPMENT β†’ VESSEL CREATION ``` ARCLUX menyediakan jalur masuk ke software engineering tanpa mengharuskan pemain memulainya sebagai programmer berpengalaman. *** ## 6. Community Lifecycle & Social Bridge ### 6.1 Community Discovery & Visibility ARCLUX menyediakan cara developer/player menemukan & terhubung dengan komunitas. Sistem tidak mengasumsikan semua player sudah punya tim. ``` INDIVIDUAL DEVELOPER β†’ ARCLUX UNIVERSE β†’ COMMUNITY DISCOVERY β†’ EXPLORE β†’ JOIN/REQUEST β†’ SOCIAL CONNECTION β†’ COLLABORATION β†’ NEW HISTORY ``` Discoverability berdasarkan: technical interests, project types, community activity, engineering specialization, play style, community history, current projects, open membership, collaboration opportunities. Komunitas menentukan discoverability sendiri: ``` PUBLIC β†’ DISCOVERABLE β†’ MEMBERSHIP REQUIRED β†’ INVITATION ONLY β†’ PRIVATE ``` ### 6.2 Solo Developer Participation Player solo (1 repo, 1 vessel, limited experience, no collaborators) tidak terhalang. Path: ``` CREATE/CONNECT REPO β†’ GENERATE VESSEL β†’ ENTER UNIVERSE β†’ DISCOVER COMMUNITIES β†’ MEET PLAYERS β†’ JOIN β†’ COLLABORATE ``` Sistem menyediakan jalur dari partisipasi individu ke komunikasi komunitas **tanpa memaksa** player bergabung. ### 6.3 Community Projects Komunitas mengorganisir shared projects β€” melibatkan banyak repository, vessel, developer, dan member: ``` COMMUNITY β†’ PROJECT β”œβ”€β”€ Repository A / B / C β”œβ”€β”€ Vessel Alpha / Beta └── Engineering Team ``` Komunitas jadi collaborative engineering organization, bukan sekadar group. ### 6.4 Community Growth ``` SOLO PLAYER β†’ SMALL GROUP β†’ COMMUNITY β†’ ESTABLISHED β†’ LARGE ORGANIZATION ``` Growth menciptakan kebutuhan baru: governance, access control, engineering roles, station/intelligence/diplomacy/fleet/recovery management. Struktur sosial muncul dari aktivitas player. ### 6.5 Social Hub Station berfungsi sebagai social hub + engineering/strategic: ``` COMMUNITY STATION β”œβ”€β”€ SOCIAL / ENGINEERING / INTELLIGENCE β”œβ”€β”€ DIPLOMACY / EVENTS / PROJECTS / HISTORY ``` Player bisa: meet member, discover projects, discuss engineering, coordinate ops, organize events, display vessels, exchange knowledge, recruit collaborators, establish diplomacy, build identity. ### 6.6 Developer Retention Loop Alih-alih: ``` BUILD PROJECT β†’ PUBLISH REPO β†’ STOP ``` The ARCLUX loop: ``` BUILD PROJECT β†’ CONNECT REPO β†’ CREATE VESSEL β†’ JOIN COMMUNITY β†’ BUILD RELATIONSHIPS β†’ DEVELOP β†’ VESSEL EVOLVES β†’ COMMUNITY ACTIVITY β†’ RETURN TO PROJECT β†’ CONTINUE DEVELOPMENT ``` Tujuan bukan memaksa developer menjaga repo β€” persistent world memberi motivasi tambahan bagi developer yang menikmati melihat software mereka berevolusi. ### 6.7 Social Bridge for Developers Loop bidirectional: ``` CODE β†’ REPOSITORY β†’ VESSEL β†’ UNIVERSE β†’ COMMUNITY β†’ PEOPLE β†’ COLLABORATION β†’ NEW CODE ``` Code creates vessels. Vessels create gameplay. Gameplay creates communities. Communities create collaboration. Collaboration creates new software β†’ new vessels. **Self-reinforcing developer ecosystem.** *** ## 7. Economic Layer & Payment Boundary ### 7.1 Economic Layer Jika economy in-universe nanti diperkenalkan, battlefield assets bisa punya nilai ekonomi. Value sources: rarity, engineering significance, provenance, demand, compatibility, historical importance, strategic capability. Economy tetap **layer design terpisah** dan tidak memerlukan nilai uang dunia nyata. ### 7.2 Real-World Payment Boundary Any real-world payment/trading/monetization **dispesifikasikan terpisah** dari core battlefield mechanics. Universe tidak mewajibkan uang nyata untuk ownership transfer biasa kecuali secara eksplisit dirancang & diatur oleh sistem ekonomi ARCLUX. ``` GAMEPLAY ASSET β‰  REAL-WORLD FINANCIAL ASSET ``` *** ## 8. Emergent Drama Sistem menghindari scripted drama. Drama muncul dari: ``` OWNERSHIP + TRUST + INFORMATION + WAR + RECOVERY + LOSS + HISTORY ``` Contoh emergent stories: * a trusted member leaks strategic information * a flagship is destroyed * a rare component is recovered by the enemy * a community loses access to an important asset * an old component appears inside a rival's vessel * communities negotiate over recovered assets * a station becomes a center of political conflict * a solo developer joins and becomes a trusted engineer * a community grows from small group to major organization > The world creates the conditions. Players create the stories. *** ## 9. Historical Artifacts & Community-Driven World Creation ### 9.1 Historical Artifacts ``` LEGENDARY FLAGSHIP β†’ DESTROYED IN WAR β†’ WRECKAGE DISCOVERED β†’ RARE COMPONENT RECOVERED β†’ INTEGRATED β†’ COMPONENT BECOMES RECOGNIZED ``` Years later, players bisa menemukan component dan inspect provenance. Player actions menjadi persistent universe history. ### 9.2 Community-Driven World Creation Players tidak hanya mengisi universe β€” mereka membantu menciptakan struktur sosialnya: identities, traditions, alliances, rivalries, projects, engineering cultures, governance, histories, reputations, diplomatic relationships. > ARCLUX menyediakan underlying systems. Players create the social world. *** ## 10. Engine Value Proposition Kekuatan extension ini: engine code-intelligence menyediakan layer intelijen yang menghubungkan: ``` REPOSITORY β†’ GRAPH β†’ IMPACT β†’ VESSEL β†’ DAMAGE β†’ RECOVERY β†’ HISTORY ``` Nilai kunci = **intelligence useful WITHOUT being mandatory**. Tanpa repository intelligence, recovery kompleks butuh kerja manual memahami file β†’ dependency β†’ impact β†’ component β†’ subsystem. Dengan ARCLUX, hubungan ini disurface otomatis β€” value proposition natural untuk engineering capabilities. *** ## 11. Ringkasan Model ``` ARCLUX UNIVERSE β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” COMMUNITIES VESSELS β”‚ β”‚ STATIONS SYSTEMS β”‚ β”‚ SOCIAL HUBS COMPONENTS β”‚ β”‚ TRUST/ACCESS CODE β”‚ β”‚ INTELLIGENCE β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ COLLABORATION β†’ WAR β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ β”‚ β”‚ REPAIR DESTRUCTION OWNERSHIP β”‚ β”‚ β”‚ COMMIT WRECKAGE HISTORY β”‚ β”‚ PROVENANCE RECOVERY COMPONENTS β”‚ β”‚ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ NEW VESSEL β†’ NEW HISTORY β”‚ COMMUNITY β†’ NEW PLAYERS β†’ NEW PROJECTS ``` *** ## 12. Access is Not Ownership β€” Asset Classification Prinsip keamanan fundamental: > **Access to an asset does not automatically mean ownership of that asset.** Contoh: ``` PLAYER B β€”authorized to operateβ†’ COMMUNITY VESSEL ``` tidak berarti `PLAYER B = OWNER`. Sistem membedakan peran secara eksplisit: ``` OWNER β†’ OPERATOR β†’ MAINTAINER β†’ AUTHORIZED USER β†’ TEMPORARY HOLDER β†’ COMMUNITY ADMIN ``` Ini mencegah sistem governance secara tidak sengaja mengubah permission operasional menjadi kepemilikan. ### 12.1 Klasifikasi Aset Setiap aset punya klasifikasi kepemilikan yang eksplisit: ``` PERSONAL COMMUNITY SHARED TEMPORARY RECOVERED CONTESTED ``` Contoh: ``` PERSONAL VESSEL Owner β†’ Player A COMMUNITY STATION Owner β†’ Community A COMMUNITY COMPONENT Owner β†’ Community A TEMPORARY ACCESS Holder β†’ Player B, Owner β†’ Community A ``` Klasifikasi ini memungkinkan sistem disiplin beroperasi **tanpa otomatis menyita properti pribadi** yang tidak terkait. > **Invariant I-8:** Operational permission must never silently become ownership. *** ## 13. Authoritative Social Actions β€” Access Expiry, Revocation & Exclusion Tindakan sosial mengikuti prinsip authority yang sama dengan combat (Β§32). ### 13.1 Access Lifetime Access tidak harus permanen: ``` ACCESS GRANTED β†’ EXPIRATION β†’ REVIEW β†’ RENEW | REVOKE ``` Berguna untuk: temporary engineers, diplomats, contractors, visiting players, temporary alliances, recovery operations. **Access yang sudah kedaluwarsa harus ditolak oleh authoritative validation.** ### 13.2 Access Revocation Ketika member kehilangan trust / meninggalkan komunitas, akses dapat dicabut. Pemicu: voluntary departure, expulsion, leadership decision, security incident, access expiration, role change, emergency lockdown. Tercatat secara akuntabel (bukan hukuman otomatis): ``` WHO Β· WHAT ACCESS Β· WHEN GRANTED Β· WHEN REVOKED Β· WHO AUTHORIZED Β· REASON / EVENT REF ``` ### 13.3 Community-Specific Exclusion Komunitas bisa memelihara status eksklusi internal: ``` TRUSTED β†’ SUSPENDED β†’ RESTRICTED β†’ EXPELLED ``` Konsekuensi yang mungkin (ditentukan komunitas): * station access denied * strategic information access denied * community channels restricted * community-owned asset access revoked * engineering permissions revoked * recovery operations restricted > **Blacklist bersifat community-specific.** Pemain yang dikeluarkan dari > Community A tidak otomatis menjadi "penjahat global" menurut ARCLUX (Β§19). ### 13.4 No Automatic Universal Confiscation Status blacklist **tidak** otomatis memindahkan kepemilikan semua aset pemain: ``` PLAYER BLACKLISTED ↓ CHECK ASSET OWNERSHIP ↓ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ PERSONAL β”‚ COMMUNITY β”‚ β”‚ remains β”‚ governed by β”‚ β”‚ personal β”‚ community rules β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ ``` Kepemilikan dievaluasi menurut catatan kepemilikan aktual aset β€” mencegah governance menjadi mekanisme penyitaan tanpa batas. ### 13.5 Community Asset Recovery Jika member yang diusir mengontrol aset yang tercatat community-owned, komunitas dapat menjalankan prosedur recovery-nya sendiri: ``` COMMUNITY VESSEL β†’ AUTHORIZED OPERATOR β†’ MEMBER EXPELLED β†’ ACCESS REVOKED β†’ RECOVERY PROCEDURE β†’ VESSEL RETURNED TO COMMUNITY ``` Ini BEDA dari menyita vessel pribadi pemain. Recovery adalah tindakan **authoritative** dan dicatat sebagai world event. *** ## 14. Governance Event Model Aksi governance penting menjadi historical events yang persisten. Daftar event (dari V3 proposal): ``` community.member.joined community.member.promoted community.member.suspended community.member.expelled access.granted access.expired access.revoked station.lockdown.enabled station.lockdown.disabled station.gate.opened station.gate.closed station.safezone.enabled station.safezone.disabled community.asset.recovery.started community.asset.recovered information.classified information.disclosed leadership.transferred ``` Sebuah governance event berisi: ``` EVENT β”œβ”€β”€ eventId β”œβ”€β”€ actor β”œβ”€β”€ target β”œβ”€β”€ action β”œβ”€β”€ timestamp β”œβ”€β”€ previousState β”œβ”€β”€ resultingState β”œβ”€β”€ authorizationContext └── references ``` > **Invariant I-7:** History cannot depend solely on client claims β€” event > penting harus berasal dari state server authoritative, bukan klaim client. *** ## 15. Multi-Signature & Emergency Governance ### 15.1 Multi-Signature Keputusan berimpak tinggi dapat memerlukan banyak persetujuan (dikonfigurasi, jumlah & role approver ditentukan komunitas): ``` REQUEST β†’ LEADER APPROVAL + COUNCIL APPROVAL β†’ ACTION EXECUTED ``` Contoh: revoke akses member senior, revoke strategic access, transfer aset besar, ubah station security policy, buka restricted access, deklarasi emergency, ubah safe-zone protection state. ### 15.2 Emergency Lockdown (Authoritative State) ``` SECURITY INCIDENT β†’ EMERGENCY LOCKDOWN β†’ RESTRICTED ACCESS β†’ AUDIT β†’ GOVERNANCE DECISION ``` Selama lockdown: * strategic access ditangguhkan sementara * station permissions dikurangi * informasi sensitif jadi restricted * community-owned assets ditempatkan di bawah controlled access > Lockdown adalah **state authoritative** β€” tercatat sebagai world event dan > memengaruhi WorldValidator, bukan sekadar indikator visual. ### 15.3 Gate / Access State Transition ``` STATION β”œβ”€β”€ Gate CLOSED β†’ Safe Zone ACTIVE └── Gate OPEN β†’ Protection Policy Changes ``` Transisi gate-state **bukan visual** β€” harus: 1. require authorization 2. modify authoritative world state 3. affect WorldValidator behavior 4. generate a world event 5. menjadi bagian persistent history Event: `station.gate.opened`, `station.gate.closed`, `station.safezone.enabled`, `station.safezone.disabled`. > **Invariant I-4:** Gate state is authoritative β€” visual gate state β‰  actual > permission. *** ## 16. Dynamic Safe-Zone / Gate (Governing Protection) Safe zone statis sudah didokumentasikan (02 Β§8-9). V3 memperkuatnya dengan membuat **state & policy proteksi dapat digovern secara authoritative**: ``` SAFE ZONE β”œβ”€β”€ radius β”œβ”€β”€ attack policy β”œβ”€β”€ access policy β”œβ”€β”€ community policy └── current state ``` Saat aktif: ``` SAFE ZONE ACTIVE β†’ TARGET INSIDE PROTECTED RADIUS β†’ WORLD VALIDATOR β†’ ATTACK REJECTED ``` Saat later / governance-controlled change: ``` SAFE-ZONE ACTIVE β†’ AUTHORIZED GOVERNANCE ACTION β†’ SAFE-ZONE DISABLED β†’ WORLD EVENT β†’ COMBAT POLICY CHANGES ``` > Perubahan proteksi harus mengubah **validasi authoritative**, bukan sekadar > mengubah indikator visual. Implementasi menempel pada `packages/gameserver` (validator/simulation): state proteksi menjadi input WorldValidator β€” dasar untuk Β§13-15. *** ## 17. Community Splits & Forked Lineage Komunitas dapat mengalami perpecahan politik internal: ``` COMMUNITY β†’ INTERNAL DISPUTE β†’ LEADERSHIP CONFLICT β†’ MEMBER GROUP SPLITS β†’ NEW COMMUNITY β†’ SHARED HISTORY ``` Aset & repository mengikuti aturan ownership/governance eksplisit β€” **bukan duplikasi otomatis yang sewenang-wenang**. Kedua komunitas hasil pecahan dapat mempertahankan referensi asal: ``` COMMUNITY A β†’ INTERNAL SPLIT β†’ (A1, A2) β†’ Origin: Community A ``` sambil mengembangkan identitas independen setelahnya β€” sejarah organisasi bertahan melintasi garis keturunan komunitas. *** ## 18. Vessel Identity, Provenance & 3D Representation ### 18.1 Vessel Identity Layer 1 repository β†’ 1 vessel. Namun vessel bukan sekadar kontainer stat combat β€” ia punya identitas persisten: ``` Vessel β”œβ”€β”€ Repository Identity β”œβ”€β”€ Owner β”œβ”€β”€ Community β”œβ”€β”€ VesselModel β”œβ”€β”€ Systems β”œβ”€β”€ Components β”œβ”€β”€ World State β”œβ”€β”€ Provenance β”œβ”€β”€ Governance References └── Visual Representation ``` Lifecycle persisten: ``` REPOSITORY β†’ CONNECTED β†’ VESSEL SPAWNED β†’ MODIFIED β†’ COMBAT β†’ DAMAGED β†’ RECOVERED β†’ REPAIRED β†’ HISTORY RETAINED ``` ### 18.2 Authoritative vs Client Representation ``` AUTHORITATIVE WORLD CLIENT REPRESENTATION packages/universe ↓ β†’ VesselModel 3D Vessel β†’ gameserver mesh / materials / animation / β†’ WorldEntity lighting / effects / camera ``` * Server menentukan: position, velocity, heading, ownership, systems, world state, combat results. * Client menentukan: mesh, materials, lighting, effects, camera, presentation. > **Invariant I-1:** Client is not authoritative β€” client representation never > becomes the source of truth. ### 18.3 Damage β†’ Visual State (Non-Authoritative) ``` Weapons: 100 β†’ Combat β†’ Weapons: 88 β†’ Client Visual State (ACTIVE / DAMAGED / DISABLED / DESTROYED) ``` > Visual state is never authoritative. State authoritative tetap di game server. ### 18.4 Provenance + Governance Coexist ``` COMPONENT X Technical: Original Owner: A Β· Vessel: Alpha Β· Battle: War #27 Recovered By: B Β· Integrated: Beta Β· Current: B Governance: Community A β†’ granted engineer access β†’ Engineer X β†’ access revoked β†’ Engineer X β†’ expelled ``` Sejarah teknikal & sejarah sosial hidup berdampingan β€” governance tidak pernah menghapus provenans teknis. ### 18.5 Kapal = Kode, dan Kerusakan Ikut Menyentuh Kode Kapal adalah repository (D-007). Ini bukan metafor belaka β€” **kerusakan kapal berdampak ke "kode" kapal**, dan pemain harus *debug*: ``` KAPAL RUSAK (thermal/collision/combat) ↓ BASELINE / SUBSYSTEM TERPENGARUH (imun hilang? sistem dasar turun?) ↓ KAPAL "TIDAK BERFUNGSI" β†’ harus diperbaiki / debug ↓ REPAIR β†’ berfungsi lagi (lihat 03 damage, 04 recovery) ``` * Kerusakan (termasuk thermal melt dari 01 Β§2.6, collision dari 03 I.9) memengaruhi sistem kapal. * **ARCLUX Universal Baseline** (05 Β§7.1) ikut terdampak: mis. kehilangan sebagian baseline β†’ kapal kehilangan kemampuan dasar/angkasa sampai diperbaiki. * Repair/recovery mengembalikan fungsi (04 Β§recovery); provenance tetap mencatat sejarah kerusakan. ### 18.6 Identitas Sosial / Callsign (label faksi & nama) Setiap vessel/player tampil di HUD/overlay dengan **identitas sosial** agar pemain langsung tahu kawan vs lawan: ``` [KOMUNITAS A] [GSF-xxxx] [username] ← label di overlay (01 Β§20) ``` * **Authoritative**: siapa owner/community ditentukan server (06 Β§18.2, I-1); label cuma representasi client. * Nama frame berasal dari vessel identity (Β§18.1: Repository Identity + Owner + Community) dan repo unik prefix user. * Tidak ada "pemenang/loser" β€” label murni penanda kawan/lawan, bukan sistem skor. ### 18.7 Intel, Kordinat & Mobilisasi Armada (drama EVE-style) Pemain/kapal dapat **membagikan titik (koordinat/waypoint)** medan atau titik kumpul ke aliansi, untuk koordinasi armada pada konflik besar: ``` PERANG BESAR ↓ kapal berbagi TITIK (koordinat / titik kumpul / waypoint medan) ↓ tersebar ke ALIANSI (beberapa komunitas bersekutu; intel, lihat Β§3) ↓ kapal sekutu melihat titik di peta (tactical marker, 01 Β§2) ↓ terima β†’ GERAK terbatas (lihat Β§18.8) β†’ mobilisasi ``` * Berbagi posisi ber-label: muncul **nama kapal/nama org** pengirim (18.6) + koordinat. * Restriksi intel mengikuti access/trust (Β§3.2/Β§3.3); intel bisa bocor (Β§3.6) β†’ drama tambahan. * **Alian/i** = beberapa community yang bersekutu (diplomasi, Β§8). Bukan konsep "sisi vs sisi dengan hasil menang/kalah" β€” open world, hasil dari keputusan & gerak. ### 18.8 Mobilisasi Terbatas (2-Teleport) + Portal Kapal yang menerima titik dapat bergerak ke sana dengan jendela pergerakan terbatas β€” **bukan teleport bebas**, bukan jump gate navigasi (01 Β§14): ``` TERIMA TITIK β†’ catat TITIK ASAL (anchor) β†’ TELEPORT #1 (portal) β†’ masuk medan perang β†’ (bertempur / membantu / batal) β†’ TELEPORT #2 (portal) β†’ BALIK ke TITIK ASAL ``` * **Batas 2 teleport per aktivasi bantuan**: 1 ke titik, 1 balik ke titik asal. Tidak bisa teleport ke tempat lain. * **Cooldown panjang** β†’ bukan "mobil gratis"; ada harga keputusan. * **Animasi portal** cinematic saat masuk/keluar (feedback EVE-level, lihat UI 01). * Bukan teleport antar-map/maintenance; murni **mobilisasi respon konflik** (bukan SOS instan β€” melainkan koordinat yang dibagikan, Β§18.7). *** ## 19. Definition of Done (V3) Dianggap konseptual lengkap ketika: * [ ] Community dapat mendefinisikan access policy * [ ] Roles & permissions terdiferensiasi dari ownership (I-8) * [ ] Assets punya klasifikasi kepemilikan eksplisit (Β§12) * [ ] Access dapat expire (Β§13) * [ ] Access dapat direvoke (Β§13) * [ ] Exclusion community-specific ada, tanpa auto-confiscation (Β§13) * [ ] Community-owned assets dapat memulai recovery (Β§13.5) * [ ] High-impact governance dapat memerlukan multi-approval (Β§15) * [ ] Emergency lockdown ada sebagai state authoritative (Β§15) * [ ] Station permissions authoritative (Β§15) * [ ] Safe-zone state dapat digovern (Β§16) * [ ] Governance events persisten (Β§14) * [ ] Accusations terdiferensiasi dari verified events (kepercayaan, Β§8) * [ ] Intelligence events mempertahankan attribution (intelijen, Β§3) * [ ] Community history persisten (Β§9) * [ ] Community splits melestarikan lineage (Β§17) * [ ] Vessel identity persisten (Β§18) * [ ] Repository tetap sumber vessel (Β§18 + 05) * [ ] Vessel provenance bertahan melalui recovery & pergantian pemilik (04) * [ ] Representation 3D tetap client-side (Β§18) * [ ] Client tidak bisa override state authoritative (I-1) * [ ] Self-hosted regions tetap kompatibel * [ ] Private repository secrets tetap di luar gameplay (Β§3.5) *** ## 20. Ringkasan Model (V3) ``` ARCLUX UNIVERSE β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ β”‚ COMMUNITIES VESSELS β”‚ β”‚ GOVERNANCE SYSTEMS β”‚ β”‚ TRUST COMPONENTS β”‚ β”‚ ACCESS CODE β”‚ β”‚ INFORMATION β”‚ β”‚ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ PLAYER ACTION β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ β”‚ COOPERATION CONFLICT β”‚ β”‚ β”‚ INTELLIGENCE β”‚ β”‚ β”‚ LEAK β”‚ β”‚ β”‚ GOVERNANCE β”‚ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ ACCESS / OWNERSHIP β”‚ CONSEQUENCE β”‚ PROVENANCE β”‚ HISTORY β”‚ COMMUNITY MEMORY β”‚ NEW SOCIAL RELATIONS ``` Code creates the vessel. The vessel creates gameplay. Gameplay creates relationships. Relationships create trust. Trust creates access. Access creates responsibility. Actions create consequences. Consequences create governance. Governance creates history. History creates community identity. Players create the events. ARCLUX preserves the consequences. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.