DevRelay v0.5.1

DevRelay v0.5.1 — release notes

Status: PUBLISHED 2026-10-29. Tag v0.5.1 peels to
9135150883a423b9ea18749d752ff033dc47b1c6; PyPI and the GitHub Release are
public. Evidence is recorded in RELEASE_CHECKLIST.md.

Highlights

v0.5.1 is a patch release on top of v0.5.0. It closes
the 0.5.0 known limitation where a run could not switch again after its switch
target lease had been released through generic lease recovery:

• POST /api/runs/{run_id}/session/lease/reattach (role,
  expected_updated_at, confirm: "apply", header X-DevRelay-Confirm: apply)
  gives the run's current role session an active lease again and releases any
  other active lease left for the same run/role (the orphaned source) in the same
  write. The run can then switch again.
• Refused, with nothing written, for a terminal run (run_terminal), a stale
  revision (run_changed), an unresolved switch (switch_pending), a session
  that already holds the lease (lease_already_active) or a session leased by
  another run (session_leased).
• GET /api/runs/{run_id} reports role_leases per role, and the WebUI run
  detail shows a confirmed Re-attach lease control.

Install / upgrade

• PyPI: python -m pip install devrelay==0.5.1
• GitHub Release: wheel, sdist, SHA256SUMS,
  DevRelay-Portable-Windows-x64.zip, DevRelay-SBOM.cdx.json

The portable zip is unsigned. Extract it as a whole and verify SHA256SUMS
before running devrelay.exe.

Security notes

• Re-attachment performs no provider I/O and writes no run document; the session
  id comes from the run document, never from the client.

Known limitations

Unchanged from 0.5.0 except the closed re-attachment item:

• adopt_completed_turn stays disabled. v0.3-E platform gates:
  G0.1/P7, G0.2, G0.3/P5 PASS; G0.4/P4 authoritative FAIL / P4 UNPROVEN
  (confirmed by the 2026-10-29 rerun); G0.5/P6, G1, G2 NOT RUN.
• Switch run write and lease commit are not one cross-store transaction; a
  failure between them needs the explicit resolve action.
• One Web writer and one MCP surface per workspace; active project selection is
  in-memory; advisory hold is not a provider pause; interrupt is still an abort.
• No .exe installer, code signing, winget/scoop or auto-update.

Verification

Recorded in RELEASE_CHECKLIST.md § v0.5.1.

devrelay v0.5.0

DevRelay v0.5.0 — release notes

Status: RELEASE CANDIDATE (2026-10-29). Not published until the tag,
draft Release, release.yml run and PyPI upload are recorded in
RELEASE_CHECKLIST.md § v0.5.0.

Highlights

v0.5.0 is the post-v0.4 hardening line on top of the v0.4 Web control plane:

• Supply chain: CycloneDX 1.5 SBOM for the portable runtime closure, a
  five-asset release gate (wheel, sdist, SHA256SUMS, portable zip, SBOM),
  Node.js 24 action pins, published-version reruns that skip the Windows
  rebuild, and a Windows/Python 3.13 release lock with a passed double-build
  proof.
• Durable run controls: manual-prompt pending markers survive restarts
  (metadata only) with a confirmed recovery action; an advisory run hold blocks
  new web prompts and MCP implementer/reviewer actions.
• Session ownership: durable session leases acquired at
  devrelay_start_run, released on terminal outcomes, with explicit recovery.
• Session switch (v3 run schema):
  • POST /api/runs/{run_id}/session/switch verifies the target belongs to
    the workspace, holds a pending target lease, appends validated
    session_switch_history evidence and atomically commits the lease;
  • WebUI run-detail switch panel with explicit confirmation and no automatic
    retry;
  • POST /api/runs/{run_id}/session/switch/recover resolves a
    pending/uncertain switch from the durable run document (commit or abort),
    failing closed on any mismatch.

Install / upgrade

• PyPI: python -m pip install devrelay==0.5.0
• GitHub Release: wheel, sdist, SHA256SUMS,
  DevRelay-Portable-Windows-x64.zip, DevRelay-SBOM.cdx.json

The portable zip is unsigned. Extract it as a whole and verify SHA256SUMS
before running devrelay.exe.

v1/v2 run documents stay readable; only v3 runs can carry switch history.
There is no automatic migration.

Security notes

• Every new write endpoint requires X-DevRelay-Confirm: apply plus a body
  confirm: "apply"; session ids come from the run or are verified by the
  OpenCode bridge, never trusted from the client.
• Lease and switch recovery perform no provider I/O; switch recovery writes no
  run document.
• Markers, holds and leases store metadata only — no prompt text, replies or
  tokens.

Known limitations

• adopt_completed_turn stays disabled. v0.3-E platform gates:
  G0.1/P7, G0.2, G0.3/P5 PASS; G0.4/P4 authoritative FAIL / P4 UNPROVEN;
  G0.5/P6, G1, G2 NOT RUN.
