Publish summary and WIP writes under the recorded intent

[hlubek]

Milestone 4 slice 4, upstream half. Summary correction and the WIP marker writes move onto the recorded-intent publication path that capture uses, and the prepared-write path they were the last users of is removed.

• replaceSummary, wipStart, wipDone and wipRemove allocate identities and the precondition before the intent, publish once under the intent's key, and report their effects. A retry finds its own publication and never overwrites a later one; a summary replacement conditions on the document it replaces and answers a moved document with a conflict carrying the current summary; removing an absent marker succeeds.
• The engine records the transition a chooser option owes with the intent, so a retry lands on the answered option's target instead of re-serving the chooser (s-tac-do6).
• PublicationStore replaces EntryPublicationStore and adds ReadDocument, LookupDocumentPublication and PublishDocument; GraphStore loses Apply and Reconcile. The conformance suite covers keyed publication, replacement preconditions and absent removals.
• Removed: ApplyPrepared/PreparedTransition, revalidation, the recovery projections and notices, sdd recover, the local store's transaction and apply-record machinery, and the recovery inject argument.

Delivers the summary and WIP requirements of 20260914-113911-d-tac-wgw; the hosted half follows in sdd-product.

🤖 Generated with Claude Code

Confidence Score: 4/5

The PR is not safe to merge until repository reads can prove that a newer branch revision contains a requested successful write.

Findings

1.  Causal revision history is lost ▶

Fix with agent prompt

### Issue 1
pkg/local/read_snapshot.go:131-132
When `IncludesRevision` names a successful write and the branch has advanced, a newly constructed read store has no in-memory lineage and no `PublicationGit`. This path therefore returns false even though the current snapshot contains the requested revision. Repository target reads create exactly this kind of fresh store, so a valid causal search can fail with “current revision cannot be shown to include the requested write” after an intervening publication. Please preserve durable lineage or make Git ancestry available to read stores.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR moves summary replacements and WIP marker changes onto intent-keyed publication, records chooser transitions for retries, and removes the prepared-transition recovery machinery.

• Adds keyed single-document publication with replacement preconditions and retry lookup.
• Records mutation transition targets so retries finish the answered chooser option.
• Removes recovery APIs, CLI surfaces, projections, and local transaction records.
• Replaces durable filesystem revision ancestry with process-local lineage, which breaks causal reads after the branch advances.

_{Reviews (1) · Last reviewed commit: "feat(application): publish summary and W..."}

[greptile-apps]

Causal revision history is lost

When IncludesRevision names a successful write and the branch has advanced, a newly constructed read store has no in-memory lineage and no PublicationGit. This path therefore returns false even though the current snapshot contains the requested revision. Repository target reads create exactly this kind of fresh store, so a valid causal search can fail with “current revision cannot be shown to include the requested write” after an intervening publication. Please preserve durable lineage or make Git ancestry available to read stores.

Prompt To Fix With AI

This is a comment left during a code review.
Path: pkg/local/read_snapshot.go
Line: 131-132

Comment:
**Causal revision history is lost**

When `IncludesRevision` names a successful write and the branch has advanced, a newly constructed read store has no in-memory lineage and no `PublicationGit`. This path therefore returns false even though the current snapshot contains the requested revision. Repository target reads create exactly this kind of fresh store, so a valid causal search can fail with “current revision cannot be shown to include the requested write” after an intervening publication. Please preserve durable lineage or make Git ancestry available to read stores.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.