사람함께에이전트▾
사람 — 직접 정하고 책임지는 비즈니스 규칙과 흐름. 직접 읽어보세요.
함께 — 개념은 알아두고, 세부 규칙은 에이전트가 따릅니다.
에이전트 — 에이전트가 따르는 규칙과 레퍼런스. 필요할 때 찾아보세요.














CLI 레퍼런스▾
AkanJS 레퍼런스▾akan repair가 그 실패를 해소하는 명령 하나를 실행합니다.plan --out이 쓰는 JSON으로, 단계와 바뀔 것으로 예상되는 파일, 돌릴 검증이 담깁니다..akan/workflows/runs/<runId>.json에 남기는 기록입니다.apply-20260921103000-a1b2c3처럼 생긴 실행 기록의 파일 이름입니다.<kind>로 골라 쓰는, 알려진 실패 하나를 위한 좁은 처방입니다.

akan workflow plan <workflow> … --out <path>akan workflow apply <planPath>akan workflow validate <runId | path>sync, lint, typecheck, build)을 돌리고, 실패를 원인별로 분류합니다.akan repair <kind>generated는 다시 sync하고, format과 imports는 다시 lint하며, 보고만 하는 두 종류는 모듈을 고칠 명령을 알려 줍니다.sync, lint, typecheck가 소스 문제로 실패한 경우로, 소스를 고치거나 복구를 실행합니다.command not found(종료 코드 127)처럼 명령 자체를 실행하지 못한 경우입니다.build 실패를 포함한 그 밖의 실패로, 리포트의 명령 출력을 읽어 봅니다.akan doctor --strict 결과가 붙는데, 이번 변경이 건드린 것과 원래 있던 것으로 나뉩니다. CLI에서는 원래 있던 것을 코드별 개수로만 보여 줍니다.akan mcp는 같은 단계를 툴로 제공합니다. plan 모드는 읽고 계획만 하고, apply 모드는 쓰기까지 합니다.list_workflows · plan, apply 모드explain_workflow · plan, apply 모드plan_workflow · plan, apply 모드apply_workflow · apply 모드run_validation · apply 모드repair_generated · apply 모드repair_imports · apply 모드repair_module_shape · apply 모드out이 없으면 워크플로 이름과 입력값으로 지은 이름(예: add-field-koyo-icecreamorder-topping.json)으로 .akan/workflows/plans/에 씁니다. 그 경로를 apply_workflow에 넘길 planPath로 돌려줍니다.akan workflow list는 각각을 언제 쓰는지 보여 주고, akan workflow explain <name>은 입력, 단계, 검증 명령까지 보여 줍니다.--format json을 주면 예상 변경과 완료 기준까지 함께 나옵니다.--app --module--app --scalar--app --module --surface--app --module --field --type--app --module --field --valuesNone 가드를 단 뮤테이션을 더하고, store 액션과 UI 컨트롤은 권장만 합니다.
필수 입력: --app --module --mutationNone 가드를 단 init 슬라이스를 더하고, 페이지 로드와 Zone은 권장만 합니다.
필수 입력: --app --module --slice--surface는 view, unit, template, zone, util을 받지만, 적용은 앞의 셋만 합니다.--type Number로 만든 플랜에는 오류가 붙고, 오류가 있는 플랜은 아무것도 적용하지 않습니다.--default는 --type에 맞게 변환되고, enum 기본값은 --values 중 하나여야 합니다.plan_workflow에서 surfaces: ["template"]를 주면 단순한 Template 폼에 필드를 넣고, includeInLight: true를 주면 Light 모델에도 더합니다.validate가 --app 대상으로 실행할 명령이 정해져 있습니다.plan과 explain은 소스를 쓰지 않습니다. 소스를 쓰는 것은 apply뿐이고, 그것도 플랜 파일로만 씁니다.list를 뺀 모든 action에 필요합니다. action마다 받는 값은 아래 참고 표에 있습니다.markdown은 사람이 읽는 형식이고, json은 MCP 클라이언트가 받는 것과 같은 리포트입니다.plan 전용입니다. 플랜 JSON을 이 경로에 씁니다. 없으면 화면에 출력만 되어 적용할 수 없습니다.apply 전용입니다. 소스를 쓰지 않고 예상 결과만 보고하며, 실행 기록은 남습니다.create-scalar를 뺀 모든 워크플로에 필요합니다.add-field, add-enum-field의 입력: 필드 이름입니다.add-field의 입력: 필드 타입이나 스칼라 이름입니다. Number 대신 Int나 Float를 씁니다.add-enum-field, 또는 --type enum인 add-field의 입력: 쉼표로 구분한 enum 값입니다.--values 중 하나여야 합니다.create-scalar의 입력: 스칼라 이름입니다.create-ui의 입력: 만들 UI 파일입니다. zone과 util은 계획만 되고 적용되지 않습니다.add-mutation의 입력: 뮤테이션(액션) 이름입니다.add-slice의 입력: 슬라이스(쿼리) 이름입니다.workflow 인자에 akan workflow list에 나오는 이름을 넣습니다.workflow 인자에 이름이 아니라 --out으로 쓴 경로를 넣고, 실행 기록은 .akan/workflows/runs/<runId>.json에 남습니다.workflow 인자에 플랜 경로, 실행 기록 경로, runId 중 하나를 넣으며, 검증도 실행 기록을 남깁니다.workflow 인자에 runId를 넣으면 적용, dry run, 검증, 복구 어느 것이든 그 리포트를 다시 보여 줍니다.dictionary와 module-shape는 아무것도 고치지 않습니다. akan doctor --strict 결과에서 해당 모듈 항목만 골라, 고칠 명령을 알려 줍니다.json은 MCP 클라이언트가 받는 형식입니다.generated, dictionary, module-shape에 필요합니다.dictionary, module-shape에 필요합니다.format, imports에 필요합니다.akan sync <app>을 실행합니다.akan lint <target>을 실행하며, kind는 리포트가 무엇에 관한 것인지 표시할 뿐입니다.akan add-field를 알려 줍니다.akan create-module을 알려 줍니다.akan doctor --strict --format json을 권합니다.repair_generated, repair_imports, repair_module_shape를 제공하고, 나머지는 CLI 전용입니다.