Corrections that wait, and every version of a summary (D31, IS-379/D51, lane 4) #808
Loading…
Reference in a new issue
No description provided.
Delete branch "build/lane4-versions"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Lane 4 (#730), server only. The Review page that uses it comes in a later lane 4 PR, and the old session page works unchanged.
Corrections that persist (D31)
session_pending_corrections, one per session and shared by the campaign's GMs, with who made each correction and when (D104).GET /api/sessions/{id}/pending-correctionsreturns{base_run_id, stale, corrections, updated_at}.stalemeans the summary has changed underneath.PUT …/pending-corrections/{beat_id}replaces that beat's set. It validates the whole set withapply_corrections, so a bad combination is a 422. An empty list clears the beat, which is Undo.DELETE …/pending-correctionsclears them all.{use_pending: true}. The applied rows are deleted only if the rewrite succeeds; a failed rewrite keeps them. The old body shape still works.Every version of a summary (IS-379 / D51)
session_summary_versions.sessions.summarystays the one text every reader uses.legacyrow, and so does every earlier text a regenerate kept. The current summary is always the newest row.showingand a preview;POST …/put-backwithexpected_updated_at. It returns 409 while a rewrite is in flight or if the page is stale. It is a no-op if that text is already showing. It fires the same follow-ups as a hand edit.TextVersionMixinplus a generictext_versionsservice, so the table note's history (D97) reuses them in the notes PR.Migration
c5d6e7f8a9b1, chained afterf3a4b5c6d7e8(#807's numbering). The single-head pin moved totest_review_tables_migration. Run for real against a fresh database, through the whole chain: up, down one, and up again.Checks
docs/API.mddocuments the endpoints.🤖 Generated with Claude Code
Saved corrections (D31). GET/DELETE /api/sessions/{id}/pending-corrections and PUT .../pending-corrections/{beat_id}, GM-only. A PUT replaces one beat's set (an empty list is Undo) and validates the whole saved set with apply_corrections against the base run, so what is saved is always what a regenerate would take: a bad combination is a 422 in its own words. The first save fixes the base to the session's latest run; once a newer run exists the set is stale -- GET says so, adding is a 409, clearing is not. A PUT while a regenerate runs is a 409. The session row is locked while a save validates, so two GMs cannot each validate without the other's row. recompose takes {"use_pending": true}. The job gets the rows' ids and deletes exactly those, in the savepoint that writes the summary, so a failed, superseded or overtaken job keeps them. A list in the body (the old page) is untouched, and the task's new argument is optional so a message queued before this release still runs. Summary versions (IS-379, D51). One helper, summary_versions.record, is called in the same transaction as every write of sessions.summary: process_audio (pipeline, with its run), the recompose task (rewrite, with the run and the correction count), restore-previous-summary (put_back, naming the version it copied), PATCH (gm_edit, only when the words change), and import. GET .../summary-versions lists them newest first with showing on the newest; GET .../{version_id} adds the text; POST .../put-back writes the summary, appends a put_back row, stamps updated_at and fires announce_summary_changed -- exactly what a hand edit fires. It is a 409 while a regenerate runs or on a stale expected_updated_at, and a no-op that writes nothing for a version that already reads as the summary. Generic half in text_versions (record, list, showing, put-back's no-op rule, preview, people) and schemas/text_version, keyed on the model's VERSION_PARENT, for the table note's history in PR E. Erasure leaves versions alone (D94). Account deletion repoints a version's author to the tombstone, as it does a wiki version's. The new endpoints live in routers/session_review.py; /api/bot/* and the old session page are unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>