• Switch run write and lease commit are not one cross-store transaction; a
  failure between them needs the explicit resolve action. A run whose switch
  target lease was released by generic lease recovery before the resolve
  endpoint existed cannot switch again without manual lease re-attachment.
• One Web writer and one MCP surface per workspace; multi-process writers are
  unsupported.
• Active project selection is in-memory; advisory hold is not a provider pause;
  interrupt is still an abort.
• No .exe installer, code signing, winget/scoop or auto-update; the portable
  build has no hash-pinned wheelhouse or cross-runner reproducibility guarantee.

Verification

Recorded in RELEASE_CHECKLIST.md § v0.5.0.

devrelay v0.4.0

DevRelay v0.4.0 — release notes

Status: PUBLISHED 2026-10-22. Tag v0.4.0 peels to
c3a54162547cb810e454c498ee05f8eac33c99ae; PyPI and the GitHub Release are
public. Evidence is recorded in RELEASE_CHECKLIST.md.

Highlights

v0.4 adds a local, auditable Web control plane on top of the accepted v0.3
orchestration core:

• A — Local HTTP API / config write: loopback-only Starlette/uvicorn,
  bearer + X-DevRelay-Session auth, Host/Origin validation, bounded bodies,
  digest/confirmation/backup/atomic config writes, and wiring edits limited to
  a loopback OpenCode base URL.
• B — WebUI: no-build static UI with fragment-token login, configuration
  form, read-only wiring/MCP/credential-name display, status and recent runs.
• C — Run/task control plane:
  • read-only run/task artifact dashboards (C1/C2a);
  • decide and role-scoped interrupt (C2b);
  • one bounded manual prompt and normalized message polling (C2c).
• D1 — Project/session management: registered-project activation and a
  run-recorded session inventory.
• E1 — Packaging: unsigned PyInstaller portable Windows x64 zip built from
  the release tag, checksummed, attached to the draft and required before
  publication. The .exe installer is explicitly deferred.

Pause is not implemented: the accepted state machine has no pause state;
interrupt is an abort, not a pause.

Install / upgrade

Published artifacts:

• PyPI: python -m pip install devrelay==0.4.0
• GitHub Release: wheel, sdist, SHA256SUMS,
  DevRelay-Portable-Windows-x64.zip

The portable zip is unsigned. Extract it as a whole and verify SHA256SUMS
before running devrelay.exe; it does not install a service or modify PATH.

Security notes

• WebUI binds loopback only; sessions ride X-DevRelay-Session, not cookies.
• Config/wiring writes require X-DevRelay-Confirm: apply, a current digest
  where applicable, secret scanning, a cross-process lock and atomic replace.
• Run decision/interrupt/prompt require explicit confirmation; roles/session
  ids come from the run, never from the client.
• Task text, review evidence and provider messages are bounded/redacted; no
  token/cost values or raw provider bodies are exposed.
• The portable build is unsigned; code signing remains deferred.

Verification

• Full offline suite: 1,345 collected — 1,343 passed + 2 environment skips
  on Windows; CI test.yml 8/8 on commit c3a5416.
• Release workflow tests: tag/PyPI/draft gates, portable job, four-asset gate,
  provenance and SHA pins.
• Release workflow
  39858586636:
  both jobs succeeded; the Windows runner built the portable zip and the publish
  job verified its commit provenance.
• Downloaded-asset verification: SHA256SUMS matched all three artifacts;
  extracted devrelay.exe version reported devrelay 0.4.0; a fresh venv
  installed the published wheel and reported 0.4.0.
• The Windows runner/portable job has now run against the real v0.4 tag.

Known limitations

• No pause; no WebSocket/SSE live stream (normalized polling only).
• No OpenCode session switching/ownership transfer.
• Active project selection is in-memory and lost on restart.
• Manual-prompt pending marker is process-local; the CLI can still start turns.
• Portable build is not byte-reproducible; no SBOM/lock is bundled.
• No .exe installer, code signing, winget/scoop manifest or auto-update.
• Actions still emit Node.js 20 deprecation warnings; bumping the pinned action
  SHAs is a post-release hardening item.
• The release workflow/portable job succeeded on the first real v0.4 tag; a
  future failure must still leave the Release as a draft and be fixed/re-run.

Publication evidence

See docs/RELEASE_CHECKLIST.md § v0.4.0. The owner created the annotated tag,
draft Release and dispatched release.yml with tag=v0.4.0 and
confirm=PUBLISH; the AI recorded and verified the evidence.

devrelay v0.3.0

0.3.0 - 2026-10-21

Earlier entries record the status at their date.

