build(rake): `rake release` and `release:full` bypass the release lane the repo forbids, and `release:full` cannot even run

[ivndev001]

What to build

The repo's release invariant is "nobody tags a release — CI does, only after the gem is live" (RELEASE.md:14-30; CLAUDE.md:101 says never re-add a tag trigger). Two Rake entry points contradict it:

1. Rakefile:3 require 'bundler/gem_tasks' defines Bundler's release task, whose prerequisites are build, release:guard_clean, release:source_control_push (creates and pushes the v<version> git tag) and release:rubygem_push (pushes with a local API key). Running it from a checkout cuts a tag from a laptop before any gem exists on RubyGems — exactly the gem-less-tag failure RELEASE.md:102-127 documents. CLAUDE.md:33 still advertises it as the release command: "Release | bin/rake release (Vite build → vendor/assets/ → gem build → push)".
2. Rakefile:240-241 task full: ['frontend:build', 'build', 'push'] (documented at RELEASE.md:179-184 as the maintainers' fallback). It skips release:check and release:package entirely, and its third prerequisite push is not defined anywhere: grep -n "task.*push" Rakefile finds nothing, and bundler/gem_tasks defines build, install, install:local, release and release:* — no bare push. bundle exec rake release:full therefore aborts with "Don't know how to build task 'push'". A documented fallback that cannot execute is worse than none.

Fix:

• Keep build and install from bundler/gem_tasks but neutralise release: after the require, Rake::Task['release'].clear and redefine task :release to abort with a one-line message pointing at RELEASE.md ("releases are cut by CI from a lib/wurk/version.rb bump; see RELEASE.md"). Do the same for release:source_control_push and release:rubygem_push so nothing can tag or push from a checkout.
• Delete release:full (Rakefile:240-241). If a local emergency push is still wanted, the existing bin/gem-build + bin/gem-push pair already does it and bin/gem-push at least requires a built .gem; make bin/gem-push run bundle exec rake release:check before pushing so the fallback goes through the same gate.
• CLAUDE.md:33: replace the row with "Release | bump lib/wurk/version.rb + CHANGELOG, merge to main; CI publishes and tags (RELEASE.md)".
• RELEASE.md:179-184: rewrite the fallback section to name bin/gem-build / bin/gem-push and state that the gate runs first.
• Add a unit test (test/unit/release_helpers_test.rb or a new test/unit/rakefile_release_test.rb that loads the Rakefile in a subprocess) asserting rake release exits non-zero with the redirect message and that no task named release:full exists.

Acceptance criteria

• bundle exec rake release exits non-zero without creating a tag or touching RubyGems, and its message names RELEASE.md.
• bundle exec rake -T | grep release lists release:check and release:package only (plus the aborting release).
• bin/gem-push runs release:check before gem push.
• CLAUDE.md:33 and RELEASE.md no longer describe a local task that tags or pushes without the gate.
• A unit test covers the aborting release task.
• gates green: rubocop, rake test, rake test:parity (bin/check exit 0)

Affected paths

Rakefile, bin/gem-push, CLAUDE.md, RELEASE.md, test/unit/release_helpers_test.rb (or a new test/unit/rakefile_release_test.rb)

Verified against

c346bc9

[developerz-ai]

Plan

Problem: rake release and release:full bypass the CI-driven release invariant by tagging/pushing from local checkouts, and release:full is broken (undefined 'push' task).

Scope:

• Neutralise Bundler's release task to abort with a message pointing to RELEASE.md
• Delete the broken release:full task
• Make bin/gem-push run release:check before pushing
• Update CLAUDE.md:33 and RELEASE.md fallback section
• Add a unit test covering the aborting release task

Acceptance criteria:

• bundle exec rake release exits non-zero without creating a tag or touching RubyGems, and its message names RELEASE.md
• bundle exec rake -T | grep release lists release:check and release:package only (plus the aborting release)
• bin/gem-push runs release:check before gem push
• CLAUDE.md:33 and RELEASE.md no longer describe a local task that tags or pushes without the gate
• A unit test covers the aborting release task
• Gates green: rubocop, rake test, rake test:parity

Files affected: Rakefile, bin/gem-push, CLAUDE.md, RELEASE.md, test/unit/release_helpers_test.rb (or new test/unit/rakefile_release_test.rb)

Confidence: 0.9

🤖 Posted by developerz.ai — the maintainer agent, not a human.

[developerz-ai]

Want to submit a fix? I can hand this off to the maintainer's coding agent.

🤖 Posted by developerz.ai — the maintainer agent, not a human.

[developerz-ai]

The maintainer's coding agent has picked this up (task tsk_a31f0b5).

🤖 Posted by developerz.ai — the maintainer agent, not a human.

[developerz-ai]

build(rake): rake release and release:full bypass the release lane the repo forbids, and release:full cannot even run

• Picked up
• Surveying the repo — 2026-09-17 19:21 UTC
• Working — 2026-09-17 19:22 UTC
• Pull request opened
• Done

Queued — waiting for a free box.

---

🤖 developerz.ai maintainer bot — developerz-ai[bot]

[ivndev001]

spec-gate verdict: READY

Audit complete. Verdict durable at /tmp/claude-1003/-home-ivann-ws-developerz-ai-Projects-wurk/83b55918-b554-44db-a13a-531ed721d058/scratchpad/verdict-491.yaml.

issue: 491
repo: developerz-ai/wurk
bodyRevision: live          # no bodySource pinned; audited the live body
verdict: READY
checklist:
  - id: C1
    name: No-op against its own stated problem
    status: pass
    evidence: >
      `bundle exec rake -T` lists `rake release[remote]  # Create tag v1.7.5 and build and push
      wurk-1.7.5.gem to rubygems.org` — the tag/push path is live and advertised. Bundler
      gem_helper.rb:67-68 wires it to `["build","release:guard_clean","release:source_control_push",
      "release:rubygem_push"]`, so neutralising it removes a real capability, not a name.
      Rakefile:246 `task full: ['frontend:build','build','push']` is genuinely unbuildable.
      Doc edits are semantic rewrites (C1's text carve-out satisfied, not merely invoked).
  - id: C2
    name: Standing ruling / authorization
    status: pass
    evidence: >
      The draft ENFORCES the repo's recorded posture rather than reversing it. CLAUDE.md:101
      ("The release tag is an output, never an input… Never re-add a `tags:` trigger") and
      RELEASE.md:14-30 ("Nobody tags a release — CI does") are binding-register prose in the
      target repo; the draft cites both as its warrant and touches
      `.github/workflows/release.yml` not at all. Change is guard-strengthening, so neither
      the stronger nor the ordinary leg is triggered.
  - id: C3
    name: Repo-wide lockout
    status: pass
    evidence: >
      `.dz/pipeline/agent-pipeline.json` (governs; no legacy root file) declares
      `merge.reviewGate: "ci-only"` and NO `policy.module` — `isPolicyRepo` is false, so the
      #215 `review-gate-conflict` analogue cannot fire. No CI-invoked task is modified:
      test.yml runs `rake test` / `test:parity` / rubocop, none of which the draft touches.
  - id: C4
    name: Live-test provenance
    status: pass
    evidence: >
      `wurk.gemspec` `spec.files = Dir['lib/**/*.rb','lib/**/*.lua','app/**/*.rb','config/**/*',
      'exe/*','vendor/assets/dashboard/**/*','README.md','LICENSE']` — Rakefile, bin/, CLAUDE.md
      and RELEASE.md ship in no gem. Non-deploying slice; repo declares
      `policy.defaultTier: "GREEN"`, so a fenceless issue short-circuits to NOT_REQUIRED. No
      fence demanded, and inventing one would only buy the signalling hazard. No REPO-CONFIG
      finding needed — this repo IS configured.
  - id: C5
    name: Checkable acceptance
    status: pass
    evidence: >
      AC#1 ("`bundle exec rake release` exits non-zero… and its message names RELEASE.md") is
      mutation-sensitive, names the behavior it asserts, and is red today. No bare absolute
      counts. `CLAUDE.md:33` is line-numbered but anchored by the verbatim row quoted in the
      body, so it is not the brittle form C5 fails. See notes 1 and 5 for two soft spots that
      do not reach FAIL.
  - id: C6
    name: Evidence holds
    status: pass
    evidence: >
      Every cited file, symbol, range and mechanism verified against the pinned revision.
      Bundler's prerequisite list matches the draft verbatim (gem_helper.rb:67-68). No cited
      file or symbol is missing, no quoted snippet misquotes source, and no mechanism claim is
      contradicted by the code. Drift only — see note 3.
  - id: C7
    name: Fail-open
    status: pass
    evidence: >
      Traced all five triggers: the change removes no blocker, widens no accept condition,
      relaxes no fail-closed default, shortens no wait, and makes no absent signal count as
      permission. It moves strictly the other way — deletes two local tag/push paths and adds
      `release:check` in front of a third. Nothing stops being checked. Not hard class: the
      `release:*` tasks and `bin/gem-push` decide whether a GEM PUBLISHES, which is downstream
      of merge; they do not decide whether a PR may merge, what review it carries, how a diff
      is classified, whether a live test is required, or whether a revert arms. CLAUDE.md:33
      is a command-table row, not merge instruction; the merge-governing line 101 is untouched.
      Labels carry `afk` and not `hitl`, so no waiver applies and none is needed.
  - id: C8
    name: Blast radius / reversibility
    status: pass
    evidence: >
      One concern (stop local Rake entry points bypassing the CI release lane) across
      Rakefile + bin + 2 docs + 1 test — one slice by the concerns test, not four. Fully
      reachable by a revert of the merge commit; no repo settings, rulesets, secrets, issue
      edits or deletions. Not a secrets trigger: no credential is rotated, minted, or read in
      plaintext. Critically, a wrong merge cannot reach RubyGems on its own — release.yml's
      paths filter is `["lib/wurk/version.rb"]`, which this slice does not touch.
  - id: C9
    name: Work is real
    status: pass
    evidence: >
      (a) Abundant resolvable evidence — Rakefile:3, Rakefile:240-241, RELEASE.md:14-30 /
      102-127 / 179-184, CLAUDE.md:33 and :101, bundler task names, bin/gem-push's
      built-.gem guard — all opened and confirmed. (b) No `## Parent` section, so limb (b)
      is unaffected.
blockers: []
notes: |
  1. HIGHEST-VALUE GAP (incompleteness, not regression — why it is here and not in `blockers`).
     The prescription names THREE neutralisations (`release`, `release:source_control_push`,
     `release:rubygem_push`); the acceptance criteria verify ONE. AC#2 is structurally blind to
     the other two: I ran `bundle exec rake -T` and those tasks carry no `desc`, so they appear
     in `rake -T` neither before nor after the change. An executor that clears `release` and
     stops passes AC#1 and AC#2 and merges with `rake release:rubygem_push` still able to push
     from a checkout. Not a FAIL — C5 requires every criterion be checkable and one be
     mutation-sensitive, both met, and a partial implementation leaves the repo no worse than
     today. Suggested AC for the caller to add: "`bundle exec rake release:source_control_push`
     and `bundle exec rake release:rubygem_push` each exit non-zero with the RELEASE.md message."

  2. THE `tags:` RULE, ANSWERED EXPLICITLY. The draft does not touch
     `.github/workflows/release.yml`, adds no `tags:` trigger, and does not weaken
     `release:check` or `release:package`. It enforces CLAUDE.md:101 / RELEASE.md:14-30 rather
     than reversing them. I confirmed the publish lane is untouched by reading release.yml: it
     invokes only `rake frontend:build`, `rake release:check`, `rake release:package`, then
     `gem push` directly — it never calls Bundler's `release` or `release:*_push`, so clearing
     those cannot break publication. AC#2 independently asserts `release:check` and
     `release:package` survive, which blocks the plausible executor overreach of clearing the
     whole `release:` namespace.

  3. DRIFT, NOT STALE-ON-ARRIVAL — checked, not assumed. Every cited line was EXACT at the
     pinned `## Verified against` c346bc9 (2026-09-02T01:56Z; issue filed 2026-09-02T16:42Z,
     and c346bc9 is an ancestor of origin/main). Three later commits (19cc92a, a584783,
     5fb0c11) moved them. Current offsets for the executor: Rakefile:240-241 -> 245-246;
     RELEASE.md:179-184 -> 180-185. Rakefile:3, CLAUDE.md:33, CLAUDE.md:101, RELEASE.md:14-30
     and 102-127 all still land. This author verified against HEAD properly — the opposite of
     the #226 pattern — so the remaining citations are trustworthy.

  4. ONE WRONG SUPPORTING CLAIM, CONCLUSION INDEPENDENTLY TRUE. The body asserts
     `grep -n "task.*push" Rakefile` "finds nothing". It does not — it returns line 246, the
     `task full: [...,'push']` line itself. The conclusion that claim supports (no task named
     `push` is defined anywhere) is nonetheless TRUE and I verified it separately: bundler
     defines only build, build:checksum, install, install:local, release, release:guard_clean,
     release:source_control_push, release:rubygem_push, and the Rakefile defines no `push`.
     A correct probe is `grep -nE "^\s*task\s+:?['\"]?push" Rakefile`. NOTE under C6, not FAIL:
     the mechanism is confirmed, not contradicted.

  5. TEST-DESIGN HAZARD FOR THE EXECUTOR. The draft asks for a test that asserts a DESTRUCTIVE
     task is neutralised by invoking it. `release:source_control_push` does a `git push` of the
     tag; `release:rubygem_push` does a `gem push`. If the neutralisation is implemented wrong
     AND the test reaches the real prerequisite chain, that runs inside `rake test` — a
     required status check. Assert on the redefined task's action/prereqs, or run in a
     sandboxed tmpdir with no git remote; never let the bundler originals execute.

  6. LOAD-TIME FRAGILITY. `Rake::Task['release'].clear` raises if the task is undefined, and
     the Rakefile is loaded by every `rake` invocation including CI's `rake test`. Guarding
     with `Rake::Task.task_defined?('release')` would be cheaper than a red suite. Bounded
     risk: the draft's own AC#6 (`bin/check` exit 0) catches it pre-merge.

  7. UNMENTIONED SCOPE CONSEQUENCE. Gating `bin/gem-push` on `release:check` makes the
     documented emergency fallback require a clean tree, a built dashboard bundle, and a live
     Redis on 127.0.0.1:6379 (`release:check` invokes `Rake::Task['test']`; the repo declares
     `services: [redis]` for exactly that reason). RELEASE.md:184 frames that path as "for an
     out-of-band manual push when CI is unavailable". The draft does not acknowledge that its
     fix makes the CI-unavailable fallback need MORE infrastructure. Caller's call — not a
     criterion failure.

  8. STALE COMMENT THE DRAFT DOES NOT NAME. Rakefile:180 reads "in git and `rake release`'s
     guard_clean sees a clean tree" — it goes stale once `release` aborts. Rakefile is already
     in `## Affected paths`, so the executor can fix it in scope.

  9. CONTEXT FOR THE CALLER. Labels: `afk` present, `hitl` absent — no label-hygiene
     contradiction. `ready-for-agent` is ALREADY applied, so this draft may already be
     selectable; I neither applied nor recommend applying any label. A prior fleet attempt
     (task tsk_a31f0b5) already picked this up and stopped after 4 attempts on a model-quota
     rate limit — it died on capacity, not on a spec defect, so nothing in that failure bears
     on this verdict. Merge posture confirmed live and it is as sharp as the caller said:
     `.dz/maintainer/maintainer.yml` sets `pr.auto_merge: true`, `merge.standingAuthorization`
     is true, and `required_approving_review_count` is 0 — READY here really does authorize an
     unattended build and merge.

Bottom line: READY. This is an unusually well-evidenced draft — every citation was exact at its pinned revision, and the change moves the repo toward the invariant the caller asked me to protect rather than away from it. The tags: rule is safe: release.yml is untouched, and it never invokes the Bundler tasks being neutralised, so the publish lane cannot break. The one thing worth acting on before handoff is note 1 — three tasks are prescribed for neutralisation and only one has a criterion behind it.

run: acb743bda7c7fbf47
provider: anthropic
model: claude-opus-5