Skip to content

Commit f85ad69

Browse files
ToolboxAidToolboxAid
committed
Create post migration platform roadmap for GameFoundryStudio - PR_26152_062-post-migration-platform-roadmap
1 parent 204989b commit f85ad69

2 files changed

Lines changed: 260 additions & 0 deletions

File tree

‎docs/dev/reports/post_migration_platform_roadmap_validation.md‎

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
# PR_26152_062 Post-Migration Platform Roadmap Validation
2+
3+
## Scope
4+
5+
Docs-only planning update.
6+
7+
Changed:
8+
- `docs/dev/roadmaps/POST_MIGRATION_PLATFORM_ROADMAP.md`
9+
10+
No runtime files, page files, CSS files, Theme V2 CSS files, JavaScript files, TypeScript files, JSON files, Admin pages, Account pages, Samples, or GameFoundryStudio pages were changed.
11+
12+
## Validation
13+
14+
Playwright impacted: No. This PR is documentation/planning only.
15+
16+
Lanes executed:
17+
- contract documentation/static validation - because this PR only creates a planning roadmap document.
18+
19+
Lanes skipped:
20+
- runtime, integration, engine, samples, recovery/UAT - no runtime, handoff, engine, sample, or recovery behavior changed.
21+
22+
Samples decision: SKIP because samples migration is explicitly deferred and no Samples files changed.
23+
24+
Commands:
25+
- Inline Node validation for required roadmap content.
26+
- `git diff --check -- docs/dev/roadmaps/POST_MIGRATION_PLATFORM_ROADMAP.md`
27+
- `git status --short -uall`
28+
- `git diff --name-only -- "*.css" "*.html" "*.js" "*.ts" "*.json"`
29+
30+
Results:
31+
- PASS: Post-Migration Platform Roadmap document exists.
32+
- PASS: Migration lane completion statement exists.
33+
- PASS: Phase 1 documents Users, Authentication, Profiles.
34+
- PASS: Phase 2 documents Roles, Permissions, Visibility.
35+
- PASS: Phase 3 documents Projects.
36+
- PASS: Phase 4 documents Tool State Persistence, including Vector Studio, Palette Manager, and Asset tools.
37+
- PASS: Phase 5 documents Asset Database.
38+
- PASS: Phase 6 documents Manifest Database.
39+
- PASS: Phase 7 documents Publishing.
40+
- PASS: Phase 8 documents Community.
41+
- PASS: Phase 9 documents Marketplace.
42+
- PASS: Phase 10 documents Config-Driven Games.
43+
- PASS: Database Direction documents Node.js, TypeScript, and PostgreSQL.
44+
- PASS: Manifest Direction documents Database = working system and Manifest = portable export/import format.
45+
- PASS: Deferred section documents Samples migration, Admin implementation, and Account implementation.
46+
- PASS: No CSS files changed.
47+
- PASS: No HTML/page files changed.
48+
- PASS: No JavaScript, TypeScript, or JSON files changed.
49+
- PASS: No repo-wide tests were run.
50+
- PASS: No tests outside GameFoundryStudio were run.
51+
52+
Expected PASS behavior:
53+
- Reviewers can use the roadmap as a post-migration planning document without any runtime or page behavior changes.
54+
55+
Expected WARN behavior:
56+
- Existing repository roadmap governance still treats `docs/dev/roadmaps/MASTER_ROADMAP_ENGINE.md` as the operational master roadmap. This PR adds a requested planning artifact and does not edit existing roadmap status.

‎docs/dev/roadmaps/POST_MIGRATION_PLATFORM_ROADMAP.md‎

