Skip to content

v0.12.0 — the application/infrastructure double vision

Choose a tag to compare

@stranxik stranxik released this 11 Jul 08:58

runward now packages both visions of the doctrine as one gated path: the application domain (what the system does) and the execution topology (where, and under which sovereignty, each port's adapter runs). Doctrine §15 (shared building blocks) was present only as an orphaned shared-bricks.md template — scaffolded, produced by no workflow, verified by no gate. It is now cabled into the method and made executable, without runward ever becoming a runtime: it traces and governs the placement decision, it deploys nothing.

ADR-0017 — operationalize doctrine §15 into the gated flow:

  • Name the double vision (positioning's 5th pillar, method + architect workflows).
  • Cable the orphaned shared-bricks.md into the architect (produce) and iterate (reopen) workflows' DoD.
  • New deliverable execution-topology.md: the port→placement bridge (per port: adapter, location family, data class, sovereignty, ADR, trigger) + a usage registry.
  • An infra ADR family (placement, sovereignty by data class, agent-identity location, multi-region, trace export).
  • execution-topology.md becomes a first-class gated deliverable with its own topology conformance phase: check --strict verifies four deterministic phases: [topology] rules (port-placement-mapped, sovereignty-by-data-class [CRITICAL], trace-export-decision, usage-registry-present), each proving a traced placement decision, never a real infra state.

Rules 54 → 58. Deterministic, zero-LLM gate; never a runtime. Full CHANGELOG: https://github.com/stranxik/runward/blob/main/CHANGELOG.md