|
| 1 | +# Project Lifecycle Model |
| 2 | + |
| 3 | +## Status |
| 4 | + |
| 5 | +This is a planning document for GameFoundryStudio project lifecycle behavior. |
| 6 | + |
| 7 | +It defines intended project states, ownership roles, visibility modes, and platform relationships before database, authentication, Admin, Account, publishing, marketplace, or runtime implementation begins. |
| 8 | + |
| 9 | +This document does not authorize runtime changes, database implementation, authentication implementation, page changes, CSS changes, JavaScript changes, or schema migrations. |
| 10 | + |
| 11 | +## Project Purpose |
| 12 | + |
| 13 | +A Project is the working container for creator activity. |
| 14 | + |
| 15 | +Projects organize tool states, assets, palettes, manifests, releases, and marketplace outputs under one ownership and visibility boundary. Projects should become the durable workspace layer between users and portable export/import artifacts. |
| 16 | + |
| 17 | +## Project States |
| 18 | + |
| 19 | +| State | Meaning | Editable | Shareable | Notes | |
| 20 | +| --- | --- | --- | --- | --- | |
| 21 | +| Draft | Early project state before active work or sharing begins. | Yes | No by default | Used for newly created projects and private experiments. | |
| 22 | +| Active | Normal working state for an in-progress project. | Yes | According to visibility | Most creator work should happen here. | |
| 23 | +| Archived | Preserved but inactive project state. | Limited | According to visibility | Restorable when policy allows; not the default editing state. | |
| 24 | +| Published | Project has produced at least one release. | Yes for project, not for immutable release snapshots | Yes | Published state does not make all project internals public. | |
| 25 | +| Marketplace | Project has produced marketplace content or listing-ready content. | Yes for project, controlled for listing content | Marketplace or moderated | Marketplace content may have stricter review, licensing, and visibility rules. | |
| 26 | +| Retired | Project is no longer active, discoverable, or supported as current content. | No by default | Limited or hidden | Retired projects may keep audit, ownership, and historical references. | |
| 27 | + |
| 28 | +## Project State Rules |
| 29 | + |
| 30 | +- Draft can move to Active. |
| 31 | +- Active can move to Archived. |
| 32 | +- Archived can move back to Active when ownership and permissions allow. |
| 33 | +- Active can move to Published when a valid Game Manifest and release workflow exist. |
| 34 | +- Published can move to Marketplace when marketplace content is created and approved. |
| 35 | +- Published or Marketplace projects can move to Retired. |
| 36 | +- Retired projects should not silently delete related Tool States, Assets, Palettes, Game Manifest records, Releases, or Marketplace Items. |
| 37 | +- State changes should be explicit database events in a future implementation. |
| 38 | + |
| 39 | +## Project Ownership |
| 40 | + |
| 41 | +| Role | Meaning | Expected Permissions | |
| 42 | +| --- | --- | --- | |
| 43 | +| Owner | Primary accountable user or organization for the project. | Manage project settings, ownership, collaborators, visibility, exports, releases, and marketplace actions subject to policy. | |
| 44 | +| Collaborator | Authorized project participant. | Read and edit project data according to assigned project permissions. Publishing or marketplace permissions must be explicit. | |
| 45 | +| Viewer | Authorized read-only participant. | View project content allowed by visibility and project policy; cannot edit, publish, or manage collaborators. | |
| 46 | + |
| 47 | +## Project Ownership Rules |
| 48 | + |
| 49 | +- Every Project must have an Owner. |
| 50 | +- Projects may have Collaborators. |
| 51 | +- Projects may have Viewers. |
| 52 | +- Collaborator and Viewer access must be explicit. |
| 53 | +- Ownership transfer must be explicit and audited. |
| 54 | +- A Project Owner does not automatically own every external object referenced by the project. |
| 55 | +- Project-owned child objects inherit project ownership unless the object model explicitly promotes separate ownership. |
| 56 | + |
| 57 | +## Project Visibility |
| 58 | + |
| 59 | +| Visibility | Meaning | Discovery | |
| 60 | +| --- | --- | --- | |
| 61 | +| Private | Visible only to the Owner and explicitly authorized participants. | Not discoverable. | |
| 62 | +| Project | Visible to project participants according to project permissions. | Not public; discoverable only inside the project context. | |
| 63 | +| Unlisted | Accessible by explicit link or direct association when policy allows. | Not listed in public discovery. | |
| 64 | +| Public | Visible and discoverable to public users. | Discoverable through public platform surfaces. | |
| 65 | + |
| 66 | +## Project Visibility Rules |
| 67 | + |
| 68 | +- Every shareable Project must have an explicit visibility value. |
| 69 | +- Visibility must not be inferred from missing data. |
| 70 | +- Private projects must not expose child objects through public links unless those child objects are separately shared and policy allows it. |
| 71 | +- Public visibility applies to the project surface, not automatically to every working Tool State, Asset, Palette, or internal record. |
| 72 | +- Marketplace visibility is not a Project visibility mode; it is a produced listing/content state that depends on Marketplace Item records. |
| 73 | + |
| 74 | +## Project Relationships |
| 75 | + |
| 76 | +Project relationships define how platform objects attach to or derive from a Project. |
| 77 | + |
| 78 | +Required relationship categories: |
| 79 | +- Tool States |
| 80 | +- Assets |
| 81 | +- Palettes |
| 82 | +- Game Manifest |
| 83 | +- Releases |
| 84 | +- Marketplace Items |
| 85 | + |
| 86 | +Relationship rules: |
| 87 | +- Project -> contains Tool States. |
| 88 | +- Project -> contains Assets. |
| 89 | +- Project -> contains Palettes. |
| 90 | +- Project -> contains Game Manifest. |
| 91 | +- Project -> may produce Releases. |
| 92 | +- Project -> may produce Marketplace content. |
| 93 | + |
| 94 | +## Relationship Model |
| 95 | + |
| 96 | +| Relationship | Ownership | Lifecycle Behavior | Export Behavior | |
| 97 | +| --- | --- | --- | --- | |
| 98 | +| Project -> Tool States | Project-owned unless explicitly promoted. | Tool States follow project state for editability; Archived or Retired projects limit editing. | Exportable as toolState JSON when permissions allow. | |
| 99 | +| Project -> Assets | Project-owned by default, with possible external references. | Assets remain attached through Draft, Active, Archived, Published, Marketplace, and Retired states unless removed or rights change. | Exportable as allowed asset files, metadata JSON, or project package entries. | |
| 100 | +| Project -> Palettes | Project-owned or asset-linked. | Palettes can support tool states, assets, and manifests across project states. | Exportable as palette JSON and manifest/project dependencies. | |
| 101 | +| Project -> Game Manifest | Project-owned working game definition. | Game Manifest becomes release input when publishing begins. | Exportable as the portable game configuration format. | |
| 102 | +| Project -> Releases | Derived from Project and Game Manifest. | Releases should be immutable or versioned snapshots once published. | Exportable as release metadata plus manifest/package data when rights allow. | |
| 103 | +| Project -> Marketplace Items | Derived from Project, Assets, Game Manifest, Release, or Community Content. | Marketplace Items require listing visibility, moderation, and rights checks. | Exportable as listing metadata and allowed item references. | |
| 104 | + |
| 105 | +## State And Relationship Expectations |
| 106 | + |
| 107 | +Draft: |
| 108 | +- May contain Tool States, Assets, Palettes, and a Game Manifest. |
| 109 | +- Should not produce Releases or Marketplace Items by default. |
| 110 | + |
| 111 | +Active: |
| 112 | +- May contain editable Tool States, Assets, Palettes, and a Game Manifest. |
| 113 | +- May prepare Releases. |
| 114 | +- May prepare Marketplace content. |
| 115 | + |
| 116 | +Archived: |
| 117 | +- Retains Tool States, Assets, Palettes, Game Manifest, Releases, and Marketplace Items. |
| 118 | +- Editing is limited until restored to Active. |
| 119 | + |
| 120 | +Published: |
| 121 | +- Must have produced at least one Release. |
| 122 | +- May continue editing the working Project while preserving release snapshots. |
| 123 | + |
| 124 | +Marketplace: |
| 125 | +- Must have produced Marketplace content or an approved Marketplace Item. |
| 126 | +- May also be Published. |
| 127 | +- Marketplace listing state should not replace Project visibility. |
| 128 | + |
| 129 | +Retired: |
| 130 | +- Retains historical relationships. |
| 131 | +- Should restrict editing and public discovery unless policy allows historical visibility. |
| 132 | + |
| 133 | +## Database And Export Direction |
| 134 | + |
| 135 | +Database behavior: |
| 136 | +- The database is the working system for Project records, ownership, visibility, permissions, state, and relationships. |
| 137 | +- The database should track state transitions and relationship changes explicitly. |
| 138 | + |
| 139 | +Portable format behavior: |
| 140 | +- Manifest/JSON remains the portable export/import format. |
| 141 | +- Project exports should include portable Tool States, Assets, Palettes, Game Manifest data, Release metadata, and Marketplace metadata only when permissions and rights allow. |
| 142 | +- Project imports should create new ownership under the importing user or project context. |
| 143 | +- Imports must not assume original database ids. |
| 144 | + |
| 145 | +## Non-Goals |
| 146 | + |
| 147 | +This document does not: |
| 148 | +- define SQL schema |
| 149 | +- define API routes |
| 150 | +- implement project persistence |
| 151 | +- implement authentication |
| 152 | +- implement authorization checks |
| 153 | +- implement Admin pages |
| 154 | +- implement Account pages |
| 155 | +- implement publishing |
| 156 | +- implement marketplace behavior |
| 157 | +- change runtime behavior |
| 158 | +- change CSS, HTML, JavaScript, TypeScript, or JSON files |
0 commit comments