[#1021] 2.7.1

[realproject7]

Closes #1021.

Release-source bump 2.7.0 → 2.7.1 from main 31708d5. npm latest is 2.7.0, so a publish without this bump would fail as a duplicate version. Version strings only — no dependency, source, docs, or build-output diff.

EPIC Alignment

• Parent: none — standalone patch release (NOT EPIC [EPIC] QuadWork v2.4.0 hardening & quality pass — audit remediation #967). Standard QuadWork merge flow.
• This ticket's role: create the release-source bump; the GitHub release/tag and npm publish are explicitly not part of this PR.
• Contracts respected: version strings only; package.json root and both lockfile version fields stay identical; source merges before any tag/release/publish.
• Out of scope: publishing, npm credentials, rollout, and any source change beyond the three version fields.

Changes (2 files, +3/−3)

Exactly the three fields the ticket names, edited by path, not by global replacement:

Field	File
version	package.json:3
version	package-lock.json:3
packages[""].version	package-lock.json:9

Path-specific editing matters here even though a global replace would happen to be safe today: package-lock.json also carries dependency versions (e.g. 2.6.1, 2.1.1), so a string sweep is safe only by coincidence of no dep sharing the release version. Verified no 2.7.0 occurrence remains in either file, and lockfile dependency resolutions are untouched.

Included since v2.7.0

• file-chat: Claude agents never woken — PTY idle heuristic starved by continuous TUI repaint #1010 — restore reliable Claude file-chat wake delivery under continuous TUI repaint, without cap-injecting into Codex/Gemini (PR [#1010] Bound Claude deferred-wake delivery under continuous TUI repaint #1020).
• Add Claude Opus 5 as a pinned selectable model #1018 — add claude-opus-5 as an explicit pinned Claude model while preserving opus (latest) (PR [#1018] Add Claude Opus 5 as a pinned selectable model #1019).
• docs(readme): Reframe QuadWork around governed batch delivery #1003–docs(operator-mcp): Make the Operator MCP guide backend-neutral and remote-safe #1009 — governed-batch and installation/operator documentation refresh (PRs [#1003] docs(readme): Reframe QuadWork around governed batch delivery #1011–[#1009] docs(operator-mcp): Make the Operator MCP guide backend-neutral and remote-safe #1017).

Self-Verification

• npm test → 64 passed, 0 failed, 2 skipped (the two skips are the pre-existing Jest-style files, out of Unref routes.js module-load pollers + add cross-platform 'npm test' (fix full-suite hang) #836 scope).
• npm run build → succeeds, TypeScript clean.
• npm pack --dry-run → succeeds: quadwork-2.7.1.tgz, 150 files, 1.1 MB packed / 3.3 MB unpacked, version: 2.7.1 — confirms the bump reaches the tarball and the files allowlist still resolves (the Settings: changing an agent's Command doesn't update mcp_inject — converting to gemini leaves stale 'flag' and crashes the CLI #937/2.3.4 crash-loops on fresh install: server requires src/lib/injectMode.js, not in npm files whitelist (#937 regression) + add pack-smoke guard #939 guard).
• git diff against the baseline is exactly the three version lines in two files; grep confirms no residual 2.7.0 in either.
• Baseline: branched from main @ 31708d5, the commit named in the ticket.
• release:patch was not used and must not be — it chains npm version patch && git push origin main --follow-tags && gh release create --latest && npm publish, which both pushes directly to main (against the project rule) and performs the public release plus publish in one non-interruptible command.

After merge

Per the ticket's release flow, this PR stops at the source bump. After @Head merges I will verify final main reads 2.7.1 and stop there. Creating the v2.7.1 GitHub release/tag requires a separate explicit public-release authorization and is the PO's action — not chained from merge verification — and npm publish is an operator-only gate.

🤖 Generated with Claude Code

[project7-interns]

Verdict: APPROVE

Epic Alignment: PASS

Standalone #1021 implements only the release-source bump contract; public release/tag/publish remain correctly outside this PR.

Checked (evidence)

• Structural gate: live PR body includes filled ## EPIC Alignment and ## Self-Verification; live amended #1021 defines the standalone release flow and path-specific three-field contract.
• Exact source version: parsed PR-tip manifests show package.json.version = 2.7.1, package-lock.json.version = 2.7.1, and package-lock.json.packages[""].version = 2.7.1 (package.json:3, package-lock.json:3,9).
• Riskiest part: lockfile resolution integrity; live diff is exactly package.json +1/-1 and package-lock.json +2/-2, and no residual "version": "2.7.0" remains in the PR-tip lockfile.
• Release boundary: the diff contains no source, dependency, tag, release, or publish change; it conforms to #1021’s prohibition on release:patch.
• Kill-list: scanned all items — clean; no scope creep.
• CI: gh pr checks 1022 → test pass 1m4s (live).

Findings

• None.

Decision

The three root version fields are synchronized at 2.7.1 and dependency resolution is untouched. Approval applies to 7ea62768e97dde18916e559a6dcad628e18d8712.

[realproject7]

@re2 APPROVE at 7ea62768e97dde18916e559a6dcad628e18d8712

2 files, +3/−3, base main, MERGEABLE, test pass 1m4s. Exactly the three path-specific version fields, nothing else.

@dev asked that the "no dependency resolution moved" claim be confirmed independently rather than eyeballed. I verified it structurally rather than by reading the diff — parsed both lock files and compared the full packages map:

package entries: 600 -> 600   | same key set: true
entries whose content changed: ["<root>"]
root version: 2.7.0 -> 2.7.1  | top-level version: 2.7.0 -> 2.7.1
lockfileVersion: 3 -> 3       | non-packages/non-version body identical: true

So of 600 lock entries, the only one whose content differs is the root package, and its sole change is the version string. That is a stronger statement than "the diff looks like 3 lines" — it rules out a reordered or re-resolved dependency hiding elsewhere in a 600-entry file. The global-replace hazard you flagged (deps at 2.6.1/2.1.1) is confirmed moot here and, more importantly, structurally excluded rather than coincidentally avoided.

Checked (evidence)

Scope. git diff --stat origin/main... → package-lock.json (+2/−2), package.json (+1/−1), 2 files changed. The three fields are package.json:3, package-lock.json:3, package-lock.json:9 (packages[""].version), all 2.7.0 → 2.7.1. No residual 2.7.0 in either file (git grep → none). No source, docs, dependency, or build-output change.

2.7.1 is the correct next publishable patch. npm view quadwork version → 2.7.0; npm view quadwork versions filtered to the 2.7.x line → 2.7.0 only, so 2.7.1 is unused. v2.7.0 is the current GitHub Latest release (2026-07-13) and its tag resolves to 8537162, matching the ticket-review finding.

Ordering boundary respected — verified by absence, not by assertion. git ls-remote --tags origin shows refs/tags/v2.7.0 and no v2.7.1; gh release list shows v2.7.0 still Latest. So no tag or GitHub release was created ahead of the source merge, and nothing was published. This PR is source-only, with no changelog/release-notes file — correct, since the notes belong to the separately-gated public release rather than to this bump.

release:patch was not used, consistent with the branch/PR flow being present at all. Recording both disqualifications since they now live in the amended ticket: it runs git push origin main --follow-tags (a direct push to main, which the project rule forbids outright) and chains gh release create --latest && npm publish in one non-interruptible command. The first reason stands even if the publish gate is handled separately.

Verification at this SHA in a clean worktree: node server/run-tests.js → 64 passed / 0 failed / 2 skipped (the pre-existing #836 Jest skips, unchanged); npx tsc --noEmit clean; npm run build succeeds, 9/9 pages; npm pack --dry-run → quadwork-2.7.1.tgz, version: 2.7.1, 150 files, 1.1 MB packed / 3.3 MB unpacked — matching your reported figures exactly. I also sanity-checked the tarball manifest against the #937/#939 files-allowlist guard: top-level entries are bin, docs, out, server, skills, src, templates, package.json, README.md, LICENSE, with no .env, node_modules, .git, key, or config-file entries.

No concerns. Head unmoved at 7ea6276 and CI green as of this comment.

On the post-merge boundary: agreed and worth restating for the gate — after merge, verification is that final main reads 2.7.1 and nothing more. Creating the v2.7.1 tag/release is outward-facing (it publishes notes and moves the public "Latest" pointer, and can't be cleanly retracted once consumers see it), so it needs its own explicit operator authorization rather than being chained from merge verification; npm publish is operator-only regardless.