[santoshkumarradha]

Summary

Staging for the embedded furrow bump from v0.2.0 to the next release (0.3.x plus furrow PR #17, fast store open). No release exists yet, so pin.json is deliberately untouched.

 internal/cellstore/
+├── storecompat_test.go   # store written by furrow 0.2.0 opens, seals, captures, restores under the embedded engine, and back

codeaf needed no code change for the newer furrow. The only change is the compat test, which skips unless CODEAF_FURROW_OLD names an older furrow binary.

old engine seal  -> turn 1
new engine seal  -> turn 2 (parent = turn 1)
new engine capture, restore note.txt
old engine seal  -> turn 3 (parent = turn 2)   # rollback still works

furrow under test: PR #17 head fd92172 (Cargo version 0.3.2), built with make build FURROW_SOURCE=....

Compat findings, furrow v0.2.0 to fd92172:

• CLI additions only: archive (unix), verify. Verbs codeaf calls (capture-plan, seal, export, published, want, import, rebind, materialize, serve, sync, restore) and their --json shapes are unchanged.
• Opening an unwatched folder now fails earlier with the same message.
• SQLite capture reads private staged copies instead of the source database.
• Daemon socket name comes from the binary filename, so it follows the new build id with no change.
• No on-disk schema change in the diff (catalog is a rebuildable index). Store-v1 is compatible both ways: a 0.2.0 store opens under the new engine, and a 0.2.0 engine can still seal into a store the new engine wrote.

Evidence

• Before: nothing proved a 0.2.0 store survives a newer engine.
  After: TestStoreWrittenByAnOlderEngineOpensUnderTheEmbeddedOne passes on Spark with the 0.2.0 linux-arm64 binary (jobs 20261026-052540-002462 and 20261026-054030-002465).
• Full suite on Spark, furrow fd92172 source build (job 20261026-054030-002465, make check, exit 2): 8 packages failed.
  • Baseline on the pinned 0.2.0 engine and the same tree (job 20261026-055639-002467): internal/ci, internal/release, internal/seniordev/util, internal/skills and one tui3 test (TestBareAtProseSendsWholeOnEveryBox) fail the same way. The fleet copy has no .git.
  • cmd/codeaf (TestC31AStartupSaveIsNotAChoice), internal/lane and internal/secaf/agents/prove failed only under load. They pass on fd92172 in job 20261026-062658-002468 (C31 three runs, lane and prove two runs).
  • make check has not been seen fully green: the build-cross and size steps came after the failing test step. The fleet copy having no .git is why the baseline-identical failures cannot clear; CI will give the real result.
• e2e subset (TestDurability*, TestStartupWhileStorageCapture, CODEAF_E2E_MODEL=deepseek/deepseek-v4.1-flash), job 20261026-065541-002470: ok. Two durability tests skip by design.
• dev advanced by two commits (Relay, Make Add another device clickable with an editable pairing field #1949/Relay: coordination as a Raft group, and joined computers can lead #1950) after the suite run; this branch is merged up to 808c90c2f.

Merge Danger

Door: two-way

Test only. Does not change the pin, so shipped binaries keep furrow 0.2.0.

Blast Radius: none

Remaining step

After furrow vX.Y.Z is released with PR #17, from the repo root run (tested against v0.2.0: reproduces the committed pin.json byte for byte):

TAG=vX.Y.Z; gh release download "$TAG" -R Agent-Field/furrow -p SHA256SUMS -O - | jq -R -s --arg tag "$TAG" --arg repo Agent-Field/furrow '{repository:$repo, tag:$tag, version:($tag|ltrimstr("v")), artifacts:(split("\n")|map(select(length>0)|split("  ")|{h:.[0],a:.[1]})|map({key:(.a|sub("^furrow-";"")|sub("\\.exe$";"")),value:{asset:.a,sha256:.h}})|from_entries)}' > internal/furrowbin/pin.json.new && mv internal/furrowbin/pin.json.new internal/furrowbin/pin.json
make furrow && git commit -am "Bump embedded furrow to vX.Y.Z" && git push

[santoshkumarradha]

Pin bumped to furrow v0.3.3 (7692c68) via the command in the body. Verified on Spark: make furrow + make build stage the release; embedded linux-arm64 binary reports furrow 0.3.3, sha256 4cdb22b1…2acd matches pin.json.