yoi/.yoi/tickets/open/20260608-110940-simplify-ticket-identity-fields/thread.md

作成

LocalTicketBackend によって作成されました。

---

Decision

Scope expansion: simplify core Ticket frontmatter, not only identity

Expand this Ticket beyond identity cleanup. The same simplification pass should also review and reduce the core Ticket frontmatter shape.

Unify status and workflow_state

The current split between local status and workflow_state creates an invalid two-axis state model. Combinations such as status: closed with workflow_state: inprogress are not meaningful.

Direction:

• Use one canonical lifecycle state field.
  • Final name can be state or retained as workflow_state, but there should not be both status and workflow_state as independent current fields.
• Treat open as a derived range of states rather than a stored independent status.
  • Example: open = planning | ready | queued | inprogress | done.
  • Terminal closed state should be represented by the same lifecycle model, e.g. closed or equivalent.
• Decide whether done and closed remain distinct.
  • done: implementation/review/merge complete, close/resolution may still be pending.
  • closed: resolution recorded and Ticket lifecycle ended.
• Revisit or remove the pending bucket/status. If a concept is still needed, define it as a lifecycle state such as deferred / parked, not as a second axis.
• Update path layout expectations if needed.
  • Directory buckets may be derived caches or UI grouping, but frontmatter should not duplicate contradictory state.

Remove kind

kind currently behaves like a single typed category but is a freeform string with unclear management and little semantic authority. Most Tickets are work items and can be described by their title/body.

Direction:

• Remove kind from the required/current schema unless a small typed enum with clear semantics is explicitly justified.
• Do not keep required freeform kind.
• If the title follows a convention such as area: verb object, it already communicates the work class better than an unconstrained kind: task field.

Remove labels

labels are useful for search, but without a registry/canonical vocabulary they create inconsistent taxonomy and can be confused with state, relation, risk, component, or priority.

Direction:

• Remove labels from the core required/current schema in this simplification pass.
• Do not use labels to represent state, dependency, blockers, risk, priority, or ownership.
• If tag-like search is needed later, add it as a separate feature with a project-managed registry/canonicalization model.
• Prefer descriptive titles and body content for search. A title convention such as component: concise action can carry much of the useful categorization without an unmanaged labels field.

Resulting target direction

The target core Ticket identity/frontmatter may be as small as:

id: 20260608-103842   # or path-derived primary key
title: component: concise action
state: planning
created_at: ...
updated_at: ...

Additional fields should justify a concrete behavior. Search/display hints without management authority should be removed or moved to separately designed features.

---

Plan

Intake assessment: requirements sync needed

この Ticket は既存 identity simplification に加えて、status / workflow_state / kind / labels を含む core Ticket frontmatter simplification へ scope が拡張されている。方向性は明確だが、実装前に schema/API/UX と移行方針として固定すべき判断が残っているため、現時点では workflow_state: planning のまま requirements sync が必要。

既に決まっていること

• canonical Ticket identity は title-derived slug words を含めない timestamp/counter primary key へ寄せる。
• slug は required/current frontmatter および canonical lookup key から外す。
• agents / Orchestrator は ID/title だけから意味を推測せず、routing/実装前に TicketShow の body/thread/artifacts を読む。
• core frontmatter simplification は identity だけでなく lifecycle/kind/labels も対象に含める。
• kind は required freeform field として残さない方向。
• labels は unmanaged taxonomy として core required/current schema から外す方向。

実装前に固定すべき open questions

1. lifecycle field の最終名を state に変更するか、既存名 workflow_state を保持して single lifecycle field にするか。
2. done と closed を distinct lifecycle states として残すか、close/resolution の表現をどう統合するか。
3. pending bucket/status を完全に廃止するか、deferred / parked などの lifecycle state として置き換えるか。
4. canonical ID を frontmatter に id として保持するか、directory name から derive するか。
5. legacy slug/path lookup を migration-only としてどこまで読むか。unreleased local data として一括 migration し、current schema では permanent alias を作らない方針でよいか。
6. kind / labels removal をこの Ticket の実装 scope に含めて同時 migration するか、identity/lifecycle の破壊的変更と分けるか。

Risk flags / reviewer focus

• ticket-schema
• storage-migration
• workflow-state
• panel-actions
• orchestrator-routing
• backward-compatibility
• typed-tool-api

Reviewer は diff だけでなく、CLI / typed Ticket tools / Panel / Orchestrator routing / local role-session claims / future relation metadata が、slug や two-axis state を authority として残していないことを確認する必要がある。

