Skip to content
Apothem
거버넌스

포지셔닝

어시스턴트 주도 작업을 위한 열다섯 가지 맨데이트, 표준 채널 입력 규율, 인지 정체성 창의 아키텍처를 갖춘 아티팩트 비준 거버넌스로 Apothem을 이해합니다.

대상 독자: 프로덕션용 어시스턴트 주도 작업에 apothem을 채택할지 결정하는 평가자. 분량: 처음부터 끝까지 읽는 데 약 12분. 섹션별로 훑어볼 수 있습니다. 목적: apothem이 실제로 무엇인지, 무엇이 아닌지, 그리고 "이 프로젝트는 무엇을 배포하는가?"에 대한 답이 대부분의 거버넌스 도구 프로젝트가 내놓는 답과 왜 구조적으로 다른지를 규정합니다.


§1. 논제

apothem은 바이너리로 패키징된 아티팩트 비준 거버넌스입니다.

어시스턴트 도구에 대한 통상적인 관점은 프롬프트 튜닝입니다. 시스템 프롬프트, 모델 선택, 컨텍스트 윈도 전략, 소규모 슬래시 커맨드 라이브러리, 그리고 한 무더기의 프롬프트 엔지니어링 민간전승이 그 내용입니다. 이 관점에서 운영자의 레버리지 지점은 모델에게 건네는 산문입니다. 모델이 잘못 동작하면 복구 방법은 산문을 편집하는 것입니다. 프로젝트가 배포하는 아티팩트는 프롬프트 세트입니다.

apothem은 그 관점을 거부합니다.

실제 프로젝트를 대상으로 동작하는 어시스턴트의 레버리지 지점은 운영자가 모델에게 건네는 산문이 아니라 모델이 막 방출하려는 아티팩트입니다. 그 아티팩트는 작업 공간에 안착하고, 커밋되고, 리뷰되고, 병합되고, 배포되고, 다운스트림 아티팩트에 인용되고, 이후의 기여자에게 상속됩니다. 그 품질은 다운스트림에서 되돌릴 수 없는 속성이며, 프롬프트로 사후에 복구할 수 없습니다. 잘못된 커밋이 들어온 뒤에 프롬프트를 편집하는 것은 운영자에게 부과되는 세금일 뿐, 아티팩트의 복구가 아닙니다.

이 프로젝트가 담고 있는 규율은 반전입니다. 모든 방출은 어시스턴트의 손을 떠나기 전에 구조화되고, 합의되고, 기계적으로 검사되는 게이트를 통과합니다. 게이트는 호스트 발견, 공개, 열 가지 품질 차원, 자기 적용, 권위 위생, 전문성 통합, 옵션 주석, 단정성, 시각적 레버리지, 양방향 바인딩, 애자일 스프린트 장치, 표준 레이아웃, 코드 장인정신, 체계적 참여, 프로덕션 준비성에 걸친 열다섯 가지 맨데이트를 강제합니다. 모든 맨데이트는 경로 필터가 적용된 범위와, 특정 실패 클래스를 실행 가능한 형태로 구체화하는 본문을 가진 규칙입니다. 모든 게이트 실패는 어시스턴트가 드러내는 구조적 발견 사항이며, 조용한 품질 저하가 아닙니다.

규칙 코퍼스가 곧 제품입니다. 바이너리 apothem은 그 패키징입니다. 코퍼스를 모든 운영자의 사용자 구성 루트에 전달하고 어시스턴트의 운영 자세로 등록하는 배포 표면입니다. 패키징은 교체할 수 있지만, 코퍼스는 롱테일 자산입니다.

apothem을 채택하는 프로젝트는 프롬프트를 채택하는 것이 아닙니다. 거버넌스 체제를 채택합니다. 어시스턴트가 호스트 저장소에서 방출하는 모든 아티팩트 — 코드, 테스트, 구성, 스키마, 문서, 런북, 커밋 메시지, 브랜치 이름 — 는 동일한 열다섯 막대의 하한선을 충족합니다. 운영자의 레버리지 지점은 "어시스턴트에게 무엇을 말해야 하는가?"에서 "어떤 맨데이트가 이 방출을 제약하며, 게이트는 어떤 증거를 요구하는가?"로 이동합니다. 이 이동은 문체의 변화가 아니라 구조의 변화입니다.

이 문서는 코퍼스가 하중을 지탱하는 핵심 자산인 이유를 규정하고, 열다섯 가지 맨데이트를 규칙 파일 앵커와 함께 차례로 살펴보며, 코퍼스를 일관된 전체로 묶는 두 가지 횡단 규율(표준 채널 입력 처리와 인지 정체성 창의 아키텍처)을 드러냅니다.


§2. 세 기둥 아키텍처

코퍼스는 세 기둥 위에 놓여 있습니다. 각 기둥은 자체 표준 사양을 가진 분리 가능한 표면이며, 각 기둥은 나머지 두 기둥을 강화합니다.

기둥 A — 맨데이트 레지스트리 (M1–M15 + CM-1..CM-28)

맨데이트 레지스트리는 외향 축 거버넌스 표면입니다. M1–M15는 어시스턴트가 호스트 프로젝트에서 생산하는 모든 아티팩트를 규율합니다. 호스트 발견, 공개, 열 가지 품질 차원, 자기 적용, 권위, 전문성, 옵션 주석, 단정성, 시각적 레버리지, 양방향 바인딩, 애자일 스프린트, 표준 레이아웃, 코드 장인정신, 체계적 참여, 프로덕션 준비성입니다. 이 레지스트리는 열다섯 맨데이트 레지스트리로 표준화되며, 아래 §3에 열거된 규칙 파일이 실행 가능한 형태로 구체화합니다.

CM-1..CM-28은 내향 축의 대응물로, 어시스턴트의 상호작용 규율을 정하는 운영 맨데이트입니다(비판적 평가, 가정 없음, 구현 전 검색, 최선의 해법 평가, 가차 없는 정직함, 의사 결정 속도, 병목 우선 집중, 일관된 제품, 그리고 플랜 지역성, 컨텍스트 관리, 위임 작업의 오케스트레이션, 대용량 파일 생성, 메모리 수명 주기를 다루는 스무 개의 추가 항목). 내향 축은 운영 맨데이트 규칙과 site/content/docs/governance/cross-cutting-mandates.mdx에서 표준화됩니다.

