ticket: split ticket workflow event log

.yoi/tickets/open/20260606-215403-explicit-ticket-workflow-state/item.md

@@ -7,7 +7,7 @@ kind: task
 priority: P1
 labels: [ticket, tui, orchestration, panel, state]
 created_at: 2026-06-06T21:54:03Z
-updated_at: 2026-06-06T22:04:15Z
+updated_at: 2026-06-06T22:14:29Z
 assignee: null
 legacy_ticket: null
 ---
@@ -90,6 +90,21 @@ The panel composer/status area should also be simplified. Do not put verbose tar
 
 The panel action currently called `Go` should become `Queue`, because the user is queuing a ready Ticket rather than approving implementation details.
 
+## Thread/event-log relationship
+
+Current workflow state should live in frontmatter, but every workflow state transition should be explainable through a concise append-only thread event. The thread should become a typed event log, not a freeform conversation transcript.
+
+This is split into companion ticket `typed-ticket-thread-event-log` so this Ticket can focus on current-state fields and panel semantics while the companion defines/implements the event-log API.
+
+Desired split:
+
+- `item.md` frontmatter: current workflow state authority.
+- `item.md` body: current Ticket snapshot.
+- `thread.md`: typed append-only events such as `state_changed`, `intake_summary`, `decision`, `implementation_report`, `review`, and `close`.
+- Pod/session logs: full conversations/runtime transcript.
+
+State mutations should eventually use backend APIs that update frontmatter and append a `state_changed` event as one logical operation. Intake should write a concise `intake_summary` instead of copying the full Intake conversation into the Ticket thread.
+
 ## Requirements
 
 - Add explicit workflow state fields to the Ticket model/parser/writer and tool/CLI surfaces as needed.
@@ -103,8 +118,8 @@ The panel action currently called `Go` should become `Queue`, because the user i
 - Remove or demote current panel heuristics that infer phase/action from labels, title text, `readiness`, `needs_preflight`, or thread event presence.
 - Rename panel `Go` action to `Queue` and make it transition `ready -> queued`.
 - Queue action must re-check current Ticket state before mutation.
-- Queue action records a durable thread decision/comment and sets `queued_by` / `queued_at` if those fields are adopted.
+- Queue action records a durable typed `state_changed` / decision event and sets `queued_by` / `queued_at` if those fields are adopted.
-- Orchestrator should treat `queued` as schedulable and set `inprogress` when it starts work.
+- Orchestrator should treat `queued` as schedulable and set `inprogress` when it starts work, with a typed state transition event once the companion event-log API exists.
 - Intake should set `workflow_state = ready` when the Ticket is fully materialized and ready to queue.
 - Done/close flow should set `workflow_state = done` or derive it consistently from close status.
 - Do not store transient `activity` in Ticket frontmatter.
@@ -112,7 +127,7 @@ The panel action currently called `Go` should become `Queue`, because the user i
 
 ## Non-goals
 
-- Building a scheduler/lease system.
+- Building the full typed thread event-log API; companion ticket `typed-ticket-thread-event-log` owns that, though this ticket should align with it.
 - Persisting live Pod activity into Tickets.
 - Reintroducing human approve/reject gates for every review loop.
 - Reintroducing `--multi` or `:ticket`.
@@ -130,3 +145,4 @@ The panel action currently called `Go` should become `Queue`, because the user i
 - Review/rework activity does not create a separate workflow state; it remains `inprogress` plus runtime/thread detail.
 - No persistent `activity` field is required for current Pod activity.
 - Existing tests cover default/migration behavior, panel display, Queue dispatch, and stale-state rejection.
+- Companion ticket `typed-ticket-thread-event-log` exists and captures the append-only state transition / Intake summary event-log work if not implemented in the same change series.

.yoi/tickets/open/20260606-215403-explicit-ticket-workflow-state/thread.md

@@ -37,4 +37,22 @@ Updated per user direction:
 - Composer/status bar should be kept concise; verbose target/help/diagnostic text should move to actionbar or detail/diagnostic areas.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-06T22:14:29Z -->
+
+## Decision
+
+Updated based on thread/event-log discussion and split out companion work.
+
+Decision:
+- Do not delete Ticket threads.
+- Do not use threads as freeform AI conversation dumps.
+- Use `item.md` frontmatter for current workflow state, `item.md` body for the current Ticket snapshot, `thread.md` as a concise typed append-only event log, and Pod/session logs for full conversations.
+- Workflow state transitions should eventually update frontmatter and append a `state_changed` event as one logical backend operation.
+- Intake should write a bounded `intake_summary` when materializing/marking a Ticket ready, not copy the full Intake conversation.
+
+Created companion ticket `typed-ticket-thread-event-log` for the typed thread event model/API so `explicit-ticket-workflow-state` can stay focused on current-state fields and panel semantics.
+
+
 ---

