용어집
한 곳에서 모든 rasen 용어, 평문으로 정의됨. 한 번 훑어보면 나머지 문서가 더 빨리 읽힙니다.
용어는 주제별로 그룹화된 다음 각 그룹 내에서 알파벳순입니다.
핵심 명사
스펙. 시스템의 일부가 어떻게 동작하는지 설명하는 문서. 스펙은 rasen/specs/에 있고 도메인별로 정리되고 요구사항과 시나리오로 이루어집니다. 스펙은 "이 소프트웨어가 뭘 하나?"라는 합의된 답변입니다. 개념을 참조하세요.
신뢰할 수 있는 단일 소스. 전체 rasen/specs/ 디렉터리. 시스템의 현재, 합의된 동작을 보유합니다. 변경이 편집을 제안하고; 보관이 적용합니다.
변경. rasen/changes/<name>/ 아래 폴더로 패키징된 작업 단위. 변경은 그 작업에 대한 모든 것을 보유합니다: 제안서, 설계, 작업, 그리고 도입하는 스펙 편집. 하나의 변경, 하나의 기능 또는 수정.
산출물. 변경 내 문서. 표준 산출물은 제안서, 증량 스펙, 설계, 작업입니다. 의존성 순서로 생성되고 서로 급여합니다.
증량 스펙. 변경 내 스펙이며 전체 스펙을 다시 명시하지 않고 ADDED, MODIFIED 및 REMOVED 섹션을 사용하여 변경되는 것만 설명합니다. 이것이 rasen이 기존 시스템을 깔끔하게 편집하도록 하는 것입니다. 개념을 참조하세요.
도메인. auth/, payments/ 또는 ui/와 같은 스펙의 논리적 그룹화. 시스템에 대해 생각하는 방식과 일치하는 도메인을 선택합니다.
스펙 내
요구사항. 시스템이 가져야 할 단일 동작, 일반적으로 RFC 2119 키워드로 작성됨: "시스템은 30분의 비활성 후 세션을 만료해야 합니다(SHALL)." 요구사항은 어떻게가 아닌 무엇을 명시합니다.
시나리오. 구체적이고 테스트 가능한 요구사항의 예, 일반적으로 Given/When/Then 형식입니다. 시나리오는 요구사항을 검증 가능하게 만듭니다: 자동화된 테스트를 하나에서 작성할 수 있습니다.
RFC 2119 키워드. 요구사항이 얼마나 엄격한지에 대한 표준화된 의미를 전달하는 MUST, SHALL, SHOULD, MAY 단어. MUST와 SHALL은 절대입니다. SHOULD는 예외를 위한 공간이 있는 권장됨. MAY는 선택사항. 이름은 그들을 정의한 인터넷 표준 문서에서 옵니다.
산출물
제안서 (proposal.md). 변경의 왜와 무엇: 의도, 범위, 고수준 접근 방식. 생성하는 첫 번째 산출물.
설계 (design.md). 어떻게: 기술적 접근 방식, 아키텍처 결정, 접할 것으로 예상되는 파일. 간단한 변경의 경우 선택사항.
작업 (tasks.md). 구현 체크리스트, 체크박스 포함. AI는 /rasen:apply 중에 그것을 진행하고 진행하면서 항목을 체크오프합니다.
생명주기
보관. 변경을 완료하는 행위. 증량 스펙이 메인 스펙에 병합되고 변경 폴더가 rasen/changes/archive/YYYY-MM-DD-<name>/로 이동합니다. 보관 후, 스펙이 새로운 현실을 설명합니다. 개념을 참조하세요.
동기화. 변경의 증량 스펙을 보관하지 않고 메인 스펙에 병합. 대개 자동 (보관이 제공) 하지만 오래 실행되는 변경을 위해 /rasen:sync로 자체적으로 사용 가능. 명령을 참조하세요.
워크플로우와 명령
OPSX. 현재 표준 rasen 워크플로우, 엄격한 단계 대신 유연한 작업 주위에 구축됨. 슬래시 명령 모두 /rasen:로 시작합니다. OPSX 워크플로우를 참조하세요.
슬래시 명령. AI 어시스턴트 채팅에 입력하는 명령, /rasen:propose처럼. 슬래시 명령이 워크플로우를 주도합니다. 터미널 명령이 아닙니다. 명령이 어떻게 작동하는지를 참조하세요.
탐색 (/rasen:explore). 생각 파트너 명령. 코드베이스를 읽고, 옵션을 비교하고, 모호한 아이디어를 구체적인 계획으로 명확히 합니다. 산출물이나 코드를 생성하지 않습니다. 문제가 있지만 아직 계획이 없을 때 권장되는 시작점. 먼저 탐색을 참조하세요.
CLI. 터미널에서 실행하는 rasen 프로그램. 프로젝트를 설정하고, 변경을 나열 및 검증하고, 대시보드를 열고, 보관합니다. rasen의 터미널 절반. CLI를 참조하세요.
스킬. AI 어시스턴트가 자동 감지하고 따르는 명령 폴더 (.../skills/rasen-*/SKILL.md). 스킬은 어시스턴트에 rasen 워크플로우를 전달하기 위한 새로운 크로스 도구 표준입니다.
명령 파일. 도구별 슬래시 명령 파일 (.../commands/rasen-*). 전달이 both일 때 스킬과 함께 설치된 선택적 추가. 거의 직접 건드리지 않습니다.
프로파일. 프로젝트에 설치된 슬래시 명령 집합. Full (기본값)은 모든 워크플로우를 설치합니다. Core는 propose, explore, apply, sync, archive로 축소합니다; custom은 선택하는 모든 부분 집합입니다. rasen config profile로 변경합니다.
전달. rasen이 또한 스킬과 함께 명령 파일을 설치하는지 (both, 기본값) 또는 스킬만 설치하는지 (skills). 스킬은 항상 설치됩니다. 글로벌로 설정되고 rasen update로 적용됩니다.
커스터마이징
스키마. 워크플로우가 어떤 산출물을 가지고 서로 어떻게 의존하는지의 정의. 내장 기본값은 spec-driven (제안서 → 스펙 → 설계 → 작업)입니다. 포크하거나 자신만의 것을 작성할 수 있습니다. 커스터마이징을 참조하세요.
템플릿. 스키마 내 마크다운 파일이며 주어진 산출물을 위해 AI가 생성하는 것을 형성합니다. 템플릿을 편집하면 다시 빌드할 필요 없이 AI의 출력이 즉시 변경됩니다.
프로젝트 설정 (rasen/config.yaml). 프로젝트별 설정: 기본 스키마, 모든 계획 요청에 주입되는 context:, 산출물별 rules:. rasen에 스택과 규칙을 가르치는 가장 쉬운 방법. 커스터마이징을 참조하세요.
컨텍스트 주입. config.yaml의 context: 필드에 프로젝트 배경을 넣어서 AI가 생성하는 모든 산출물에 자동으로 추가됩니다. AI가 별도 파일을 읽기를 바라는 것보다 더 신뢰할 수 있습니다.
의존성 그래프. 산출물 requires: 관계로 형성된 방향 그래프. DAG (방향 무환 그래프: 화살표는 앞으로만 지향, 루프에서 절대 아님), rasen은 다음에 생성할 수 있는 것을 알도록 사용합니다.
인에이블러, 게이트가 아님. 산출물 의존성이 다음에 가능해지는 것을 보여주는 원칙, 다음에 필요한 것이 아닙니다. 언제든지 산출물을 다시 방문하고 편집할 수 있습니다. 한눈에 핵심 개념을 참조하세요.
리포 간 조정 (베타)
이 용어는 계획이 둘 이상의 리포를 걸친 경우에만 적용됩니다. 베타입니다. 대부분의 사용자는 무시할 수 있습니다. Stores 사용자 가이드를 참조하세요.
Store. 유일한 역할이 계획인 독립 리포. 이미 알고 있는 동일한 rasen/ 형태 (스펙과 변경)와 작은 정체성 파일을 가지고 있습니다. 이름으로 한 번 기계에 등록하고, 어디서든지 rasen 명령이 그것에서 작동할 수 있습니다.
Reference. 코드 리포의 rasen/config.yaml에서 그 리포가 그리는 store의 선언. Reference는 읽기 전용입니다: 리포는 자신의 루트를 유지하고, rasen instructions이 참조된 store의 스펙의 인덱스를 얻으며, 각각 정확히 가져올 명령을 포함합니다.
작업 컨텍스트. rasen context가 현재 리포를 위해 조합하는 것: 루트와 참조하는 모든 store, 각각 가져오는 방법을 포함. "뭘 작업하고 있나?"에 대한 답변.
Workset. 함께 여는 개인, 기계-로컬 폴더 집합 (계획하는 code 리포와 함께 store). rasen workset create로 명시적으로 생성됨; 공유 계획 리포에 커밋된 것이 로컬 경로에 대해 없습니다.
참고
- 한눈에 핵심 개념: 한 페이지의 다섯 아이디어
- 개념: 긴 형식 설명
- 명령이 어떻게 작동하는지: 슬래시 명령 vs CLI