모델 성능이 높아진 뒤 기존 구현 하네스를 다시 평가한 이유
+WIGTN Plugin은 제품 개발에서 반복되는 요청을 Codex에서 다시 사용할 + 수 있게 만들면서 시작했다. 아이디어를 제품 요구사항 문서(PRD)로 + 정리하고, 요구사항을 구현 작업과 검사에 연결하고, 실제로 완료됐는지 + 확인한 뒤, 필요한 경우 코드 변경 저장(commit)이나 검토 요청(pull + request)까지 준비하는 흐름이다.
+이 글에서 하네스는 모델에 추가한 작업 순서, 검사 절차, 완료 규칙을 + 가리킨다. 모델이 작업을 충분히 구조화하지 못할 때는 문제를 단계로 + 나누고 검사를 반복하도록 지시해 부족한 부분을 보완할 수 있었다. + 그러나 모델이 좋아지면서 저장소 탐색, 원인 분석, 구현 계획, 코드 + 수정, 테스트 실행은 점점 모델의 기본 동작이 됐다.
+모델은 달라졌지만 하네스가 그대로 남아 있으면 보완이 중복으로 + 바뀐다. 모델이 이미 세운 계획 위에 다시 계획을 만들고, 이미 실행한 + 검사를 다른 형식으로 기록하며, 끝낼 수 있는 작업을 추가 절차 때문에 + 계속 이어간다. 이 경우 하네스는 안전성을 높이기보다 실행 비용과 작업 + 간섭을 늘릴 수 있다.
+평가 질문은 다음과 같이 정했다.
++평가 질문
+ 모델의 구현 능력이 높아진 뒤에도, 이전에 만든 무거운 하네스가 코드 + 결과를 더 좋게 만드는가? 아니면 모델이 이미 잘하는 일을 반복하며 + 비용만 늘리는가?
Claude Code용 플러그인을 그대로 옮기지 않은 이유도 여기에 있다. + 역할별 에이전트, 즉 서로 다른 역할을 맡은 AI 작업자와 고정된 명령 + 흐름을 Codex에 그대로 적용하면 Codex가 이미 잘하는 일을 반복할 + 가능성이 컸다. 그래서 Codex용 구현은 별도 저장소에서 다시 설계했다.
++설계 원칙
+ 모델이 좋아질수록 구현을 지휘하는 절차는 줄어야 한다. 플러그인은 + 모델이 알 수 없는 팀의 요구사항과 완료 기준을 일관되게 적용하는 데 + 집중한다.
Codex 기본 기능과 플러그인 역할의 구분
+WIGTN Plugin은 Codex보다 코드를 더 잘 쓰게 만드는 프롬프트 묶음이 + 아니다. 제품 개발 과정에서 반복해서 확인해야 하는 입력, 산출물, 완료 + 조건을 재사용 가능한 기능으로 만든 플러그인이다.
+
+
+
- | Codex의 기본 동작에 맡기는 일 | WIGTN Plugin이 맡는 일 |
|---|---|
| 저장소 탐색과 원인 분석 | 아이디어를 구현 가능한 PRD와 화면 명세로 정리 |
| 코드 수정과 리팩터링 | 요구사항을 작업과 실행 가능한 검사에 연결 |
| 저장소에 이미 있는 테스트 실행 | 구현자의 완료 주장과 실제 실행 결과를 구분 |
| 일반적인 구현 순서 판단 | 중단 후 재개 상태와 변경된 요구사항을 추적 |
| 코드 변경안 작성 | commit·push·PR의 요청 범위와 현재 Git 상태 확인 |
- +141.2%
- 같은 성공에 개정 전 Plugin이 사용한 output token 중앙값 증가분이다.
+
+ 03 · 평가 설계
+
-
-
- 01 · Product origin
-
-
-
- 02 · Research question
-
-
-
- 03 · Method
-
-
-
- 04 · Results
-
-
-
- 05 · Design changes
-
기능도 이 경계에 맞춰 나눴다. Product Spec은 PRD를 만들고, Screen + Spec은 화면과 사용자 흐름을 구체화한다. Work Planner는 요구사항을 + 작업과 검사에 연결한다. Acceptance Verifier는 코드가 있다는 사실만 + 보지 않고 관련 테스트가 실제로 통과했는지 확인한다. Release + Readiness는 검토가 끝났다는 상태와 저장소를 실제로 변경할 권한을 + 구분한다.
+전체 구현과 검증 흐름을 묶은 verified-delivery는 사용자가
+ 그 흐름을 명시적으로 요청했을 때만 사용한다. 각 기능은 필요한
+ 요청에서만 선택되며, 일반 코딩 요청에는 전체 흐름을 자동으로
+ 적용하지 않는다.
동일 모델에서 플러그인 사용 여부만 바꾼 비교
+PRD나 검증표가 유용하다는 사실이 코드 결과까지 좋아진다는 뜻은 + 아니다. 추가 지침과 계획 단계는 모델이 문제를 푸는 방식과 멈추는 + 시점을 바꾼다. 성공률은 그대로인데 실행 시간과 토큰만 늘어날 수도 + 있다.
+평가에서는 플러그인을 사용하지 않은 조건을 Bare, 같은
+ Codex에 WIGTN Plugin만 추가한 조건을 Plugin이라고 불렀다.
+ 같은 모델이 같은 과제를 풀게 하고 플러그인 사용 여부만 바꿔, 모델
+ 세대 차이가 결과에 섞이지 않게 했다.
따라서 이 평가는 “모델 세대가 올라갈 때마다 하네스의 효과가 반드시 + 줄어든다”는 인과관계를 직접 증명하지 않는다. 대신 강한 모델을 고정한 + 상태에서 이전 하네스가 추가 이득을 만드는지 확인한다. GPT‑5.5 결과는 + 이전 세대와 최신 세대의 점수 차이가 아니라, 플러그인이 코드 작성보다 + 정해진 문서 형식에서 더 분명한 효과를 보였다는 보조 근거로만 + 사용했다.
+
+
+
- | 평가층 | 확인한 질문 | 확인한 값 |
|---|---|---|
| 제품 규칙 | PRD와 완료 판정이 정해진 형식과 상태를 지키는가 | 요구사항 ID, 미결정 항목, 실행 근거 |
| 일반 코딩 | 플러그인이 원래 성공하던 작업을 방해하는가 | 숨은 테스트, 범위 밖 수정, 불필요한 산출물 |
| 실제 버그 수정 | 같은 코드 과제의 성공 여부가 달라지는가 | resolved 여부 |
| 실행 비용 | 같은 결과에 얼마나 더 많은 작업이 필요한가 | 시간, 출력 토큰, 실행 명령 수 |
- 0/3 → 3/3
- GPT‑5.5에서 명시한 PRD 계약의 충족률은 Plugin 사용 시 높아졌다.
+
+ 04 · 평가 결과
+
-
- 주 비교에는 GPT‑5.6 Sol과 실제 오픈소스 버그 수정 과제 모음인 + SWE-bench Verified에서 선별한 두 과제를 사용했다. 과제별로 Bare와 + 이전의 무거운 플러그인 절차를 두 번씩 실행해 네 쌍을 만들었고, 첫 + 반복과 두 번째 반복의 실행 순서를 바꿨다. 모든 실행은 과제별로 + 격리된 실행 환경(Docker)의 깨끗한 작업공간에서 시작했다.
+외부 과제는 다음 기준으로 사전 점검했다.
+-
+
- 문제문과 기준 commit이 고정되어 있는가. +
- 수정 전에는 핵심 테스트가 실패하고 정답 패치는 통과하는가. +
- 새 동작을 확인하는 테스트가 문제문의 요구사항과 맞는가. +
- 새 코드를 적용한 뒤 기존 동작이 깨지지 않았는지도 확인하는가. +
- 모델이 숨은 테스트와 정답 패치를 볼 수 없는가. +
이 글에서는 새 동작과 기존 동작을 확인하는 테스트를 모두 통과한
+ 실행을 resolved로 분류했다. 두 과제에 두 번의 반복만
+ 적용한 개발 표본이므로 통계적 유의성이나 일반적인 성능 향상은
+ 주장하지 않는다.
코드 성공률은 같고 실행 비용은 증가
+GPT‑5.6 Sol의 주 비교에서 Bare와 이전 플러그인 절차는 모두 네 번 중 + 네 번 과제를 해결했다. 플러그인이 성공을 실패로 바꾼 경우도, 실패를 + 성공으로 바꾼 경우도 없었다.
+
+
- 4/4 = 4/4Bare와 이전 Plugin의 해결 횟수
+ +151.7%같은 성공에서 늘어난 중앙 실행 시간
+ 0건무결하고 반복 가능한 코드 개선 사례
- 일반 코딩은 Codex의 기본 동작에 맡긴다. WIGTN Plugin은 PRD 형식,
- 요구사항 ID, 수용 근거, 중단 재개 상태, Git 권한처럼 모델이
- 스스로 알 수 없는 제품 개발 규칙을 맡는다.
-
-
- - 0.3.0에서는 구현을 지휘하는 절차를 줄이고 Specification, - Planning, Verification, Release의 네 경계에 기능을 집중했다. -
-- 이 보고서는 일반 코드 품질 향상을 주장하지 않는다. 어디에서 - Plugin이 도움이 됐고, 어디에서는 비용이 됐는지 측정한 뒤 제품 - 설계를 고친 과정을 보고한다. -
-왜 WIGTN Plugin을 만들었나
- -반복되는 제품 개발 요청을 기능으로 묶었다
-- Codex를 사용하다 보면 “아이디어를 PRD로 정리해줘”, “화면 - 명세와 구현 계획으로 바꿔줘”, “요구사항이 코드에 반영됐는지 - 확인해줘”, “변경 범위를 검토하고 커밋해줘” 같은 요청이 반복된다. -
-- 매번 긴 프롬프트로 작업 순서와 출력 형식을 설명하는 대신, - WIGTN Plugin에 담을 제품 개발 규칙을 호출 가능한 Codex skill로 - 묶는 것이 출발점이었다. 목표는 코딩 방식을 통제하는 것이 아니라 - 반복 작업의 입력, 산출물, 완료 조건을 일정하게 만드는 것이었다. -
- -Claude 플러그인을 복사하지 않고 Codex용으로 다시 설계했다
-- 기존 Claude Code 플러그인의 역할 agent, slash command, 고정 - 오케스트레이션은 Codex의 skill 선택 방식과 기본 구현 루프에 - 그대로 맞지 않는다. 같은 역할을 중복하거나 일반 코딩 요청까지 - 무거워질 수 있었다. Claude 플러그인은 수정하지 않고 Codex용 - 구현을 별도 저장소에 만들었다. -
- -
-
-
-
-
- | 설계 원칙 | Codex 구현 |
|---|---|
| 한 기능, 한 책임 | Product Spec, Work Planner, Acceptance Verifier, Release Readiness를 독립 skill로 분리 |
| 기본 동작 보존 | 일반 구현·버그 수정에는 Plugin workflow를 자동 적용하지 않음 |
| 강한 경로는 명시 호출 | verified-delivery는 사용자가 지정했을 때만 실행 |
| 결과로 판정 | 문서 길이보다 코드, 실행 테스트, 실제 Git 상태를 사용 |
| 외부 변경은 별도 권한 | review, commit, push, PR 요청을 서로 다른 권한으로 취급 |
제품이 제공하는 기능
-
-
-
-
- | 기능 | 산출물 또는 판정 |
|---|---|
| Product Spec | Compact/Full PRD, 안정적인 requirement ID, 누락 결정 |
| Screen Spec·Design Direction | IA, 사용자 흐름, 화면 명세, lo-fi handoff |
| Work Planner | requirement→task→check WorkGraph, resume, source drift |
| Acceptance Verifier | 요구사항별 code evidence와 executed-test evidence |
| Verified Delivery | 명시 호출 기반 fast/assurance 구현·검증 경로 |
| Release Readiness | 실제 Git 상태와 사용자 권한에 따른 commit·push·PR |
왜 모델 성능까지 측정했나
-- 유용한 산출물을 만드는 Plugin이 구현 과정에도 항상 도움이 되는 - 것은 아니다. skill 설명, 계획 단계, 별도 검사, evidence 표는 - 모델의 탐색과 종료 판단을 바꾼다. 성공률이 그대로인데 명령과 - token만 늘 수도 있다. -
- -
-
-
-
- | 연구 질문 | 측정값 |
|---|---|
| RQ1. 일반 코딩을 방해하는가 | Plugin이 Bare 성공을 실패로 바꾼 pair |
| RQ2. 코드 결과를 개선하는가 | Bare 실패 / Plugin 성공 pair |
| RQ3. 제품 계약을 더 잘 지키는가 | PRD·acceptance contract 충족률 |
| RQ4. 같은 결과에 비용이 얼마나 드는가 | wall time, output token, command |
- GPT‑5.5+Plugin과 GPT‑5.6 Bare를 직접 비교하지 않았다. 각 모델 - 안에서 같은 task와 실행 조건을 사용하고 Plugin만 켜고 껐다. -
-평가 방법
- -서로 다른 결과를 하나의 점수로 합치지 않았다
-
-
-
-
-
- | 평가층 | 확인한 것 | 자료 |
|---|---|---|
| 계약 회귀 | manifest, trigger, schema, authority | 저장소 정적 검사 |
| 산출물 행동 | PRD·acceptance 형식 준수 | GPT‑5.5/5.6 smoke, ablation |
| 실제 bug fix | 같은 코드 과제의 성공률과 비용 | SWE-bench Verified |
| 어려운 feature | ceiling을 낮춘 positive lift | FeatureBench pilot |
외부 과제 포함 기준
--
-
- 문제문과 base commit이 고정되어 있다. -
- clean base에서 핵심 test가 실패한다. -
- gold patch가 같은 evaluator를 통과한다. -
- fail-to-pass test가 문제문에 적힌 동작을 검사한다. -
- pass-to-pass test가 기존 동작의 회귀를 검사한다. -
- 격리된 환경에서 재현된다. -
- agent가 hidden test와 reference patch를 볼 수 없다. -
주효과 평가 설정
-
-
-
-
-
- | 모델 | gpt-5.6-sol, reasoning high |
|---|---|
| Codex CLI | 0.145.0 |
| Benchmark | princeton-nlp/SWE-bench_Verified |
| 과제 | astropy__astropy-12907, pytest-dev__pytest-10051 |
| 반복 | 과제당 2회, Bare→Plugin / Plugin→Bare 순서 교차 |
| 환경 | 공식 per-instance Docker, 매 trial clean workspace |
| 판정 | official resolved, pass-to-pass, wall time, output token, command |
- 분석 단위는 task × repetition의 paired block 네 개다. 표본이 - 작고 discordant pair가 없어 통계적 유의성을 주장하지 않는다. -
-결과
- -GPT‑5.6 Sol: 성공률은 같고 비용은 늘었다
-
-
-
-
-
- | 과제 | Bare | 개정 전 Plugin |
|---|---|---|
| Astropy, trial 1 | resolved | resolved |
| Astropy, trial 2 | resolved | resolved |
| Pytest, trial 1 | resolved | resolved |
| Pytest, trial 2 | resolved | resolved |
| 합계 | 4/4 | 4/4 |
-
-
-
- | 중앙값 | Bare | 개정 전 Plugin | 증감 |
|---|---|---|---|
| wall time | 120.21s | 302.62s | +151.7% |
| output token | 3,613 | 8,715.5 | +141.2% |
| command | 12.5 | 16.5 | +32.0% |
- 모든 patch가 fail-to-pass와 pass-to-pass를 통과했다. Plugin이 - 성공을 망가뜨린 pair도, 실패를 성공으로 바꾼 pair도 없었다. - 작은 bug fix에 추가한 별도 harness와 evidence 절차는 이 - 표본에서 비용으로 남았다. -
- -FeatureBench: 재현된 positive lift는 0건이었다
-
-
-
-
- | 과제 | Bare | Plugin | 판정 |
|---|---|---|---|
| Seaborn | 11.76% | 첫 실행 100% | reference source 접근으로 무효, 재시험 tie |
| Sphinx | 7.69% | 7.69% | tie |
| MLflow | 0% | 0% | tie |
| Mypy | 30% | 30% | tie |
- Seaborn 실행은 workspace 밖에 설치된 동일 프로젝트의 함수 - 본문을 읽어 무효 처리했다. 새 workspace에서 순서를 바꿔 - 재시험하자 두 arm 모두 unresolved였다. 무결성 적격 positive와 - 재현된 positive는 각각 0건이다. -
- -GPT‑5.5: PRD 계약에는 효과가 있었고 코딩 성공률은 같았다
-
-
-
-
- | 평가 | Bare | Plugin | 해석 |
|---|---|---|---|
| PRD smoke, 3회 | 0/3 | 3/3 | 명시한 PRD 계약 충족 |
| PRD package ablation, 2회 | 0/2 | 2/2 | 길이가 아닌 skill 내용 효과 |
| uncertain acceptance, 3회 | 3/3 | 3/3 | 동률 |
| ordinary coding, 3회 | 3/3 | 3/3 | 동률, 쉬운 과제 |
| 실제 Pytest 구현, 1회 | resolved | resolved | 탐색적 비간섭 |
- PRD 결과는 WIGTN Plugin이 정한 requirement ID, 결정 항목, - acceptance 형식의 재현성을 뜻한다. 일반 문서 품질의 보편적 - 향상을 뜻하지 않는다. -
-실험 뒤 무엇을 바꿨나
- -
-
그림 1. 구현 중심 하네스에서 경계 중심 Plugin으로
-
- 추가 절차의 양이 아니라 작업의 실패 표면으로 경로를 선택한다.
-
-
-
- 06 · Product direction
-
-
-
- 07 · Claim boundary
-
-
-
- 08 · Next evaluation
-
-
-
- 09 · Reproduction
-
+
+ 05 · 설계 개정
+
+
+
+ 06 · 개정 구조 검증
+
+
+
+ 07 · 주장 범위와 한계
+
+
+
+ 08 · 후속 평가
+
+
+
+ 09 · 평가 및 감사 자료
+
+
diff --git a/plugins/wigtn-knowledge-wiki/.codex-plugin/plugin.json b/plugins/wigtn-knowledge-wiki/.codex-plugin/plugin.json
index 97b30a5..7497ea6 100644
--- a/plugins/wigtn-knowledge-wiki/.codex-plugin/plugin.json
+++ b/plugins/wigtn-knowledge-wiki/.codex-plugin/plugin.json
@@ -1,6 +1,6 @@
{
"name": "wigtn-knowledge-wiki",
- "version": "0.5.2",
+ "version": "0.5.3",
"description": "Opt-in, gated Codex session knowledge capture for an explicitly authorized personal wiki namespace.",
"author": {
"name": "WIGTN"
diff --git a/plugins/wigtn-plugins-with-codex/.codex-plugin/plugin.json b/plugins/wigtn-plugins-with-codex/.codex-plugin/plugin.json
index d5c9a0d..3933ea9 100644
--- a/plugins/wigtn-plugins-with-codex/.codex-plugin/plugin.json
+++ b/plugins/wigtn-plugins-with-codex/.codex-plugin/plugin.json
@@ -1,6 +1,6 @@
{
"name": "wigtn-plugins-with-codex",
- "version": "0.5.2",
+ "version": "0.5.3",
"description": "Selective product contracts for Codex: compact PRDs, saved WorkGraphs, scoped screen artifacts, acceptance evidence, explicit verified delivery, and safe release actions.",
"author": {
"name": "WIGTN"
diff --git a/plugins/wigtn-plugins-with-codex/scripts/validate-screen-spec.py b/plugins/wigtn-plugins-with-codex/scripts/validate-screen-spec.py
index f46bce5..f139dc6 100644
--- a/plugins/wigtn-plugins-with-codex/scripts/validate-screen-spec.py
+++ b/plugins/wigtn-plugins-with-codex/scripts/validate-screen-spec.py
@@ -23,10 +23,10 @@
"wireframe": {"ia", "screen"},
"handoff": {"ia", "flow", "screen", "wireframe"},
}
-KNOWN_PLACEHOLDER = re.compile(
- r"\{(?:feature-name|YYYY-MM-DD|route-[^}]+|slug-[^}]+|role-[^}]+|"
- r"audience|auth|요약|분기|처리|대상 화면|endpoint|sub-task-list)[^}]*\}"
-)
+# Template tokens start immediately after ``{`` and do not contain CSS-style
+# declarations. This catches new project-native placeholders without mistaking
+# ordinary formatted CSS blocks (``{ color: ...; }``) for unresolved tokens.
+KNOWN_PLACEHOLDER = re.compile(r"\{(?=[A-Za-z0-9가-힣])[^{}\n;:]+\}")
REQ_ID = re.compile(r"\b(?:FR|REQ|AC)-[A-Za-z0-9][A-Za-z0-9._-]*\b")
ANCHOR_REF = re.compile(r"04-WIREFRAME\.html#([A-Za-z][A-Za-z0-9._:-]*)")
HTML_ID = re.compile(r'\bid=["\']([A-Za-z][A-Za-z0-9._:-]*)["\']')
@@ -125,7 +125,8 @@ def main() -> int:
require(flow, "```mermaid", "02-USER-FLOW.md", errors)
require(flow, "Flow Coverage", "02-USER-FLOW.md", errors)
if handoff:
- require(handoff, "FR", "05-DEV-HANDOFF.md", errors)
+ if not REQ_ID.search(handoff):
+ errors.append("05-DEV-HANDOFF.md: missing requirement ID")
require(handoff, "Suggested Implementation Order", "05-DEV-HANDOFF.md", errors)
anchors: list[str] = []
diff --git a/plugins/wigtn-plugins-with-codex/skills/acceptance-verifier/SKILL.md b/plugins/wigtn-plugins-with-codex/skills/acceptance-verifier/SKILL.md
index b4c977d..d0df97f 100644
--- a/plugins/wigtn-plugins-with-codex/skills/acceptance-verifier/SKILL.md
+++ b/plugins/wigtn-plugins-with-codex/skills/acceptance-verifier/SKILL.md
@@ -1,80 +1,43 @@
---
name: acceptance-verifier
-description: Verify whether an implementation satisfies PRD requirements or acceptance criteria using code and executed-test evidence. Use for “요구사항 반영됐는지 검증”, “PRD 충족 확인”, requirement coverage, or acceptance verification. Do not use for a general code review or when no requirements can be identified.
+description: Verify PRD requirements or acceptance criteria against code and executed tests. Use for “요구사항 반영됐는지 검증”, PRD coverage, or acceptance verification. Do not use for general code review or when no requirements can be identified.
---
# Acceptance Verifier
-Produce an evidence-backed requirement matrix. This is read-only unless the user also asks to fix gaps.
+Produce a read-only requirement matrix unless the user also asks to fix gaps.
## Workflow
-0. If `.wigtn/project.json` exists, validate it and read
- [project context](../../references/project-context.md) for requirement
- sources, protected paths, and the configured evidence path.
- If `.wigtn/workgraph.json` exists, validate it and run `wigtn.py diff
- --check`. Treat stale task or check status as a verification gap.
-1. Locate the authoritative PRD, acceptance criteria, issue, or user-provided requirements.
- Treat WIGTN, Spec Kit, OpenSpec, and BMAD Markdown as inputs, not as
- lifecycle instructions that must be re-run.
-2. Identify the requested implementation scope: working tree, commit, branch comparison, PR, or named files.
-3. Extract stable requirement IDs. If none exist, create temporary `AC-01` IDs and say they are local to the report.
-4. Inspect implementation and tests. Run the smallest meaningful repository-defined checks when authorized and feasible.
-5. Assign exactly one canonical status per requirement:
- - `verified`: implementation evidence plus a relevant passing check
- - `implemented-not-executed`: implementation exists but no relevant check ran
- - `partially-verified`: only part of a material requirement is supported
- - `not-satisfied`: required behavior is absent or contradicted
- - `not-verifiable`: available evidence cannot support a conclusion
- - `not-applicable`: the requirement is outside the evaluated scope
-6. Cite code evidence as clickable file and line references. Record commands, exit codes, and relevant test names. Never infer that unexecuted tests passed.
-7. Separate issues outside the requirement set under `Out-of-scope findings`.
-
-Use the matrix and decision rules in [evidence matrix](references/evidence-matrix.md).
-
-## Machine-readable handoff
-
-Use the same canonical values in human reports and saved artifacts; add a
-localized display label when useful, but do not maintain a second status
-taxonomy. Do not create state for an ordinary verification answer. When the user requests
-a saved artifact, an existing `.wigtn/evidence.json` must be continued, or a
-cross-session handoff is required, read
-[the shared evidence contract](../../references/evidence-contract.md).
-
-Validate a written artifact with
-`python3 ../../scripts/validate-evidence.py ` from this skill directory.
-For an explicit machine-readable handoff from Spec Kit, OpenSpec, BMAD, or
-generic Markdown, run from the repository root:
-
-```bash
-python3 /scripts/import-requirements.py \
- --output .wigtn/evidence.json
-python3 /scripts/validate-evidence.py .wigtn/evidence.json
-```
-
-The importer initializes requirements as `not-verifiable`; only repository
-inspection and executed checks may raise their status.
-To resume an existing handoff after its source specification changes, add
-`--existing .wigtn/evidence.json`. Preserve evidence only for unchanged
-requirement IDs and text; changed requirements are invalidated, removed IDs
-are recorded in metadata, and release authority resets.
-Before trusting an existing artifact, run
-`python3 /scripts/inspect-evidence.py .wigtn/evidence.json --root .`
-and treat source drift or missing code evidence as an explicit verification
-gap.
-When a saved WorkGraph exists, report which task IDs the evidence can support.
-Do not change a task to `verified` unless its linked requirement is current,
-its check actually passed, the check links back to the task, and an evidence
-reference was saved.
+1. Locate the authoritative PRD, acceptance criteria, issue, or user-provided
+ requirements. Treat WIGTN, Spec Kit, OpenSpec, and BMAD documents as inputs,
+ not workflows that must be replayed.
+2. Identify the requested comparison: working tree, commit, branch, PR, or
+ named files. If `.wigtn/project.json` or `.wigtn/workgraph.json` exists,
+ validate it before trusting sources or status; source drift is a gap.
+3. Preserve stable requirement IDs. If none exist, create temporary `AC-01`
+ IDs and label them local to the report.
+4. Inspect implementation and tests. Run the smallest relevant
+ repository-defined checks when authorized and feasible.
+5. Read [evidence matrix](references/evidence-matrix.md), then assign exactly
+ one canonical status per requirement. Cite precise code lines, exact
+ commands, exits, and relevant test names. Never infer that an unexecuted or
+ irrelevant check passed.
+6. Put findings outside the requirement set under `Out-of-scope findings`.
## Output
| Requirement | Status | Code evidence | Test evidence | Gap |
|---|---|---|---|---|
-Always print the exact canonical status value, including for chat-only answers.
-For insufficient evidence, write `not-verifiable`; a localized label may follow
-in parentheses. Never replace it with `Not Verified`, `Unverified`, or a
-localized-only label.
+Use the canonical status value in every row. For insufficient evidence, write
+`not-verifiable`; a localized label may follow but must not replace it. A
+missing test does not automatically mean the requirement failed.
+
+Do not create state for an ordinary verification answer. For a requested saved
+artifact, existing `.wigtn/evidence.json`, cross-session handoff, or explicit
+Spec Kit/OpenSpec/BMAD import, read [saved evidence](references/saved-evidence.md).
-Follow with executed commands, limitations, and prioritized gaps. A missing test is not automatically a failed requirement; distinguish implementation evidence from verification confidence.
+Finish with executed commands, limitations, prioritized gaps, and any saved
+artifact validation result. Do not change a WorkGraph task to `verified`
+unless its current linked check passed and a valid evidence reference exists.
diff --git a/plugins/wigtn-plugins-with-codex/skills/acceptance-verifier/references/saved-evidence.md b/plugins/wigtn-plugins-with-codex/skills/acceptance-verifier/references/saved-evidence.md
new file mode 100644
index 0000000..96f7633
--- /dev/null
+++ b/plugins/wigtn-plugins-with-codex/skills/acceptance-verifier/references/saved-evidence.md
@@ -0,0 +1,28 @@
+# Saved acceptance evidence
+
+Use only for an explicitly requested machine-readable artifact, an existing
+`.wigtn/evidence.json`, or a cross-session handoff. First read the shared
+[Evidence Contract](../../../references/evidence-contract.md).
+
+For a new imported handoff, run from the target repository root:
+
+```bash
+python3 /scripts/import-requirements.py \
+ --output .wigtn/evidence.json
+python3 /scripts/validate-evidence.py .wigtn/evidence.json
+```
+
+The importer starts every requirement as `not-verifiable`. Only inspected code
+and executed checks may raise status. To resume after source changes, add
+`--existing .wigtn/evidence.json`; changed requirements lose prior evidence,
+removed IDs stay in metadata, and release authority resets.
+
+Before trusting an existing artifact, run:
+
+```bash
+python3 /scripts/inspect-evidence.py .wigtn/evidence.json --root .
+```
+
+Treat source drift, missing code references, or invalid checks as gaps. Use the
+same canonical status in the saved artifact and human report. A saved artifact
+records evidence and authority; it grants neither release nor remote action.
diff --git a/plugins/wigtn-plugins-with-codex/skills/design-direction/SKILL.md b/plugins/wigtn-plugins-with-codex/skills/design-direction/SKILL.md
index 1c1add5..a5b7357 100644
--- a/plugins/wigtn-plugins-with-codex/skills/design-direction/SKILL.md
+++ b/plugins/wigtn-plugins-with-codex/skills/design-direction/SKILL.md
@@ -1,6 +1,6 @@
---
name: design-direction
-description: Derive a project-native visual direction for a new UI or redesign by inspecting the existing design system first. Use for UI design direction, style exploration, greenfield interface styling, or redesign requests. Do not use for a tiny CSS fix, established-component implementation, or non-UI work.
+description: Derive a project-native UI direction from the existing design system. Use for visual direction, greenfield styling, or redesign requests. Do not use for small CSS fixes, established-component work, or non-UI tasks.
---
# Design Direction
diff --git a/plugins/wigtn-plugins-with-codex/skills/handdrawn-diagram/SKILL.md b/plugins/wigtn-plugins-with-codex/skills/handdrawn-diagram/SKILL.md
index 99d4b8a..224a27b 100644
--- a/plugins/wigtn-plugins-with-codex/skills/handdrawn-diagram/SKILL.md
+++ b/plugins/wigtn-plugins-with-codex/skills/handdrawn-diagram/SKILL.md
@@ -1,6 +1,6 @@
---
name: handdrawn-diagram
-description: Create committable sketch-style architecture or flow diagrams as Mermaid handDrawn source plus verified SVG and PNG. Use when the user explicitly requests a 손그림, sketch, hand-drawn, or handDrawn aesthetic, including Devpost assets with that stated style. Do not use for an ordinary diagram, chart, presentation diagram, or bitmap illustration without a sketch-style request.
+description: Create Mermaid handDrawn architecture or flow diagrams with verified SVG and PNG. Use for explicit 손그림, sketch, hand-drawn, or handDrawn requests. Do not use for ordinary diagrams, charts, presentation diagrams, or bitmap illustrations.
---
# Hand-drawn Diagram
diff --git a/plugins/wigtn-plugins-with-codex/skills/product-spec/SKILL.md b/plugins/wigtn-plugins-with-codex/skills/product-spec/SKILL.md
index 700709c..b8c1fe6 100644
--- a/plugins/wigtn-plugins-with-codex/skills/product-spec/SKILL.md
+++ b/plugins/wigtn-plugins-with-codex/skills/product-spec/SKILL.md
@@ -1,6 +1,6 @@
---
name: product-spec
-description: Create, review, or deeply analyze an actual implementation-ready PRD or product-spec artifact. Use for “PRD 뽑아줘”, “PRD 검토해줘”, “PRD 디깅해줘”, drafting requirements or acceptance criteria, and feasibility, security, edge-case, or contradiction review of a provided spec. Do not use for conceptual explanations of product terms, brainstorming without a requested requirements artifact, ordinary implementation, minor fixes, or general code review.
+description: Create, review, or deep-dive an implementation-ready PRD or product spec. Use for “PRD 뽑아줘”, “PRD 검토해줘”, “PRD 디깅해줘”, requirements, acceptance criteria, and spec feasibility or contradiction review. Do not use for brainstorming without an artifact, implementation, minor fixes, or general code review.
---
# Product Spec
diff --git a/plugins/wigtn-plugins-with-codex/skills/release-readiness/SKILL.md b/plugins/wigtn-plugins-with-codex/skills/release-readiness/SKILL.md
index 66b9709..45003c3 100644
--- a/plugins/wigtn-plugins-with-codex/skills/release-readiness/SKILL.md
+++ b/plugins/wigtn-plugins-with-codex/skills/release-readiness/SKILL.md
@@ -1,6 +1,6 @@
---
name: release-readiness
-description: Safely review, verify, commit, push, or open a pull request when the user asks in natural language such as “커밋해줘”, “푸시해줘”, “PR 올려줘”, or “커밋 준비해줘”. Preserve unrelated changes and execute only the requested Git scope. Do not use for ordinary implementation or vague “완료해줘”.
+description: Safely review, prepare, commit, push, or open a PR for explicit Git requests such as “커밋해줘”, “푸시해줘”, or “PR 올려줘”. Preserve unrelated changes and perform only the requested scope. Do not use for implementation or vague completion requests.
---
# Release Readiness
diff --git a/plugins/wigtn-plugins-with-codex/skills/screen-spec/SKILL.md b/plugins/wigtn-plugins-with-codex/skills/screen-spec/SKILL.md
index f78ebad..abc1b0c 100644
--- a/plugins/wigtn-plugins-with-codex/skills/screen-spec/SKILL.md
+++ b/plugins/wigtn-plugins-with-codex/skills/screen-spec/SKILL.md
@@ -1,70 +1,56 @@
---
name: screen-spec
-description: Create only the requested implementation-ready IA, user flow, screen specification, lo-fi HTML wireframe, or developer handoff from a PRD or feature description. Use for “화면정의서”, “IA”, “user flow”, “wireframe”, or UI handoff requests. Generate the full five-artifact bundle only when the user requests a complete screen specification or handoff bundle. Do not use for visual styling alone or non-UI backend work.
+description: Create only the requested IA, user flow, screen spec, lo-fi HTML wireframe, or developer handoff from requirements. Use for “화면정의서”, IA, user flow, wireframe, or UI handoff requests. Build all five only for an explicit complete bundle. Do not use for styling alone or backend work.
---
# Screen Spec
-Select the artifacts requested by the user:
+Select the requested artifact and its dependency closure:
- `ia` → `01-IA.md`
- `flow` → `02-USER-FLOW.md`
- `screen` → `03-SCREEN-SPEC.md` plus IA
-- `wireframe` → `04-WIREFRAME.html` plus IA and screen spec
-- `handoff` → `05-DEV-HANDOFF.md` and its full dependency closure
-- complete “화면정의서”, bundle, or full handoff request → all five
+- `wireframe` → `04-WIREFRAME.html` plus IA and screen
+- `handoff` → `05-DEV-HANDOFF.md` plus all dependencies
+- explicit complete bundle → all five
-Do not create unrelated artifacts merely because the skill was selected.
+Do not produce or propose the other artifacts merely because the skill loaded.
-## Compact single-artifact path
+## IA-only or flow-only
-For an IA-only or flow-only request:
-
-- Treat a sufficient user-provided feature description as the source. Do not
- scan the repository unless the user requests project-native routes or points
- to source files.
-- For a chat-only answer, do not read templates or references, create files,
- run validators, or perform browser checks. Return only the selected artifact.
-- When a file is requested, read only its matching template, write only that
- file, and validate only the selected artifact.
-- Keep IA to assumptions, a structured page map, navigation, access roles, and
- scope boundaries. The page map must contain `Page`/`페이지` plus
- `Route`/`경로` columns, or `정보 단위` plus `경로` columns.
-- Stop after the selected artifact. Do not propose or summarize the other four.
+- Use a sufficient user brief directly. Inspect repository routes only when
+ project-native behavior is requested or source files are named.
+- For chat-only output, do not read templates, create files, run validators,
+ or perform browser checks.
+- For a file, read only its matching template and validate only that artifact.
+- IA needs assumptions, a page/route map, navigation, roles, and boundaries.
+ Stop after the requested artifact.
## Multi-artifact workflow
-1. Read the source PRD or feature description and relevant existing routes,
- components, permissions, and design system.
-2. Preserve requirement IDs. Record safe inferences under `Assumptions`; ask
- only when a missing decision materially changes navigation or behavior.
-3. Build the requested artifacts and required dependency closure from the
- templates in `assets/templates/`. Keep page IDs, routes, roles, states, and
- requirement IDs consistent across the artifacts that exist.
-4. Cover only applicable states: loading, empty, error, success, unauthorized,
- validation, offline, and destructive confirmation.
-5. Keep wireframes grayscale with semantic status colors only. If browser
- control is available, verify desktop and mobile widths, overflow, labels,
- and links before completion. Use the single self-contained responsive
- `04-WIREFRAME.html` template; do not create a second mobile artifact.
-6. Run the selector-aware validator from this skill directory:
-
- `python3 ../../scripts/validate-screen-spec.py --artifacts `
-
- Fix missing selected artifacts, unresolved template tokens, broken anchors,
- and requirement drift between artifacts that exist.
-7. Return file links and deterministic plus visual verification results
- without pasting every artifact into the conversation.
-
-Read [state checklist](references/state-checklist.md) only when screen,
-wireframe, or handoff is selected. Read
-[handoff checklist](references/handoff-checklist.md) only for handoff.
-Read [microcopy patterns](references/microcopy-patterns.md) only when the user
-requests UX copy or the selected screen/handoff contains material forms,
-empty/error states, permission guidance, or destructive confirmation.
-If a saved WorkGraph exists, preserve its requirement IDs and let
-`work-planner` register the generated artifact set. Screen output never
-verifies implementation.
-
-Do not invent a visual brand. Suggest `design-direction` only when a new visual
-direction is actually requested.
+1. Read the requirements and only the existing routes, components,
+ permissions, and tokens needed for the selected artifacts.
+2. Preserve requirement IDs. Mark unsupported routes, policies, breakpoints,
+ APIs, and copy as assumptions or open decisions rather than defaults.
+3. Read only the selected templates in `assets/templates/` and their dependency
+ templates. Treat placeholders as shape, never as product facts.
+4. Keep page IDs, roles, routes, states, requirements, and wireframe anchors
+ consistent across the artifacts that exist.
+5. For screen, wireframe, or handoff, read the compact
+ [state contract](references/state-contract.md). For handoff, also read the
+ [handoff contract](references/handoff-contract.md).
+6. Keep wireframes grayscale with semantic status colors and one self-contained
+ responsive HTML file. If browser control is available, inspect wide and
+ narrow layouts, overflow, labels, and links.
+7. Run from this skill directory:
+
+ `python3 ../../scripts/validate-screen-spec.py --artifacts `
+
+8. Return file links and deterministic plus visual results without pasting the
+ full bundle into chat.
+
+Use project-native language for microcopy. Prefer explicit action labels and a
+useful recovery action; do not invent timing, policy, ownership, or operational
+promises. Screen artifacts describe intended behavior and never verify its
+implementation. Suggest `design-direction` only for an actual visual-direction
+request.
diff --git a/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/02-USER-FLOW.md b/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/02-USER-FLOW.md
index 041ee22..1efbd58 100644
--- a/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/02-USER-FLOW.md
+++ b/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/02-USER-FLOW.md
@@ -1,83 +1,36 @@
# User Flow — {feature-name}
-> **Generated from**: docs/prd/PRD_{feature-name}.md §5.5
-> **Created**: {YYYY-MM-DD}
-> **Status**: Draft
+## Assumptions and boundaries
-> **Mermaid 룰**: 라우트(`/`)/특수문자(`?`, `=`, `:`)를 포함하는 노드 텍스트는 항상 `["..."]` 큰따옴표로 감싼다. valid한 shape만 사용: `[]` `()` `(())` `{}` `[(...)]`. `{(...)}`는 존재하지 않는다.
+- Source requirements: {requirement IDs or brief}
+- In-scope actor: {role-1}
+- Open decision: {요약}
-## Flow A: {role-1} — {primary-scenario}
+## Flow: {primary-scenario}
-> Acceptance Criteria 매핑: Scenario {A}
+Requirement mapping: {FR/AC IDs}
```mermaid
flowchart TD
- Start([{진입점}]) --> Step1[{초기 화면 또는 액션}]
- Step1 --> Decide{인증 필요?}
- Decide -->|허용| Continue["/main-route"]
- Decide -->|거부| NoPerm[no-permission 안내]
- Continue --> Form[필드 입력]
- Form --> Validate{검증}
- Validate -->|FAIL| Form
- Validate -->|PASS| Server{서버 응답}
- Server -->|201 OK| Success[성공 토스트]
- Server -->|4xx| Form
- Success --> Next["/next-route"]
+ Start["{entry}"] --> Action["{user action}"]
+ Action --> Decision{"{observable condition}"}
+ Decision -->|"{branch A}"| OutcomeA["{result or next screen}"]
+ Decision -->|"{branch B}"| Recovery["{recovery or alternate action}"]
```
-## Flow B: {role-1} — {secondary-scenario}
+## Branch contract
-> Acceptance Criteria 매핑: Scenario {B}
+| Branch | Trigger or precondition | Observable result | Recovery / next action | Requirements |
+|---|---|---|---|---|
+| {branch A} | {known condition} | {result} | {next action} | {IDs} |
+| {branch B} | {known condition} | {result} | {recovery} | {IDs} |
-```mermaid
-flowchart TD
- Start(["{진입 라우트}"]) --> List[목록 표시]
- List --> Click[항목 클릭]
- Click --> CheckStatus{status 확인}
- CheckStatus -->|편집 가능| Edit["/edit?id=…"]
- CheckStatus -->|잠금| Locked[수정 불가 안내]
- Edit --> Save{저장}
- Save -->|성공| List
- Save -->|FAIL| Edit
-```
-
-## Flow C: {role-2} — {admin-scenario}
-
-> Acceptance Criteria 매핑: Scenario {C}
-
-```mermaid
-flowchart TD
- Start(["/admin 진입"]) --> CheckRole{role 확인}
- CheckRole -->|권한 없음| Redirect["/ 로 리다이렉트"]
- CheckRole -->|권한 있음| List[전체 목록]
- List --> Filter[필터 적용]
- Filter --> Action[액션 트리거]
- Action --> Modal[옵션 모달]
- Modal --> Complete((완료))
-```
-
-## Flow Coverage Check
-
-| Acceptance Criteria | Flow |
-|--------------------|------|
-| Scenario A | Flow A |
-| Scenario B | Flow B |
-| Scenario C | Flow C |
-
-**규칙**:
-- 모든 Acceptance Criteria가 1+ Flow에 매핑되어야 함
-- 매핑되지 않는 시나리오 → Flow를 추가하거나 시나리오가 모호
-
-## Branch Conditions Reference
-
-| 분기 노드 | 조건 | 처리 |
-|----------|------|------|
-| 인증 검증 | `user.authenticated && role in allowed_roles` | 허용 / no-permission |
-| 클라이언트 검증 | 필드별 validation rule | PASS / FAIL |
-| 서버 응답 | HTTP status | 201 / 422 / 400 |
-| 권한 확인 | `user.role === required_role` | 허용 / 리다이렉트 |
+## Flow Coverage
-## Open Questions
+| Requirement or scenario | Covered flow / branch | Gap |
+|---|---|---|
+| {ID} | {flow and branch} | {none or open decision} |
-- [ ] 인증 만료 시 어디서 분기되는가?
-- [ ] 자동 저장은 별도 Flow인가?
+Add another flow only for a materially different actor or lifecycle. Quote
+Mermaid labels containing routes or punctuation. Do not invent authentication,
+HTTP status, retry, navigation, or success behavior absent from the source.
diff --git a/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/03-SCREEN-SPEC.md b/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/03-SCREEN-SPEC.md
index e914f45..a3239c4 100644
--- a/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/03-SCREEN-SPEC.md
+++ b/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/03-SCREEN-SPEC.md
@@ -1,143 +1,54 @@
# Screen Specifications — {feature-name}
-> **Generated from**: docs/prd/PRD_{feature-name}.md
-> **Created**: {YYYY-MM-DD}
+## Assumptions and open decisions
-## Convention
+- {fact, inference, or unresolved decision}
-각 화면은 다음 7개 슬롯을 모두 채운다:
+Duplicate the following section only for an in-scope screen.
-1. **Meta**: Audience / Auth / Linked FRs / Layout / Responsive
-2. **States**: §5.4.1에서 체크된 상태마다 1줄 이상
-3. **Components**: 폼 필드/버튼/리스트 등 모든 UI 슬롯
-4. **Microcopy**: 진입 안내, 버튼 라벨, 에러 메시지, 빈 상태 메시지
-5. **Responsive**: 분기점별 레이아웃 변화
-6. **Wireframe Anchor**: 04-WIREFRAME.html의 anchor
-7. **Open Questions** (선택): 명세 진입 시 결정되지 않은 항목
+## Screen: {screen-id} — {screen-name}
-> `--interview` 플래그로 수집된 결정사항(네비 패턴 / 밀도 / 에러 톤 / 빈 상태 철학 / 전환 방식 / 모바일 우선순위 / 핵심 후크)이 있다면 각 화면 명세 작성 시 명시적으로 반영한다.
-
----
-
-## Screen: {route-1}
-
-| 항목 | 값 |
+| Field | Contract |
|---|---|
-| Audience | {role-1} |
-| Auth | {Required 또는 Optional} ({인증 방식}) |
-| Linked FRs | {FR-001, FR-002, ...} |
-| Layout | {레이아웃 요약, max-width 등} |
-| Responsive | {Desktop / Tablet / Mobile 분기} |
+| Route / entry | {confirmed route, entry condition, or TBD + owner} |
+| Audience / authorization | {roles and server-enforced boundary if known} |
+| Requirements | {FR/AC IDs} |
+| Purpose | {one observable user outcome} |
### States
-PRD §5.4.1에서 체크된 항목만 1줄 이상 명세:
-- [x] loading: {구체적 처리 — 스피너/스켈레톤}
-- [ ] empty: N/A 또는 {CTA 포함 안내}
-- [x] error: {inline 또는 배너, 메시지 톤}
-- [x] success: {전환 또는 토스트}
-- [ ] no-permission: N/A 또는 {안내 + 리다이렉트}
-
-### Components
-
-| Slot | Type | Required | Validation | Microcopy |
+| State | Trigger | Visible behavior | Recovery / next action | Requirements |
|---|---|---|---|---|
-| {field-1} | {input/select/textarea/...} | Yes/No | {검증 규칙} | {라벨 또는 placeholder} |
-| {field-2} | ... | ... | ... | ... |
-| submit | button | Yes | - | "{동사형 라벨}" |
-
-### Microcopy
-
-- 진입 안내: "{1~2줄 안내. 소요 시간/임시저장 가능 여부 등}"
-- 에러 메시지: "{사용자 언어로, 코드 노출 금지}"
-- 빈 상태: "{다음 행동 유도 + CTA}"
-
-### Responsive
-
-- Desktop (≥1024px): {레이아웃 변화}
-- Tablet (768~1023): {접힘/숨김 처리}
-- Mobile (<768): {1열 / 모달 / floating button}
+| {applicable state} | {condition} | {what the user observes} | {action} | {IDs} |
-### Wireframe Anchor
+### Components and data
-→ `04-WIREFRAME.html#screen-{slug-1}`
-
-### Open Questions
-
-- [ ] {결정 보류 항목}
-
----
-
-## Screen: {route-2}
-
-| 항목 | 값 |
-|---|---|
-| Audience | {role-1} |
-| Auth | {Required 또는 Optional} |
-| Linked FRs | {FR-003, ...} |
-| Layout | {레이아웃 요약} |
-| Responsive | {분기} |
-
-### States
-
-- [x] loading: {처리}
-- [x] empty: {CTA + 안내}
-- [x] error: {처리}
-- [x] success: {처리}
-
-### Components
-
-| Slot | Type | Required | Validation | Microcopy |
+| Element | Role | Input / source | Validation or boundary | States |
|---|---|---|---|---|
-| {필터 또는 액션} | {type} | No | - | "{라벨}" |
-
-### Microcopy
-
-- 헤드라인: "{화면 제목}"
-- 빈 상태: "{첫 사용 시 안내 + CTA}"
-
-### Responsive
-
-- Desktop: {표 형식}
-- Mobile: {카드 그리드}
-
-### Wireframe Anchor
+| {component or region} | {purpose} | {known source or TBD} | {rule or open decision} | {state names} |
-→ `04-WIREFRAME.html#screen-{slug-2}`
+### Interactions
----
+| User action | Preconditions | Result | Failure behavior | Requirements |
+|---|---|---|---|---|
+| {action} | {condition} | {observable result} | {recovery} | {IDs} |
-## Screen: {route-3} (관리/제한 화면 예시)
+### Responsive behavior
-| 항목 | 값 |
+| Context | Behavior |
|---|---|
-| Audience | {role-2} |
-| Auth | Required + {role 검증} |
-| Linked FRs | {FR-...} |
-| Layout | {Filter bar + Table + Action bar} |
-| Responsive | **Desktop only** 또는 모바일 별도 처리 |
-
-### States
-
-- [x] no-permission: {role 아님 → / 리다이렉트 + 토스트}
-- [x] success: {필터/페이지네이션 테이블}
-
-### Components
-
-| Slot | Type | Required | Validation | Microcopy |
-|---|---|---|---|---|
-| filter | multi-select | No | - | "{필터 라벨}" |
-| export_btn | button | - | - | "내보내기" |
-
-### Microcopy
+| Wide | {project-native layout behavior} |
+| Narrow | {priority, order, collapse, or overflow behavior} |
-- 권한 안내: "{role}만 접근할 수 있습니다. 권한 요청은 {담당자/팀}에게 문의하세요."
+### Copy and accessibility
-### Responsive
+- Primary action label: {project-native action text}
+- Error or empty recovery: {message plus next action}
+- Focus / keyboard / semantics: {applicable contract}
-- Desktop (≥1280px): 전체 표시
-- Mobile (<768): "PC에서 접속하세요" 안내 또는 별도 화면
+### Wireframe anchor
-### Wireframe Anchor
+`04-WIREFRAME.html#screen-{slug-1}`
-→ `04-WIREFRAME.html#screen-{slug-3}`
+Do not invent exact breakpoints, components, APIs, storage, or policies. Record
+unknowns as `TBD` with an owner or decision point.
diff --git a/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/04-WIREFRAME.html b/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/04-WIREFRAME.html
index 5527134..1da04a2 100644
--- a/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/04-WIREFRAME.html
+++ b/plugins/wigtn-plugins-with-codex/skills/screen-spec/assets/templates/04-WIREFRAME.html
@@ -1,127 +1,70 @@
-
-
+
+
-
+
- 화면정의서 — {feature-name}
+ {feature-name} lo-fi wireframe
-
-
- 개정 전
-
-
- 명시 호출된 구현을 하나의 heavy workflow로 처리. 작은 수정에도 별도 harness와 evidence 절차가 붙음.
-
- 0.3.0
-
+ 일반 구현은 native/Fast. 제품 계약, 검증 근거, 저장 상태, Git 권한이 필요할 때만 강한 경로 사용.
-
+
+
- | 과제 | Bare | 이전 Plugin |
|---|---|---|
| Astropy, 실행 1 | resolved | resolved |
| Astropy, 실행 2 | resolved | resolved |
| Pytest, 실행 1 | resolved | resolved |
| Pytest, 실행 2 | resolved | resolved |
| 합계 | 4/4 | 4/4 |
구현 경로를 Fast와 Assurance로 나눴다
-
-
-
-
-
- | 경로 | 사용하는 경우 | 실행 범위 |
|---|---|---|
| Fast | 국소 변경, 낮은 위험, 저장소 테스트 실행 가능 | inspect → minimal patch → focused test → 관련 suite 1개 |
| Assurance | auth, schema, persistence, concurrency, migration, 복수 요구사항 | stable ID, invariant, provenance, evidence artifact |
Fast path에서 제거한 작업
--
-
- 작은 수정에 requirement matrix나 WorkGraph를 만드는 일 -
- 저장소 테스트가 있는데 같은 happy path를 별도 harness로 다시 만드는 일 -
- 저장·인계 요청이 없는데 evidence JSON을 생성하는 일 -
- 관련 suite 통과 뒤 근거 없이 검사를 계속 추가하는 일 -
외부 정답 접근과 무한 탐색을 막았다
--
-
- workspace 밖 동일 프로젝트, package cache, gold/reference source를 구현 근거로 사용하지 않는다. -
- 복수 interface 작업만 편집 전 coverage census를 작성한다. -
- 두 diagnostic cycle 동안 새 증거가 없으면 탐색을 넓히지 않는다. -
- reference leakage가 발생하면 evaluator 성공과 관계없이
Not verifiable로 판정한다.
-
개정 후 forward-test
-
-
-
-
- | 지표 | 개정 전 Plugin 중앙값 | 개정 후 1회 |
|---|---|---|
| official resolved | 2/2 | pass |
| output token | 10,470.5 | 4,466 |
| command | 23 | 10 |
- output token은 57.3%, command는 56.5% 줄었다. 한 번의 개발 - 세트 결과이므로 일반 효율 향상 근거로 쓰지 않는다. 설계 변경이 - 실제 실행 경로를 줄였는지 확인한 결과다. -
- - -WIGTN Plugin 0.3.0의 방향
- -일반 구현·버그 수정
- └─ Codex native workflow 또는 Fast path
-
-제품 개발 계약이 필요한 작업
- ├─ Product Spec 요구사항과 결정
- ├─ Work Planner task, check, resume, drift
- ├─ Acceptance Verifier code·executed-test evidence
- └─ Release Readiness Git 상태와 실행 권한
-
- 0.3.0에 추가한 것
-
-
-
-
-
- | 영역 | 구현 |
|---|---|
| Evidence Contract | 거짓 verified, 누락 gap, source drift, 권한 없는 외부 작업을 validator로 차단 |
| WorkGraph | requirement→task→check 상태, 중단 재개, source hash 변경 시 stale 전파 |
| Requirement import | WIGTN Plugin PRD, Spec Kit, OpenSpec, BMAD 형식 정규화 |
| Project context | 선택적 .wigtn/project.json으로 검증 명령과 보호 경로 공유 |
| Screen contract | IA·flow·screen·wireframe·handoff 연결과 requirement anchor 검사 |
| Release state | branch, upstream, conflict, staged, unstaged, untracked를 mutation 없이 점검 |
| Evidence inspection | 파일 변경과 hash drift 뒤 기존 완료 판정 재검사 |
| 평가 분리 | 정적 계약, model behavior, 외부 benchmark를 별도 suite로 운영 |
- Codex의 구현 능력은 그대로 사용하고, PRD에서 검증과 안전한 Git
- 릴리스까지 필요한 제품 개발 계약만 추가한다.
-
- - 상태 파일은 일반 코딩 때 자동 생성되지 않는다. 저장형 계획, - 세션 간 재개, 감사 가능한 handoff를 요청했을 때만 사용한다. -
-어디까지 믿을 수 있나
- -
-
-
-
-
- | 주장 | 판정 | 근거 |
|---|---|---|
| 정해진 PRD 계약의 재현성을 높인다 | 제한적으로 지지 | GPT‑5.5 smoke 0/3→3/3, ablation 0/2→2/2 |
| 일반 코딩의 성공을 크게 망가뜨리지 않는다 | 개발 표본에서 지지 | ordinary gate와 paired bug fix 동률 |
| 개정 전 heavy workflow는 같은 성공에 비용을 늘렸다 | 선택한 GPT‑5.6 과제에서 지지 | 4/4 tie, token·wall·command 증가 |
| 일반 코드 품질을 높인다 | 지지되지 않음 | 유효하고 재현된 positive lift 0 |
| 모델이 강할수록 항상 하네스를 줄여야 한다 | 미검증 | 두 모델과 작은 표본만 관측 |
한계
--
-
- SWE-bench 주효과는 Python bug fix 두 과제, 네 pair다. -
- FeatureBench 파일럿은 네 과제이며 positive lift가 없다. -
- GPT‑5.5 실제 저장소 복제는 한 과제, 한 반복이다. -
- 독립 oracle 감사자와 blind human reviewer 수가 부족하다. -
- 프론트엔드, 데이터베이스, 대규모 migration 결과는 없다. -
- 0.3.0 개정 후 외부 holdout 반복은 아직 완료하지 않았다. -
- 현재 가장 강한 결론: 선택한 GPT‑5.6 Sol bug fix에서 개정 전 - WIGTN Plugin은 성공률을 바꾸지 않고 비용을 늘렸다. 이 결과를 - 반영해 일반 구현 절차를 줄이고 제품별 계약과 검증·릴리스 경계에 - 기능을 집중했다. -
-다음 검증
-
-
-
-
- | 우선순위 | 평가 | 종료 조건 |
|---|---|---|
| P0 | 개정 후 fresh holdout 20 task | 5개 이상 repo, task당 3회, reference source 격리 |
| P0 | Fast/Assurance routing 10 task | 잘못된 Assurance 호출 0, median output overhead ≤25% |
| P1 | GPT‑5.5 실제 저장소 복제 | 2개 과제×2회, 순서 교차 |
| P1 | 독립 oracle 감사 | 포함·제외 합의 κ≥0.7 |
| P1 | blind patch review | arm을 숨긴 reviewer 2인 이상 |
| P2 | PRD→implementation 12 feature | 요구사항 누락, clarification, rework 측정 |
| P2 | release state 60 fixture | 권한 없는 mutation 0 |
| P2 | cross-platform | macOS/Linux와 fresh install 재현 |
- fresh holdout 전에는 일반 코드 품질 향상을 제품 주장으로 쓰지 - 않는다. 0.3.0 릴리스는 일반 코딩의 불필요한 heavy workflow를 - 막고, 저장형 계약의 drift와 거짓 완료를 차단하며, Git 작업을 - 사용자 권한 안에서 수행하는지를 기준으로 검증한다. -
-재현 자료
--
-
- 외부 평가 프로토콜 -
- SWE-bench machine-readable protocol -
- SWE-bench 결과와 제외 기록 -
- FeatureBench 사전 프로토콜 -
- FeatureBench 파일럿과 leakage 감사 -
- FeatureBench 결과 -
- SWE-bench evaluation reference -
- Anthropic, Demystifying evals for AI agents -
- OpenAI, Separating signal from noise in coding evaluations -
- Claw-SWE-Bench -
성공률은 같았지만 비용은 달랐다.
+
+
+
+
+ | 중앙값 | Bare | 이전 Plugin | 증가 |
|---|---|---|---|
| 실행 시간 | 120.21초 | 302.62초 | +151.7% |
| 출력 토큰 | 3,613 | 8,715.5 | +141.2% |
| 실행 명령 수 | 12.5 | 16.5 | +32.0% |
이 결과를 플러그인의 모든 기능이 항상 느리다는 결론으로 일반화할
+ 수는 없다. 다만 선택한 두 과제에서는 이전
+ verified-delivery가 작은 버그 수정에도 별도 계획과 검사,
+ 완료 기록을 반복했고, 추가 절차가 코드 결과를 바꾸지 않은 채 비용으로
+ 남았다.
FeatureBench 파일럿에서는 유효한 개선을 확인하지 못함
+여러 파일을 수정하는 기능 구현 평가인 FeatureBench에서도 Seaborn, + Sphinx, MLflow, Mypy 과제를 살펴봤다. 첫 Seaborn Plugin 실행은 + 테스트를 통과했지만 작업공간 밖에 설치된 같은 프로젝트의 구현을 + 읽은 사실이 확인됐다. 정답에 해당하는 소스에 접근했기 때문에 이 + 실행은 무효로 처리했다. 새 작업공간에서 실행 순서를 바꿔 다시 + 평가했을 때는 Bare와 Plugin 모두 해결하지 못했다.
+나머지 세 과제도 두 조건의 결과가 같았다. 따라서 무결성 기준을 + 통과하고 반복해서 확인된 코드 성능 개선 사례는 0건이다. 이 파일럿의 + 첫 네 짝에서 중앙 실행 명령 수는 17에서 38로, 출력 토큰은 + 10,274에서 20,663.5로 늘었다.
+ +PRD 평가에서는 문서 형식 준수율이 개선됨
+GPT‑5.5로 같은 PRD 요청을 세 번 실행했을 때, WIGTN이 정한 문서 + 형식의 충족 횟수는 Bare 0/3, Plugin 3/3이었다. 기능 일부를 빼거나 + 내용 없는 지침으로 바꾼 비교 실험에서도 플러그인 미사용 조건과 내용 + 없는 대조 지침은 0/2, 핵심 기능과 전체 패키지는 2/2였다.
+이 평가에서 확인한 범위는 문서의 전반적인 품질이 아니라 요구사항 + ID, 미결정 항목, 수용 기준 형식처럼 WIGTN이 미리 정한 항목의 준수 + 여부다.
++ + +관찰 결과
+ 선택한 구현 과제에서는 이전 하네스가 추가 성공 없이 비용을 늘렸다. + PRD 평가에서는 미리 정한 문서 항목의 준수율이 높아졌다.
일반 구현 개입 축소와 고위험 작업의 선택적 검증
+평가 결과를 반영해 구현 경로를 작업 위험도에 따라 나눴다.
+
+
+
+
+ | 경로 | 사용하는 경우 | 실행 범위 |
|---|---|---|
| Fast(간단 경로) | 국소 변경, 낮은 위험, 저장소 테스트 실행 가능 | 원인 확인 → 최소 수정 → 집중 테스트 → 관련 검사 |
| Assurance(강화 검증 경로) | 로그인·권한, 데이터 구조, 저장·동시 처리, 데이터 이전, 복수 요구사항 | 요구사항 ID → 위험 조건 → 코드 위치 → 실행 근거 |
Fast 경로에서는 작은 수정에 WorkGraph나 요구사항 표를 만들지 않는다. + 기존 테스트가 같은 동작을 확인할 수 있다면 별도 테스트 환경을 중복해서 + 만들지 않고, 관련 검사가 통과하면 이유 없이 검사를 계속 늘리지 + 않는다.
+Assurance 경로는 실패 비용이 큰 작업에만 사용한다. 여기서도 많은 + 절차를 수행하는 것 자체를 품질로 보지 않는다. 어떤 요구사항이 어떤 + 코드로 구현됐고 어떤 검사를 실제로 통과했는지를 연결하는 데 집중한다.
+WorkGraph는 이 연결을 세션 사이에 보존해야 할 때 쓰는 선택적 상태
+ 파일이다. 원본 요구사항이나 연결된 산출물이 바뀌면 관련 작업과 검사를
+ stale, 즉 다시 확인해야 하는 상태로 바꾼다. 일반 코딩 때
+ 자동으로 생성하지 않고, 사용자가 저장형 계획이나 중단 후 재개를
+ 요청할 때만 쓴다.
완료 판정도 코드 존재 여부만으로 끝내지 않는다. 정확한 코드 위치와
+ 관련된 성공 테스트가 함께 있어야 verified로 기록할 수
+ 있다. 다만 이 기록 규칙이 실제 Git 명령을 막는 보안 장치는 아니다.
+ commit, push, PR은 사용자의 현재 요청이 해당 작업을 허용하는지 별도로
+ 확인한다.
FeatureBench에서 드러난 문제도 제품 규칙에 반영했다. 작업공간 밖의 + 같은 프로젝트, 별도 체크아웃, 패키지 캐시, 정답 패치, 숨은 + 테스트를 구현 근거로 사용하지 않는다. 이런 접근이 발견되면 테스트 + 통과와 관계없이 검증할 수 없는 실행으로 처리한다.
+일반 코딩 방해 여부 및 WorkGraph 기능 검사
+이전 구현 절차의 비용을 확인한 실험과 현재 제품 구조의 검증을 섞지 + 않았다. 구조를 바꾼 뒤에는 일반 코딩을 방해하지 않는지, 선택 기능이 + 정해진 상태 규칙을 지키는지를 별도로 검사했다.
+일반 코딩 방해 여부. Python, JavaScript, Ruby로 만든 + 합성 버그 수정 12개를 Bare와 현재 전체 기능 구성으로 각각 실행했다. + 숨은 테스트는 양쪽 모두 12/12를 통과했고, 허용 범위 밖 수정과 + 요청하지 않은 PRD·WorkGraph·릴리스 상태 생성, 사용자 초안 손실은 + 모두 0건이었다.
+현재 구성의 중앙 출력 토큰은 Bare보다 10.3% 낮고 실행 시간은 + 18.8% 높았다. 표본이 작고 실행 순서와 클라우드 지연의 영향을 받으므로 + 효율 개선이나 저하의 근거로 사용하지 않는다. 확인된 것은 이 12개 + 과제에서 현재 플러그인이 일반 코딩을 무거운 제품 흐름으로 바꾸지 + 않았다는 점이다.
+WorkGraph 생성. 인증, 여러 고객의 데이터를 분리하는 + 멀티테넌시, 데이터 구조 변경, 웹훅 등 12개 격리 저장소에서 Work + Planner를 명시적으로 호출했다. 12개 저장소가 모두 최종 형식 검사를 + 통과했고, 출처·요구사항·작업·검사·위험·보호 경로를 확인한 144개 + 항목도 모두 통과했다. 실행하지 않은 작업을 완료로 기록하거나 + 삭제되면 안 되는 확인용 파일을 잃은 경우는 없었다.
+고정 입력 회귀 검사. WorkGraph의 생성·변경
+ 전파·형식 이전·명령행 도구 67개 사례와 완료 판정의 정상·오류 상태,
+ PRD와 화면 명세 형식, Git을 변경하지 않는 릴리스 상태 검사, 자연어
+ 요청에 따른 verified-delivery 선택을 각각 확인했다.
검증 범위는 플러그인이 정의한 기능 규칙의 동작까지다. Bare + Codex와의 계획 품질 및 일반 코드 품질 비교는 포함하지 않았다.
+현재 근거가 지지하는 주장과 아직 검증하지 못한 가설
+
+
+
+
+ | 주장 | 현재 판정 | 근거 |
|---|---|---|
| WIGTN이 정한 PRD 형식의 재현성을 높인다 | 제한적으로 지지 | GPT‑5.5 0/3→3/3, 기능 제거 비교 0/2→2/2 |
| 현재 구성이 일반 코딩을 불필요한 제품 흐름으로 바꾸지 않는다 | 개발 표본에서 지지 | 합성 과제 12개에서 비간섭 |
| 이전의 무거운 구현 절차는 같은 성공에 비용을 늘렸다 | 선택한 과제에서 지지 | GPT‑5.6 Sol 4/4 동률, 시간·토큰·명령 증가 |
| 모델이 좋아질수록 과한 하네스의 추가 효과가 줄어든다 | 설계 가설과 부합 | 강한 모델에서 추가 성공 없이 비용 증가, 세대 변화의 인과관계는 미검증 |
| WorkGraph와 완료 판정이 정해진 상태 규칙을 지킨다 | 개발 표본에서 지지 | 모델 파일럿과 고정 입력 회귀 검사 |
| WIGTN이 일반 코드 품질을 높인다 | 지지되지 않음 | 무결하고 반복 가능한 개선 사례 0건 |
| 모든 저장소와 모델에서 같은 결과가 나온다 | 확인하지 않음 | 모델·언어·과제 수가 제한적 |
현재 근거로 “모델이 좋아질수록 모든 하네스가 반드시 쓸모없어진다”거나 + “플러그인을 쓰면 Codex가 코드를 더 잘 짠다”, “모든 작업에서 시간과 + 토큰이 줄어든다”라고 말할 수 없다. 일부 원시 실행 패킷도 아직 영구 + 저장소에 공개되지 않아, 이 자료를 완전한 제3자 재현 패키지라고 + 부르지 않는다.
+가장 강하게 말할 수 있는 결론은 다음과 같다.
++선택한 GPT‑5.6 Sol 버그 수정 과제에서 이전의 무거운 + 하네스는 성공률을 바꾸지 않고 비용을 늘렸다. 이 결과를 바탕으로 + 일반 구현 제어를 축소했다. 모델의 기본 구현 흐름은 그대로 두고, + 프로젝트마다 정해야 하는 요구사항·검증·릴리스 규칙에 플러그인의 + 역할을 집중했다.
현재 선택적 구조의 외부 과제 검증 계획
+다음 외부 평가는 이전의 무거운 하네스가 아니라 현재의 선택적 + 구조를 대상으로 한다. 이후 모델 세대에서도 같은 평가를 반복해, + 모델 능력이 달라질 때 적정 하네스의 범위가 실제로 어떻게 변하는지도 + 추적한다.
+-
+
- 최소 다섯 개 저장소의 새 외부 과제 20개를 과제당 세 번 실행하고, + 정답 소스와 패키지 캐시를 파일시스템 수준에서 격리한다. +
- 작업 열 개에서 Fast와 Assurance 선택이 적절한지 확인하고, + 불필요하게 Assurance를 선택한 경우 0건과 출력 비용 중앙값 증가 + 25% 이하를 종료 조건으로 둔다. +
- PRD에서 구현까지 이어지는 기능 12개에서 요구사항 누락, 추가 + 질문, 재작업을 측정하고, 릴리스 상태 60개에서 권한 없는 Git 변경 + 0건을 확인한다. +
새 외부 과제 평가가 끝나기 전에는 일반 코드 품질 향상을 제품 + 문구로 사용하지 않는다. 현재 제품의 합격 기준은 일반 코딩을 + 불필요하게 무겁게 만들지 않는 것, 실행 근거가 없을 때 완료로 + 기록하지 않는 것, 저장소 변경을 사용자가 요청한 범위 안에서만 + 실행하는 것이다.
+프로토콜·결과·감사 자료
+-
+
- 외부 평가 프로토콜 +
- SWE-bench machine-readable protocol +
- SWE-bench 결과와 제외 기록 +
- FeatureBench 사전 프로토콜 +
- FeatureBench 파일럿과 정답 소스 접근 감사 +
- FeatureBench 결과 +
- 일반 코딩 비간섭 평가 +
- WorkGraph 기능 평가 +
- 선택적 하네스 후속 연구 +
- SWE-bench evaluation reference +
- Anthropic, Demystifying evals for AI agents +
- OpenAI, Separating signal from noise in coding evaluations +
- Claw-SWE-Bench +
이 자료는 평가 조건과 결과를 확인할 수 있도록 프로토콜, 요약 결과, + 검사 코드를 연결한다. 공개 범위와 재현 한계는 위 한계 절에 함께 + 적었다.
+