Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
ecdc52fce9
yoi/.yoi/tickets/00001KVMT2J25/thread.md

20 KiB
Raw Blame History

作成

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

State changed

Panel returned ready Ticket 00001KVMT2J25 to planning for requirements sync. This is not Queue routing and must not start implementation.

User refinement instruction

今あるフロントSPAをnodeからdenoにしたい。 https://hareworks.net/blog/tech/sveltekit-with-deno

Comment

Intake requirements sync result

対象 Ticket 00001KVMT2J25 の item/thread/artifacts と関連 Ticket/source を確認した結果、今回の refinement instruction はこの Ticket の既存スコープとは一致しないため、00001KVMT2J25 を ready に戻したり queue routing したりせず、requirements sync の結果としてここに記録する。

User claims / request snapshot

  • ユーザーは「今あるフロントSPAを node から deno にしたい」と述べた。
  • 参考 URL として https://hareworks.net/blog/tech/sveltekit-with-deno が提示された。

Confirmed facts / sources

  • 00001KVMT2J25 の item は「Attach mid-stream TUI client without losing in-flight content」で、protocol / pod / TUI reconnect / stream-state の実装 Ticket である。
  • 00001KVMT2J25 の thread には、Panel が ready から planning に戻した理由として上記 frontend/Deno refinement instruction が記録されている。
  • 関連する closed Ticket 00001KVMFFYVX は Workspace web control plane bootstrap で、SvelteKit static SPA skeleton を web/workspace に追加した作業である。
  • web/workspace/README.md は現在の package manager を npm とし、npm install, npm run check, npm run build を案内している。
  • web/workspace/package.json は SvelteKit static SPA の scripts / devDependencies を持ち、package-lock.json が存在する。
  • web/workspace/svelte.config.js は @sveltejs/adapter-static を使い、build/ に static output を出す設定である。
  • package.nix は web/workspace/node_modules, .svelte-kit, build を source filter から除外している。
  • devshell.nix には deno が含まれている。

Intake conclusion

  • この refinement は 00001KVMT2J25 の late-attach / stream-state work item とは別目的であり、同一 Ticket の requirements / acceptance criteria に混ぜると work item が破綻する。
  • 既存の frontend bootstrap Ticket 00001KVMFFYVX は closed であり、現在の npm 採用は当時の bootstrap decision / implementation detail として記録されている。Deno 移行は closed Ticket の再オープンではなく、別の concrete follow-up Ticket として扱うのが妥当。
  • 現時点では、ユーザーが「新規 Ticket を作成して」と明示していないため、duplicate/new Ticket は作成しない。

Candidate follow-up draft if user approves new Ticket

Title: Workspace web SPA の frontend tooling を npm/Node から Deno に移行する

Readiness: implementation_ready Risk flags: [frontend-tooling, packaging, nix-source-filter, validation]

Requirements:

  • web/workspace の開発・検証・build 手順を npm/Node 前提から Deno 前提へ移行する。
  • SvelteKit static SPA であること、Rust backend が business/API authority を持つこと、static output が web/workspace/build/ に出ることは維持する。
  • web/workspace/README.md の package manager / command guidance を Deno 前提に更新する。
  • lockfile と依存関係管理を Deno 前提で明確にし、古い npm lockfile/source-of-truth が残る場合は理由を明示する。
  • generated artifacts (node_modules, .svelte-kit, build など) が git/Nix package source に混入しない状態を維持する。

Acceptance criteria:

  • web/workspace の check/build が Deno command で成功する。
  • README と project files から、通常の frontend 作業者が Deno で install/check/build できることが分かる。
  • npm lockfile / npm scripts / Node-only guidance が不要なら削除され、必要なら Deno 移行後も残す理由が code/docs に明確である。
  • package.nix / devshell / repository hygiene が Deno 移行後の generated artifacts と矛盾しない。
  • 既存の Rust backend static serving assumptions と .yoi records as authority の境界を変えない。

Implementation latitude:

  • Deno project layout は deno.json / deno.lock / deno task を使う形でよい。
  • SvelteKit/Vite を Deno の npm compatibility で動かすか、最小限の package metadata を残すかは実装時に選んでよい。ただし source-of-truth と command guidance は曖昧にしない。

Validation:

  • cd web/workspace && deno task check
  • cd web/workspace && deno task build
  • git diff --check
  • packaging/source-filter を変更する場合は nix build .#yoi --no-link または Orchestrator が妥当と判断する同等確認

Next routing recommendation:

  • 00001KVMT2J25 はこの refinement では implementation_ready に戻さない。
  • ユーザーが Deno 移行の新規 Ticket 作成を承認した場合、上記 draft を別 Ticket として materialize する。
  • ユーザーがあくまで 00001KVMT2J25 の差し替えを望む場合は、既存 Ticket を repurpose するのではなく、Orchestrator/maintainer に cancel/close/replacement 方針の判断を戻す。