Version 0.3.0 is single-sourced in pyproject.toml and in the
src/devrelay/__init__.py fallback constant, and is what devrelay version
reports. The tag-driven workflow in .github/workflows/release.yml publishes
this release (2026-10-21); publication results are recorded in
docs/RELEASE_CHECKLIST.md.

Added

• The v0.3 stage series is in the package: the OpenCode session bridge (v0.3-A),
  the ChatGPT/MCP stdio tool surface (v0.3-B), semantic agent role routing
  (v0.3-C), bounded orchestration (v0.3-D) and the v0.3-E mandatory fail-closed
  recovery core (local read-only reconciliation plus a one-shot
  mark_unrecoverable).
• devrelay mcp serve --workspace <project> exposes 19 MCP tools over the
  official MCP Python SDK: eleven devrelay_* tools (including
  devrelay_reconcile_run and devrelay_resolve_recovery) and eight
  opencode_* tools.
• Offline CI (.github/workflows/test.yml, Python 3.11-3.14 on Linux and
  Windows) and a tag-driven release workflow
  (.github/workflows/release.yml).

Changed

• Package version 0.1.0 -> 0.3.0 (pyproject.toml,
  src/devrelay/__init__.py); tests/test_version.py pins the release version
  to the packaged one. The MCP server banner keeps its own 0.3.0-e
  identifier.
• The sdist ships the packaged policy profiles
  (recursive-include src/devrelay/profiles *.yaml in MANIFEST.in).
• Recovery: adoption is refused structurally before any run mutation; a terminal
  run is refused as orchestration_invalid_transition before the
  adoption-disabled check.
• Recovery: the recovery reason is derived from the strict local ledger scan
  (W3/W4 submission_uncertain, W5/W6 reply_pending) rather than from bridge
  flags alone.
• The orchestration store now fsyncs a run document's temp file before
  os.replace (and the parent directory on POSIX); Windows cannot fsync a
  directory, so cross-power-loss rename durability is not claimed there, and the
  OpenCode call ledger still does not fsync.

Security

• Publishing uses PyPI trusted publishing (GitHub OIDC, pypi environment, no
  stored credentials, attestations enabled). The workflow validates the tag
  shape, pins the tag to the packaged version, requires the tag to be reachable
  from origin/main, requires a draft GitHub Release whose built artifacts
  the workflow uploads (the Release is undrafted only after PyPI and the three
  assets verify), and passes workflow_dispatch inputs to the shell only
  through environment variables.
• The Codex child keeps its explicit credential denylist (reviewer credentials,
  DEVRELAY_OPENCODE_TOKEN and common provider keys) - an explicit denylist,
  not general secret isolation.

Known limitations

• v0.2-A (automatic review loop), v0.2-B (project profiles / frozen-policy
  integrity) and v0.2-C (structured Codex runtime) remain candidates under
  independent review; they were validated offline with fake providers only.
• v0.3-A to v0.3-D are accepted internally and closed, and shipped in 0.3.0.
• v0.3-E is scoped to the mandatory fail-closed core: adopt_completed_turn
  stays DISABLED, there is no automatic resume, and remote correlation was
  never exercised. The OpenCode call ledger assumes a single writer and
  issues no fsync, so durability against power loss is not claimed there (the
  orchestration store now fsyncs — see Changed above).
• The platform proof gate stays partially executed / not complete:
  G0.1/P7 = PASS, G0.2 = PASS, G0.3/P5 = PASS, G0.4/P4 = authoritative FAIL /
  P4 UNPROVEN (no OpenCode base endpoint in the accepted workspace, 0 GET /doc
  issued), G0.5/P6 = NOT RUN, and G1/G2 not run.
• The offline test suite is 1,271 tests (python -m pytest -q; 1,270 pass and
  one POSIX-only test is skipped on Windows); it needs no model, no network and
  no installed Codex CLI.

DevRelay v0.1.0

DevRelay v0.1.0

First public release of DevRelay.

DevRelay is a local AI coding orchestrator that coordinates a structured development pipeline:

Plan
→ Implement
→ Test
→ Review
→ Fix
→ Final Gate

Highlights

• Official Codex CLI implementation provider
• Works with Codex authenticated through a user's ChatGPT subscription
• No OpenAI API key required for the Codex CLI path
• Persistent resumable task state
• Dirty-workspace task baselines
• Task-relative Git diffs
• Git repository policy guards
• Interrupted-provider recovery
• Manual and OpenAI-compatible reviewer workflows
• Reviewer-facing secret redaction
• Human-readable audit artifacts

Validation

• 149 automated tests
• Independent release audit and closure audit
• Real end-to-end Codex CLI smoke test
• Dirty-workspace attribution verified
• Fresh wheel installation verified

Known limitations

• One active task / Codex implementer in v0.1
• No MCP or Web UI yet
• Push prevention is provider-limited
• Secret redaction is best-effort and not a DLP system
• Structured Codex event parsing planned for a later release

See CHANGELOG.md for details.