Release v2.61.0

.changelog/v2.61.0.md

@@ -0,0 +1,74 @@
+# Release v2.61.0
+
+Released: 2026-09-09
+
+## Highlights
+
+**Chief of Staff and scheduled work**
+- Scheduled audits can now be organized by labeled lenses, with shared guidance, actionable disabled states, and live maintenance progress.
+- Quota Burn and scheduled maintenance now preserve ordered plans and invoke the same maintenance sequence independently of one another.
+- Agent lifecycle and completion handling now share one consistent path across CLI, TUI, read-only, and claim runs.
+
+**Providers and review operations**
+- Code review configuration now selects supported providers, models, and effort pins from the shared catalog, with a larger-model fallback for oversized reviews.
+- Provider controls, model metadata, and local backend management now use shared ownership and safer readiness rules.
+
+**Communication and federation**
+- Added Beeper as a third communications source, including a desktop bridge and feature-group controls alongside existing messaging integrations.
+- Hosted Eidoverse guest sessions now cap microphone input and re-read live session state before relaying it.
+
+**Creative workspaces**
+- Universe Builder now offers character-sheet casting plus relationship graph views, timeline navigation, gap inspection, and poster export.
+- Writers Room editing is more focused with collapsible sections and stabilized saves, while video asset readiness and repair warnings are now unified.
+
+**Reliability and everyday UI**
+- Backup, restore, update, notification, voice-call, and cron paths now report failures and preserve state more consistently.
+- Responsive layouts, navigation, disabled controls, and mobile headers received focused fixes across the main workspaces.
+
+## Changes
+
+### Chief of Staff, audits, and maintenance
+
+- Added labeled scheduled-audit lenses and shared run guidance, with catalog-derived audit stages and lane tests.
+- Added maintenance sequences that can be launched from scheduled tasks or directly from the Schedule tab, with HTTP-safe identifiers and streamed agent notifications.
+- Added ordered maintenance steps to Quota Burn and preserved maintenance plans across refresh failures and disabled-run states.
+- Hardened autonomous issue filing with shared labels, substantive-review requirements, and issue-count quota guards.
+- Compacted completed agents into a responsive grid and kept claim, read-only, and non-coding runs accurately identified.
+
+### Agent execution and task lifecycle
+
+- Centralized agent completion and status-transition handling across CLI and TUI spawners.
+- Contained scheduled handler loading and execution failures and prevented unrelated skill templates from entering scheduled-task prompts.
+- Exposed safe shared seams for provider controls and aligned launch behavior with the Claude harness.
+- Preserved boundary contracts for task intake, write-task updates, and spawn block-and-bail gates.
+
+### Providers, models, and review
+
+- Added catalog-backed provider and model selection for code review, including effort pins and safe fallback assignments for oversized reviews.
+- Gave local model metadata a shared service owner and unified hosted VideoGen backend predicates and asset readiness.
+- Added a feature-group toggle for related instance features and attributed group changes to the user.
+- Preserved provider control state across refreshes and kept disabled providers from being selected.
+
+### Communications, federation, and voice
+
+- Added Beeper as a desktop-bridge communications source and hardened its integration and feature-group behavior.
+- Preserved Telegram notification coverage and aligned unread badges with authoritative server totals.
+- Kept voice-call openings pending until TTS delivery, decoded misaligned PCM frames, and capped hosted guest microphone input.
+
+### Creative and media workspaces
+
+- Redesigned Universe Builder cast entries as character sheets and added relationship graph, timeline, gaps, and poster-export workflows.
+- Added focused Writers Room controls, collapsible sections, and stable save behavior for narrow and mobile layouts.
+- Centralized pinned video snapshot resolution and unified video repair labels and readiness warnings, including missing metadata.
+- Preserved scene, media-queue, and render-lane accounting through retries, cancellations, and recovery paths.
+
+### Backup, restore, update, and infrastructure
+
+- Made backup schedule defaults resolve consistently and clarified exclusion-rule state without promising unsupported file inclusion.
+- Bound database restores to previewed scope and valid previews, with locked live restore controls.
+- Made self-update launch readiness explicit and preserved exact Git paths in CI test selection.
+- Improved PM2 log line buffering, cron validation, and cross-platform send guards.
+
+## Full Changelog
+
+**Full Diff**: https://github.com/atomantic/PortOS/compare/v2.60.0...v2.61.0

.claude/skills/portos-file-issue/SKILL.md

@@ -9,12 +9,10 @@ description: PortOS conventions for filing GitHub issues and capturing deferred
 
 - **Decide, don't defer — avoid decision-blocked issues (`future` / `needs-input`).** A cluster of open issues that each wait on a human decision is worse than a shipped best-guess the user can iterate on. When you would file a follow-up (or claim one) whose only obstacle is an **undecided design choice** — "option A vs B", "which API shape", "is this in scope" — **make the call yourself**: pick the most reasonable option, state it as *the decision* in the issue body (with a one-line rationale), and file it **ready-to-work**, not parked. The user has explicitly accepted the tradeoff — they would rather iterate on top of a wrong-but-shipped choice than accumulate issues that need decisions. Default to your own recommendation; do not punt the decision back to a human.
   - **Ready-to-work is the default.** Label an issue for its kind (`bug`, `enhancement`, `code-quality`, `plan`) and write a decision-complete body — the problem, the chosen approach, affected files/paths, and acceptance criteria — so another agent can pick it up cold and ship it. `plan` marks the claimable queue that `/do:next --issues` drains.
