Engineering notes.
Architecture, implementation notes, and the decisions behind the build.
Choose a reading path 3 guided routes
Build a first PlumeGo service
Run the minimal service, inspect its boundaries, then review the reference tests.
Explore MiniX across hosts
Reproduce the H5 sample before examining shared contracts and unverified host boundaries.
Build a readable static-first site
Follow the rendering boundary, maintenance choices and rich-content implementation.
Browse topics
Static finding aid: browse a topic below, or use your browser’s Find command. All notes are available on this page.
Birdor Links architecture: workspace-first SaaS edges on Cloudflare
How we structure a Cloudflare-native short URL service with explicit HTTP boundaries, workspace-scoped authorization, and 34-table D1 schema that separates edge redirects from background side effects.
Run the MiniX H5 sample against a local API
Reproduce the MiniX H5 sample at a fixed revision, repair its workspace lock entry, and inspect the local login and navigation boundary.
Your first PlumeGo service: one verified HTTP round trip
Build a minimal PlumeGo HTTP service at a fixed source revision, inspect its JSON envelope, and trace route ownership.
MiniX lab review: keeping a multi-host application kernel inspectable
A public lab review of MiniX: how contracts, controllers, host adapters and manifests create a visible boundary between shared application intent and H5 or WeChat runtime behavior.
PlumeGo lab review: using reference services to test HTTP boundaries
A public lab review of PlumeGo reference services: how runnable examples and bounded use cases test whether a small Go HTTP kernel remains explicit under application pressure.
PlumeGo architecture: explicit Go HTTP boundaries for humans and agents
How PlumeGo combines a standard-library-only Go kernel, explicit route wiring, stable modules, and machine-readable specifications for inspectable HTTP services.
Designing system boundaries before service boundaries
A practical way to turn an ambiguous product surface into stable technical seams before choosing infrastructure.
Treating engineering content as an interface
Why a technical article should expose a stable, useful structure for humans, search systems, and future maintainers.
Static-first systems for developer-facing sites
How we keep a content-heavy technical surface fast, deployable, and easy to maintain without introducing an application backend.
Maintaining a small interface as a product scales
A field note on keeping technical surfaces understandable when projects, tools, and experiments begin to multiply.