ticket: use base32 project record ids
This commit is contained in:
@@ -0,0 +1,120 @@
|
||||
# Delegation intent: Ticket Intake -> Orchestrator handoff
|
||||
|
||||
## Classification
|
||||
|
||||
`implementation-ready` after Orchestrator lifecycle and composer target slices.
|
||||
|
||||
`yoi panel` now opens the workspace panel, ensures a workspace Orchestrator for Ticket-enabled workspaces, and can launch a Ticket Intake Pod from the composer. This ticket connects those pieces with an explicit handoff contract.
|
||||
|
||||
## Intent
|
||||
|
||||
When the panel launches a Ticket Intake Pod, provide the workspace Orchestrator as the Intake's notification/handoff target so the Intake can report clarified Ticket readiness to the Orchestrator. The handoff must be visible in the destination Pod's committed input/history or durable peer metadata, not hidden context.
|
||||
|
||||
The handoff should not authorize implementation automatically. It only tells Intake where to report readiness or follow-up state after Intake has clarified and materialized/agreed a Ticket.
|
||||
|
||||
## Worktree / branch
|
||||
|
||||
- worktree: `/home/hare/Projects/yoi/.worktree/ticket-intake-orchestrator-handoff`
|
||||
- branch: `work/ticket-intake-orchestrator-handoff`
|
||||
|
||||
This ticket may read tracked `.yoi/tickets` records/design artifacts. Do not read or edit `.yoi/memory/`.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Define a simple handoff contract from workspace panel to Intake.
|
||||
- Include Orchestrator Pod name.
|
||||
- Include that Intake should notify/report to the Orchestrator when it has enough information for routing/preflight.
|
||||
- State clearly that implementation must not start automatically; human Go / Orchestrator routing gates still apply.
|
||||
- Carry the handoff through the existing Ticket role launch path where practical.
|
||||
- Prefer adding explicit fields/options to `TicketRoleLaunchContext` or equivalent over ad hoc string assembly in TUI.
|
||||
- Do not duplicate role prompt/profile construction in TUI.
|
||||
- Register Intake and Orchestrator as peers when both are live/reachable if existing `RegisterPeer` semantics make this feasible.
|
||||
- Registration failure should be a bounded diagnostic/warning, not a reason to lose the Intake launch if the launch itself succeeded.
|
||||
- Do not rely only on an LLM-internal instruction if a durable peer metadata path is available.
|
||||
- Include the handoff instruction in the Intake launch input/history so the Intake can explain why it may notify the Orchestrator in later turns.
|
||||
- Do not inject hidden context only.
|
||||
- Do not append the Intake request to Companion/current Pod history.
|
||||
- Add panel success/failure diagnostics for handoff setup separately from Intake launch success.
|
||||
- No-Ticket workspace must not expose this path.
|
||||
- Keep Orchestrator as background coordinator; do not make it foreground composer target by default.
|
||||
- Keep the contract small and typed enough to test, but do not build a scheduler/queue.
|
||||
|
||||
## Suggested contract shape
|
||||
|
||||
A small data type is preferred over freeform string construction in the panel:
|
||||
|
||||
```rust
|
||||
TicketIntakeHandoff {
|
||||
orchestrator_pod: String,
|
||||
workspace_label: String,
|
||||
}
|
||||
```
|
||||
|
||||
The role launcher can render this into the Intake `user_instruction` as an explicit section, for example:
|
||||
|
||||
```text
|
||||
Panel handoff:
|
||||
- Workspace Orchestrator Pod: <name>
|
||||
- When Intake has clarified the request and created/updated the Ticket, notify/report readiness to this Orchestrator.
|
||||
- Do not start implementation automatically; wait for Orchestrator routing/preflight and human Go gates.
|
||||
```
|
||||
|
||||
If peer registration is implemented, Intake should also receive durable peer metadata for the Orchestrator using the existing Pod peer registration path.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Automatic implementation scheduling.
|
||||
- Queue/lease system.
|
||||
- Full Ticket action model refinement.
|
||||
- Final layout/display tuning.
|
||||
- Generic arbitrary handoff routing.
|
||||
- Reintroducing `--multi`.
|
||||
|
||||
## Current code map
|
||||
|
||||
- `crates/tui/src/multi_pod.rs`
|
||||
- Panel composer target handling and Intake launch path.
|
||||
- `crates/tui/src/workspace_panel.rs`
|
||||
- Orchestrator state/name and composer target view state.
|
||||
- `crates/client/src/ticket_role.rs`
|
||||
- Role launch context and prompt/input assembly; preferred place for typed handoff fields.
|
||||
- `crates/protocol/src/lib.rs`
|
||||
- `Method::RegisterPeer` / `Event::PeerRegistered` semantics.
|
||||
- `crates/pod/src/controller.rs`
|
||||
- Peer registration handling for reference.
|
||||
- `crates/tui/src/socket.rs` / existing client helpers
|
||||
- Reuse existing socket/method helpers where practical; do not hand-roll protocol loops unnecessarily.
|
||||
|
||||
## Validation
|
||||
|
||||
Run at least:
|
||||
|
||||
- targeted tests for role launch input rendering with handoff;
|
||||
- targeted tests for panel Intake launch including handoff data;
|
||||
- targeted tests for peer registration success/failure behavior if implemented;
|
||||
- `cargo test -p client ticket_role`;
|
||||
- `cargo test -p tui workspace_panel`;
|
||||
- `cargo test -p tui multi_pod` or updated panel test names;
|
||||
- `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 handoff contract/data type;
|
||||
- how Orchestrator target is included in Intake input/history;
|
||||
- whether/how peer registration is performed;
|
||||
- launch vs handoff diagnostic behavior;
|
||||
- proof no Companion/current Pod history mutation is used for Intake body;
|
||||
- tests updated/added;
|
||||
- validation results;
|
||||
- known follow-up layout/display tuning items.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Ticket intake to orchestrator handoff"
|
||||
state: "closed"
|
||||
created_at: "2026-06-05T21:07:04Z"
|
||||
updated_at: "2026-06-06T05:27:40Z"
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
Intake can create or refine Tickets, but the next Orchestrator routing step is currently manual. The workspace panel needs a safe handoff from Intake to the workspace Orchestrator.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Define a machine-readable handoff contract from Intake to Orchestrator.
|
||||
- Handoff should include:
|
||||
- created/updated Ticket id or slug;
|
||||
- readiness;
|
||||
- needs_preflight;
|
||||
- risk flags when available;
|
||||
- whether user Go/approval is required;
|
||||
- summary of the Intake result.
|
||||
- Intake launch should receive the Orchestrator notification target in its initial input or durable metadata, not hidden context.
|
||||
- Orchestrator should be notified through an existing durable/observable channel where possible.
|
||||
- Handoff should not automatically start implementation.
|
||||
- The panel should be able to show a Ticket-ready-for-Go or routing-needed state after Intake.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Full scheduler/queue/lease.
|
||||
- Automatic coder/reviewer spawn.
|
||||
- Generic notification bus redesign.
|
||||
- External tracker integration.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Intake can hand off a newly created/refined Ticket to the workspace Orchestrator without the user manually retyping the Ticket id.
|
||||
- Handoff is visible/auditable in history or Ticket records.
|
||||
- Orchestrator routing is triggered or queued only within the agreed Go/authorization boundary.
|
||||
- Tests or fixtures cover handoff payload parsing/formatting where practical.
|
||||
@@ -0,0 +1,37 @@
|
||||
Implemented Ticket Intake -> Orchestrator handoff for the workspace panel.
|
||||
|
||||
Changes:
|
||||
- Added typed handoff contract `TicketIntakeHandoff { orchestrator_pod, workspace_label }`.
|
||||
- Extended `TicketRoleLaunchContext` with optional Intake handoff data.
|
||||
- Rendered a `Panel handoff:` section into Intake launch input/history through the existing Ticket role launcher.
|
||||
- The handoff section includes:
|
||||
- workspace label;
|
||||
- workspace Orchestrator Pod name;
|
||||
- expected readiness/report fields;
|
||||
- an explicit no-auto-implementation gate requiring Orchestrator routing/preflight and human Go before implementation.
|
||||
- Added `TicketRoleLaunchOptions` / `launch_ticket_role_pod_with_options(...)` for bounded pre-run peer registration.
|
||||
- Preserved `launch_ticket_role_pod(...)` as the default no-options wrapper.
|
||||
- Panel Intake launch now passes Orchestrator handoff data and, when applicable, a pre-run peer registration request.
|
||||
- `RegisterPeer` is sent before the first `Method::Run`, avoiding the controller's running-state rejection path.
|
||||
- Peer registration warnings are non-fatal when Intake launch/run succeeds.
|
||||
- No-Ticket workspaces remain Companion-only and expose no handoff path.
|
||||
- Intake requests do not route through Companion/current Pod history or selected-Pod direct send.
|
||||
- No automatic implementation scheduling/coder/reviewer spawning was added.
|
||||
- `--multi` was not reintroduced.
|
||||
|
||||
Validation after merge:
|
||||
- `cargo test -p client ticket_role`
|
||||
- `cargo test -p tui workspace_panel`
|
||||
- `cargo test -p tui multi_pod`
|
||||
- `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:
|
||||
- Final layout/display wording for handoff notices is deferred to panel tuning.
|
||||
@@ -0,0 +1,83 @@
|
||||
<!-- event: create author: yoi ticket at: 2026-06-05T21:07:04Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: hare at: 2026-06-06T04:49:16Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
Preflight result: `implementation-ready` after Orchestrator lifecycle and composer target slices.
|
||||
|
||||
This ticket should connect panel-launched Intake Pods to the workspace Orchestrator with an explicit, auditable handoff target. The handoff should be carried through the existing Ticket role launch path, preferably as a typed launch-context field rendered into the Intake first-run input/history, and peer metadata should be registered when feasible. It must not authorize automatic implementation.
|
||||
|
||||
Detailed delegation intent is recorded in `artifacts/delegation-intent.md`.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: review author: hare at: 2026-06-06T05:27:40Z status: approve -->
|
||||
|
||||
## Review: approve
|
||||
|
||||
External reviewer approved current HEAD after requested changes were addressed.
|
||||
|
||||
Review summary:
|
||||
- The previous blocking issue was fixed: `RegisterPeer` is now sent through the Ticket role launcher before the first `Method::Run`.
|
||||
- Handoff uses a small typed `TicketIntakeHandoff` contract and `TicketRoleLaunchOptions`, not scheduler state.
|
||||
- Intake launch input includes Orchestrator target and the no-auto-implementation gate.
|
||||
- No-Ticket workspaces remain Companion-only/no handoff.
|
||||
- Peer registration failures/skips are bounded warnings, not launch failures.
|
||||
- Intake request does not route through Companion/current Pod history or selected-Pod direct send.
|
||||
- No automatic implementation scheduling or `--multi` reintroduction.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: close author: hare at: 2026-06-06T05:27:40Z status: closed -->
|
||||
|
||||
## Closed
|
||||
|
||||
Implemented Ticket Intake -> Orchestrator handoff for the workspace panel.
|
||||
|
||||
Changes:
|
||||
- Added typed handoff contract `TicketIntakeHandoff { orchestrator_pod, workspace_label }`.
|
||||
- Extended `TicketRoleLaunchContext` with optional Intake handoff data.
|
||||
- Rendered a `Panel handoff:` section into Intake launch input/history through the existing Ticket role launcher.
|
||||
- The handoff section includes:
|
||||
- workspace label;
|
||||
- workspace Orchestrator Pod name;
|
||||
- expected readiness/report fields;
|
||||
- an explicit no-auto-implementation gate requiring Orchestrator routing/preflight and human Go before implementation.
|
||||
- Added `TicketRoleLaunchOptions` / `launch_ticket_role_pod_with_options(...)` for bounded pre-run peer registration.
|
||||
- Preserved `launch_ticket_role_pod(...)` as the default no-options wrapper.
|
||||
- Panel Intake launch now passes Orchestrator handoff data and, when applicable, a pre-run peer registration request.
|
||||
- `RegisterPeer` is sent before the first `Method::Run`, avoiding the controller's running-state rejection path.
|
||||
- Peer registration warnings are non-fatal when Intake launch/run succeeds.
|
||||
- No-Ticket workspaces remain Companion-only and expose no handoff path.
|
||||
- Intake requests do not route through Companion/current Pod history or selected-Pod direct send.
|
||||
- No automatic implementation scheduling/coder/reviewer spawning was added.
|
||||
- `--multi` was not reintroduced.
|
||||
|
||||
Validation after merge:
|
||||
- `cargo test -p client ticket_role`
|
||||
- `cargo test -p tui workspace_panel`
|
||||
- `cargo test -p tui multi_pod`
|
||||
- `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:
|
||||
- Final layout/display wording for handoff notices is deferred to panel tuning.
|
||||
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user