Skip to content

✨ Make project discovery and upload destinations explicit - #395

Merged
Robdel12 merged 1 commit into
mainfrom
rd/project-discovery-ux
Nov 4, 2026
Merged

Robdel12 merged 1 commit into
mainfrom
rd/project-discovery-ux

Conversation

@Robdel12

@Robdel12 Robdel12 commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

Why

Finding a project and reading its builds could use different credentials. A checkout's upload token could hide projects available to the signed-in user, and expired saved access tokens were discarded before refresh could recover the session. This made account browsing look like it required relinking the checkout.

Approach

Keep account browsing separate from the checkout's upload destination. Cloud reads share explicit --auth auto|user|token selection, report credential scope, and recover the selected saved login with one refresh budget. Explicit token settings now take precedence consistently in organization and project discovery. Raw API writes remain unreplayed; review decisions retain their existing retry with an unchanged, server-deduplicated command ID.

project link offers a paged project picker that guided setup also uses. project status distinguishes the configured project from the effective token destination, and run/upload verify that destination before creating a build or sending screenshots. Browsing another project leaves the upload binding unchanged.

Discovery and build lists consume the current SDK meta contract while preserving CLI JSON pagination and the 250-result cap through bounded API pages. Baseline build selection uses that same contract. Help and documentation connect discovery, scoped browsing, and upload setup.

Evidence

Built CLI and real-terminal workflows cover account browsing across projects, pagination beyond 50 results, refresh success/rejection/server failure, picker cancellation, unchanged bindings, wrong-destination rejection, and token-only CI uploads. Review coverage follows actual CLI outcomes instead of mocked internal calls.

The full suite passed with 1,917 tests passing and six skipped. Build, architecture, lint, formatting, and published type checks also passed.

Keep account reads independent of checkout upload credentials, recover saved
user sessions, and make project discovery and destination selection explicit.
Verify upload targets before cloud writes and exercise the workflows through
the built CLI and real terminal prompts.
@vizzly-testing

vizzly-testing Bot commented Nov 3, 2026

Copy link
Copy Markdown

Vizzly - Visual Test Results

CLI Reporter - Waiting for build

No builds received yet for this pull request.

CLI TUI - 3 changes need review
Result Count Review
Meaningful diffs 3 Required - inspect changed screenshots
Meaningful diffs needing review (3)

vizzly-invalid-command · 1202×578 · 1.5% diff

vizzly-invalid-command

vizzly-help · 1202×1430 · 0.6% diff

vizzly-help

vizzly-tdd-help · 1202×578 · 1.5% diff

vizzly-tdd-help

Review changes


rd/project-discovery-ux · 5ee0c040

@Robdel12
Robdel12 merged commit c5c43ce into main Nov 4, 2026
29 of 30 checks passed
@Robdel12
Robdel12 deleted the rd/project-discovery-ux branch November 4, 2026 06:42
Robdel12 added a commit that referenced this pull request Nov 4, 2026
Builds on the project discovery work merged in #395.

## Why

Signing in should be enough to use Vizzly within the permissions the
user grants. Requiring another project credential for uploads made a
valid login feel incomplete, while shared refresh state could make
simultaneous CLI processes invalidate one another.

## Approach

Save consented sessions by API origin, use native credential storage
where available, and coordinate refresh across processes before
rereading the saved successor. Persist refresh uncertainty before
rotation so a dropped response, process exit, or failed save cannot
cause a later command to replay a consumed token. Login supports
explicit scope requests and headless terminals; whoami and permission
errors report the actual grant. Selected-user failures never switch
identities, while explicit CI tokens remain authoritative.

Project linking now saves the checkout destination without minting
credentials. The same selected session reaches uploads, run screenshot
forwarding, finalization, previews, and reporter cloud reads through
supported SDK routes. Build-only uploads work without read permission,
and submitted generic writes are not replayed after authentication
failures.

## Evidence

The full CLI suite passed 1,884 tests with six skips; the reporter
browser suite passed 98 journeys with two skips. Build, published types,
lint, formatting, and architecture checks passed. Additional local
end-to-end verification used the real API for browser-approved login,
four concurrent CLI processes sharing one refresh, user/token build
attribution, read-only rejection before writes, a build-only run with
screenshot forwarding and finalization, isolated logout, and a committed
refresh with a dropped response whose successor remains valid because
the later CLI process refuses replay. The production review also covers
durable uncertain-refresh recovery through real HTTP, disk reload, and
fresh CLI processes. Review covered process-owner death, repeated expiry
windows, lock collisions, bounded authentication requests, and safe JSON
projections.

## Rollout

Release alongside the scoped-session API contract. Existing generic
logins require one fresh browser consent; they are not silently
upgraded. Project-token CI remains supported. Custom VIZZLY_HOME
directories use isolated credential files by default. The duplicate
authentication guide is removed; the README and command help retain the
user workflow.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant