v0.9.5

Aelira v0.9.5

Security

• Canvas staff authorization remains bound to the authoritative tenant, account, course, content type, and object throughout launch, navigation, scan, remediation, approval, upload, and write-back paths.
• API-key recovery and management remain tenant-scoped, LMS AI use is policy-bound and purpose-isolated, and release publication remains fail-closed behind signed-tag, protected-denylist, CI, four-receipt, dependency-audit, seven release SBOM assets, and reproducibility gates.

Fixed

• Canvas content identity now includes course and content type; inline image remediation preserves image type; LTI navigation exchanges launch codes once; dashboard review actions and labels reflect persisted state.
• Standalone batches drain all requested work, including the verified 1,000-item boundary, instead of stopping after the first page.

Changed

• Cloud scans, remediations, uploads, syncs, and Canvas reconciliation run through a bounded, fenced, multi-worker durable queue with heartbeats, retries, restart recovery, deduplication, and explicit managed artifacts.
• The deterministic release browser gate covers the staff Canvas course, image remediation, review, write-back, rescan, restart, and artifact journey across five release Chromium tests and the ten-project compatibility matrix.

Operator action required

• Durable-job quarantine: durable-worker activation quarantines every pre-v0.9.5 pending or processing job rather than executing it. Each row becomes terminal failed with exact reason pre_v0_9_5_job_quarantined; its original payload, result, and external-effect evidence remain available for review. Identify all affected rows with: SELECT id, job_type, status, last_error_code, created_at FROM cloud_job_queue WHERE status = 'failed' AND last_error_code = 'pre_v0_9_5_job_quarantined' ORDER BY created_at, id;
• Review each quarantined row and its linked course, file, credential, managed artifact, and external-effect evidence. Do not edit the old row back to pending. After confirming current authorization and intent, deliberately resubmit scans, remediations, uploads, and syncs through the same authenticated dashboard action or API endpoint that initiates new work; retain the failed row as the audit record.
• Preserve every v0.9.4 operator action in CHANGELOG.md, back up PostgreSQL, run alembic upgrade head explicitly, and confirm API and worker health before accepting new work.

Release-candidate evidence

• The open-core candidate integrates the reviewed hardening train through Task24a.
• Website release coordination is current at commit 88d6e717aab852aefd10ca10e8bd49504eeb6d1c: 15 focused tests (13 metadata + 2 dependency-policy), production website and CMS builds, and the generator check using a synthetic immutable v0.9.5 fixture are locally verified; canonical metadata remains v0.9.4 until immutable v0.9.5 exists.
• Publication remains blocked until the signed tag and all protected release workflow gates succeed. This checked-in body is consumed verbatim by .github/workflows/release.yml.