# Profiles (concept & install-flow note)

> The implemented Profile model (CRUD, scope rules, profile-routed proxy access)
> is documented in [`phase-2.2-registry.md`](./phase-2.2-registry.md). This note
> covers the broader concept (bundling all resource kinds + third-party imports)
> and the intended CLI install flow, which is still future work.

A **profile** is a named, versioned bundle of resources (MCP servers, skills,
hooks, sub-agents, rules, commands) plus optional third-party imports (ECC,
Superpower). One-click install applies one or more profiles to a target Agent
tool, writing assets into that tool's config directories.

## Scoping

Every resource and profile is either **global** (admin-managed, shared) or
**personal** (per-user). Personal items are only visible to their owner; global
items are visible to all authenticated users. The CLI and API honor this when
listing and installing.

## Install flow (intended)

1. `hnx install --profile frontend-daily --target zcode`
2. CLI resolves the profile → its entries (resources) and imports.
3. For each resource: fetch the artifact (git/tarball/local), verify checksum,
   then write to the target tool's directory using a target-specific writer
   (e.g. `~/.claude/skills`, ZCode workspace config, …).
4. For each import: run the matching adapter (ECC/Superpower) to place assets.

The CLI fetches profiles from a running Harness Nexus server via the SDK. A
profile is a reference bundle (its entries point at server-side resources by
id), so the resource bodies and the aggregated `/mcp` endpoint both require
the server — the CLI does not read local manifests.

## Manifest schema

Defined in `packages/shared/src/schemas/profile.ts` (zod). The server, web UI,
and CLI all validate against this. Keep it in sync with the domain types in
`packages/core/src/domain/profile.ts`.