When creating an agent session with --onboard or --submit-job, create_session.sh calls delegate_submit_job before persisting the session record via atomic_dump_yaml. Because multi-agent-mux-delegate-job verifies that the target session exists in .mam/agent-sessions.yaml / .mam/agent-sessions.db, it always fails with: ERROR: 에이전트 세션 '<session_name>'이 존재하지 않습니다. 작업을 위임하기 전에 먼저 에이전트 세션을 기동해 주세요.
Root Cause
In create_session.sh (lines 322-353):
Line 335: DELEGATE_JOB_ID=$(delegate_submit_job "$SUBMIT_JOB_PROMPT" "$delegate_agent" "$agent_session") is executed.
delegate_submit_job invokes multi-agent-mux-delegate-job submit, which queries has-session / registry state from agent-sessions.yaml and .mam/agent-sessions.db.
Line 353: atomic_dump_yaml "$AGENT_SESSIONS_YAML" ... runs afterdelegate_submit_job.
As a result, the session record has not yet been written to YAML or DB when the validation check occurs, causing delegate_submit_job to fail every time.
Proposed Fix
Execute atomic_dump_yaml first to persist the session in YAML and SQLite DB.
If --onboard or --submit-job is provided, call delegate_submit_job after the session is saved.
Update the session row in agent-sessions.yaml with the resulting delegate_job_id.
### Summary
When creating an agent session with `--onboard` or `--submit-job`, `create_session.sh` calls `delegate_submit_job` before persisting the session record via `atomic_dump_yaml`. Because `multi-agent-mux-delegate-job` verifies that the target session exists in `.mam/agent-sessions.yaml` / `.mam/agent-sessions.db`, it always fails with:
`ERROR: 에이전트 세션 '<session_name>'이 존재하지 않습니다. 작업을 위임하기 전에 먼저 에이전트 세션을 기동해 주세요.`
### Root Cause
In `create_session.sh` (lines 322-353):
1. Line 335: `DELEGATE_JOB_ID=$(delegate_submit_job "$SUBMIT_JOB_PROMPT" "$delegate_agent" "$agent_session")` is executed.
2. `delegate_submit_job` invokes `multi-agent-mux-delegate-job submit`, which queries `has-session` / registry state from `agent-sessions.yaml` and `.mam/agent-sessions.db`.
3. Line 353: `atomic_dump_yaml "$AGENT_SESSIONS_YAML" ...` runs **after** `delegate_submit_job`.
4. As a result, the session record has not yet been written to YAML or DB when the validation check occurs, causing `delegate_submit_job` to fail every time.
### Proposed Fix
1. Execute `atomic_dump_yaml` first to persist the session in YAML and SQLite DB.
2. If `--onboard` or `--submit-job` is provided, call `delegate_submit_job` after the session is saved.
3. Update the session row in `agent-sessions.yaml` with the resulting `delegate_job_id`.
코드 레벨 분석 및 통합 테스트를 통해 검증한 결과, 본 이슈에서 제기된 내용은 프레임워크 내부 호출 구조에 대한 오해에서 비롯된 것으로 확인되어 스킬 수정 없이 이슈를 종료합니다.
1. delegate_submit_job의 실제 호출 경로
create_session.sh에서 호출하는 delegate_submit_job() 함수(.agents/skills/lib.sh:1873-1886)는 CLI 래퍼인 multi-agent-mux-delegate-job submit을 실행하는 것이 아니라, 경량 등록 스크립트 python registry.py register를 직접 호출합니다.
registry.py register는 .mam/jobs/<job_id>.json 및 이벤트 로그 파일만 생성하여 신규 job_id를 반환할 뿐, agent-sessions.yaml이나 DB에 해당 세션이 존재하는지 검증하지 않습니다.
이는 에이전트 세션이 생성되기 전에 사용자가 수동으로 multi-agent-mux-delegate-job submit 명령을 직접 실행했을 때 발생하는 정상적인 사전 검증(Pre-flight check)입니다.
create_session.sh 내부에서는 이 CLI 래퍼를 호출하지 않으므로 해당 에러가 발생하지 않습니다.
3. 단일 트랜잭션 원자성(Atomicity) 설계 의도
현행 아키텍처는 delegate_submit_job으로 DELEGATE_JOB_ID를 먼저 발급받은 뒤, atomic_dump_yaml 1회 호출로 세션 메타데이터와 delegate_job_id를 YAML 및 SQLite DB에 단일 트랜잭션으로 원자적 기록하도록 설계되었습니다.
atomic_dump_yaml을 먼저 실행할 경우 불필요한 다중 I/O 및 락 경합이 발생하게 됩니다.
4. 테스트 검증 결과
--onboard 및 --submit-job 조합을 검증하는 통합 테스트(pytest tests/test_tier3_integration.py) 실행 결과 5/5 모두 정상 통과(100% PASS)함을 확인하였습니다.
### 🔍 검증 및 분석 결과 (Not a Bug / Works as Intended)
코드 레벨 분석 및 통합 테스트를 통해 검증한 결과, 본 이슈에서 제기된 내용은 프레임워크 내부 호출 구조에 대한 오해에서 비롯된 것으로 확인되어 스킬 수정 없이 이슈를 종료합니다.
---
### 1. delegate_submit_job의 실제 호출 경로
- `create_session.sh`에서 호출하는 `delegate_submit_job()` 함수(`.agents/skills/lib.sh:1873-1886`)는 CLI 래퍼인 `multi-agent-mux-delegate-job submit`을 실행하는 것이 아니라, **경량 등록 스크립트 `python registry.py register`를 직접 호출**합니다.
- `registry.py register`는 `.mam/jobs/<job_id>.json` 및 이벤트 로그 파일만 생성하여 신규 `job_id`를 반환할 뿐, `agent-sessions.yaml`이나 DB에 해당 세션이 존재하는지 검증하지 않습니다.
### 2. 에러 메시지의 실제 발생 원인
- 본문에서 인용된 `ERROR: 에이전트 세션 '<session_name>'이 존재하지 않습니다...` 메시지는 `multi-agent-mux-delegate-job` CLI 래퍼(469행)의 `run_agent()`에서만 출력됩니다.
- 이는 에이전트 세션이 생성되기 전에 사용자가 수동으로 `multi-agent-mux-delegate-job submit` 명령을 직접 실행했을 때 발생하는 정상적인 사전 검증(Pre-flight check)입니다.
- `create_session.sh` 내부에서는 이 CLI 래퍼를 호출하지 않으므로 해당 에러가 발생하지 않습니다.
### 3. 단일 트랜잭션 원자성(Atomicity) 설계 의도
- 현행 아키텍처는 `delegate_submit_job`으로 `DELEGATE_JOB_ID`를 먼저 발급받은 뒤, `atomic_dump_yaml` 1회 호출로 세션 메타데이터와 `delegate_job_id`를 YAML 및 SQLite DB에 **단일 트랜잭션으로 원자적 기록**하도록 설계되었습니다.
- `atomic_dump_yaml`을 먼저 실행할 경우 불필요한 다중 I/O 및 락 경합이 발생하게 됩니다.
### 4. 테스트 검증 결과
- `--onboard` 및 `--submit-job` 조합을 검증하는 통합 테스트(`pytest tests/test_tier3_integration.py`) 실행 결과 5/5 모두 정상 통과(100% PASS)함을 확인하였습니다.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
When creating an agent session with
--onboardor--submit-job,create_session.shcallsdelegate_submit_jobbefore persisting the session record viaatomic_dump_yaml. Becausemulti-agent-mux-delegate-jobverifies that the target session exists in.mam/agent-sessions.yaml/.mam/agent-sessions.db, it always fails with:ERROR: 에이전트 세션 '<session_name>'이 존재하지 않습니다. 작업을 위임하기 전에 먼저 에이전트 세션을 기동해 주세요.Root Cause
In
create_session.sh(lines 322-353):DELEGATE_JOB_ID=$(delegate_submit_job "$SUBMIT_JOB_PROMPT" "$delegate_agent" "$agent_session")is executed.delegate_submit_jobinvokesmulti-agent-mux-delegate-job submit, which querieshas-session/ registry state fromagent-sessions.yamland.mam/agent-sessions.db.atomic_dump_yaml "$AGENT_SESSIONS_YAML" ...runs afterdelegate_submit_job.delegate_submit_jobto fail every time.Proposed Fix
atomic_dump_yamlfirst to persist the session in YAML and SQLite DB.--onboardor--submit-jobis provided, calldelegate_submit_jobafter the session is saved.agent-sessions.yamlwith the resultingdelegate_job_id.🔍 검증 및 분석 결과 (Not a Bug / Works as Intended)
코드 레벨 분석 및 통합 테스트를 통해 검증한 결과, 본 이슈에서 제기된 내용은 프레임워크 내부 호출 구조에 대한 오해에서 비롯된 것으로 확인되어 스킬 수정 없이 이슈를 종료합니다.
1. delegate_submit_job의 실제 호출 경로
create_session.sh에서 호출하는delegate_submit_job()함수(.agents/skills/lib.sh:1873-1886)는 CLI 래퍼인multi-agent-mux-delegate-job submit을 실행하는 것이 아니라, 경량 등록 스크립트python registry.py register를 직접 호출합니다.registry.py register는.mam/jobs/<job_id>.json및 이벤트 로그 파일만 생성하여 신규job_id를 반환할 뿐,agent-sessions.yaml이나 DB에 해당 세션이 존재하는지 검증하지 않습니다.2. 에러 메시지의 실제 발생 원인
ERROR: 에이전트 세션 '<session_name>'이 존재하지 않습니다...메시지는multi-agent-mux-delegate-jobCLI 래퍼(469행)의run_agent()에서만 출력됩니다.multi-agent-mux-delegate-job submit명령을 직접 실행했을 때 발생하는 정상적인 사전 검증(Pre-flight check)입니다.create_session.sh내부에서는 이 CLI 래퍼를 호출하지 않으므로 해당 에러가 발생하지 않습니다.3. 단일 트랜잭션 원자성(Atomicity) 설계 의도
delegate_submit_job으로DELEGATE_JOB_ID를 먼저 발급받은 뒤,atomic_dump_yaml1회 호출로 세션 메타데이터와delegate_job_id를 YAML 및 SQLite DB에 단일 트랜잭션으로 원자적 기록하도록 설계되었습니다.atomic_dump_yaml을 먼저 실행할 경우 불필요한 다중 I/O 및 락 경합이 발생하게 됩니다.4. 테스트 검증 결과
--onboard및--submit-job조합을 검증하는 통합 테스트(pytest tests/test_tier3_integration.py) 실행 결과 5/5 모두 정상 통과(100% PASS)함을 확인하였습니다.