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.