次の Intake action

上記 open questions に user/maintainer decision が入れば、Ticket を implementation_ready として ready にできる。未回答のまま進める場合は、先に design/spike として routing し、実装 Ticket とは分けるのが安全。

---

Decision

User decision: target Ticket schema and storage shape

User/maintainer decision for this Ticket:

• Lifecycle field は state に統一する。status と workflow_state の二軸 current state は廃止する。
• done と closed は一旦 distinct states として分離したままにする。
  • done: 実装・review・merge 等は完了しているが、resolution/close 処理前の状態。
  • closed: resolution が記録され、Ticket lifecycle が終了した状態。
• pending は不要。pending bucket/status は current model から削除する。
• filesystem layout は状態 bucket を持たず、すべて平坦に .yoi/tickets/<ticket-id>/ に置く。
  • open/pending/closed directory bucket は authority ではなくなり、current layout からも外す。
• canonical Ticket ID は directory name から derive し、frontmatter には id を重複保存しない。
• kind / labels 等の core frontmatter 削除もこの Ticket の scope に含める。

Updated target direction

Current frontmatter は少なくとも以下へ縮小する方向で実装する。

title: component: concise action
state: planning
created_at: ...
updated_at: ...

Canonical identity は .yoi/tickets/<ticket-id>/ の <ticket-id>。slug、frontmatter id、directory bucket、freeform kind、unmanaged labels は current schema authority から外す。

Implementation latitude

• Timestamp/counter ID の exact format、collision suffix、高解像度 timestamp のどれを使うかは、opaque ID・安定 lookup・testability を満たす範囲で実装側が選べる。
• Existing local records は新 layout/schema に migration する。unreleased local data として扱い、明示的に必要にならない限り permanent slug alias や旧 bucket layout の長期互換層は作らない。
• priority、action_required、attention_required、queued_at 等の周辺 field は、削除・置換・維持の判断を「具体的な現在動作を持つか」で監査し、core identity/lifecycle simplification を歪めない範囲で扱う。

Reviewer focus

Reviewer は、CLI / typed Ticket tools / Panel / role-session claims / Orchestrator guidance / relation metadata が、旧 slug、frontmatter id、status/workflow_state 二軸、open/pending/closed bucket を authority として残していないことを重点確認する。

---

Intake summary

Ticket schema simplification の binding decisions が揃った。Lifecycle は state に統一し、done と closed は一旦分離、pending は廃止する。Filesystem layout は .yoi/tickets/<ticket-id>/ の平坦構造にし、canonical ID は directory name から derive して frontmatter に重複保存しない。slug、frontmatter id、freeform kind、unmanaged labels、open/pending/closed bucket、status/workflow_state 二軸 state は current schema authority から外す。実装前に Orchestrator/Coder は CLI・typed tools・Panel・role-session claims・Orchestrator guidance・relation metadata の旧 identity/state 依存を監査し、local records を新 layout/schema に migrate すること。

---

State changed

必要な schema/lifecycle/storage layout の判断が user decision として記録されたため、Orchestrator が実装 routing できる状態になった。

---

State changed

Ticket を workspace-panel が queued にしました。

---

State changed

Accepted queued implementation after reading the Ticket body/thread, binding user decisions from Intake, current workspace state, and visible worktree/Pod state. No active implementation worktree remains. This is high-risk/broad Ticket schema/storage migration, but the required decisions are explicit enough to proceed with strict implementation invariants, migration evidence, and reviewer focus rather than returning to planning.

---

Decision

Routing decision: implementation_ready

Evidence checked:

• Ticket body, expanded scope decision, Intake assessment, user binding decision, Intake summary, and queued event.
• Current workspace state: clean after committing queued event.
• Worktree list: only main workspace, no active implementation worktree.
• Visible Pods: no active sibling coder/reviewer from previous work remains.

Reason:

• This is a broad and high-risk schema/storage migration, but the Ticket now contains explicit binding decisions for identity, lifecycle, path layout, and core frontmatter simplification.
• Returning to planning would need a concrete missing decision; after reading the Ticket/thread, the main open questions have user decisions.
• Proceed with a strict audit-first implementation and reviewer focus.

IntentPacket:

Intent:

• Simplify current Ticket identity/storage/frontmatter around path-derived opaque timestamp/counter IDs, a single lifecycle state, and minimal current frontmatter, while migrating local Ticket records and updating all current Ticket surfaces.

