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

[devin-ai-integration]

Part of #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).

[jeffhuber]

Work Order: reject exact-commit materializations whose tracked symlinks escape the private checkout

Take over this single bounded fix at exact head 4b66f2077aab7a13206167576ec95d278c70c13c after the Devin writer completed.

A peer review reproduced that materialized_commit_source() checks out tracked symlinks, _set_tree_permissions() skips them, and Board reads code-mower.yml through the symlink. An external target can change while HEAD and clean provenance remain unchanged, violating the strict exact-commit claim.

Acceptance criteria:

1. Validate the materialized tree after checkout and before any consumer can read it.
2. Fail closed with a bounded CloudBundleError for any symlink whose resolved target escapes the materialized worktree or enters its .git metadata; dangling links must also fail closed.
3. Preserve ordinary tracked symlinks that resolve to safe paths inside the worktree, unless a narrower documented policy is required for correctness.
4. Add regression tests covering external absolute/relative escape, .git escape, dangling targets, and a safe internal symlink.
5. Run the focused cloud/Board tests, git diff --check, and release readiness. Commit and push only this fix to the existing PR branch, then report the exact head and evidence.

Do not perform release, tag, publish, merge, credential, or Board restart actions in this fix round.

[jeffhuber]

Mac lane runner: accepted an explicit recovery handoff.

• source lane: devin
• destination lane: codex
• target PR: Prepare the v1.4.0 release and stop stale completions projecting complete #959
• expected head: 4b66f20

Single-writer enforcement is otherwise unchanged.

[devin-ai-integration]

Devin lane standing down per the recovery handoff (devin → codex) at expected head 4b66f2077aab7a13206167576ec95d278c70c13c. I had started the tracked-symlink escape fix in materialized_commit_source() and have fully reverted that in-progress local edit, so the branch and my working tree are both exactly 4b66f2077aab7a13206167576ec95d278c70c13c with nothing uncommitted and nothing pushed. The symlink work order is handed to the codex lane; for reference, my intended shape was a post-checkout _reject_escaping_symlinks(source) validation run before permission hardening and before yielding, failing closed with a bounded CloudBundleError on targets that resolve outside the materialized worktree, into its .git metadata, or dangle, while preserving symlinks that resolve inside the worktree.

[jeffhuber]

Codex fix round: needs owner action

PR: #959
Verified PR head: 4b66f2077aab7a13206167576ec95d278c70c13c

I verified the trusted symlink-validation work order and the explicit Devin → Codex recovery handoff. The sandbox then blocked the required branch setup before any product edits:

git fetch --no-tags origin refs/heads/devin/912-release-v1.4.0
error: cannot open '.git/FETCH_HEAD': Operation not permitted

The configured filesystem policy makes this checkout's .git read-only. The fetch failed, so the subsequent head assertion and branch checkout did not execute. The working copy remains at origin/main (7629993); no commit or push occurred. Per the run's sandbox-denial rule, I stopped without retrying or bypassing the restriction.

Owner action:

1. Configure the Mac lane runner's filesystem policy to permit normal Git metadata writes in /Users/jhuber/actions-runner/_work/lanes/codex/codemower-ai__code-mower/.git, preserving the pre-push single-writer guard and the accepted PR Prepare the v1.4.0 release and stop stale completions projecting complete #959 handoff.
2. Redispatch this bounded fix round against PR Prepare the v1.4.0 release and stop stale completions projecting complete #959, confirming its current head and retaining the symlink-validation acceptance criteria from the work order.

Validation: GitHub head/handoff and repository instructions inspected. Tests, git diff --check, and release readiness were not run because the target branch could not be checked out. All requested symlink validation and regression tests remain outstanding. Recorded .code-mower/lane-outcome.json with outcome owner_action in the working copy.

[jeffhuber]

Mac lane runner (codex): bounded delivery outcome owner_action on this pr.

Sandbox makes .git read-only, preventing checkout, commit, and push of the authorized PR #959 fix.

[jeffhuber]

Mac lane runner: accepted an explicit recovery handoff.

• source lane: devin
• destination lane: codex
• target PR: Prepare the v1.4.0 release and stop stale completions projecting complete #959
• expected head: 4b66f20

Single-writer enforcement is otherwise unchanged.

[jeffhuber]

Mac lane runner (codex): this run ended without a validated delivery. The unit stays open for the next cycle.

• provider exit: 2
• supervision: completed
• observed transition: none
• classification: provider_exit_nonzero

[jeffhuber]

Mac lane runner: accepted an explicit recovery handoff.

• source lane: devin
• destination lane: codex
• target PR: Prepare the v1.4.0 release and stop stale completions projecting complete #959
• expected head: 4b66f20

Single-writer enforcement is otherwise unchanged.

[devin-ai-integration]

Devin lane: the symlink-escape fix is implemented and fully validated locally, committed but not pushed, because the writer role is currently handed to the codex lane (which is blocked by its read-only .git sandbox). origin/devin/912-release-v1.4.0 is still exactly 4b66f2077aab7a13206167576ec95d278c70c13c.

Local commit 566cb2e22fd6fdcd1a0f21ee6ccc556829b84660 on top of the verified head:

• materialized_commit_source() now runs _reject_escaping_symlinks(source) after checkout/provenance and before permission hardening and before yielding, so no consumer can follow a link.
• Bounded, path-free CloudBundleError for any tracked symlink whose resolved target leaves the materialized worktree or enters its .git metadata, and for dangling targets (what they resolve to is not fixed by the commit).
• Tracked symlinks resolving inside the worktree are preserved and still readable.
• Regression tests: absolute escape, relative escape, .git escape, dangling target (each asserting the exact bounded message, no name/path disclosure, no leftover private root, and that the tree is never yielded), plus a safe internal symlink case.

