PilotSwarm v0.5.14

Highlights

• Per-user session ownership, private/shared visibility, targeted read/write grants, and authorization audit trails.
• Server-stamped sender identity and owner-priority handling for shared and cross-owner session messages.
• Synchronized portal, TUI, Web API, WebSocket, and MCP sharing controls, plus fail-closed local dev personas.
• Processed outbox prompts no longer remain visibly queued after completion.
• Durable orchestration advances to 1.0.61 with the published 1.0.60 schedule frozen for replay safety.
• CMS migrations 0029-0033 and validated transactional/non-transactional migration execution modes.

Published artifacts

• npm: pilotswarm-sdk@0.5.14
• npm: pilotswarm-horizon-store@0.5.14
• npm: pilotswarm@0.5.14
• Docker: pilotswarm-starter:v0.5.14, :0.5.14, and :latest for linux/amd64 and linux/arm64

Validation

• All three workspaces built successfully.
• All three npm packages passed dry-pack inspection, including package-local READMEs and required runtime files.
• Full and targeted tests were skipped at maintainer request. The latest attempted targeted command (./scripts/run-tests.sh --with-horizondb check-agents session-policy-behavior) exited 1 and was not treated as passing.

PilotSwarm v0.5.13

Reliability and contract hardening

• Pending-question answers now interrupt the input hold immediately instead of waiting behind the 30-minute affinity timer.
• GitHub Copilot credential failures persist as visible, recoverable session errors with Admin guidance.
• Reused SDK and MCP session handles refresh response cursors before sendAndWait, preventing stale responses.
• Agent skills: declarations preload named plugin skills, with missing-skill diagnostics.
• Child result contracts publish concrete fact/artifact references and normalize compatible aliases.
• Child sessions inherit model, reasoning effort, and context tier together.
• Published app documentation now covers shared Entra login, remote TUI usage, MCP client setup, and HTTP transport security.

Release validation

• Workspace build passed for pilotswarm-sdk, pilotswarm-horizon-store, and pilotswarm.
• npm dry-pack validation passed for all three packages, including package-local READMEs, SDK plugins, Horizon migrations, and app bins.
• Full tests were not rerun during the release step at maintainer request; the maintainer had already completed the all-provider suite.

This release also triggers the multi-platform pilotswarm-starter Docker image publish for v0.5.13, 0.5.13, latest, and the release SHA.

v0.5.12 — Artifact API v2: a real data plane for agents

Artifact API v2

The model is a control plane, not a wire. Agents now move bytes by reference:

• write_artifact takes exactly one source: inline content, fromFile (worker-local path — streamed server-side, path-jailed, never transits the model; the fix for the base64-sidecar ceremony), or fromArtifact (server-side copy from another session, optional expectedSha256 precondition).
• read_artifact gains toFile (stream to worker disk — the binary read path), metaOnly (provenance stat), bounded inline reads (maxBytes/offset + truncated), and encoding: "base64" for small binaries.
• SHA-256 + provenance in every result (sha256, source, sourceDetail, pinned, artifactLink). BREAKING: export_artifact is retired — the link comes back from every write.
• Pinning: pinned artifacts survive bulk session cleanup.
• Blob store env fix: PILOTSWARM_BLOB_USE_MANAGED_IDENTITY is honored (explicit value wins) and an account URL with no credential path now throws instead of silently degrading to the filesystem store.
• MCP: new copy_artifact + pin_artifact; get_artifact gains include: "base64" and loud not-found. TUI uploads stream with digests.
• Base prompts teach pod filesystem isolation and the fromFile→toFile handoff; the framework default agent ships list_artifacts again.

Docs, builder templates, and the DevOps sample updated; design rationale in docs/proposals/artifact-api-v2.md.

