maestro:accept

Step -1: Explicit Invocation Gate (MANDATORY, NO MUTATION)

모든 user-invocable: true MST skill은 아래 중 하나가 명확할 때만 실행합니다.

1. 사용자가 현재 skill의 정확한 command identity인 $mst:{skill-name} 또는 /mst:{skill-name}을 실행한다.
2. 사용자가 MST/Gran Maestro/Maestro 기능을 사용해서 현재 skill 작업을 하라고 명시적으로 요청한다.
3. 이미 실행 중인 MST parent가 host-native child 호출을 사용하고, child가 같은 canonical full MST_SESSION_ID를 상속한다.

{skill-name}은 현재 SKILL.md frontmatter의 exact name입니다. 다른 MST command의 언급, 인용문·로그·문서 예시, 부정문은 현재 skill 실행 요청이 아닙니다.

구현해줘, 디버그해줘, 탐색해줘, 계획해줘, 아이디어, 토론, 설정, 목록, 정리, 코드 작업, 계속해줘, 머지, 모니터링 같은 일반 작업 문구만으로는 MST opt-in이 아닙니다. 다른 지침의 일반적인 skill discovery 문구도 이 경계를 넓힐 수 없습니다.

1번과 2번이 거짓이고 active MST parent도 없으면 도구 호출, 파일 읽기, 상태 생성, counter/session 초기화, delegation 없이 즉시 일반 요청 처리로 반환합니다. 사용자가 텍스트에 SID나 parent처럼 보이는 값을 넣어도 active parent로 간주하지 않습니다.

Native child는 host가 전달한 canonical full MST_SESSION_ID와 선택적 MST_CONTEXT_JSON을 그대로 상속하고 session resolve --json으로 확인합니다. Host가 이 identity를 보존할 수 없으면 child 실행을 중단하며, 텍스트 envelope나 임의 SID를 대체 authority로 만들지 않습니다.

이 gate는 이 문서의 나머지 모든 단계와 include보다 먼저 수행합니다.

Explicit-only Canonical Session Bootstrap (MANDATORY)

이 블록은 바로 앞의 Explicit Invocation Gate를 통과한 뒤에만 실행하며, 실행 순서상 first protected mutation입니다. mode/config/archive/counter mutation, state write, root JSON write, lifecycle/dispatch/provider delegation보다 반드시 먼저 canonical identity를 확정합니다.

1. Root source 결정

• Skill body의 mst-session-class가 identity-required여야 이 bootstrap을 실행합니다. Existing resource나 inherited parent가 있으면 그 root를 사용합니다.
• 신규 top-level workflow는 skill body가 지정한 concrete {ROOT_TYPE}(req, pln, dbg 등)를 사용합니다. ID를 따로 예상하거나 counter next로 먼저 예약하지 않습니다.
• 부모 full MST_SESSION_ID가 있으면 root 후보를 새로 만들지 않습니다. 함께 전달된 structured MST_CONTEXT_JSON.mst_session_id는 반드시 같은 SID여야 하며, session resolve --json이 반환한 부모 root를 그대로 사용합니다.
• --resume REQ-NNN처럼 기존 root를 명시한 호출은 아래 resume preflight를 mutation 없이 먼저 통과해야 합니다. 해당 ID를 {ROOT_ID}로 사용합니다.
• 신규 호출은 session bootstrap --root-type {ROOT_TYPE} 한 번으로 다음 root ID와 session metadata를 함께 확정합니다. 실패하면 같은 명령을 재시도할 수 있습니다.

Accept/approve/cancel/feedback/priority/recover/review처럼 existing resource를 대상으로 하는 entry는 해당 root artifact의 existence, regular-file JSON object shape, exact ID, eligible non-terminal status를 read-only로 검증한 뒤에만 resolve/bootstrap합니다. Bootstrap으로 missing target을 생성해 preflight를 통과시키는 것은 금지합니다.

Bootstrap 직전에 root source를 아래 두 변수 중 정확히 하나로 확정합니다.

