omd-apply

name	omd-apply
description	프로젝트 DESIGN.md를 UI/시각 작업의 brand context로 적용. 컴포넌트·색상·폰트·레이아웃 수정 같은 구체적 요청과 톤·분위기 표현 — KR '좀 더 따뜻하게', EN 'make it warmer/cooler', 日本語「もう少し暖かく」, 繁體中文「更溫暖一點」 — 모두에 트리거. DESIGN.md 부재 시 omd:init 우선. 화면 전체 신규 디자인은 omd:harness, 교정 기록은 omd:remember.

omd:apply — Brand Context Injection + Delivery Router

유효하게 채택된 Core v2 package에서는 System Graph를 canonical authority로, 그 외에는 standalone DESIGN.md를 모든 UI/디자인 작업의 portable contract로 사용한다. 책임은 세 가지:

1. 인라인 처리 — 작은 단일 변경 (1 component, 1 token, 1 카피 라인)은 직접 Edit 툴로 처리
2. Advisory dispatch — 복합 작업은 적합한 전문 역할의 의견을 먼저 받음 (master 거치지 않음)
3. Delivery ownership — 사용자가 구현·수정을 요청했다면 본 에이전트가 실제 편집과 검증을 끝까지 소유

전문 역할은 자문자다. 역할이 없거나 자문이 read-only여도 구현 요청을 감사 결과로 끝내거나 아무 변경 없이 종료하지 않는다.

트리거 조건

다음 중 하나가 감지되면 SKILL 전체를 로드한다.

• 컴포넌트 생성 / 수정 (button, card, dialog, nav, form 등)
• 스타일 변경 (Tailwind 클래스, CSS, 토큰 값)
• 마이크로카피 작성 / 수정 (버튼 라벨, empty state, 에러, tooltip)
• 모션 / 트랜지션 추가
• 색상 · 타이포그래피 · 스페이싱 조정
• 에셋 (아이콘, 차트, 일러스트, 3D 렌더) 요청
• 디자인 시스템 관련 질문

Phase 0 — Intent + dispatch decision tree (가장 먼저)

먼저 요청의 완료 조건을 구분한다.

• audit/advice: 분석, 리뷰, 의견, 대안만 요청. 자문 결과로 종료 가능.
• implement/change: 만들어, 고쳐, 바꿔, 적용해, 개선해. 본 에이전트가 편집과 검증을 완료해야 함.

기존 화면의 수정·리디자인은 규모가 커도 omd:apply의 implement/change다. /omd-harness는 새 surface를 처음부터 설계하거나 사용자가 명시적으로 요청한 경우에만 추천한다.

작업 시작 전에 어떤 처리 경로인지 결정한다. 다음 표를 위에서부터 순차 매칭, 첫 번째 매칭 행으로 진행:

사용자 요청 패턴	처리 경로	이유
"에셋 / 아이콘 / 일러스트 / 차트 / 사진 / 로고 / 그래프 / SVG 만들어"	dispatch omd-asset-curator	매체 선택 + 스택 매칭이 전문 영역
"새 메인 화면 / 새 landing / 새 surface / 처음부터 / 와이어프레임"	사용자에게 /omd-harness 추천	10-phase 파이프라인이 적합
"접근성 / a11y / 색약 / 키보드 네비" 감사	dispatch omd-a11y-auditor	전문 감사
"마이크로카피만 다듬어 / 카피 톤 정리 / empty state 문구 전부" 복수	dispatch omd-microcopy	voice 일관성
"사용자 시나리오 / 페르소나 walk through / 4명 입장에서 검토"	dispatch omd-persona-tester	adversarial 4-페르소나
"이 카피 좋은지 / hero 카피 약점 / 섹션별 카피 전문가 의견 / A/B 후보"	dispatch omd-ux-writer	UX writing 분석 + 대안 + 근거
"이 인터랙션 / 모션 / 포커스 / 모바일 / 지각 성능 / 섹션별 UX 약점"	dispatch omd-ux-engineer	코드 레벨 인터랙션 감사 + fix
"기존 랜딩 / 메인 화면 / 페이지 전체를 전문가 의견으로 개선"	advisory dispatch omd-ux-writer + omd-ux-engineer (병렬)	두 트랙 자문 후 본 에이전트가 구현
"이게 왜 안 좋은지 critique / postmortem / root cause"	dispatch omd-critic	비판적 분석
"DESIGN.md 만들어 / reference 골라 / 카탈로그에서 추천"	dispatch omd-init skill (또는 omd-add-reference)	reference 매칭
"preference 정리 / 누적된 교정 반영 / DESIGN.md 업데이트"	dispatch omd-learn skill	fold-in 로직
"이 한 줄 / 이 컬러 / 이 spacing 좀" 단발 명확	인라인 처리	분명한 단일 변경
위 어디에도 안 맞는 자유로운 디자인 작업	본 에이전트가 처리 후 Phase 3 (교정 캡처)	일반 케이스

