Opt-in Northwind commerce + private Assistant/MCP showcase scaffolded via netscript CLI

What they did

The author added an opt-in showcase to the netscript CLI: `netscript init northwind --from showcase`, plus a documented `showcase:setup` recipe. The showcase composes existing Utility pages and plugin wiring into a working commerce app — orders, customers, products and line items with typed oRPC reads, Prisma persistence and realistic dated seed data. On top of that they wired durable worker progress and an order → payment → shipping saga state shown on the order detail page, real webhook ingress, and stream-linked activity. They also built an authenticated private chat/MCP surface with finite catch-up, exact-offset resume, ownership checks and native transcript replay, plus no-key provider setup and canonical sign-in surfaces. Work was sliced S0 research/design through S3 configured gates, runtime CI, bounded debt documentation and formal leaf evaluation. Crucially, ordinary init was left byte-for-byte identical: all 220 default files, including the agent bundle, match current main. Validation covered 16 root check tasks, structured type check, architecture/quality gate, CLI lint/format ratchet, export doc-lint and publish dry-run; a fresh scaffold.showcase run passed all six local gates; 96 focused tests, 21 source/stub scenarios and a mounted chat browser regression passed; a read-only visual subgate scored all 60 view/theme/width combinations at ≥8/10; and runtime CI passed on Postgres (124/124), SQLite (116/116) and showcase (8/8). A first non-draft quality run failed in release:preflight because generated scaffold source inside a quoted string was misclassified as executable package file IO; the repair used upstream Babel token ranges with conservative scanning on parse failure, adding no allowlist or generated-file exemption.

How it went

The showcase shipped as release scope 0.0.9 with formal independent IMPL-EVAL PASS and reviewer approval on the repaired slice. Default init isolation was proven at 220/220 identical files, runtime CI passed across Postgres, SQLite and showcase lanes, and visual acceptance cleared every combination. Accepted debt was recorded for two over-cap parents growing by one showcase child each, with owners, costs and closure gates.

Worth knowing

Private chat currently requires POSIX secret-file permissions and a single app host with local ownership KV; conversation metadata listing is O(n), so larger deployments need shared ownership and index pagination. Real OAuth/OIDC and model credentials are external prerequisites — CI uses a stub provider and external-provider browser acceptance was not exercised. Telemetry renders its current unavailable state. The final repair-head immutable remote CI was still in progress at write time, and the desktop exception boundary #859 was enforced rather than fixed.

Wiring

The CLI gains a `--from showcase` source on init that pulls the showcase archetype instead of the default template set, and a `showcase:setup` recipe documented alongside it. The showcase composes existing Utility pages and plugin wiring rather than replacing the framework runtime: Prisma provides persistence, typed oRPC procedures expose reads, and the order detail view binds saga state fed by durable worker progress. Webhook ingress writes into the same stream that activity views read, so committed stream activity and saga timestamps render together. The private Assistant/MCP path sits behind authentication with ownership checks, uses a local ownership KV plus POSIX secret-file permissions for credentials, and supports finite catch-up and exact-offset resume with native transcript replay. CI runs the showcase lane against Postgres and SQLite with a stub provider, and a separate read-only visual subgate renders 15 views across light/dark at 1440 and 390px. Release preflight scans generated scaffold source using upstream Babel token ranges, falling back to conservative scanning when parsing fails.

Try it yourself

In this repo, add an opt-in showcase archetype to the CLI without changing default init output. Steps: (1) add `netscript init <name> --from showcase` and a documented `showcase:setup` recipe; (2) compose existing Utility pages and plugin wiring into a commerce app with orders, customers, products and line items using typed oRPC reads, Prisma persistence and realistic dated seed data; (3) add durable worker progress and an order → payment → shipping saga state on the order detail page, real webhook ingress and stream-linked activity; (4) add authenticated private chat/MCP with finite catch-up, exact-offset resume, ownership checks and native transcript replay, plus no-key provider setup and canonical sign-in; (5) prove default init is byte-identical (all 220 files, including the agent bundle) with no exclusions or normalization; (6) run root check tasks, type check, architecture/quality gate, lint/format ratchet, export doc-lint and publish dry-run, then a fresh scaffold.showcase through all local gates; (7) add focused tests, stub scenarios and a mounted chat browser regression, including negative controls for missing shipping persistence, empty-conversation deadlock and cold evidence-directory failure; (8) record any cardinality debt with owners, costs, stop conditions and closure gates.