[charlesrhoward]

Follow-up to #167, covering the points its final review raised after it merged.

The coverage page and the repo-sync page disagreed about whether old OAuth-only rows come back in Projects. They do in one case: visibleScopedRepos in the app shows every repo while none of them has an installation id. The repo-sync page promised they never return. Both pages now describe that fallback.

The setup-state table in the project workflow guide now uses the status labels Settings → Account shows (Not connected, OAuth only, Install pending, App installed, Ready), taken from deriveGithubState.

The first-run steps on the docs home page and on Projects asked readers to confirm App coverage that a new account does not have yet. They now say to install the App on the owner, confirm the link under Settings → Account, and note that org members who are not owners use team-shared repos.

The review also asked about an "Installed scopes" heading. That text does not appear in the docs on main, so nothing changed for it.

No-tests: wording-only docs change; the existing link and navigation tests cover the touched pages.

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
mogplex-docs	Ready	Preview	Nov 9, 2026 11:16am UTC

[mogplex]

Mogplex PR Review

Status: No material issues found

Docs-only wording change that does what the description claims: the Projects fallback is now described consistently on the coverage and repo-sync pages, the setup-state table uses the Settings → Account labels, and the first-run steps no longer ask new accounts to confirm App coverage. No blockers; a few cross-page consistency gaps remain for later passes.

Affected files

• content/docs/index.mdx
• content/docs/web/guides/project-workflow.mdx
• content/docs/web/installations/coverage-and-triggerability.mdx
• content/docs/web/installations/repo-sync-and-rebinding.mdx
• content/docs/web/spaces.mdx

Suggestions

• App installed row still implies Projects is always installation-filtered (content/docs/web/guides/project-workflow.mdx:L39)
  The rewritten row keeps "Repos will not show up in Projects until they are synced or imported" as the "does not unlock yet" column. That is exactly the window this PR now documents as the fallback case: while none of your repos has an installation id, Projects shows every repo, including older rows without coverage. A reader in App installed is likely to see repos in Projects and conclude the docs are wrong.

  Suggest softening it to something like "Covered repos are not yet synced, so Projects may still be showing older OAuth-only rows" and linking the Coverage and Triggerability fallback paragraph.

• Label parity claim is not yet true on the coverage page (content/docs/web/guides/project-workflow.mdx:L31)
  This line now promises "The state names match the GitHub status shown in Settings → Account" and lists five labels, but content/docs/web/installations/coverage-and-triggerability.mdx (the page that owns "User-level GitHub state") still lists only four — OAuth only, Install pending, App installed, Ready — with no Not connected. Since the goal of this PR is exactly that alignment, adding the Not connected row there (or explicitly saying the list is a subset) would close the loop.

• Section 4 still states the filter as absolute (content/docs/web/guides/project-workflow.mdx)
  Under "4. Import or create repos", the bullet "Once installation-backed sync is active, Projects lists only repos covered by a linked installation, which hides stale Synced only rows" has no pointer to the fallback this PR is standardising. It is defensible as written, but this page is where the setup-interpretation happens, so a one-clause qualifier ("once at least one repo carries an installation id") or a link to the coverage page would prevent the same confusion that motivated the PR.

• First-run step asks readers to confirm a link without naming the surface (content/docs/index.mdx)
  The new step tells readers to "confirm the installation is linked to you under Settings → Account", but content/docs/web/installations/index.mdx is the page that tells them to look for the Installed scopes block on that page. Naming Installed scopes here (as the Installations overview already does) makes the check verifiable rather than a vague glance at Settings. The same three-line paragraph is duplicated verbatim in content/docs/web/spaces.mdx; if you would rather not maintain it twice, point that page at the Project Workflow guide instead.

• PR description says the "Installed scopes" text is absent, but it exists (content/docs/web/installations/index.mdx)
  The description closes out the earlier review note with "That text does not appear in the docs on main". It is not a heading, but content/docs/web/installations/index.mdx does use Installed scopes as a label in "The most reliable workflow", and it is the surface the new first-run step is really asking about. Worth re-checking the original comment before treating that point as resolved; if the concern was really about naming, a short mention of Installed scopes in the new first-run text settles it.

View check run

[charlesrhoward]

The review passed with no warnings, so this merges. On the suggestions:

• Installed scopes: I re-checked. grep -rn "Installed scopes" content on this branch finds nothing, and the app has no such label either (Settings → Account titles the section "GitHub" since mogplex#723). Nothing to name.
• The App installed row and the section 4 bullet: fair points. Both describe the usual state rather than the short window before the first sync. I'll fold a pointer to the fallback paragraph into the next docs pass instead of opening another round here.
• Not connected on the coverage page: that table lists states after a connection exists. Not connected is defined in the project-workflow table.