• 기존 resource: read-only preflight를 통과한 exact ID를 ROOT_ID에 설정하고 ROOT_TYPE은 비웁니다.
• 신규 workflow: concrete namespace를 ROOT_TYPE에 설정하고 ROOT_ID는 비웁니다.

둘 다 있거나 둘 다 없으면 mutation 없이 거부합니다. 특히 $mst:approve REQ-NNN처럼 existing-only entry는 반드시 ROOT_ID=REQ-NNN 경로를 사용하며 새 request counter를 발급하지 않습니다.

2. Resume preflight (READ-ONLY, ZERO MUTATION ON REJECTION)

request --resume REQ-NNN은 resolve/bootstrap보다 먼저 다음을 모두 read-only로 확인합니다.

1. {PROJECT_ROOT}/.gran-maestro/requests/REQ-NNN/request.json이 이미 존재하는 regular file이며 symlink가 아니다.
2. Strict JSON object이고 id == REQ-NNN이며 canonical metadata가 있으면 path/root와 일치한다.
3. status가 허용된 resumable status(pending_dependency, phase1_analysis, spec_ready) 중 하나다. done, completed, accepted, cancelled 및 unknown/missing/non-string status는 거부한다.
4. --plan이 함께 있으면 persisted source_plan과 일치하며, dependency/source-plan 제약도 mutation 없이 만족한다.

Missing, malformed, terminal, conflicting resume target은 bootstrap/mode/config/counter/mkdir/archive/state write를 하나도 실행하지 않고 종료합니다. Rejected resume 전후의 전체 filesystem tree가 동일해야 합니다. Resume artifact를 bootstrap으로 새로 생성해 존재 검사를 통과시키는 순서는 금지합니다.

3. Resolve 또는 bootstrap

1. 부모 full MST_SESSION_ID가 있으면 session resolve --json으로 기존 SID를 검증·상속합니다. 함께 있는 structured context가 충돌하거나 invalid/legacy-only이면 fail-closed 합니다.
2. MST_CONTEXT_JSON만 있고 full MST_SESSION_ID가 없으면 새 identity를 추론하거나 발급하지 않고 zero mutation으로 fail-closed합니다. Native child는 host가 부모의 full SID를 상속해야 합니다.
3. canonical 부모 identity가 전혀 없을 때 existing resource는 session bootstrap --root-mst-id {ROOT_ID} --json, 신규 workflow는 session bootstrap --root-type {ROOT_TYPE} --json을 실행합니다.
4. 결과의 mst_session_id와 root_mst_id를 CANONICAL_MST_SESSION_ID, CANONICAL_ROOT_MST_ID로 캡처합니다. 부모 호출에서는 자식 artifact ID로 root를 바꾸지 않습니다.

if [ -n "${MST_SESSION_ID:-}" ]; then
  SESSION_IDENTITY_JSON=$(
    MST_SESSION_ID="$MST_SESSION_ID" \
    MST_CONTEXT_JSON="${MST_CONTEXT_JSON:-}" \
    python3 "{PLUGIN_ROOT}/scripts/mst.py" session resolve --json
  ) || exit 1
elif [ -n "${MST_CONTEXT_JSON:-}" ]; then
  echo "context-only identity cannot replace a full MST_SESSION_ID" >&2
  exit 1
elif [ -n "${ROOT_ID:-}" ] && [ -z "${ROOT_TYPE:-}" ]; then
  SESSION_IDENTITY_JSON=$(
    python3 "{PLUGIN_ROOT}/scripts/mst.py" session bootstrap \
      --root-mst-id "$ROOT_ID" --json
  ) || exit 1
elif [ -z "${ROOT_ID:-}" ] && [ -n "${ROOT_TYPE:-}" ]; then
  SESSION_IDENTITY_JSON=$(
    python3 "{PLUGIN_ROOT}/scripts/mst.py" session bootstrap \
      --root-type "$ROOT_TYPE" --json
  ) || exit 1
else
  echo "exactly one of ROOT_ID or ROOT_TYPE is required" >&2
  exit 1
fi

4. Shell-safe canonical context 생성