Capability preflight + recovery

dispatch 전에 실제 역할 가용성을 확인하고 아래 첫 번째 가능한 경로를 사용한다.

1. 런타임 역할 사용 가능 → Agent 툴로 dispatch하고 결과를 자문으로 수집.
2. 런타임 목록에는 없지만 유효한 로컬 역할 파일 존재 → 현재 채널의 역할 파일을 전체 읽고 그 관점을 인라인 자문 렌즈로 적용. 역할을 실행했다고 표현하지 않음.
3. 역할과 유효한 역할 파일 모두 없음 → 전문 역할이 실행되지 않았음을 숨기지 않고 Phase 1-2의 DESIGN.md 계약으로 계속 진행. 역할 부재만으로 작업을 중단하거나 사용자에게 설치를 요구하지 않음.

implement/change 요청은 어떤 recovery 경로에서도 본 에이전트가 자문을 반영해 실제 파일을 편집하고 검증한다. audit/advice 요청만 자문 결과 요약으로 종료할 수 있다.

Work packet — 역할 수보다 먼저 고정

복합 작업은 dispatch 전에 아래 필드를 인라인으로 고정한다. 2개 이상 specialist를 쓰거나 다음 턴으로 이어질 때만 .omd/work/<timestamp>-<slug>.json에 기록한다. 단일 변경에 파일을 만들지 않는다.

intent: audit | implement
task: <사용자가 원하는 결과>
consumer_route: <사용자가 실제로 진입하는 route>
acceptance: [<관찰 가능한 완료 조건>]
protected_behaviors: [<깨지면 안 되는 동작>]
protected_contract:
  cardinality: [<동작을 가진 control/row/form/disclosure의 현재 개수와 허용 변화>]
  state_transitions: [<before → action → after>]
  facts: [<보존할 값·카피·hook·필드명>]
  change_authority: original-user-task-only
visual_equity:
  - identity: <task-helpful 기존 시각 결정>
    user_value: <사용자 판단·안심·상태 인지에 주는 가치>
    before_evidence: <같은 route/state의 code·DOM·screenshot>
    decision: preserve | reinforce | replace
    change_authority: <original user task | explicit DESIGN.md rule | same consumer route measured defect>
evidence: [DESIGN.md, screenshot, code, browser observation]
unknowns: [<확인되지 않은 정보 — fallback으로 채우지 않음>]
implementation_owner: main-agent | none
  verification:
  routes: []
  viewports: []
  states: []
  commands: []
  budget:
    required: []
    optional: []
    delivery_reserve: true
    first_product_edit: 50%
    advisory_to_first_edit: min(90s, 10%)
    stop_optional_verification: 80%
    begin_final_delivery: 90%
  first_safe_edit:
    target: <기존 파일의 정확한 snippet 또는 selector>
    smallest_useful_change: <acceptance에 기여하는 실제 변경>
    protected_contract_effect: none
    acceptance_check: <변경 직후 확인할 한 가지>

설치된 채널 data root에 workflow-capabilities.json이 있으면 선언된 workflow와 필드명을 사용한다. 파일이 없어도 위 계약으로 계속하며 설치를 강요하지 않는다.

specialist handoff에는 전체 대화 대신 이 packet과 필요한 파일·스크린샷만 전달한다. 기존 UI repair의 specialist는 기본적으로 mode: bounded-repair-advisory를 사용하고 요청된 위험 영역 1-2개, finding 최대 3개, 약 300단어로 제한한다. 전 섹션 audit, 8/10항목 전수평가, A/B 옵션, 추가 아이디어 발산은 별도 full audit 요청에서만 한다. specialist 응답은 main agent가 설명 없이 바로 적용할 수 있는 first_safe_edit를 맨 앞에 두고 다음 shape로 제한한다.

first_safe_edit:
  target: <기존 파일의 정확한 snippet 또는 selector>
  evidence: <route·line·DOM·screenshot 근거>
  smallest_useful_change: <완료 조건에 기여하는 최소 유효 수정>
  protected_contract_effect: none
  acceptance_check: <적용 직후 어떻게 확인할지>
findings:
  - finding: <무엇이 문제인가>
    evidence: <근거>
    smallest_useful_change: <최소 유효 수정>
    acceptance_check: <어떻게 통과를 확인할지>
unresolved: [<확인 불가 항목>]

서로 다른 specialist가 같은 제품 파일을 동시에 수정하지 않는다. implementation_owner: main-agent만 자문을 합치고 코드를 편집한다. specialist는 protected ledger나 visual equity ledger를 수정·완화할 권한이 없다. handoff는 current_count, allowed_delta, states, facts, change_authority와 visual equity 항목을 그대로 복사해야 하며, 이를 벗어난 제안은 implementation 후보가 아니라 rejected_contract_drift로 폐기한다.

