Skip to content

v0.6.7

Choose a tag to compare

@github-actions github-actions released this 18 Oct 10:17
· 118 commits to main since this release
8867e43

[0.6.7] - 2026-10-18

Added

  • The llm-fallbacks service grows one additive read-only method: getAgentRole(agentId) returns the DECLARED RAW role id a live subagent was dispatched as (trimming preserved), readable from the moment of dispatch — before the child's first step and for its whole activation lifetime — and null whenever no dispatch role resolved for that id.
  • ROLE_PROJECTION_KEY and readRoleProjectionValue are now re-exported from the package root, so a companion reads the durable fallbacksSubagentRole session projection without hard-coding the key literal or re-implementing the blank-string guard.

Changed

  • The role a dispatch declares (**Execute as**: <id> in the child's prompt) is now an explicit stage of dispatch-time role resolution, so a declared role's chain head drives the child's first request — including an Agent Team teammate's initial spawn prompt.
  • Agent Team teammates get their persona, role notice/badge and chain-head model from that same header; teammate names stay arbitrary, several teammates may share one role, and an external provider still delivers no persona, notice or badge.
  • Restructured the README around three core capabilities (automatic model failover, peak/valley time slots, role-based subagents) and moved the reference detail into the new docs/features.md and docs/repair.md.
  • Documented that the role-based subagent pillar covers both ordinary dispatch and Agent Team teammates through the same **Execute as**: <id> dispatch header.

Fixed

  • pnpm repair:session-logs works against the dsh 0.2.1-rc.2 session-format catalog again: a pre-V3 log is repaired and published as its V3 repair-floor generation through the catalog's own historicalSessionFormatCatalog, and the host migrates that generation onward to the installed V4 format with its own historical child evidence. Previously every --apply publication and every catalog classification of a pre-V3 log failed with V3 catalog migration requires explicit historical child facts, because the newer catalog's V3→V4 edge needs corpus-level child evidence a single-log repair cannot supply.
  • The resolved catalog's repair floor is now validated and reported: a newer build without a usable historicalSessionFormatCatalog is refused up front (exit 2), and the text/--json report names both the installed currentVersion and the repairVersion successors are published at.