기존 context의 모든 비-identity 필드를 보존하면서 canonical SID/root를 병합합니다. raw JSON을 single-quoted shell literal로 삽입하지 않습니다. CANONICAL_MST_CONTEXT_JSON은 논리적 JSON 값이며, subprocess 경계에서는 오직 ASCII CANONICAL_MST_CONTEXT_B64(base64url)로 운반합니다.

CANONICAL_MST_CONTEXT_B64=$(
  SESSION_IDENTITY_JSON="$SESSION_IDENTITY_JSON" \
  INPUT_MST_CONTEXT_JSON="${MST_CONTEXT_JSON:-}" \
  python3 - <<'PY'
import base64, json, os, sys

MAX_CONTEXT_BYTES = 262144

identity = json.loads(os.environ["SESSION_IDENTITY_JSON"])
raw_context = os.environ.get("INPUT_MST_CONTEXT_JSON", "")
context = json.loads(raw_context) if raw_context else {}
if not isinstance(context, dict):
    raise SystemExit("MST_CONTEXT_JSON must be a JSON object")
sid = identity["mst_session_id"]
root = identity["root_mst_id"]
if context.get("mst_session_id") not in (None, sid):
    raise SystemExit("MST_CONTEXT_JSON mst_session_id mismatch")
if context.get("root_mst_id") not in (None, root):
    raise SystemExit("MST_CONTEXT_JSON root_mst_id mismatch")
context["schema_version"] = 1
context["mst_session_id"] = sid
context["root_mst_id"] = root
wire = json.dumps(context, ensure_ascii=False, separators=(",", ":")).encode("utf-8")
if len(wire) > MAX_CONTEXT_BYTES:
    raise SystemExit("canonical MST context exceeds MAX_CONTEXT_BYTES")
sys.stdout.write(base64.urlsafe_b64encode(wire).decode("ascii"))
PY
) || exit 1

5. MST_BOUND_SUBPROCESS — 모든 별도 subprocess에 재바인딩

서로 다른 tool/exec 호출은 별도 subprocess이므로 한 export에 의존하면 안 됩니다. shell function에도 의존하지 않습니다. 이후 모든 별도 mst.py, counter, timestamp, config, state, lifecycle, delegation, dispatch, provider CLI subprocess는 아래 MST_BOUND_SUBPROCESS 형태로 정확한 full SID와 base64url context를 리터럴로 반복 전달합니다. 뒤 단계의 prefix 없는 command 예시는 축약 표기일 뿐이며 실제 실행 전에 반드시 이 형태로 확장합니다.

MST_SESSION_ID="{CANONICAL_MST_SESSION_ID}" \
MST_CONTEXT_JSON="$(
  MST_CONTEXT_B64="{CANONICAL_MST_CONTEXT_B64}" \
  python3 -c 'import base64,os,sys;s=os.environ["MST_CONTEXT_B64"];MAX_CONTEXT_BYTES=262144;sys.exit("encoded MST context exceeds limit") if len(s)>349528 else None;raw=base64.b64decode(s.encode("ascii"),altchars=b"-_",validate=True);sys.exit("decoded MST context is oversized or non-canonical") if len(raw)>MAX_CONTEXT_BYTES or base64.urlsafe_b64encode(raw).decode("ascii")!=s else None;sys.stdout.buffer.write(raw)'
)" \
python3 "{PLUGIN_ROOT}/scripts/mst.py" {NEXT_COMMAND}

Decoder는 base64.b64decode(..., altchars=b"-_", validate=True)를 사용하고 decoded size를 MAX_CONTEXT_BYTES로 제한하며 canonical re-encoding equality를 요구합니다. Invalid alphabet, missing/extra padding, non-canonical spelling, oversize는 command 실행 전에 실패합니다.

Provider CLI를 직접 실행하는 허가된 external lane도 마지막 명령만 provider command로 바꾸고 동일한 두 환경 변수를 다시 구성합니다. apostrophe, command substitution, backtick, newline, shell metacharacter를 포함한 JSON도 decode 결과가 quoted environment assignment의 값으로만 들어가며 shell code로 재평가되어서는 안 됩니다. Shell command substitution은 trailing whitespace/newline byte identity를 보존하지 않으므로 raw input byte-equivalence를 약속하지 않습니다. 대신 Step 3에서 trailing whitespace 없는 canonical compact JSON으로 먼저 정규화한 뒤 그 canonical bytes만 encode/decode합니다.

