Documented example verification

Independent execution review on 4 October 2026, on Windows with Node 22, in owned workspaces and isolated instance/port registries. This records actual example outcomes; it is not Linux/macOS, release or GA qualification.

Template-derived Todo services

The current learning path uses dedicated repositories generated by GitHub from service-template: lasso-todo and lasso-todo-api. They own their runtime source, manifests, package/test/verify entrypoints and release pipelines. The Todo and API run as managed services using acquired release archives.

Independent review caught three publisher defects before release: workflow input placement, prerelease tag pinning and missing checksum declarations. The first published consumer attempt then exposed Core's health-check import serialization defect, tracked as #1669. Both producers use the supported singular form for their single HTTP check.

The original PostgreSQL pin failed first boot on the materialized data directory and detached the launcher. The preceding tutorial verification used an explicit local foreground adapter and did not qualify those published defaults. The corrected producer release below replaces that prerequisite; original failures remain retained under #1667.

Independent Windows consumer verification of the corrected development releases passed for Todo 2026.10.4-b6d089f and API 2026.10.4-9b45f09. Literal fresh imports and Core checksum acquisition passed. Released Admin installed, configured and started both services. Browser creation, refresh and Admin stop/start retained the same Todo data. Original JSON IDs migrated into real PostgreSQL; the Go API served the Todo proxy, returned an observable 503 during API outage, recovered and retained all original IDs after the three managed services stopped and restarted. The acquired Go binary identifies the exact clean release source commit.

Both service pipelines package Windows, Linux and macOS archives. Todo archive consumer checks run on all three; API additionally verifies its held Linux archive against real PostgreSQL. Full managed/Admin integration above was executed on Windows with the explicit PostgreSQL adapter. It does not qualify macOS PostgreSQL, whole-demo shutdown, upstream template admission or GA.

