feat(projects): make project network visibility (public/private) effective

[martian56]

Summary

Closes #197.

Choosing a project's network had no effect: Project.Network existed (default 2) but was never bound in create/update or used in listing/access, and the UI "Network" dropdown was wired to the unrelated guest_view_all_features flag.

Backend

• network is now bound in project create and update and validated (must be public = 2 or secret = 0, else 400).
• Visibility is enforced:
  • List — ProjectStore.ListVisibleByWorkspaceID returns every public project plus the (public or secret) ones the user belongs to; workspace admins/owners still see everything.
  • GetByID — a secret project returns 404 to a workspace member who isn't a project member (and isn't a workspace admin).
• Existing projects default to public, so their visibility is unchanged.

Frontend

• The settings and create-project "Network" dropdowns now read from and write to the real network field (public → 2, secret → 0) instead of conflating it with guest_view_all_features.

Testing

• go vet ./... passes; project + issue handler test suites pass (no regression from the GetByID change).
• handler_test.TestProject_NetworkVisibility drives the full HTTP stack: a public project is visible/openable to a non-member workspace member; after switching it to secret, that user no longer sees it in the list and gets 404 on GetByID, while a project member still sees and opens it; restoring to public re-shows it; an out-of-range network value is rejected 400.
• Frontend typecheck + lint + format:check pass. Note: a live in-browser click-through was blocked this session (the browser tool was disconnected and the local dev session had expired), so the end-to-end coverage here is the HTTP-level integration test above.

AI assistance

Produced with the help of Claude Code (Claude Opus 4.8). See the Co-Authored-By trailer on the commit.

Summary by CodeRabbit

• New Features

  • Added project visibility controls with public and secret network settings.
  • Project lists and detail access now respect visibility for workspace members and non-members.

• Bug Fixes

  • Secret projects are now hidden from unauthorized users and return a not-found response on direct access.
  • Invalid network values now return a clear bad request error.

• UI Updates

  • Project creation and settings screens now let you set and update project visibility.
  • Project data returned by the app now includes the saved visibility setting.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

apps/api/internal/store/project.go (1)

58-71: 🚀 Performance & Scalability | 🔵 Trivial

Consider adding database indexes for ListVisibleByWorkspaceID.

The query filters on projects.workspace_id + projects.network and uses a subquery on project_members.member_id. For workspaces with many projects, a composite index on projects(workspace_id, network) and an index on project_members(member_id, deleted_at) would improve listing performance.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/api/internal/store/project.go` around lines 58 - 71, Add the missing
database indexes for ProjectStore.ListVisibleByWorkspaceID: the query in
ListVisibleByWorkspaceID filters on projects.workspace_id and projects.network,
and the subquery on model.ProjectMember filters by member_id plus deleted_at.
Update the relevant model/migration definitions for model.Project and
model.ProjectMember to include a composite index on workspace_id, network and an
index on member_id, deleted_at so the workspace project listing stays fast.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/api/internal/handler/project.go`:
- Line 98: The Create flow in ProjectHandler currently creates the project
before validating body.Network, which can leave behind a default project when
Update later returns ErrInvalidNetwork. Move the network validation into the
Create handler before the h.Project.Create call, using the same validation path
used by Update/ErrInvalidNetwork handling so invalid input is rejected early
with no side effects. Keep the change localized around the ProjectHandler.Create
and Update validation logic so the network field is checked before any project
is persisted.

---

Nitpick comments:
In `@apps/api/internal/store/project.go`:
- Around line 58-71: Add the missing database indexes for
ProjectStore.ListVisibleByWorkspaceID: the query in ListVisibleByWorkspaceID
filters on projects.workspace_id and projects.network, and the subquery on
model.ProjectMember filters by member_id plus deleted_at. Update the relevant
model/migration definitions for model.Project and model.ProjectMember to include
a composite index on workspace_id, network and an index on member_id, deleted_at
so the workspace project listing stays fast.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: d3fe2c55-054c-4e07-8653-c07eadfcdb7e

📥 Commits

Reviewing files that changed from the base of the PR and between 4bf962a and 4e3d8e6.

📒 Files selected for processing (9)

• apps/api/internal/handler/project.go
• apps/api/internal/handler/project_network_test.go
• apps/api/internal/model/project.go
• apps/api/internal/service/project.go
• apps/api/internal/store/project.go
• apps/web/src/api/types.ts
• apps/web/src/components/CreateProjectModal.tsx
• apps/web/src/pages/SettingsPage.tsx
• apps/web/src/services/projectService.ts