Release notes

Released 8 October 2026

• Accounts the tool keeps, as a third way to sign in. Authentication:Local=true keeps the operators' accounts in the tool itself — in a SQLite file of its own under Accounts:Directory, or in a database of your choosing, PostgreSQL, SQL Server or SQLite, named in Accounts:ConnectionString the way a service names its store — beside the provider and running open; exactly one of the three is set. There is no registration: the first start answers every address with a setup page that makes the first Administrator, and from then on an Administrator makes every account. Operators sign in at /login; five wrong passwords lock an account for a while; a session lasts twelve hours without a request. The roles are the roles an account holds, Administrator, Reader or a name a manifest writes under roles.read, which exists as a role from the moment the manifest is installed — see Keeping the accounts in the tool.
• The admin area. Settings moved to /admin/settings, with /settings sending a bookmark on; an overview at /admin offers every page in the area as a tile; and two pages joined Settings under the operator's menu: Users, where accounts are listed, made, given and relieved of roles, renamed, given a password, unlocked and removed; and Roles, where every role is listed with where it came from, and roles are made and removed. Through a provider, both pages say the accounts are the provider's, name it, and list what grants each role, read-only. A service cannot be named admin, setup or password, since those are the tool's addresses now.
• Password, under the operator's name, where an operator with an account the tool keeps changes the password they were given to one of their own.

Released 7 October 2026

• Minor fixes. Nothing a manifest says, and nothing a store holds, reads any differently; the image is built from the same framework packages as 1.0.0.

Released 7 October 2026

• The first release. The build the website and the hosted demo run, with nothing changed in the tool since the last beta: the three betas before it, below, are what it is made of. The registry now carries latest beside 1.0.0 and 1.0, as Deployment said it would; the pull lines on this site keep naming the version, so a restart never moves you to a release you did not choose.

Released 7 October 2026

• Built on Memoria 2.0.0. The framework packages the tool carries move from the second beta of 2.0.0 to its release. Nothing a manifest says, and nothing a store holds, reads any differently: the suite and the six store spikes pass as they did, and Memoria's own stores are still declared through the manifest the way anyone else's are.

Released 7 October 2026

• A clean cut of the beta. 1.0.0-beta.1 was republished under its own name several times between 4 and 6 October while the deployment was built around it, each time from a later commit; this version names one build, the one the website and the hosted demo run, and changes nothing in the tool since the last of those. What arrived on the way is listed under 1.0.0-beta.1 below, which is where it was first released.

Released 4 October 2026, and republished through 6 October as the deployment was built

• The image is pulled with a version. The registry carries no latest before the first full release, on purpose, so the Get it page and the account's pull token page print the pull with the version the website was built with.
• Every account gets a pull token from its account page: the image is private, and the token, made on request and shown once, is what pulls it.
• The tool is StateLens. It reads any store through a manifest, so its name carries no framework's. Its website is statelens.dev, where these notes, the documentation and the licence are, and the manifest at the root of a zip is statelens.json.
• Support is asked for on the website. The support form at statelens.dev/support is where support for every edition is asked for, signed in; there is no public issue tracker. Anything else goes through the contact form, open to anyone.
• The samples ship as an image and two downloads. The seeder that fills a store with the sample domain is published as statelens.azurecr.io/statelens-samples, and the two sample archives, each an assembly and its manifest, are attached to a release on the public Memoria repository — see the samples page. Nothing needs a checkout.
• The image is private, and every account gets a pull token. The tool and the seeder are published to a registry of the product's own, statelens.azurecr.io, which is not open: the Community edition is now sign up for free, get a pull token, and the token — a name and a password that read the two images and nothing else — is the account's to regenerate. See The container image.
• The tool's own version line starts here. The tool was versioned with the framework until now, and nothing was ever released under those numbers; from this version it is numbered on its own, from 1.0.0, and released as a container image of its own, statelens.azurecr.io/statelens. See Deployment
• Any event sourced store is read through a manifest. A zip of domain assemblies carries a statelens.json that says which of its types are the streams, the events, the aggregates and the projections, how they are named, folded and read back, and where the events and snapshots are: in SQL, in Cosmos DB or in KurrentDB. The tool knows no framework by name; Memoria's own stores are declared the way anyone else's are. Stores written by Marten, Eventuous, Message DB, SQL Stream Store, KurrentDB and Cosmos DB have each been read this way. See Configuration and the example manifests
• A manifest can say what a domain calls its models. A service's domain block may carry labels, one entry per kind: the singular in lower case, or an object saying one and many for a plural not made with an s. The bar, the overview tiles, the Types and Data pages, the detail pages and the home page's counts all take the word, so a domain that calls its read models views or summaries reads that way everywhere; a service that says nothing reads as before. The dynamic consistency boundary's kinds keep their names, since its tables are Memoria's own. The website's manifest builder writes the key, and the SQL Server example uses it. See What to put in a zip
• Each installed archive's manifest opens from its row on Settings. The statelens.json as it was uploaded, with the file name above it and a way to copy it, in the same pop-up a stored payload opens in. An archive whose manifest broke a rule is marked Manifest refused, its row still saying which rule, and its manifest still opens; one with no manifest at all is still marked No manifest. See StateLens
• Editions, metered by services. One service, an entry in a manifest's services list, is read free, by anyone on your team, forever. Standard reads up to five, Professional up to twenty-five and Enterprise any number, named in the Edition setting; there is no key and nothing to activate, and the tool counts the services itself. See Editions, Pricing and the licence
• Read-only, everywhere. The tool never appends an event, never writes a snapshot, never deletes a row and never creates schema, whichever store it reads
• The tool links its own website, and nothing else. The About page's version is said and not linked, and the commit it was built from is not shown: the repository is private, so a reader could open nothing. About's licence, its documentation tiles, its Pricing tile, the start-up refusal's link to Configuration and the footer's first mark all open the tool's website, under a stand-in address until the product's domain is chosen. The build is still stamped with its commit, in the assembly's informational version. See About