Lines changed: 204 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,204 @@
1+
# Post-Migration Platform Roadmap
2+
3+
## Status
4+
5+
The public/root migration lane is considered complete for current planning purposes.
6+
7+
This roadmap is a planning document only. It does not authorize runtime changes, page changes, CSS changes, database implementation, authentication implementation, Admin implementation, Account implementation, or sample migration.
8+
9+
## Direction
10+
11+
GameFoundryStudio now needs to move from static public/root migration recovery into platform capability planning. The next work should prioritize durable platform foundations before deeper creator, publishing, marketplace, and config-driven game features.
12+
13+
## Phase 1 - Users, Authentication, Profiles
14+
15+
Purpose:
16+
- Establish the user identity foundation for the platform.
17+
18+
Planned scope:
19+
- Users
20+
- Authentication
21+
- Profiles
22+
23+
Notes:
24+
- This phase should define user records, sign-in/out behavior, profile ownership, and public/private profile boundaries before role or project work begins.
25+
26+
## Phase 2 - Roles, Permissions, Visibility
27+
28+
Purpose:
29+
- Define who can see, edit, publish, moderate, and administer platform resources.
30+
31+
Planned scope:
32+
- Roles
33+
- Permissions
34+
- Visibility
35+
36+
Notes:
37+
- Visibility rules should be documented before they are attached to projects, assets, manifests, publishing, community, or marketplace surfaces.
38+
39+
## Phase 3 - Projects
40+
41+
Purpose:
42+
- Introduce project-level ownership and organization.
43+
44+
Planned scope:
45+
- Project records
46+
- Project metadata
47+
- Project ownership
48+
- Project visibility
49+
- Project-to-tool relationships
50+
51+
Notes:
52+
- Projects should become the organizing layer between users and creator tool outputs.
53+
54+
## Phase 4 - Tool State Persistence
55+
56+
Purpose:
57+
- Persist creator tool work in the platform database while keeping export/import portable.
58+
59+
Planned scope:
60+
- Vector Studio
61+
- Palette Manager
62+
- Asset tools
63+
64+
Notes:
65+
- Tool state persistence should preserve the existing toolState terminology.
66+
- Persistence should not imply hidden fallback state.
67+
- Saved state should be owned by a project and user once those foundations exist.
68+
69+
## Phase 5 - Asset Database
70+
71+
Purpose:
72+
- Store reusable assets as first-class platform records.
73+
74+
Planned scope:
75+
- Asset records
76+
- Asset metadata
77+
- Asset ownership
78+
- Asset visibility
79+
- Asset usage relationships
80+
81+
Notes:
82+
- Asset database work should build on users, roles, projects, and tool state persistence rather than bypassing them.
83+
84+
## Phase 6 - Manifest Database
85+
86+
Purpose:
87+
- Store working game manifests as database-backed platform records.
88+
89+
Planned scope:
90+
- Manifest records
91+
- Manifest versions
92+
- Manifest ownership
93+
- Manifest validation status
94+
- Manifest export/import readiness
95+
96+
Notes:
97+
- Manifest database work should support the existing manifest contract instead of replacing portable manifests.
98+
99+
## Phase 7 - Publishing
100+
101+
Purpose:
102+
- Turn validated projects and manifests into release-ready game outputs.
103+
104+
Planned scope:
105+
- Publishing workflow
106+
- Release records
107+
- Release visibility
108+
- Publish validation
109+
- Creator-facing release status
110+
111+
Notes:
112+
- Publishing should depend on manifest validation, asset readiness, ownership, and visibility.
113+
114+
## Phase 8 - Community
115+
116+
Purpose:
117+
- Add community surfaces after identity, visibility, projects, assets, manifests, and publishing are established.
118+
119+
Planned scope:
120+
- Creator discovery
121+
- Community profiles
122+
- Sharing surfaces
123+
- Feedback and moderation planning
124+
125+
Notes:
126+
- Community work should respect roles, permissions, and visibility rules from earlier phases.
127+
128+
## Phase 9 - Marketplace
129+
130+
Purpose:
131+
- Enable discoverable asset, template, game, and creator resources.
132+
133+
Planned scope:
134+
- Marketplace listings
135+
- Listing ownership
136+
- Listing visibility
137+
- Listing metadata
138+
- Marketplace moderation planning
139+
140+
Notes:
141+
- Marketplace should build on assets, manifests, publishing, community, and permissions rather than becoming a separate data model.
142+
143+
## Phase 10 - Config-Driven Games
144+
145+
Purpose:
146+
- Advance the zero-code direction where game behavior is driven by configuration, manifests, and reusable systems.
147+
148+
Planned scope:
149+
- Config-driven game records
150+
- Runtime-ready manifest relationships
151+
- Game configuration validation
152+
- Project-to-game publishing paths
153+
154+
Notes:
155+
- Config-driven game work should keep manifest validation, portable exports, and database-backed working state aligned.
156+
157+
## Database Direction
158+
159+
Approved planning direction:
160+
- Node.js
161+
- TypeScript
162+
- PostgreSQL
163+
164+
Notes:
165+
- Node.js and TypeScript should own application/server implementation direction.
166+
- PostgreSQL should own relational platform data persistence direction.
167+
- Database implementation is deferred until an explicit implementation PR.
168+
169+
## Manifest Direction
170+
171+
Planning rule:
172+
- Database = working system
173+
- Manifest = portable export/import format
174+
175+
Meaning:
176+
- The platform database should store working records, ownership, visibility, versioning, status, and relationships.
177+
- Manifests should remain portable artifacts for export, import, validation, sharing, and runtime handoff.
178+
- The database should not make manifests obsolete.
179+
- Manifest export/import should remain a deliberate capability, not an accidental copy of hidden database state.
180+
181+
## Deferred
182+
183+
Deferred lanes:
184+
- Samples migration
185+
- Admin implementation
186+
- Account implementation
187+
188+
Notes:
189+
- Samples migration remains deferred until a dedicated sample-alignment scope is named.
190+
- Admin implementation remains deferred until database, authentication, roles, permissions, and visibility foundations are planned or implemented.
191+
- Account implementation remains deferred until users, authentication, and profiles are in scope.
192+
193+
## Non-Goals For This Document
194+
195+
This document does not:
196+
- implement database code
197+
- implement login or authentication
198+
- implement Admin pages
199+
- implement Account pages
200+
- migrate Samples
201+
- change runtime behavior
202+
- change page behavior
203+
- change CSS or Theme V2 CSS
204+
- change existing manifests or toolState payloads

0 commit comments

Comments
 (0)