5.5 KiB
ticket
Handles Ticket requirements, states, relations, audit events, and per-Workspace SQLite persistence. Does not search Repository documents or handle Git integration.
Main entry points
- [
TicketBackend], [SqliteTicketBackend]: operation boundary and persistence - [
TicketBackend::update_case]: reasoned close, reopen, and closure correction - [
ticket_content_digest]: requirement-content comparison condition - [
tool]: Worker-facing operation definitions
Posts and creation metadata
The initial body is a real Comment in typed_ticket_events, with the same author,
creation time, persisted event_ref, and edit metadata as later comments.
Ticket.document.body is a derived convenience, not another storage authority.
TicketMeta.created_at and optional created_by belong to the Ticket itself;
unknown legacy authors remain unknown.
TicketBackend::edit_post_with_snapshots edits a comment by its persisted identity
and exact expected body, returning the before/after Ticket snapshots atomically for
host audit and initial-post rescope handling. The host must supply the authenticated
editor, rather than trusting an author from Web input. Original post author and time
are retained; edited_at and edited_by record the edit. System events/judgments
are not editable posts. edit_item_with_snapshots still supports title/target and
initial-body authoring, without generating a discussion message.
Transport operation TicketBackendOperation::EditPost { id, edit } returns
TicketBackendOperationResult::TicketSnapshots { previous, current } by calling
that atomic snapshot method. The native TicketEditPost tool accepts ticket,
event_ref, expected_body, and body; it does not accept an author. Its standalone
actor default must be replaced with the authenticated caller by Workspace hosts.
Generic Show always returns initial_post, even when the recent-event window omits
it, using the same post identity/authorship/edit metadata projection as discussion
entries. Truncated bodies are marked and must not be used as exact edit observations.
Component migration 12 appends to the retained 10/11 migration history. It reserves
SQL event index -1 for the initial comment and leaves all prior event indices,
references, attributes, and evidence unchanged. Create/item_edit records are archived
in place (archived = 1) outside Ticket.events, not deleted. New creates insert
only the real initial comment; new item edits do not append events. Existing posts
retain their published identity: a stored event_id, otherwise the old zero-based
sequence:<ordinal> computed before inserting or hiding rows. Duplicate identities
abort migration rather than being silently changed. event_ref is persisted and
must not subsequently be recomputed from display position; existing attributes are
not overwritten. Initial edit metadata comes only from the last known body-edit
record (changes includes body), never a later title-only edit. Missing or empty
creator identities remain explicitly nullable, not inferred from later editors.
The retained base SQL and frozen fixture schemas remain unchanged; fresh creation
composes the ordered post migration.
Subject responsibility schema
Component migration 14 owns the Subject principal CHECKs and assignment/current,
operation, and legacy tracking/history guards. Fresh standalone stores and Workspace
hosts use the same migrate_sqlite_ticket_schema_in_transaction(&Connection) startup
composition; the host owns its surrounding transaction, authentication, live Subject
body bindings, delivery/start fences, and notification routing. Request paths only
verify the owning schema and never install a host-dependent fixture or fallback.
Retained host startup migrations must instead call
migrate_historical_sqlite_ticket_schema_in_transaction(&Connection, HistoricalTicketSchemaTarget)
with the explicit Cases10, Tracking11, Posts12, or Content13 boundary. This
bounded API shares the latest composer's migration engine; it cannot select arbitrary
versions or downgrade a current store. If the applied version is already newer, it
verifies that actual contract without replaying old steps or relabelling receipts.
Original baseline receipts are retained, including v6–9 baselines; their ordered
v7/10 composition receipts are appended instead of overwriting the baseline. Previously
retained normalized baseline10 histories remain supported. Neither composer is a
request-path API or a grant of legacy execution authority.
The additive migration leaves applied core/tracking SQL unchanged. It preflights
complete known table generations (standalone or Workspace-parent FKs), widens only
the three principal CHECKs with exact-SQL CAS, restores writable_schema on failure,
and checks integrity before accepting the migration. This avoids rebuilding immutable
parents and their host-owned FK graph inside a host transaction. Unsupported/mixed
tables and weakened guards fail closed; a trigger name alone never selects a schema
generation. Migration history selects the exact verified contract.
Old workspace_agent relationships, handling/results, audit source JSON, and receipts
remain readable as historical data, with a nonoperational diagnostic. They are not
converted to an arbitrary Subject or replayed as new input. Newly authorized Subject
Assign/reissue creates a distinct identity. Tracking sources use the Rust/JSON field
subject_id; historical agent_key audit JSON remains an unmodified JSON value,
not an alias accepted as current Subject authority.