Validation: full run-tests.sh --all-providers green on both storage providers (postgres 1058 tests, HorizonDB overlay 1071); new unit suites (artifact-api-v2 ×17, blob-store-mi-flag ×7) verified red-on-old-code; live AKS smoke confirmed byte-exact binary handoff top-level↔top-level and parent↔child. Formal test suites were run pre-release; the release itself skipped re-running them per maintainer instruction.

🤖 Generated with Claude Code

https://claude.ai/code/session_019NHSmwAEaENnD2ZtjKZhnP

v0.5.11

Two session-reliability fixes, both found investigating a wedged facts-manager on a production fleet (2026-07-12):

SDK

• Zombie turns now self-settle. When the Copilot CLI subprocess died mid-turn (e.g. V8 heap OOM), session.idle never arrived and the durable runTurn activity stayed in-flight forever — the session wedged while its queue backed up. Two worker-side guards now settle the turn (explicit 0 disables either):
  • Inactivity watchdog (turnInactivityTimeoutMs, default 5 min): total event silence means a dead or wedged subprocess; settles as a retryable transport-loss error riding the existing recovery path (release affinity → retry on a fresh subprocess → bounded lossy-handoff fallback).
  • Wall-clock turn cap (turnTimeoutMs, now defaulted to 10 min — previously dead code that nothing enabled).
• Stale cron timer fires after cron(action="cancel") are ignored instead of dereferencing the cleared schedule and throwing a TypeError that surfaced as a non-retryable OrchestrationFailed, permanently failing the session and orphaning its sub-agents.

Verification

Full --all-providers suite green before release: baseline PgFactStore 153 passed / 2 skipped; HorizonDB overlay 18 provider files + 154 passed / 1 skipped; 0 failed test entries across all phases. New regression coverage: turn-inactivity-watchdog.test.js (5 cases) and orchestration-stale-cron-timer.test.mjs (2 cases).

v0.5.10

Highlights

• Portal session list shows real owner initials instead of ?. The paged
  list read path (cms_list_sessions_page) returned SETOF sessions — the raw
  table, which carries no owner columns — so every listed session reached the UI
  with owner: null. CMS migration 0028 recreates it with the
  session_owners/users join that cms_list_sessions already performs.
  Ownership was always persisted; only this read path dropped it. No render-side
  change.
• Agent mobile splash screens persist correctly. normalizeCreatableAgent
  forwarded splash but dropped splashMobile, so agent sessions stored only
  the desktop banner and phones fell back to the wide art. The field now flows
  through the normalizer (the single source feeding both the worker and the
  portal's baked-plugin-dir catalog), system-agent creation, and inspect-tools.
• Redesigned management-agent desktop splashes (pilotswarm, sweeper,
  agent-tuner, resourcemgr, facts-manager) — solid ANSI-Shadow logos with
  per-row color bands, boxed roles, and flavor lines.

Tests / CI

• New migration-shape unit test (test:unit) locking the paged-list column set
  to the canonical cms_list_sessions shape, plus a DB-backed
  test:local:cms for the paged owner join.
• Fixed a latent CI build-order bug in tests.yml (built workspaces
  alphabetically, so app compiled before sdk); it now uses the
  dependency-ordered root build like publish-npm.yml.

Test run note

The full integration suite was run sequentially (parallel exhausts CI's
Postgres max_connections). All suites passed except knowledge-pipeline > Merged intakes produce single skill visible to agent, an LLM-driven skill-merge
test with known non-determinism; it passed on isolated re-run. Called out per
release policy — no product change is implicated.

v0.5.9

SDK

• Sub-agents spawned by a system session now inherit the SYSTEM user as their owner (staying deletable and manageable) instead of being marked is_system. Both spawn paths resolve the lineage's effective owner via a shared resolveEffectiveSpawnOwner walk; the child still resolves the admin-stored System GitHub Copilot key through the ordinary per-owner credential path.

Portal

• One unified "System" bucket in the session owner filter — covers both is_system agents and System-owned children (no more duplicate "System" entry).
• The default view reliably shows your own sessions — the profile-default fallback is derived from the resolved principal (Me + System), not a mount-time {all:true} snapshot.
• The owner-filter list stays live while open — it rebuilds on each catalog refresh, so newly-arrived owners appear without reopening.
• Light dividers between rows in the full-screen (desktop) portal session list.

v0.5.8

0.5.8 — 2026-07-10

SDK

• Sub-agents of a system session are marked system in the spawn path the LLM
  actually uses. 0.5.7 restored the parent→child isSystem propagation in
  handleSubAgentAction, but the spawn_agent tool routes through
  controlBridge.spawnAgent (session-proxy) — a separate, near-duplicate spawn
  path that never set the child's isSystem at all (it computed agentIsSystem
  from the agent definition and used it only for the title). So sub-agents of a
  working system session were still created non-system and kept failing GitHub
  Copilot turns with "key not configured". The real path now reads the parent's
  authoritative CMS row (not any in-memory flag, which a worker restart drops)
  and sets the child's is_system before its bootstrap turn is sent, so the
  child's first turn resolves the System key from its own row. The
  orchestration input also adopts cmsRow.isSystem in
  _ensureOrchestrationAndSend, so a resumed system session's flag survives
  worker restarts. Guarded by a restored end-to-end integration test that
  exercises the real path (it failed against the 0.5.7 build).

