feat(plugins): improve install review and show live progress

[dviejokfs]

Plugin installation now has a dedicated review page with compact source/version/build badges, an explicit required/optional permission checklist, and live host-reported installation stages. Browsing the catalog and managing running plugins use separate tabs.

The install page keeps completed steps and failures visible instead of showing only a disabled button. Stages cover source fetching, builder preparation, dependencies, target runtime, compilation, binary extraction, startup, and promotion. Success stays on the page with a View plugins action.

Permission metadata is optional for backward compatibility: known metadata shows the plugin's declared requirements and reasons; legacy entries show the full permission list. All grants still require explicit approval. Registry metadata does not override runtime permission enforcement.

Registry permission metadata was published separately in gotempsh/plugins#7, with Site Crawl requirements in gotempsh/temps-plugin-site-crawl#2.

Progress polling requires a system administrator, uses a client UUID, returns static messages rather than subprocess output, and retains at most 64 records with finished records expiring after ten minutes or evicted oldest-first at capacity. Active records are never evicted; registration identities prevent stale handles from modifying a reused ID. A queued stage remains active while waiting for the lifecycle lock. Existing synchronous installs remain compatible.

Evidence

• bun test src/components/plugins src/lib/plugin-repository.test.ts src/pages/settings/PluginsPage.test.tsx: 46 passed, 0 failed on the rebased branch.
• bunx playwright test --config /tmp/plugin-source-playwright.config.mts: 6 passed against the production web bundle with a real local session. Tests cover dedicated-page navigation, pinned revisions, explicit required permission approval, update refs, and progress success/failure retention. Plugin install/progress responses are mocked in these browser tests.
• Browser walkthrough on local port 3029: submitted a custom repository with mocked installation endpoints; observed completed source/builder stages and an active dependencies stage with elapsed times. Inspected desktop and 390px mobile rendering.
• Live isolated API: an install against a synthetic nonexistent GitHub repository returned 502. Polling observed fetching_source/running followed by fetching_source/failed in 647ms. Unauthenticated progress polling returned 401. No plugin or grants were created by this check.
• cargo test --lib -p temps-external-plugins install_progress::tests: 6 passed.
• cargo test --lib -p temps-external-plugins repository_install_preparation_validates_before_reserving_progress: 1 passed, verifies service-owned validation before reservation plus duplicate/full capacity and untracked compatibility.
• cargo test --lib -p temps-external-plugins repository_install_reports_actual_lifecycle_wait: 1 passed, exercises a contested lock.
• cargo test --lib -p temps-external-plugins repository_progress_id_is_camel_case_and_registered_in_openapi: 1 passed.
• cargo test --lib -p temps-external-plugins permission_metadata: 2 passed.
• Affected Rust crate cargo check --lib and Clippy with -D warnings: passed. Web TypeScript, targeted ESLint, and production build passed.
• Independent security reviews of permission metadata and progress polling: PASS.

Limitations

A complete successful native installation with these new progress stages has not been demonstrated locally. The success UI is covered with mocked responses; earlier local Docker builds encountered external dependency network timeouts. The broad external-plugin suite was stopped after 120 seconds without a result; focused tests passed. No paid AI-provider calls were made.

Native plugins execute with the host OS account's permissions. These controls protect host APIs; Docker isolates the build, not the running plugin. This PR includes no independent ESLint cleanup and does not claim that the entire web lint backlog passes.

[github-actions]

📓 Changelog preview

This is what your commits will add to the generated CHANGELOG.md at release time (via git-cliff). Do not edit CHANGELOG.md by hand — it is generated from your Conventional Commit messages.

## [Unreleased]

### Added

- **plugins:** Review permissions and show live installation progress

### Fixed

- **plugins:** Preserve install progress capacity and queued status

### Refactor

- **plugins:** Reserve installation progress through service

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge, with no new actionable issues found in the changes since the previous review.

Summary

This PR adds a dedicated plugin-install review experience, explicit permission approval, and administrator-only live installation progress while retaining compatibility with synchronous installs.

• Separates plugin catalog browsing from installed-plugin management.
• Displays declared required and optional permissions without changing runtime enforcement.
• Reports bounded, static installation milestones across source retrieval, building, startup, and promotion.
• Moves repository-install preparation and source validation into the service layer.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Administrator reviews plugin] --> B[Approves required and optional grants]
    B --> C[Client creates progress UUID]
    C --> D[Service validates repository source and reserves progress record]
    D --> E[Fetch repository source]
    E --> F[Wait for lifecycle lock]
    F --> G[Prepare builder and dependencies]
    G --> H[Compile and extract binary]
    H --> I[Start candidate plugin]
    I --> J[Promote verified plugin]
    J --> K[Mark progress completed]
    D -. authenticated polling .-> L[Install progress endpoint]
    E -. stages .-> L
    F -. stages .-> L
    G -. stages .-> L
    H -. stages .-> L
    I -. stages .-> L
    J -. stages .-> L

Loading

_{Reviews (3) · Last reviewed commit: "refactor(plugins): reserve installation ..."}

[dviejokfs]

@greptile-apps please review the latest commit 0aaef68. Both reported findings are fixed with regression tests; the capacity fix also isolates reused IDs from stale handles. Please check for remaining findings across the PR.