@kaydash9999/banker-plugins 0.13.0 → 0.15.0

package/hooks/graceful-pause.mjs

@@ -0,0 +1,222 @@
+/**
+ * /graceful-pause [memo]: ask the running work to finish only its current step, stop,
+ * report and wait for instructions, without cutting it off the way Esc does.
+ *
+ * A skill or plugin command typed while a turn runs waits until the turn ends. This one
+ * is registered `immediate`, so it runs at once, mid-turn. It appends one user-role row
+ * the person does not see (`$.session.append`); the running turn reads it from its next
+ * model request on, that is once the tool call in flight returns.
+ *
+ * Two ways the note could land wrong are closed here:
+ *   - typed during the turn's last answer, no later request reads it, and the next
+ *     prompt's turn would read a stale pause first: when the turn ends unread and no
+ *     background work is left, a second row voids it;
+ *   - typed while idle with background work or a scheduled wake-up still pending, the
+ *     next notification or scheduled prompt would start the next step: the note goes out
+ *     as a prompt of its own instead, read as the person's (`asUser`), from a timer,
+ *     since the engine refuses a submission made inside the command's own hook (the
+ *     submission would wait on the dispatch that hook holds).
+ *
+ * The background count (tasks in flight plus scheduled wake-ups) is what the last Stop
+ * or SubagentStop reported. A turn cut off
+ * by Esc reports none, so the count can stay high until the next one: the note's last
+ * line covers that, as it tells the model to follow a newer prompt. The module's
+ * variables start over when the plugin reloads; a turn already running then reads as
+ * idle until the next one starts.
+ *
+ * Function hooks run inside the engine with no Node and no DOM: everything goes
+ * through `$`. `immediate` is checked on Claude Code 2.1.289; an older engine gets no
+ * command (it would wait for the turn to end, then answer "nothing to stop"). Codex
+ * has no function hooks.
+ */
+export const COMMAND = 'graceful-pause';
+export const MIN_ENGINE = [2, 1, 289];
+
+const SPEC = {
+  name: COMMAND,
+  description: '지금 단계만 끝내고 멈춘 뒤 보고하고 지시를 기다림. 작업 중에 입력해도 바로 전달',
+  argumentHint: '[멈춘 뒤 다룰 지시나 메모]',
+  immediate: true,
+};
+
+const IDLE = '진행 중인 작업이 없어 멈출 것이 없습니다. 지시를 바로 입력하면 됩니다.';
+const SENT = '정지 요청을 진행 중인 작업에 전달했습니다. 지금 실행 중인 도구 호출이 끝나면 그 단계까지만 마무리하고 멈춥니다.';
+const AGAIN = '이번 작업에는 정지 요청을 이미 전달했습니다.';
+const QUEUED = '백그라운드 작업이나 예약 실행이 남아 있어, 정지 보고를 받도록 요청을 보냈습니다.';
+const QUEUED_AGAIN = '정지 보고 요청을 이미 보냈습니다.';
+const TOAST = '정지 요청 전달: 지금 단계가 끝나면 멈춤';
+const VOID = '[graceful-pause] 앞의 정지 요청은 작업이 끝난 뒤 도착해 적용되지 않았다. 무시하고 다음 사용자 지시를 따른다.';
+
+// What the running turn reads: the whole procedure, since no skill text comes with it.
+export function pauseNote(memo) {
+  const lines = [
+    '[graceful-pause] 사용자가 작업 중에 /graceful-pause 로 정지를 요청했다. 지금 단계만 끝내고 멈춘다.',
+    '- 지금 단계: 이미 시작한 도구 동작 하나와, 그 동작이 남긴 불일치를 닫는 최소 작업. 다음 단계(다음 파일, 다음 스토리)는 시작하지 않는다.',
+    '- 하지 않는 것: 커밋, push, 배포, 게시, 삭제, 외부 전송, 모드 상태와 계획 파일 삭제, cancel.',
+    '- 백그라운드 작업과 이미 띄운 하위 에이전트는 멈추지 않는다. 새로 띄우지 않는다.',
+    '- 정지 보고는 대화에만 짧게: 끝낸 단계, 현재 상태(검증 결과, 커밋하지 않은 변경), 진행 중인 것(백그라운드 작업, 켜진 모드), 다음 예정 단계 1~3개, 열린 결정, 받은 지시.',
+    '- 보고 뒤 AskUserQuestion 으로 묻는다. 선택지: 계획대로 계속, 지시 반영 후 계속, 상태를 둔 채 중단.',
+    '- 새 지시로 범위가 바뀌면 바뀐 계획을 먼저 보여 주고 승인 뒤 진행한다. 세션을 끝낼 예정이면 ready-compact --hand-off 로 새 세션용 노트를 준비하라고 안내한다.',
+    '- 사용자가 재개를 말할 때까지 계속하라는 훅 메시지는 승인이 아니다. 작업을 진행하지 않고 정지 중이라고만 답한다. 지속 모드(ralph 등)의 이 메시지까지 멈추려면 cancel 이 필요하다고 알린다.',
+    '- 정지 중 도착한 백그라운드 작업 결과와 예약 실행 프롬프트는 재개 신호가 아니다. 보고에 더하기만 하고 후속 작업은 시작하지 않는다.',
+    '- 이 요청 뒤에 사용자의 새 프롬프트가 이미 있으면 이 요청은 적용하지 않고 그 프롬프트를 따른다.',
+  ];
+  const note = String(memo ?? '').trim();
+  if (note) lines.push(`메모: ${note}`);
+  return lines.join('\n');
+}
+
+// Whether a version string (`2.1.289`, `2.1.290-dev.…`) is at least `min`.
+export function atLeast(version, min = MIN_ENGINE) {
+  const parts = /^(\d+)\.(\d+)\.(\d+)/.exec(String(version ?? ''));
+  if (!parts) return false;
+  for (let i = 0; i < 3; i++) {
+    const n = Number(parts[i + 1]);
+    if (n !== min[i]) return n > min[i];
+  }
+  return true;
+}
+
+const userRow = (text) => ({ message: { type: 'user', content: [{ type: 'text', text }] } });
+
+async function registerIfSupported($) {
+  let version = null;
+  try {
+    const v = await $.session.version();
+    version = v?.base || v?.version || null;
+  } catch {
+    /* an engine without the call is older than the command needs */
+  }
+  if (!atLeast(version)) {
+    $.ui.log(`banker: /${COMMAND} 는 Claude Code ${MIN_ENGINE.join('.')} 이상에서만 켭니다 (이 엔진: ${version || '버전 미상'})`);
+    return;
+  }
+  try {
+    await $.command.register(SPEC);
+  } catch (err) {
+    $.ui.log(`banker: /${COMMAND} 를 등록하지 못했습니다 (${String(err?.message ?? err)})`);
+  }
+}
+
+// Appends the note to the running turn; the answer the command shows. The note counts
+// as sent before the call returns: a model request starting meanwhile reads the stored
+// row, and a second /graceful-pause meanwhile must not append another.
+async function deliver($, state, memo) {
+  if (state.pending?.turnId === state.main) return { text: AGAIN };
+  const pending = { turnId: state.main, afterStep: state.step, read: false };
+  state.pending = pending;
+  let res;
+  try {
+    res = await $.session.append(userRow(pauseNote(memo)));
+  } catch (err) {
+    res = { deny: String(err?.message ?? err) };
+  }
+  if (res?.deny) {
+    if (state.pending === pending) state.pending = null;
+    return { text: `정지 요청을 전달하지 못했습니다: ${res.deny}` };
+  }
+  $.ui.toast(TOAST);
+  return { text: SENT };
+}
+
+// Idle with background work or a scheduled wake-up pending: the note as a prompt of its
+// own, sent from a timer once the command has answered. A hook that drops the prompt
+// resolves `{ drop }` rather than rejecting.
+function queueReport($, state, memo) {
+  if (state.queued) return { text: QUEUED_AGAIN };
+  state.queued = true;
+  const failed = (why) => {
+    state.queued = false;
+    $.ui.log(`banker: /${COMMAND} 정지 보고 요청을 보내지 못했습니다 (${why})`);
+  };
+  $.clock.after(1, () => {
+    $.prompt.submit({ text: pauseNote(memo), asUser: true }).then(
+      (res) => res?.drop && failed(String(res.drop)),
+      (err) => failed(String(err?.message ?? err)),
+    );
+  });
+  return { text: QUEUED };
+}
+
+// At the main turn's end: a note no later request read is voided unless background
+// work will wake the session (the turn it starts reads the note then).
+async function settlePending($, state) {
+  const { pending } = state;
+  state.pending = null;
+  if (!pending || pending.read || state.background > 0) return;
+  try {
+    await $.session.append(userRow(VOID));
+  } catch {
+    /* nothing more to do: the log line below still tells the person */
+  }
+  $.ui.log('banker: /graceful-pause 요청이 작업 끝에 도착해 적용되지 않았습니다.');
+}
+
+// Nothing in flight: the state a fresh session, or one after /clear, starts from.
+const fresh = () => ({ main: null, step: -1, pending: null, background: 0, queued: false });
+const listed = (v) => (Array.isArray(v) ? v.length : 0);
+const backgroundCount = (e) => listed(e.background_tasks) + listed(e.session_crons);
+
+export function registerGracefulPause(on) {
+  // The main turn in flight and its latest model request; subagent loops raise no
+  // turn.start and end with an agentId. `queued`: a report prompt not started yet.
+  const state = fresh();
+  watchSession(on, state);
+  watchTurns(on, state);
+
+  on('command.run', { command: COMMAND }, async ($, e) => {
+    if (state.main) return deliver($, state, e.args);
+    if (state.background > 0) return queueReport($, state, e.args);
+    return { text: IDLE };
+  });
+}
+
+// The command's registration, a fresh state after /clear, and the background count the
+// stop events report.
+function watchSession(on, state) {
+  on('session.start', async ($, e, next) => {
+    await registerIfSupported($);
+    return next(e);
+  });
+
+  // `/clear` ends the conversation and raises no session.start for the next one.
+  on('session.end', async ($, e, next) => {
+    Object.assign(state, fresh());
+    return next(e);
+  });
+
+  on('classic.Stop', async ($, e, next) => {
+    state.background = backgroundCount(e);
+    return next(e);
+  });
+
+  on('classic.SubagentStop', async ($, e, next) => {
+    state.background = backgroundCount(e);
+    return next(e);
+  });
+}
+
+// The main turn in flight and the model requests it makes. turn.step wraps every
+// request's stream, subagents' too: in the engine's kit that cost 25 to 45 µs a chunk,
+// well under 1% of a request.
+function watchTurns(on, state) {
+  on('turn.start', async ($, e, next) => {
+    Object.assign(state, { main: e.turnId, step: -1, queued: false });
+    return next(e);
+  });
+
+  on('turn.step', async function* ($, e, next) {
+    if (e.turnId === state.main) {
+      state.step = e.index;
+      if (state.pending?.turnId === e.turnId && e.index > state.pending.afterStep) state.pending.read = true;
+    }
+    return yield* next(e);
+  });
+
+  on('turn.complete', async ($, e, next) => {
+    if (e.agentId || e.turnId !== state.main) return next(e);
+    state.main = null;
+    await settlePending($, state);
+    return next(e);
+  });
+}