Phase 1 — DESIGN.md 로드

실제 변경 또는 디자인 판단 전에 진행:

1. 프로젝트 루트의 DESIGN.md를 전체 읽는다. 요약 금지, Read 툴로 직접 로드한다.
2. .omd/system/manifest.json 또는 .omd/system/graph.json 중 하나라도 있으면 둘 다 regular file인지 확인하고 다음 binding을 전부 검증한다: format: design-md-core, format_version: 2.0.0, profile: portable-core, authority.canonical: system-graph, exact seven section order/path, schema-valid seven graph objects, deterministic graph→projection semantic equality, Portable Core usefulness, actual graph와 DESIGN.md 및 manifest에 열거된 artifact bytes의 exact SHA-256. 전부 맞을 때만 adopted valid portable-core graph로 인정하며 graph.json이 canonical이고 DESIGN.md는 standalone portable projection이다. graph와 projection이 충돌하면 graph가 이긴다.
3. manifest가 migration-candidate면 candidate graph는 non-authoritative다. authority.source_sha256에 결박된 source DESIGN.md만 canonical로 읽고, candidate projection/graph를 적용 근거로 쓰지 않는다. sidecar가 가리킨 source를 찾을 수 없으면 candidate를 적용하지 않고 fail closed한다. sidecar가 missing/stale/invalid면 graph authority를 버리고 root DESIGN.md를 독립 standalone contract로 읽는다. binding 오류는 unresolved에 남기고 bound-system이라고 주장하지 않는다. standalone 문서가 Portable Core usefulness를 통과하지 못해도 확인된 field는 읽을 수 있지만, 빠진 계약은 absent로 유지하고 portable conformance를 주장하지 않는다.
4. Core v2 DESIGN.md는 heading 번호나 번역된 제목이 아니라 다음 exact stable anchor로 읽는다: experience, foundations, typography-assets, components-states, layout-platforms, content-locales, governance. exact Core anchor가 전혀 없는 문서만 legacy compatibility input으로 읽고, Visual Theme, Color Palette, Typography, Components, Responsive, Voice & Tone, Motion 같은 의미 heading을 Core anchor로 매핑한다. legacy 숫자 section을 새 code citation이나 산출물에 복사하지 않는다.
5. .omd/preferences.md가 있으면 같이 읽는다. status: pending은 graph를 몰래 다시 쓰는 machine authority가 아니라 이후 사용자 교정 layer다. 현재 사용자의 명시적 지시와 explicit pending 교정은 실행 시 우선하되, inferred 교정으로 canonical graph의 확정값을 바꾸지 않는다.
6. reference-capture는 evidence-only: .omd/init-context.json의 reference_id(legacy input만 legacy metadata의 bootstrapped_from fallback)로 assets/_reference/<id>/를 찾고 evidence.json, tokens.json, structure.json, , screenshots를 필요할 때 읽을 수 있다. 그러나 captured , , font URL, logo, composition은 프로젝트 authority가 아니며 자동 적용·동기화·fallback하지 않는다. graph-authoring checkpoint가 provenance와 함께 해당 결정을 에 명시적으로 admit했고 위 hash binding이 valid할 때만 그 graph path를 통해 적용한다. admission되지 않은 capture는 관찰 근거로만 남기고 구현 값은 absent다.

DESIGN.md 없으면 사용자에게 알리고 omd:init 스킬 트리거. 임의 생성 금지.

Phase 2 — Brand Context 적용

• 토큰 값은 valid graph의 foundations/typography_assets, 또는 standalone DESIGN.md의 foundations/typography-assets에서만 인용한다. 임의 hex / spacing / radius / font fallback 금지.
• content-locales를 마이크로카피에 적용한다. 문장 길이, 어휘 register, 은유 밀도와 locale behavior를 일치시킨다.
• components-states의 variant / state / sizes와 layout-platforms의 responsive/platform 규칙을 따른다.
• 없는 토큰 지어내지 않음. 필요 시 사용자에게 "이건 DESIGN.md에 없는데, 어떻게 할까요?" 묻기.
• advisory dispatch 결과가 read-only 제안이어도 implement/change 요청에서는 본 에이전트가 최소 유효 변경을 직접 적용.
• 변경 전 consumer_route의 viewport·state·핵심 동작을 기록하고, 변경 후 같은 consumer route·viewport·state를 다시 연다. 공유 renderer나 진단 route만 확인해 통과 처리하지 않는다.
• 변경 후 요청에 비례한 빌드·테스트·실제 route 검증을 수행. 동작, 시각 계약, 접근성, overflow를 확인한다. 실행하지 못한 검증은 통과로 표현하지 않고 unresolved에 남긴다. 자문 완료를 구현 완료로 간주하지 않음.

Phase 2.25 — Contract-first edit + acceptance packet