Intake summary

ユーザーから、Deno 移行 refinement は 00001KVMT2J25 に誤って付いたものであり、00001KVMT2J25 は ready に戻してよいとの明示指示があった。再確認したところ、00001KVMT2J25 の body は late attach / in-flight stream snapshot の concrete work item で、readiness は implementation_ready、blocking open question はない。Deno 移行は別 Ticket 00001KVMV03QY として作成済みであり、本 Ticket の要件には混ぜない。

State changed

Deno 移行 refinement は誤付与として分離済み。00001KVMT2J25 は元の protocol reconnect / unfinished block snapshot Ticket として Orchestrator routing 可能な ready 状態へ戻す。queue routing や implementation start は行わない。

State changed

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

Decision

Routing decision: implementation_ready

Reason:

  • Ticket body は in-flight LLM response reconnect snapshot の問題、affected blocks、protocol/pod/TUI relevant files、acceptance criteria、validation が具体化されている。
  • readiness: implementation_ready で、relations / orchestration plan に blocker はない。
  • Requirements sync で Deno refinement は誤付与として分離済みで、この Ticket は original protocol reconnect scope に戻されている。
  • 同時 queued の 00001KVMV03QY は frontend Deno tooling migration であり、この Ticket の protocol/pod/TUI stream-state work と主対象が異なるため並列実装可能と判断する。
  • Orchestrator worktree は clean on orchestration at b4786b40 で、対象 Ticket 用 worktree / branch は未作成。

Evidence checked:

  • Ticket body / thread / artifacts via TicketShow and direct item.md read。
  • TicketRelationQuery(00001KVMT2J25): no relations / blockers。
  • TicketOrchestrationPlanQuery(00001KVMT2J25): no records。
  • Orchestrator git state / worktree list / branch list checked from /home/hare/Projects/yoi/.worktree/orchestration only。
  • Bounded code map:
    • crates/protocol/src/lib.rs: Event::Snapshot, TextDelta, ThinkingDelta, ToolCallArgsDelta, serialization tests。
    • crates/pod/src/segment_log_sink.rs: committed LogEntry snapshot / live entry receiver。
    • crates/pod/src/controller.rs: direct broadcast of streaming deltas and current controller comments around stream reconstruction。
    • crates/pod/src/ipc/server.rs: connect-time snapshot event construction。
    • crates/tui/src/app.rs: restore_snapshot and live delta handling for text/thinking/tool-call args。

IntentPacket:

Intent:

  • Ensure late attach / reconnect during an in-flight LLM response can display already-generated unfinished text/thinking/tool-call args, then continue live deltas without gaps or duplicates。

Binding decisions / invariants:

  • Fix at protocol/pod state level, not TUI-only workaround。
  • Do not persist unfinished model output as finalized assistant history。
  • Do not mutate/replay provider stream itself。
  • Preserve committed session-log gap-free semantics。
  • Preserve post-run reconnect behavior from finalized Snapshot entries。
  • No hidden context/history injection。
  • Keep in-flight snapshot bounded and typed; if large/unbounded policy is required, escalate。

Requirements / acceptance criteria:

  • New client connecting during response sees unfinished assistant text, thinking/reasoning, and tool-call args generated before connect。
  • Live deltas after connect append to same logical block without missing or duplicated content。
  • Completed run reconnect still restores finalized transcript from normal Snapshot entries。
  • Snapshot/live boundary gap-free / duplicate-free behavior is tested。
  • TUI Snapshot restore + live delta handling has regression coverage。
  • Focused validation covers protocol/pod/TUI relevant paths。

Implementation latitude:

  • Add structured in_flight state to Event::Snapshot, or implement bounded/sequence replay buffer if cleaner。
  • Controller/Pod may keep current accumulators for text/thinking/tool-call args。
  • TUI may seed unfinished blocks from Snapshot and continue applying live deltas to the same block。
  • Wire compatibility should be minimal; prioritize type safety and maintainability。

Escalate if:

  • Design requires persisting unfinished output as durable history item。
  • In-flight snapshot state becomes large enough to need truncation/bounding policy beyond a straightforward current-turn accumulator。
  • Public protocol compatibility policy becomes a product decision。
  • Scope spreads to Dashboard/Pod list preview or broader UX surfaces beyond TUI/console attach。

Validation plan:

  • cargo fmt --check
  • Focused cargo test -p protocol roundtrip/serialization tests for snapshot in-flight state。
  • Focused cargo test -p pod tests for connect-time snapshot/live boundary and accumulator behavior。
  • Focused cargo test -p tui tests for snapshot seeding plus live delta continuation。
  • cargo check -p protocol -p pod -p tui
  • git diff --check
  • yoi ticket doctor。

