plan

Plan

설계를 실행 가능한 태스크와 의존관계로 구조화한다.

plan은 산출물이다. 구현하지 않는다.

Step 0 — 컨텍스트 로드

1. 작업 대상 프로젝트의 .loom/index.md를 읽어 도메인 전체 지도를 파악한다.
2. aeira search -s {프로젝트의 .loom 경로} "{입력 키워드}" 로 관련 문서를 식별한다.
3. 식별된 문서에서 aeira graph neighbors -s {프로젝트의 .loom 경로} "{node}" 로 연결 문서를 탐색한다 (outgoing: 연관 concept과 flow, incoming: 참조 decision).
4. 탐색된 concept, flow, decision을 읽는다.

shape에서 넘어온 경우, shape summary를 입력으로 사용한다. triage에서 바로 넘어온 경우, 원본 요구사항을 입력으로 사용한다.

Step 1 — 룰 카탈로그 로드

.loom/rules/index.md를 읽어 어떤 룰과 컨벤션이 있는지 카탈로그를 인지한다.

rule은 이 프로젝트에서 항상 지켜져야 하는 강제적 합의, convention은 강하게 권장되지만 대체 가능한 형태이다. 인덱스를 통해 항목 목록과 각 항목의 호출 상황을 파악한다. 본문은 활용 시점에 필요한 항목을 골라낸 뒤 로드한다.

Step 2 — 분해

입력을 실행 가능한 태스크로 분해한다.

concept과 flow가 분해의 바탕이다 — flow의 단계는 어떤 도메인을 어떤 순서로 구현할지의 단서가 되고, concept은 각 태스크의 범위를 한정한다.

분해의 원칙:

• 각 태스크는 독립적으로 실행 가능한 단위여야 한다
• 태스크 간 복잡도가 대체로 균일해야 한다
• 한 태스크가 너무 크다고 느껴지면 더 쪼갠다

룰 카탈로그 활용

분해 시, 인지한 룰 카탈로그를 도구 선택 절차로 활용한다:

1. 지금 수행하려는 행동을 의식적으로 명시한다
2. 카탈로그에서 그 행동에 적용될 가능성 있는 항목을 골라낸다
3. 골라낸 항목의 본문 파일을 로드해 적용 방식을 파악한다
4. 본문에 따라 태스크를 분해한다

해상도 점검

해상도가 부족한 태스크의 신호:

• 태스크 기술이 "~를 정의한다", "~를 구현한다" 수준에 머물고, 입출력의 형태가 명시되지 않은 경우
• 하나의 태스크에서 새로운 추상화를 도입하면서 그 추상화의 인터페이스 계약이 없는 경우
• 데이터 모델링 태스크의 결과가 후속 태스크에 반영되지 않은 경우

이 신호가 인식되면, 해당 태스크는 실행 전에 shape를 통해 해상도를 올려야 할 수 있다. plan 작성 시점에 인식되면 기록하고, 실행 시점에 발견되면 그때 shape를 호출한다.

분해의 완료는 사용자가 판단한다. 시스템은 "이 정도면 실행 가능한가?"를 물어볼 수 있지만, 최종 결정은 사용자의 몫이다.

Step 3 — 의존관계 식별

태스크 간의 의존관계를 명시한다.

• 어떤 태스크가 다른 태스크를 선행해야 하는가
• 병렬 진행이 가능한 태스크 그룹은 무엇인가
• 크리티컬 패스는 어디인가

의존관계는 사용자가 우선순위와 병렬 진행 가능성을 판단하기 위한 정보이다.

Step 4 — 산출물 작성

.loom/plans/에 plan 파일을 생성한다.

템플릿: ../../templates/plan.md를 읽어 사용한다.

파일 이름 규칙

{plan-제목}.md (예: user-auth-implementation.md)

그래프 갱신

.loom/ 내 문서를 생성하거나 수정한 후 aeira sync -s {프로젝트의 .loom 경로} 를 실행한다.

Summary

plan 완료 시 다음 형식으로 정리한다:

## Plan Summary
- 범위: [이 plan이 다루는 것]
- 태스크 수: [N개 태스크, M개 phase]
- 크리티컬 패스: [가장 긴 의존 체인]
- 열린 질문: [해소되지 않은 것들]