시각적 확장보다 먼저 기존 제품 계약을 잠근다. 목적은 디자인을 보수적으로 만드는 것이 아니라, 더 나은 화면을 만들면서 이미 동작하는 제품을 다른 제품으로 바꾸지 않는 것이다.

Non-interactive browser-infrastructure rule (browser-gated 절차보다 우선)

자동화·benchmark·non-interactive run에서는 사용자에게 remote debugging 허용, permission dialog 클릭, 로그인, browser attach, 재개 응답을 요구하지 않는다. Chrome 권한 팝업, remote debugging disabled, named socket unavailable, attach denial처럼 route navigation 전에 막힌 한 번의 준비된 browser command는 즉시 browser_infrastructure_unavailable로 분류한다. 같은 browser·port·runtime을 재시도하거나 사용자를 불러 대기하지 않는다.

• implement/change 요청이고 prompt·task packet·baseline이 구체적인 must_fix를 이미 제공했다면, pre-edit browser plan 불가가 제품 수정을 취소하는 이유가 아니다. 기존 source·DESIGN.md token·protected ledger·명시된 failure만 사용해 bounded static repair를 계속한다. 브라우저에서만 알 수 있는 width·ratio·state를 측정한 것처럼 만들지 않고, 근거 없는 brand fact/token/value나 task와 무관한 carrier를 추측하지 않는다.
• .omd/reflow-closure.json에 source_contract.state: provider-sealed가 이미 있으면 이것이 기본 경로다. manifest나 artifact를 열어 고치지 말고 제품 edit 전에 node <current-skill-dir>/scripts/reflow-artifact.mjs source-packet .omd/reflow-closure.json을 정확히 한 번 실행한다. 이 read-only 명령이 pre-edit product hash, immutable inventory, source-fallback stamp를 다시 검증하고 완성된 patch contract를 출력한다. 출력이 red면 제품을 편집하지 않고 중단한다. sealed artifact는 모델의 작업물이 아니며 필드 보완·정규화·충돌 제거를 위해 수정할 수 없다. packet이 열린 뒤 완성될 제품 bytes 전체를 .omd/product-candidate.html에 먼저 작성하고 node <current-skill-dir>/scripts/reflow-artifact.mjs static-preview .omd/reflow-closure.json .omd/product-candidate.html로 검사한다. candidate는 제품 파일이 아니므로 preview red를 고쳐 다시 검사할 수 있지만, locked product와 artifact는 preview가 pass하기 전까지 그대로여야 한다. preview pass 뒤 candidate를 다시 읽거나 모델 edit으로 재작성하지 않고 node <current-skill-dir>/scripts/reflow-artifact.mjs static-promote .omd/reflow-closure.json .omd/product-candidate.html을 정확히 한 번 실행해 receipt가 결박한 bytes를 제품에 그대로 승격한다.
• benchmark가 source contract 0.2를 제공하면 provider 이전 admission이 해시로 잠긴 raw baseline의 모든 실패 critical gate를 critical_gate_debt_coverage와 대조한 상태다. 모델은 coverage를 축소하거나 baseline을 재해석하지 않는다. comparison-scroll row의 packet에는 carrier 자체뿐 아니라 nowrap content가 상위 grid/flex item의 automatic minimum을 밀어내지 않도록 하는 exact parent min-width: 0 containment declaration도 포함돼야 한다. baseline의 contrast failure나 carrier parent containment가 packet에 없으면 준비 실패이며, 모델이 실행 중 추측으로 보완하는 경로가 아니다.
• provider-sealed artifact가 없는 일반 프로젝트에서 pre-edit plan command가 navigation 전에 infrastructure error로 끝났다면 제품 edit 전에 node <current-skill-dir>/scripts/reflow-artifact.mjs source-fallback-open .omd/reflow-closure.json을 실행한다. browser-harness wrapper가 stdin을 실행하기 전 막혀 snapshot이 없으면 이 명령이 현재 product를 먼저 snapshot으로 잠근다. 관계 contract validation에서 red면 opening은 소비되지 않으므로 error가 요구한 artifact-only carrier/row 계약만 고치고 같은 명령을 다시 실행한다. source_fallback_closure.state: opened stdout을 받은 뒤에는 재실행하지 않는다. helper가 잠근 pre-edit product sha256·inventory sha256와 opening stamp가 없으면 fallback edit은 금지한다. measured plan이 있거나 product가 이미 바뀐 뒤에는 이 경로를 열 수 없다.
• 이 infrastructure branch에서는 browser-derived plan-close와 fit budget을 unresolved로 남기고, 한 번의 product edit + 저장소에 이미 있는 결정론 static evaluator/closure 한 번으로 알려진 결함을 닫는다. browser proof는 , source-backed static proof만 로 분리한다. 완전 검증·browser pass라고 표현하지 않는다.