State changed

Human authorized queue routing from Workspace Dashboard. Ticket has concrete acceptance criteria, no recorded blockers, and is semantically separate from the frontend Deno tooling Ticket, so Orchestrator accepts implementation.

Implementation report

Implementation start report:

  • Created child implementation worktree:
    • /home/hare/Projects/yoi/.worktree/00001KVMT2J25-inflight-snapshot
  • Created branch:
    • impl/00001KVMT2J25-inflight-snapshot
  • Base commit:
    • 155e039e ticket: route deno and inflight snapshot work
  • Confirmed tracked Ticket project records are visible in the child worktree。
  • Confirmed .yoi/memory has no tracked/untracked entries in the child worktree check。
  • Spawned sibling Coder Pod:
    • yoi-coder-00001KVMT2J25
  • Coder scope:
    • read: /home/hare/Projects/yoi
    • write: /home/hare/Projects/yoi/.worktree/00001KVMT2J25-inflight-snapshot

Parallelization note:

  • 00001KVMV03QY is active in a separate child worktree and targets frontend Deno tooling. This Ticket should stay limited to protocol/pod/TUI in-flight snapshot semantics。

Next action:

  • Wait for Coder implementation report, then spawn Reviewer read-only for the implementation diff。

Implementation report

Coder implementation report received from yoi-coder-00001KVMT2J25.

Implementation commit:

  • 74aca6f6 fix: snapshot in-flight stream state

Changed areas:

  • crates/protocol/src/lib.rs
    • Added typed InFlightSnapshot / InFlightBlock state on Event::Snapshot。
    • Added serialization/default compatibility coverage。
  • crates/pod/src/in_flight.rs
    • New in-flight accumulator for assistant text, thinking/reasoning, and tool-call args。
    • Snapshot/live boundary tests for no gap/duplicate。
  • crates/pod/src/controller.rs
    • Streaming callbacks update the in-flight accumulator and broadcast live deltas from the same path。
  • crates/pod/src/ipc/alerter.rs, crates/pod/src/ipc/server.rs
    • Connect-time snapshot now includes alerts plus typed in-flight stream state while subscribing live events。
  • crates/pod/src/pod.rs
    • Clears matching in-flight blocks once committed assistant items reach durable session log entries。
  • crates/tui/src/app.rs
    • Snapshot restore seeds unfinished assistant text/thinking/tool-call blocks。
    • Live deltas continue those seeded blocks。
    • Added regression coverage for snapshot seeding plus live continuation。
  • Other touched files update test Snapshot constructors for the new in_flight field。

Coder validation reported:

  • cargo fmt --all --check: passed
  • cargo test -p protocol: passed
  • cargo test -p protocol event_snapshot_in_flight_roundtrip_and_default: passed
  • cargo test -p pod in_flight: passed
  • cargo test -p pod subscribe_with_alerts_and_in_flight_snapshot_splits_snapshot_and_live_deltas: passed
  • cargo test -p tui: passed
  • cargo test -p tui snapshot_in_flight_blocks_continue_with_live_deltas: passed
  • cargo check -p protocol -p pod -p tui: passed
  • git diff --check: passed
  • target/debug/yoi ticket doctor: passed

Known unrelated validation note:

  • Full cargo test -p pod still fails on two prompt-resource assertion tests unrelated to this change:
    • prompt::catalog::tests::pod_orchestration_guidance_section_renders_resource_body
    • prompt::system::tests::pod_orchestration_guidance_is_included_for_pod_management_tools
    • Both assert missing text: worktree status, diff, and test results。

Orchestrator evidence checked:

  • Implementation worktree is clean on impl/00001KVMT2J25-inflight-snapshot。
  • HEAD is 74aca6f6。
  • Diff 155e039e..HEAD touches 17 protocol/pod/TUI files, adding crates/pod/src/in_flight.rs and updating Snapshot constructors/tests。
  • git diff --check 155e039e..HEAD produced no diagnostics。

Next action:

  • Route to read-only Reviewer Pod for acceptance review against the Ticket。

Comment

Review routing:

Spawned read-only Reviewer Pod:

  • yoi-reviewer-00001KVMT2J25-r1

Review target:

  • Worktree: /home/hare/Projects/yoi/.worktree/00001KVMT2J25-inflight-snapshot
  • Branch: impl/00001KVMT2J25-inflight-snapshot
  • Baseline: 155e039e
  • Implementation commit: 74aca6f6 fix: snapshot in-flight stream state
  • Diff: 155e039e..74aca6f6

