Roadmap

This is what Loomscope intends to build, in the order it intends to build it, and — just as importantly — what it has decided not to build.

Dates are deliberately absent. Loomscope is maintained by one person; sequence is a commitment, timing is not.

Current release: 0.13.1. Usable, covered by CI, not yet stable.

Every release below carries an entry in CHANGELOG.md with the same four headings, in this order, and a heading is omitted only when it is genuinely empty:

• Security — anything that changed a boundary. First, always, because it is the section that decides whether an upgrade is optional.
• Added — new capability, named from the operator's side.
• Fixed — with the symptom stated, not just the cause. "The linter had never loaded its configuration" is more useful to a reader than "fix lint config".
• Known defects — what shipped broken, and the workaround. A release that hides one of these buys a week and spends a customer's trust.

---

How to read this

Each item carries a state:

---

0.2 — Close the credibility gaps

The theme is removing the distance between what Loomscope claims and what it does. Nothing here is a new capability; all of it is making the existing surface trustworthy.

0.2.1 — A deployment you can actually start

The 0.2 audit found that the product has no front door. Nothing in the shipped code ever creates an organisation or a membership — the only such statements live in tests and the seed script — and there is no sign-up page, no invitation and no role change. The quick start says "sign in"; a new installer has nothing to sign in with.

Both features here are small. They are grouped as a patch release because each removes a way a first-time installation silently does nothing useful.

0.2.2 — Work that happens without a browser open

This is the release after which the README stops telling operators to treat the server as a single instance.

0.3 — Integrations and alerting

Loomscope currently tells you things only if you go and look. This is the release where it can tell you without being asked.

Event types: host.added, host.removed, service.changed, tls.expiring, vuln.critical, vuln.high, snapshot.diff_significant, daemon.offline.

The pipeline is the decision, not the destination list — see ADR-0013. Two items ride on it:

0.4 — Programmable Loomscope

Three interfaces onto the same inventory, for three different consumers. Each has its own ADR because each could reasonably have been declined.

The ordering is deliberate. The REST API comes first because the CLI and the MCP server are both clients of it — building either one first would bake in an unstable contract.

0.5 — Operable at scale

Proved on a cluster, 2026-08-19

The Helm chart was linted, rendered and schema-checked by CI and had never been installed anywhere. Installing it into a k3s node with ingress-nginx and cert-manager took about an hour and found three defects, every one of which made the product unusable at any real hostname:

• A chart helper named a Secret the chart never creates. cve-ingest could not start whenever the bundled PostgreSQL was enabled.
• The auth client had localhost:3000 compiled into the browser bundle. NEXT_PUBLIC_* is substituted at build time, so every released image told visitors to authenticate against their own machine. Sign-in span forever rather than failing, because the rejected fetch had nothing waiting on it.
• The session cookie was set, sent, and never recognised. Better-Auth prefixes its cookie with __Secure- over HTTPS; the middleware looked only for the bare name, so a successful sign-in bounced straight back to the login page.

All three share a signature: they exist only when the product is served behind TLS at a real hostname. 721 tests, a kubeconform-validated chart and a CI suite that had grown all week could not see any of them.

The install path is now scripts/k3s-install.sh, with scripts/k3s-load-images.sh for a cluster with no registry credentials and scripts/vps-recon.sh for looking at a machine before putting anything on it. The docker compose quickstart remains unproven — the node used had no Docker, and installing one beside a running production cluster was not a change worth making for a test.

1.0 — Enterprise readiness

1.0 means the interfaces are stable and upgrades are supported, not that the feature list is finished.

---

Considering

Ideas under analysis. Each will get an ADR before any code is written.

Candidates from a field comparison, 2026-08-19

Prompted by looking at L0p4Map, a PyQt6 desktop scanner. It is not a competitor — a single-user desktop tool and a multi-tenant inventory platform do not replace each other — but its feature list named things we do not do, and some are cheap.

Ordered by what they are worth, not by effort.

A correction. This paragraph previously declined full nmap/NSE integration outright, on the grounds that it would mean shipping a restrictively-licensed binary and its update cadence inside an air-gap bundle. The observation was right and the conclusion was wrong: the licence problem is with shipping nmap, not with using it. Invoking the nmap the operator already installed carries no redistribution obligation, needs no OEM licence, and leaves the air-gap bundle exactly as auditable as it is today. It is in the table above, and the reasoning is recorded in ADR-0024.

The honest reading of that comparison. In a ten-minute demonstration to a network engineer, a desktop tool that launches and draws a live graph beats a platform that wants Docker, an enrolled daemon and a scan cycle. Our advantage only appears at the second question — who changed what, on which site, six months ago, and can you prove it to an auditor. That is a real difference and a real weakness at the same time, and the answer is to make first-run work faultlessly rather than to add features.

| Agentless Windows inventory over WinRM | Closes a real gap for mixed estates | Credential handling on Windows is a large surface, and SNMP plus port fingerprinting already identify most Windows hosts | | Passive discovery via SPAN/mirror ports | Finds hosts that never answer a probe | Requires switch configuration most users cannot change, and overlaps with the NetFlow path | | Config-drift detection on network devices | Natural extension of snapshots | Turns Loomscope into a configuration manager, which is a different product | | Multi-instance federation | Some estates genuinely cannot route to one control plane | Doubles the security model. Explicitly out of scope for multi-site, which solves the common case |

Declined

Recorded so the reasoning survives.

---

Known gaps

Carried from the changelog so this document is honest on its own:

• Scheduled work does not retry across a restart. A failed tick is retried within the same run, with backoff, where the job's interval is long enough for the wait to matter — but a worker that dies mid-retry resumes the normal schedule rather than resuming the attempts. Closing it properly needs a durable queue, which is a dependency decision still open.
• SAML is not implemented. OpenID Connect and SCIM cover the directories that speak either; a provider that only speaks SAML cannot federate.
• There is no public inventory API. /api/v1/ carries the daemon protocol and a few administrative endpoints; the UI talks over tRPC, which is internal and not a stable interface.
• There is no /metrics endpoint. Prometheus support is planned.
• Nothing prunes itself. Snapshots and audit entries accumulate indefinitely, so disk grows with inventory size times days retained.
• Automated tests reach a minority of the HTTP routes, and no browser test framework is installed, so the UI is verified only by hand.
• The published OpenAPI specification can drift from the Zod contracts if the pre-commit hook is bypassed.

Influencing this roadmap

Open an issue describing the problem you have, not the feature you want. The most useful contributions to this document have been descriptions of an environment Loomscope handled badly.