Why DevStation needs engineering notes

DevStation is being built as a topology-first CLI for modeling and recreating homelab and development environments. That creates decisions that deserve more than a changelog line: how to isolate domain contexts, where provider integrations should live, when RPC helps support multiple UIs, and how to test flows that combine terminal interaction, files, infrastructure and real state.

This space exists to turn those decisions into useful material. The goal is not to sell a vague promise. The goal is to show reasoning, mistakes, constraints and project evolution with enough clarity that someone can reuse the ideas in another context.

What belongs here

Posts should start from concrete DevStation problems:

• why topology needs to be the source of truth;
• how hexagonal architecture keeps Proxmox, the TUI and persistence away from the core;
• how DDD helps separate cluster, environment, vault, role and station without turning everything into one generic service;
• how MCP can support exploratory testing and behavior review;
• why RPC creates a path for a TUI, web UI and external automation without duplicating rules.

Each post should include context, the decision, rejected alternatives, practical consequences and next steps. When useful, it should include diagrams, code snippets, reproducible commands and both Portuguese and English versions.

The value for the project

Public engineering notes create a trust trail. Readers can understand what exists, what is still a hypothesis and how technical choices connect to the roadmap.

They also force internal clarity. If a decision cannot be explained in writing, it may not be mature enough in code yet. That pressure is useful: good architecture is not just folder organization, it is the ability to explain boundaries, costs and intent.

The value for the author

A consistent technical blog is also a portfolio. It shows judgment, communication, depth and the ability to turn practical experience into shared knowledge. That can open doors, but the path is indirect: usefulness comes first, authority comes later.

That is why the editorial bar needs to stay high. AI can help with review, structure, translation and clarity checks, but the technical direction has to remain human: each article should come from project decisions, not generic topic generation.

First editorial line

The next posts should form a foundational sequence:

1. Topology-first: why the model comes before the provider.
2. Hexagonal architecture: how to keep integrations outside the domain.
3. DDD in DevStation: small, explicit and testable contexts.
4. RPC for multiple UIs: TUI now, web and automation later.
5. MCP in exploratory testing: observing behavior beyond traditional asserts.

If this foundation is well written, the blog stops being a marketing page and becomes living documentation of the engineering reasoning behind DevStation.