Reviewer scope:

  • read-only /home/hare/Projects/yoi

Reviewer focus:

  • Snapshot/live subscription ordering is gap-free。
  • Seeded unfinished blocks and later live deltas do not duplicate content。
  • Accumulator lifecycle clears after durable assistant commit and does not leak across runs。
  • Tool-call args partial JSON string deltas accumulate correctly。
  • Thinking/reasoning blocks remain separated and safe。
  • Finished-run reconnect still restores finalized transcript normally。
  • No unfinished model output is persisted as finalized history。
  • TUI restore seeding is compatible with existing live delta handlers。

Orchestrator will wait for reviewer verdict before integration。

Review: request changes

Verdict: request_changes

確認範囲:

  • Ticket authority:
    • .yoi/tickets/00001KVMT2J25/item.md
    • .yoi/tickets/00001KVMT2J25/thread.md
  • Diff 155e039e..74aca6f6, including:
    • crates/protocol/src/lib.rs
    • crates/pod/src/in_flight.rs
    • crates/pod/src/controller.rs
    • crates/pod/src/ipc/alerter.rs
    • crates/pod/src/ipc/server.rs
    • crates/pod/src/pod.rs
    • crates/pod/src/segment_log_sink.rs
    • crates/tui/src/app.rs
    • constructor/test updates in pod/TUI/discovery/spawn/dashboard-related test files

Blocking issue:

  1. Snapshot/live boundary still has a gap for finalized assistant items committed between the session-log snapshot and the in-flight snapshot。

The implementation makes in-flight streaming deltas mostly gap-free by holding the in-flight mutex across subscribe/snapshot, but the full connection snapshot is not atomic across the committed session-log mirror and the new in-flight accumulator。

Relevant path:

  • crates/pod/src/ipc/server.rs:112 takes handle.sink.subscribe_with_snapshot() first。
  • crates/pod/src/ipc/server.rs:118-120 then subscribes/snapshots alerts + in-flight state。
  • crates/pod/src/pod.rs:182-191 persists an entry, clears matching in-flight state for LogEntry::AssistantItem, then publishes to the session-log sink。
  • crates/pod/src/segment_log_sink.rs:90-103 documents that AssistantItem is mirror-only and not live-broadcast。
  • crates/pod/src/segment_log_sink.rs:120-127 confirms only SegmentStart, UserInput, SystemItem, and Invoke are live-relevant。

Race:

  1. New client connects。
  2. Server snapshots session-log entries at N。
  3. LLM response finalizes and appends LogEntry::AssistantItem。
  4. append_entry clears the matching in-flight text/thinking block。
  5. SegmentLogSink::publish mirrors the AssistantItem, but does not broadcast it live。
  6. Server snapshots in-flight state, now empty/cleared。
  7. Client receives Event::Snapshot with no finalized assistant item in entries, no unfinished/finalized in-flight block, and no live committed assistant event forthcoming。

This violates the Ticket invariant that Snapshot and post-Snapshot live events must be gap-free and duplicate-free。

Required fix:

  • Make the connection snapshot atomic enough across session-log mirror and in-flight state, or otherwise ensure committed assistant items cannot disappear in this boundary。
  • Add an integrated regression test around session-log snapshot + in-flight snapshot + mirror-only assistant commit boundary。
  • Ensure the fix still avoids persisting unfinished output as final history and still does not duplicate content when final AssistantItem is included in committed snapshot。

Non-blocking concerns:

  • The suggested focused test name subscribe_with_alerts_and_in_flight_snapshot_splits_snapshot_and_live_deltas selected 0 tests; no matching test exists。Add/rename an integrated focused test so validation can target the boundary reliably。
  • Minor protocol doc issue: Greeting doc comment appears displaced so “Pod self-description...” now sits immediately before InFlightSnapshot in crates/protocol/src/lib.rs。Not blocking but should be cleaned up if easy。

Reviewer validation:

  • git diff --check 155e039e..HEAD: passed
  • cargo fmt --all --check: passed
  • cargo test -p protocol: passed, 40 tests
  • cargo test -p pod in_flight: passed selected tests
  • cargo test -p pod subscribe_with_alerts_and_in_flight_snapshot_splits_snapshot_and_live_deltas: selected 0 tests / no matching test
  • cargo test -p tui snapshot_in_flight_blocks_continue_with_live_deltas: passed
  • cargo test -p tui: passed, 367 tests
  • cargo check -p protocol -p pod -p tui: passed
  • target/debug/yoi ticket doctor: passed (doctor: ok)
  • Full cargo test -p pod: failed only on the two known unrelated prompt-resource assertion tests。

Worktree status:

  • Clean on impl/00001KVMT2J25-inflight-snapshot。