0.6.0 - Winter is Coming

New Features

• Case Relationships: the Case detail page now has a Related Cases tab supporting three weak-association types (Related, Duplicate of, Parent of) with notes of up to 500 characters, plus relationship suggestions. Relationships are weak associations and do not affect Dashboard metrics, case counts, routing, or the case lifecycle. Creating, updating, and deleting relationships is written to the audit log, and the Agent API exposes relationship read/write endpoints.
• Custom Variables: the Custom Definitions page now has a Variables tab for managed variables of six types (string, integer, float, boolean, list, dictionary) with enable/disable switches. Secret variables are limited to String, their values are never returned by the API, and clearing the secret flag requires confirmation. Custom Modules and Playbooks read enabled variables through self.get_variable("KEY"). List and dictionary values are edited in a CodeMirror JSON editor.
• Worker Health: the five background workers (Agentic Module, Case Analysis, Playbook, ELK Action, Dashboard Cache) write a heartbeat to Redis every 10 seconds and are considered stale after 30 seconds. The Settings → Workers page (Admin) shows the state of each worker, and the API returns 503 when Redis is unavailable.
• Playbook execution visibility: Playbooks record started_at and finished_at, and the list shows run duration. The run detail now includes a message stream with structured execution messages, and an interruption remark is written automatically when a worker exits before completion.

Improvements

• Playbook run messages are sanitized before storage: Authorization headers and password, token, api_key, and secret assignments are replaced with ***, and each message is truncated to 1000 characters.
• Refined the case relationship experience, including list interactions, suggestions, and relationship constraint validation; self-relationships are rejected and only one relationship is kept per case pair.
• Frontend data tables now fill the available container height, removing extra whitespace and scrolling.
• Updated backend dependencies (uv.lock).
• Added frontend dependencies @uiw/react-codemirror and @codemirror/lang-json for editing custom variable JSON values.

Fixes

• Fixed wide tables not filling the available page height.

Deployment and Release Engineering

• Reworked the Compose lifecycle scripts: init.sh for initialization, doctor.sh for health checks, backup.sh for backups, restore.sh for restores, and upgrade.sh for managed upgrades; rewrote both READMEs.
• Managed upgrades: run ./scripts/upgrade.sh inside the extracted new release package. It reads the target image tags from .env.example, updates .env, pulls images, runs migrations, starts services, and checks the deployment.
• Documented every setting in .env.example and added ASP_DOCTOR_WAIT_SECONDS (maximum time doctor.sh waits for services) and DJANGO_LOG_LEVEL_DJANGO (Django framework log level).
• Release consistency checks now cover the CLI version, Compose image tags, quick-start generated blocks, release notes pages, and VitePress navigation; CI validates the release package so development samples never enter the custom template; release packages preserve script executable permissions.
• The Compose package and quick-start documentation default to the 0.6.0 image tags.

Upgrade Notes

Upgrading directly from 0.5.2 to 0.6.0 is supported. Direct upgrades from earlier versions are not supported, and no database downgrade is offered; rollback relies on a backup taken before the upgrade.

Back up first:

./scripts/backup.sh

Extract the 0.6.0 release package over your existing deployment directory, then run the upgrade:

cd asp-compose
./scripts/upgrade.sh

upgrade.sh updates the .env image tags, pulls images, applies migrations, starts the services, and checks the deployment. This release contains 4 database migrations: the Case Relationship table, the Playbook start/finish time fields, the Custom Variable table, and the variable type fields. All are additive and run against existing data.

If you maintain a custom Compose file, merge the new settings from .env.example.

To use the CLI, install it with pipx:

pipx install asp-cli==0.6.0

If asp-cli is already installed, upgrade to the latest version:

pipx upgrade asp-cli

You can also force a specific version:

pipx install asp-cli==0.6.0 --force

The deployment boundary is unchanged: single-host Docker Compose is the only officially supported topology, and each background worker officially supports a single instance; duplicate instances overwrite each other's Worker Health state.

Developer Notes

• Case relationships build a pair_key from the sorted case id pair, which is unique; self-relationships are rejected and only one relationship exists per pair, while direction is still expressed by source/target.
• Playbook run status updates use suppress_audit to avoid audit noise, and high-frequency health telemetry such as worker heartbeats never writes AuditLog.
• Custom variables are read through apps.settings.custom_variables.get_custom_variable, which only returns enabled variables; secret values never appear in API responses.
• Worker heartbeats are written to the Redis hash worker-health:v1:{worker_type}, and health state aggregation lives in apps.common.worker_health without touching the database.