deathbyknowledge/gsv-package-review

GSV Package Review

Review Procedure

Start from metadata, then verify with source:

pkg list
pkg show <package>
pkg manifest <package>
pkg capabilities <package>
pkg refs <package>
pkg log <package> --limit 20
pkg source status <package>

A review should usually start from clean source. If staged edits exist, explain what they are before trusting the tree.

Inspect /src/packages/<package> directly. Identify browser, backend, CLI, public route, daemon, signal, and package profile entrypoints.

What To Check

• Requested Kernel capabilities match code paths that need them.
• Filesystem writes/deletes are scoped and intentional.
• Shell execution is justified and bounded.
• Repository mutation uses the correct repo and ref.
• Package lifecycle calls such as install, checkout, sync, approve, enable, and public visibility are justified.
• Process spawning, IPC, schedules, adapter calls, notifications, and public routes are explicit.
• Browser code does not abuse parent-window messaging or host bridge assumptions.
• Backend/public routes do their own webhook signature or route-specific authorization.
• Network access, dynamic import, eval-like behavior, and destructive actions are called out.

Mutating Commands

Use these only when the user asked for that action:

pkg add --repo owner/repo --ref main --subdir .
pkg approve <package>
pkg enable <package>
pkg disable <package>
pkg checkout <ref> <package>
pkg public on <package>
pkg public off <package>

Approval and enablement are separate. Approval trusts a package for its requested grants. Enablement activates entrypoints.

Verdict

Lead with findings when risks exist. End with one clear verdict:

• approve
• do not approve
• approve only after named fixes

Do not approve based on display name, description, screenshots, or UI polish alone.