Postmaster v9.4.4: WebGUI-only task correction

CHANGELOG.md

@@ -2,6 +2,25 @@
 
 Postmaster MCP follows Semantic Versioning for stable releases. Every stable release should update `VERSION`, this changelog, and publish an immutable Git tag/release named `vX.Y.Z`.
 
+## 9.4.4 - 2026-08-20
+
+### Fixed
+- Restored the public task MCP/API contract to v9.4.2 compatibility. `list_jobs(owner_id=None, project_id=None, status=None, limit=200)` again has no `include_completed` parameter, includes `status=completed` records by default, and uses the pre-v9.4.3 MCP serialization without the `{ok, count, jobs}` wrapper.
+- Restored `SchedulerEngine.list_jobs` to the v9.4.2 signature and semantics. Completed-task visibility is no longer a scheduler/backend default and explicit owner/project/status filters behave as they did in v9.4.2.
+- Removed the duplicate runtime `get_job` registration that could log `Tool already exists: get_job`. The original read-only `get_job(job_id)` tool from v9.4.2 remains the single canonical registration.
+- Removed the v9.4.3 `build_status.task_detail_view` and `build_status.completed_tasks_hidden_by_default` capability flags, because completed visibility/detail is now strictly a WebGUI presentation concern.
+
+### Added
+- WebGUI-only Tasks filtering: completed tasks remain in the database and MCP results, but the Tasks page hides them by default and offers `Show completed (N)` / `Hide completed` controls.
+- A `View` action for every displayed task and a read-only task-detail panel showing id, owner/project, title/description, action type, execution profile, schedule, timezone, approval mode, status, timestamps, last error and safely rendered payload.
+- Dashboard-local `show_completed=1` and `view_job=<id>` navigation that preserves the Tasks tab. A completed task can be opened directly by ID even while completed rows remain hidden from the default list.
+- Regression coverage for the v9.4.2 MCP schema/output contract, completed visibility in MCP versus WebGUI, single `get_job` registration, safe detail rendering, counts, Pause/Resume, scheduler status, due jobs, completion and recurring advancement.
+
+### Compatibility / deployment
+- `create_job`, `update_job`, `pause_job`, `resume_job`, `complete_job`, `delete_job`, `get_job_history`, `list_due_jobs`, `scheduler_status`, recurrence advancement, approval/security and persistent task storage are unchanged.
+- No scheduler/database migration, environment variable, port, volume or Cloudflare rule is introduced.
+- `postmaster-mcp.yml` remains byte-for-byte unchanged. Existing `POSTMASTER_VERSION=latest` deployments with update checks enabled can select v9.4.4 with the normal restart/redeploy after the stable release is published.
+
 ## 9.4.3 - 2026-08-20
 
 ### Added
@@ -159,4 +178,4 @@ Postmaster MCP follows Semantic Versioning for stable releases. Every stable rel
 - CI coverage for runtime import, bootstrap, model provisioning, MIME regressions and knowledge operations.
 
 ### Changed
-- Public project naming and configuration became provider-agnostic.
+- Public project naming and configuration became provider-agnostic.

README.md

@@ -44,7 +44,7 @@ The important v9 changes are:
 - improved MIME parsing for forwarded mail and HTML-heavy messages;
 - CI coverage for the bootstrap, MIME parser, knowledge store and semantic-model provisioning;
 - persistent small-file storage plus native ChatGPT file inputs in v9.2;
-- task list/detail UX with completed tasks hidden by default and explicit retrieval in v9.4.3;
+- WebGUI-only task list/detail UX in v9.4.4, while the public task MCP/API contract is restored to v9.4.2 compatibility;
 - semantic release history through `VERSION`, `CHANGELOG.md` and immutable `vX.Y.Z` release tags.
 
 ---
@@ -450,18 +450,18 @@ Review Junk and restore genuine false positives.
 Check unread mail and summarize messages requiring attention.
 ```
 
-From v9.4.3 the task read UX mirrors the Memory/Skill list/detail pattern. Completed tasks remain stored with the persistent status `completed`, but they are hidden from the normal list unless the caller asks for them explicitly:
+v9.4.4 deliberately restores the public task MCP/API behavior to the v9.4.2 contract:
 
 ```text
-list_jobs()                         -> non-completed tasks only
-list_jobs(include_completed=true)   -> non-completed + completed tasks
-list_jobs(status="completed")       -> completed tasks explicitly
-get_job(job_id)                     -> complete record for one task
+list_jobs(owner_id=None, project_id=None, status=None, limit=200)
+get_job(job_id)
 ```
 
-`list_jobs` returns one structured MCP result with `{ok, count, jobs}`. The individual job objects keep their existing fields for compatibility, while `get_job` is the full detail view with owner/project, description, action type, execution profile, schedule, approval mode, status, timestamps, last error and payload. Owner/project/status filters still combine normally, and the result `limit` is applied after completed tasks are excluded.
+There is no `include_completed` parameter. `list_jobs()` includes completed tasks by default, an explicit `status="completed"` filter still selects completed records, and the MCP output uses the same pre-v9.4.3 serialization rather than a `{ok, count, jobs}` wrapper. `get_job` is not new in v9.4.4; it is the original read-only v9.4.2 task lookup and is registered only once.
 
-Hiding a completed task is presentation only: no record is renamed to `done`, archived, deleted or migrated. `scheduler_status` still counts completed tasks, and `get_job` can read a completed task directly by ID. The server persists the task state; the AI client performs the reasoning and explicit action.
+The completed-task UX now exists **only in the WebGUI**. On the Tasks page, rows with the persistent status `completed` are hidden by default, `Show completed (N)` reveals them, and `Hide completed` returns to the default view. Each displayed task has a `View` action, and the detail view shows the complete stored task record including owner/project, description, action type, execution profile, schedule, approval mode, status, timestamps, last error and safely rendered payload. A completed task can be opened directly with the dashboard-local `view_job=<id>` query even while completed rows are hidden from the list.
+
+Hiding a completed task is presentation only: no record is renamed to `done`, archived, deleted or migrated. `scheduler_status` still counts completed tasks, MCP callers still receive them from the default `list_jobs()`, and the server remains a passive task registry; the AI client performs the reasoning and explicit action.
 
 ---
 

VERSION

@@ -1 +1 @@
-9.4.3
+9.4.4