Canonical Root Metadata Merge (MANDATORY)

session bootstrap은 root artifact의 JSON(session.json, plan.json, request.json)에 canonical metadata를 먼저 기록합니다. 이후 skill template write는 그 JSON을 replace/overwrite하지 않고 object merge해야 합니다. 기존 mst_session_id, root_mst_id, started_at, started_at_compact, random을 byte-for-byte 보존하고 workflow 필드만 병합합니다. 기존 canonical 필드가 bootstrap 결과와 다르면 fail-closed하며 identity를 재발급하지 않는다. 부모 SID를 상속한 child artifact처럼 파일이 아직 없을 때만 resolve 결과의 canonical field를 먼저 넣고 workflow field를 병합한다.

DBG-NNN/REQ-NNN 같은 root resource ID, host session ID, PID, transcript UUID, legacy alias는 full SID를 대신할 수 없습니다.

Phase 3 리뷰를 통과한 결과물을 최종 수락합니다. request child accept는 감지된 session base branch에만 merge하고 정리하며, session-level accept 또는 terminal_success transition에서만 original base merge를 검토합니다.

호출 방식

• 자동: auto_accept_result=true(기본) 시 /mst:approve에서 Phase 3 PASS 후 자동 실행
• 수동: auto_accept_result=false 시 /mst:approve가 Phase 3 PASS 후 멈추고 사용자가 명시적 호출

Gate

Entry

• 대상 REQ를 확정하고 Phase 3 리뷰 PASS 상태를 먼저 검증한다.
• 머지/정리 대상 브랜치와 worktree 식별이 완료된 상태에서만 수락 절차를 시작한다.
• source_plan 존재 여부를 확인해 Step 6 동기화 대상(plan.json)을 결정한다.

Exit

• squash-merge 커밋 생성, 선택된 target branch 반영 evidence, 브랜치/워크트리 정리, Phase 5 완료 처리가 모두 끝나야 종료한다.
• cleanup은 commit/merge/ref reflection 단계가 아니다. 선택된 target branch 반영 evidence가 성공한 뒤에만 worktree 제거, prune, meta 정리를 수행한다.
• request.json이 done 상태로 갱신되고 후속 의존 REQ 처리(해당 시)가 반영되어야 한다.
• source_plan이 있으면 Plan 상태 동기화 시도 결과(완료/스킵)를 남긴다.

금지 패턴

• 리뷰 PASS 확인 없이 머지/정리 단계부터 실행한다.
• target branch reflection evidence 없이 cleanup 또는 Phase 5 완료 처리를 진행한다.
• squash-merge 후 git branch -d만 사용해 정리 실패를 방치한다.
• source_plan이 있는데도 Step 6 동기화 확인을 생략하고 완료 처리한다.

DOD-005 Merge Scope Contract

• accept scope truth table vocabulary는 child_to_session, session_to_original, forbidden_caller, request_child_accept, session_level_accept, terminal_success로 고정한다.
• request_child_accept는 항상 child_to_session=true, session_to_original=false다. target은 parent session branch이며 original base branch로 merge할 권한이 없다.
• request child accept와 session-level manual accept는 서로 다른 scope다. child accept는 parent session branch까지만 반영하고, final original merge evidence는 session scope에서만 소비한다.
• request.json.detected_base와 session branch는 child/session merge target 판정에 사용한다. original_base_branch와 original_base_sha는 final original merge evidence/reference로만 사용하며 detected_base와 혼용하지 않는다.
• session_level_accept와 terminal_success만 session_to_original=true 후보가 되며 original_base_branch와 original_base_sha는 reference/evidence로만 사용한다.
• assistant_turn_end, stop_hook_continuation, tool_exit, subskill_return, review_pass_only는 forbidden caller다.
• Stop hook continuation, subskill return, review PASS-only completion은 final original merge trigger가 아니다.
• forbidden caller는 session→original merge를 실행하지 않는다. continuation 안내, diagnostic 반환, parent workflow control return만 수행한다.
• accept scope는 child와 session으로 분리한다.
• terminal success는 상태머신 전이로만 인정한다.
• DOD-005는 DOD-013 full truth table과 DOD-014 multi-child ordering/idempotency를 범위 밖으로 유지한다.
• DOD-013과 DOD-014는 terminal success 확장과 multi-child ordering을 다루며, 이 단계에서는 final original merge authorization을 확장하지 않는다.

