feat: 리뷰 이어받기, review --repos, BLOCKED 선택지, Target 오류 안내 (v2.3.0)

README.ko.md

@@ -94,7 +94,7 @@ $EDITOR .sdlc/config.md                          # build, test, lint, run, e2e,
 `lint`, `run`, `e2e` 명령, 화면이나 API를 다룰 `qa` 도구, `human_gates`(기본값
 `intent`, 모든 plan을 직접 승인하려면 `plan` 추가, 위험 플래그가 있는 plan은
 설정과 상관없이 사람이 승인), `knowledge` 폴더, `repos`(리뷰가 묶을 저장소.
-프로젝트 루트 아래 저장소가 많으면 나열하고, 비우면 루트 아래 전부)입니다. `.sdlc/`는
+프로젝트 루트 아래 저장소가 많으면 나열하거나 리뷰마다 `sdlc.sh review <slug> pass --repos "<경로> ..." "<메모>"`로 지정하고, 비우면 루트 아래 전부)입니다. `.sdlc/`는
 `.git/info/exclude`로 git에서 빠집니다. 팀이 배운 것을 공유하려면 `knowledge:`를
 git이 추적하는 폴더로 지정하세요.
 

README.md

@@ -95,7 +95,8 @@ Closed features move to `.sdlc/archive/`. Verified facts move to the
 `lint`, `run` and `e2e` commands, the `qa` tool that drives screens or APIs,
 `human_gates` (default `intent`; add `plan` to approve every plan yourself — a
 plan with a risk flag always asks), the `knowledge` folder, and `repos` (the
-repositories a review binds — list them when the project root holds many;
+repositories a review binds — list them when the project root holds many,
+or name them per review with `sdlc.sh review <slug> pass --repos "<path> ..." "<note>"`;
 empty means every one under it). `.sdlc/` stays
 out of git through `.git/info/exclude`; point `knowledge:` at a tracked folder
 to share what the team learns.

SKILL.md

@@ -77,7 +77,8 @@ finds `.git`.
 `.sdlc/config.md` holds every project value: `build`, `test`, `lint`, `run`,
 `e2e`, `qa` (the tool that drives screens or APIs), `human_gates` (default
 `intent`), `knowledge` (the durable knowledge folder) and `repos` (the
-repositories a review binds; empty means every one under the project root).
+repositories a review binds; empty means every one under the project root;
+`review --repos` names them for one review).
 Records are working
 knowledge, not source: `init` keeps `.sdlc/` out of git through
 `.git/info/exclude`, changing no tracked file. Closed features move

VERSION

@@ -1 +1 @@
-2.2.1
+2.3.0

log/changelog-v2.3.0.md

