Modern software engineering increasingly spans dozens of repositories, each representing a microservice, library, or infrastructure component. Coordinating changes across these boundaries while maintaining speed, safety, and auditability has become a daunting challenge for many organizations. Traditional CI/CD pipelines often assume a monorepo or tight coupling to a specific cloud provider, leaving teams that prefer a decentralized, polyglot ecosystem struggling with fragmented tooling and manual handoffs. DyroEngineeringFlow steps into this gap by offering a local‑first automation and delivery control platform that treats the engineer’s workstation as the central hub for orchestrating multi‑repository workflows. Rather than pushing complexity onto remote servers or proprietary SaaS platforms, Dyro keeps the decision‑making, policy enforcement, and state tracking close to the source code, enabling teams to retain full ownership of their processes while still benefiting from sophisticated automation.
At its heart, DyroEngineeringFlow introduces a set of composable primitives that mirror the lifecycle of a software change: development lines, Git worktrees, agent launchers, task gates, independent review mechanisms, and merge audits. Development lines act as long‑running branches that isolate workstreams without polluting the main history, while Git worktrees allow simultaneous checkout of multiple commits from the same repository, facilitating parallel experimentation. Agent launchers encapsulate the invocation of any external tool—whether a language model, a linter, a test runner, or a custom script—behind a uniform interface that Dyro can control and monitor. Task gates serve as programmable checkpoints that must be satisfied before a piece of work can advance, ensuring that quality, security, and compliance criteria are never bypassed. Independent review and merge audit provide immutable records of who approved what and why, creating a traceable chain of custody for every change that reaches production.
What truly differentiates Dyro is its profile‑driven architecture. Each team maintains a dyro.toml file that declares the repositories involved, the layout of workspaces, the adapters that connect to external agents, and the delivery policies that govern execution, review, and sign‑off. Crucially, business rules, model cost estimations, and release practices reside entirely within this profile, meaning that Dyro itself remains agnostic to any particular AI framework, cloud vendor, or domain‑specific convention. This separation of concerns ensures that the core engine—responsible for workspace management, launching agents, dispatching tasks, verifying outcomes, and merging changes—can evolve independently while teams retain the freedom to tailor behavior to their unique contexts. The profile is versioned alongside the code, making it trivial to audit policy changes over time and to reproduce historic builds with exact fidelity.
Getting started with Dyro is deliberately frictionless and safety‑oriented. The recommended installation path uses pipx to create an isolated Python environment, guaranteeing that the CLI does not interfere with existing project dependencies. Once installed, invoking dyro from any directory that contains Git repositories—or even from an empty folder—triggers a guided first‑run experience. This guide scans the local filesystem, proposes a workspace‑relative layout, and outlines precisely what actions it will take: creating a profile, cloning missing remotes, establishing the first development line, or registering a detected agent adapter. Importantly, the guide never writes anything until the user explicitly confirms; it also refrains from altering the original repositories, instead opting to create a sibling Dyro workspace when invoked from a repository root. This conservative approach eliminates the fear of accidental data loss and encourages experimentation.
After the initial setup, Dyro records a reversible global home for each project, allowing the same dyro command to resume a recent development line, hotfix, or existing task worktree from any location on the filesystem—no need to remember cumbersome –root flags. Projects can also be explicitly registered, selected, and inspected through dedicated subcommands that manipulate only these global entry points, leaving the underlying workspaces untouched. The task open command, for example, validates the anchor and branch topology of an existing worktree before granting access, ensuring that engineers never accidentally diverge from the intended lineage. Meanwhile, agent discover distinguishes between adapters that have been formally approved in the profile and mere executable commands that happen to be present on the path, preventing unauthorized tooling from slipping into the workflow.
When it comes to executing a release or addressing a production incident, Dyro enforces explicitness at every step. A hotfix must declare its verified production base rather than implicitly inheriting the default branch, guarding against the common pitfall of branching from an outdated or unstable state. For teams that rely on external systems to perform the actual execution or approval steps, Dyro offers an external execution mode. By setting policy.execution_mode to “external” and policy.require_external_signoff to true, the local Dyro instance restricts itself to planning activities only; a task cannot be marked as done until a trusted external runner returns a signed receipt that matches the exact task HEADs. This model supports sophisticated split‑responsibility architectures while preserving the immutable audit trail that Dyro generates internally.
Evidence collection is a cornerstone of Dyro’s trust model. Every successful execution yields an evidence bundle that must contain a provenance.json file, cryptographically linking the bundle to the specific task, agent, and runtime conditions that produced it. Importing legacy bundles that predate this provenance requirement is treated as a deliberate migration action, requiring an explicit flag to acknowledge the reduced guarantees. If an external runner encounters a situation where it cannot determine the outcome autonomously, it may return a QUESTION state; Dyro then provides a dedicated command to record the human‑supplied answer, preserving the original claim and returning the task to the assigned queue for the next evidence submission. This mechanism ensures that uncertainty is captured, tracked, and resolved without losing the context of prior attempts.
Beyond collection, Dyro provides robust facilities for inspecting and retaining immutable evidence generations. Engineers can browse historic bundles, verify their signatures, and confirm that no tampering has occurred since creation. To underpin these guarantees, cryptographic identities for runners and approvers are generated outside the workspace, with only the public keys imported into purpose‑separated trust stores. This separation minimizes the risk of key leakage and simplifies rotation procedures. The local trust audit chain can then be synchronized to an independent Witness service, which acts as a tamper‑evident log that validates the sequence of events, rejects any attempts to fork or replay outdated checkpoints, and writes verifiable receipts to immutable storage.
The Witness implementation shipped with Dyro is a deployable standard‑library service that enforces strict integrity controls. By default it requires a bearer token and TLS, advancing its checkpoint only after successfully persisting a batch file named records/
Signature enforcement within Dyro is governed by three explicit policy flags: policy.require_signed_execution, policy.require_signed_review, and policy.require_signed_signoff. Deleting every trusted key never disables an enabled policy; instead, the system simply refuses to proceed until valid signatures are presented. Signed execution claims bind together a claim ID, generation number, runner identifier, and the specific execution key used, while the actual signature messages and execution plan hashes are computed using RFC 8785 JSON Canonicalization Scheme bytes. This choice ensures that any external runner—whether written in Python, Node.js, Go, or Rust—can reproduce the exact signed payload by following the same canonicalization steps, fostering true interoperability. Independent reviewers produce a signed JSON envelope via the dyro task evidence review‑build command, and key rotation is designed to be non‑disruptive: the new key ID is trusted before the switch, the old key is retained during an overlap window, and finally revoked through the workspace’s controlled key‑management process.
To illustrate these principles in action, the repository includes a minimal TypeScript reference signer and a Python/Node interoperability example located in examples/typescript‑runner/. This sample walks through the exact canonical byte construction, signature domain definition, Ed25519 signing call, and envelope format expected by Dyro’s control plane. By providing a concrete, runnable reference, the project lowers the barrier for teams wishing to integrate custom agents or external approval systems while guaranteeing compliance with the platform’s security contract. Every write‑capable operation in Dyro also offers a planning mode, allowing teams to preview the effects of a command—such as creating a new development line or registering an agent—without persisting any state, further reinforcing the safety‑first ethos that permeates the tool.
In the broader landscape of developer tooling, DyroEngineeringFlow carves out a niche that distinguishes it from both pure agent‑orchestration frameworks and knowledge‑graph/RAG stacks. While some discussions label multi‑node agent/work topologies as “Graph Engineering,” Dyro’s delivery topology—comprising a TaskGraph, state machine, gates, review, merge, and an optional dispatch subgraph—is best understood as a delivery control plane. The optional local dispatch harness, accessible via dyro dispatch …, remains purely advisory; it never supersedes the mandatory gates, review, sign‑off, or merge steps that guarantee correctness. Local multi‑repository merges are preflighted and recovered as a single atomic operation, acknowledging that remote Git servers cannot provide cross‑repository push atomicity, and therefore any partial failure is recorded for systematic recovery. Automatic merge is only permitted when both the task manifest and the local policy explicitly grant permission, ensuring that no change can slip through without proper oversight.
Adopting DyroEngineeringFlow can yield tangible benefits for teams seeking to improve release predictability, reduce integration friction, and strengthen compliance posture. To begin, evaluate your current multi‑repository pain points—such as inconsistent branching strategies, opaque approval processes, or difficulty reproducing past builds—and map them to Dyro’s core concepts. Start with a pilot project that contains a modest number of services, install dyro via pipx, and run the first‑run guide to establish a baseline profile and workspace. Use the planning modes extensively to validate proposed changes before committing them, and gradually introduce external agents or Witness services as your confidence grows. Finally, institute regular retrospectives that examine the evidence bundles and audit logs generated by Dyro, using those insights to refine your policy.tomon and continuously elevate the quality and reliability of your delivery pipeline.