-  - **Dispatch hints and contributor labels are optional and independent.** When the work you just inspected justifies them, also apply:
-    - `model:light|medium|heavy` — capability (mechanical vs. hard reasoning)
-    - `effort:low|medium|high|xhigh|max` — reasoning budget per step, independent of `model:`
-    - `good first issue` — self-contained, well-specified, a new contributor can ship it without deep repo context. A `model:light` 40-file sweep is **not** a good first issue.
-    - `help wanted` — extra hands welcome and the body is scoped enough to pick up cold.
-  - **Planner attribution (`planner:<model>`) records who WROTE the plan.** It is a third independent axis — the author, not a recommendation about how to run the work. Take the label verbatim from the "Planner Attribution" section of your own run's prompt (PortOS resolves it from the provider/model it dispatched you with); **never guess it from what you believe you are**, and omit the axis entirely when your run was given none. Create it like any other label: `gh label create planner:<model> --color C2185B --description 'Plan authored by the <model> model' 2>/dev/null || true`.
-    Omit an axis rather than guessing. Do not stamp `medium` on both dispatch axes. Do not put `[model:…]` / `[effort:…]` / `[category]` / `[SEVERITY]` in the title. Create each missing label immediately before applying it (`gh label create <name> --color <hex> 2>/dev/null || true`; colors: model:light `D4C5F9`, model:medium `A371F7`, model:heavy `6F42C1`, effort:low `BFE5E5`, effort:medium `76C7C7`, effort:high `1D7874`, effort:xhigh `0E4F4C`, effort:max `05403D`, good first issue `7057FF`, help wanted `008672`). Use repeated `--label` flags. Never relabel a deduplicated existing issue.
+  - **Apply the canonical issue-label contract.** Follow the runtime **Issue Filing Labels** section and take planner identity from **Planner Attribution**. For a standalone run without that section, read the shared contract from the repository root:
+    ```bash
+    node --input-type=module -e "import { MANDATORY_DISPATCH_HINT_GUIDANCE } from './server/lib/dispatchLabels.js'; console.log(MANDATORY_DISPATCH_HINT_GUIDANCE)"
+    ```
+    This is the source of truth for mandatory dispatch axes, contributor-label eligibility, label creation, and read-back verification. Do not maintain a second vocabulary here.
   - **`future` is almost never correct.** Do NOT use it to park a choice you could make yourself. The narrow legitimate park is work a **human must personally drive** — a real fidelity/validation run only they can judge, or a step that needs **specific hardware/credentials** the agent doesn't have (e.g. a CUDA box, an Apple-Silicon-only validation). Mark those `blocked` (skipped by autonomous claim runs), not `future`, and say in the body exactly what human action unblocks it. `blocked` also covers a genuine dependency on another unshipped issue/PR — for that case, name the dependency on its own line as `Blocked by #N` (or `Blocked by #N, #M` for more than one): the `issue-reconcile` scheduled task (`blockedIssueReconcile.js`) parses exactly that line, and removes the label automatically once every named issue is closed. An issue with no `Blocked by` line is never auto-unblocked, so the human/hardware case is unaffected.
   - **`needs-input` is a last resort, not a reflex.** When claiming an ambiguous issue, prefer proceeding on your best interpretation and shipping it. Fall back to `needs-input` only when proceeding would be **destructive/irreversible** or genuinely requires the human (hardware, credentials, a personal judgment call) — never merely because more than one reasonable reading exists.

.gitignore

@@ -1,5 +1,7 @@
 # Dependencies
 node_modules/
+/client/node_modules
+/server/node_modules
 
 # Build output
 dist/

AGENTS.md

@@ -119,7 +119,11 @@ Client- and server-specific conventions live in nested memory files that load wh
 
 `server/lib/navManifest.js` is the single source of truth for navigation: `NAV_COMMANDS` + `resolveNavCommand()`, consumed by both the `⌘K` palette and the voice agent's `ui_navigate` tool. **Adding a `<Route>` without a `NAV_COMMANDS` entry leaves the page unreachable from `⌘K` and un-navigable by voice.** Invoke the `portos-add-page` skill for the entry shape, palette-action wiring, and the fail-fast guards.
 
