[v0.0.2] - 2026-09-28

Fixed

• Quick Start fails on Windows (Issue #1) — the production compose file now maps host port 8080 to container port 80 instead of 80:80.
  • On Windows machines where port 80 is reserved at the kernel level by IIS / the http.sys driver (IIS's default site registers the full-port reservation http://+:80/), the Docker daemon (a user process) cannot bind port 80 and docker compose up failed with:
    listen tcp 0.0.0.0:80: bind: An attempt was made to access a socket in a way forbidden by its access permissions (WSA_EACCES / 10013).
  • 8080 is not an IIS/http.sys default, so the one-command run now works out of the box on every machine. The app inside the container is unchanged.
  • READMEs (EN + ZH) updated: Quick Start now opens http://localhost:8080/, with a note on how to use host port 80 instead (change the mapping to 80:80 and free port 80 first, e.g. stop IIS).
  • Root cause confirmed 1:1 by controlled experiment: with an HttpListener holding http://+:80/ (the http.sys kernel driver — the same mechanism IIS uses), docker run -p 80:80 fails with the identical error; a plain user-process socket holding 80 does not block Docker (SO_REUSEADDR coexistence), and the Windows firewall has no effect.

Restrain the agent your way

• Switch off individual agent writes without switching off the agent.
• A read-only toggle for your own session.
• Per-person turn limits, with a banner that says when you can send again. There is no limit until an administrator sets one.
• Ask the agent for the script instead of the change, and take it into your own change process.
• Conversations are kept, cleared on a retention schedule, and open to administrators.
• Content the agent reads is defanged before it reaches the model, and a seeded-injection test proves a log line cannot steer it.
  New screens
• A try-it console for any REST application's OpenAPI document.
• Six more logs: System Monitor, background task errors, xDBC errors, SQL diagnostics, the interoperability event log and the analytics log.
• Older messages.log files, from the portal (Community Idea DPI-I-966).
• Security and operations findings on Home, each with a fix you review and confirm.
• A Guardrails page: what the agent may never do, and what needs your confirmation.
  Conveniences
• After every write, the screen confirms the instance now holds the new value.
• Removals say what else depends on the item before you confirm.
• The instance's performance at a glance on Home.
• Any table downloads as CSV.
• Many small fixes.
  Requires InterSystems IRIS or IRIS for Health 2026.2 or later. Upgrading from 1.0.1 keeps your agent definitions, conversations and audit records.

Release of Aperture for the InterSystems contest entry.

Changelog — spec 010: Canvas onboarding and flow management usability

Branch feat/spec010 (uncommitted). Frontend only; nothing changed under src/ or in openapi.yaml.

Added

Flow management (US1, US2)

• Save as…: creates a new flow from the current canvas, including unsaved edits, under a new name. The original keeps its name, revision and contents. The address switches to the new flow, and Back returns to the original. If the name is taken, the dialog shows the platform's reason word for word and stays open.
• New flow: starts an empty canvas with a unique default name (Untitled flow YYYY-MM-DD HH:MM:SS, with (2), (3)… added on a clash) and removes the flow from the address.
• Rename notice: editing a saved flow's name shows "Renames this flow — use Save as… to keep a copy".
• Conflict hint: when Save flow hits a revision conflict, the platform's message is followed by "Use Save as… to keep your version."
• Unsaved-changes dialog (Save / Discard / Cancel): a single dialog guards New flow, Open flow…, Open example flow, and back/forward or links that change the open flow. A refused save keeps it open with the platform's reason.
• Open flow…: lists every saved flow with its name, revision and last-saved time, newest first. It has a case-insensitive name filter and marks the open flow. The list is read fresh on every opening. With 5,000 flows it opens in about 80 ms and filters in about 70 ms.
• Flow that can't be opened: if the address names a flow that can't be read, the canvas now opens with the platform's reason and offers Open flow… and New flow, instead of a blank error page.

Sign-in across reloads (US3)

• Reload keeps the sign-in: the page returns to the same screen, flow and live run from the address, and the sign-in form never flashes during the reload.
• What is stored: only the refresh token plus a small "in use" flag, kept in the tab's own storage (sessionStorage). No password, access token, user name, role or permission is stored.
• Duplicated tab: it never reuses the copied token and asks for its own sign-in. Reusing it would make the platform sign the original tab out.
• Session ended: when the kept sign-in can't be renewed (expired after 15 minutes, revoked, IRIS restarted or unreachable), the sign-in form says "Your session ended — sign in again." After signing in, it returns to the place in the address.
• What ends it: sign-out, a rejected request, a failed renewal, or closing the tab.

Example flow (US4)

• "Example: storage health check": two read-only steps that run in parallel. Storage headroom check runs with minFreePercent: 10; Database size report has no parameters. It validates with 0 errors and completes in about 1.7 s, with no destructive confirmation.
• Where it's offered: on the empty canvas of an instance with no flows (next to Start from scratch), in Open flow… when the list is empty, and in the getting-started guide.
• Never duplicated: the example is identified by its name. If it already exists it opens; if creating it clashes on the name, the list is read again and the existing one opens.
• When it's hidden: if any step type it needs is missing, unavailable or destructive, or if the flow list can't be read.

Getting-started guide (US5)

• Six-step dialog: Welcome, Open the example, Build a flow, Validate and run, Save/Save as/Open, and Schedule and explore. It has Back/Next, "Step n of 6", and Close on every step.
• "Don't show this again": remembered per browser. If the browser blocks storage, the guide still works and simply appears again at the next sign-in.
• When it opens by itself: only after a sign-in typed with the password, not after a reload, and once per visit.
• Help → Getting started: on every screen.
• Accessible: a modal dialog announced with its title, fully keyboard-operable. Tab stays inside, Escape closes it, and focus returns to where it was.

Changed

• Top bar layout, so everything fits at 1440 px:
  • Open flow… is a visible button.
  • New flow and Save as… moved into a More ▾ menu.
  • The %SYS label and the revision/saved-time line sit under the flow name.
• Shared building blocks: Modal.svelte (the dialog frame, with focus handling and Escape), MenuButton.svelte (keyboard-accessible menu button) and dialog.css (shared dialog look, theme tokens only).

Fixed

• Focus leaving dialogs: Tab could leave the dialog for the browser's own toolbar; it now wraps inside the dialog.
• Guide preference lost on sign-out: signing out after a reload could erase the stored "Don't show this again" choice.
• Example step under the legend: the example's first step was placed under the canvas edge legend and couldn't be clicked.

Tests

• Unit tests: 89 → 145.
• End-to-end: 5 new spec files, us17–us21. The full suite has 64 passed, 1 skipped (the opt-in 900 s expiry test, which passed on its own), 0 failed.
• Existing tests updated on purpose:
  • us7-catalog: a reload and a same-tab navigation no longer need a new sign-in.
  • us15-targets: the "no credential left in the browser" check now targets target credentials specifically, allowing only the tab's own kept refresh token. It also registers iris-target itself, so it no longer depends on test order.
• Test helpers:
  • signIn can pre-dismiss the guide.
  • deleteFlowWithRuns deletes a flow and its runs. It refuses to run unless on the local dev instance, in the IRISAPP namespace, and on a flow whose exact name has a known test prefix.

Docs

• docs/limitations.md: new entries on sign-in across reloads (including that a browser crash requires signing in again) and on the example flow (its 10% free-space threshold).
• Spec 010 docs: the quickstart has a free-space check before the example run; evidence/ holds the test records, performance numbers and the Constitution review.

Environment notes

• Dev-only setting: ^sentai("config","allowInsecureTargets")=1 was set by hand on the dev instance. The running iris image predates the iris.script line that sets it, so it disappears if the container is recreated from this image.
• Test data: 134 of this feature's test flows (plus probe flow 5126) were deleted from the dev instance.

Initial Release

Initial Release

Initial Release

Initial Release

Initial Release

Initial Release

Highlights

• A visual canvas, served by IRIS itself. You compose flows, validate them, dispatch them and
  watch them live in the browser at /csp/sentai/. There is no separate web server.
• Declared step types. New maintenance steps run inside the platform, on a Work Queue Manager
  worker, with the dispatching operator's own authority. Four new types are available:
  storage-headroom-check (Embedded Python), db-size-report, switch-journal and
  purge-task-history.
• Task catalog. A catalog of the platform's Task Manager reports exactly what the platform
  reports, with a screen to browse, filter, suspend and resume tasks.
• Distributed targets (InterSystems Ideas DPI-I-588, "Distributed Work Manager"). A step can
  run on another IRIS instance. The run tracks it and keeps its result on the primary instance.
• Runs that outlive the 60-second token. A dispatched run renews its own credential until it
  ends.

Added

Canvas (spec 002)

• Flow composition. You drag step types from the palette, connect steps with edges (a cycle is
  refused as you draw), and see several incoming edges meet at one fan-in junction.
• Inspector, validation and scheduling. Errors and warnings appear on each node and in the
  status bar. Errors block running; warnings don't.
• Live-run screen. You can dispatch a flow, watch each step's state and control the run: cancel
  the run, cancel or pause a step, or re-run a failed step.
• Light and dark themes built from a single design-token source. Both themes render the same
  screens.
• The static SvelteKit build is baked into the image at /opt/sentai-web and served by
  sentai.web.StaticFiles.

Declared step types (spec 005)

• Each entry of the closed step-type catalog now declares label, executor
  (platform-api | in-process) and a parameters schema.
• In-process executor. The step's class is resolved only from the catalog, by the step's
  type. Properties are set by iterating the declared schema, never from the keys of the step's
  JSON. The task runs in its own namespace frame, so a task that switches to %SYS cannot leak
  that switch.
• New step types:
  • storage-headroom-check: read-only. It fails when a database directory or the journal
    directory has less free disk space than minFreePercent (0–100, default 10), and names
    each location with its free percentage. It is written in Embedded Python
    (shutil.disk_usage).
  • db-size-report: read-only. result.databases lists every database with sizeMB and
    freeMB.
  • switch-journal and purge-task-history (keepDays, integer ≥ 0, default 30) now run
    in-process instead of calling management-API endpoints that don't exist.
• Parameter validation on validate, dispatch and schedule. The new codes are PARAM_REQUIRED,
  PARAM_TYPE_MISMATCH, PARAM_OUT_OF_RANGE and PARAM_UNKNOWN. Each finding carries a
  structured parameter field.
• A declared type whose class is not installed on the instance is refused with
  STEP_TYPE_NOT_SUPPORTED_ON_TARGET.
• Run reads (GET /runs/{guid} → steps[]) show executedAs (who ran the step) and result
  (the step's JSON report, at most 8000 characters; larger reports are truncated and marked
  "truncated": true).
• In-process step timeouts. timeoutMinutes defaults to 60 when set to 0 and counts from
  running, so it includes the time spent waiting for a worker. Terminal transitions are locked,
  so exactly one writer wins.

Task catalog (specs 006 and 007)

• GET /catalog/tasks and GET /catalog/tasks/{id} return the platform's own values: class,
  runAsUser, timePeriod, nextRun, lastStarted, lastFinished, status, lastError,
  suspended, and history on the item read.
• destructive and destructiveUnknown are derived from the step-type catalog.
• origin links a task created by SentaiTask back to its flow and step.
• A task that can't be read shows up with unavailable entries and the platform's reason.
• POST /catalog/tasks/{id}/suspend suspends or resumes a task through the platform's real
  endpoints, then re-reads it.
• New errors: 400 INVALID_FILTER, 502 SUSPEND_NOT_APPLIED, 502 PLATFORM_UNREACHABLE.
• New Task catalog screen, reached from the top bar and addressable at
  ?view=catalog&task=<id>. It offers filters, sorting, a detail view with an origin link, and
  suspend/resume.
• Typed confirmation per destructive step in the Run now dialog.
• Declared step types in the canvas. The palette has a Custom group, and the inspector shows a
  generated parameter form with required marks, bounds, defaults and descriptions. Findings are
  routed to their field by parameter. A legacy custom step shows its class read-only.

Distributed targets (specs 008 and 009)

• Target registry:
  • GET/POST /targets
  • GET/PUT/DELETE /targets/{name}
  • POST /targets/{name}/online
  • POST /targets/{name}/sign-in (keeps nothing)
  • GET /targets/{name}/status (the target's token travels in
    X-Sentai-Target-Authorization)
• A step may name a target. Platform-executed types (in v1: integrity-check) start, poll,
  pause and cancel their job on that instance, with the operator's own credential for it.
• Step types expose a derived remoteCapable field.
• Dispatch accepts targetCredentials. It redeems one credential per target the flow uses and
  checks that each belongs to the same user before a run exists. The run renews each credential
  and erases it when the run ends.
• Run reads show executedOn (local or the target's name). Platform steps now keep their
  result, whether local or remote.
• New validation and refusal codes:
  • TARGET_NOT_FOUND, TARGET_OFFLINE, TARGET_UNREACHABLE, TARGET_REFUSED
  • TARGET_NOT_VERIFIED (a warning when /validate has no credential for the target)
  • TARGET_CREDENTIAL_MISSING, TARGET_CREDENTIAL_USER_MISMATCH
  • STEP_TYPE_NOT_REMOTE_CAPABLE, INVALID_TARGET, TARGET_EXISTS
  • CONTROL_REFUSED (502 when a target refuses a cancel or pause)
• A target that goes down mid-run fails only its own step, after that step's timeout. A target
  that doesn't answer is backed off for 30 s, so it can't hold the rest of the run.
• New Targets screen (?view=targets) to list, add, edit and delete targets, switch them
  online or offline, and read their live state.
• The inspector gains Run on, a node on a target shows a badge, Run now asks for one password
  per target, and the live run shows executedOn.
• The demo compose stack adds a second IRIS instance, iris-target.

Run credential (E-1)

• POST /flows/{id}/dispatch accepts runCredential.refreshToken, the refresh token of a
  sign-in dedicated to the run. The run loop is the only process that renews it, and the
  credential is erased when the run ends.
• The canvas signs in separately at Run now and sends this token. Runs such as the demo wave
  (3 checks → join → 2 in sequence) now complete past 60 s.

Changed

• Available step types are now integrity-check, switch-journal,
  storage-headroom-check, db-size-report and purge-task-history. Before, only
  integrity-check was available. The refusal message lists the available types instead of a
  hard-coded one.
• /schedule creates native tasks through the platform (POST /api/admin/v2/task) with the
  operator's token. A refusal is returned verbatim, and tasks already created by the same request
  are rolled back.
• One identity per run:
  • /dispatch redeems the runCredential before creating the run and refuses a credential that
    belongs to another user: 403 RUN_CREDENTIAL_USER_MISMATCH.
  • Only the user who dispatched a run may re-run its steps: 403 RERUN_NOT_BY_DISPATCHER.
  • In-process steps can't be scheduled (IN_PROCESS_NOT_SCHEDULABLE), because a scheduled run
    has no operator.
• purge-task-history is no longer pausable, since there is no pause for in-process work.
• purge-audit-records declares daysToKeep (required, integer ≥ 1) for the canvas. Its class
  was corrected to the platform's %SYS.Task.PurgeAudit; the type is still unavailable.
• In the palette, types the platform doesn't support in v1 stay listed, disabled, as "not
  supported in v1". Saved flows that use them still load.

Breaking changes

• GET /catalog/tasks: the invented fields className and state were removed. Use class
  and status / lastError / lastStarted / lastFinished instead. isDestructive and
  lastRun remain as deprecated aliases of destructive and lastFinished.
• /dispatch with a runCredential of a different user now returns 403 instead of starting a
  run under two identities.
• /rerun by anyone other than the run's dispatcher now returns 403.
• The canvas URL is /csp/sentai/.

Fixed

• A step whose status check gets a 4xx (for example 401 after the token expired) now fails, with
  the HTTP status recorded, instead of being polled forever. 5xx and network errors are still
  retried.
• A cancelled run finalizes as cancelled, not completed. failed outranks cancelled, which
  outranks completed.
• /dispatch validates the flow with the freshly redeemed access token. Redeeming the run
  credential revokes the canvas's bearer token, which used to turn every step into
  CATEGORY_NOT_FOUND.
• A local job is polled with the run credential renewed at poll time, so a slow loop pass can't
  let the credential expire under a running step.
• Container startup. The runtime working directory moved off the bind mount, which fixes the
  iris-main.log boot loop.
• Test isolation. The backend suite no longer starts real background jobs and removes the runs
  it creates. About 1400 stuck running runs left on the dev instance by earlier suites were
  purged.

Security

• Nothing an operator types selects code. The class a step runs comes from the closed catalog
  only. A legacy custom step's customClass is never read on any execution path, which a test
  enforces. There is no Xecute.
• Declared steps run with the dispatching operator's own IRIS roles. The platform decides at use
  time, and its refusal is returned verbatim.
• The canvas page is public static content; the API keeps password + JWT authentication. The
  anonymous file server lives alone in a small SENTAIWEB database (resource %DB_SENTAIWEB,
  public read). IRISAPP_CODE and IRISAPP_DATA keep no public access, and the file server
  refuses any path outside /opt/sentai-web and sends nosniff and X-Frame-Options headers.
• Targets must use https:// with peer verification (TLS configuration SentaiTargets). Plain
  http is accepted only for loopback targets or when ^sentai("config","allowInsecureTargets")
  is set. The demo image sets that flag for its compose network; remove it in any real
  deployment.
• Target credentials live in IRISTEMP (never journaled, lost on restart) and are erased when
  the run ends. Target sign-in stores nothing.

Deployment

• The Docker image now builds the frontend in a Node stage. Only the static output ships in the
  IRIS image.
• iris.script creates:
  • the SENTAIWEB database, its resource, and the mapping of the sentai.web package to it
  • the SentaiWebPage role
  • the SentaiTargets TLS client configuration
• docker-compose.yml adds the iris-target service (demo only) and sets the runtime
  working_dir.

Known limitations

The full list is in docs/limitations.md. The most relevant:

• Scheduled runs still can't authenticate to the platform. Use manual dispatch.
• A dispatch without runCredential (for example plain curl) is limited by the 60 s access
  token.
• Operators who validate flows need %Admin_Manage:USE and read access on IRISSYS, because
  validation reads the WQM categories with the operator's token. With those rights, IRIS 2026.2
  also lets the operator purge task history. It refuses the journal switch without
  %Admin_Operate:USE.
• Only integrity-check can run on a target. Declared in-process types are refused with
  STEP_TYPE_NOT_REMOTE_CAPABLE.
• Cancelling a running platform job makes IRIS log ERROR #7802 at severity 2, which puts the
  container in the unhealthy state. So do the backend suite's deliberate unknown-category
  tests. Clear it with do $SYSTEM.Monitor.Clear() in %SYS.
• compact-globals, defragment-globals, purge-audit-records and legacy custom remain
  unavailable.

Tests

• The backend %UnitTest suite grew from 115 to 269 methods. It runs against a test double of
  the management API and leaves no runs behind.
• The frontend has unit tests (Vitest) and Playwright acceptance tests against the deployed
  container.

Contributors

Henrique Dias, Henry Hamon, José R. Pereira Jr.

IRIS Ops Studio 1.3.1 — bounded one-hour guard session and jury route
The optional HTTPS managed guard now has a fixed maximum one-hour navigation session. Bounded native access can renew read-only while a tab is visible and idle; it cannot extend the family deadline or repeat a write. Per-workflow write approval remains limited to 60 seconds and exact-target previews to 30 seconds. Guard navigation shows only its supported Wallet, Web apps, Access control and local Session journal views. The full direct SysAdmin console remains a separate installation and URL.
The README and docs/JURY-EVALUATION.md distinguish three evaluation routes: labeled Safe demo, full direct console, and optional managed guard. The GitHub v1.3.1 release includes the separate review ZIP, judge guide and SHA-256 748A1B361198AA6AEA850E6AA32CB538724C9A47C21C25D0364E662571B655DE. Historical v1.3.0 remains available.
Verification and limits: 270 JavaScript tests and 12 syntax checks pass; the exact ZIP passed independent extraction and verification. Eighteen native renewal checks ran on disposable IRIS Community 2026.2. One real browser session reached the one-hour boundary on the preceding local bundle; the exact new ZIP was not reinstalled for another live-IRIS pass, and the separate scripted long-duration test remains unrun. The optional guard reports productionReady: false. This is a bounded technical review package, not an automatic IPM upgrade, whole-console guard or general production-readiness claim.
Video guides: The three earlier videos describe previous console workflows. Two new illustrated 1.3.1 guides use synthetic narration and are not live test footage: Install and Evaluate the Contest Entry and How the Bounded Server Guard Verifies a Change. The written judge guide and validation record remain the technical evidence.

IRIS Anvil release notes

2026-09-27 —

Verified IRIS 2026.2 reactor
This release makes the contest workflow reproducible and live-tested on IRIS 2026.2. The only supported change is DEPLOY_WEB_APP for /anvil-demo, with the declared USER namespace, Anvil.REST dispatch class, and enabled state.

Added

• Live IRIS 2026.2 integration coverage in GitHub Actions.
• A smoke test covering SysAdmin login, web-app PUT and GET, independent ObjectScript verification, receipt replay, and read-only process and task inventory.
• A randomly credentialed operator for a fresh, disposable local demo container.
• Read-only observation through /api/admin/info, /api/admin/v2/processes, and /api/admin/v2/tasks.
• A contract check for the API endpoints, bearer-token boundary, allowlist, receipt construction, and both REST bootstrap surfaces.

Fixed

• Read the IRIS 2026.2 login token from its actual top-level response field.
• Compile both Anvil.Public and Anvil.REST during bootstrap; a fresh container previously returned 404 from the public API.
• Wait until IRIS reports running before bootstrapping.
• Show an independent receipt-verification mismatch as a reactor failure.

Hardened

• Reject proposals outside the demo’s action, target, or payload allowlist.
• Refuse execution if the stored payload or digest no longer matches the declared intent.
• Recheck the receipt against current IRIS state; a planned proposal cannot claim to be verified.
• Bind demo ports to localhost and pin the runtime to intersystems/iris-community:2026.2.

Verified
The live smoke path passed on IRIS Community 2026.2 (Build 221U): it rejected an out-of-scope proposal, confirmed a planned proposal was unverified, performed the official SysAdmin PUT and GET, sealed an independently checked receipt, replayed it without changing the receipt, and read process and task inventories.

Upgrade notes and limits
Pull the 2026.2 image and recreate the demo container before bootstrapping. The generated AnvilDemo account has %All and belongs only in the dedicated local demo container. Ports now bind to localhost by default.

The only mutation remains /anvil-demo. Process and task features are read-only; optional Sling/Oak mirroring is outside the mutation trust boundary.

Initial Release

Optional IRIS-native managed guard with four bounded workflows, server READ_ONLY,
per-workflow approvals, native authorization/readback and persistent recovery
without repeating uncertain changes. Guided review installer and final audit
fixes for stop retry, startup failures, key-cleanup reporting and profile docs.
Validated on a fresh IRIS Community 2026.2 instance; 269 JavaScript and 20 Linux
log-reader tests pass. Separate managed bundle; not an automatic IPM upgrade,
general active-user editor or production-readiness claim. See the release and
final remediation report for exact artifact hashes and limits.

Initial Release

IRIS Portico - Initial Release (v0.0.1)

We are excited to announce the first release of IRIS Portico, a web-based management portal and admin console for InterSystems IRIS.

🚀 Key Features

• Web-based Management Portal: A modern, intuitive interface to manage and monitor your InterSystems IRIS instances.
• Admin Console: Built with Angular for a responsive and dynamic user experience.
• SysAdmin API Integration: Seamlessly interacts with InterSystems IRIS SysAdmin APIs for administrative tasks.
• Docker Support: Easy to deploy and run in containerized environments.
• Healthcare Ready: Compatible with both InterSystems IRIS and InterSystems IRIS for Health.

🛠️ Technology Stack

• InterSystems IRIS / InterSystems IRIS for Health
• Angular (Frontend)
• Docker (Deployment)
• SysAdmin API (Integration)

📦 Installation & Usage

Please refer to the README and Documentation for detailed installation and usage instructions.

🔗 Links

• GitHub Repository: https://github.com/xohg/iris-portico
• Documentation: https://github.com/xohg/iris-portico/blob/main
• License: https://github.com/xohg/iris-portico/blob/main/LICENSE

---

This is the initial release. Feedback and contributions are welcome!

Initial Release

Initial Release

Initial public release of Armada Battery, an evidence-driven operations console for InterSystems IRIS.

Includes a Docker Compose setup with IRIS Community Edition, read-only instance observations, four bounded administrative workflows, and auditable outcome receipts.

Changes are disabled by default. Workflow tests use synthetic fixtures; live verification covers read-only observations and blocked preflight. Installation instructions and current limitations are documented in the README.

Initial Release

Initial Release

Initial Release

Release 1.0.1

• The audit database and task history now open with results: the audit database shows the last 24 hours and task history the last 7 days, instead of an empty screen waiting for a search.
• When the agent opens one of those screens to answer you, the screen runs the same search the agent read, so the rows it talks about are the rows in front of you.
• README: a 90-second tour, calling OcuPilot's REST API from a script, known limitations, and the architecture diagram as an image.
• IPM install note: if IPM reports that no repositories are configured, run zpm "enable -community" once, then install again.

The live demo at https://ocupilot.org runs this release.

Initial Release

ValhallISC mounts InterSystems IRIS servers as local folders. Namespaces show up as folders, packages as subfolders, and classes and routines as .xml files. Copying a file out gives its XML export; copying an .xml file in imports and compiles it. You manage profiles from a tray / menu-bar app, or from the command line (valhallisc --help).

Initial Release

Minor packages installation fixes

Initial Release

Initial Release