v0.5.7

0.5.7 — 2026-07-10

SDK

• A child spawned by a system session is again a system session. System
  sessions are ownerless, so a spawned child inherits no owner — its only route
  to a GitHub Copilot credential is the ownerless SYSTEM identity, i.e. the
  admin-stored System key (_resolveSessionGitHubToken falls back to
  SYSTEM_USER_PRINCIPAL only when the row is isSystem and has no owner).
  The modular orchestration set a child's isSystem only from the spawned
  agent definition's own system flag and dropped the parent→child propagation
  the pre-modular orchestration had, so children of a working system session
  came out ownerless and non-system and then failed every GitHub Copilot
  turn with "GitHub Copilot key not configured" — even though the parent ran
  fine on the System key. handleSubAgentAction now propagates the parent's
  isSystem to the child.

v0.5.6

0.5.6 — 2026-07-10

SDK / API / MCP

• Context-window tier is now part of the Switch Model path, end to end. The
  durable set_model command handler applies contextTier to the session
  config like reasoning effort — omitted preserves the current tier, present
  rebinds the model on the next turn (via the existing requiresModelRebind).
  management-client.setSessionModel (and the web-management client) validate
  the tier against the target model's supportedContextTiers and forward it,
  and the MCP switch_model tool gains a context_tier argument (Web API
  mode). The POST /management/sessions/:id/model body accepts contextTier.

Portal / TUI

• Switch Model offers the context-window step. Previously the picker chain
  was model → effort → apply; for tier-capable models it is now model → effort
  → context window → apply (tier-less models still apply directly), preselecting
  the smaller window. Works in both the portal and the TUI.
• Switch Model is reachable in the TUI. It had no keybinding (only the
  portal button); it is now bound to Shift+M (sibling of Shift+N =
  new+model) and listed in the keybinding help.

v0.5.5

0.5.5 — 2026-07-10

Portal / TUI

• Answers to a pending question are delivered immediately instead of being
  queued. A question renders from the live session.input_required_started
  event well before the slower customStatus detail-sync populates
  session.pendingQuestion. An answer typed inside that window failed the
  pendingQuestion gate and fell through to the outbox queue — where, being a
  queued message rather than an orchestration answer, it sat unconsumed until
  the next send flushed it. The controller now sets pendingQuestion + status
  synchronously from the event (which already carries the question, choices, and
  freeform flag) so the answer takes the direct sendAnswer path, and guards
  that freshly-shown question against a stale same-age detail-sync that raced
  the event. Affects both the portal and the TUI.