Prepare the v1.4.0 release and stop stale completions projecting complete

[devin-ai-integration]

Closes #912. Part of #901. Depends on #911.

Summary

• Current release becomes 1.4.0 in pyproject.toml, src/code_mower/__init__.py, materialized builder-provenance.yml.j2 templates, current install pins and release claims across the docs, and the release-hygiene assertions. v1.3.1 release notes, qualification records, and other historical statements stay historical.

• The committed code-mower-package-manifest.json is a current package surface, so its stale package.version (0.5.0b53) becomes 1.4.0. Release hygiene and release-readiness now fail when it disagrees with either source version:

  committed-package-manifest-version: code-mower-package-manifest.json=1.4.0,
    src/code_mower/__init__.py=1.4.0, pyproject.toml=1.4.0 -> pass
  

• New docs/v140-release-notes.md plus CHANGELOG.md and docs/release-history.md entries covering the whole v1.3.1..v1.4.0 delta: optional Devin peer participation with the local/hosted setup, readiness, lifecycle, work-order, context-delivery, review-evidence, and recovery work; the bounded optional Graphify provider with its revision-bound local graph and no default dependency; and the Slack command and authenticated-ingress foundation, described as a foundation for later worker delivery rather than a completed Slack integration. README and docs/current-state-and-roadmap.md posture rows follow. Claude + Codex remain the first-run default and Devin stays optional.

• Release hardening in DevinWorkOrders: a persisted completion rejection no longer coexists with a complete session projection, which could make an orchestrator stop polling an active fix round.

  if record.get("completion_rejection") is None or result.get("state") != "complete":
      return result
  return public_projection({**result, "state": "running",
                            "reason": "result_not_ready", "next_action": "status"})

  Only the returned logical projection is copied. The authoritative rejection block (state: rejected, a bounded reason such as stale_completion, next_action: collect_after_provider_update), the durable remote record, shared RemoteSessions result precedence, and exact-round, issue, repository, branch, author, PR, head-SHA, and base-branch verification are unchanged; no raw structured output is inspected or exposed and no provider work is retried or created. A later valid exact-round collection clears the rejection and returns verified PR evidence.

• docs/devin-peer-support-qualification.md corrections found after Add Devin peer-support qualification scorecard #958 merged: the round-0 local build/twine check result is separated from GitHub CI; CI coverage is stated exactly (editable installs on 3.12/3.13/3.14; release readiness, regular base install, easy-mode smoke, fresh-clone rehearsal, and package-install rehearsal on 3.12 only; PR CI does not run Twine), so no fresh-wheel or Twine claim spans every matrix version; the Board/cloud section moves from pending to the completed trusted-orchestrator evidence on Devin: peer-support qualification and public scorecard #911 (exact-main Board privacy/gate inspection passed; one zero-report board_snapshot event with no report text); and the PACKAGE_FILES entry is described as changing generated standalone package materialization while docs stay outside the built wheel. The v1.4.0 hardening item above is recorded there too.

• Post-merge release steps (tag, release.yml runs, TestPyPI/PyPI publication and rehearsals, artifact SHA-256 comparison and GitHub Release, local installation, published-package campaign, Board restart, CodeMower.com metadata upload) are documented in the release notes with their expected evidence and left to the orchestrator.

Validation

From this clean release checkout on Python 3.12:

