ticket: record queued intake updates
This commit is contained in:
parent
939ba16e8d
commit
87d89bfa5c
|
|
@ -6,7 +6,7 @@ status: open
|
|||
kind: task
|
||||
priority: P2
|
||||
labels: [pod, panel, cli, lifecycle, metadata]
|
||||
workflow_state: 'queued'
|
||||
workflow_state: 'planning'
|
||||
created_at: 2026-06-07T23:45:30Z
|
||||
updated_at: '2026-06-08T03:49:14Z'
|
||||
assignee: null
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@ status: 'open'
|
|||
kind: 'task'
|
||||
priority: 'P1'
|
||||
labels: ['ticket', 'orchestrator', 'planning', 'workflow', 'prompt']
|
||||
workflow_state: planning
|
||||
workflow_state: 'ready'
|
||||
created_at: '2026-06-08T07:17:22Z'
|
||||
updated_at: '2026-06-08T07:17:22Z'
|
||||
updated_at: '2026-06-08T10:58:29Z'
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
|
|
|||
|
|
@ -5,3 +5,55 @@
|
|||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: intake at: 2026-06-08T10:58:22Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
Intake refinement: implementation_ready
|
||||
|
||||
Context checked:
|
||||
- Target Ticket body/thread.
|
||||
- `replace-intake-state-with-planning` resolution: planning-state model is settled and `ready|queued -> planning` now requires audited typed state-change reasons.
|
||||
- `allow-spawnpod-child-workspace-cwd` resolution: confirms the motivating authority-adjacent example was risky but sufficiently specified and should be treated as reviewer focus when binding decisions exist.
|
||||
- Current `.yoi/workflow/ticket-orchestrator-routing.md`: already contains the routing surface to refine, including `return_to_planning`, `implementation_ready`, `Evidence checked`, and IntentPacket sections.
|
||||
|
||||
Binding decisions / invariants:
|
||||
- Returning a ready/queued Ticket to `planning` must require a concrete missing decision/information item after bounded relevant context checking.
|
||||
- Risk flags and risky domains are context lookup triggers and reviewer-focus signals, not stop gates.
|
||||
- If no concrete gap can be named after context checking, risky-but-specified Tickets should route as `implementation_ready` when other criteria are satisfied.
|
||||
- The routing decision record must expose checked evidence and explain why any gap cannot be safely handled as implementation latitude.
|
||||
- Do not reintroduce a separate readiness/preflight lane or operation.
|
||||
|
||||
Implementation latitude:
|
||||
- Implementation may choose whether to refine only `.yoi/workflow/ticket-orchestrator-routing.md`, related prompt resources, focused tests, or all of those if the current code layout requires it.
|
||||
- Wording and test structure may be chosen locally as long as the policy is explicit and reviewer can verify the acceptance criteria.
|
||||
|
||||
Escalation conditions:
|
||||
- Escalate if implementation would change the workflow-state graph or Ticket lifecycle semantics beyond the documented `planning -> ready -> queued -> inprogress -> done` model.
|
||||
- Escalate if enforcing evidence recording requires new public API/tool schema changes rather than workflow/prompt/test updates.
|
||||
- Escalate if the existing prompt/workflow guidance is already fully compliant and no meaningful code/resource change is needed; record a close-ready/no-op dossier instead of manufacturing churn.
|
||||
|
||||
Validation:
|
||||
- `target/debug/yoi ticket doctor`
|
||||
- `git diff --check`
|
||||
- Focused prompt/workflow validation or tests covering: risky but specified Ticket -> implementation-ready; genuinely missing decision -> return to planning; risk flag alone is insufficient as the reason.
|
||||
- `nix build .#yoi` if runtime resources, prompts, code, or packaging inputs change.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: intake_summary author: intake at: 2026-06-08T10:58:29Z -->
|
||||
|
||||
## Intake summary
|
||||
|
||||
既存 Ticket を重複作成せず refinement した。`replace-intake-state-with-planning` の完了により前提は満たされており、対象 Ticket は Orchestrator routing guidance の bounded context check policy として implementation_ready。binding invariants、implementation latitude、escalation conditions、validation を thread に補足済み。未決定の blocking question はない。risk flags は workflow/prompt、orchestrator-routing、planning-state、authority-boundary/context-check。
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: intake at: 2026-06-08T10:58:29Z from: planning to: ready reason: intake_ready field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Intake refinement completed. Ticket has enough intent, acceptance criteria, binding invariants, implementation latitude, escalation conditions, and validation guidance for Orchestrator routing.
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -0,0 +1,82 @@
|
|||
---
|
||||
id: '20260608-103133-tui-chat-markdown-table-rendering'
|
||||
slug: 'tui-chat-markdown-table-rendering'
|
||||
title: 'TUI chat view should render Markdown tables'
|
||||
status: 'open'
|
||||
kind: 'bug'
|
||||
priority: 'P2'
|
||||
labels: ['tui', 'chat', 'markdown', 'rendering', 'ux']
|
||||
workflow_state: 'ready'
|
||||
created_at: '2026-06-08T10:31:33Z'
|
||||
updated_at: '2026-06-08T10:31:40Z'
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
risk_flags: ['tui-rendering', 'markdown']
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
チャットビューの TUI で、Markdown の Table が描画できない問題がある。会話内の Markdown 出力に表が含まれると、ユーザーが内容を読み取りづらくなり、LLM が表形式で整理した結果や比較情報を TUI 上で確認しにくい。
|
||||
|
||||
既存 Ticket を確認した範囲では、同じ目的の open Ticket は見当たらない。関連する過去作業として TUI 会話表示・履歴表示・描画境界の修正 Ticket はあるが、本件は Markdown Table 描画の不具合として独立に扱う。
|
||||
|
||||
## Requirements
|
||||
|
||||
- TUI の通常のチャット / conversation view で、Markdown の pipe table を読み取り可能に描画できること。
|
||||
- Assistant 出力に含まれる Markdown Table が、raw text の崩れ・欠落・不正な折り返し・表示不能として扱われないこと。
|
||||
- 表の描画は TUI の既存のスクロール、折り返し、会話履歴表示、色/スタイル規則と整合すること。
|
||||
- Markdown Table 非対応が原因で message 全体の描画が壊れないこと。
|
||||
- 修正は表示層の問題として扱い、Pod history / session log / LLM context の内容は変更しないこと。
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- 少なくとも以下のような Markdown Table を含む assistant message が TUI チャットビューで読み取り可能に表示される。
|
||||
|
||||
```markdown
|
||||
| Item | Status |
|
||||
| --- | --- |
|
||||
| A | done |
|
||||
| B | pending |
|
||||
```
|
||||
|
||||
- Table を含まない既存 Markdown / plain text message の表示が退行しない。
|
||||
- 幅の狭い terminal でも、表を含む message が panic や行欠落を起こさず、既存の折り返し/切り詰め方針に従って表示される。
|
||||
- 表の描画ロジックに対する unit / snapshot-like test、または明確な手動確認手順が残っている。
|
||||
|
||||
## Binding decisions / invariants
|
||||
|
||||
- これは chat view の Markdown 表示不具合であり、Ticket panel / `yoi ticket show` / docs rendering / WebFetch extraction の仕様変更として扱わない。
|
||||
- 表示のために session history、Pod metadata、worker history、prompt context を書き換えない。
|
||||
- Markdown Table の完全な GitHub Flavored Markdown 互換性をこの Ticket の必須要件にしない。まず通常の pipe table が読み取り可能に表示されることを優先する。
|
||||
- 表示不能な入力があっても TUI 全体や message block の描画を壊さず、既存の graceful fallback 方針に従う。
|
||||
|
||||
## Implementation latitude
|
||||
|
||||
- 既存の Markdown rendering path に table support を追加するか、table を readable plain-text fallback として整形するかは実装者が選んでよい。
|
||||
- Column width 計算、alignment marker の扱い、cell wrapping の詳細は、既存 TUI の制約と実装コストに合わせて選んでよい。
|
||||
- 実装調査の結果、Markdown renderer / ratatui widget / line wrapping の責務境界に問題が見つかった場合は、最小の設計整理を含めてよい。
|
||||
|
||||
## Readiness
|
||||
|
||||
- readiness: implementation_ready
|
||||
- risk_flags: [tui-rendering, markdown]
|
||||
- open_questions: []
|
||||
|
||||
## Escalation conditions
|
||||
|
||||
- Table support を入れるために Markdown parser の大きな依存追加や public API 変更が必要になる場合は、実装前に Orchestrator / maintainer に戻す。
|
||||
- Chat view 以外の TUI surfaces へ広く影響する rendering abstraction 変更が必要になる場合は、範囲拡大として判断を求める。
|
||||
- GFM 完全互換を目指す必要が出た場合は、本 Ticket の bug fix 範囲を超えるため別 Ticket または設計判断に切り出す。
|
||||
|
||||
## Validation
|
||||
|
||||
- 関連する TUI / Markdown rendering unit tests を追加または更新する。
|
||||
- `cargo test` で関連 crate のテストを通す。
|
||||
- TUI/package/runtime resource に関わる変更のため、完了前に `nix build .#yoi` で package build を確認する。
|
||||
- 必要なら、Table を含むサンプル message を TUI で表示する手動確認手順を実装報告に残す。
|
||||
|
||||
## Related work
|
||||
|
||||
- `20260601-013132-tui-new-session-first-message-missing`: TUI 会話ビュー表示の既存修正。
|
||||
- `20260531-074258-tui-move-view-mode-state`: single-Pod display/history mode の state/render boundary 整理。
|
||||
- `20260606-060548-workspace-panel-layout-display-tuning`: panel 側の layout/display tuning。対象 surface は異なるため duplicate ではない。
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
<!-- event: create author: LocalTicketBackend at: 2026-06-08T10:31:33Z -->
|
||||
|
||||
## 作成
|
||||
|
||||
LocalTicketBackend によって作成されました。
|
||||
|
||||
---
|
||||
|
||||
<!-- event: intake_summary author: intake at: 2026-06-08T10:31:40Z -->
|
||||
|
||||
## Intake summary
|
||||
|
||||
チャットビューの TUI で Markdown pipe table が読み取り可能に描画できない不具合を bug Ticket として整理した。対象 surface は通常の chat / conversation view に限定し、session history / Pod metadata / worker history / prompt context は変更しないことを invariant とした。通常の pipe table 表示、既存 Markdown/plain text の非退行、狭い terminal での安全な表示、関連テストまたは手動確認を受け入れ条件にしている。
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: intake at: 2026-06-08T10:31:40Z from: planning to: ready reason: planning_ready field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
要件・受け入れ条件・invariant・validation が揃っており、Orchestrator が implementation routing できる状態になった。
|
||||
|
||||
---
|
||||
|
|
@ -6,11 +6,13 @@ status: 'open'
|
|||
kind: 'task'
|
||||
priority: 'P1'
|
||||
labels: ['ticket', 'schema', 'migration', 'cleanup']
|
||||
workflow_state: 'planning'
|
||||
workflow_state: 'queued'
|
||||
created_at: '2026-06-08T10:38:42Z'
|
||||
updated_at: '2026-06-08T10:38:42Z'
|
||||
updated_at: '2026-06-08T11:21:33Z'
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
queued_by: 'workspace-panel'
|
||||
queued_at: '2026-06-08T11:21:33Z'
|
||||
---
|
||||
|
||||
## Background
|
||||
|
|
|
|||
|
|
@ -4,4 +4,69 @@
|
|||
|
||||
LocalTicketBackend によって作成されました。
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: intake at: 2026-06-08T10:57:37Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
## Intake refinement
|
||||
|
||||
readiness は `implementation_ready`。既存 Ticket の目的・受け入れ条件・除外範囲は十分に具体的で、Orchestrator が実装 routing できる。
|
||||
|
||||
### Binding decisions / invariants
|
||||
|
||||
- `legacy_ticket` と `needs_preflight` は current Ticket schema / tool input / tool output / CLI output / frontmatter writer / doctor requirements から削除する。通常の新規 Ticket 作成経路で再び出力してはいけない。
|
||||
- `workflow_state: intake` は互換 alias として残さず、parser / doctor / tests で invalid として扱う。
|
||||
- `workflow_state` 未指定時の bounded migration fallback を残す場合でも、`intake` 語彙を復活させてはいけない。
|
||||
- `.yoi/tickets/**/item.md` の current frontmatter は stricter schema に合わせて移行する。`thread.md` / `resolution.md` の過去本文に残る語は audit history として扱い、通常は書き換えない。
|
||||
- `legacy_ticket` の代替として generic external issue link field を追加しない。関係メタデータは別 Ticket `typed-ticket-relation-metadata` の範囲とする。
|
||||
|
||||
### Implementation latitude
|
||||
|
||||
- 実装者は parser / writer / metadata structs / tool schemas / panel view model / tests / prompts / docs のどこから整理するかを選んでよい。
|
||||
- 移行専用の一時的な読み取り経路が必要な場合は、current API surface に露出しない bounded migration path に限定してよい。
|
||||
- fixture や local Ticket record の更新方法は手動・補助スクリプトのどちらでもよいが、差分は schema 変更に必要な範囲へ限定する。
|
||||
|
||||
### Escalation conditions
|
||||
|
||||
- 非 null の `legacy_ticket` 値を削除することで保持すべき current relation 情報が失われると判断した場合は、代替フィールドを silently 追加せず Orchestrator / human に戻す。
|
||||
- `needs_preflight` または `workflow_state: intake` をまだ実行時互換として保持すべき外部利用者が見つかった場合は、後方互換要件として戻す。
|
||||
- 変更が Ticket schema 以外の authority boundary / role workflow semantics に広がる場合は、別 Ticket 化または routing 判断を求める。
|
||||
|
||||
### Validation focus
|
||||
|
||||
- `yoi ticket doctor` が stricter schema の local records で通ること。
|
||||
- `TicketCreate` / `TicketShow` / `TicketList` / panel 表示に `legacy_ticket` と `needs_preflight` が current field として出ないこと。
|
||||
- `workflow_state: intake` を invalid とする focused test を追加または更新すること。
|
||||
- 既存指示どおり、実装完了時は focused tests、`cargo fmt --check`、`git diff --check`、必要に応じて `nix build .#yoi` で確認すること。
|
||||
|
||||
Open questions: なし。
|
||||
Risk flags: `ticket-schema`, `migration`, `tool-api`, `panel-output`, `docs-prompts`.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: intake_summary author: intake at: 2026-06-08T10:57:43Z -->
|
||||
|
||||
## Intake summary
|
||||
|
||||
既存 Ticket を精査し、obsolete な `legacy_ticket` / `needs_preflight` と `workflow_state: intake` 互換の削除範囲を実装可能な契約として整理した。binding decisions は current schema/tool/API/panel/docs/prompts から legacy fields を削除し、`intake` alias を拒否すること。historical thread/resolution prose は audit history として通常は保持する。Open questions はなく、risk flags は ticket-schema / migration / tool-api / panel-output / docs-prompts。
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: intake at: 2026-06-08T10:57:43Z from: planning to: ready reason: intake_ready field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Intake refinement が完了し、Orchestrator が routing できる状態になったため `ready` に変更する。
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: workspace-panel at: 2026-06-08T11:21:33Z from: ready to: queued reason: queued field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Ticket を `workspace-panel` が queued にしました。
|
||||
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -0,0 +1,106 @@
|
|||
---
|
||||
id: '20260608-110940-simplify-ticket-identity-fields'
|
||||
slug: 'simplify-ticket-identity-fields'
|
||||
title: 'Simplify Ticket identity to timestamp key and title'
|
||||
status: 'open'
|
||||
kind: 'task'
|
||||
priority: 'P1'
|
||||
labels: ['ticket', 'schema', 'identity', 'migration', 'orchestrator']
|
||||
workflow_state: 'planning'
|
||||
created_at: '2026-06-08T11:09:40Z'
|
||||
updated_at: '2026-06-08T11:15:09Z'
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
The current Ticket identity/frontmatter shape carries overlapping identity/display fields:
|
||||
|
||||
```yaml
|
||||
id: 20260608-103842-remove-legacy-ticket-schema-fields
|
||||
slug: remove-legacy-ticket-schema-fields
|
||||
title: Remove legacy Ticket schema fields and intake compatibility
|
||||
```
|
||||
|
||||
This makes the ID and slug semantically rich enough that agents may infer meaning from the identifier instead of reading the authoritative Ticket body/thread. It also duplicates the role of `title`: the slug is a second human-readable label, and the current ID is timestamp plus slug.
|
||||
|
||||
A GitHub-Issue-like model may be cleaner:
|
||||
|
||||
```text
|
||||
primary key: opaque timestamp/counter ID
|
||||
title: human-readable summary
|
||||
body/thread: authoritative requirements and history
|
||||
```
|
||||
|
||||
The desired direction is to make Ticket identity mostly opaque and force both humans and agents to follow `id -> TicketShow -> body/thread/artifacts` for real meaning.
|
||||
|
||||
## Goal
|
||||
|
||||
Redesign Ticket identity/frontmatter around a timestamp primary key plus title, removing slug as a required/current identity field and avoiding title-derived meaning in the canonical ID.
|
||||
|
||||
## Proposed direction
|
||||
|
||||
- Use a timestamp-based primary key as the canonical Ticket ID.
|
||||
- Example: `20260608-103842`.
|
||||
- If collision is possible, use a deterministic suffix such as `20260608-103842-2` or a higher-resolution timestamp.
|
||||
- Store Tickets under directories named by that primary key only:
|
||||
- `.yoi/tickets/open/20260608-103842/`
|
||||
- Keep `title` as the human-readable display summary.
|
||||
- Remove `slug` from required frontmatter and from canonical lookup semantics.
|
||||
- Consider whether `id` must remain in frontmatter or can be derived from the directory name.
|
||||
- Option A: keep `id: 20260608-103842` for file self-description and doctor path checks.
|
||||
- Option B: remove `id` from frontmatter and make directory name authoritative.
|
||||
- Do not include title/slug words in the canonical ID.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Audit current uses of `id`, `slug`, and title-derived directory names across:
|
||||
- Ticket backend create/list/show/query;
|
||||
- Ticket tools;
|
||||
- CLI;
|
||||
- Panel/TUI;
|
||||
- role/session registry and local claims;
|
||||
- Orchestrator prompts/workflows;
|
||||
- future relation metadata assumptions.
|
||||
- Define the canonical Ticket reference format.
|
||||
- Prefer opaque timestamp/counter ID.
|
||||
- Exact lookup should use canonical ID.
|
||||
- If title search is needed, provide search/list UX rather than making slug canonical.
|
||||
- Remove `slug` as a required current field.
|
||||
- New Tickets should not require or write `slug` unless a deliberate display/search alias is kept separately.
|
||||
- `ticket doctor` should not require `slug` if the new schema removes it.
|
||||
- Existing local records should be migrated.
|
||||
- Decide whether `id` remains in frontmatter.
|
||||
- If retained, it must be the opaque primary key and match the directory name.
|
||||
- If removed, update doctor/show/list to derive it from the directory path.
|
||||
- Update `TicketShow` / `TicketList` / Panel display to present `id + title` rather than `id + slug + title`.
|
||||
- Update query behavior.
|
||||
- Exact ID lookup remains.
|
||||
- Slug lookup should be removed or treated as legacy/migration-only.
|
||||
- Title search, if needed, should be explicit and bounded rather than ambiguous exact slug matching.
|
||||
- Update typed Ticket relations design to reference canonical ID, not slug.
|
||||
- Update AI/Orchestrator guidance:
|
||||
- do not infer Ticket meaning from ID/title alone;
|
||||
- always read `TicketShow` body/thread/artifacts before routing, accepting, returning to planning, or implementing.
|
||||
- Migrate current local `.yoi/tickets` records and path layout.
|
||||
- Example: `20260608-103842-remove-legacy-ticket-schema-fields` -> `20260608-103842`.
|
||||
- Preserve Git history through normal commit; no special backward compatibility for unreleased local data unless explicitly required.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Designing full typed Ticket relation metadata; this ticket should only ensure relation metadata will use canonical opaque IDs later.
|
||||
- Removing `title`.
|
||||
- Replacing full-text/list/search UX with ID-only workflows.
|
||||
- Preserving slug as a permanent compatibility alias unless explicitly justified.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- New Ticket records use an opaque timestamp/counter primary key and title, without title words in the canonical ID.
|
||||
- `slug` is no longer a required current frontmatter field or canonical lookup key.
|
||||
- `TicketList` and `TicketShow` display the simplified identity clearly.
|
||||
- Agents cannot reasonably infer Ticket requirements from canonical ID alone.
|
||||
- Ticket lookup, Panel actions, role/session claims, and future relation metadata use canonical ID.
|
||||
- Local Ticket records are migrated to the simplified identity schema.
|
||||
- Tests cover create, lookup, doctor, duplicate/collision handling, and migration-relevant parsing.
|
||||
- `target/debug/yoi ticket doctor`, focused tests, `cargo fmt --check`, and `git diff --check` pass.
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
<!-- event: create author: LocalTicketBackend at: 2026-06-08T11:09:40Z -->
|
||||
|
||||
## 作成
|
||||
|
||||
LocalTicketBackend によって作成されました。
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-08T11:15:09Z -->
|
||||
|
||||
## 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:
|
||||
|
||||
```yaml
|
||||
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.
|
||||
|
||||
---
|
||||
Loading…
Reference in New Issue
Block a user