이 절은 아래의 “plan-close 전 product edit 금지” 규칙에 대한 유일한 infrastructure 예외다. 정상적으로 browser plan이 실행된 경우에는 기존 measured-plan 절차를 그대로 따른다.

Release-blocker pass — polish보다 먼저 한 번만 닫기

아래 세 항목은 서로 다른 문서 작업이 아니라 첫 edit transaction의 완료 조건이다. 긴 ledger를 다시 설명하거나 검증을 반복하지 말고, 제품을 읽을 때 위험을 표시한 뒤 한 번의 edit으로 같이 고친다.

Completion loop — accounting 전에 실제 결함 닫기

사용자 prompt·task packet·DESIGN.md가 이미 실패라고 말한 항목은 must_fix다. 첫 제품 diff 직후, static closure 전에 딱 한 번 아래 순서로 확인한다.

1. Contrast: normal text pair가 4.5 미만이면 그 요소를 확인된 Ink/text-role token으로 바꾼다. palette 전체를 새 hex로 바꾸거나 “unresolved”만 기록하지 않는다.
2. Atomic rows: 320px·200%에서 exact identifier/summary가 한 줄에 안 맞으면 carrier 자체를 full-row/stack한다. 하나의 protected wrapper가 ID-A + ID-B처럼 둘 이상의 atomic token을 담고 wrapper에 one-line 계약이 있으면 wrapper와 원문 순서를 보존한 채 각 token을 visible semantic child로 감싸더라도 parent 전체가 한 줄이어야 한다. child나 separator 사이 wrap도 실패다. parent를 display:grid/column/flex-wrap으로 쪼개지 말고, carrier를 full-row→stack→relocate해 필요한 연속 폭을 회수한다. 그래도 전체 compound value가 물리적으로 안 맞을 때만 text가 아닌 관계 carrier 전체에 이름 있는 comparison-scroll을 쓴다. protected target/identifier/state 같은 passive text 자체에 overflow:auto|scroll을 두는 것은 금지다. comparison carrier는 row selector와 다른 selector, accessible name, keyboard reachability, visible focus를 모두 가져야 한다. page overflow, word-break, 임의 글자 축소, 숨김·복제는 금지다.
3. Second edit gate: must_fix 중 제품 diff에 실제 교정이 없는 항목이 하나라도 있으면 static proof로 넘어가지 않고 두 번째 제품 edit을 한다. finalize-unresolved는 수정 대신 쓰는 출구가 아니다.

브라우저 명령은 static closure 뒤 한 번만 실행한다. host hook이 있는 환경에서는 artifact의 browser_attempt 자가진술로 충분하지 않다. helper가 .omd/proof-policy의 실제 실행 관측을 확인해야 finalize-unresolved를 허용한다. hook이 명령을 실행 전에 차단했다면 attempt가 아니므로, deny guidance에 따라 올바르게 분류되는 browser command 한 번을 실행하거나 delivery를 unresolved로 남긴다.

편집 전에 아래 세 값을 한 줄씩 확정한다. 빈 값이 있으면 제품 edit을 시작하지 않는다.

pre_edit_release_invariant:
  known_failure_ledger: "every supplied baseline failure and every pre-edit measured failing critical gate → selector/condition + evidence + required correction or fail-closed outcome"
  foreground_change: "selector + surface + exact before ratio → existing verified text-role/ink token + exact after ratio or fail-closed replacement"
  comparison_carrier_set: "every protected or named relationship scope containing registered atomic text → named containment or exact relocation + concrete 390px + 320px + actual 200% zoom/reflow outcomes per carrier"
  browser_attempt: "one prepared command that navigates the same consumer route"

known_failure_ledger AND foreground_change AND comparison_carrier_set이 한 transaction에서 모두 닫혀야 한다. 사용자 요청·task packet·baseline 증거가 실패로 명시한 gate와 pre-edit 계산에서 실제 실패한 gate는 headline 수정 영역이 아니어도 모두 ledger에 올린다. 값을 계산하거나 실패라고 언급한 뒤 제품 diff에서 교정하지 않으면 measured-but-unchanged로 transaction은 미완료다. known failure가 하나라도 open|unresolved|measured-but-unchanged면 static closure·browser proof·delivery로 넘어가지 않는다.

known failure를 메모리에만 두지 않는다. reflow artifact의 acceptance_debt_ledger에 사용자 prompt·DESIGN.md·baseline이 직접 언급한 모든 실패 범주를 한 행씩 기록한다. 각 행은 pre-edit selector, baseline evidence, required correction/outcome, static guardrail, proof mode를 가지며 guardrail assertion은 static_closure_manifest에도 동일하게 존재해야 lock이 통과한다. contrast를 요구했는데 reflow 행만 등록하거나, baseline이 4.5:1 미만임을 알고도 low-contrast source pattern을 forbidden guardrail에 묶지 않으면 제품 edit을 시작하지 않는다.

