---
name: vellum-boundary-guard
description: Check Vellum Assistant architecture and package boundaries. Use when editing imports, moving code, adding endpoints, touching assistant/gateway/client/skill boundaries, or reviewing architecture-sensitive changes.
---

# Vellum Boundary Guard

## Package Import Boundaries

Enforce these boundaries:

- `assistant/` must not import from `gateway/` via relative paths.
- `gateway/` must not import from `assistant/` via relative paths.
- `assistant/` and `skills/` must not import from each other directly.
- Runtime code must not import from `meta/`.
- Shared cross-package logic belongs in `packages/`.

For tests that need behavior from another package, mock the boundary instead of importing real handlers.

## HTTP And IPC Boundaries

- Public inbound HTTP endpoints belong in `gateway/`.
- New CLI-to-assistant interactions should use Unix socket IPC through the existing IPC route pattern.
- Events from assistant runtime code should use the assistant event hub rather than new HTTP endpoints when possible.

## Security Ownership Boundaries

- Gateway owns trust rules and gateway security files.
- CES owns credential files.
- The assistant must not read gateway-owned directories directly.
- Clients must not read from the user's `~/.vellum` directory.
- Secrets must not be stored in workspace files.

## Skill Boundaries

First-party skills run as separate processes and should communicate through supported contracts. Do not bypass skill isolation with direct relative imports.

## Review Workflow

1. Search changed imports and new route registrations.
2. Identify any package-crossing dependency.
3. Decide whether the correct home is a package-local module, a shared `packages/` module, IPC, HTTP through gateway, or a skill contract.
4. If a violation exists, recommend the smallest boundary-preserving move.

## Verification

Prefer existing guard tests when available, then add focused tests for any new boundary rule or route pattern.