@@ -0,0 +1,51 @@
+# v2.3.0 — fewer repeated reviews, faster review on large roots
+
+Four fixes from two days of use on a project root holding about 350 git
+repositories and worktrees, where 8 features ran through the loop.
+
+## Changes
+
+- **Review carries over when nothing it judged moved.** `approve plan` used
+  to clear the review PASS every time, so a human resuming a BLOCKED route to
+  retry one scenario had to run a new diff review on unchanged code. One
+  feature did this 12 times: rounds 5 to 15 reviewed the same two commits and
+  found nothing. Now the PASS carries to the new build entry when the
+  build's review was a PASS, every HEAD it bound is unchanged, intent.md is
+  unchanged, and PLAN.md is unchanged outside its Scenarios section.
+  `approve plan` then prints `review PASS carried` and the next step is QA.
+  A new commit in a bound repository, a change to intent.md or to any other
+  PLAN.md section (HTML comments aside), a round in review.md after the
+  recorded review that is not PASS (a passing plan gap check is fine), a review bound to a working tree (`--uncommitted`) or a `.state`
+  written by an older kit still needs a new round. The PLAN.md hash outside Scenarios is stored as
+  `planbody:` in `.state`.
+- **`review --repos "<path> ..."`.** Binding every repository under the root
+  took a median of 109 s per `review` (31 recordings, 201 s at worst);
+  run alone, the repository scan took 125 s, and 0.14 s with three listed
+  repositories. A global `repos:` does not fit a root where each feature
+  commits in a different worktree, so `--repos`, given before the note,
+  replaces `repos:` for one review, with the same checks and commas between
+  entries. It goes with `--uncommitted` in either order. An empty list is
+  refused, as are a repeated flag and `--repos` on a FAIL. A Commit outside
+  the bound repositories now names both `config repos:` (with its current
+  list) and `review --repos` in its error.
+- **BLOCKED choices.** On a human route for a BLOCKED row, Evidence now
+  offers all three choices: remove the scenario (the approval records it),
+  retry with what is missing and a limit on attempts, or drop. Before, only
+  retry was described, and one feature asked the human to approve a new
+  retry 9 times.
+- **Delivery Target errors quote the value.** Three intents in those days first
+  failed with `Delivery Target must be local, pr or deploy` because detail
+  followed the value (`deploy (dev → stg)`, `local commit → push`). The
+  error now quotes what it found, or says `missing`, and points detail to a
+  `- Note:` line, which the intent template now has. Phase 1 says `pr` also
+  covers pushing a branch for review with no pull request.
+
+Selftest adds `reposflag`, `carry` and `target` (119 checks); each fails on
+v2.2.1 for the reported reason.
+
+## Compatibility
+
+Existing records stay valid. A feature whose `.state` has no `planbody:`
+keeps the v2.2.1 behavior until its next plan approval, which records it.
+Messages for `repos:` errors now start with `config repos:` or
+`review --repos`, naming where the list came from.

phases/1-intent.md

@@ -22,8 +22,11 @@ risks in that understanding — confirmed before anyone explores deeply.
      gets built or leaves the authorized scope. Ask them one at a time and
      record each answer in place as `— resolved: <answer, source>`. Other
      uncertainty is written as `[assumed: why]`.
-   - **Delivery** — `local`, `pr` or `deploy`, and `Authorized: yes —
-     "<the human's words>"` when they authorized it, else `no`.
+   - **Delivery** — `local`, `pr` or `deploy` alone on the Target line
+     (`pr` also covers pushing a branch for review with no pull request),
+     details such as branch or environment on a `Note:` line, and
+     `Authorized: yes — "<the human's words>"` when they authorized it, else
+     `no`.
 4. Several independent outcomes → one slug each; list them under Understood
    as.
 5. A bug report also records what was done, what happened against what was

phases/3-build.md

@@ -34,7 +34,10 @@ approval, review the uncommitted change instead. The reviewer appends a round
 to `review.md` ending in `VERDICT: PASS` or `VERDICT: FAIL`. Record it with
 `sdlc.sh review <slug> pass|fail "<one line>"`: the script reads the verdict
 of the newest round (every recording needs a new one) and binds a PASS to the
-HEAD of every repository under the project root (or in config `repos:`);
+HEAD of every repository under the project root (or in config `repos:`, or
+in `--repos "<path> ..."` given before the note, which replaces `repos:` for
+that review: name the repositories the change touches when the root holds
+many);
 `score` and `close` compare only the repositories named on evidence `Commit`
 lines, and each Commit must be that HEAD. For a review of the uncommitted
 change, record `sdlc.sh review <slug> pass --uncommitted "<one line>"`: the

phases/4-evidence.md

@@ -31,7 +31,11 @@ checked out — then counts and routes:
 BLOCKED counts as not passed. Each kind of return is capped at three; after
 that the route is human. On a human route, show the human the score lines,
 the failing rows and their logs; they resume with `sdlc.sh approve plan
-<slug> --human` or drop the feature.
+<slug> --human` or drop the feature. For a BLOCKED row, offer all three:
+remove the scenario (the approval records the removal and the gap), retry
+with what is missing and a limit on attempts, or drop. When intent.md, the
+HEADs a PASS bound (not a working tree) and PLAN.md outside Scenarios are
+unchanged, the approval keeps the review PASS: go straight to QA.
 
 ## Deliver