Web UI: Project registry and onboarding model #427

Closed
opened 2026-07-07 12:21:00 -05:00 by jcwalker3 · 1 comment
Owner

Problem statement

Project onboarding metadata (repo, remotes, profiles, workflow paths) is implicit in docs and operator memory. The web UI needs a structured registry to onboard repositories consistently.

Scope

Add project/repository onboarding data model and UI page:

  • registry schema for projects the control plane manages
  • fields for repo identity, remotes, branches, local checkout paths
  • author/reviewer/reconciler profile mapping
  • workflow/schema path references
  • onboarding checklist UI

Acceptance criteria

  • Registry records: repo name, Gitea owner/org, remote host, default branch, local checkout path
  • Registry records author, reviewer, and reconciler profile names per project
  • Registry records canonical workflow and schema paths for the project
  • Gitea-Tools is seeded as the first registry entry
  • Onboarding checklist page walks required setup steps (profiles, MCP config, wiki gate, branches layout)
  • Data loads from a versioned config file or generated manifest (not hard-coded only in UI)

Non-goals

  • Auto-discovering every repo in an org without operator input
  • Storing tokens or credentials in the registry
  • Performing onboarding mutations (install deps, edit profiles) from the UI in MVP

Relation to tracker

Child of tracker #425. Implements one slice of the MCP Control Plane internal web UI. Does not duplicate backend policy already enforced by MCP tools/workflows.

Dependencies

Depends on #426 (server skeleton + /projects route).

Notes

Registry file should live in-repo or in operator config outside git; document the chosen location.

## Problem statement Project onboarding metadata (repo, remotes, profiles, workflow paths) is implicit in docs and operator memory. The web UI needs a structured registry to onboard repositories consistently. ## Scope Add project/repository onboarding data model and UI page: - registry schema for projects the control plane manages - fields for repo identity, remotes, branches, local checkout paths - author/reviewer/reconciler profile mapping - workflow/schema path references - onboarding checklist UI ## Acceptance criteria - Registry records: repo name, Gitea owner/org, remote host, default branch, local checkout path - Registry records author, reviewer, and reconciler profile names per project - Registry records canonical workflow and schema paths for the project - `Gitea-Tools` is seeded as the first registry entry - Onboarding checklist page walks required setup steps (profiles, MCP config, wiki gate, branches layout) - Data loads from a versioned config file or generated manifest (not hard-coded only in UI) ## Non-goals - Auto-discovering every repo in an org without operator input - Storing tokens or credentials in the registry - Performing onboarding mutations (install deps, edit profiles) from the UI in MVP ## Relation to tracker Child of tracker #425. Implements one slice of the MCP Control Plane internal web UI. Does not duplicate backend policy already enforced by MCP tools/workflows. ## Dependencies Depends on #426 (server skeleton + `/projects` route). ## Notes Registry file should live in-repo or in operator config outside git; document the chosen location.
jcwalker3 added the status:in-progress label 2026-07-07 12:26:23 -05:00
Author
Owner

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #427 - branch: feat/issue-427-project-registry - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation
sysadmin removed the status:in-progress label 2026-07-07 13:48:09 -05:00
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#427