레퍼런스
CLI 레퍼런스
Apothem CLI 레퍼런스 — 모든 하위 명령과 플래그.
apothem CLI는 공유 프로필과 하니스 어댑터를 관리하는 주된 운영자
인터페이스입니다.
전역 플래그
| 플래그 | 설명 |
|---|---|
--version | Apothem 버전을 출력하고 종료합니다 |
--help | 명령의 도움말을 출력합니다 |
하위 명령
apothem install
공유 프로필에서 하니스 어댑터를 설치합니다.
apothem install --harness <name|all> [--profile PATH] [--project PATH] [--dry-run] [--clean|--fresh] [--yes]| 옵션 | 설명 |
|---|---|
--harness <name> | 하니스 어댑터 이름(아래의 정규 값 참조). 필수입니다. |
--profile PATH | 공유 프로필 YAML의 경로입니다. 기본값은 ~/.config/apothem/profile.yaml입니다. |
--project PATH | 프로젝트 범위 하니스를 위한 프로젝트 루트입니다. |
--dry-run | 파일을 쓰지 않고 설치를 미리 봅니다. |
--clean, --fresh | 옵트인 클린 슬레이트: 설치하기 전에 이전 설치 상태(~/.claude, ~/.codex, ~/.agents, ~/.config/apothem)를 백업하고 제거합니다. |
--yes | 클린 슬레이트 제거 중 대상별 확인을 건너뜁니다(비대화형 --clean 실행에 필요). |
정규 --harness 값:
antigravity
claude-code
codebuddy
codex
cursor
gemini-cli
github-copilot
glm
hermes
kimi-code
kiro
open-claw
opencode
qwen-code
trae
windsurf
zed레지스트리 전체 집합을 선택하려면 --harness all --project <path>를 사용하세요.
프로필의 exclude_harnesses 목록은 install/update 배치 선택 중에
존중됩니다.
apothem update
현재 공유 프로필에서 하니스 어댑터의 네이티브 구성을 다시 도출합니다.
apothem update --harness <name|all> [--profile PATH] [--project PATH] [--dry-run]| 옵션 | 설명 |
|---|---|
--harness <name> | 하니스 어댑터 이름. 필수입니다. |
--profile PATH | 공유 프로필 YAML의 경로입니다. |
--project PATH | 프로젝트 범위 하니스를 위한 프로젝트 루트입니다. |
--dry-run | 파일을 쓰지 않고 업데이트를 미리 봅니다. |
update는 하니스 출력을 다시 머티리얼라이즈합니다. Apothem 엔진 자체는
업그레이드하지 않습니다. 엔진은 업데이트에 설명된 대로
설치에 사용한 채널(/plugin 흐름, npx, 또는 설치 프로그램과 업데이트
스크립트)을 통해 업데이트하세요.
apothem uninstall
하니스 어댑터의 네이티브 구성을 제거합니다.
apothem uninstall --harness <name|all> [--project PATH] [--yes]| 옵션 | 설명 |
|---|---|
--harness <name> | 하니스 어댑터 이름. 필수입니다. |
--project PATH | 프로젝트 범위 하니스를 위한 프로젝트 루트입니다. |
--yes | 확인 프롬프트를 건너뜁니다. |
apothem verify
하니스 어댑터의 관리 대상이 존재하고 유효한지 검증합니다.
apothem verify --harness <name|all> [--profile PATH] [--project PATH]| 옵션 | 설명 |
|---|---|
--harness <name> | 하니스 어댑터 이름 또는 all. 필수입니다. |
--profile PATH | 충실도 검사의 기준이 되는 공유 프로필 YAML입니다. 이 옵션이 없으면 검사는 순전히 구조적입니다. |
--project PATH | 프로젝트 범위 하니스를 위한 프로젝트 루트입니다. |
--profile이 없으면 검사는 구조적입니다. 모든 관리 대상이 존재하고 유효해야
합니다. --profile을 지정하면 충실도도 요구하므로, 존재하지만 그 프로필에서
드리프트한 설치는 verify에 실패합니다 — 특정 프로필이 충실하게 설치되었는지
확인하려면 이 옵션을 사용하세요.
종료 코드는 하니스가 검증되었을 때(그리고 --profile을 지정한 경우 그 프로필에
충실할 때) 0이고, 대상이 없거나 유효하지 않을 때, 또는 --profile이
주어졌고 설치가 드리프트했을 때 1입니다.
apothem status
등록된 모든 하니스의 설치, 검증, 드리프트 상태를 보고합니다.
apothem status [--profile PATH] [--project PATH]| 옵션 | 설명 |
|---|---|
--profile PATH | 드리프트 기준선으로 사용할 공유 프로필입니다. 기본 프로필을 읽을 수 없으면 스윕을 중단하지 않고 드리프트를 unknown으로 낮춥니다. |
--project PATH | 프로젝트 범위 하니스를 위한 프로젝트 루트입니다. 이 옵션이 없으면 그런 하니스는 needs-project를 보고합니다. |
각 행은 installed 플래그와 verified 플래그를 짝지으며, 두 플래그가
결합되어 드리프트 상태가 됩니다.
| 상태 | 의미 |
|---|---|
absent | Apothem이 이 하니스에 설치하지 않았습니다. |
in-sync | 설치되어 있고 프로필 기준선과 일치합니다. |
drift | 설치되어 있지만 더 이상 일치하지 않습니다 — apothem update로 바로잡으세요. |
unknown | 설치되어 있지만 기준선 프로필을 읽을 수 없었습니다. |
needs-project | 프로젝트 범위 하니스가 --project 없이 보고되어 그 대상을 확인할 수 없습니다. |
installed는 "이 하니스가 머신에 있는가?"가 아니라 "Apothem이 여기에
설치했는가?"에 답합니다. 이 플래그는 Apothem 자체의 아티팩트 — 지침 앵커 안의
관리 블록과 Apothem 소유 .apothem/ 하위 트리 아래의 콘텐츠 — 를 기준으로
하며, 하니스가 스스로 쓰는 벤더 소유 파일을 기준으로 삼는 일은 절대 없습니다.
구성 디렉터리는 존재하지만 Apothem이 한 번도 건드리지 않은 하니스는 absent를
보고하고, 제거된 하니스는 비워진 디렉터리가 남아 있더라도 absent를
보고합니다.
apothem profile
공유 Apothem 프로필을 관리합니다.
apothem profile show [--profile PATH]
apothem profile init [--profile PATH] [--force]
apothem profile set <key> <value> [--profile PATH]
apothem profile edit [--profile PATH]| 하위 명령 | 설명 |
|---|---|
profile init | 스키마에 맞는 최소 프로필 스캐폴드를 생성합니다. |
profile show | 해석된 프로필을 JSON으로 stdout에 출력합니다. --json을 지정하면 문서는 schema_version으로 시작합니다. |
profile set <key> <value> | 프로필 필드를 설정합니다. 값은 리터럴 문자열로 저장됩니다. 맨 단어는 강제 변환되지 않으므로 no는 "no"로, 1.0은 문자열로 남습니다. 단, true/false와 명시적인 [...] / {...} 목록 및 맵 입력은 예외입니다. 조립된 프로필은 쓰기 전에 스키마 검증을 거칩니다. |
profile edit | $EDITOR에서 프로필을 엽니다(플랫폼 기본값으로 대체됩니다). |
--profile PATH 옵션은 각 하위 명령이 대체 프로필 파일을 가리키게 합니다.
기본값은 ~/.config/apothem/profile.yaml입니다.
apothem harnesses
등록된 하니스 어댑터를 나열하고 검사합니다.
apothem harnesses list
apothem harnesses show <name>| 하위 명령 | 설명 |
|---|---|
harnesses list | 등록된 모든 어댑터를 설치 상태 플래그 및 출력 경로와 함께 표로 출력합니다. |
harnesses show <name> | 한 어댑터의 이름, 설치 상태, 출력 경로를 출력합니다. |
apothem doctor
Apothem 설치에 대한 시스템 진단을 실행합니다.
apothem doctorApothem 버전, Python 인터프리터, 플랫폼, 해석된 프로필 경로, 하니스별 설치 상태 표를 출력합니다. 어느 점검이든 실패하면 종료 코드는 1입니다. 예를 들면 잘못된 프로필, 설치되었지만 검증되지 않는 하니스, 시작할 수 없는 등록된 훅 명령, 로드하거나 프로브할 수 없는 어댑터, 읽을 수 없는 원장이 해당합니다. 설치되지 않은 하니스는 보고되지만 실패로 간주되지 않으며, 참고용 메모는 종료 코드를 바꾸지 않습니다.
생성된 명령 및 플래그 레퍼런스
| Command | Flags | Description |
|---|---|---|
apothem backups prune | --dry-run, --format, --harness, --json, --keep, --no-color, --quiet, -q, --verbose, -v | Delete backup sets and install records beyond the newest N per harness. Keeps the newest N backup sets under ~/.apothem/backups/ for each selected harness, and the newest N install records per install root in its ledger under ~/.apothem/state/. A backup set that a kept record, or the latest install record of any install root, still references is never deleted, so rollback of the latest install still restores. |
apothem completion | — | Print a shell-completion script for SHELL to stdout. Supported shells: bash, zsh, fish, powershell. Every script is generated by Click's env-var completion protocol — PowerShell through the completion class registered above, since Click ships none natively. Enabling completion is opt-in: this command only prints the script — pipe or append it to the shell's completion file yourself (see --help). |
apothem diff | --format, --harness, --json, --no-color, --profile, --project, --quiet, -q, --verbose, -v | Preview the pending configuration changes for a single harness. |
apothem doctor | --format, --json, --no-color, --project, --quiet, -q, --verbose, -v | Check the installed harnesses and the shared profile; exit 1 on any failure. Reports the engine version, Python, and platform; validates a present shared profile against the packaged schema; and, for every installed harness, runs the adapter's verify and starts each hook command the install registered with a no-op payload. A harness that is not installed is reported but is not a failure, so a machine with one healthy harness passes. Project-scope harnesses are checked when --project names their root. |
apothem harnesses list | --format, --json, --no-color, --quiet, -q, --verbose, -v | List all registered harness adapters. |
apothem harnesses show | --format, --json, --no-color, --quiet, -q, --verbose, -v | Show details for a specific harness adapter. |
apothem install | --clean, --fresh, --dry-run, --format, --harness, --json, --no-color, --profile, --project, --quiet, -q, --verbose, -v, --yes | Install a harness adapter configuration. |
apothem migrate-workspace | --dry-run, --format, --json, --no-color, --project, --quiet, -q, --verbose, -v | Migrate a legacy per-harness workspace into the shared .apothem layout. The base is the resolved --project root when supplied, otherwise the current working directory (the project-local default). Per-harness memory/contexts/learning stores union-merge into the shared store; a conflicting record is skipped, never overwritten; a legacy .plans tree moves under .apothem/plans; every consumed source is backed up first. The migration is idempotent. |
apothem profile edit | --format, --json, --no-color, --profile, --quiet, -q, --verbose, -v | Open the shared profile in the system editor. |
apothem profile init | --force, --format, --json, --no-color, --profile, --quiet, -q, --verbose, -v | Create a schema-valid shared profile scaffold. |
apothem profile set | --format, --json, --no-color, --profile, --quiet, -q, --verbose, -v | Set a key in the shared profile. KEY is a dotted path that descends into the nested profile structure (identity.name, preferences.style, enforcement.sprints, harnesses.<harness>.preferences.style); a single key with no dot sets a top-level node. VALUE is stored as a literal string — bare words are not coerced (no stays "no", 2024-01-01 and 1.0 stay strings) — except true/false (the boolean enforcement flags) and explicit [...]/{...} list/map input. The fully-assembled profile is validated against the packaged schema BEFORE writing; an invalid set is refused with the standard diagnostic and the profile on disk is unchanged. |
apothem profile show | --format, --json, --no-color, --profile, --quiet, -q, --verbose, -v | Display the current shared profile. |
apothem quickstart | --format, --harness, --json, --no-color, --profile, --project, --quiet, -q, --verbose, -v, --yes | Guided first run: ensure a profile, preview the writes, then install. Walks a new operator through the canonical path in one linear flow — create a starter profile if none exists (with a personalize nudge), preview the files each harness will write (project root vs your home directory), confirm, then install with the grouped capability-note output — and ends with the recommended next commands. --yes runs the whole sequence non-interactively; --format json emits one structured summary of every step. It composes the install building blocks; it does not duplicate them. Without --harness it asks which harness to install, so the first run writes one harness's configuration rather than all of them; all is an explicit choice. A run that cannot ask fails with a usage error before anything is written. |
apothem rollback | --format, --harness, --install-id, --json, --last, --no-color, --project, --quiet, -q, --verbose, -v, --yes | Restore a harness to the state before its recorded install. |
apothem status | --format, --json, --no-color, --profile, --project, --quiet, -q, --verbose, -v | Report install, verify, and drift state for every registered harness. |
apothem uninstall | --format, --harness, --json, --no-color, --project, --quiet, -q, --verbose, -v, --yes | Remove a harness adapter configuration. |
apothem update | --dry-run, --format, --harness, --json, --no-color, --profile, --project, --quiet, -q, --verbose, -v | Re-install a harness adapter configuration from the current profile. |
apothem verify | --format, --harness, --json, --no-color, --profile, --project, --quiet, -q, --verbose, -v | Verify a harness adapter installation. Without --profile the check is structural: every managed target must be present and valid. With --profile the check additionally requires profile fidelity, so a present-but-drifted install fails verify — answering "is THIS profile faithfully installed?" rather than merely "does it exist?". |