@tuzi-ince/hi-loop 0.6.0 → 0.6.1

package/docs/guide.md

@@ -364,7 +364,9 @@ hiloop_run({ goal, step: true })
 > ]
 > ```
 > e2e 는 **셸 명령**이어야 한다(엔진은 Playwright MCP 도구를 부를 수 없다 — 그 경우는 스킬이 루프 후
-> MCP 로 돌린다). `flow` 스킬이 UI 작업을 감지하면 이 `checks` 를 자동으로 구성해 넘긴다.
+> MCP 로 돌린다). `checks` 엔진 게이트는 **opt-in**이다: `flow` 스킬은 기본적으로 시작 시 e2e 를 걸지
+> 않고 **루프 통과 후 UI 변경이 있을 때** e2e 여부를 한 번 묻는다. 매 회차 결정론적 강제가 필요할 때
+> (무인·CI, 또는 "매 회차 e2e 로 막아줘"라고 명시)만 이 `checks` 를 시작 시 건다.
 
 > **cwd 기본값은 `CLAUDE_PROJECT_DIR || process.cwd()`.** MCP 는 호스트(클로드코드/커서)가 서버를
 > 띄우는 경로라, "어느 프로젝트인가"의 정답은 호스트가 주입하는 `CLAUDE_PROJECT_DIR` 다. 각 도구에

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tuzi-ince/hi-loop",
-  "version": "0.6.0",
+  "version": "0.6.1",
   "description": "CLI와 MCP 모드를 지원하는 초경량 자율형 자가 치유 엔진",
   "type": "module",
   "license": "MIT",

package/skills/flow/SKILL.md

@@ -84,19 +84,16 @@ user-invocable: true
    - **단계어가 있으면** 위 "인자 문법" 표대로 `stopAfter`(및 필요한 `full`/`ship`/`watch`)를 준다.
      **없으면** `full: true` — 발굴·설계리뷰·코드리뷰를 포함한 전체 라이프사이클로 완료까지.
    - `testCommand`: 프로젝트의 테스트 명령(기본 `npm test`)
-   - **UI 작업이면 e2e 를 엔진 게이트로 넣는다(권장 — LLM 기억에 의존하지 않는 결정론적 강제).**
-     goal 이 UI(화면·컴포넌트·라우팅·스타일)를 건드릴 것 같고 프로젝트에 **셸 e2e 명령**
-     (package.json `test:e2e` 스크립트, 또는 `playwright.config.*` → `npx playwright test`)이 있으면,
-     **먼저 사용자에게 e2e 게이트 여부를 묻고**, 켜기로 하면 `checks` 로 넘긴다:
+   - **e2e 는 시작 시 묻지 않는다.** UI 작업이어도 우선 기본 테스트(`testCommand`)로 루프를 돌린다.
+     e2e 확인은 **통과 후(7단계)** — 구현이 실제로 되고 확인할 UI 변경이 생겼을 때 — 로 미룬다.
+     (구현이 되는지도 모르는 시작 시점에 헷갈리는 e2e 결정을 강요하지 않는다.)
+   - **(고급, opt-in) 매 회차 e2e 강제**: 사용자가 "매 회차 e2e 로 막아줘" 같이 **명시적으로** 원할 때만
+     시작 시 `checks` 를 건다(무인·CI 처럼 결정론적 게이트가 필요한 경우). 셸 e2e 명령과 실행 환경(서버 등)이
+     있어야 한다. 느리고 비싸므로 **기본이 아니다**:
      ```json
