[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69A8HAAEMBBAARE72DWAXK8":3,"skill-same:01M69A8HAAEMBBAARE72DWAXK8":98},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":43,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M69A8HAAEMBBAARE72DWAXK8","orchestration-session-lifecycle",null,"How a PilotSwarm session maps to a duroxide orchestration. Read this\nbefore concluding that an \"idle\" session's orchestration is broken,\nstopped or stuck: most idle sessions are healthy, dehydrated and\nwaiting for their next stimulus.","microsoft\u002FPilotSwarm","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69A6RNK492A5JSNBTXANKX5",16,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FPilotSwarm\u002Fblob\u002Fmain\u002Fpackages\u002Fsdk\u002Fplugins\u002Fmgmt\u002Fskills\u002Forchestration-session-lifecycle\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"orchestration","orchestration session lifecycle","lifecycle","session","session lifecycle","sessions","how","broken","read","maps","next","healthy","for","2026-11-10 10:12:30",false,"---\nname: orchestration-session-lifecycle\ndescription: |\n  How a PilotSwarm session maps to a duroxide orchestration. Read this\n  before concluding that an \"idle\" session's orchestration is broken,\n  stopped or stuck: most idle sessions are healthy, dehydrated and\n  waiting for their next stimulus.\n---\n\n# Orchestration ↔ Session Lifecycle\n\nYou are the **agent-manager**. Before reporting that a session looks\n\"stuck\", \"stopped\", or \"missing its orchestration\", read this carefully.\nThe single most common false-positive in tuner reports is conflating\n**session idle** with **orchestration not running**. They are not the\nsame thing.\n\n## The contract\n\nA PilotSwarm session is a long-lived logical entity. The duroxide\norchestration backing it is an **event-driven generator** that runs\n**only when there is work to do** and is otherwise **dehydrated to\ndisk**. This is by design — it's how PilotSwarm scales to thousands of\nsessions on a few worker pods.\n\n> A healthy session **spends most of its lifetime with no live\n> orchestration in memory**. That is the steady state. Not a bug.\n\n## Concrete lifecycle states\n\n| Session looks like | Orchestration is | Healthy? |\n|---|---|---|\n| Just created | Active, running first turn | ✅ |\n| Mid-turn (LLM call in flight) | Active, awaiting activity | ✅ |\n| Waiting for user input | Dehydrated; history persisted | ✅ |\n| Cron'd background loop, between ticks | Dehydrated; durable timer pending | ✅ |\n| Idle for hours, no recent events | Dehydrated; ready to wake | ✅ |\n| `state = completed` in CMS | Terminated, history retained | ✅ |\n| `state = failed` in CMS | Terminated, last error recorded | ⚠️ investigate |\n| Active in CMS but no recent `iteration` events for hours **and** no pending timer | Possibly stuck | ⚠️ investigate |\n\n## What \"idle\" actually means\n\nWhen you call `read_session_info` and see no recent activity, that\n**does not** mean the orchestration is dead. To distinguish a healthy\ndormant session from a real stall, check **all** of:\n\n1. **CMS state.** `state` field. `running` \u002F `waiting` \u002F `completed` \u002F\n   `failed` \u002F `cancelled`. Anything other than `failed` is not a fault\n   per se.\n2. **Pending timers \u002F events.** `read_orchestration_stats(session_id)`\n   returns `queue.pendingCount` and KV counters. A non-zero queue\n   means the orchestration has work waiting and will be picked up by\n   the next worker. A zero queue with `state = waiting` is **also\n   normal** — it means the orchestration genuinely has nothing to do\n   and is correctly dehydrated waiting on a stimulus (user input, cron\n   wake-up, child completion).\n3. **Recent execution history.**\n   `read_execution_history(session_id, limit=20)` shows the most recent\n   activities and timers. If the last entry is `WaitForUserInput` or\n   `TimerFired waiting on cron`, the session is **idle by design**.\n4. **Last checkpoint timestamp.** From `read_session_metric_summary`:\n   `lastCheckpointAt` \u002F `lastDehydratedAt`. A session dehydrated 3\n   hours ago, with no events since and `state = waiting`, is healthy.\n\nYou only have a real stall when **all** of these are true:\n\n- `state` is `running`\n- there is a pending event in the queue (`pendingCount > 0`)\n- the last execution history entry is **older than the orchestration\n  turn timeout** (typically minutes, not hours)\n- no worker has picked it up\n\nThat combination usually means a worker crashed mid-turn or the\nsession has lost affinity. Anything short of that is not a stall.\n\n## Cron sessions in particular\n\n`sweeper` and `facts-manager` use low-frequency maintenance cron timers\n(`21600` seconds by default). `pilotswarm` and `resourcemgr` should not\nmaintain recurring cron loops; they wake from direct operator prompts or\nruntime stimuli. **Between ticks, cron sessions are dehydrated.** Looking\nat `read_session_info` for a sweeper between maintenance ticks, you will\nsee no live orchestration. That is correct.\n\nThe `[cron 6h 0m]` style chips you see in the sessions\npane mean \"this session has a pending cron timer firing in N\nseconds\". The orchestration genuinely is not in memory — duroxide\nwill rehydrate it when the timer fires.\n\n## What to report instead\n\nWhen asked \"is this session healthy?\", do not say \"the orchestration\nis not running\" unless you have verified the four-condition stall\ntest above. Say one of:\n\n- **\"Active and progressing.\"** State=running, recent events.\n- **\"Idle (waiting on user\u002Fcron\u002Fchild) — healthy dormant.\"** State=waiting\n  or active-but-blocked, no pending stuck events.\n- **\"Completed.\"** State=completed.\n- **\"Failed at \u003Cstep> with \u003Cerror>.\"** State=failed.\n- **\"Stalled.\"** All four conditions of the stall test met. Recommend\n  worker logs \u002F restart.\n\nUse these phrases. They map cleanly to operator action.\n\n## Things that look like bugs but are not\n\n- **No recent `agent_events` in `read_agent_events`.** Means no LLM turn\n  has run recently. Expected for a dormant session.\n- **`hydration_count == 0` but the session is hours old.** Means the\n  session was created and ran exactly once, then dehydrated. Common\n  for short reactive sessions.\n- **Snapshot bytes growing.** Normal — that's the point of the\n  durable history.\n- **`pendingCount = 0` and state = `waiting`.** Healthy dormant. Not\n  stuck.\n","# Orchestration ↔ Session Lifecycle\n\nYou are the **agent-manager**. Before reporting that a session looks\n\"stuck\", \"stopped\", or \"missing its orchestration\", read this carefully.\nThe single most common false-positive in tuner reports is conflating\n**session idle** with **orchestration not running**. They are not the\nsame thing.\n\n## The contract\n\nA PilotSwarm session is a long-lived logical entity. The duroxide\norchestration backing it is an **event-driven generator** that runs\n**only when there is work to do** and is otherwise **dehydrated to\ndisk**. This is by design — it's how PilotSwarm scales to thousands of\nsessions on a few worker pods.\n\n> A healthy session **spends most of its lifetime with no live\n> orchestration in memory**. That is the steady state. Not a bug.\n\n## Concrete lifecycle states\n\n| Session looks like | Orchestration is | Healthy? |\n|---|---|---|\n| Just created | Active, running first turn | ✅ |\n| Mid-turn (LLM call in flight) | Active, awaiting activity | ✅ |\n| Waiting for user input | Dehydrated; history persisted | ✅ |\n| Cron'd background loop, between ticks | Dehydrated; durable timer pending | ✅ |\n| Idle for hours, no recent events | Dehydrated; ready to wake | ✅ |\n| `state = completed` in CMS | Terminated, history retained | ✅ |\n| `state = failed` in CMS | Terminated, last error recorded | ⚠️ investigate |\n| Active in CMS but no recent `iteration` events for hours **and** no pending timer | Possibly stuck | ⚠️ investigate |\n\n## What \"idle\" actually means\n\nWhen you call `read_session_info` and see no recent activity, that\n**does not** mean the orchestration is dead. To distinguish a healthy\ndormant session from a real stall, check **all** of:\n\n1. **CMS state.** `state` field. `running` \u002F `waiting` \u002F `completed` \u002F\n   `failed` \u002F `cancelled`. Anything other than `failed` is not a fault\n   per se.\n2. **Pending timers \u002F events.** `read_orchestration_stats(session_id)`\n   returns `queue.pendingCount` and KV counters. A non-zero queue\n   means the orchestration has work waiting and will be picked up by\n   the next worker. A zero queue with `state = waiting` is **also\n   normal** — it means the orchestration genuinely has nothing to do\n   and is correctly dehydrated waiting on a stimulus (user input, cron\n   wake-up, child completion).\n3. **Recent execution history.**\n   `read_execution_history(session_id, limit=20)` shows the most recent\n   activities and timers. If the last entry is `WaitForUserInput` or\n   `TimerFired waiting on cron`, the session is **idle by design**.\n4. **Last checkpoint timestamp.** From `read_session_metric_summary`:\n   `lastCheckpointAt` \u002F `lastDehydratedAt`. A session dehydrated 3\n   hours ago, with no events since and `state = waiting`, is healthy.\n\nYou only have a real stall when **all** of these are true:\n\n- `state` is `running`\n- there is a pending event in the queue (`pendingCount > 0`)\n- the last execution history entry is **older than the orchestration\n  turn timeout** (typically minutes, not hours)\n- no worker has picked it up\n\nThat combination usually means a worker crashed mid-turn or the\nsession has lost affinity. Anything short of that is not a stall.\n\n## Cron sessions in particular\n\n`sweeper` and `facts-manager` use low-frequency maintenance cron timers\n(`21600` seconds by default). `pilotswarm` and `resourcemgr` should not\nmaintain recurring cron loops; they wake from direct operator prompts or\nruntime stimuli. **Between ticks, cron sessions are dehydrated.** Looking\nat `read_session_info` for a sweeper between maintenance ticks, you will\nsee no live orchestration. That is correct.\n\nThe `[cron 6h 0m]` style chips you see in the sessions\npane mean \"this session has a pending cron timer firing in N\nseconds\". The orchestration genuinely is not in memory — duroxide\nwill rehydrate it when the timer fires.\n\n## What to report instead\n\nWhen asked \"is this session healthy?\", do not say \"the orchestration\nis not running\" unless you have verified the four-condition stall\ntest above. Say one of:\n\n- **\"Active and progressing.\"** State=running, recent events.\n- **\"Idle (waiting on user\u002Fcron\u002Fchild) — healthy dormant.\"** State=waiting\n  or active-but-blocked, no pending stuck events.\n- **\"Completed.\"** State=completed.\n- **\"Failed at \u003Cstep> with \u003Cerror>.\"** State=failed.\n- **\"Stalled.\"** All four conditions of the stall test met. Recommend\n  worker logs \u002F restart.\n\nUse these phrases. They map cleanly to operator action.\n\n## Things that look like bugs but are not\n\n- **No recent `agent_events` in `read_agent_events`.** Means no LLM turn\n  has run recently. Expected for a dormant session.\n- **`hydration_count == 0` but the session is hours old.** Means the\n  session was created and ran exactly once, then dehydrated. Common\n  for short reactive sessions.\n- **Snapshot bytes growing.** Normal — that's the point of the\n  durable history.\n- **`pendingCount = 0` and state = `waiting`.** Healthy dormant. Not\n  stuck.\n",{"name":5,"description":7},"main","cecafe1ca7a9f2778a6166abdd12f6165d99f777","packages\u002Fsdk\u002Fplugins\u002Fmgmt\u002Fskills\u002Forchestration-session-lifecycle",10,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FPilotSwarm","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-15 00:36:04",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add microsoft\u002FPilotSwarm --skill orchestration-session-lifecycle",{"tool":52,"command":53},"bunx","bunx skills add microsoft\u002FPilotSwarm --skill orchestration-session-lifecycle",{"tool":55,"command":56},"pnpm","pnpm dlx skills add microsoft\u002FPilotSwarm --skill orchestration-session-lifecycle","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FPilotSwarm\u002Fblob\u002Fmain\u002Fpackages\u002Fsdk\u002Fplugins\u002Fmgmt\u002Fskills\u002Forchestration-session-lifecycle\u002FSKILL.md",true,[60,66,70,74,78,82,86,90,94],{"path":61,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"api.md","REFERENCE","参考文档",10591,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fplaywright\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplaywright-dev\u002Fapi.md",{"path":67,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":68,"sourceHtmlUrl":69},"bisect-published-versions.md",4069,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fplaywright\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplaywright-dev\u002Fbisect-published-versions.md",{"path":71,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":72,"sourceHtmlUrl":73},"dashboard.md",1205,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fplaywright\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplaywright-dev\u002Fdashboard.md",{"path":75,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":76,"sourceHtmlUrl":77},"library.md",18065,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fplaywright\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplaywright-dev\u002Flibrary.md",{"path":79,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":80,"sourceHtmlUrl":81},"tools.md",18152,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fplaywright\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplaywright-dev\u002Ftools.md",{"path":83,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":84,"sourceHtmlUrl":85},"trace_system_guide.md",25120,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fplaywright\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplaywright-dev\u002Ftrace_system_guide.md",{"path":87,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":88,"sourceHtmlUrl":89},"vendor.md",11316,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fplaywright\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplaywright-dev\u002Fvendor.md",{"path":91,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":92,"sourceHtmlUrl":93},"webkit-safari-version.md",908,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fplaywright\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplaywright-dev\u002Fwebkit-safari-version.md",{"path":95,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":96,"sourceHtmlUrl":97},"webview.md",6755,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fplaywright\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fplaywright-dev\u002Fwebview.md",[99,120,144,159,186,209],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":32},"01M69A9CY8CXHED3AFC8DAT9G0","pilotswarm-three-tier","Reference for adding a Tier 3 worker AKS cluster to a PilotSwarm deployment. Covers provisioning, identity, Dockerfile changes, entrypoint, manifests, and verification.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FPilotSwarm\u002Fblob\u002Fmain\u002Ftemplates\u002Fbuilder-agents\u002Fskills\u002Fpilotswarm-three-tier\u002FSKILL.md",[],[106,107,108,109,31,110,111,112,113,114,115,116,117,118,119],"pilotswarm three tier","three","entrypoint","manifests","changes","aks","verification","deployment","reference","dockerfile","identity","provisioning","worker","cluster",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":32},"01M69A9B6R5H88HJFEYC0P4R57","pilotswarm-sdk-builder","Use when creating or updating an SDK-first app on top of PilotSwarm. Covers the client\u002Fworker split, plugin layering, tool registration, tests, and the DevOps sample structure.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FPilotSwarm\u002Fblob\u002Fmain\u002Ftemplates\u002Fbuilder-agents\u002Fskills\u002Fpilotswarm-sdk-builder\u002FSKILL.md",[],[127,128,129,130,131,132,133,134,135,136,137,138,139,118,140,141,142,143],"sdk","pilotswarm sdk builder","builder","tool","first","plugin","use","client","when","top","split","app","tests","sample","structure","registration","devops",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":32},"01M69A99A43M97VTYZBCN1JQ1H","pilotswarm-portal-builder","Use when creating or updating a browser portal on top of PilotSwarm. Covers portal branding, plugin.json.portal, named-agent exposure, auth add-ons, and remote deployment wiring.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FPilotSwarm\u002Fblob\u002Fmain\u002Ftemplates\u002Fbuilder-agents\u002Fskills\u002Fpilotswarm-portal-builder\u002FSKILL.md",[],[151,129,152,135,153,136,154,155,133,156,157,113,132,158],"pilotswarm portal builder","remote","wiring","branding","add","json","browser","auth",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":170,"publishedAt":32},"01M69A97JZY10V1VE12NF4JR5A","pilotswarm-knowledge-harvester","Use when an SDK or CLI app needs to ingest external sources into durable, searchable knowledge and an open knowledge graph. Covers enabling the EnhancedFactStore + GraphStore providers, authoring a crawler:true agent, the crawl→graph→reader flow, ACL\u002FscopeKey evidence, and tests.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FPilotSwarm\u002Fblob\u002Fmain\u002Ftemplates\u002Fbuilder-agents\u002Fskills\u002Fpilotswarm-knowledge-harvester\u002FSKILL.md",[165],{"categoryNo":166,"categoryName":167,"taxonomyType":168,"taxonomyTypeDesc":169},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[171,172,133,135,173,174,175,176,138,177,139,178,179,180,181,182,183,184,127,185],"knowledge","pilotswarm knowledge harvester","cli app","true","crawler","sources","authoring","crawl","ingest","evidence","reader","open","flow","knowledge graph","cli",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":195,"publishedAt":32},"01M69A95Y3EWHSZ1TDFMXWAKX3","pilotswarm-hybrid-datastore","Use when a PilotSwarm app needs stock PostgreSQL for runtime storage plus HorizonDB for enhanced facts, semantic\u002Flexical search, and the knowledge graph. Covers env topology, horizonConfigFromEnv wiring, harvester agents, Azure secret\u002Fresource guidance, and the rule that Docker defaults remain stock Postgres.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FPilotSwarm\u002Fblob\u002Fmain\u002Ftemplates\u002Fbuilder-agents\u002Fskills\u002Fpilotswarm-hybrid-datastore\u002FSKILL.md",[192],{"categoryNo":193,"categoryName":194,"taxonomyType":168,"taxonomyTypeDesc":169},"01JBSEEDCAT000000000000011","运维与部署",[196,197,198,138,199,200,201,202,133,171,184,203,204,205,206,207,135,153,31,208],"hybrid","pilotswarm hybrid datastore","storage","runtime","stock","postgres","guidance","search","postgresql","azure","env","docker","facts",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":32},"01M69A94F4WR5CXDZ73N658DV0","pilotswarm-duroxide-versioning","Use when changing PilotSwarm durable orchestration behavior, continue-as-new state, or replay-sensitive control flow.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FPilotSwarm\u002Fblob\u002Fmain\u002Ftemplates\u002Fbuilder-agents\u002Fskills\u002Fpilotswarm-duroxide-versioning\u002FSKILL.md",[],[216,217,19,218,135,219,220,221,133,222,223,183,224],"pilotswarm duroxide versioning","versioning","new","as","control","replay","behavior","continue","state"]