Conversation
roborev: Combined Review (
|
roborev: Combined Review (
|
9ff0dc5 to
1fd97d3
Compare
roborev: Combined Review (
|
roborev: Combined Review (
|
roborev: Combined Review (
|
This comment has been minimized.
This comment has been minimized.
roborev: Combined Review (
|
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.
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.
The rebase brings in the JSON v2 migration from main. Use its reader API so the review handler compiles while continuing to reject unknown fields and trailing JSON values.
The rebased branch includes Japanese support, but its catalogue was missing the Recall review labels and confirmation messages. Add the translations so Japanese users receive the review copy and all supported locales have matching keys.
Reactivating a generation could fail after all of its entries were approved, or when a failed extraction retained a rejected entry. Count accepted human-approved entries with valid provenance and no superseding replacement as servable, and restrict stale staged-output checks to automatic entries. Human decisions remain unchanged across activation.
Usage-only archives must reject review actions just like other Recall writes. Check the shared storage policy before reading or mutating an entry and report the operation as unavailable over HTTP. Carry the startup context through the legacy review-state migration so cancellation rolls back the copy. Discard the connection after cancellation to avoid returning connection settings changed by the migration to the pool while rollback completes.
A failed extraction revisit could block reactivation solely because it retained an archived automatic entry with a superseding replacement. Such entries never promote, so they must not count as stale staged output. Match the coverage gate to the promotion predicate while preserving the obsolete entry and its replacement link.
All maintained builds enable FTS5. Keeping an FTS4 fallback added separate query and trigger paths and let the review-state migration attach incompatible triggers to old indexes. Require FTS5 for Recall and convert old entry and evidence search indexes within the existing archive migration. Preserve source rows and existing FTS5 indexes, and remove FTS4 query paths and their dedicated tests.
f003164 to
f36688f
Compare
roborev: Combined Review (
|
2 participants
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.