이것은 계획 메모가 아니라 conjunctive edit 범위다. foreground_change AND comparison_carrier_set이 한 transaction에서 모두 구체화되어야 한다. carrier set은 protected ledger와 reflow row에서 target|identifier|evidence|state|control-label을 담는 모든 보호된 또는 이름 붙은 relationship scope를 포함한다. 인접한 scope를 대표 carrier 하나로 합치거나 주요 다이어그램만 기록하지 않는다. 첫 diff와 consolidated static closure에는 foreground의 exact numeric result(또는 verified text-role fail-close)와 carrier별 390px·320px·실제 200% 결과가 있어야 한다. 한 breakpoint, 최대 너비, width:100%, page overflow 0, 또는 미계측 placeholder는 carrier 결과가 아니다. carrier 하나나 viewport 결과 하나라도 빠지면 static closure로 넘어가지 않고 transaction을 미완료로 둔다. static grep은 결과가 아니며 browser session 생성은 결과가 아니다. static closure 뒤 browser_attempt가 실제 route를 열어야 하며, infrastructure가 막힌 실제 navigate 시도만 unresolved로 닫을 수 있다.

1. Foreground: visible normal text의 실제 foreground/background pair를 exact ratio로 계산한다. 4.5 미만이거나 미계측이면 첫 edit diff에서 DESIGN.md의 검증된 text-role/ink token으로 실제 교체하고 accent는 non-text cue에만 남긴다. ratio 기록만 하고 교정을 미루면 transaction 미완료다.
2. Reflow: desktop·390px·320px·200%에서 atomic identifier와 짧은 label을 먼저 본다. fit하지 않으면 글자를 쪼개거나 줄이는 대신 parent row를 full-row→stack하고 desktop track/min-width 제약을 해제한다. shared header·legend가 관계를 전달하면 기본값은 그 carrier가 보이는 named comparison-scroll이다. 숨기고 unbound visual copy를 만들지 않으며, stack이 필요하면 기존 semantic carrier의 identity·cardinality·visibility를 mobile parent로 옮긴다.
3. Stop: 제품 edit 뒤 consolidated static closure 1회, 준비된 browser mechanism 1회만 쓴다. browser infrastructure가 막히면 unresolved로 닫고 다른 browser·port·runtime을 찾지 않은 채 전달한다.

이 pass가 끝난 뒤에만 optional polish로 간다. 아래 packet은 이 세 결정을 증명하는 필드 정의이지 추가 실행 단계가 아니다.

Acceptance packet은 실행 파일이 아니라 체크리스트와 관찰 결과다. 이 표현은 verify.*, verifier.*, check.*, probe.*, 임시 shell 파일, CDP/browser automation, 새 test runner를 작성할 권한을 주지 않는다. 새 프로그램이 실제 Chrome을 실행하더라도 replacement verifier다. 저장소에 이미 있는 테스트·평가기 또는 파일을 만들지 않는 직접 browser command만 실행하고, 그런 수단이 한 번 막히면 browser proof를 unresolved로 남기고 전달을 시작한다.

1. 첫 편집 전 protected ledger를 만든다. 기존 DOM·코드·요청에서 동작을 가진 control, form, disclosure, row/list, 상태 출력의 identity와 개수를 기록한다. 각 항목은 current_count, allowed_delta, states, facts, initial_visibility, own_geometry를 가진다. 사용자가 원 요청에서 추가·삭제를 명시하지 않았다면 언제나 allowed_delta: 0이다. agent, specialist, DESIGN.md, 미적 아이디어, “production-ready” 같은 품질 표현은 변경 권한이 아니다. 부모가 handoff를 만들 때도 이 값을 완화할 수 없다. 특히 초기 문자열이 비어 있는 dynamic status/live region도 protected selector 자체의 baseline rendered box를 기록한다. 편집 뒤 부모 wrapper에만 min-height를 주거나 selector를 DOM에 남겼다는 사실은 그 selector의 가시성 보존이 아니다. baseline에서 보이던 protected selector는 자신의 rendered width·height를 유지해야 하며, 확인할 수 없으면 pre-edit geometry 선언을 복원한다. 1a. 첫 편집 전 visual equity ledger를 만든다. 같은 consumer route/state에서 task-helpful 기존 시각 결정만 최대 5개 기록한다. 각 항목은 identity, user_value, before_evidence, decision(preserve|reinforce|replace), change_authority를 가진다. eligible 결정이 없는 low-salience 변경은 visual_equity: []와 visual-equity closure: N/A로 기록해 inline 작업을 지연시키지 않는다. 대상은 decision hierarchy, risk/reversibility cue, active/selected-state distinction, primary-action prominence, 서로 다른 사용자 결정을 가르는 spatial boundary다. task value 없는 장식과 모든 옛 스타일은 보호 대상이 아니다. 항목을 replace하거나 약화할 권한은 original user task, explicit DESIGN.md rule, same consumer route measured defect 중 하나뿐이다. 이 authority는 protected behavior, foreground, geometry-token, interactive 계약을 override하지 않으며 충돌하면 더 엄격한 계약이 이긴다. “cleaner”, “more consistent/minimal”, component consolidation, generic best practice, specialist preference, model taste는 권한이 아니다. consolidation은 자동 simplification이 아니며 restraint도 안전한 token-backed state signal을 중립화할 허가가 아니다. ledger를 지키려고 DESIGN.md에 없는 token·fallback 값을 만들지 않는다.