• unittest discover -s tests: 3253 tests, 18 skipped, OK.
• ruff check ., privacy_scan.py, compileall -q src scripts, smoke_easy_mode.py --json: clean.
• release-readiness --json: pass, 15/15 checks, version 1.4.0, spec code-mower==1.4.0, tag v1.4.0.
• package-install-rehearsal --package-spec . --work-dir /tmp/code-mower-v140-local-rehearsal --json: pass, reported code-mower 1.4.0.
• python -m build then twine check dist/*: sdist and wheel PASSED (local result; PR CI does not run Twine).
• fresh_clone_rehearsal.py at this exact head: pass; doctor --adoption --json from that fresh clone: 56 checks, 0 failures.

CI, the package matrix, and code-mower/gate run on the exact head; their results are the authoritative record.

Risk / Rollback

• Release metadata and documentation changes are revertible with the branch. The behavioral change is confined to the returned work-order session projection; durable remote records, result precedence, and every verification path are untouched, so a revert restores the previous projection only.

Data Or Secret Exposure

• This change does not add source, raw diffs, raw transcripts, raw provider output, tokens, or machine-specific paths to public artifacts.

Link to Devin session: https://app.devin.ai/sessions/b67c789defa644749e1396ab6900244e
Open in Devin Desktop: https://app.devin.ai/desktop/session/b67c789defa644749e1396ab6900244e?variant=devin

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[jeffhuber]

Codex audit (merge-authority lane)

Head SHA: 36b2c1577224e41ac9979dce3a1efe58fad9f959
Findings: P0=0, P1=0, P2=1, P3=0 (blocker policy: any P0/P1/P2 → BLOCKED)

Codex Audit: BLOCKED

Summary:

The executable release runbook aborts during the Board restart stage because its fresh clone never receives the newly created release tag.

Findings:

• [P2] Fetch the release tag into the fresh checkout before checking it -- /private/var/folders/f2/g9zqfdjx7z3ckcsx_f46htwm0000gn/T/codex-audit-p7d9m0h8/wt/docs/pypi-release.md:1072
  Finding ID: codex:7e08419ac0c9e4445f8e
  Following the runbook in order creates $RELEASE_CHECKOUT before v1.4.0 exists, then creates and pushes the tag from the original repository in step 3. Nothing subsequently fetches that tag into the fresh clone, so this rev-list fails and set -e aborts step 15 before the Boards restart. Fetch the release tag into $RELEASE_CHECKOUT before asserting its target.

[jeffhuber]

Claude audit (merge-authority lane)

Head SHA: 36b2c1577224e41ac9979dce3a1efe58fad9f959
Findings: P0=0, P1=0, P2=0, P3=0 (blocker policy: any P0/P1/P2 -> BLOCKED)

Claude Audit: PASS

Summary:

Large v1.4.0 release-prep PR (Devin-authored, not a Claude branch, so independence guard does not apply). Reviewed the core runtime change (DevinWorkOrders stale-completion projection fix), cloud_client manifest/identity/provenance hardening, release workflow SHA-binding gate, and version-consistency tooling. The stale-completion fix correctly persists the rejection before releasing the compare-bound result (verified against the added KeyboardInterrupt-interruption test), and the new cloud upload/identity/checkout-provenance checks are defensive improvements with matching test coverage. No correctness, security, or data-loss regressions found in the reviewable diff.

Findings: none.

[devin-ai-integration]

Codex P2 (codex:7e08419ac0c9e4445f8e) fixed in 0ce1bb1b2c9fbeb1c38952351f4ee13aed753fb6.

Step 15 now fetches the published tag into the fresh clone before asserting its target:

git -C "$RELEASE_CHECKOUT" fetch --no-tags origin "+refs/tags/v1.4.0:refs/tags/v1.4.0"
test "$(git -C "$RELEASE_CHECKOUT" rev-list -n 1 v1.4.0)" = "$RELEASE_SHA"

Both commands are now required release-readiness assertions, with tests that the fetch precedes the rev-list assertion and that readiness fails if the fetch is removed. Evidence: release hygiene 345 passed / 769 subtests, readiness pass 20/20, ruff on changed Python and git diff --check clean.

[jeffhuber]

Codex audit (merge-authority lane)

Head SHA: 0ed457732b740984bb9d075c06176337b1cd91e3
Findings: P0=0, P1=0, P2=1, P3=0 (blocker policy: any P0/P1/P2 → BLOCKED)

Codex Audit: BLOCKED

Summary:

Strict Board snapshots fail from repository subdirectories because the clone source is not normalized to the repository root.

Findings:

• [P2] Resolve the Git root before cloning the snapshot source -- /private/var/folders/f2/g9zqfdjx7z3ckcsx_f46htwm0000gn/T/codex-audit-eedqzp2c/wt/src/code_mower/cloud_client/git_metadata.py:154
  Finding ID: codex:e1150d38b13e28fec2ce
  When cloud board-snapshot --require-clean or --require-head-sha runs from a repository subdirectory without an explicit --repo-path, the default path is that subdirectory. The provenance checks succeed because Git discovers the enclosing repository, but git clone requires its source argument to identify a repository and fails on the subdirectory. Resolve the enclosing Git top-level directory before materializing the commit so strict snapshots work from the same checkout locations as the initial checks.

[jeffhuber]

Claude audit (merge-authority lane)

Head SHA: 0ed457732b740984bb9d075c06176337b1cd91e3
Findings: P0=0, P1=0, P2=0, P3=2 (blocker policy: any P0/P1/P2 -> BLOCKED)

Claude Audit: PASS

Summary:

Large v1.4.0 release-prep PR (Devin-authored, branch devin/912-release-v1.4.0). Core behavioral fix in devin_work_orders.py (stale-completion rejection no longer projects a "complete" session) is correctly implemented, ordered for crash-safety, and covered by targeted tests. Extensive new cloud-upload identity/provenance verification (bundle manifest digest binding, cloud profile identity checks, git checkout provenance) is defense-in-depth, consistently applied across cloud.py/operations.py/release_campaigns.py, and backed by substantial new tests. The bulk of the diff is documentation/version-bump churn and an elaborate self-verifying release runbook (release_readiness.py doc-lint assertions), which is unusual but not functionally risky since it only gates CI/release readiness, not runtime behavior. No P0/P1/P2 correctness, security, or data-loss issues found in the shipped code paths.

Findings:

• [P3] Release workflow hardcodes the current release tag in a reusable gate -- .github/workflows/release.yml:15
  Finding ID: claude:6d6e83750a5c1dccd62e
  The new release-identity job asserts test "$ACTUAL_REF" = "refs/tags/v1.4.0" as a literal string inside the general-purpose release.yml workflow used for every future release. Unless this literal (and the matching hardcoded check in release_readiness.py's _dispatch_sha_gate_holds) is updated on every subsequent release, manual workflow_dispatch publishing (the path used in the documented runbook) will fail closed for v1.4.1/v1.5.0/etc. This appears consistent with the repo's established convention of hardcoding per-release version strings throughout docs and tests, so it is likely intentional/expected process rather than an oversight, but it is a real forward-compatibility footgun worth flagging.
• [P3] resolve_cloud_identity now rejects explicit team/install overrides that disagree with a stored profile -- src/code_mower/cloud_client/tokens.py:330
  Finding ID: claude:d2aeae1d5d99d81ef78a
  Previously an explicitly passed --team-id/--install-id (or env var) always won over a resolved install-profile's stored values. Now require_cloud_profile_identity raises CloudBundleError when both are non-empty and disagree. This is a deliberate security hardening (prevents a swapped profile from silently redirecting an explicitly-identified upload) and is well tested, but it changes behavior for any legitimate workflow where an operator intentionally overrides team/install id on top of a different stored profile (e.g. multi-team dogfood/catch-up uploads from one machine).

[devin-ai-integration]

Codex P2 codex:e1150d38b13e28fec2ce fixed in 8aef767c423ac71fbf0f18eb521c4c0a222475fe: materialized_commit_source now resolves the enclosing Git top-level with git rev-parse --show-toplevel and clones from that root, so strict --require-clean/--require-head-sha snapshots work from a repository subdirectory exactly where the provenance checks already succeed. Added test_board_snapshot_materializes_from_a_repository_subdirectory, which collects with repo_path set to a nested subdirectory and proves the materialized source is used and reports the exact required commit.

The two Claude P3 notes are left as-is: the hardcoded v1.4.0 tag assertion matches this repo's per-release version-pinning convention (and is part of the requested expected_sha gate), and the stricter resolve_cloud_identity conflict rejection is the explicitly requested hardening for this release.