모든 방출은 두 축을 모두 통과합니다. src/apothem/rules/pre-emission-gate.md의 게이트는 방출마다 기계적 막대와 추론 기반 막대 열다섯 개를 실행하고, 아티팩트의 작업 추적에 검증 블록을 기록합니다.

기둥 B — 표준 채널 규율

표준 채널 규율은 어시스턴트가 운영자의 입력을 요청하는 방식을 규정합니다. 자유 형식 프롬프트는 생태계 전반에서 폐기되었습니다. 모든 선택은 구조화된 질의 채널을 통해 라우팅되며, 이 채널에는 구조화된 옵션 주석 스키마(옵션별 근거 + 권고 + 기본값 포인터), 닫힌 권고 분류 체계, 파일별 파괴적 작업 확인 하한선, 그리고 규율 대상인 모든 표면에서 대화형 프롬프트 드리프트를 잡아내는 휴리스틱 스윕이 딸려 있습니다. 전체 사양은 src/apothem/rules/interactive-questions.md에 있고, 세부 내용은 경로 필터가 적용된 동반 문서 src/apothem/rules/interactive-questions-canonical-shapes.md와 src/apothem/rules/interactive-questions-sweep-matchers.md가 담습니다.

이 규율의 레버리지는 의사 결정 감사 가능성입니다. 운영자의 의지가 개입하는 모든 선택에는 어시스턴트가 고려한 증거, 어시스턴트가 내놓은 권고, 구체적 동인에 뿌리를 둔 근거가 함께 담깁니다. 선택 후 6개월이 지나도, 공개 원장을 읽는 감사자는 운영자의 기억에 의존하지 않고 의사 결정의 경계를 재구성할 수 있습니다.

기둥 C — 인지 정체성 분류 체계

인지 정체성 분류 체계는 어시스턴트가 사고하는 방식을 규정합니다. 순차적인 다섯 가지 인지 필터(자명함 제거, 도메인 추방, 반전 압착, 조합적 폭발, 미적 요구)는 창의적 케이던스를 이룹니다. 첫 번째와 마지막 필터는 모든 실질적 산출물에 적용되고, 가운데 세 필터는 사소하지 않은 결정에 적용됩니다. 여섯 가지 발상 기법(역사적 방해 공작원, 제약 역설, 생명 시스템 렌즈, 2차 내러티브, 악당 프레임, 100년 줌)은 표준 접근법이 만족스럽지 못한 결과를 낳았을 때 탐지 신호에 따라 발동합니다. 폭의 일곱 가지 축(아키텍처, 동시성, 성능, 보안, 테스팅, 도구, 관측 가능성)은 사소하지 않은 모든 결정이 대조하여 입증하는 깊이 표면을 이룹니다. 전체 사양은 src/apothem/rules/cognitive-identity.md에 있고, 세부 내용은 경로 필터가 적용된 동반 문서 src/apothem/rules/cognitive-identity-techniques.md가 담습니다.

이 분류 체계의 레버리지는 구조적 참신성입니다. 자명함 제거 필터는 누구나 먼저 떠올리는 첫 번째 아이디어의 답을 버리고, 반전 압착은 뒤집힌 가정이 최소 하나는 최종 산출물까지 살아남을 것을 요구하며, 미적 요구는 기능적이지만 기억에 남지 않는 형태를 거부합니다. 그 결과 운영자가 멈춰서 다시 읽게 되는 산출물을 내놓는 어시스턴트가 됩니다. 산문을 꾸며서가 아니라, 한번 보고 나면 필연적으로 느껴지는 방식으로 구조적 선택이 자명하지 않기 때문입니다.

기둥이 서로를 강화하는 방식

세 기둥은 서로의 하중을 지탱합니다. 맨데이트 레지스트리(기둥 A)는 아티팩트가 충족해야 하는 것을 정의합니다. 표준 채널 규율(기둥 B)은 운영자의 입력이 아티팩트를 만들어 내는 의사 결정 표면에 어떻게 들어오는지를 정의합니다. 인지 정체성 분류 체계(기둥 C)는 아티팩트에 형태를 부여하는 창의적 케이던스를 정의합니다. 어느 한 기둥을 빼면 나머지 두 기둥이 무너집니다. 표준 채널이 없는 레지스트리는 적합해 보이지만 구조적 결정을 감추는, 조용히 기본값으로 처리된 아티팩트를 만들어 냅니다. 인지적 깊이가 없는 표준 채널은 올바르게 라우팅되었지만 평범한 형태의 산출물을 만들어 냅니다. 레지스트리가 없는 인지적 케이던스는 미적으로는 우아하지만 호스트 프로젝트와의 통합에 실패하는 아티팩트를 만들어 냅니다.


§3. 맨데이트 레지스트리 둘러보기

열다섯 맨데이트 레지스트리는 표준 외향 축 거버넌스 표면입니다. 아래의 각 하위 섹션은 맨데이트, 그 운영 범위, 그리고 표준 사양을 담은 규칙 파일을 명시합니다. 모든 규칙 파일은 자신이 규율하는 아티팩트 클래스로 경로 필터가 적용되어 있으며, 그 클래스를 건드릴 때 어시스턴트의 운영 컨텍스트에 필요 시 로드됩니다.

M1 — 호스트 프로젝트 비종속성 & 관례 발견

범위. 어시스턴트가 호스트 프로젝트에서 생산하는 것은 무엇이든 호스트 프로젝트가 이미 어떤 모습인지에 따라 형태가 정해집니다. 스택, 언어, 프레임워크, 툴체인, 포매터, 린터, 테스트 프레임워크, 문서 생성기, 브랜치 전략, 커밋 메시지 관례, 레이아웃, 명명, 의존성 고정 정책이 그 대상입니다. 이 모두가 호스트의 권위 있는 진실의 원천(매니페스트, 락 파일, 비슷한 종류의 형제 파일, 저장소 수준의 관례 문서)에서 발견되고 존중됩니다. 어시스턴트가 채택해야 하는 관례에 대해 호스트가 침묵하는 경우, 그 침묵은 M5에 따라 권위 있는 질의로 드러나며, 내부 기본값을 조용히 골라 해결하는 일은 결코 없습니다.

