Document the remaining work as a handover

[contrasam]

docs/OPEN-WORK.md — everything still open after 0.3.0, written to be picked up cold.

0.3.0 shipped four of the report's eight items plus two defects that weren't on it. What's left is currently spread across a merged report, a dozen PR threads, and findings made while implementing — none of which survives a fresh context.

What it contains

Each item carries the evidence, so nobody has to re-derive why it matters:

• The probe output for the multi-tag version defect (next QUEUE-only append got localId=4 (expected 1))
• The measured 43 vs 51 step count for Catalyst's live corruption
• Which mutation survivors are worth killing, and the two classes that are not — FileChannel::force, which no in-process test can distinguish, and trim's index purge, which survives because the code is redundant rather than because the test is weak

It records ordering, not just a list, because parts are sequenced: the fault-injection harness belongs before D2 (D2 is a partial-write problem and would be its first customer), and the multi-tag version goes last as the only item carrying a log-migration cost.

Two items changed rank against the report, with reasons

A4 (capabilities) moves up from 7th. It was ranked as polish on the grounds that adapters didn't meaningfully differ — and 0.3.0 made them differ. The same append(request, expectedVersion) is fenced across processes on FoundationDB and fenced within one writer on the file adapter. That distinction exists only in prose right now, which is precisely how D4 happened.

D2 moves down. The directory lock from #7 means a second writer now fails loudly, so D2 is needed to make multi-writer usable, not to stop it being dangerous.

Also recorded

§0 is the release blocker: the 0.3.0 tag isn't pushed, with the exact commands and the reason it couldn't be done from the session that cut the release. Plus a coordinate mismatch worth settling first — pom.xml says com.cajunsystems, the README says com.github.CajunSystems, and Catalyst's existing 0.2.0 dependency therefore isn't resolving from JitPack.

Three process hazards that cost real time here:

• A stacked PR merged after its base has already gone to main leaves its content behind while GitHub reports it merged (this happened to the streamVersion rename and needed Land the streamVersion rename on main (#9 was merged into #8's branch, not main) #12 to recover)
• Review comments arrive after replies — a fifth P1 on Assign stream versions in storage, and fence appends on them #13 sat unnoticed because a previous fetch was treated as final
• A green test is not evidence the test works — two here passed against the very defect they were written for

Doc only; no code changes. Linked from the README's Further reading.

---

Generated by Claude Code

[greptile-apps]

Greptile Summary

Documents the remaining post-0.3.0 work and clarifies failure semantics.

• Adds a prioritized handover covering release tasks, unresolved defects, adapter capabilities, testing gaps, and process hazards.
• Correctly scopes the trim index-purge guidance to FileBasedPersistenceAdapter and distinguishes InMemoryPersistenceAdapter.
• Links the failure-semantics and open-work documents from the README.

Confidence Score: 5/5

The documentation-only PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
README.md	Adds links to the failure-semantics and open-work documentation.
docs/FAILURE_SEMANTICS.md	Clarifies that the file adapter’s trim purge remains necessary for bounding index memory and does not generalize to the in-memory adapter.
docs/OPEN-WORK.md	Adds a detailed, prioritized handover of unresolved release, correctness, API, testing, and process work, including the corrected adapter-specific trim guidance.

_{Reviews (2): Last reviewed commit: "Correct the trim-purge guidance: name th..." | Re-trigger Greptile}