메뉴
Diagnose slow or inconsistent managed Longhouse sessions by separating provider-loop latency, local hook/control-path health, hosted ingest lag, and runtime-state mismatches.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Zerg/Longhouse full ship cycle — test, deploy, QA, verify. Use when pushing changes to production or doing a full dev→deploy iteration.
Zerg local dev workflow (make dev, logs, debug, stop). Use when running or troubleshooting this repo.
Longhouse managed provider CLI control paths for Claude, Codex, Antigravity, and similar CLIs. Use when investigating or changing managed sessions, provider binary ownership, `longhouse claude`, `longhouse codex`, bridge/relay/hook behavior, local-health liveness, reattach behavior, stale provider runtimes, or AGENTS.md guidance about managed vs unmanaged sessions.
Refresh and ship the Longhouse landing hero video, poster, and supporting product screenshots from realistic demo data, then verify the responsive composition visually.
Zerg testing workflow (unit + E2E). Use when running or debugging tests.
Debug hosted Longhouse instances on the runtime host. Use when investigating a hosted tenant / live prod behavior, control-plane-managed tenants, managed session state, hosted auth, or tenant SQLite state.
| name | managed-session-debug |
| description | Diagnose slow or inconsistent managed Longhouse sessions by separating provider-loop latency, local hook/control-path health, hosted ingest lag, and runtime-state mismatches. |
Use this when a managed Claude/Codex/Gemini session feels slow, appears stuck, shows the wrong lifecycle state, or disagrees between local CLI and hosted timeline.
For "is transcript shipping live/slow?" questions, check ~/.longhouse/agent/engine-status.json ship_lanes.live and Shipped transcript engine logs before static code reading.
Local truth:
longhouse local-health --json | jq '.managed_sessions[]? | select(.session_id=="<session-id>")'
Provider transcript timing:
scripts/ops/session-transcript-timing.mjs <session-id>
Hosted tenant truth:
scripts/ops/hosted-session-debug.sh --subdomain <subdomain> --session <session-id> --limit 20 --json
Process and channel state for Claude:
ps -axo pid,ppid,lstart,command | rg '<session-id>|claude-channel|longhouse-channel'
test -f ~/.claude/channels/longhouse/sessions/<session-id>.json && jq . ~/.claude/channels/longhouse/sessions/<session-id>.json
assistant_tool_to_tool_result means the tool itself or Claude hook/tool execution is slow.tool_result_to_next_assistant means provider/model-loop latency.assistant_text with no following tool_use, Stop, or idle phase is a stuck provider/TUI turn, not tool latency or hosted ingest lag. On a Bedrock Claude flow, also check whether LONGHOUSE_FORCE_NATIVE_CLAUDE_CHANNELS=1 is using the private native-channel patch.cache_read_input_tokens plus slow tool_result_to_next_assistant usually points at provider latency from a large thread, not Longhouse telemetry.sessions.ended_at with session_runtime_state.terminal_state = null is a state-model mismatch. Treat runtime state as the lifecycle source of truth.Claude hooks should be local-only and fast. The installed hook should write local presence/binding state and exit 0. If you suspect hook blocking, measure it with a synthetic event before blaming hosted telemetry.
~/.claude/projects/**/<session-id>.jsonl~/.claude/channels/longhouse/sessions/<session-id>.json/var/app-data/longhouse/<subdomain>/longhouse.db on the runtime hostlonghouse-<subdomain>End with a verdict:
provider latencytool/hook latencyhosted ingest lagruntime state mismatchunknownInclude the one or two numbers that prove it, not a full transcript dump.