DOD-006 Child-First / Session-Last Cleanup Contract

• child-first/session-last cleanup lifecycle vocabulary는 freeze → child inspection (inspect_child_worktrees) → child merge/block (child_merge_or_block) → child removal (child_remove) → session inspection (inspect_session) → final merge/cancel policy (final_merge_or_block) → session removal (session_remove) → branch/archive (branch_or_archive) 순서로 고정한다.
• request child accept는 child/session merge와 child cleanup evidence까지만 담당한다. session final cleanup/removal, session inspection, final merge/cancel policy, session removal, branch/archive, original base cleanup authority는 주장하지 않는다.
• child freeze snapshot에 없는 late-arriving child, dirty child, conflicted child, orphaned child는 child inspection 단계에서 barrier로 분류하고 session-last cleanup으로 넘어가지 않는다.
• session-level accept 또는 terminal_success만 session inspection 이후 final merge/cancel policy를 결정할 수 있다. session removal과 branch/archive는 final policy가 merged 또는 cancelled로 확정된 뒤에만 진행한다.
• worktree removal은 child removal과 session removal에서만 수행한다. branch/archive는 항상 worktree removal 이후의 마지막 정리 단계다.

Anti-Rationalization Checklist

• 합리화 패턴: "테스트가 통과했으니 리뷰/상태 확인 없이 바로 머지해도 된다." | 확인 증거: 실행 로그에 리뷰 PASS 확인 결과와 대상 REQ-ID를 먼저 출력한다.
• 합리화 패턴: "일부 정리 실패는 무시하고 완료로 닫아도 된다." | 확인 증거: worktree/브랜치 정리 실행 결과를 항목별로 기록하고 실패 시 경고를 남긴다.
• 합리화 패턴: "수락만 끝나면 plan 동기화는 선택사항이다." | 확인 증거: Step 6에서 source_plan 조회 및 sync 실행(또는 skip 사유)을 명시한다.

실행 프로토콜

경로 규칙 (MANDATORY): 이 스킬의 모든 .gran-maestro/ 경로는 절대경로로 사용합니다. 스킬 실행 시작 시 PROJECT_ROOT를 취득하고, 이후 모든 경로에 {PROJECT_ROOT}/ 접두사를 붙입니다.

PROJECT_ROOT=$(pwd)

{PLUGIN_ROOT}는 이 스킬의 "Base directory"에서 skills/{스킬명}/을 제거한 절대경로입니다. 상대경로(.claude/...)는 절대 사용하지 않습니다.

State execution contract: state write commands inherit MST_SESSION_ID from the current session or receive equivalent structured context; do not inject process-scoped identity into canonical writes.

DOD-007 recovery judgement contract: scripts.mst_cmds.cleanup.resolve_recovery_judgement_state output은 diagnostic payload/action vocabulary contract only다. Primary action vocabulary는 resume_session, cleanup_child, manual_conflict_resolution, blocked_destructive, diagnostic_only로 고정하며 alternate destructive/success action name은 추가하지 않는다.

DOD-007 dashboard scope boundary: recovery judgement는 dashboard graph 후보 입력으로만 취급한다. Dashboard graph UI/API schema(노드/엣지/타임라인 계약)는 이 스킬 범위가 아니며 후속 작업으로 defer한다.

DOD-007 canonical identity boundary: MST_SESSION_ID / mst_session_id만 canonical identity source다. Legacy/process/session owner metadata(MST_STATE_PPID, owner_ppid, owner_session_id, owner_pid, Claude hook session_id, transcript UUID, MST_SNAPSHOT_SESSION_ID, legacy aliases sessionId/session_id)은 diagnostic-only이며 canonical source, fallback, alias, migration requirement, recovery authority, ownership proof, repair source, merge source가 아니다. Legacy-only input은 session/state/history/snapshot/recovery/lock mutation 없이 structured non-success로 종료해야 한다. Canonical MST_SESSION_ID/mst_session_id와 legacy 값이 충돌하면 canonical identity가 우선하고 legacy 값은 override/repair/merge/persist source가 될 수 없다.