2. 첫 편집 전 semantic_color_ledger를 잠근다. 의미 있는 foreground/background pair를 token, surface, content_type, contrast_proof로 기록한다. muted, secondary, supporting도 normal text면 exact pair를 계산하며 반올림 전 값이 4.5 미만이면 실패다. 실패·미계측 pair는 확인된 text-role/ink token으로 fail-close하고, accent는 인접한 non-text cue에만 남긴다. 대체 token이 없으면 새 hex를 만들지 않는다. 일반 텍스트로 의미를 보존한다. 2a. 편집 직후 foreground closure를 한 번 수행한다. changed foreground와 ledger의 기존 실패 pair를 실제 surface에서 다시 대조한다. token 이름·굵기·“거의 4.5”는 proof가 아니다. normal text는 exact 4.5:1을 통과하거나 확인된 text-role token으로 교체되어야 하며, 색만으로 상태를 구분하지 않는다. 이 되기 전에는 acceptance를 시작하지 않는다. 2b. 마지막 제품 편집과 전에 이번 product diff에서 추가·변경한 모든 선언과 그 선언을 받는 실제 surface를 전수한다. card, control/input/button, dialog/sheet, badge/tag처럼 기존 DOM·component name·제품 계약으로 이미 식별되는 역할만 사용하며, 모양이 비슷하다는 이유로 역할을 추측하지 않는다. 각 항목에 , , , , , , 를 붙인다. DESIGN.md에 해당 역할의 radius token이 있으면 source에서 그 exact token을 참조하거나 computed value가 exact token 값과 일치해야 한다. “거의 같다”, 다른 역할 token, 임의 literal, 평균값은 proof가 아니다. changed surface의 역할 또는 token이 없으면 plausible radius를 새로 만들거나 인접 component 값을 빌리지 않고 pre-edit geometry를 복원한다. 새 surface가 원 사용자 요청에 필수인데 역할 token이 없으면 radius 없이 두고 사실을 보존하며 새 token을 만들지 않는다. closure는 , , 이 모두 성립하기 전에는 acceptance를 시작하지 않는다. browser/computed proof가 없더라도 exact source token 대조 또는 pre-edit 복원으로 fail-close하고, 이를 위해 replacement verifier를 만들지 않는다. 2c. optional browser 검증이나 전달로 넘어가기 전에 이번 product diff에서 추가·변경한 모든 focusable element를 전수한다. native control과 link뿐 아니라 , , focusable ARIA widget, skip/navigation control을 포함하고, 각 항목에 , , , , , , , 를 붙인다. 실제 diff를 protected ledger와 대조했을 때 원 사용자 요청의 추가 권한이 없고 이면 접근성 개선 의도, “production-ready”, specialist 제안과 무관하게 그 focusable addition을 검증 전에 제거한다. 의도적으로 숨긴 focusable control은 기존 제품 계약 또는 원 사용자 요청의 권한이 있어야 하고, 같은 selector의 source-level / reveal path가 clip·크기·위치를 해제하며 same-route keyboard acceptance에서 viewport 안에 들어오는지 확인한다. base /visually-hidden 규칙만 있고 focus reveal이 없으면 영구 clipping으로 판정한다. browser proof가 불가능한 새 hidden focusable은 로 출고하지 않고 제거하거나, 원 요청상 control이 꼭 필요하면 평상시에도 보이게 만든다. closure는 , , 이 모두 성립하기 전에는 acceptance를 시작하지 않는다. 새 verifier를 만드는 대신 기존 diff·테스트·같은 route 검증으로 이 transaction을 증명한다. 2d. 이면 desktop/mobile 대조 없이 로 종료한다. ledger가 비어 있지 않으면 마지막 제품 편집 뒤 같은 consumer route/state의 desktop과 mobile을 before/after로 대조한다. 변경된 high-salience 항목은 ledger의 authority에 매핑하고, 권한 없는 변경은 token 안에서 복원한다. , , , 이 모두 성립하기 전에는 acceptance를 시작하지 않는다. visual equity 보존은 모든 옛 스타일의 동결이 아니며, 근거 있는 replace/reinforce와 measured defect 교정은 허용한다. 2e. 같은 consumer route의 390px·320px·actual 200% reflow를 검사한다. 200%는 640px viewport만 뜻하지 않는다. 과 를 함께 적용해 effective CSS width 320px 조건을 만든다. 첫 CSS 편집 전에 필요한 source inspection을 전부 끝내고 한다. 는 이후 제품 source를 //로 다시 읽지 않겠다는 latch다. 같은 selector·역할·longest value를 공유하는 반복 행은 인스턴스마다 복제하지 않고 로 전부 계상한다. 인접한 의미 관계가 다른 carrier는 합치지 않는다.

