Cory Policht
← Back to the Devlog
DEVLOG · 2026-05-14 .. 2026-05-25 · RELEASE

The first real releases.

The infrastructure layer reaches 1.0 — shared-workflows, DockerContainers, and the logging library — while the MCP Server lands its tool surface and a runner-label scheme gets reverted three days after it shipped.

WINDOW
Start2026-05-14
End2026-05-25
Kindrelease
Projectshomelab-infrastructure, structured-logging, mcp-server-implementation, ide-extension
Delivered
  • structured-logging
    Structured logging ships as a reusable 1.0 library
    Coryp.Logging cuts v1.0.0 — the first component in the portfolio to be published as a library other projects consume rather than as a service.
    Coryp.Logging · v1.0.0
  • homelab-infrastructure
    Shared CI workflows and base images reach 1.0
    shared-workflows v1.0.0 and DockerContainers v1.0.0 land within five days of each other. Everything else in the portfolio builds on these two, so versioning them was the precondition for versioning anything else.
    shared-workflows · v1.0.0DockerContainers · v1.0.0
  • mcp-server-implementation
    The MCP Server's tool surface lands behind a capability registry
    File tools, a run_command shell tool with workspace and environment confinement, and git status/add/commit/push — each gated through a tool capability registry rather than exposed flat.
    MCPServer · #2MCPServer · #3MCPServer · #4MCPServer · #5
  • ide-extension
    IDE extension gains activation, config schema and structured output
    US-IDE-7.1.1 lands as a single reviewable unit covering activation, the configuration schema, and the structured output channel.
    IDEExtension · #2
  • homelab-infrastructure
    Runner stack auto-deploys on tag push
    The lightweight runner stack starts deploying itself when a tag is pushed, so a version bump is what provisions capacity.
    homelab-stacks · d653cc0

This is the week the infrastructure layer stops being a pile of scripts and starts being something you can depend on.

shared-workflows cuts v1.0.0 on 05-16 and DockerContainers v1.0.0 on 05-21. Those two sit under everything else in the portfolio — every pipeline pins the first, every image builds on the second — so versioning them was the precondition for versioning anything at all. Both then take a handful of patch bumps over the following days, which is what a real 1.0 looks like: not a perfect tag, a tag you are allowed to move.

Coryp.Logging cuts v1.0.0 on 05-23. This is the first thing here published as a library rather than a service — something another project takes a dependency on. That is a different kind of release from deploying a container, and worth marking separately.

On top of the infrastructure, the actual product surfaces move. The MCP Server lands its tool surface in four PRs — file tools, a run_command shell tool with workspace and environment confinement, git operations, and a tool capability registry they all hang off. The registry is the interesting decision: the tools are not exposed flat, they are gated. The IDE extension lands activation, its config schema and its structured output channel in one unit.

Then there is the part nobody puts in a release note. On 05-24 the runner labelling scheme — per-host, per-toolchain labels — is reverted in both homelab-infra and homelab-stacks. It shipped days earlier as part of “Group B Wave 1-3 — runner hardening”. The single-label scheme that replaced it is less fine-grained and more correct. Two of the five patch bumps on DockerContainers that same day exist because the first attempt at this was wrong.

Lessons learned

  • Version the things everything else builds on first. Until shared-workflows and the base images had numbers, every other “release” in the portfolio was a deploy with no contract behind it.
  • A revert three days after shipping is cheaper than a quarter of living with it. The runner labels were a reasonable idea that turned out to be operationally expensive. Reverting was the fix, not the failure.
  • Gate a tool surface behind a registry rather than exposing it flat. It is the difference between adding tools and having to redesign when the fourth one needs a permission.