Feat/viz prefix

[DevOlabode]

closes #99

[ieliofficial]

I think the availability check and the create call disagree about the name now.

checkGitHubRepoNameAvailability normalizes but doesn't prefix, so it looks up owner/scans. createGitHubRepository calls applyVizablyRepoPrefix, so it creates owner/viz_scans. ConnectView sends the unprefixed suffix to the check.

Two ways that bites, and the default name is now "scans" so it's easy to hit:

• someone already has a repo called "scans" and gets told the name is taken, even though viz_scans is free
• someone already has viz_scans from an earlier run, gets told it's available, then create fails with a 422

Interesting bit is that findRepoByName in that same effect does check both the prefixed and unprefixed name, so the client side already handles it. It's just the server round trip that misses.

Could we apply the prefix inside checkGitHubRepoNameAvailability? That way the endpoint is consistent by itself instead of relying on the frontend to prefix first.

The prefix helper itself looks right, I checked the idempotency and casing paths.

[DevOlabode]

Both check and create already share _normalizeGitHubRepoName → applyVizablyRepoPrefix (b850685), so the availability lookup targets owner/viz_scans for an unprefixed scans input — same as create. Tests cover that.

[ieliofficial]

Availability check is fine, you were right, tests cover it.

Changing the ask. We want a deterministic name, not a prefix-only on a name people type. Vizably picks where storage goes so a second device finds the same store with no input.

• fixed name, same for every account
• fallback when it's taken: viz_scans, viz_scans-2, viz_scans-3
• on load, find the account by scanning the user's repos for viz_* with a vizably.json, instead of asking
• keep it provider-neutral so the Drive folder reuses it

That means the Connect screen loses the name field and the "Use an existing repository" picker. It becomes one button. Right now it shows "Vizably account found, 9 saved scans" and "TAKEN" on the same screen, which is the confusion this removes.

Worth a quick call before you start, it's a bigger change than the branch is now. Rebase too, it conflicts with main.

[ieliofficial]

Instructions left in the #104 comment section.

[DevOlabode]

Should I proceed with implementing #116 (Use One GitHub Repository Per User) as part of this change before completing #104?

The latest feedback on #104 moves toward the same architecture described in #116 — a per-user repository, automatic repository discovery, and removing the manual repository/name selection flow.

I want to avoid completing the current #104 implementation and then immediately reworking the same code for #116. Would you prefer that I implement #116 first and then update/rebase this PR, or incorporate the #116 requirements directly into #104?

[ieliofficial]

Should I proceed with implementing #116 (Use One GitHub Repository Per User) as part of this change before completing #104?

The latest feedback on #104 moves toward the same architecture described in #116 — a per-user repository, automatic repository discovery, and removing the manual repository/name selection flow.

I want to avoid completing the current #104 implementation and then immediately reworking the same code for #116. Would you prefer that I implement #116 first and then update/rebase this PR, or incorporate the #116 requirements directly into #104?

Good call, but don't fold it into #104 or rebase it. Close #104 and #99 and start fresh on #116. Only thing worth carrying over is shared/githubRepoName.js I believe.

One heads up: #116 as written says to handle selection through the existing flow, which keeps the picker. That's the opposite of what we want. I've put the decisions on #116, update the issue to match before you start.