Earlier App-only identity stage (#1673)

The fourth tutorial now adds Zitadel sign-in to the managed Todo app, rather than leaving the consuming application unspecified. Published Todo 2026.10.4-6f47534 targets 6f4753485dfa93a8a23e6f3d9751416d770042e3; all three platform source and extracted-archive checks plus publication passed in run 37213848505.

Signed HTTPS protocol fixtures directly exercise code + PKCE, nonce/state, signature/issuer/audience/expiry rejection, outage refusal, callback replay, CSRF/host denial, capacity, logout, restart invalidation and retained shared data. Those fixtures are separate from actual Zitadel/browser execution.

The local identity setup pins Zitadel 2026.9.25-93d4c84, Certificates 2026.9.25-588398b and corrected PostgreSQL 2026.10.4-1af7982. The application owns @todo-certs; the baseline certificate manifest and CA remain untouched. Provisioning uses declared create-only signed Broker IPC and preserves existing master-key/password references. The initial incorrect bootstrap-variable attempt remains failure evidence; FIRSTINSTANCE_ORG_HUMAN_* is the checked contract. Fresh initialization in a separate retained identity database passed browser login with the Broker-backed bootstrap password and no forced password change. The initial login name is [email protected]; the guide distinguishes it from the contact email. Re-running the public provisioning helper reported both references existing and unchanged.

Independent Windows execution acquired the actual released Todo archive through literal Core CLI import/install and verified SHA256 a8297a6f16e13cc283ef80ccc0a5187e1c276fdbb176d21f0e6faa3d32b8d5e6. A fresh owned Core loaded that exact artifact; an earlier in-memory held-artifact attempt was retained and excluded from released acceptance. Actual Zitadel test user login, App-protected Go API proxy reads/writes/reload, native confirmed Todo restart, re-login and logout passed. PostgreSQL retained all four original JSON IDs/titles, and the released Go API list matched the SQL rows.

Node verified the local CA chain. Browser verification used an isolated profile with the exact leaf SPKI pinned; it did not install OS trust or establish a machine-wide trust claim. Public /healthz stayed available; anonymous /todos was denied, and restart invalidated sessions while retaining data. Local sessions authorize the shared list, not per-user rows or direct remote API access. No Linux/macOS native identity, production deployment or GA claim follows.

Correction (#1692): that release protected Todo's front door only. The Go API still accepted direct anonymous reads and writes. The previous browser checks established App session enforcement, not API authorization. That gap was a defect in the SSO lesson, even though the API listened on loopback. The corrective release below adds API token validation; the earlier results remain recorded with this narrower scope.

Todo API authentication correction (#1692)

The API now requires an explicit mode: anonymous for the preceding local lessons, or Zitadel for SSO. Missing or partial identity configuration fails startup. The secured API introspects each bearer access token over trusted HTTPS with a separate registered Basic API client and a private secret file. It checks active status, issuer, project audience, issuing Todo Web client, subject, token type and lifetime before accessing the database. Public health does not authorize Todo reads or writes.

Todo requests the project audience and keeps the access token only in its bounded server session. The proxy forwards that token, ignores browser-supplied Authorization headers and never falls back after API rejection. The paired configuration helper rejects older API manifests and configures API protection before enabling App sign-in. Both services must be stopped during changes.

New tests cover source middleware rejection and configuration, signed HTTPS OIDC forwarding, access-token expiry and extracted-archive execution. The proxy fixture uses a simulated API and does not establish Go enforcement or real Zitadel acceptance. Existing protected tests were not edited.

The first corrective publication, Todo 2026.10.4-9c6567f and API 2026.10.4-3e560cc, passed package pipelines but failed the literal Core import configuration check: Core's schema projection removes meta, including the API capability marker. The acquired archives were correct; the released helper refused to enable SSO on the imported manifest. That attempt is retained as a failure, not released acceptance. The subsequent correction publishes the non-secret capability in env.TODO_API_AUTH_CONTRACT, which import preserves, and tests the paired helper against a manifest with no metadata. Runtime startup uses the same capability and still requires matching secured settings.

On 5 October 2026, independent Windows execution passed with literal Core imports, actual checksum acquisition, the acquired paired configuration helper and managed launch of these final development consumers:

Consumer	Exact published identity	Windows archive SHA-256
App	Todo 2026.10.4-15dc4b9, source 15dc4b906224a360d91f0478acace04633fee70c	f8c1ce5247d5118e939598b27b40ed44da9531743a304b026be99d2d71a86ebf
API	API 2026.10.4-02ef566, source 02ef5663a16a04dab1769bb33f0d5a168c525f81	00d84ca8c04d701c44f228111e3196633a91c139b2a41f717ea58f4b441cbdb6

Todo publication run 37245621423 and API publication run 37245603210 passed all three platform package gates; the API also passed held Linux archive execution against real PostgreSQL. The independent managed identity boundary below was executed on Windows, separately from those hosted package gates.

Managed boundary	Direct result
Literal release import	Preserved environment capability; no metadata repair or local archive substitution
Direct API GET/POST without a token or with an invalid bearer	401; exact SQL rows unchanged
Real Zitadel password + PKCE browser login	Session established; access-token-forwarded create 201 and list 200
Persistence and managed App/API restart	Eight SQL rows, all previous IDs/titles retained; old session invalidated
Identity stopped with an authenticated session	Read and CSRF-authorized write returned 503; SQL rows unchanged
Identity recovery	Authenticated list recovered with retained data
Logout	Old cookie and anonymous App data requests returned 401

An earlier local-package integration also tested a real token for the wrong audience. Source TLS middleware fixtures cover expired/revoked/incorrect issuer/client/scope tokens and malformed/provider responses. Those are separate from the final released browser/API observations above. A test harness initially omitted the App's CSRF header and received the expected 403; the corrected positive write used the actual session CSRF token. Transient GitHub 500 responses during release checksum acquisition were retained; a later actual Core install succeeded without substituting local payloads. Private credentials, databases, certificates and failed attempts remain retained; inherited fixtures and host trust were not changed. No per-user list, native WebView SSO, production or GA qualification follows from this correction.

Corrected PostgreSQL producer release

lasso-postgres 2026.10.4-1af7982 targets 1af7982802a1f996a35c86cf42417d35d222cf7c and includes a foreground launcher beneath the managed Node provider. It leaves install files outside the cluster, retains only the old sole empty placeholder outside that directory, refuses unexpected nonempty contents and removes the temporary initialization password. The released manifest pins the tag and binds archive SHA256 checksums.

All three platform jobs passed in publication run 37196595447. Held archives were tested for actual install files, foreground child identity, cold/warm SQL persistence, launcher stop/listener closure, abnormal child failure/recovery, old-placeholder recovery, retained-data refusal and configured max_connections=120. Windows hosted execution uses an ordinary account because the upstream server refuses administrative tokens. Its archive graceful stop uses parent IPC; that check is separate from native Core stop/start below.

Independent Windows consumption of the actual published archive passed literal release import, Core checksum acquisition, cold startup, SQL write, configured 120 connections, native confirmed Stop with port closure and Start retaining the original row. The observed PostgreSQL process is a descendant of the acquired Node provider and Core's managed process. No local tutorial adapter was used. Published Todo retained its original IDs through JSON-to-SQL migration; the published Go API served the proxy and recovered from a real 503 outage. Stopping and restarting all three services through native Core retained all three original Todo IDs.

The supplementary historical PostgreSQL smoke example keeps its old pin and adapter. Full native Core integration here was verified on Windows; hosted producer archive checks do not establish Core integration on Linux/macOS, Apple Silicon, whole-demo shutdown or GA.

Previous managed Todo execution (before template correction)

The previous beginner, PostgreSQL and Go API examples were executed against real Service Lasso, not by manually starting the app binaries.

Check	Observed result
Add Todo to the default running inventory	Discovered in the canonical demo and actual Admin UI
Install/configure/start through Lasso	Released Node provider and Todo HTTP health passed
Todo browser create/refresh	Passed; same saved ID and title retained
Admin Stop/confirmation/Start	Listener became unavailable, then restarted with the same todo
Add PostgreSQL	Pinned release acquired; real SQL create/list passed
Move beginner data to SQL	Original JSON todo ID retained; later SQL todo survived restart
Add Go API	Managed dependency chain, actual browser proxy path and API log confirmed
Stop API and recover	Todo returned 503, then recovered through managed service actions
Restart application service chain	All prior todo IDs retained

The reviewer caught and reran fixes for the running inventory path, required manifest description and direct executable path. The earlier external-host architecture and comment-only Go sketch did not satisfy these lessons.

Todo desktop stage (#1679)

The fifth tutorial uses the native Windows implementation in template PR #25. Its reviewed source candidate is 2372ca237dfe671a4b7bb1e6ae0d99a74a549c9f. Native Windows run 37219797993 compiled the application and NSIS installer; protected host regressions passed on Windows and in Linux run 37219797955. Existing protected tests were not edited.

Boundary	Direct observation
Packaged host dependencies	Portable Node 22, published Core 2026.9.22-f3de461, checksum-verified Admin 2026.8.31-f015b44
Released managed stack	Todo 2026.10.4-6f47534, Go API 2026.10.4-9b45f09, PostgreSQL 2026.10.4-1af7982 installed/configured/started through real Core
Todo persistence	Real browser creation; API and Todo read the same ID after a full host restart
Seed preservation	Modified manifest and user-data sentinel remained unchanged after restart
Broker onboarding	Canonical Core IPC consumer manifest completed bootstrap/authenticated readiness; same Broker remained healthy after 63 seconds
Credential acknowledgement	Reviewer custody retained privately; literal Copy/Continue/sign-in flow remains unqualified because verification did not write credentials to the shared clipboard
Owned shutdown	Host exited zero after stdin shutdown plus EOF; exact PostgreSQL/API/Todo and Broker PIDs were absent afterward
Actual compiled native app	Unchanged NSIS-extracted application created a native window, started real PostgreSQL/API/Todo and read the retained Todo ID; the normal CloseRequested handler exited zero and all five exact native/Node/service PIDs were absent
Diagrams	All five tutorial diagrams passed desktop/mobile and light/dark rendering: 20 views, readable labels and no page overflow

The first compiled candidate (019adef) failed before readiness because Node could not resolve Tauri's extended Windows resource path. The final source normalizes those paths. Earlier raw Broker-producer HTTP health failures remain retained; the corrected template uses Core's canonical IPC consumer definition. The legacy packaging fixture also lacked its declared executable; the packaging helper now creates that fixture without weakening its protected tests. Fixture installation is separate from the real released Todo execution above.

The native application SHA-256 is 9c2ea584f7e2b9ff1bd7e0fa2ad4fa0ae9419c7b00f014406c7a903ed1474a91; installer SHA-256 is 4912b21184d643284d7da283538411e09d806163972e3317b32ccb5f05e8c843. The held payload includes Node 22.23.3; no source or dependency was swapped for execution. The same implementation landed on template develop at 59a8039d5aa57bc60728f3e6e5fda461d6d7a825.

Native installer UI installation/uninstallation/upgrades, manual native-window interaction, code signing, offline service acquisition, embedded WebView SSO, macOS/Linux native execution and GA are separate, unqualified boundaries. The unchanged Core startup-crash suite still reports existing fixture failures; this docs-only change does not claim whole-Core acceptance.

Public Mac SSO checkpoint (#1704)

The SSO article now recommends the public lesson-host route qualified on Intel macOS 11.7.11. Public lesson source 0d72fc40fe3147786fec97642b658389bb063b63 contains the reviewed stage04 implementation; its frozen author head was d9d27754b17db6e0e6ad6534548668ed35f7c9ff. Lesson #9's direct acceptance record retains the literal consumer results and original failed attempts.

Identity release 2026.10.5-d7e04eb targets d7e04ebd9489ddc8c6798e408cd8ce7992711146. Producer run 37327998201 passed all eight full source/actual binary scans and five hosted native gates. All thirteen public assets and twelve checksum entries were read back; seven staged qualification files matched the published bytes. That producer proof is distinct from the literal Mac lesson below.

Boundary	Direct observation
Public consumption	Published Core/Admin, selected Intel macOS 11 Broker/Identity profiles, normal checksum-bound acquisition/configuration/start
Private provisioning	Hidden Node prompt; invalid input/cancellation launched no child; create-only Broker references and protected private API credential file
Paired application	Real Web PKCE login, authenticated App/API reads/writes, SQL IDs retained on refresh
Denials	Anonymous/malformed and genuine other-project API tokens returned 401; CSRF returned 403; SQL unchanged
Identity outage	API reads/writes returned 503 without SQL mutation; recovery returned 200
Lifecycle	Restart invalidated sessions; relogin retained rows; logout invalidated the old cookie; full Core reopen retained identity users/projects and Todo IDs
Setup retention/shutdown	Nineteen manifest/credential/certificate files and three Node symlink targets preserved; owned processes and listener range empty afterward

Exact lesson test run 37347837393 and Windows desktop run 37347837387 passed. They do not replace the native Mac application/provider observations. Natural access-token expiry was not verified; temporary isolated provider settings were restored. ARM macOS 11, native Mac desktop, all-platform full SSO and GA remain unqualified. The earlier manual Windows Core route and its pins remain separate; existing wider Core failures are not repaired by this article. Documentation merge, publication and exact live source readback are separate acceptance steps.

Wider example inventory (earlier review)

Article/example	Observed result and remaining boundary
PostgreSQL source smoke example	SQL/HTTP, stop/restart and setting 120 passed with isolated registries
Packaged PostgreSQL recipient	Pack, unpack, install, setup and real SQL/HTTP passed
Reference host sources: Node, web, Electron, Tauri, pkg, SEA, nexe	Dependency install passed; source startup needs an absent sibling Admin build. #1660
pkg/SEA/nexe Windows wrappers	Builds and host/API/Admin HTTP passed; Echo failed to launch its missing fixture command. #1661
Harness starter, latest reviewed develop	Package/contract validation passed; Windows direct execution failed. The article's historical source pin is a separate boundary. #1662
Wire-consumers import	Old illustrative Dagu tag returned 404; current Dagu manifest also fails validation. #1664. The article now uses a pinned PostgreSQL manifest whose dry-run and real import passed
Canonical demo first-run and Todo Admin	Fresh onboarding, credential acknowledgement, sign-in and Todo service actions passed
Canonical demo recycle/shutdown	Recycle bootstrap fails at Broker startup; stop can report already stopped while owned listeners remain. Unqualified; #1665
Existing shared-host instance registry	Literal startup exceeded the registry size limit; inherited metadata preserved. Isolated registries allowed tests. #1663
ZITADEL SSO Hub	Blocked on operator CA trust, secret provisioning and a registered consumer; no end-to-end SSO claim
Native shells, other operating systems and external release authoring	No native/platform/release acceptance; source/packaging checks do not establish it

Schema fragments, service plans and release checklists are authoring material, not complete standalone examples. Commands containing repository/issue placeholders need real targets; this review did not create or publish external repositories. Runtime API/CLI operations were exercised for the examples above, not every mutation in the reference manual.

Original failures and exact source/artifact identities remain in the private review receipt. Only review-owned processes were cleaned up; inherited state, unrelated services and host trust were preserved. These findings remain open where linked, rather than being replaced by an all-examples-pass claim.