Validation: focused cloud/Board/release-hygiene/campaign suites 942 passed (1195 subtests), Ruff on both changed files clean, git diff --check clean, code-mower migration release-readiness --json → pass 20/20.

Owner call needed: say the word and I'll push this from the devin lane (which has working Git), or I can leave it parked and hand the exact patch to codex once its filesystem policy is fixed. I did not push to avoid breaking the accepted single-writer handoff.

[jeffhuber]

Codex fix round: fixed

PR: #959
Head: a56b30949e61d5a8553b24989e6dc32ffb7187f3

Implemented the trusted symlink-validation work order on the existing branch under the explicit Devin → Codex recovery handoff.

materialized_commit_source() now validates the private checkout immediately after checkout and before any consumer receives it. Every step of symlink resolution must stay inside the source tree and outside its Git metadata; unresolved targets and cyclic/excessive chains fail with bounded CloudBundleError messages. Safe internal file, directory, absolute, and chained links remain intact. Validation failures retain cleanup and prevent Board collection or upload.

Changed only src/code_mower/cloud_client/git_metadata.py, tests/test_cloud_git_metadata.py, and tests/test_cloud_client.py. The documented policy also rejects intermediate external/Git-metadata traversal, even when the final destination is internal, because those routes cannot support the immutable-source claim.

Validation on Python 3.12.13/macOS, with PYTHONPATH="$PWD/src" explicitly binding commands to this checkout:

• python -m unittest discover -s tests -p test_cloud_git_metadata.py -v: 21 passed, including 16 new boundary tests.
• python -m pytest tests/test_cloud*.py tests/test_board*.py -q: 185 passed, 25 subtests passed; one importlib metadata deprecation warning in a Board lease test.
• python -m unittest discover -s tests: 3,391 tests run, OK, 11 skipped on the clean pushed commit (500.318 seconds).
• python -m code_mower.migration release-readiness --json: pass, 20/20.
• python -m ruff check ., python scripts/privacy_scan.py, python -m compileall -q src scripts, and git diff --check: passed.
• Easy-mode smoke: passed, 14 steps.

Regression coverage confirms rejected sources never reach the context consumer, the Board consumer, or upload; private checkouts are removed on rejection. Positive coverage confirms internal symlinks remain readable, read-only, and clean at the committed revision. Tests cover absolute/relative escapes, hidden directory links, Git metadata and case aliases, intermediate traversal, dangling targets, cycles, and invalid non-directory suffixes.

Pushed without force. Applied builder:codex, removed the stale Codex verdict label, and re-requested needs-claude-audit for this head.

GitHub CI on this head: Python 3.12, 3.13, and 3.14 package checks, aggregate package check, Linux containment, and macOS containment all passed.

Claude audit on this head: PASS, P0/P1/P2 = 0. Its two P3 observations concern existing release-tag literals in the workflow/readiness checks; those remain outside this bounded symlink fix.

Remaining: the separately requested Codex audit is pending (needs-codex-audit). The symlink work order has no outstanding implementation or validation items. The working tree is clean. No release, tag, publishing, merge, credential, or Board restart actions were performed.

[jeffhuber]

Devin CLI audit (informational only)

Head SHA: a56b30949e61d5a8553b24989e6dc32ffb7187f3

Devin CLI Audit Result — INCOMPLETE

Summary:

PR author 'devin-ai-integration[bot]' is excluded from the Devin CLI reviewer lane

[jeffhuber]

Claude audit (merge-authority lane)

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

Claude Audit: PASS

Summary:

Large release-preparation PR for v1.4.0 (Devin builder branch, not Claude — independence guard is not applicable). The functional changes are well-tested: the stale-completion session projection fix in devin_work_orders.py, the new release-identity SHA-binding gate in release.yml, PEP 440-aware version comparisons in migration_readiness.py/migration_install.py, and the cloud-upload identity/manifest-provenance binding in cloud_client/* all look correct and are backed by extensive new unit tests. No P0/P1/P2 correctness, security, or data-loss issues were found in the code changes; the bulk of the diff is documentation/version-bump churn. One minor maintainability note below is non-blocking.

Findings:

• [P3] Release-identity ref check hardcodes the current tag name -- .github/workflows/release.yml:21
  Finding ID: claude:c23a919fb29c791a48e4
  The new release-identity job checks test "$ACTUAL_REF" = "refs/tags/v1.4.0" as a literal string rather than deriving it from an input or a version-independent pattern (e.g. refs/tags/v*). Since this workflow file is not regenerated per release, every future release (v1.4.1, v1.5.0, ...) will need this line manually edited or the workflow_dispatch identity gate will always fail for that release. Given the repo's existing practice of manually bumping hard-coded version strings across dozens of docs each release, this is likely an expected edit point rather than an oversight, but it's worth flagging so it isn't missed for the next cut — a forgotten update fails closed (blocks the release) rather than silently, so it is low risk.
• [P3] Release-readiness self-test also hardcodes v1.4.0 in the same assertion -- tests/test_release_hygiene.py:3388
  Finding ID: claude:6b87e6e91054e4e2fdb2
_dispatch_sha_gate_holds's required_identity_fragments list embeds the literal test "$ACTUAL_REF" = "refs/tags/v1.4.0" string, so the test will need to be updated in lockstep with the workflow file for the next release tag — consistent with (and reinforcing) the note above about release.yml.