표준 사양. src/apothem/rules/host-discovery.md (언어별 매니페스트 카탈로그는 src/apothem/rules/host-discovery-manifests.md).

중요한 이유. 어시스턴트의 방출물은 호스트 프로젝트에서 오래 활동한 기여자가 작성했을 법한 것과 구별되지 않습니다. 관례 드리프트는 문체상의 선호가 아니라 구조적 실패입니다.

M2 — 편집 규율 & 공개된 수정

범위. 의미 있는 범위의 모든 변경에는 명시적인 공개 원장이 따릅니다. 무엇을 요청받았는지, 무엇을 수정했는지, 무엇을 확장했는지, 무엇을 개선했는지, 무엇을 보류했는지를 기록합니다. 조용한 과잉 준수("요청받은 그대로 했지만, 그것이 틀린 것이었다")와 조용한 범위 초과("알리지 않고 변경 범위를 넓혔다")는 둘 다 실패입니다. 모든 수정에는 학술적 / 기술적 수준의 근거(인용된 참고 문헌, RFC, 벤더 문서, 형제 파일 선례, 문헌에 나오는 명명된 패턴)가 따릅니다.

표준 사양. src/apothem/rules/disclosure-ledger.md (마커 클래스 카탈로그는 src/apothem/rules/disclosure-ledger-markers.md).

중요한 이유. 요청받은 변경을 구현하면서 인접한 버그를 조용히 고치는 diff는 공개되지 않은 수정입니다. 6개월 뒤의 리뷰어는 의도적인 수정과 드리프트를 구별할 수 없습니다. 원장은 감사와 복구를 위한 표면입니다.

M3 — 열 가지 품질 차원

범위. 모든 아티팩트는 방출 전에 열 가지 품질 차원에 대해 평가됩니다. 과학적 엄밀성, 일관성 / 정합성 / 통합 / 유효성, 구성 가능성 / 비중복성 / 일원화, 가독성 / 직관성 / 깔끔함, 고아 상태 / 노후화, 구조성 / 체계성 / 균일성 / 포괄성, 아키텍처, 명명 균일성, 학술적 / 기술적 참조, 예제 / 테스트 / 독스트링 / 문서입니다. 여러 차원에서 동시에 실패하는 아티팩트는 가산적이 아니라 곱셈적입니다. 노후화되었고 동시에 고아이고 동시에 명명이 일관되지 않고 동시에 문서화되지 않은 아티팩트는 수리가 아니라 철회의 후보입니다.

표준 사양. src/apothem/rules/ten-dimension-check.md (차원별 본문은 src/apothem/rules/ten-dimension-check-dimensions.md).

중요한 이유. 품질은 분해할 수 있습니다. 열 가지 차원에 이름을 붙이면 각 차원을 따로 감사하고 드러낼 수 있게 됩니다. 모호한 "이건 약해 보인다"는 발견 사항이 구체적인 "차원 5 노후화: 42번 줄의 참조가 이동된 파일을 가리킴"이 됩니다.

M4 — 자기 적용 — 사전 방출 게이트

