[gitfromwildan]

Problem

core/Cargo.toml (the shared docubook-core engine) is the only manifest that does not follow the app release version. It sat at 0.1.8 while package.json, src-tauri/Cargo.toml, server/Cargo.toml, src-tauri/tauri.conf.json, and every lock had already moved to 0.2.0.

This is a real gap, not cosmetic: docubook-core is a path dependency of both consumers (desktop via src-tauri, web via server), so its version is embedded in core/Cargo.lock, src-tauri/Cargo.lock, and server/Cargo.lock. Leaving it unpinned to the release means:

• the shipped engine reports a version (0.1.8) that no longer matches the release it was built into;
• the CI version gate never checked it, so the drift passed silently;
• a core API change that both consumers pick up is invisible in the release number.

CONTRIBUTING.md and the release-please.yml header both asserted independent core versioning, which is what let the drift go unnoticed.

Changes

File	Change
release-please-config.json	Add { "type": "toml", "path": "core/Cargo.toml", "jsonpath": "$.package.version" } to the root extra-files so release-please bumps it with the app.
.github/workflows/release-please.yml	sync_root_version core docubook-core in the sync-lockfiles job, so core/Cargo.lock's root entry tracks the bumped manifest. Header corrected (five manifests; core no longer "intentionally not bumped").
.github/workflows/ci.yml	Extract core_v from core/Cargo.toml and core_lock_v from the docubook-core lock entry, then include both in the version-consistency loop.
test/check-release-config.mjs	New guard: fail if the root package loses the core extra-file updater (or its toml / $.package.version shape changes).
CONTRIBUTING.md	Version overview now lists core/Cargo.toml as one of the five synced manifests; release-workflow table lists core under release-please and "all three Cargo.lock" under the sync job. Removed the "versioned independently" / "four manifests" claims.

The pre-push hook already synced core (its own lock root version and the docubook-core entry inside both consumer locks), so local pushes were consistent — the gap was only in the automated release path and the CI gate, which is what this PR closes.

Verification

• node test/check-release-config.mjs → release config OK … core tracks the release version
• node test/check-changelog-heading.mjs, node test/check-acl.mjs, node test/check-docker-paths.mjs → all pass
• npm test → 84 files / 862 tests pass
• release-please-config.json parses as strict JSON; both workflows parse as valid YAML
• Version-extraction gate simulated locally: all eight values (package.json, package-lock, three Cargo.tomls, tauri.conf.json, three Cargo.lock entries) agree

Notes

• Core remains intentionally on the same version as the app; there is no separate core release. This is the fix to the drift described above.
• No manifest version was hand-edited — the bump flows from the next release-please run, which will now write core/Cargo.toml too.
• The release PR (chore(release): v0.2.0 — DocuBook #273) will regenerate with core included; the sync-lockfiles job keeps core/Cargo.lock in step.

[pullfrog]

Important

The new core lockfile synchronization is not included in the commit/push step, so the release PR remains inconsistent and fails the CI gate.

Reviewed changes

• Core release versioning — Reviewed the release-please extra-file configuration, release workflow lock synchronization, CI version-consistency checks, release guard, and corresponding documentation updates.
• Validation — Traced the new core/Cargo.lock sync through the workflow's change detection and staging logic; the focused release-config check was also run, but is blocked by the checkout's unavailable bootstrap commit f6ee177.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using gpt-6-luna ｜ 𝕏}

[pullfrog]

Fixed and pushed commit bd6b1f6 to PR #275. The release workflow now includes core/Cargo.lock in both its changed-file detection and staging list, so the lockfile update produced by sync_root_version core docubook-core will be committed. Verified with node --check test/check-release-config.mjs, a focused workflow-file assertion confirming all synchronized files are staged, and git diff --check; the worktree is clean. The standalone release-config guard remains blocked by the pre-existing unavailable bootstrap-sha commit f6ee177, unrelated to this fix.

Task list (5/5 completed)

• Checkout PR fix(release): track the core crate version with the app release #275 and inspect failed check logs
• Verify the failure is introduced by the PR and reproduce it locally
• Implement the minimal root-cause fix
• Run applicable verification and review the diff
• Commit the fix, push PR branch, and report results

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using gpt-6-luna ｜ 𝕏}

[pullfrog]

✅ Pullfrog addressed all of its review feedback on this PR.

Addressed the review finding: core/Cargo.lock is now included in release-workflow change detection and staging (commit bd6b1f603688e23abd8d9f3d10ea42bea904a396), and the thread is replied to and resolved. The release-config guard ran but reports its existing bootstrap SHA f6ee177 is unavailable in this checkout; the working tree is clean and the fix is already on PR #275.

Task list (4/4 completed)

• Checkout PR 275 and inspect review 5543854043 threads
• Implement validated fixes for all actionable review comments
• Run targeted tests and inspect the final diff
• Commit, push, reply to addressed threads, and report results

  ^{｜ View workflow run ｜ Using gpt-6-luna ｜ 𝕏}