Management for projects with different types

[nighca]

Summary

Add an initial worklist document for issue #2802 to capture the implementation scope across frontend and backend.

Included

• summarize the issue and parent issue background
• list the current frontend and backend gaps
• break the work into implementation areas
• record validation steps, open questions, and suggested execution order

Refs #2802

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new markdown document that serves as a detailed worklist for issue #2802. The document aims to capture the full scope of work required to integrate an explicit project type field throughout the application, from backend storage and APIs to frontend models and user interfaces. It acts as a foundational planning resource to ensure a structured and comprehensive approach to this significant feature.

Highlights

• New Worklist Document Added: An initial worklist document for issue Management for projects with different types #2802 has been added, outlining the comprehensive plan for implementing project type management across the frontend and backend.
• Detailed Implementation Scope: The document provides a detailed breakdown of the implementation scope, covering data model, backend schema, API contracts, frontend types, metadata, project factory, creation flow, UI, import/export, compatibility, and testing.
• Identified Gaps and Open Questions: The worklist summarizes current frontend and backend gaps related to project types and lists open questions to be addressed during the implementation process.
• Suggested Execution Order: A suggested execution order is provided to guide the development team through the various stages of implementing project type functionality.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

[Copilot]

Pull request overview

Adds a dedicated worklist document for issue #2802 to capture current gaps and a proposed implementation plan spanning frontend and backend.

Changes:

• Introduce spx-gui/ISSUE-2802-worklist.md summarizing background, current state gaps, and a step-by-step checklist.
• Document validation steps, open questions, and a suggested execution order.
• Enumerate primary entry points across frontend and backend components.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[xgopilot]

Well-structured planning document with good coverage of both frontend and backend concerns. A few accuracy and placement issues noted via inline comments. The checklist is thorough, but the file location and naming diverge from project conventions.

[xgopilot]

cmd/spx-backend/xgo_autogen.go is missing the builder-backend-release/ prefix used for every other backend path in this section. Should be builder-backend-release/cmd/spx-backend/xgo_autogen.go.

[xgopilot]

Section 6 covers cloud and .xbp serialization but omits src/models/common/local.ts. The local (IndexedDB-backed) storage path spreads the full Metadata object into storage, so project type won't be persisted locally until it is added to Metadata. Neither a checklist item nor a test task covers this path, and it is missing from the Primary Entry Points list.

[xgopilot]

"Review any other places that directly instantiate SpxProject" understates the scope. There are at least four additional production call sites not listed here or in Primary Entry Points:

• src/components/copilot/CopilotRoot.vue
• src/components/agent-copilot/CopilotProvider.vue
• src/widgets/spx-runner/SpxRunner.ce.vue (two sites)
• src/models/spx/gen/sprite-gen.ts

CopilotProvider.vue and SpxRunner.ce.vue are high-impact integration points that will need explicit treatment.

[xgopilot]

Factually incorrect: docs/openapi.yaml exists in the repository. The question should be rephrased to address how and when the OpenAPI spec should be updated, and should also be added to the Suggested Execution Order (currently absent from all 8 steps).

[xgopilot]

All backend paths here omit the builder-backend-release/ prefix (e.g. internal/model/project.go), but every corresponding checklist item in sections 2–4 uses the full prefix. The abbreviated paths are not navigable as written and are inconsistent with the rest of the document. Also, two items to consider adding:

• src/models/common/local.ts (local storage path, see section 6 comment)
• docs/openapi.yaml (API contract document)

[xgopilot]

File placement — spx-gui/ is the frontend application directory; this document covers backend schema migrations, YAP endpoints, and controller logic that have no relation to that subtree. A cross-cutting planning document like this fits better under docs/develop/generalization/ (alongside the existing project.md for issue #2800). The ISSUE-NNNN- filename prefix is also inconsistent with every other file in the docs tree, which uses descriptive kebab-case names.

[xgopilot]

Inaccurate SpxProject location — The statement implies SpxProject is in src/models/project.ts, but the class lives in src/models/spx/project.ts. src/models/project.ts is the generic IProject abstraction. This distinction matters for implementers: the hard-coding to remove is in src/models/spx/project.ts and call-sites like src/components/project/index.ts, not in src/models/project.ts itself.

[xgopilot]

Backend path prefix is inconsistent and likely wrong — Every item in the backend checklist (sections 2–4) uses a builder-backend-release/ prefix (e.g., builder-backend-release/internal/model/project.go), but no such directory exists in this repository. The project's own documentation and docs/develop/database-migration/index.md consistently refer to spx-backend. The "Primary Entry Points" section drops the prefix entirely, making the two sections contradictory. Please use the correct module-relative path throughout.

[xgopilot]

Missing validation items for list-filter and remix paths — Section 3 validates projectType only in the create flow. Two additional items are needed:

1. List filter: projectType passed to ListProjects must be validated as a strict enum (allowlist lookup) before use in a SQL WHERE clause — never raw interpolation.
2. Remix: The backend must derive projectType from the source project record, not accept a client-supplied value. A client that specifies a different type during remix could load project content in the wrong runtime.

[xgopilot]

Missing cloud.ts item — src/models/common/cloud.ts handles cloud save/load serialization and must propagate projectType through parseProjectData() / save(). It is listed as a Primary Entry Point but has no corresponding checklist item in Section 6. This is as concrete a change as the xbp.ts items already listed.

[xgopilot]

.xbp deserialization: Object.assign merges all fields without validation — xbp.ts currently does Object.assign(metadata, m) for all content from builder-meta.json. Once projectType drives frontend runtime dispatch (Section 7), a crafted .xbp file that injects an unexpected projectType — or overrides other metadata fields like owner or id — becomes a meaningful attack surface. The checklist should explicitly require:

• Validate the deserialized projectType against the allowed enum before accepting it.
• Replace the blanket Object.assign with an explicit field-by-field merge that rejects unknown or unexpected keys.

[xgopilot]

docs/openapi.yaml does exist — The premise of this open question is incorrect; docs/openapi.yaml is present in the repository. The question should instead address whether the spec is hand-maintained or generated, and who owns the update. The projectType field should be defined there as a named ProjectType enum schema (same pattern as the existing Visibility enum), which also provides the machine-readable contract that drives backend validation.

[xgopilot]

Thorough and well-structured worklist. A few factual corrections to address before merging: the backend path prefix builder-backend-release/ doesn't match any directory in this repo (should align with spx-backend); SpxProject lives in src/models/spx/project.ts, not src/models/project.ts; and docs/openapi.yaml does exist. See inline comments for the remaining gaps.