ticket: use base32 project record ids

2026-06-09 22:10:47 +09:00
parent 0803bc3725
commit 4203988d74
798 changed files with 477 additions and 105 deletions
@@ -0,0 +1,49 @@
+---
+title: "Companion status context and tool policy"
+state: "planning"
+created_at: "2026-06-07T00:16:51Z"
+updated_at: "2026-06-07T02:45:32Z"
+---
+
+## Background
+
+The workspace Companion should help the human understand and steer the workspace, not act as a direct implementation worker. It should know what is complete, what remains, what is queued/in progress, which Pods exist, and where attention may be useful. It should not directly edit files, mutate Tickets, spawn implementation Pods, or perform destructive actions.
+
+This requires a distinct prompt/profile/tool policy from ordinary coder/reviewer/orchestrator Pods.
+
+## Goal
+
+Define and implement the Companion's prompt/profile/tool policy so it can provide real-time situational assistance while being prevented from direct write/mutation authority.
+
+## Requirements
+
+- Add or define a Companion role/profile/prompt for workspace panel usage.
+- System prompt should instruct the Companion to:
+  - summarize current workspace status;
+  - explain completed/remaining work;
+  - help the human understand Ticket/Pod/Orchestrator state;
+  - suggest next safe high-level actions;
+  - avoid directly implementing, editing, or mutating project state.
+- Tool policy should prohibit direct file writes and direct Ticket mutation by default.
+- Tool policy should prohibit spawning implementation/review Pods directly unless a later explicit design grants that authority.
+- Companion may have read/status capabilities needed for situational awareness, such as bounded Ticket list/show, Pod list/state, and possibly read-only docs/context access.
+- If read-only status is provided through a specialized summary/context mechanism rather than raw tools, keep it auditable and derived from authoritative Ticket/Pod state.
+- Companion should not receive hidden, non-history context that affects behavior without being committed to an appropriate history/event path.
+- Keep secrets/private input out of diagnostics, status summaries, and prompts.
+- Preserve Orchestrator as the actor responsible for scheduling/routing work; Companion is human-facing support, not scheduler authority.
+
+## Non-goals
+
+- Giving Companion write access.
+- Replacing Orchestrator.
+- Replacing Ticket tools/workflows.
+- Building a full scheduler.
+- Final UI layout tuning.
+
+## Acceptance criteria
+
+- A Companion prompt/profile/tool policy exists and is used by `yoi panel` Companion lifecycle.
+- Companion can answer status questions from read-only/derived authoritative sources.
+- Companion cannot directly mutate repository files or Ticket records under default policy.
+- Companion cannot directly launch implementation/review Pods under default policy.
+- Prompt/tool docs clearly distinguish Companion from Orchestrator, Intake, coder, and reviewer roles.
@@ -0,0 +1,44 @@
+<!-- event: create author: "yoi ticket" at: 2026-06-07T00:16:51Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---
+
+<!-- event: comment author: hare at: 2026-06-07T01:21:43Z -->
+
+## Comment
+
+## Status context boundary
+
+When local role session / Ticket claim overlay support is added, it can become one source of read-only Companion status context. The Companion should treat it as local runtime status, distinct from authoritative git-tracked Ticket project records.
+
+Default Companion policy should still prohibit direct mutation of Ticket records and direct role Pod spawning/claiming unless a later explicit design grants that authority.
+
+---
+
+<!-- event: decision author: hare at: 2026-06-07T02:45:32Z -->
+
+## Decision
+
+## Companion Bash policy decision
+
+Default Companion policy should not include Bash.
+
+Rationale:
+- Companion and Orchestrator both operate around the workspace root, but only Orchestrator should hold workspace operation authority.
+- Companion is a human-facing status/understanding assistant, not an actor that creates orchestration side effects.
+- Bash is too broad to treat as safely read-only by prompt alone. Even seemingly read-only commands can touch git locks/index state, build caches, `target/`, package caches, or long-running CPU/IO resources.
+- Adding reliable read-only constraints to Bash would become a sandbox/policy redesign, not a small Companion-policy detail.
+
+Policy:
+- Default Companion: no Bash, no direct file writes, no Ticket mutation, no SpawnPod/worktree/merge authority.
+- Prefer typed read/status tools and derived panel/registry/Ticket/Pod context for situational awareness.
+- If future dogfooding shows Companion needs shell diagnostics, create a separate explicit design/ticket for an opt-in diagnostic Bash/read-only shell capability rather than adding Bash to the default Companion profile.
+
+Operational trigger for revisiting:
+- Users repeatedly want Companion to perform clear shell-based diagnostics; or
+- Prompt-level "read-only" instructions prove insufficient and Companion attempts or performs unsafe Bash actions.
+
+---