Binding decisions / invariants:

• Canonical Ticket identity is the directory name under flat .yoi/tickets/<ticket-id>/.
• The canonical ID must be opaque timestamp/counter style and must not include title/slug words.
• Frontmatter must not duplicate canonical identity as current id.
• slug is not a required/current field and is not a canonical lookup key.
• status and workflow_state must not remain independent current state axes; use one canonical lifecycle field named state.
• done and closed remain distinct states for now:
  • done: implementation/review/merge complete but resolution/close handling not yet final;
  • closed: resolution recorded and Ticket lifecycle ended.
• pending bucket/status is removed from the current model.
• Current filesystem layout is flat .yoi/tickets/<ticket-id>/, not .yoi/tickets/{open,pending,closed}/....
• kind and unmanaged labels are removed from current required/core frontmatter.
• New Ticket records should use minimal current frontmatter, approximately title, state, created_at, updated_at plus only fields with concrete current behavior that survive audit.
• Existing local .yoi/tickets records must be migrated to the new layout/schema.
• Permanent slug aliases / long-term old bucket compatibility should not be added unless a concrete current requirement is discovered; this is unreleased local data.
• Exact canonical ID lookup remains; title/search UX may be list/search-oriented but must not make slug canonical.
• Panel actions, role/session claims, tool/API outputs, Ticket doctor, CLI, Orchestrator guidance, and future relation/orchestration-plan references must use canonical IDs, not slug/path-derived title words.
• Agents/Orchestrator guidance must reinforce reading TicketShow body/thread/artifacts before routing/implementation; do not infer requirements from ID/title alone.
• Do not implement full typed Ticket relation metadata here.
• Do not remove title.
• Do not change Pod protocol/history/session semantics except where Ticket storage references are legitimately updated.

Implementation latitude:

• Coder may choose timestamp collision strategy (counter suffix or higher-resolution timestamp) if deterministic/testable and ID remains opaque.
• Coder may keep tightly scoped migration-only parser/lookup helpers if needed to read old local records during migration, but current writers/tools/docs must emit/use the new schema/layout.
• Coder may split implementation internally into commits if useful, but should report a coherent final branch state.
• Coder should stop and report if the change proves too large to keep the repository buildable or if a hidden external compatibility requirement requires long-term legacy aliases.

Reviewer focus:

• Verify there is no old authoritative dependency on slug, frontmatter id, open/pending/closed buckets, status/workflow_state two-axis state, freeform kind, or unmanaged labels in current CLI/tools/panel/backend/claims/docs.
• Verify local record migration is complete and ticket doctor validates the new flat layout/schema.
• Verify exact lookup and user-facing display remain usable with id + title.
• Verify close/resolution semantics distinguish done vs closed as decided.
• Verify legacy compatibility is migration-only and does not reintroduce permanent slug authority.

Escalate if:

• Implementation requires a broad backward-compatibility layer for old slug/bucket layouts.
• The change cannot keep the repo in a buildable state while migrating records.
• Existing code depends on old directory buckets in a way that requires a larger storage-provider redesign.
• Tool schema changes would require external plugin/capability redesign beyond Ticket built-in tools.

Validation:

• Focused Ticket backend/parser/writer/doctor/create/list/show/query tests for flat layout, path-derived ID, state, collision handling, and migrated records.
• Focused tool schema/output tests for TicketCreate/List/Show/WorkflowState/Close/Status-equivalent behavior.
• Focused panel/role-session/orchestrator guidance tests where surfaces changed.
• cargo fmt --check.
• git diff --check.
• cargo run -q -p yoi -- ticket doctor or the new equivalent if command behavior changes.
• cargo check --workspace.
• nix build .#yoi.

---

Implementation report

Implementation routing started.

Worktree/branch:

• Worktree: .worktree/simplify-ticket-identity-fields
• Branch: simplify-ticket-identity-fields
• Base/routing commit: 48efcc7 ticket: route identity simplification

Spawned sibling Coder Pod:

• coder-simplify-ticket-identity-fields
• Scope: non-recursive read on parent workspace root plus recursive write limited to the child worktree.

Routing context:

• The workspace was clean and no active implementation worktree existed before acceptance.
• This is a broad/high-risk schema/storage migration, so the handoff emphasizes audit-first implementation, complete local Ticket record migration, buildable coherent stopping points, and escalation if permanent legacy compatibility or a larger storage-provider redesign is discovered.

---