.yoi/tickets/open/20260606-221301-typed-ticket-thread-event-log/item.md

@@ -0,0 +1,102 @@
+---
+id: 20260606-221301-typed-ticket-thread-event-log
+slug: typed-ticket-thread-event-log
+title: Typed Ticket thread event log for workflow state changes
+status: open
+kind: task
+priority: P1
+labels: [ticket, orchestration, state, audit]
+created_at: 2026-06-06T22:13:01Z
+updated_at: 2026-06-06T22:14:29Z
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+The explicit workflow state design moves current Ticket workflow state into frontmatter, but frontmatter alone only records the current value. The system also needs a small append-only audit trail explaining why state changed and which actor changed it.
+
+The current Ticket thread is too freeform to be a reliable workflow record. It tends to become a place for arbitrary comments and AI-generated prose, while still not clearly recording state transitions or Intake decisions.
+
+## Goal
+
+Make `thread.md` a concise typed event log for durable Ticket events, especially workflow state changes and Intake summaries, rather than a general conversation transcript.
+
+## Authority split
+
+- `item.md` frontmatter: current mechanical state authority.
+- `item.md` body: current human-readable Ticket snapshot: background, goal, requirements, non-goals, acceptance criteria.
+- `thread.md`: append-only typed event log explaining state transitions, important decisions, implementation reports, reviews, and close events.
+- Pod/session logs: full conversational/runtime transcript. Do not copy full Pod conversations into Ticket thread.
+
+## Event model
+
+Add or formalize typed thread events for at least:
+
+```text
+create
+state_changed
+intake_summary
+decision
+implementation_report
+review
+close
+```
+
+`comment` may remain for manual escape hatches if needed, but Orchestrator/Intake/panel workflow should not rely on freeform comments as the primary record.
+
+## State transition logging
+
+Every workflow state mutation should append a concise `state_changed` event containing at least:
+
+```text
+from
+to
+actor
+reason
+summary or refs
+```
+
+State transitions should be performed through backend APIs that update frontmatter and append the thread event as one logical mutation. Avoid separate call sites that can update frontmatter without an event or append an event without updating current state.
+
+## Intake logging
+
+Intake should not dump the full Intake Pod conversation into `thread.md`. When Intake materializes a Ticket or marks it `ready`, it should write a concise `intake_summary` event containing:
+
+- accepted user intent;
+- important clarified decisions;
+- requirements / acceptance criteria summary;
+- known non-goals;
+- unresolved questions, if any.
+
+The Ticket body should hold the current snapshot. The thread should hold the reason/history for how that snapshot became accepted.
+
+## Constraints
+
+- Keep events concise and bounded.
+- Do not persist hidden reasoning.
+- Do not paste raw transcripts by default.
+- Do not use thread events as the source of current workflow state; current state lives in frontmatter.
+- Do not store transient Pod activity as Ticket state.
+- Preserve existing historical thread records; do not mass-rewrite old history unless a migration explicitly requires it.
+
+## Relationship to explicit workflow state
+
+This ticket is a companion/prerequisite to `explicit-ticket-workflow-state`. That ticket defines the current-state fields and panel semantics. This ticket defines the audit/event-log mechanics so state transitions remain explainable without relying on noisy freeform thread prose.
+
+## Non-goals
+
+- Building a scheduler/lease system.
+- Replacing Pod/session logs.
+- Capturing full Intake conversations in Ticket records.
+- Rewriting all historical threads.
+- Changing public UI layout by itself.
+
+## Acceptance criteria
+
+- A typed event model exists for `state_changed` and `intake_summary` at minimum.
+- Workflow state changes have an API path that updates current state and appends a `state_changed` event together.
+- Intake-ready/materialization flow has a bounded `intake_summary` event path.
+- Panel/Orchestrator state changes do not rely on freeform comments for auditability.
+- Existing Ticket doctor/lint checks accept the new event types and reject malformed required fields where practical.
+- Documentation explains the split between current state, current Ticket snapshot, append-only thread events, and Pod/session transcripts.

.yoi/tickets/open/20260606-221301-typed-ticket-thread-event-log/thread.md

@@ -0,0 +1,18 @@
+<!-- event: create author: yoi ticket at: 2026-06-06T22:13:01Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---
+
+<!-- event: plan author: hare at: 2026-06-06T22:14:29Z -->
+
+## Plan
+
+Created as a companion split from `explicit-ticket-workflow-state`.
+
+This ticket owns making Ticket `thread.md` a concise typed append-only event log for workflow state transitions and Intake summaries, rather than a freeform transcript/comment sink. It should define/implement events such as `state_changed` and `intake_summary`, and provide backend APIs that keep frontmatter current state and thread transition events in sync.
+
+
+---