feat(recall): review extracted entries from the corpus - #1369
Open
wesm wants to merge 10 commits into
Open
Conversation
Machine-extracted entries need a durable human disposition before they can safely become trusted or stay rejected. The design keeps that decision explicit in the review state so extraction generation changes cannot silently reverse it.\n\nThe existing SQLite CHECK makes review-state evolution an archive concern instead of a Go business rule. The approved design removes that constraint through one narrowly scoped, data-preserving migration and defines the API, UI, freshness, and failure contracts for the implementation.
The approved workflow spans a data-preserving SQLite migration, transactional review semantics, an HTTP boundary, and row-local frontend behavior. A file-specific red-first plan keeps those layers independently verifiable while preserving the clean scope of individual approve and archive decisions.
Recall review needs a terminal rejection state that survives reopen and future state additions. Keeping the allowed review-state enum in SQLite made each new business state require a table change, so policy now lives at the shared Go write boundary.\n\nExisting archives are rebuilt transactionally before schema initialization while preserving row IDs and relationships needed by evidence, supersession, and FTS.
Machine-generated Recall entries need a one-way human disposition that extraction maintenance cannot reverse. The store now enforces that only accepted, unreviewed automatic entries can be approved or archived, with provenance required for approval.\n\nReturning the hydrated entry from the same transaction keeps the API response aligned with the committed decision, while SQLite triggers continue to invalidate only the query and embedding views affected by each transition.
The Corpus UI needs a narrow mutation boundary for approving or dismissing one machine-generated entry without exposing broader entry editing. The endpoint validates a single explicit action, preserves typed storage conflicts, and returns the committed entry so clients can update one row in place.\n\nRead-only and maintenance states follow the server's existing capability and retry semantics, and vector refresh is scheduled only after a successful decision.
Review controls need one typed client operation and stable user-facing language before the Corpus table can expose mutations. The frontend now models the two allowed decisions, preserves server error details, and names every review state so raw storage values do not leak into the interface.\n\nAll supported locales carry the same confirmation, provenance, and failure messages, keeping the interaction accessible regardless of the active language.
A distilled corpus is only useful if people can turn uncertain automatic output into an explicit decision where they inspect it. Expanded rows now expose immediate approval and confirmed archive actions, while revoked provenance blocks only the trust-increasing transition.\n\nSuccessful responses update the current page locally instead of reloading or disturbing pagination and scroll. Pending and conflict states stay scoped to the affected row so unrelated corpus browsing remains available.
The public workflow now lets users make durable trust decisions from the Corpus table, so the documentation must distinguish approval from rejection and make provenance gating explicit. The extraction lifecycle notes also clarify that machine maintenance cannot reverse either human state.\n\nThe migration test uses the repository's current Go loop form so the full linter remains clean.
The design and execution notes were useful while the review workflow was being built, but they are not product documentation and would add maintenance noise to the public change. The durable behavior now lives in the Recall user and extraction lifecycle documentation.
roborev: Combined Review (
|
Human-rejected entries are archived, so querying by review state alone silently restricted the result to the API's accepted default. Pairing that review state with the archived lifecycle status makes the named Corpus filter include the decisions it represents without changing other filters.
roborev: Combined Review (
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
human_reviewedentry; confirmed archive produces an archivedhuman_rejectedentry. Both decisions remain outside extraction generation cleanup.internal/db, error mapping ininternal/server/recall.go, and row-local behavior inRecallCorpusPanel.svelte.