fix: feat(project): add project type selector to create-project flow

[sriraajj-lab]

Solution for: feat(project): add project type selector to create-project flow

Addresses #74.

Changes:

• frontend/src/App.vue
• frontend/src/styles.css

Build Status:

• Frontend build verified
• No config files modified
• No CSS deletions
• SSR preserved

---

Generated by Hermes Bounty Solver V3 (Command Code + DeepSeek V4 Pro)

[TUPM96]

Thanks for the PR. For bounty review, please add verification evidence in this PR before final review:

• screenshot, GIF, or video showing the changed flow/UI
• the test/build command(s) you ran and the result
• any relevant edge cases or viewport sizes checked

Evidence can be attached in a PR comment; images in comments count. If this PR has the star: missing label, please also star this repository so bounty eligibility can be verified.

[xingxi0614-cpu]

QA verification for PR #107

Target PR: #107
Head commit checked: 90ce54898968092db5697dbd2083ba2955e89033
Author: sriraajj-lab
Linked bounty area: project creation flow / New Project vs existing bug-fix split

GitHub Actions

All visible PR checks are green at the time of review:

• Secret scan: success
• Backend build and test: success
• Web build and test (frontend): success
• Web build and test (admin): success
• Web build and test (scan): success

Merge state is clean.

Local checks

I checked out the PR head and ran the relevant frontend commands:

npm test
# 8/8 tests passed

npm run build:local
# client build passed
# SSR build passed

What the PR changes

The PR adds a new top-level selector with two choices:

• New project
• Fix bug in existing project

It stores that choice in a new projectSetupForm.projectPurpose field and sends it as project_type in buildCreateProjectPayload().

Blocking findings

1. The old project-type selector is still rendered underneath the new selector.

The bounty goal is to make the create-project flow clearly split new projects from existing bug fixes. This PR adds the new two-choice selector, but it leaves the existing six-choice projectTypeOptions selector in the same step.

Evidence:

frontend/src/App.vue

projectPurpose selector:
- New project
- Fix bug in existing project

projectTypeOptions still include:
- Web Development
- Repo Issue Fix
- Mobile Development
- AI / ML
- Smart Contract
- Other

This creates two overlapping classification fields instead of one clear split. A user can choose New project at the top and still choose Repo Issue Fix in the old selector below, or choose Fix bug in existing project and then choose AI / ML below.

2. The repo-import path still writes the old Repo Issue Fix value and does not set the new projectPurpose.

Evidence:

frontend/src/App.vue

async function loadRepoIssues() {
  ...
  if (repoImportedIssues.value.length) {
    projectSetupForm.projectType = 'Repo Issue Fix';
    ...
  }
}

So a successful repo import still updates the legacy projectType field, while the new projectPurpose field remains unchanged. That means the new two-choice state can be left empty even after the user takes the existing-repo bug-fix path.

3. The new field is only wired into one payload path.

The PR sends projectSetupForm.projectPurpose as project_type in buildCreateProjectPayload(), but other existing flows still read projectSetupForm.projectType, including project labels, AI evaluation payload, repo import state, and the project brief. This creates inconsistent downstream data about what kind of project the user selected.

Evidence status

Evidence is incomplete. The PR has green CI, but I do not see attached screenshots, GIF, or video showing the new two-choice flow, the old selector interaction, or the repo-import path. The maintainer has already requested runtime evidence in the PR.

Recommendation

Request changes / not ready for bounty acceptance.

The PR needs to make the new project/fix split the single source of truth, or clearly map it into the existing project type model. At minimum:

• remove or reconcile the old six-choice selector,
• set projectPurpose = 'fix' on successful repo import,
• ensure all payloads and labels use consistent project-type semantics,
• add runtime evidence for the New Project path and existing-repo Bug Fix path.

[TUPM96]

Not ready for bounty acceptance yet.

This introduces a separate projectPurpose field, but the existing projectType / repo-import behavior is not fully wired into the same taxonomy. The final payload can now send project_type as
ew / ix while site_type remains based on the older empty/projectType field, which creates inconsistent data for pricing and project creation.

Please unify this with the existing project type model, wire repo import to the Bug Fix path, and attach runtime evidence. Star eligibility is still missing too.

[TUPM96]

Thanks for the contribution and for moving this bounty forward. We accepted PR #109 for issue #12 after a small maintainer follow-up, and this PR is now superseded by the merged implementation on master. Closing to keep the queue clean. For the next bounty, please rebase on latest master and include clear runtime evidence/screenshots so review can move faster.