ticket: use base32 project record ids
This commit is contained in:
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "Workspace panel Companion interface"
|
||||
state: "planning"
|
||||
created_at: "2026-06-07T00:16:51Z"
|
||||
updated_at: "2026-06-07T03:13:01Z"
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
The current `yoi panel` `Companion` composer target is a misleading name: it is effectively the selected-Pod direct-send path. The desired UX is different.
|
||||
|
||||
The workspace panel should have a real Companion: a workspace-scoped Pod used for the foreground management conversation. It should help the human understand what is done, what remains, what is blocked/queued/in progress, and where intervention is useful. It should not be a direct write-capable worker.
|
||||
|
||||
Direct message sending from the panel to arbitrary selected Pods should be removed. The panel composer should talk to the Companion by default, with Ticket Intake as the other explicit creation path in Ticket-enabled workspaces.
|
||||
|
||||
## Goal
|
||||
|
||||
Redesign the workspace panel composer around a real workspace Companion Pod and remove the selected-Pod direct-send UX.
|
||||
|
||||
## Target model
|
||||
|
||||
- `yoi panel` restores/spawns a workspace Companion Pod.
|
||||
- The Companion Pod name is based on the workspace name, matching the default workspace Pod naming direction where practical.
|
||||
- The panel composer default target is the Companion conversation.
|
||||
- Ticket Intake remains a separate target for creating/materializing new Ticket requests.
|
||||
- Selected Pod direct send is removed from the panel.
|
||||
- Opening/attaching to a Pod remains available for inspecting details.
|
||||
- The Companion is status-aware but not write-capable.
|
||||
|
||||
## Child tickets
|
||||
|
||||
1. `workspace-panel-remove-direct-pod-send`
|
||||
- Remove selected-Pod direct send from `yoi panel`; keep attach/open and Ticket Intake.
|
||||
|
||||
2. `workspace-panel-companion-pod-lifecycle`
|
||||
- Restore/spawn the workspace-named Companion Pod and route Companion composer input to it.
|
||||
|
||||
3. `companion-status-context-tool-policy`
|
||||
- Define Companion prompt/profile/tool policy: status-awareness and human assistance, no direct repository writes or Ticket mutations.
|
||||
|
||||
4. `workspace-panel-local-role-session-registry`
|
||||
- Define the local user-data overlay for role sessions and Ticket claims; keep local Pod assignment out of git-tracked Ticket metadata.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Removing Pod attach/open.
|
||||
- Removing Ticket Intake target.
|
||||
- Removing Orchestrator lifecycle.
|
||||
- Giving Companion direct write access or implementation authority.
|
||||
- Reintroducing `--multi` or `:ticket`.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- The workspace panel no longer treats `Companion` as selected-Pod direct send.
|
||||
- The panel has a real workspace Companion Pod/session as the foreground management chat.
|
||||
- Direct selected-Pod send is removed or disabled with clear UI behavior.
|
||||
- Companion tool policy prevents direct file/Ticket mutation while still allowing status awareness.
|
||||
- No-Ticket workspaces still get a useful Companion/Pod-inspection panel.
|
||||
@@ -0,0 +1,77 @@
|
||||
<!-- event: create author: "yoi ticket" at: 2026-06-07T00:16:51Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-07T00:18:58Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
Decision from user discussion:
|
||||
|
||||
The panel should not provide direct messaging to arbitrary selected Pods. The existing `Companion` composer target is currently a misleading label for selected-Pod direct send and should be replaced by a real workspace Companion Pod.
|
||||
|
||||
Target model:
|
||||
- default panel composer talks to a workspace-named Companion Pod;
|
||||
- Companion is a foreground management chat for the human;
|
||||
- Ticket Intake remains a separate target for new requests;
|
||||
- selected Pod direct send is removed;
|
||||
- Pod attach/open remains available for inspection;
|
||||
- Companion should be status-aware but not directly write/mutate project state;
|
||||
- Companion prompt/tool policy should focus on situational awareness and human support, with direct writes/Ticket mutations/implementation spawning prohibited by default.
|
||||
|
||||
Split child tickets were created for direct-send removal, Companion lifecycle, and Companion prompt/tool policy.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-07T01:21:43Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Local role/session overlay split
|
||||
|
||||
The Companion/panel redesign should not store Ticket↔local Pod assignment in git-tracked Ticket metadata. Local Pod names, runtime/session identity, socket/restorable state, and current claims are per-machine runtime concerns.
|
||||
|
||||
A new child ticket `workspace-panel-local-role-session-registry` covers the local overlay model:
|
||||
|
||||
- Ticket project records keep workflow state and auditable summaries only.
|
||||
- A Ticket may have at most one active local Pod claim at a time.
|
||||
- A Pod/session may relate to zero or more Tickets.
|
||||
- Intake is not 1:1 with Ticket: pre-Ticket Intake may have no Ticket yet, and one Intake session may materialize/split into multiple Tickets.
|
||||
- Existing `ticket-*` Pod visibility in the panel is acceptable as an interim access path until the registry UI/model exists.
|
||||
- The panel should not poll and automatically start Intake for newly-created `workflow_state = intake` Tickets; starting/claiming remains an explicit action.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-07T02:02:21Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Orchestrator automation follow-up
|
||||
|
||||
Created `workspace-panel-orchestrator-queue-automation` to cover the missing end-to-end route from Panel Intake/Queue into Orchestrator-managed work.
|
||||
|
||||
This follow-up fixes the intended `queued` semantics:
|
||||
- `queued` means the human authorized Orchestrator routing;
|
||||
- the Orchestrator should inspect Ticket/workspace state and start if unblocked;
|
||||
- conflicts, dependency blockers, preflight gaps, and capacity constraints are Orchestrator decisions, not reasons for the panel to stay passive forever.
|
||||
|
||||
This remains separate from Companion lifecycle and local role/session registry work, but may consume the registry once available to avoid duplicate ownership.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-07T03:13:01Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Priority adjustment
|
||||
|
||||
Companion work is useful but not required for near-term panel operation. The panel can still be used by manually attaching/opening Pods, and the direct selected-Pod send path has already been removed.
|
||||
|
||||
Decision: downgrade Companion-related follow-up priority to P2 so near-term focus can stay on Ticket role config strictness/init, Orchestrator queue automation, and workflow/compaction reliability.
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user