Skip to content

v0.6.0

Choose a tag to compare

@github-actions github-actions released this 21 Oct 07:11
· 5 commits to main since this release
3314013

RoleWeave 0.6.0

RoleWeave 0.6.0 adds versioned task briefings and collaboration dependencies, traceable relay handoff notes, per-task execution progress, opt-in delivery preflight and approval aging advice, and improves Codex reliability. It includes the eight commits after v0.5.0 through main revision b69b9d8a2a0271b0084e38670e1add22b1454640; the preparation commit synchronizes release versions and documentation. Release record #623 tracks review, exact source checks, publication and independent asset verification.

Changes

  • Project briefings: capture server-owned goal/task requirements and acceptance criteria before execution, preserve the same versioned snapshot in conversations and human review, and reject stale plans before a model call. Retries and approval resumes retain their task/plan binding (#619, #620).
  • Task collaboration: record explicit collaborators, responsibilities and same-project dependencies. Validated dependency graphs and current delivery/acceptance evidence gate execution; project views refresh current readiness while execution snapshots remain fixed. Recording a reviewer does not dispatch them or give them acceptance authority (#621, #620).
  • Relay handoffs: add optional per-step requirements and inspect persisted handoff notes alongside timeline replies. Snapshots identify the preceding completed results actually included in model input and disclose filtering, truncation and omitted sources. Relay sources share existing context budgets, avoid duplicate history and do not imply approval or acceptance (#617, #618).
  • Project progress: follow the latest task attempt in project cards, schedule rows and the task editor. Live execution stages and persisted snapshots recover after reconnect. Stage counts describe execution phases, not a percentage of work completed or time remaining; completed execution still requires delivery acceptance (#615, #616).
  • Delivery preflight: enable a project-level check and explicitly select versioned document references for acceptance criteria. The check reports reference structure, broken links, version conflicts and modification time. It does not read document bodies, call Laya, change goal status/health or issue an overall acceptance decision (#467, #508).
  • Approval aging: the existing default-off Laya integration can add advisory nudge, wait or discuss-close text to pending approvals. Only creation time, current time, decision kind and risk are submitted. Advice never hides pending high-risk items, grants/denies approval or changes expiry rules (#466, #506).
  • Codex models: query the installed CLI catalog, offer explicit refresh, preserve saved model choices and show fallback status when discovery fails. A catalog entry or recommendation does not establish account entitlement. When ChatGPT login rejects a model, the conversation and picker provide recovery guidance; RoleWeave does not silently change the model or switch to API billing (#609, #610, #613, #614).
  • Codex prompts on Windows: pass the complete employee prompt and thread context through stdin so command launchers preserve Chinese, multiline and long requests. Input-pipe failures return a typed error (#611, #612).
  • Windows package checks: verify process ancestry against creation times so reused parent process IDs cannot bring unrelated processes into smoke-test cleanup (#615, #616).

Compatibility and upgrade

This remains a pre-1.0 preview. Back up the workspace before upgrading the per-user desktop application. New readers accept older records, and existing workspace identities, history and settings are retained.

Breaking compatibility note for downgrades: relay handoffs and project collaboration add optional GroupMessage.relaySteps, TurnRecord.relayHandoff, TurnRecord.taskBriefing, and GoalWorkItem.participants / dependsOn fields to local records. Older strict readers can reject those records. Keep the 0.6.0 workspace intact if reverting the app; use a copy of a pre-upgrade backup or a separate workspace with v0.5.0. Do not strip stored handoff evidence to simulate compatibility.

Existing local Agent installations, sign-ins and model/service entitlements remain operator-managed. Delivery preflight and approval advice do not replace human delivery acceptance or approval. Laya advice stays disabled unless the existing integration is explicitly enabled.

Downloads and validation

  • macOS Apple Silicon: roleweave-0.6.0-arm64.dmg and roleweave-0.6.0-arm64.zip.
  • Windows x64: roleweave-0.6.0-x64.exe.
  • Intel Mac, Linux and native mobile installers are not included.

The existing distribution channel is unchanged: macOS packages are not Apple Developer ID-signed or notarized, and Windows packages are not Authenticode-signed. The macOS app verifies a separately signed update manifest, downloads updates in the background and replaces the app on normal exit. Windows verifies the installer checksum against the HTTPS feed and requires confirmation. Publication advances both public update feeds.

Existing v0.4.0/v0.5.0 clients can use the normal update flow. Older Windows builds that disable in-app installation need one manual upgrade. Native builds, packaged startup/layout, installer metadata and artifact integrity are checked in CI. User-machine installation, uninstallation, cross-version updates and real provider entitlement require separate product validation.

Publisher handoff

Follow the ByteFolk release process: independent approval of the final preparation head, protected squash merge, exact merged-commit checks, unused-version and main-ancestry checks, and release-tag protection readback. An eligible actor creates one annotated v0.6.0 tag at the recorded commit after those gates pass.

The existing release workflow freezes these notes from that commit, builds both native distributions, signs the macOS update manifest, verifies the draft inventory and publishes last. Stop on a failed gate. Before publication, revert preparation through a reviewed source change if needed. After publication, keep the 0.6.0 workspace intact and use immutable v0.5.0 with a pre-upgrade backup copy or a separate workspace if necessary; correct defects in a new patch version; never replace released assets or move/reuse a tag.