이 packet은 benchmark selector를 맞추는 절차가 아니다. 실제 제품에서 사용자 동작과 접근성·reflow 계약을 보존하기 위한 일반 acceptance layer다.

Phase 2.5 — Bounded verification + guaranteed delivery

검증은 결과 전달을 막지 않는 범위에서 fail-closed로 수행한다.

1. work packet의 protected ledger, visual equity ledger·closure, acceptance packet을 필수 검증으로 두고, acceptance를 증명하는 최소 명령·route와 선택 검증(추가 screenshot, 보조 브라우저, 중복 lint)을 분리한다.
2. 가장 결정론적이고 값싼 검증부터 실행한다. 이미 같은 계약을 증명한 검증을 “더 확실하게” 만들기 위해 반복하지 않는다.
3. sandbox permission, quota, browser attach, missing executable/dependency 같은 infrastructure error는 제품 결함과 분리한다. verification mechanism은 종류별로 한 번만 시도한다. 실패 원인을 읽는 보정 명령은 제품을 다시 실행하지 않는 범위에서 한 번만 허용하고, 같은 browser/runtime mechanism을 변형해 재시도하지 않는다.
4. 네트워크 다운로드·새 도구 설치·권한 완화·sandbox 해제는 사용자가 요청하거나 work packet에 사전 승인된 경우가 아니면 검증 우회책으로 사용하지 않는다.
5. browser/DOM/runtime을 흉내 내는 새 shim, mock browser, replacement verifier를 검증 우회책으로 작성하지 않는다. verify.*, verifier.*, check.*, probe.*, 임시 shell 파일, CDP/browser automation, 새 test runner도 작성하지 않는다. 새 프로그램이 실제 browser를 실행해도 금지다. 저장소에 이미 있는 테스트·검증기·정적 검사 또는 파일을 만들지 않는 직접 browser command만 사용하고, 없는 증명은 unresolved로 남긴다. 사용자가 테스트 인프라 구현 자체를 요청한 경우만 예외다.
6. 제품 변경이 acceptance를 충족하고 필수 검증 결과를 확보했으면 선택 검증보다 최종 전달을 우선한다. 알려진 시간 예산의 80%에서 선택 검증을 끝내고 90% 전에는 최종 응답을 시작한다. 잔여 예산을 알 수 없으면 첫 제품 편집 이후 acceptance packet 한 번 또는 첫 infrastructure error를 delivery reserve로 간주한다.
7. 검증 인프라가 막혀도 구현을 지우거나 무한 재시도하지 않는다. 최종 응답을 implemented / verified / unresolved로 나눠 무엇이 완성됐고 무엇이 실행되지 못했는지 명시한다.

timeout 직전까지 optional verification을 계속해 final response를 잃는 것은 실패다. artifact가 만들어졌더라도 사용자가 결과·근거·남은 위험을 전달받지 못하면 delivery complete로 처리하지 않는다.

Phase 3 — 교정 캡처

턴 종료 전에 다음 중 하나가 있었는지 확인:

1. 사용자가 디자인 선택을 명시적 교정 ("no, use X", "actually, Y", "don't use Z", "we never do W")
2. 사용자가 토큰/값을 revert 또는 교체
3. 사용자가 "우리는 ~한다/하지 않는다" 형태 원칙 언급

감지되면 omd:remember 스킬을 트리거한다 (CLI 호출 X — .omd/preferences.md에 직접 append). 트리거 메서드: omd-remember SKILL.md의 Step 1-6 절차를 따라 Edit 툴로 파일 수정.

Phase 4 — 확인 메시지

교정 기록 시 턴 끝에 한 줄:

Logged to .omd/preferences.md — say "preference 정리해줘" later to fold into DESIGN.md.

일반 작업에는 불필요. 과한 알림 금지.

금지

• DESIGN.md 없는데 임의 생성 금지 (사용자에게 omd:init 제안)
• 전문 역할 부재 또는 read-only 자문을 이유로 implement/change 요청을 무변경 종료 금지
• 전문 역할 파일을 인라인으로 읽었을 때 해당 역할이 실제 실행됐다고 주장 금지
• 교정 감지 시 "기록할까요?" 묻지 말 것 — 자동 기록 + 한 줄 알림
• 같은 턴 내 같은 교정 중복 기록 금지
• CLI 호출 (omd remember, omd learn 등) 금지 — 1.0.0부터 모두 스킬 prose