-     "checks": [
-       { "cmd": "<기본 테스트, 예: npm test>" },
-       { "cmd": "<e2e 셸 명령>", "when": "<UI 글롭, 예: src/**/*.tsx>" }
-     ]
+     "checks": [{ "cmd": "<기본 테스트>" }, { "cmd": "<e2e 셸 명령>", "when": "<UI 글롭, 예: src/**/*.tsx>" }]
      ```
-     → 엔진이 **UI 변경이 (커밋 전) 워킹트리에 있는 회차마다** e2e 를 돌리고, 통과해야 pass 로 인정한다(조용히 빠지지 않는다).
-   - 셸 e2e 명령이 없고 **Playwright MCP 만** 있으면 `checks` 를 쓰지 않는다(엔진은 MCP 도구를 못 부른다)
-     — 루프 통과 후 7단계에서 MCP 로 돌린다. **둘 다 없으면** e2e 는 스킵한다(도구를 임의 설치하지 않는다).
+     → 엔진이 UI 변경 회차마다 e2e 를 돌려 통과해야 pass 로 인정한다.
 
 5-a. **스텝 이어가기 (step 모드).** 응답이 `⏭ 스텝 완료 …` 로 오면 루프가 **아직 미완**이다.
    그 한 줄 진행(어느 회차·어느 단계인지)을 **사용자에게 중계**한 뒤, **같은 인자로 `hiloop_run` 을
@@ -110,18 +107,20 @@ user-invocable: true
 6. **결과 보고.** `✅ 통과` / `❌ 실패` 와 반복 횟수, 그리고 함께 온 Gaps(검증 한계)를
    사용자에게 전한다. false green(테스트만 초록이고 실제 미완)을 통과로 포장하지 않는다.
 
-7. **e2e 후처리 (스크린샷·리포트, MCP 폴백).** 루프가 통과(✅)한 뒤, 4단계에서 정한 e2e 전략에 따라:
-   - **엔진 `checks` 로 돌린 경우**: e2e 는 이미 게이트로 통과했다(엔진이 강제). 결과 화면(스크린샷)
-     저장이 필요하면 사용자에게 물어 저장한다. **여기서 다시 e2e 를 돌릴 필요는 없다.**
-   - **Playwright MCP 폴백 경우**(셸 e2e 명령이 없어 4단계에서 checks 를 못 건 경우): 사용자에게
-     "UI 변경이 있었습니다. 지금 Playwright MCP 로 e2e 를 돌릴까요?" 물어, 승인 시 MCP 로 실행한다.
-   - **스킵된 경우**(도구 없음): e2e 도구가 없어 스킵했음을 밝힌다 — 통과한 루프를 실패로 만들지 않는다.
-   - 실행한 경우 **결과서·스크린샷을 test 폴더에 저장**한다(예: 리포트 `tests/e2e/report-<날짜시각>.md`,
+7. **e2e 확인 (통과 후 · UI 변경이 있을 때만).** 여기가 e2e 를 정하는 **기본 지점**이다. 루프가 통과(✅)했고
+   **UI(화면·컴포넌트·라우팅·스타일)가 바뀌었으며** e2e 도구가 있으면, **간단히 예/아니오로** 묻는다:
+   > "UI 가 바뀌었어요. 지금 e2e 로 실제 화면을 확인할까요? (예 / 아니오)"
+   - **예** → e2e 실행. **셸 e2e 명령**(package.json `test:e2e`, 또는 `playwright.config.*` → `npx playwright test`)이
+     있으면 그걸, 없고 **Playwright MCP** 만 있으면 MCP 로 돌린다. 서버 등 환경이 필요하면 먼저 확인·기동한다.
+   - **아니오** → 기본 테스트로 충분하다고 보고 넘어간다.
+   - e2e 도구가 **둘 다 없으면** 묻지 말고 스킵했음을 밝힌다(도구를 임의 설치하지 않는다 — 통과한 루프를 실패로 만들지 않는다).
+   - UI 변경이 없으면 e2e 는 해당 없음(묻지 않는다).
+   - **4단계에서 `checks` 엔진 게이트를 이미 걸었다면** e2e 는 이미 게이트로 통과했으니 다시 묻지 않는다(스크린샷 저장만 필요하면 물어 저장).
+   - 실행한 경우 **결과서·스크린샷을 test 폴더에 저장**한다(리포트 `tests/e2e/report-<날짜시각>.md`,
      스크린샷 `tests/e2e/screenshots/`). 날짜·시각은 실제 값으로 채우고 저장 경로를 알린다.
-     스크린샷은 브라우저를 구동하는 도구(Playwright MCP/셸)가 있을 때만 가능하다.
 
-   > 왜 이렇게 나누나: e2e "실행"은 결정론적 게이트라 **엔진(`checks`)**에 맡기는 게 최신 정설이다
-   > (프롬프트 지시는 "제안"이지 "강제"가 아니다). 엔진이 못 부르는 Playwright MCP 만 LLM 이 후처리한다.
+   > 왜 통과 후에 묻나: 구현이 되기 전엔 e2e 결정이 이르고 헷갈린다. **일이 됐고 확인할 UI가 있을 때**
+   > 한 번 묻는 게 자연스럽다. 매 회차 결정론적 강제가 꼭 필요하면(무인·CI) 4단계의 opt-in `checks` 를 쓴다.
 
 8. **커밋 게이트 (git 워크플로).** 테스트가 통과(✅)하고 e2e 게이트까지 끝나면 `commitPolicy` 대로
    **로컬** 커밋한다. **push/PR 은 하지 않는다.** git 저장소가 아니면 건너뛴다.