package/hooks/hooks.json

@@ -1,5 +1,6 @@
 {
-  "description": "banker hooks: obsidizer wiki canonicalization (PostToolUse, inert until `obsidizer --enable`) + anonymous usage counting (PostToolUse Skill / UserPromptExpansion, count-default-on, opt-out BANKER_NO_TELEMETRY, no-op without endpoint) + update-check notification (SessionStart, opt-out BANKER_NO_UPDATE_CHECK).",
+  "description": "banker hooks: obsidizer wiki canonicalization (PostToolUse, inert until `obsidizer --enable`) + anonymous usage counting (PostToolUse Skill / UserPromptExpansion, count-default-on, opt-out BANKER_NO_TELEMETRY, no-op without endpoint) + update-check notification (SessionStart, opt-out BANKER_NO_UPDATE_CHECK). modules: function hooks (Claude Code 2.1.289+) serving /graceful-pause, which runs at once even mid-turn.",
+  "modules": ["./register.mjs"],
   "hooks": {
     "PostToolUse": [
       {

package/hooks/register.mjs

@@ -0,0 +1,12 @@
+/**
+ * banker's function-hooks module: the one file hooks/hooks.json names under
+ * `modules`. Claude Code loads it beside the classic hooks in the same file;
+ * builds without function hooks, and Codex, leave it alone.
+ *
+ * Each feature registers its own hooks; this file only gathers them.
+ */
+import { registerGracefulPause } from './graceful-pause.mjs';
+
+export const register = (on) => {
+  registerGracefulPause(on);
+};

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kaydash9999/banker-plugins",
-  "version": "0.13.0",
+  "version": "0.15.0",
   "description": "banker — Claude Code + Codex CLI plugin (QA, audit, docs, architecture, wiki skills). Install via Claude Code marketplace, or `npm i -g @kaydash9999/banker-plugins` then `banker setup`.",
   "bin": {
     "banker": "bin/banker.js"
@@ -15,10 +15,13 @@
     "!skills/ultra-init-workspace/**",
     "commands",
     ".claude-plugin",
+    "!.claude-plugin/types",
+    "!.claude-plugin/types/**",
     "codex",
     "hooks",
     "bin",
     "!**/*.test.mjs",
+    "!**/*.test.ts",
     "!**/test_*.py",
     "!**/__pycache__",
     "!**/__pycache__/**",

package/skills/3d-intro-build/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 3d-intro-build
-description: "(banker) 브랜드 인트로용 스크롤-스크럽 3D fly-through 사이트를 Azure(gpt-image-2 스틸 + Sora-2 forward-chaining)로 제작: 인터뷰 → 비용 승인 게이트 → 스틸 → fly-through → 로컬 프리뷰. '3d-intro-build'/'3D 인트로'/'스크롤 fly-through'/'인트로 영상 사이트' 시 사용."
+description: "스크롤 위치에 맞춰 3D 플라이스루 영상이 움직이는 브랜드 인트로 사이트를 만듦. Azure 의 gpt-image-2 로 스틸을, Sora-2 로 영상을 생성. 인터뷰 뒤에 비용 승인 게이트에서 사용자가 승인해야만 유료 생성을 시작하고, 스틸, 영상, 로컬 프리뷰 순서로 진행. '3d-intro-build'/'3D 인트로'/'스크롤 fly-through'/'인트로 영상 사이트' 시 사용."
 ---
 
 # 3d-intro-build — 스크롤-스크럽 3D 인트로 제작 (Azure 파이프라인)

package/skills/3d-intro-setup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: 3d-intro-setup
-description: "(banker) Azure Sora-2/gpt-image-2 3D 인트로 제작용 크레덴셜·의존성 설치: Node≥18·ffmpeg 확보 + apikey/엔드포인트/배포명 직접입력 또는 콘솔 샘플 코드 붙여넣기로 크레덴셜 저장 + 무과금 프리플라이트(listVideos·images badreq)로 검증. 'setup-3d-intro'/'3d-intro-setup'/'3D 인트로 설정'/'Azure Sora 크레덴셜' 또는 /banker:setup 시 사용."
+description: "`3d-intro-build` 에 필요한 Node 18 이상과 ffmpeg 를 갖추고 Azure 크레덴셜을 저장함. 크레덴셜은 직접 입력하거나 Azure 콘솔의 샘플 코드를 붙여 넣어 받고, 무과금 프리플라이트로 확인. 'setup-3d-intro'/'3d-intro-setup'/'3D 인트로 설정'/'Azure Sora 크레덴셜' 또는 `/banker:setup` 시 사용."
 ---
 
 # 3d-intro-setup — Azure Sora-2 / gpt-image-2 3D 인트로 제작 전제조건 설치

package/skills/all-in-one/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: all-in-one
-description: "(banker) 한 명령으로 합의 계획→검증 구현→독립 테스트 게이트를 연쇄(ralplan→ralph→ultraqa). 코딩 작업을 계획부터 통과까지 최대 rigor로 한 번에. 'all-in-one'/'all in one' 시 사용(한 줄 수정은 ralph, 아이디어 확장은 autopilot)."
+description: "코딩 작업을 한 명령으로 계획부터 QA 통과까지 엄격하게 진행. `ralplan` 으로 합의 계획, `ralph` 로 검증 구현을 하고 독립 QA 게이트(Claude Code 는 `verify` 순환, Codex 는 `ultraqa`)로 마무리. 'all-in-one'/'all in one' 시 사용. 한 줄 수정은 이 스킬 대신 `ralph`, 아이디어 확장은 `autopilot`."
 argument-hint: "[--short] [--checkpoint] [--critic=critic|architect|codex] [--qa=tests|build|lint|typecheck] [--no-deslop] <task description>"
 level: 4
 ---
@@ -9,18 +9,40 @@ level: 4
 
 [ALL-IN-ONE ACTIVATED — SEQUENTIAL 3-STAGE PIPELINE]
 
-## 0. Prerequisite: OMC (install first if missing)
-
-This skill orchestrates OMC's `ralplan` → `ralph` → `ultraqa`. **Check the dependency before running**; if it is missing, **guide installation first** rather than failing mid-pipeline:
-- Check: `command -v omc` and whether `/oh-my-claudecode:*` skills are available.
-- If missing: install via `/banker:setup` → oh-my-claudecode (or the `setup-omc` skill / `omc update`), then resume. On Codex the equivalent is OMX (`omx setup`).
-
-**런타임 매핑 (Claude Code ↔ Codex).** 이 스킬이 부르는 `ralplan`·`ralph`·`ultraqa`는 Claude Code에선 OMC 스킬이고 **Codex에선 oh-my-codex(OMX)가 제공하는 동명 스킬**이다. 아래 Execution의 `Skill("oh-my-claudecode:<name>")` 표기는 Claude Code 기준 — **Codex 런타임에선 OMC 대신 OMX의 해당 스킬(`ralplan`/`ralph`/`ultraqa`)을 적용**한다.
+## 0. Prerequisite: OMC 5 with a matching `omc` CLI (check first)
+
+This skill orchestrates OMC's `ralplan` → `ralph`, then a QA gate built on OMC's
+`verify` workflow. **Check the dependency before Stage 1**; if it is missing or
+stale, **guide installation first** rather than failing mid-pipeline. The `omc`
+check below is for Claude Code; on Codex check OMX instead (`omx --version`), whose
+`ralph` does not use the `omc` CLI.
+
+- **The `omc` CLI must have `ralph verify` (Claude Code).** OMC 5's `ralph` runs
+  `omc ralph verify` on its first iteration and stops when the command is
+  missing, and a global `omc` CLI older than the plugin (4.x) does not have it.
+  Judge by the output, not the exit code: given `--help`, a 4.x CLI prints its
+  general help and still exits 0. Keep the `--help`: without it, an unknown
+  command makes the CLI launch Claude Code.
+  ```bash
+  omc ralph verify --help 2>&1 | grep -q 'Usage: omc ralph verify' && echo "omc ok" || echo "omc CLI missing or too old"
+  ```
+  ```powershell
+  if ((omc ralph verify --help 2>&1 | Out-String) -match 'Usage: omc ralph verify') { 'omc ok' } else { 'omc CLI missing or too old' }
+  ```
+- **If the check fails:** stop before Stage 1 and guide the fix (`/banker:setup`
+  → oh-my-claudecode, the `setup-omc` skill, or
+  `npm install -g oh-my-claude-sisyphus@latest`), then resume. Do not start a
+  pipeline whose Stage 2 will stop.
+- **`ultraqa` does not exist in OMC 5** (removed in 5.0.0, no alias), so a call
+  to `oh-my-claudecode:ultraqa` fails. Stage 3 below runs in its place.
+- On Codex the equivalent framework is OMX (`omx setup`).
+
+**런타임 매핑 (Claude Code ↔ Codex).** Stage 1·2 의 `ralplan`·`ralph` 는 Claude Code에선 OMC 스킬이고 **Codex에선 oh-my-codex(OMX)가 제공하는 동명 스킬**이다. Stage 3 은 런타임마다 다르다: Claude Code(OMC 5)는 `ultraqa` 가 없어 아래 verify 순환을 직접 돌리고, **Codex는 OMX 가 아직 제공하는 `ultraqa`** 를 쓴다. 아래 `Skill("oh-my-claudecode:<name>")`·`Task(subagent_type="oh-my-claudecode:<name>")` 표기는 Claude Code 기준이다.
 
 ## Purpose
 
 Run one substantial coding task through three independent quality gates in a
-fixed order, each delegated to an existing OMC skill:
+fixed order:
 
 ```
 Stage 1  /ralplan --deliberate     consensus plan (Planner → Architect → Critic)
@@ -29,15 +51,18 @@ Stage 1  /ralplan --deliberate     consensus plan (Planner → Architect → Cri
 Stage 2  /ralph --critic=critic    PRD-driven persistent build, critic-verified
    │     → implementation + deslop + regression, then ralph self-cancels
    ▼
-Stage 3  /ultraqa --tests          independent test-cycling acceptance gate
-         → PASS, or honest STOPPED-with-diagnosis
+Stage 3  QA gate (--qa=tests)      fresh verifier → diagnose → fix, bounded cycle
+         → PASS, or honest STOPPED-with-diagnosis   (Codex: OMX /ultraqa)
 ```
 
 This skill is a **thin sequential orchestrator**. It does not implement, plan,
-or test directly, and it does **not** create its own persistence loop or state
-file — every loop, retry, and verification belongs to the sub-skill it
-delegates to. Its only job is to invoke the three skills in order, bridge their
-handoffs, gate each stage on the previous one's success, and report honestly.
+or test directly, and it does **not** create its own state file. Stages 1 and 2
+hand every loop, retry, and verification to the sub-skill they invoke. The one
+loop all-in-one owns is Stage 3's bounded verify → fix cycle: OMC 5 removed
+`ultraqa`, which used to own it, and its replacement `verify` gathers evidence
+but does not fix. Beyond that, its only job is to run the stages in order,
+bridge their handoffs, gate each stage on the previous one's success, and
+report honestly.
 
 ## Why three stages (and not just ralph)
 
@@ -50,23 +75,24 @@ modes, and each stage's reviewer is independent of the previous stage's author
 2. **A partial or unverified build declared "done"** → Stage 2's PRD
    story-by-story persistence + critic verification catch this.
 3. **Integration / regression breakage slipping past the builder's own checks**
-   → Stage 3's fresh, test-focused, fix-cycling loop catches this.
+   → Stage 3's fresh, test-focused, fix-cycling gate catches this.
 
 **On the apparent redundancy of Stage 3:** ralph (Stage 2) already runs its own
-Step-7 critic verification and Step-7.6 regression re-run on the changed-file
-set. ultraqa (Stage 3) is still worth running because it is *independent* (fresh
-agents, not the ones that built it), *test-suite-focused*, and *actively fixes*
-in a cycle. If ralph's regression already ran the full suite green, ultraqa
-usually confirms in cycle 1 (cheap); its value rises when the suite is broad,
-when changes touched many files, or when integration/flaky issues hide behind
-unit-level checks. Keeping it explicit gives a clean, separate PASS signal.
+Step-7 reviewer verification and Step-7.6 regression re-run (`omc ralph verify`
+against the baseline it recorded). Stage 3 is still worth running because it is
+*independent* (a fresh verifier agent, not the context that built the change),
+*test-suite-focused*, and *actively fixes* in a bounded cycle. If ralph's
+regression already ran the suite green, the gate usually passes in cycle 1
+(cheap); its value rises when the suite is broad, when changes touched many
+files, or when integration/flaky issues hide behind unit-level checks. Keeping
+it explicit gives a clean, separate PASS signal.
 
 ## When to use
 
 - A substantial, mostly-specified coding task you want carried from plan →
   verified implementation → green test gate in one step, with the most
   front-loaded rigor OMC offers.
-- You have been running `ralplan → ralph → ultraqa` by hand and want it as one
+- You have been running `ralplan → ralph →` a QA pass by hand and want it as one
   command.
 - The task is moderately under-specified — that's fine: Stage 1's consensus
   planning absorbs scoping, so all-in-one tolerates vaguer input than raw ralph.
@@ -75,8 +101,9 @@ unit-level checks. Keeping it explicit gives a clean, separate PASS signal.
 
 - **One-line fix or tiny change** → use `/ralph` or delegate to an executor;
   three heavy multi-agent loops is overkill.
-- **Pure exploration / brainstorming** → use `/oh-my-claudecode:plan` or the
-  brainstorming skill; nothing should be implemented yet.
+- **Pure exploration / brainstorming** → use `/oh-my-claudecode:ralplan` on its
+  own (it stops at a `pending approval` plan) or the brainstorming skill;
+  nothing should be implemented yet.
 - **A 2-3 line product idea needing requirements expansion** → use
   `/autopilot` (it expands the idea first) or `/deep-interview`.
 - **Frontend spec / reference-parity work** → use the specialized `/front-qa`.
@@ -88,7 +115,7 @@ unit-level checks. Keeping it explicit gives a clean, separate PASS signal.
 | `--short` | Stage 1 runs ralplan **without** `--deliberate` (skips pre-mortem + expanded test plan) for lower-risk work | off → deliberate |
 | `--checkpoint` | Insert an `AskUserQuestion` approval gate between Stage 1 (plan) and Stage 2 (implement) | off → auto-proceed |
 | `--critic=critic\|architect\|codex` | Reviewer passed to ralph's verification | `critic` |
-| `--qa=tests\|build\|lint\|typecheck` | Goal passed to ultraqa in Stage 3 | `tests` |
+| `--qa=tests\|build\|lint\|typecheck` | What the Stage 3 gate checks (Codex: the goal passed to ultraqa) | `tests` |
 | `--no-deslop` | Passed through to ralph (skip the post-review deslop pass) | off |
 
 Everything before the flags / after them that isn't a recognized flag is the
@@ -118,6 +145,21 @@ then **stops**.
   `APPROVE`): do not auto-proceed. Surface the best plan and ask the user how to
   proceed. Never build on an unapproved plan.
 
+### Before Stage 2 — record what already fails
+
+Run the command(s) of the `--qa` goal once on the unchanged tree and keep the
+failing items (test names, error lines) in this conversation. This
+**pre-change record** is the gate's baseline: it covers checks that are not
+among ralph's feedback commands, and on Codex it is the only baseline there is
+(OMX `ralph` keeps none). Never use `git stash` or `git reset` to get a
+pre-change state for it; if the tree already has changes, take the record from
+a clean copy of HEAD (`git worktree add --detach <tmp> HEAD`, run there, then
+`git worktree remove <tmp>`). A fresh worktree has no installed dependencies
+(`node_modules`, a venv): link or install them there first, and confirm the
+commands really ran — a record made only of "command not found" errors is no
+baseline. The record lives only in this conversation; if the session may
+compact or end before Stage 3, put it in the `ready-compact` note.
+
 ### Stage 2 — Implement: `/ralph`
 
 Precondition: a consensus plan exists and is approved (auto via the invocation,
@@ -131,33 +173,93 @@ its job is to turn the plan's stages into PRD stories and implement + verify
 them, not to re-plan. (This mirrors how autopilot consumes a ralplan plan and
 skips its own planning phase.)
 
-ralph runs its full loop on its own: PRD refinement → implement per story →
-verify acceptance criteria → Step-7 critic verification → Step-7.5 deslop →
-Step-7.6 regression → Step-8 `/oh-my-claudecode:cancel`.
+ralph runs its full loop on its own: feedback baseline (`omc ralph verify
+--write-baseline`) → PRD refinement → implement per story → verify acceptance
+criteria → Step-7 reviewer verification → Step-7.5 deslop → Step-7.6 regression
+→ Step-8 closeout and `/oh-my-claudecode:cancel`.
 
-> ralph's Step-8 cancel clears **ralph/ultrawork** session state — it ends the
+> ralph's Step-8 cancel clears **ralph's own** session state — it ends the
 > IMPLEMENTATION stage, not all-in-one. all-in-one is not a registered OMC mode,
 > so the cancel does not affect it. Let ralph fully finish (reviewer APPROVE +
-> deslop + regression + cancel) **before** Stage 3 — ralph and ultraqa share
-> mutually-exclusive session state, so they must not overlap.
-
+> deslop + regression + cancel) **before** Stage 3, so the gate checks the final
+> tree and no ralph continuation is still steering the session.
+
+- **Settle ralph's questions up front.** ralph 5.6.1 asks the user once for the
+  PRD's `repoQualityClass` (`prototype`, `production` or `library`) when the task
+  does not say. Infer it from repo signals (CI config, test depth, published
+  package metadata) and put it in the handoff; let ralph ask only when the
+  signals conflict.
+- **Give ralph feedback commands that print only failures.** OMC 5.6.1's
+  `omc ralph verify` fingerprints *every* output line of each feedback command,
+  and normalizes only durations written as `<number><unit>`, timestamps, `/tmp`
+  paths and hex ids. A line that changes between runs or when a story adds
+  tests therefore reads as a NEW failure: node:test's default reporter prints
+  `ℹ duration_ms 151.4` and `ℹ tests 8`, so its gate fails on every run with no
+  change at all. In the handoff, tell ralph to set the PRD's `feedbackCommands`
+  **before it records the baseline** to forms whose output is constant on
+  success and names each failure — for node:test,
+  `FORCE_COLOR=0 NODE_NO_WARNINGS=1 node --test --test-reporter=dot 2>&1 | grep -Ev '^[.X]+$'`
+  (the two variables keep color codes from slipping past the filter and
+  warnings with a process id out of the output; adapt the form on Windows);
+  keep build/lint commands that are silent on success. If the gate still flags
+  only such lines, fix the commands and re-record ralph's baseline on the
+  current tree (`omc ralph verify --write-baseline`) — the pre-change record
+  still tells old failures from new ones. Never edit the baseline file by
+  hand; never stash or reset.
+- **Carry the baseline forward.** ralph's own baseline (first iteration) also
+  lists failures that existed before the change; ralph treats them as noise
+  and reports them at Step 8. Note its session id (the `<id>` in its PRD path
+  `.omc/state/sessions/<id>/`) for Stage 3.
 - **If ralph reports a fundamental blocker** (same issue across 3+ iterations,
-  missing credentials, unclear requirement, external dependency down): stop and
-  report. Do **not** run Stage 3 on a broken or partial build and call it done.
-
-### Stage 3 — QA gate: `/ultraqa`
-
-Precondition: Stage 2's ralph has completed and self-cancelled (no session-state
-overlap).
-
-Invoke `Skill(oh-my-claudecode:ultraqa)` with args `--<qa goal>` (default
-`--tests`). ultraqa cycles run-QA → architect-diagnose → executor-fix → repeat
-(max 5; early-exit if the same failure appears 3×).
+  missing credentials, unclear requirement, external dependency down, or the
+  `omc ralph verify` command unavailable): stop and report. Do **not** run
+  Stage 3 on a broken or partial build and call it done.
+
+### Stage 3 — QA gate
+
+Precondition: Stage 2's ralph has completed and self-cancelled.
+
+**Claude Code (OMC 5):** run the bounded cycle that `ultraqa` used to own —
+the same shape as OMC 5's autopilot QA phase. No state file: the cycle count
+lives in this conversation.
+
+1. **Verify, independently.** `Task(subagent_type="oh-my-claudecode:verifier", ...)`
+   — a fresh context that did not build the change. Brief it to follow the
+   `oh-my-claudecode:verify` workflow for the `--qa` goal (`tests` by default;
+   `build`, `lint` or `typecheck` select that check), run the project's real
+   commands, and return **PASS** or **FAIL** with the commands, their output and
+   each failing item.
+   Whether a failure predates the change is not judged by eye. A failure is
+   **pre-existing only** when the pre-change record lists it, or — Claude
+   Code — when `omc ralph verify --session <ralph's session id> --json` leaves
+   it out of `newFailures` (cancel leaves the baseline in place; check that the
+   JSON reports `baselinePresent: true` — without a baseline it reports every
+   current failure as new). **Everything else is new**, and so is a
+   pre-existing failure that points at a file the change touched (as in ralph).
+   If ralph was run again in this session (a resumed run), its first iteration
+   rewrote that baseline on the half-changed tree; then judge by the
+   pre-change record alone.
+2. **PASS** → the gate is met; go to the final report.
+3. **FAIL** → `Task(subagent_type="oh-my-claudecode:architect", ...)` diagnoses
+   the root cause (read-only), then `Task(subagent_type="oh-my-claudecode:executor", ...)`
+   makes the smallest fix inside the change's scope. The next cycle verifies
+   again with a **fresh** verifier, never the one that saw the failure.
+
+Limits: at most 5 verifications. When the 5th still fails, stop without
+another fix (a fix nobody verified is not a result). Stop early when the same
+failure (same test, same error signature) comes back 3 times — that is a
+fundamental problem for the user, not for another cycle. Never fix a baseline
+failure inside this gate; report it.
+
+**Codex (OMX):** run OMX `$ultraqa` with the goal (OMX still ships it). OMX
+keeps no feedback baseline, so hand it the pre-change record, tell it not to
+fix those failures, and report them apart; treat its outcome the same way.
 
 Report the real outcome:
 - **Goal met** → "ALL-IN-ONE COMPLETE" with the cycle count.
-- **Max cycles / same failure 3×** → "STOPPED" with ultraqa's diagnosis. Do
-  **not** claim success if the gate did not reach goal-met.
+- **5 failed verifications / same failure 3×** → "STOPPED" with the verifier's
+  evidence and the architect's diagnosis. Do **not** claim success if the gate did not reach
+  goal-met.
 
 ## Orchestrator rules
 
@@ -165,8 +267,8 @@ Report the real outcome:
   next begins. No skipping, no reordering, no running two stages' loops at once.
 - Emit one clear progress line at each stage boundary so the user always knows
   where the pipeline is (`[all-in-one] Stage 1/3 — planning…`, etc.).
-- Do not add a competing persistence loop or all-in-one-specific state file; the
-  sub-skills own all looping and state.
+- Do not add an all-in-one state file or a second persistence loop. Stages 1–2
+  own their loops and state; Stage 3's bounded cycle is the only loop here.
 - Treat a sub-skill's internal "stop"/"cancel" as the end of *that stage*, never
   as the end of the pipeline (see the Stage 1 and Stage 2 notes above).
 
@@ -178,7 +280,8 @@ When the pipeline ends (complete or stopped), give a concise honest summary:
   (1 line).
 - **Implementation**: stories/stages completed, files changed, the ralph critic
   verdict.
-- **QA**: ultraqa goal, PASS after N cycles or STOPPED-with-diagnosis.
+- **QA**: the gate's goal, PASS after N cycles or STOPPED-with-diagnosis, and
+  the baseline failures that predate the change, listed apart.
 - **Unmet / scope-limited / deferred**: state plainly — never paper over a gate
   that did not pass.
 
@@ -205,21 +308,23 @@ first to expand it into a spec.
 
 ## Stop conditions
 
+- The `omc` CLI check in §0 fails → guide the install/update; do not start.
 - Stage 1 cannot reach consensus → surface best plan, ask the user (don't build).
 - Stage 2 ralph hits a fundamental blocker → stop and report (don't run QA).
-- Stage 3 ultraqa exhausts cycles / repeats a failure 3× → report the diagnosis
-  honestly (don't claim success).
+- Stage 3 fails its 5th verification / sees the same failure 3× → report the
+  diagnosis honestly (don't claim success).
 - User says "stop" / "cancel" / "abort" at any point → run
   `/oh-my-claudecode:cancel` and stop.
 
 ## Final checklist
 
+- [ ] §0: on Claude Code the `omc` CLI answered `omc ralph verify --help` with its usage (Codex: `omx --version`)
 - [ ] Stage 1 produced a consensus plan in `.omc/plans/` (or stopped honestly on
       no-consensus / checkpoint rejection)
 - [ ] Stage 2 received the plan path, completed all PRD stories, passed critic
       verification, and self-cancelled before Stage 3
-- [ ] Stages did not overlap (ralph fully ended before ultraqa began)
-- [ ] Stage 3 ran the chosen QA goal and reached goal-met (or reported STOPPED
-      with diagnosis)
+- [ ] Stages did not overlap (ralph fully ended before the gate began)
+- [ ] Stage 3: a fresh verifier reported the chosen goal met (or STOPPED with
+      diagnosis); baseline failures reported apart, not fixed
 - [ ] Final report states plan/implementation/QA outcomes and any unmet items
       plainly

package/skills/append_wiki/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: append_wiki
-description: "(banker) 새로 배운 비자명 지식을 .omc/wiki에 구조화 적재·병합. 'append_wiki'/'위키 기록'/'wiki에 정리'/'알게 된 내용 기록' 시 사용."
+description: "새로 알게 된 비자명한 지식을 `.omc/wiki` 에 구조화해 넣고 기존 페이지와 병합. 'append_wiki'/'위키 기록'/'wiki에 정리'/'알게 된 내용 기록' 시 사용."
 ---
 
 # append_wiki — 작업 지식을 wiki에 적재

package/skills/arch-diagram/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: arch-diagram
-description: "(banker) 시스템 아키텍처 구성도를 PlantUML과 편집 가능 PPTX로 산출. '아키텍처 다이어그램'/'plantuml'/'pptx 다이어그램'/'구성도' 시 사용."
+description: "시스템 아키텍처 구성도를 PlantUML과 편집 가능 PPTX로 산출. '아키텍처 다이어그램'/'plantuml'/'pptx 다이어그램'/'구성도' 시 사용."
 ---
 
 # arch-diagram — PlantUML + PPTX 아키텍처 다이어그램 산출

package/skills/audit-mock/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: audit-mock
-description: "(banker) 하드코딩·mock/stub·열거형을 read-only 정적 감사로 검출. 'audit-mock'/'하드코딩 검출'/'mock·stub 감사'/'SQL 없이 하드코딩 반환' 시 사용."
+description: "하드코딩된 값, mock, stub, 열거형을 정적 감사로 검출. 코드는 읽기만 함. 'audit-mock'/'하드코딩 검출'/'mock 감사'/'stub 감사'/'SQL 없이 하드코딩 반환' 시 사용."
 ---
 
 # audit-mock — 하드코딩 / mock·stub / 열거형 read-only 정적 감사