-**Optional features gate navigation, not routes.** `server/lib/instanceFeatureRegistry.js` declares the optional per-install features (`post`, `datadog`, `jira`) the user toggles in **Settings > Features**; `server/services/instanceFeatures.js` resolves each one as stored override → auto-detection of the integration it fronts → `defaultEnabled`. A nav entry tagged `feature: '<id>'` (or living in a section listed in navManifest's `SECTION_FEATURE` map) drops out of `⌘K` and the sidebar while that feature is off — **the `<Route>` keeps working, so bookmarks, direct links, and voice `ui_navigate` still resolve**. The gate is applied CLIENT-side (`useInstanceFeatures` + `client/src/lib/navFeatures.js`), not by filtering the manifest response: `⌘K` and the voice widget each fetch `/api/palette/manifest` once per session and it is HTTP-cached, so a server-side filter would both defeat that cache and still show hidden pages until a reload. Tag the sidebar row in `client/src/components/Layout.jsx` with the same id; `navManifest.test.js` scrapes both lists and fails when they drift, when a tag names an unregistered feature, or when a `SECTION_FEATURE` key stops matching a live section.
+**Optional features gate navigation, not routes.** `server/lib/instanceFeatureRegistry.js` declares the optional per-install features (`post`, `datadog`, `jira`) the user toggles in **Settings > Features**; `server/services/instanceFeatures.js` resolves each one as stored override → auto-detection of the integration it fronts → `defaultEnabled`. A nav entry tagged `feature: '<id>'` (or living in a section listed in navManifest's `SECTION_FEATURE` map) drops out of `⌘K` and the sidebar while that feature is off — **the `<Route>` keeps working, so bookmarks, direct links, and voice `ui_navigate` still resolve**. The gate is applied CLIENT-side (`useInstanceFeatures` + `client/src/lib/navFeatures.js`), not by filtering the manifest response: `⌘K` and the voice widget each fetch `/api/palette/manifest` once per session and it is HTTP-cached, so a server-side filter would both defeat that cache and still show hidden pages until a reload. A sidebar row still needs its own `NAV_PRESENTATION` entry in `client/src/components/Layout.jsx` (path → icon); `feature`, `section` and `label` are inherited from `NAV_COMMANDS`, so the path is the one thing declared twice — the icon lives only in `NAV_PRESENTATION` — and a manifest tag alone yields no sidebar row — `NAV_PRESENTATION`'s keys are the set the sidebar iterates. `Layout.test.jsx` pins that every Settings, Digital Twin and Messages sub-tab path has a `NAV_PRESENTATION` entry, and that each entry stays presentation-only (an icon, no `to`/`label`/`section`/`feature`) keyed to a live manifest path. `navManifest.test.js` fails when a tag names an unregistered feature, or when a `SECTION_FEATURE` key stops matching a live section.
+
+**Feature groups bucket related features under one toggle, additively.** `INSTANCE_FEATURE_GROUPS` in `server/lib/instanceFeatureRegistry.js` declares the groups (today: `comms`, holding FaceTime Audio, iMessage, Signal, X, Stacker News and Beeper); a feature joins one by carrying `group: '<groupId>'` on its descriptor, which is the whole edit. `resolveOne` in `server/services/instanceFeatures.js` resolves a grouped feature as **its own stored override → the group flag → the detector → `defaultEnabled`**: an explicit per-feature override always wins, and only a feature left on "inherit" answers to its group (group off hides it, group on hands it straight back to its normal resolution). Setting an override back to inherit deletes the stored key rather than writing a third sentinel, so it reads exactly like a feature nobody ever touched. **A group's own `enabled` defaults to `true` when no group state is stored** — that default is the parity guarantee: an install with no `instanceFeatureGroups` in settings resolves every member exactly as it did before the group existed, so registering a group is never a silent hide and needs no settings migration. Malformed group settings fail toward `false`, matching the per-feature override's own posture. An ungrouped feature is completely unaffected.
+
+**A feature toggle that arms background work must reconcile that work at toggle time, not only at boot.** A subsystem gated on "feature on AND credential present" and started once in `services/bootstrap.js` is silently wrong the moment either half of that gate moves at runtime: on a live install, storing a Beeper credential left the realtime transport down and no sweep registered for 48 minutes, until a restart — and the mirror-image gap left a socket relaying on a token a disconnect had just revoked. Give the subsystem one idempotent `reconcile…()` that reads the gate and moves everything to match it, and call it from every path that can move the gate (each credential write, the feature toggle, the group toggle, disconnect). Make repeat calls no-ops rather than re-registrations — re-`schedule()`ing an existing event resets `nextRunAt` a full interval out, so an unrelated toggle would keep pushing the next run away — serialize overlapping calls on one tail, and log transitions only, so an install that has never enabled the feature still narrates nothing. `server/services/beeperArming.js` is the worked example.
 
 ### Slashdo Commands (`lib/slashdo`)
 

client/src/App.jsx

@@ -309,6 +309,7 @@ export default function App() {
           <Route path="cos" element={<Navigate to="/cos/tasks" replace />} />
           <Route path="cos/mind/tools" element={<Navigate to="/cos/mind?panel=tools" replace />} />
           <Route path="cos/tools" element={<Navigate to="/cos/mind?panel=tools" replace />} />
+          <Route path="cos/:tab/:agentId" element={<ChiefOfStaff />} />
           <Route path="cos/:tab" element={<ChiefOfStaff />} />
           <Route path="calendar" element={<Navigate to="/calendar/agenda" replace />} />
           <Route path="calendar/:tab" element={<CalendarPage />} />