fix: resolve IRIS compilation and installer errors

Add community articles

Migration of administrative areas (Processes, Users and Roles, Tasks, Web Applications, and Security) to the official InterSystems SysAdmin v2 API. Includes a new automated test suite validating read operations and actual mutations via the official API.

What's new

• Public demo ready — least-privilege demo account, daily reset, and a warning before a cancel that makes IRIS raise an alert.
• Semantic step search — the palette finds step types by intent ("check disk space"), not just by name.
• In-process embeddings — the search model runs inside IRIS through Embedded Python (CPU-only, offline, no second service).
• Run log & history — every run records its own log (steps, durations, the platform's failure reasons verbatim); a Runs screen finds past runs; any run exports to a file.
• Report steps — security posture, web application inventory, system alerts and secrets inventory as flow steps, locally or on target servers.
• Scheduled runs that execute — one native task per flow, running as a run-as account whose password is kept in the IRIS Wallet.
• Instance overview API — processes (suspend/resume/terminate), locks, shared memory, activity, devices, licenses and web sessions, as the platform reports them.
• Overview screen — the new landing screen: live cards for each area, detail views, and area reports run from a card.
• Security inventory — certificate-expiry-check (schedule it to be warned before a certificate expires), permissions-inventory and oauth-inventory. Read-only; no secret is ever read.
• Docs — README and known limitations brought up to date.

Databases and namespaces

• Local databases: a three-step Create wizard, a properties editor with the volume files, and delete by typed name, optionally with the files. A new database always needs its own directory.
• Namespaces: create, edit and delete, with what a delete would take with it shown first.
• Global, routine and package mappings, and copying mappings from one namespace to another.
  New screens
• A unified log hub: every log in one list, and one timeline merging them newest first.
• License usage and the full dashboard.
• Web sessions, listed and ended.
• Background tasks: pause, resume and cancel.
• Broadcast a message to terminal sessions.
• Task export and import.
• A user's effective privileges, and Check permission for any user or role.
• The agent audit ledger: each model call, tool call and confirmed write.
• Allowed directories, and Copy as curl beside the try-it console's Send.
  Safety
• Four agent actions start switched off: deleting a local database, deleting a namespace, importing tasks and purging the audit database. Turn them on under Agent co-pilot → Governance policy; the screens themselves still do all four.
• Images in agent replies show as their text description only.
• Routine "not found" answers no longer raise the instance's alert state.
  A refreshed README with new screenshots, and many small fixes.
  Requires InterSystems IRIS or IRIS for Health 2026.2 or later. Upgrading from 1.0.2 keeps your agent definitions, conversations, settings and audit records.

1.2.0: opening an entry of the Messages log now says how often its message was logged and since when, found with IRIS Vector Search, and Show similar entries lists them (nothing is indexed until you ask); in the online demo the index is ready from the start. Dependency updates now arrive monthly and each merged batch is a patch release of its own (1.1.1 was the first). The README links the video walkthrough and names every contest bonus.

1.2.0: opening an entry of the Messages log now says how often its message was logged and since when, found with IRIS Vector Search, and Show similar entries lists them (nothing is indexed until you ask); in the online demo the index is ready from the start. Dependency updates now arrive monthly and each merged batch is a patch release of its own (1.1.1 was the first). The README links the video walkthrough and names every contest bonus.

A regular app, easy to find. On macOS the app now has a Dock icon, so it can't get lost behind the notch any more.

• Clicking the Dock icon, or opening the app again, shows the Profiles window.
• The menu bar has File → Profiles… (Cmd-,) and Quit (Cmd-Q).
• Starting the app a second time on any platform brings up the running app's Profiles window.
• Windows, the Dock and the Windows taskbar show the ValhallISC logo.

Windows installer. ValhallISC-0.9.3-windows-x86_64-setup.exe installs per user without administrator rights. It adds a Start menu entry, an optional desktop icon and an uninstaller in Installed apps. The standalone executables are still available.

Source control. In namespaces under IRIS source control (for example git-source-control or CCR), checked-out classes and routines are marked:

• macOS: Finder tags, green "Checked out" (by you) and orange "Checked out by ";
• Linux: user.xdg.tags attributes (shown by KDE Dolphin), plus _CHECKED_OUT.txt in each folder;
• Windows: _CHECKED_OUT.txt in each folder.

Documents you can't edit are read-only. Check-out, check-in and commit stay in your usual tools; importing a file still goes through the server's source control hooks.

Profiles window, reviewed.

• Mount is the main button, bottom right; it reads Save & Mount when there are unsaved changes.
• The interface says Mount / Unmount / Mounted throughout.
• A mounted profile shows its state and folder in a two-line banner.
• Coloured state dots in the list and in the menu: grey not mounted, amber mounting or unmounting, green mounted.
• If the server can't be reached, a hint suggests the web server's port: IRIS 2023.2 and later have no built-in web server on 52773.
• In the menu bar menu, idle servers read "Name — Mount".
• Clearer dark theme; the locked password field no longer looks editable.

Harbor 1.1.0 adds IPM installation of the production frontend, bundled gateway dependencies and native extension. Node.js 22.12+ remains required; no npm or compiler is needed on the target host. Follow docs/HARBOR_IPM.md for installation, service setup and lifecycle operations.
The launcher requires explicit origin, cookie, instance and external data settings. It rejects relative or package-contained data locations, including symlinks. The extension installer refuses a route owned by another dispatch class or namespace. It creates no native accounts, credentials, grants or sample tasks. Package resources have application-specific names.
Validation: production build and 341 source tests plus two packaging tests. Isolated IRIS 2026.2/IPM 0.10.8 source and archive installations, native login and extension reads, retained records after uninstall/reinstall, conflicting-route refusal, desktop and 390px browser checks passed. External records remained byte-identical. Existing production data and earlier releases are unchanged.
IPM publication is requested through the existing Open Exchange application. Registry availability and bonus awards are separate from local package validation.

Waypoint 1.1.0 adds IPM installation of the production frontend, bundled gateway dependencies and native extension. Node.js 22.12+ remains required; no npm or compiler is needed on the target host. Follow docs/WAYPOINT_IPM.md for installation, service setup and lifecycle operations.
The launcher requires explicit origin, cookie, instance and external data settings. It rejects relative or package-contained data locations, including symlinks. The extension installer refuses a route owned by another dispatch class or namespace. It creates no native accounts, credentials, grants or sample tasks. Package resources have application-specific names.
Validation: production build and 257 source tests plus two packaging tests. Isolated IRIS 2026.2/IPM 0.10.8 source and archive installations, native login and extension reads, retained records after uninstall/reinstall, conflicting-route refusal, desktop and 390px browser checks passed. External records remained byte-identical. Existing production data and earlier releases are unchanged.
IPM publication is requested through the existing Open Exchange application. Registry availability and bonus awards are separate from local package validation.

Initial Release

Access Atlas can now be deployed through IPM with its compiled frontend, bundled gateway dependencies and native telemetry/log extension. Node.js 22.12+ remains a runtime requirement; npm and a build toolchain are not needed on the target host. Follow docs/IPM.md for installation, configuration and startup.
The launcher requires an explicit instance ID and an external campaign directory. Package uninstall preserves that directory. Installation refuses an existing /api/atlas route owned by a different class or namespace. No users, passwords, native grants or sample records are created by the package.
Validation: production build, 302 application tests and two packaging tests; clean Linux CI rebuild reproduces the committed payload. On isolated IRIS 2026.2/IPM 0.10.8: source and archive installs, native login and capture, telemetry/log reads, campaign save and reopening after uninstall/reinstall, route-conflict refusal, desktop and 390px layouts.
Download access-atlas-1.3.0.tgz for IPM archive loading or the ZIP for source/Docker installation. Community registry publication is requested through the existing Open Exchange application; registry availability and any contest bonus await the publishing process. Existing Docker deployments can remain on their current deployment method. Preserve instance ID and data volumes when upgrading.

Run creation now distinguishes 100 unarchived runs from 1,000 total records. Built-in plans and saved procedures explain when archiving can help and when it cannot. Storage limits, existing records and restoration obligations are unchanged.
Validation: production build and 257 tests passed, including refusal without native calls or writes and successful creation below both limits. The production frontend was checked at desktop and 390px widths using synthetic storage and the real creation guard.
Rebuild only the portal service, preserving the configured instance ID and existing run-data volume. No migration is required.

Latest Version

The interactive access example now follows a role reassignment through comparison and a downloadable training report. Removing SupportTeam leaves ReportingReader's read path visible, with an explicit owner follow-up instead of a claim that all access was revoked.

The new Review outcome view compares two supplied synthetic captures using the application’s graph and comparison functions. Add a reviewer note and export the remaining path, capture times and scope limitations. No IRIS connection, native change, live readback or saved campaign is simulated.

Historical technical-review documents now describe only this application's findings and verification.

Validation: production and example builds; 302 automated tests; 17 browser checks; manual 1280px and 390px layouts; downloaded training report checked. Existing connected workflows, storage and API behavior are unchanged.

Adding a campaign duty rule now keeps the entered title and selected roles when the save is refused. Previously the title disappeared before the server confirmed the update. The submitted title clears only after a confirmed save; a later campaign-list refresh failure does not turn that save into a failure.
Pending submissions prevent repeat adds. Standalone duty rules remain local, and campaign ownership, revision checks and refusal recovery are unchanged. No native permissions are changed by saving a review rule.
Rebuild only the portal service, preserving the configured instance ID and campaign volume. No stored-data migration is required.
Validation: production build, 300 tests and ten actual-component browser checks pass. Manual desktop and 390px checks verify refusal, deliberate retry and a saved update followed by list-refresh failure. Synthetic transport only; no native calls or stored records changed.

1.1.1: dependency updates, released automatically when Dependabot's pull requests were merged: @tabler/icons-react 3.48.0 and @tanstack/react-query 5.103.2 in the portal; globals 17.12.0, prettier 3.9.9 and typescript-eslint 8.70.1 in the build tools; a refreshed node:22-alpine image for the Docker build stage. No feature changes; the portal's build (www/) was rebuilt with them.

Task history now shows the existing wall-clock caveat beside the duration summary when its filtered sample includes timestamps without offsets. This makes the limits of median and percentile durations visible without opening each execution.
Native timestamps remain exactly as returned. Duration calculations, filters, schedule interpretation and raw exports are unchanged; Harbor does not infer an instance timezone or compensate for unrecorded clock changes.
Rebuild only the portal service while preserving the configured instance ID and investigation volume. No stored-data migration is required.
Validation: production build and the existing 341 tests pass, along with seven actual TaskCenter browser checks. Desktop and 390px review confirms readable context and its removal when filters exclude the affected records. Synthetic data only; no native or saved records changed.

When Read SQL privileges discovers that the current Atlas session has expired, the workspace now returns to sign-in and removes the previous report and its export control. Previously this session check could leave cached evidence visible after the gateway returned HTTP 401.
Initial signed-out discovery remains quiet. Temporary server errors retain the previous dated capture, and delayed responses from an earlier session cannot end a newer session. No request is automatically retried. Files previously exported are unaffected.
Rebuild only the portal service, preserving the existing configured instance ID and campaign volume. No stored-data migration is required.
Validation: production build, 297 tests and eight actual App browser checks pass. Desktop and 390px checks confirm retained evidence after temporary failure and sign-in with username focus after expiry. Synthetic transport only; no native calls or saved records were changed.

Run comparisons now retain the collection context of both observations. A record present in only one bounded response is labelled Only in before or Only in after, with an explicit warning that this does not prove native creation or deletion.
Comparison JSON preserves recorded request limits and legacy notices. A summary warning remains visible when unchanged sources are hidden. Existing identity matching, field differences, comparison limits and saved run records are unchanged; request limits are not treated as proof of truncation.
Rebuild only the portal service and retain the configured instance ID and run-data volume. No migration is required.
Validation: production build, 255 tests and nine actual-component browser checks pass. Desktop and 390px checks cover shifted windows, legacy limits, unchanged-source filtering and keyboard table scrolling. Synthetic data only; no native calls or existing records were changed.

IRIS Relay 0.4.0

• Similarity search across current and archived logs, ranked with IRIS VECTOR_COSINE and bounded lexical embeddings. No external model or data transfer.
• One-command Docker Compose lab, IPM package for the IRIS components, and a live HTTPS demo with hourly reset and changes restricted to Relay fixtures.
• New 5-step guided tour of a clearly labelled, simulated incident: find related log messages, read the archived rotation (DPI-I-966), capture a task baseline, review and verify a task change, then compare and export a handover.
• The suggested handover note asks the visitor to check the comparison and session activity; it does not claim a skipped or cancelled change was applied.
• Log consistency safeguards include content digests, atomic index refresh with rollback and process locks. Demo upgrades are pinned to a full commit SHA.
• Validated on the dedicated demo VPS: 46 JavaScript tests, 29 Python tests, and all 60 HTTPS visitor checks passed. The IPM components and module version remain 0.4.0.
• 0.4 guided tour (1:34): https://youtu.be/A5OkIV2Q3xA
• 0.3 walkthrough (2:38): https://youtu.be/i_EW6gS3EJg
• Live demo: https://78-17-93-244.sslip.io
• Reviewed code: https://github.com/rafaorlando3/iris-relay/commit/297ff3f3f9a85107d60ad5aab589a5809bb666e8
• Community idea: https://ideas.intersystems.com/ideas/DPI-I-966

Successful inventory and task-history observations now retain the row limit used in the request. The run view, JSON handover and printable report expose that limit so a bounded result is not mistaken for a complete inventory.
The limit is recorded with new successful reads. The run view and printable report identify older observations whose collection limit was not recorded; no historical value is inferred. The evidence payload, assertion paths, native requests and execution authority are unchanged. Logs retain their existing source-specific limits.
Rebuild only the portal service and preserve the configured instance ID and run-data volume. Existing run records remain readable without migration.
Validation: production build, 251 tests and 8 actual-component browser checks pass. Memory-only engine tests verify the exact request parameters, unchanged evidence, legacy validation and failed retries. Desktop and 390px checks verify the current and legacy notices and the generated HTML. No native calls or existing run records were changed.

Certification JSON exports now retain campaign and capture context, source warnings and scope limits. This makes an incomplete report explainable when individual objects already have decisions.
Markdown reports retain original human review dates, follow-up dates and decision capture IDs. They distinguish outdated decisions and preserve unknown-evidence warnings, including when campaign activity is excluded. Saved decisions, coverage calculations and native permissions are unchanged.
Rebuild only the portal service while preserving the configured instance ID and existing campaign volume. No data migration is required.
Validation: production build, 294 tests and 10 actual-component browser checks pass. Manual desktop and 390px checks confirm the generated JSON and Markdown context. Test records are synthetic; no native calls or durable writes were made.

Investigation creation fields now stay unavailable while the submitted request is pending, including when starting from a saved profile. This prevents later edits from disappearing when the saved investigation opens. If the request fails, the submitted values remain available for correction and explicit retry.
Existing uncertainty warnings, profile access checks and saved record formats are unchanged. Rebuild only the portal service, preserving the configured instance ID and existing investigation data volume.
Validation: production build, 341 tests and 12 actual-component browser checks pass. Manual desktop and 390px checks confirm pending controls, retained values after refusal and successful creation. Browser responses are synthetic; no native or durable records were changed.

Open Exchange: "Release app" for 1.1.0

Version: 1.1.0. Tick "Publish in Package Manager" so the IPM registry gets 1.1.0 on approval. The README is
imported from main ("Use GitHub/GitLab README as long description"), so it updates by itself once 1.1.0 is on
main; since 1.1.0 its paragraphs are one line each, so the listing no longer breaks them mid-sentence.

What's new (plain text, fits the box):

1.1.0: suspended tasks show as suspended (IRIS's task list reports every task as active, so each task's state is read on its own, in the Tasks screen and the Health check); every resource save is read back, and the portal says when IRIS answered 200 without keeping it; the whole portal works from the keyboard (tables sort, a skip link, menus that name their current choice); confirmations before suspending the task manager, running a task now or switching auditing off; the Job Center's progress follows every poll; clearer messages for an ended process, a full disk and another origin; the README reads the same on Open Exchange as on GitHub.

An unconfirmed response while creating a campaign or next review period now blocks an immediate repeat. Check saved campaigns refreshes the existing list and clears filters; inspect the saved record before explicitly allowing another creation. No record is treated as an automatic match, and an absent entry does not prove failure.
Entered fields and next-period source review remain intact. A known successful save followed by a failed list refresh remains reported as saved. This change affects creation of review records, not native permissions or stored formats. The guard lasts while the page remains open; after a full reload, inspect saved campaigns before repeating interrupted creation.
Rebuild only the portal service while preserving the configured instance ID and existing campaign volume. Validation: build and 292 tests pass, plus 19 actual-component browser checks. Manual desktop and 390px checks covered retained fields, source confirmation, history failures, filter reset and explicit acknowledgement. Synthetic fixtures performed no native or durable writes.

When the response to creating a run from a saved procedure is lost or unreadable, Waypoint now marks the outcome unconfirmed and blocks an immediate duplicate attempt. Check recent saved runs, open the relevant record and inspect its procedure version before deciding whether to create another plan. An empty list is not proof that creation failed.
Definite refusals remain retryable. Creating a plan does not execute any step. Existing run formats, procedure versions and native permissions are unchanged. Rebuild only the portal service while preserving its configured instance ID and existing data volume.
Validation: build and 247 tests pass, plus 18 actual-component browser checks. Desktop and 390px manual checks covered lost responses, recovery reads, inline history failures, explicit acknowledgement and saved procedure identity. Synthetic fixtures made no native or durable writes. The guard lasts while the page remains open; after a full reload, inspect Runbooks before repeating an interrupted creation.

Certification carry-forward now previews which saved decisions are eligible and why others are omitted before recording the action. The preview identifies the source and current captures; paginated rows keep larger scopes readable. The action names the number of decisions it will carry.
The preview and save use the same eligibility rules. The original human review dates remain unchanged; carrying a decision is not a new approval. Native permissions, saved formats and revision protection are unchanged.
Rebuild only the portal service while preserving the configured instance ID and existing data volume. Validation: build and 292 tests pass, plus 17 actual-component browser checks. Desktop and 390px review covered eligible/skipped reasons, refused saves, successful carry, pagination and incomplete evidence. Synthetic fixtures performed no native or durable writes.

Printable handovers identify the observation behind each procedure assertion by step number, title and identifier, with its source and target. This makes a failed or unknown check traceable when several observation steps share a title. Missing references are reported explicitly rather than inferred from names.
Recorded outcomes, procedure versions and saved runs are unchanged. The report does not rerun checks. Rebuild only the portal service, preserving the configured instance ID and existing data volumes. No native class or stored-data migration is required.
Validation: production build and 247 tests pass, including eight report tests for exact references, pending and unknown checks, missing sources, escaping and legacy output. Manual desktop and 390px inspection of the generated report confirms the referenced step and target are readable without page overflow. Synthetic data only; no native or durable writes.

Evidence review fields are temporarily disabled while their save is pending. Previously, text entered during that interval could disappear when the saved decision or conclusion returned. A failed save keeps the submitted draft and restores editing.
Capture-pair ownership, difference identities, stored records and native operations are unchanged. Rebuild only the portal service, preserving the configured instance ID and existing data volumes. No native class or stored-data migration is required.
Validation: production build and 341 tests pass, plus 16 actual-component browser checks covering pending fields, successful saves, failed-save draft retention and capture-pair separation. Test records and transport are synthetic; no native or saved records were changed.
Manual desktop and 390px checks confirm the retained drafts and normal recovery of editing after a refusal, without page overflow.