Plugin Review

# Dependency Detection

How to resolve affected and related plugins for scoped
review.

## Affected Plugins

Detect from git diff against the base branch:

```bash
git diff main --name-only | \
  grep '^plugins/' | \
  sed 's|^plugins/\([^/]*\)/.*|\1|' | \
  sort -u
```

If no diff available (detached HEAD, no main branch),
fall back to all plugins.

## Related Plugins

Load `docs/plugin-dependencies.json` and for each affected
plugin, look up who depends on it:

1. Read the `dependencies` section to find the affected
   plugin
2. If `dependents` is `["*"]`, ALL other plugins are related
3. Otherwise, `dependents` lists the specific related plugins

Example: if `abstract` is affected and has
`dependents: ["*"]`, then all 16 other plugins are related.

If `leyline` is affected and has `dependents: ["conjure"]`,
then only conjure is related.

## Deduplication

A plugin that is both affected (has direct changes) AND
related (depends on another changed plugin) is treated as
affected. The "affected" role always wins.

## Special Cases

- **Root-level changes** (pyproject.toml, Makefile, scripts/):
  These affect the workspace, not individual plugins.
  At branch tier, skip. At pr/release tier, flag for
  manual review.

- **No plugins changed**: If the diff has no plugin changes,
  report "No plugin changes detected" and exit with PASS.

- **New plugin**: If a plugin directory exists on disk but
  is not in `plugin-dependencies.json`, flag it and suggest
  running `scripts/generate_dependency_map.py` to update.


# Branch Tier Checks

The branch tier runs quick quality gates on affected and
related plugins. Designed for fast feedback during
development.

## Checks for Affected Plugins

Run these sequentially for each affected plugin:

### 1. Plugin Structure Validation

Run the plugin validator to check plugin.json schema,
skill/agent frontmatter, hook event types, and path
references against the official Claude Code spec:

```bash
python3 plugins/abstract/scripts/validate_plugin.py \
  plugins/<plugin>
```

If critical issues found, mark plugin as FAIL.
Warnings are non-blocking at branch tier.

### 2. Registration Audit

**Only available in night-market repo.** Check script exists first:

```bash
# Check if the script exists (night-market only)
if [[ -f "plugins/sanctum/scripts/update_plugin_registrations.py" ]]; then
  python3 plugins/sanctum/scripts/update_plugin_registrations.py \
    <plugin-name> --dry-run
else
  echo "Registration audit skipped - not running in night-market"
fi
```

Report any missing or stale registrations. If skipped, note in the
result table that registration audit is unavailable.

### 3. Test Gate

```bash
cd plugins/<plugin> && make test
```

Capture pass/fail and test count. If tests fail, mark
plugin as FAIL.

### 4. Lint Gate

```bash
cd plugins/<plugin> && make lint
```

Capture pass/fail. If lint fails, mark as WARNING (not
blocking at branch tier).

### 5. Typecheck Gate

```bash
cd plugins/<plugin> && make typecheck
```

Capture pass/fail. If typecheck fails, mark as WARNING.

### 6. Diff Analysis

Run `git diff main -- plugins/<plugin>/` to identify:
- New files (commands, skills, hooks, agents)
- Deleted files
- Modified production code vs test-only changes

Flag high-risk patterns:
- Hook changes (security surface)
- `__init__.py` export changes (API surface)
- pyproject.toml dependency changes

## Checks for Related Plugins

Run a lighter subset:

### 1. Registration Audit

Same as affected plugins.

### 2. Test Gate

```bash
cd plugins/<plugin> && make test
```

Tests must pass. This catches side-effect breakage from
dependency changes.

## Result Table

Build a table with columns: plugin, test, lint, type, reg,
verdict. Use `--` for skipped checks on related plugins.

## Verdict Rules

- Any test FAIL on affected or related: overall FAIL
- Any lint/type FAIL on affected: overall PASS-WITH-WARNINGS
- All green: PASS


# PR Tier Checks

The PR tier adds quality scoring on top of branch tier