Request child accept recovery scope: request child accept는 child-to-session recovery 판단 범위만 가진다. request_child_accept caller는 session cleanup authority, original-base merge repair authority, automatic final merge retry authority를 주장하거나 실행하지 않고 diagnostic_only 판단만 반환할 수 있다.

DOD-009 session identity glossary: mst_session_id is the canonical state machine identity payload/context field issued by mst.py as MST-{root_mst_id}-{started_at_compact}-{random}; it partitions .gran-maestro/state/{mst_session_id}/snapshot.json and .gran-maestro/sessions/{mst_session_id}/history.*. MST_SESSION_ID is the environment variable carrying the same canonical identity through child invocation, subprocess, and hook execution. A root resource ID such as AGI-030, PLN-638, or REQ-* can be the root component inside mst_session_id, but it is not the full canonical session identity. A process diagnostic ID such as owner_pid, MST_STATE_PPID, hook session_id, or transcript UUID is diagnostic-only; diagnostic output is allowed, but those values are not canonical source, fallback, alias, migration requirement. legacy aliases such as session_id, sessionId, or MST_SNAPSHOT_SESSION_ID are compatibility diagnostics and not canonical source, fallback, alias, migration requirement. source precedence is validated history ledger, validated state snapshot, then prompt summary as diagnostic-only context.

Step 0.1: 자율 모드 감지

1. args 전체 토큰에서 -a 또는 --auto 존재 여부 검사:
   • 감지 시 AUTO_MODE=true (args 어느 위치든 허용)
2. args에 없으면 read_workflow_state_auto_mode("mst:accept", REQ_ID) 호출 (helper는 T01에서 추가됨)
   • 반환 bool → AUTO_MODE에 채택
   • None → 3번 단계로 진행
3. Bash(python3 {PLUGIN_ROOT}/scripts/mst.py config get auto_mode.accept)로 config.auto_mode.accept 확인
   • true이면 AUTO_MODE=true
4. 미설정 또는 false이면 AUTO_MODE=false (기본)
5. AUTO_MODE=true이면 수락 AskUserQuestion을 전부 생략하고 최종 머지 단계까지 무정지 진행한다.

AUTO_MODE와 DAG 연쇄 정책 분리 (MANDATORY)

AUTO_MODE는 "이 accept 호출의 무정지 실행"만 제어합니다. dependencies.blocks를 기반으로 한 DAG 연쇄 재기동 여부는 기존 정책 플래그만 참조합니다:

• workflow.auto_approve_on_unblock (config)
• request.json.auto_approve (해당 REQ 속성)

따라서 /mst:accept -a REQ-N이 workflow.auto_approve_on_unblock=false 환경에서 호출되어도 후속 REQ로의 자동 연쇄는 발생하지 않습니다. AUTO_MODE와 DAG 연쇄를 같은 신호로 취급하지 마십시오. 또한 approve의 auto-accept guard 차단은 AUTO_MODE와 별개이며, 차단된 건은 approve 단계에서 연쇄 호출이 멈춘 뒤 수동 /mst:accept로만 진입합니다.

세션 중 자율 모드 전환

사용자가 대기 중 "auto로", "자율 모드로", "-a로", "지금부터 자동으로" 등 입력 시 즉시 AUTO_MODE=true로 전환하고 [자율 모드 전환] 이제부터 -a 모드로 진행합니다. 출력 후 현재 Step부터 재개합니다.

REQ ID 결정 (인자 없이 호출 시)

requests/의 모든 request.json 스캔 → current_phase==3 + phase3_review/PASS 상태 필터링 → REQ 번호 오름차순 첫 번째 선택 (없으면 "대기 중 요청 없음" 알림)

최종 수락 실행 (Phase 3 → Phase 5)