ticket: use base32 project record ids
This commit is contained in:
@@ -0,0 +1,96 @@
|
||||
# Delegation intent: workspace panel orchestrator lifecycle
|
||||
|
||||
## Classification
|
||||
|
||||
`implementation-ready` after the first action-model slice.
|
||||
|
||||
The action model slice added `yoi panel`, removed `--multi` as a user-facing launch route, and established no-Ticket behavior: if workspace Ticket config is absent, the panel suppresses Ticket UI and behaves as a Pod-centric dashboard. This lifecycle ticket should respect that boundary.
|
||||
|
||||
## Intent
|
||||
|
||||
When `yoi panel` opens in a Ticket-enabled workspace, ensure a workspace Orchestrator Pod exists or surface a bounded diagnostic explaining why it cannot be restored/spawned. The Orchestrator remains a background coordinator; closing the panel must not stop it, and Companion remains the foreground management target.
|
||||
|
||||
In a no-Ticket workspace, do not spawn/restore an Orchestrator and do not show Orchestrator/Ticket workflow affordances. The panel should remain equivalent to the old Pod-centric `--multi` behavior.
|
||||
|
||||
## Worktree / branch
|
||||
|
||||
- worktree: `/home/hare/Projects/yoi/.worktree/workspace-panel-orchestrator-lifecycle`
|
||||
- branch: `work/workspace-panel-orchestrator-lifecycle`
|
||||
|
||||
This ticket may read tracked `.yoi/tickets` records/design artifacts. Do not read or edit `.yoi/memory/`.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Derive the workspace Orchestrator Pod name from the workspace directory, e.g. `<dir-name>-orchestrator`.
|
||||
- Use a safe/stable Pod-name normalization compatible with existing Pod name constraints.
|
||||
- Add tests for common workspace names and edge cases.
|
||||
- On `yoi panel` open in a Ticket-enabled workspace:
|
||||
- if Orchestrator is already live, observe/report it as live;
|
||||
- if restorable, restore it through existing Pod restore semantics;
|
||||
- if missing and permitted, spawn it;
|
||||
- if restore/spawn is not possible, surface a bounded panel diagnostic.
|
||||
- Gate Orchestrator lifecycle on explicit Ticket config availability/usability.
|
||||
- If `.yoi/ticket.config.toml` is absent, skip Orchestrator lifecycle and show Pod-centric panel only.
|
||||
- If config exists but is malformed/unusable, surface a diagnostic rather than silently behaving as no-Ticket if practical in this slice.
|
||||
- Use existing Ticket role/profile configuration and role launcher where practical; do not hand-build role prompts/profiles inside TUI.
|
||||
- Preserve current Pod registry/restore/spawn semantics; do not duplicate registry logic.
|
||||
- Panel close must not stop the Orchestrator.
|
||||
- Do not make Orchestrator the foreground composer target by default.
|
||||
- Keep layout changes minimal; final display tuning is later.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Composer target switching / New Intake send.
|
||||
- Intake -> Orchestrator handoff payload.
|
||||
- Scheduler/lease/queue.
|
||||
- Automatic coder/reviewer spawning.
|
||||
- Final layout/display tuning.
|
||||
- Reintroducing `--multi`.
|
||||
|
||||
## Current code map
|
||||
|
||||
- `crates/tui/src/lib.rs`
|
||||
- `LaunchMode::Panel` path.
|
||||
- `crates/tui/src/single_pod.rs`
|
||||
- `run_panel(...)` loop around the panel/dashboard and nested Pod open behavior.
|
||||
- `crates/tui/src/multi_pod.rs`
|
||||
- current panel substrate, snapshot loading, rows/rendering/actions.
|
||||
- `crates/tui/src/workspace_panel.rs`
|
||||
- thin panel ViewModel / Ticket row model. Extend header/diagnostics as needed without making it a runtime authority.
|
||||
- `crates/client/src/ticket_role.rs`
|
||||
- Ticket role launcher path; prefer this for spawning role Pods if it fits panel lifecycle.
|
||||
- `crates/ticket/src/config.rs`
|
||||
- Ticket config detection/loading; use this to gate Ticket-enabled vs no-Ticket mode.
|
||||
- Existing Pod restore/list/spawn client APIs used by picker/multi/role launcher.
|
||||
|
||||
## Validation
|
||||
|
||||
Run at least:
|
||||
|
||||
- targeted TUI tests for name derivation and lifecycle decision logic;
|
||||
- `cargo test -p tui workspace_panel`;
|
||||
- `cargo test -p tui multi` or updated panel test names;
|
||||
- `cargo test -p client ticket_role` if role launcher code changes;
|
||||
- `cargo test -p yoi panel`;
|
||||
- `cargo check --workspace --all-targets`;
|
||||
- `cargo fmt --check`;
|
||||
- `git diff --check`;
|
||||
- `cargo build -p yoi`;
|
||||
- `target/debug/yoi ticket doctor`.
|
||||
|
||||
Run `nix build .#yoi --no-link` if feasible.
|
||||
|
||||
## Completion report
|
||||
|
||||
Report:
|
||||
|
||||
- worktree path / branch;
|
||||
- commit hash;
|
||||
- final Orchestrator Pod naming rule;
|
||||
- lifecycle decision behavior for live/restorable/missing/unavailable;
|
||||
- no-Ticket workspace behavior;
|
||||
- role launcher/profile usage;
|
||||
- diagnostics surfaced;
|
||||
- tests updated/added;
|
||||
- validation results;
|
||||
- known follow-up layout/display tuning items.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Workspace panel orchestrator lifecycle"
|
||||
state: "closed"
|
||||
created_at: "2026-06-05T21:07:04Z"
|
||||
updated_at: "2026-06-06T04:23:48Z"
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
The workspace orchestration panel needs a background Orchestrator Pod that is restored or spawned when the panel opens and remains alive after the panel closes.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Derive Orchestrator Pod name from workspace directory, e.g. `<dir-name>-orchestrator`.
|
||||
- On panel open:
|
||||
- restore if restorable;
|
||||
- attach/observe if already live;
|
||||
- spawn if missing and permitted.
|
||||
- Use `.yoi/ticket.config.toml` role profile for `orchestrator`.
|
||||
- Use the Ticket role launcher where practical.
|
||||
- Panel close must not stop the Orchestrator.
|
||||
- Surface lifecycle diagnostics in the panel.
|
||||
- Do not make Orchestrator the foreground composer target by default; Companion remains foreground management chat.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Full panel UI layout.
|
||||
- Intake handoff contract.
|
||||
- Scheduler/lease/queue.
|
||||
- Automatic coder/reviewer spawning.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Workspace panel startup can ensure an Orchestrator Pod exists or report why it cannot.
|
||||
- Orchestrator lifecycle uses existing Pod restore/spawn semantics and does not duplicate registry logic.
|
||||
- Tests cover name derivation and restore/spawn decision logic where practical.
|
||||
@@ -0,0 +1,32 @@
|
||||
Implemented workspace panel Orchestrator lifecycle.
|
||||
|
||||
Changes:
|
||||
- `yoi panel` now ensures a workspace Orchestrator only in Ticket-enabled workspaces.
|
||||
- If `.yoi/ticket.config.toml` is absent, the panel skips Orchestrator lifecycle and remains Pod-centric.
|
||||
- Existing malformed/unusable Ticket config paths surface diagnostics instead of silently falling back to no-Ticket mode.
|
||||
- Orchestrator Pod name is derived from the workspace directory using ASCII-safe normalization and the `-orchestrator` suffix, capped at 80 chars.
|
||||
- Already-live Orchestrator is reported as live.
|
||||
- Restorable Orchestrator is restored through existing Pod restore semantics.
|
||||
- Missing Orchestrator is spawned through the existing Ticket role launcher as `TicketRole::Orchestrator`.
|
||||
- Lifecycle decisions use an exact-name authority path and do not depend on the capped UI `PodList` rows.
|
||||
- Panel close does not stop the Orchestrator.
|
||||
- Orchestrator is not selected as the default foreground target when it is the only row or when another Pod can be selected.
|
||||
- Bounded lifecycle/config diagnostics are displayed in the panel.
|
||||
|
||||
Validation after merge:
|
||||
- `cargo test -p tui workspace_panel`
|
||||
- `cargo test -p tui multi`
|
||||
- `cargo test -p client ticket_role`
|
||||
- `cargo test -p yoi panel`
|
||||
- `cargo check --workspace --all-targets`
|
||||
- `cargo fmt --check`
|
||||
- `git diff --check HEAD~1..HEAD`
|
||||
- `cargo build -p yoi`
|
||||
- `target/debug/yoi ticket doctor`
|
||||
- `nix build .#yoi --no-link --print-out-paths`
|
||||
|
||||
External review approved after one requested-changes cycle.
|
||||
|
||||
Known follow-up:
|
||||
- Layout/display tuning remains intentionally deferred until the first end-to-end panel flow exists.
|
||||
- Composer target switching and Intake handoff are covered by follow-up child tickets.
|
||||
@@ -0,0 +1,80 @@
|
||||
<!-- event: create author: yoi ticket at: 2026-06-05T21:07:04Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: hare at: 2026-06-05T23:32:34Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
Preflight result: `implementation-ready` after the first action-model slice.
|
||||
|
||||
This ticket should add the workspace Orchestrator lifecycle to `yoi panel` only for Ticket-enabled workspaces. If `.yoi/ticket.config.toml` is absent, the panel should skip Orchestrator lifecycle and remain Pod-centric, matching the old `--multi` behavior.
|
||||
|
||||
Implementation should use existing Pod restore/spawn semantics and the Ticket role launcher/profile configuration where practical, surface bounded diagnostics, and leave final layout tuning for later.
|
||||
|
||||
Detailed delegation intent is recorded in `artifacts/delegation-intent.md`.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: review author: hare at: 2026-06-06T04:23:48Z status: approve -->
|
||||
|
||||
## Review: approve
|
||||
|
||||
External reviewer approved current HEAD after requested changes were addressed.
|
||||
|
||||
Review summary:
|
||||
- Orchestrator lifecycle no longer depends on capped UI rows; exact Orchestrator pod presence is checked through an unbounded authority path before lifecycle decisions.
|
||||
- Existing non-file `.yoi/ticket.config.toml` paths are surfaced as unusable, not absent.
|
||||
- Tests cover both targeted regressions.
|
||||
- No `--multi` reintroduction.
|
||||
- Panel close does not stop the Orchestrator.
|
||||
- Spawning uses the Ticket role launcher/profile path.
|
||||
- Default selection avoids making the Orchestrator the foreground target in covered cases.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: close author: hare at: 2026-06-06T04:23:48Z status: closed -->
|
||||
|
||||
## Closed
|
||||
|
||||
Implemented workspace panel Orchestrator lifecycle.
|
||||
|
||||
Changes:
|
||||
- `yoi panel` now ensures a workspace Orchestrator only in Ticket-enabled workspaces.
|
||||
- If `.yoi/ticket.config.toml` is absent, the panel skips Orchestrator lifecycle and remains Pod-centric.
|
||||
- Existing malformed/unusable Ticket config paths surface diagnostics instead of silently falling back to no-Ticket mode.
|
||||
- Orchestrator Pod name is derived from the workspace directory using ASCII-safe normalization and the `-orchestrator` suffix, capped at 80 chars.
|
||||
- Already-live Orchestrator is reported as live.
|
||||
- Restorable Orchestrator is restored through existing Pod restore semantics.
|
||||
- Missing Orchestrator is spawned through the existing Ticket role launcher as `TicketRole::Orchestrator`.
|
||||
- Lifecycle decisions use an exact-name authority path and do not depend on the capped UI `PodList` rows.
|
||||
- Panel close does not stop the Orchestrator.
|
||||
- Orchestrator is not selected as the default foreground target when it is the only row or when another Pod can be selected.
|
||||
- Bounded lifecycle/config diagnostics are displayed in the panel.
|
||||
|
||||
Validation after merge:
|
||||
- `cargo test -p tui workspace_panel`
|
||||
- `cargo test -p tui multi`
|
||||
- `cargo test -p client ticket_role`
|
||||
- `cargo test -p yoi panel`
|
||||
- `cargo check --workspace --all-targets`
|
||||
- `cargo fmt --check`
|
||||
- `git diff --check HEAD~1..HEAD`
|
||||
- `cargo build -p yoi`
|
||||
- `target/debug/yoi ticket doctor`
|
||||
- `nix build .#yoi --no-link --print-out-paths`
|
||||
|
||||
External review approved after one requested-changes cycle.
|
||||
|
||||
Known follow-up:
|
||||
- Layout/display tuning remains intentionally deferred until the first end-to-end panel flow exists.
|
||||
- Composer target switching and Intake handoff are covered by follow-up child tickets.
|
||||
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user