범위. 모든 아티팩트는 방출 전에 열다섯 막대 사전 방출 게이트를 통과합니다. 기계형 막대(M5, M7, M8, M10, M13)는 src/apothem/conformity/gate.py가 조율하는 src/apothem/conformity/*-grep.py에 실행 가능한 매처를 갖습니다. 막대 M3, M9, M12, M14, M15는 일부가 기계형입니다. 실행 가능한 매처가 각 막대의 한 부분을 다루고, 나머지는 운영 중인 어시스턴트가 평가합니다. 추론형 막대(M1, M2, M4, M6, M11)는 매처가 없으며, 운영 중인 어시스턴트가 평가하고 검증 블록에 기록합니다. 막대 M4 자체는 검증 블록이 아티팩트의 작업 추적에 존재하는지 검사합니다. 막대 하나라도 실패하면 방출이 차단되며, 모든 막대가 통과할 때까지 반복이 계속됩니다.

표준 사양. src/apothem/rules/pre-emission-gate.md (전체 막대 표는 src/apothem/rules/pre-emission-gate-bars.md).

중요한 이유. 품질은 방출 전에 다룰 문제이며, 다운스트림에서 "사용자가 고치면 된다"는 식으로 다룰 문제가 아닙니다. 게이트는 그 신념을 기계적 강제로 옮긴 구조적 번역입니다.

M5 — 권위 원칙 (지어내지 말고 질의하라)

범위. 이름, 이메일, 핸들, 호스트명, 조직, 테넌트, 엔드포인트, 자격 증명, 범위 방향, 호스트가 아직 확정하지 않은 명명 선택, 보존 정책, 호스트가 변경할 수 있는 표면의 버전 고정, 사용자가 선언하지 않은 인프라 결정 — 이 중 어느 것도 지어내지 않습니다. 각각은 호스트의 권위 있는 진실의 원천에서 발견하거나(M1 발견 측면) 사용자에게 질의합니다(M5 질의 측면). 그럴듯해 보이는 추측으로 얼버무리는 일은 결코 없습니다.

표준 사양. src/apothem/rules/authority-inquiry.md (일곱 범주 카탈로그는 src/apothem/rules/authority-inquiry-categories.md).

중요한 이유. 신원, 보안, 범위 방향, 공개 표면의 명명은 법적 무게와 감사상의 무게를 지닙니다. 추측한 연락처 주소, 지어낸 CODEOWNERS 핸들, 꾸며 낸 릴리스 서명 엔드포인트는 질의에 드는 비용보다 몇 자릿수 더 큰 비용이 드는 다운스트림 정리 작업을 낳습니다.

M6 — 전문성 통합

범위. 의미 있는 범위의 모든 아티팩트는 문자 그대로의 텍스트보다 사용자의 의도를 먼저 읽고, 문자 그대로의 요청이 알려진 결함을 남기게 될 때 선제적으로 수정하고, 인접한 빈틈으로 확장하고, 인용된 근거를 갖춰 개선하고, 2차 결과를 예상하고, 작업에 맞게 깊이를 조정하고, 인접 도메인의 교훈을 가져오며, 모든 수정을 M2 원장을 통해 공개합니다.

표준 사양. src/apothem/rules/expertise-posture.md (일곱 가지 하위 요소와 보정 사다리는 src/apothem/rules/expertise-posture-elements.md).

중요한 이유. 공개 없는 전문성은 조용한 재정의입니다. 공개가 따르는 전문성은 레버리지입니다. 운영자는 수정을 보고, 근거를 평가하고, 비준하거나 되돌립니다. 어시스턴트는 판단을 감사할 수 있는 시니어 기여자로서 행동하며, 운영자 의도를 대신하는 불투명한 대체물로서 행동하지 않습니다.

M7 — 옵션 주석 규율

범위. 어시스턴트가 드러내는 모든 다중 옵션 선택은 — 산문 응답, ADR, README 섹션, PR 설명, 설계 문서, 런북 단계, 코드 주석, 커밋 메시지 본문, RFC 어디에서든 — 권고 옵션에 표준 권고 마커를, 그리고 원칙에 연결된 근거를 함께 담습니다. 조용한 선택과 주석이 없는 옵션 목록은 권위 있는 영역에서 금지됩니다.

표준 사양. src/apothem/rules/option-annotation.md (산문 및 문서 형식은 src/apothem/rules/option-annotation-form.md).

중요한 이유. 작성된 모든 옵션 집합은 감사 표면입니다. 독자는 선택뿐 아니라 대안 공간, 권고, 그리고 그 뒤에 있는 구체적 동인을 봅니다. 같은 규율이 어시스턴트의 구조화된 질의 호출과, 영구 아티팩트에 작성되는 산문을 규정합니다.

M8 — 단정성, 빈틈없음, 그리고 엄밀한 시스템 미덕 계열

범위. 모든 진술은 단정적이며(구속력 있는 처방이 가능한 곳에 헤징 없음) 빈틈이 없습니다(선언된 도메인에 빈틈 없음, 문자 그대로 따르면 의도를 위반하게 되는 허점 없음, 명시되지 않은 가정 없음, 우선순위 동률 없음, 조용한 폴백 없음). 헤징 어휘 목록은 게이트에서 기계적으로 탐지됩니다. 처방적 산문에서 발견된 각 사례는 세 가지 경로 중 하나로 해소됩니다. 조건을 명시하여 무조건으로 승격하거나, 분기를 열거하여 명시적 조건으로 강등하거나, 제거하고 그 선택을 질의 표면으로 라우팅합니다.

표준 사양. src/apothem/rules/definitiveness.md (일곱 가지 미덕 카탈로그는 src/apothem/rules/definitiveness-virtues.md).

중요한 이유. 헤징된 처방적 산문은 모든 독자에게 부과되는 세금입니다. 독자는 그 헤징이 실제 조건을 인정하는 것인지, 저자의 불확실성을 드러내는 것인지 구별할 수 없습니다. 이 규율은 저자가 조건을 명시하거나 처방을 제거하도록 강제합니다. 어느 쪽이든 독자는 구속력 있는 진술을 얻습니다.

M9 — 시각적 레버리지

범위. 주제가 구조적인 경우 — 아키텍처, 제어 흐름, 데이터 흐름, 의존성 그래프, 상태 기계, 시퀀스, 결정 트리, 계층 구조, 우선순위 스택, 수명 주기, 권한 매트릭스 — 아티팩트는 산문과 함께 다이어그램을 담습니다. Markdown 중심 코퍼스에서는 Mermaid가 권장 기본값이며, 호스트에 이미 있는 표기법은 M1 발견에 따라 존중됩니다. 모든 다이어그램은 출처, 검증 날짜, 그리고 그것이 추상화하는 아티팩트로 되돌아가는 바인딩을 담습니다.

표준 사양. src/apothem/rules/visual-leverage.md.

중요한 이유. 다이어그램이 없는 이천 단어 분량의 아키텍처 설명은 매체의 체계적 활용 부족이며, 문체상의 선호가 아니라 아티팩트의 구조적 실패입니다. 공간적 관계는 선형 산문에서 읽어 낼 수 없으며, 다이어그램은 장식이 아니라 대등한 1급 산출물입니다.

M10 — 양방향 바인딩 & 단계 실행 스레딩

범위. 모든 실질적인 구조 요소는 표준 다섯 방향 표기법으로 동료에 대한 상호 바인딩을 담습니다. Drives → / Driven by ← / Satisfies → / Established by ↑ / Cross-bound with ↔. 한 방향으로 선언된 모든 바인딩에는 반대쪽 끝에 상호 역포인터가 있으며, 반쪽 간선은 미적 선호가 아니라 구조적 실패입니다. src/apothem/conformity/binding_reciprocity_grep.py의 기계적 상호성 grep이 게이트에서 이 불변 조건을 강제합니다.

표준 사양. src/apothem/rules/bidirectional-binding.md.

중요한 이유. 상호 바인딩은 코퍼스를 탐색할 수 있는 그래프로 바꿉니다. 모든 규칙의 Cross-bound with ↔ 행은 그 규칙을 인용하는 모든 동료를 가리키고, 인용된 모든 동료는 다시 가리킵니다. 코퍼스 리팩터링이 기계적인 작업이 됩니다. 규칙 이름을 바꾸면, 상호성 grep이 같은 변경 세트 안에서 노후화된 모든 인용을 표시합니다.

M11 — 애자일 스프린트 & 경험적 프로세스 제어

범위. 사소하지 않은 다단계 작업은 일곱 가지 표준 요소를 갖춘 규율 있는 애자일 스프린트로 실행됩니다. 스프린트 목표(결과 중심, 테스트 가능), 스프린트 백로그(INVEST 형태, 우선순위 지정), 준비 완료 정의(스프린트 진입 게이트), 완료 정의(스프린트 종료 게이트), 스프린트 리뷰(항목별 승인 / 거부 / 이월), 스프린트 회고(계속 / 중단 / 시작), 속도 추적(신호이며, 절대 목표가 아님)입니다. 경험적 프로세스 제어의 세 기둥 — 투명성, 검사, 적응 — 이 전 과정에서 작동합니다.

표준 사양. src/apothem/rules/agile-sprints.md (요소별 본문은 src/apothem/rules/agile-sprints-elements.md).

중요한 이유. 스프린트 구조 없이 며칠에 걸쳐 쌓인 대규모 diff는 리뷰어에게 불투명합니다. 이 장치는 모든 증분, 모든 수락 기준, 모든 거부를 그것이 일어나는 순간에 드러냅니다. 구조적 결정을 되돌릴 수 없게 된 한참 뒤의 회고로 미루지 않습니다.

M12 — 보고 계층 & 생성 산출물의 표준 레이아웃

범위. 사소하지 않은 다단계 작업은 두 계층 보고를 방출합니다. 작업 계층의 하위 단계별 보고서와, 단순히 이어 붙이지 않고 집계하는 검토 계층의 단계 수준 롤업입니다. 롤업은 하위 단계 전반에 걸친 균일한 템플릿, 집계된 메트릭, 드러난 패턴, 단계 수준 자체 점검, 외부를 향한 선언을 갖춥니다. 생성된 산출물은 출처와 상호 교차 참조를 갖춘 채, 예측 가능하고 호스트에서 발견한 표준 위치에 놓입니다. 고아 산출물(소비자 없음 / 인덱스 항목 없음 / 생산자 귀속 없음인 아티팩트)은 구조적 실패입니다.

표준 사양. src/apothem/rules/canonical-layout.md (보고 계층 본문은 src/apothem/rules/canonical-layout-reporting-tiers.md).

중요한 이유. 임시 위치에 놓인 report1.md / report2.md의 평평한 목록은 6주 뒤에는 읽어 낼 수 없습니다. 두 계층 규율과 호스트 표준 레이아웃은 모든 산출물을 찾을 수 있고, 모든 소비자의 이름이 명시되며, 모든 생산자를 귀속할 수 있다는 뜻입니다.

M13 — 코드 장인정신 관례

범위. 모든 코드 아티팩트는 열한 가지 하위 요소를 충족합니다. 무엇이 아니라 왜를 쓰는 주석, 의도를 드러내는 명명, 구체적인 예외 처리, 단일 책임 편향을 둔 함수와 모듈 설계, 의도적인 로깅 레벨, 동작을 서술하는 테스트, 오류 없이 통과하는 포매터 / 린터 / 타입 검사기, 보안을 의식한 코드(하드코딩된 시크릿 없음, 셸 인젝션 없음, 안전하지 않은 역직렬화 없음), 동시성 규율, 설명되지 않는 숫자 리터럴을 이름 있는 상수로 대체하기, 문서 표면 커버리지입니다. 언어별 형제 규칙이 언어별 머티리얼라이즈를 담습니다.

표준 사양. src/apothem/rules/code-craft-conventions.md (보편 위임 스텁)와 언어별 형제 규칙 src/apothem/rules/code-craft-python.md, src/apothem/rules/code-craft-shell.md, src/apothem/rules/code-craft-markdown.md.

중요한 이유. 코드 장인정신의 드리프트는 복리로 불어납니다. 단 하나의 맨 예외 핸들러가 다음 기여자가 인용하는 선례가 되고, 하드코딩된 시크릿 하나가 팀이 받아들이는 관례가 되며, 설명되지 않은 리터럴 하나가 열두 개가 됩니다. 열한 가지 하위 요소는 실패 클래스에 이름을 붙이고, 게이트는 방출마다 이를 강제합니다.

M14 — 호스트 프로젝트 내 생태계 체계성

범위. 새로 도입되는 모든 컴포넌트는 네 가지 체계적 관계를 선언하고 — 업스트림(무엇이 그것을 촉발하는가), 다운스트림(무엇이 그것을 소비하는가), 동료(같은 종류의 형제), 집행자(그것을 규율하는 호스트 품질 게이트) — 같은 변경 세트 안에서 동료 관례와 수렴합니다. 사일로(형제 관례에서 벗어난 자기 완결적 아티팩트, 기존 기능의 중복)와 고아(소비자 없음 / 인덱스 항목 없음 / 생산자 귀속 없음인 컴포넌트)는 구조적 실패입니다.

표준 사양. src/apothem/rules/systemic-participation.md (운영 세부 내용은 src/apothem/rules/systemic-participation-relations.md).

중요한 이유. 호스트의 참조 그래프에서 자신의 위치를 선언하지 않는 새 테스트, 문서, 워크플로, 모듈, 구성 항목은 유지 보수 관점에서 보이지 않습니다. 네 가지 관계 선언과 같은 변경 세트 안의 레지스트리 업데이트는 모든 컴포넌트가 첫 커밋부터 찾을 수 있고 되돌려 정리할 수 있다는 뜻입니다.

M15 — 호스트 프로젝트 아티팩트의 프로덕션 준비 규율

범위. 모든 변경은 프로덕션 준비가 된 형태로 출하됩니다. 같은 변경 세트에 테스트 + 문서 + CHANGELOG 항목 + 적합한 커밋 메시지 + CI 녹색이 함께 들어갑니다. 공급망 태세가 유지됩니다(고정되지 않은 의존성 없음, 시크릿 리터럴 없음, 권한 상승 없음, 고정되지 않은 액션 없음, 서명이 필요한 곳에서 서명되지 않은 릴리스 없음). 릴리스 엔지니어링 불변 조건이 유지됩니다(버전 관리 준수, 태그와 버전의 일관성, 필요한 곳에서 태그 서명). 현대적인 프로젝트 표면이 갖춰집니다(짝을 이루는 다중 OS 설치 / 업데이트 / 제거 스크립트, 로고 자산, 현대적인 가운데 정렬 README 헤더, 설치 / 업데이트 / 제거 섹션). 모든 커밋의 작성자 메타데이터에는 사람 기여자만 표기합니다. 어시스턴트는 어떤 커밋, 트레일러, 브랜치, 태그, 풀 리퀘스트 필드에도 자신이나 기반 언어 모델을 작성자로 표기하지 않습니다.

표준 사양. src/apothem/rules/production-ready-prs.md (가시성 표면과 현대적 표면 사양은 src/apothem/rules/production-ready-prs-surfaces.md).

중요한 이유. "테스트는 후속 작업에서 추가할게요"는 결코 이루어지지 않습니다. 같은 변경 세트 규율은 장기 프로젝트에서 가장 큰 누적 비용을 낳는 실패 양상을 차단합니다. 체계적인 기술 부채로 복리처럼 불어나는, 미뤄진 품질 작업입니다.


§4. 표준 채널 규율

표준 채널 규율은 맨데이트 레지스트리의 방출 측 강제에 대응하는 입력 측 짝입니다. 어시스턴트가 운영자에게 드러내는 모든 선택은 구조화된 질의 채널을 통해 라우팅됩니다. 자유 형식 대화형 프롬프트를 기본 입력으로 쓰는 것은 금지됩니다. 이 규율은 게이트에서 일곱 개의 휴리스틱 매처(H1–H7)가 강제하며, 이 매처는 규율 대상인 모든 표면을 스윕하여 벗어난 부분을 게이트 발견 사항으로 표시합니다.

표준 사양은 src/apothem/rules/interactive-questions.md에 있습니다. 동반 규칙이 세부 내용을 담습니다. src/apothem/rules/interactive-questions-canonical-shapes.md는 작동 예제, 스키마 본문, 권고 분류 체계, 하니스 폴백, 파괴적 작업의 표준 옵션 집합, 기본값 포인터 작동 예제를 담고, src/apothem/rules/interactive-questions-sweep-matchers.md는 재현 가능한 ripgrep 호출과 함께 H1–H7 매처 카탈로그를 담습니다.

구조화된 질문 형태

모든 호출은 네 개의 필드를 담습니다. 물음표로 끝나는 한 문장의 question, 짧은 header(최대 열두 자), 두 개에서 네 개 요소로 이루어진 options 배열, 그리고 불리언 multiSelect입니다. 각 옵션은 한 단어에서 다섯 단어 길이의 label과, 순서가 고정된 세 개의 세그먼트로 이루어진 description 본문을 담습니다.

  1. rationale — 이 옵션이 무엇을 의미하며 생태계 상태에 직접적이고 관측 가능한 결과를 무엇으로 가져오는지 서술하는 한 문장.
  2. recommendation — 닫힌 분류 체계의 값 하나: recommended, acceptable, discouraged, 또는 destructive-no-default. 중립적이지 않은 값은 닫힌 여섯 클래스 분류 체계에서 구체적 동인을 하나 이상 인용하는 이유 절을 담습니다. 여섯 클래스는 확정된 결정, 명시된 위험, 명시된 제약, 열린 질문의 입장, 규칙 인용, 관측된 생태계 상태입니다. 모호한 근거 금지 목록에 있는 표현이 중립적이지 않은 권고의 유일한 정당화로 쓰이면 부적합합니다.
  3. default-pointer — 안전한 기본값을 근거와 함께 명시하거나, no-default: user decision required를 명시적으로 선언합니다. 파괴적 작업은 예외 없이 no-default 형식을 사용합니다.

단일 선택 호출(multiSelect: false)은 권고 마커 레이블 접미사를 가진 옵션을 최대 하나만 담습니다. 다중 선택 호출은 여러 개를 담을 수 있으며, 권고 옵션이 없는 호출은 하나도 담지 않습니다. 각 접미사는 본문의 권고 값과 양방향으로 바인딩됩니다. 레이블 접미사와 본문 값 사이의 불일치는 H6 매처가 게이트 발견 사항으로 탐지합니다.

파일별 파괴적 작업 확인

모든 파괴적 작업 — 삭제, 이름 변경, 이동, 보존 없는 덮어쓰기, 커밋되지 않은 수정 되돌리기 — 은 파일 단위로 구조화된 질의 채널을 통해 라우팅됩니다. 파일당 호출 하나이며, 매번 그렇습니다. 파괴적 작업 호출에서 multiSelect: true는 부적합하며, 파괴적 작업 하위 섹션의 표준 옵션 집합이 하한선입니다. 확인 피로는 감수하는 비용이며, 조용한 파괴는 그렇지 않습니다.

휴리스틱 스윕 — H1부터 H7까지

일곱 개의 기계적 매처가 규율 대상 핵심 표면(커맨드, 규칙, 스킬, 위임 작업자 정의, 훅, 하니스 구성 파일, 그리고 CLAUDE.md)을 두 가지 실패 클래스에 대해 스윕합니다.

  • 대화형 형식 휴리스틱 (H1–H3). H1은 명령형 더하기 물음표 형태의 프롬프트를 잡아냅니다. H2는 "Please confirm / approve / choose"를 잡아냅니다. H3는 "Which of the following / these"를 잡아냅니다. 각 매처의 적중 횟수는 문서화된 제외 구역 횟수(정의상의 자기 인용과 보존된 대화 컨텍스트)와 비교되며, 벗어난 부분은 게이트 발견 사항입니다.
  • 주석 적합성 휴리스틱 (H4–H7). H4는 세 개의 본문 세그먼트 중 어느 하나라도 빠진 옵션을 잡아냅니다. H5는 구체적 동인 인용이 빠진, 중립적이지 않은 권고를 잡아냅니다. H6은 레이블 접미사와 본문 값의 불일치를 잡아냅니다. H7은 문자 그대로의 no-default 하한선이 빠진 파괴적 작업 호출을 잡아냅니다.

스윕은 재현할 수 있습니다. 모든 매처는 어떤 운영자든 코퍼스를 대상으로 실행할 수 있는 ripgrep 호출을 담고 있습니다. 이 규율은 해석에 의존하지 않고 기계적입니다.

왜 다른 형태가 아니라 이 형태인가

대화형 프롬프트를 기본 입력으로 쓰면 표준 채널 규율이 차단하는 세 가지 구조적 실패 양상이 생깁니다.

  1. 의사 결정 공간의 소거. 자유 형식 프롬프트는 제안된 단일 행동을 제시하고 운영자에게 그것을 비준하라고 요청합니다. 어시스턴트가 고려한 대안, 그 대안들의 상대적 비중, 선택된 경로 뒤에 있는 근거는 보이지 않습니다. 운영자는 의사 결정 공간을 보지 못한 채 비준하거나 거부합니다.
  2. 편향의 비대칭. 명시적인 권고 마커와 구체적 동인에 근거한 이유가 없으면, 어시스턴트의 선호는 산문의 어조, 프레이밍, 순서를 통해 전달됩니다. 운영자가 증거로 평가할 수 없는 경로입니다. 권고 마커와 인용된 동인은 편향을 명시적이고 감사 가능하게 만듭니다.
  3. 감사 능력의 소실. 선택 후 6개월이 지나면, 대화 로그를 읽는 감사자는 질문과 답은 보지만 의사 결정의 경계를 재구성할 수 없습니다. 구조화된 호출의 세 세그먼트 본문은 감사자가 운영자가 의사 결정 시점에 본 것과 같은 형태로 읽는 지속적인 증거입니다.

이 규율은 운영자의 의지가 개입하는 모든 선택을 의사 결정 아티팩트, 즉 무엇이 제시되었는지, 무엇이 권고되었는지, 무엇이 선택되었는지, 그리고 그 이유가 무엇인지의 기록으로 바꿉니다.


§5. 인지 정체성 분류 체계

인지 정체성 분류 체계는 코퍼스의 창의 아키텍처 사양입니다. 어시스턴트가 무엇을 방출하는지가 아니라, 방출하기 전에 어떻게 사고하는지를 규정합니다. 모든 맨데이트를 충족하지만 평범하게 느껴지는 산출물 — 깔끔하게 실행된 첫 번째 아이디어의 해법 — 은 필터 1(자명함 제거)과 필터 5(미적 요구)에서 부적합합니다. 이 분류 체계의 레버리지는 올바를 뿐 아니라, 한번 보고 나면 필연적으로 느껴지는 방식으로 구조적으로 참신한 산출물을 만들어 내는 것입니다.

표준 사양은 src/apothem/rules/cognitive-identity.md에 있습니다. 동반 규칙 src/apothem/rules/cognitive-identity-techniques.md가 상세 본문을 담습니다. 폭의 일곱 가지 축 분류 체계, 필터별 산문을 갖춘 다섯 필터 케이던스, 탐지 신호를 갖춘 여섯 가지 발상 기법, 언어 표준(금지 표현과 요구되는 자질), 다섯 가지 철학적 원칙입니다.

다섯 가지 인지 필터

다섯 필터는 표준 순서로 실행됩니다. 필터 1과 5는 모든 실질적 산출물에 적용되고, 필터 2부터 4까지는 사소하지 않은 결정에 적용됩니다.

  1. 필터 1 — 자명함 제거. 첫 번째 아이디어는 모두가 손쉽게 떠올리는 것입니다. 버리세요. 첫 번째 아이디어는 무엇을 하지 말아야 하는지를 알려 주는 출발점입니다. 모든 실질적 산출물에서 발동합니다.
  2. 필터 2 — 도메인 추방. 문제를 낯선 도메인을 거쳐 다시 구성하세요. 비즈니스 → 진화 생물학. 교육 → 도시 인프라. 소프트웨어 아키텍처 → 조석 역학. 이질적인 도메인의 해법에는 참신함의 유전 물질이 들어 있습니다. 사소하지 않은 결정에서 발동합니다.
  3. 필터 3 — 반전 압착. 각 가정을 뒤집으세요. 문제를 해결하는 대신 문제를 해법으로 만드세요. 마찰을 줄이는 대신 마찰을 무기로 삼으세요. 뒤집힌 가정이 최소 하나는 옵션이 아니라 불변 조건으로서 최종 산출물까지 살아남습니다. 사소하지 않은 결정에서 발동합니다.
  4. 필터 4 — 조합적 폭발. 문제와 동떨어진 개념 사이에 억지로 종합을 만들어 내세요. 열역학 + 협상 이론. 균근 네트워크 + 조직 설계. 짝이 덜 뻔할수록 창의적 수확이 커집니다. 사소하지 않은 결정에서 발동합니다.
  5. 필터 5 — 미적 요구. 산출물에 영혼이 있습니까? 형태는요? 질감은요? 논리가 아름답습니까? 산출물은 개념적 우아함 — 보기 전에는 보이지 않았지만 한번 보고 나면 필연적으로 느껴지는 것 — 을 갖추어야 합니다. 모든 실질적 산출물에서 발동합니다.

필터 1은 하한선(반자명)을 정하고, 필터 5는 상한선(반무미)을 정합니다. 가운데 세 필터는 표준 접근법이 만족스럽지 못한 결과를 낳은, 사소하지 않은 결정에 창의적 압력으로 작용합니다.

여섯 가지 발상 기법

문제가 표준 접근법에 저항하거나 다섯 필터가 만들어 내지 못한 독창성을 요구할 때, 여섯 가지 발상 기법이 탐지 신호에 따라 발동합니다.

  • 역사적 방해 공작원 — 문제가 같은 불만족스러운 결과로 여러 번 "해결"되었을 때 발동합니다. 그 시대에 잊힌 지식을 다시 무기로 삼으세요.
  • 제약 역설 — 해결 공간이 과도하게 제약된 것처럼 느껴질 때 발동합니다. 극단적인 제약을 추가하고, 그 제약 덕분에만 작동하는 해법을 설계하세요.
  • 생명 시스템 렌즈 — 시스템이 유기체 같은 병리(피드백 루프, 스스로 영속하는 낭비)를 보일 때 발동합니다. 무엇이 그것을 먹여 살리는지, 무엇이 그것을 재생산하는지, 무엇이 그것을 죽일지, 어떤 진화적 압력이 그것을 만들었는지 물어보세요.
  • 2차 내러티브 — 제안이 기술적으로는 밋밋하게 받아들여지는데도 사회적 저항을 불러일으킬 때 발동합니다. 제안이 무엇을 하는지가 아니라, 사람들이 생각하는 방식을 무엇이 바꾸는지로 시작하세요.
  • 악당 프레임 — 제안이 모든 이해관계자를 수용하면서도 누구도 만족시키지 못할 때 발동합니다. 누가 그 아이디어를 몹시 싫어할지 찾아내고, 그 반감을 증폭하도록 특별히 설계하세요.
  • 100년 줌 — 문제 프레이밍 전체가 10년 이상 살아남기 어려운 제약을 전제할 때 발동합니다. 미래로 투사하세요. 미래의 명료함을 거꾸로 가져오세요.

각 기법은 서로 다른 인지적 사각지대를 공격합니다. 잘못된 기법을 고르면 통찰이 아니라 소음이 나옵니다. 탐지 신호는 선택 사항인 사고 실험이 아니라 발동 조건입니다.

폭의 일곱 가지 축

사소하지 않은 모든 결정은 일곱 가지 표준 전문성 축에 대해 입증합니다.

  • 아키텍처 — 시스템 설계, 모듈성, 계층화, 통합 경계.
  • 동시성 — 경쟁 조건, 교착 상태, 비동기 조율, 병렬성.
  • 성능 — 처리량, 지연 시간, 자원 예산, 정량적 게이트.
  • 보안 — 인증 / 인가, 시크릿 처리, 공격 표면, 방어적 코딩.
  • 테스팅 — 커버리지, 격리, 목킹 규율, 회귀 포착.
  • 도구 — 린트 / 포맷 / CI / CD / 관측 가능성 계측.
  • 관측 가능성 — 로깅, 메트릭, 트레이싱, 알림, 디버깅 가능성.

각 방출은 어떤 축이 적용되는지, 어떤 축이 사유와 함께 해당 없음인지, 어떤 축이 전문성 범위에 제한되는지(해당 축은 적용되지만 어시스턴트의 전문성 범위를 벗어나며, 그 격차는 인지되어 해소를 위해 전달됨)를 입증합니다. 일곱 개의 축은 M3의 열 가지 품질 차원이 평가되는 기준이 되는 깊이 표면을 이룹니다. 축별 수정 사항은 <harness-root>/memory/expertise-gap-log.md에서 추적됩니다. 성능 축은 경로 필터가 적용된 자체 원칙을 src/apothem/rules/performance-discipline.md에 두며, 클래스별 예산(훅 핸들러, 적합성 게이트 오케스트레이터, 테스트 스위트, 위임 작업자 생성)과 src/apothem/benchmarks/의 정량적 게이트를 함께 담습니다.

언어 표준

이 분류 체계는 실질적 산출물에서 닫힌 어휘 목록을 금지합니다. 마케팅 강조어, 합의에 호소하는 줄임 표현, 아이디어가 전달되기 전에 그것을 누그러뜨리는 모든 헤징입니다. 요구되는 자질이 그것들을 대체합니다. 구체성(모호한 아이디어는 아이디어가 아니라 몸짓입니다), 놀라움(독자가 그것이 오는 것을 예상하지 못합니다), 내적 논리(자체의 논리로 일관됩니다), 생성력(후속 아이디어를 낳습니다), 긴장(최고의 아이디어는 생산적인 모순을 품고 있습니다)입니다.

왜 "창의적이 되어라"가 아니라 이 분류 체계인가

"창의적이 되어라"는 레버리지가 없는 지시입니다. 인지 정체성 분류 체계는 창의성을 기계적인 표면으로 분해합니다. 표준 순서로 발동하는 필터, 탐지 신호에 따라 발동하는 기법, 산출물이 대조하여 입증하는 축, 그리고 비용 압박을 받는 저자가 손을 뻗는 지름길을 잡아내는 어휘 규율입니다. 이 분류 체계는 실행 가능한 형태로 구체화된 인지 아키텍처입니다. 모든 실질적 산출물은 상시 필터를 통과하고, 사소하지 않은 모든 결정은 전체 케이던스를 통과하며, 이는 운영자가 감사할 수 있는 기록이지 어시스턴트가 지켜 주기를 운영자가 바라는 분위기가 아닙니다.


§6. 마무리

apothem은 여러분이 설치하는 바이너리가 아닙니다. 바이너리는 코퍼스를 — src/apothem/harnesses/<harness>/ 아래의 하니스별 어댑터를 통해 — 지원되는 각 도구의 네이티브 구성 디렉터리로 머티리얼라이즈하고, 어시스턴트의 운영 자세로 등록하는 패키징입니다. 제품은 코퍼스입니다 — 열다섯 가지 맨데이트 더하기 스물여덟 가지 횡단 맨데이트 더하기 표준 채널 규율 더하기 인지 정체성 분류 체계 — 그리고 src/apothem/rules/*.md의 규칙 파일이 그 표준 사양입니다.

apothem을 채택하는 프로젝트는 프롬프트가 아니라 거버넌스 체제를 채택합니다. 어시스턴트가 여러분의 저장소에서 생산하는 모든 아티팩트 — 코드, 테스트, 구성, 스키마, 문서, 런북, 커밋 메시지, 브랜치 이름 — 는 동일한 열다섯 막대 사전 방출 게이트를 통과하고, 동일한 공개 원장을 갖추고, 동일한 호스트 발견 관례를 존중하고, 동일한 상호 바인딩을 선언하고, 동일한 코드 장인정신 하위 요소를 충족하고, 동일한 프로덕션 준비 형태로 출하됩니다. 운영자의 레버리지 지점은 프롬프트 튜닝에서 아티팩트 비준으로 이동합니다.

이 주장을 직접 평가하려면 코퍼스를 읽으세요. 저장소를 클론하고, src/apothem/rules/로 가서, 규칙 파일을 아무 순서로나 읽으세요. 모든 규칙은 자기 완결적이고, 모든 바인딩은 상호적이며, 모든 교차 참조는 특정 규칙 경로와 섹션 앵커로 해소됩니다. 규칙들은 종합적으로, 여러분의 프로젝트에서 시니어 기여자가 코드를 쓰는 방식 그대로 코드를 쓰는 어시스턴트를 기술합니다. 바이너리는 그 규칙들을 전달하는 표면입니다.

코퍼스는 바이너리가 바뀐 뒤에도 남는 것입니다.

gh repo clone ahmed-g-gad/apothem
$EDITOR src/apothem/rules/*.md

읽는 것이 곧 평가입니다.

On this page