Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

fix: update remaining active worker wording

Browse Source
This commit is contained in:
Hare
2026-06-26 01:06:20 +09:00
parent da96d06f25
commit cb0c52e787
9 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/development/environment.md
+1 -1
View File
@@ -4,7 +4,7 @@ Environment variables are a minimized runtime boundary. Prefer explicit profile/
## Why minimize environment variables
Ambient environment is hard to audit: it can differ between shells, services, spawned Pods, tests, and restored processes. If important runtime behavior depends on it, reproducing a session becomes harder.
Ambient environment is hard to audit: it can differ between shells, services, spawned Workers, tests, and restored processes. If important runtime behavior depends on it, reproducing a session becomes harder.
Yoi keeps environment variables for narrow bootstrap and development cases, while normal provider credentials and runtime configuration should be explicit records.
docs/development/work-items.md
+5 -5
View File
@@ -24,14 +24,14 @@ Use the highest-level interface that matches the work:
- Use `yoi panel` for the Ticket/Intake/Orchestrator workspace Dashboard and role-launch actions.
- Use `yoi objective ...` for lightweight medium-term Objective records and their non-blocking canonical Ticket links.
- Inside Pods, use typed Ticket tools to create, inspect, comment, review, and close Tickets.
- Inside Workers, use typed Ticket tools to create, inspect, comment, review, and close Tickets.
- For multi-step work, follow the Ticket Intake, Orchestrator Routing, planning/requirements-sync, and Multi-agent workflows.
Maintainers can inspect the local `.yoi/tickets/` files directly when debugging storage, but normal user instructions should go through `yoi panel`, Ticket tools, or `yoi ticket ...`.
## Ticket tools inside Pods
## Ticket tools inside Workers
Pods with the Ticket built-in feature can use typed Ticket tools:
Workers with the Ticket built-in feature can use typed Ticket tools:
- `TicketCreate`
- `TicketList` — lightweight bounded overview for selecting ids; it returns short summaries only and must not be used as body/thread/artifact authority.
@@ -195,7 +195,7 @@ Intake should:
- draft background, requirements, acceptance criteria, binding decisions/invariants, implementation latitude, readiness, risk flags, and validation;
- create or update the Ticket only after user agreement.
Intake should not schedule implementation, spawn coder/reviewer Pods, create worktrees, merge, or close Tickets.
Intake should not schedule implementation, spawn coder/reviewer Workers, create worktrees, merge, or close Tickets.
### 2. Orchestrator routing
@@ -226,7 +226,7 @@ Planning sync should resolve or record:
- critical risks and failure modes;
- implementation-ready vs requirements-sync/spike/blocked classification.
Do not send Tickets with unresolved concrete missing decisions/information directly to coder Pods. If no concrete missing item remains after bounded checks, risky-but-specified Tickets should proceed with an IntentPacket plus escalation conditions and reviewer focus.
Do not send Tickets with unresolved concrete missing decisions/information directly to coder Workers. If no concrete missing item remains after bounded checks, risky-but-specified Tickets should proceed with an IntentPacket plus escalation conditions and reviewer focus.
### 4. Implementation assignment
docs/development/workflows.md
+2 -2
View File
@@ -17,7 +17,7 @@ Current workflow themes include:
- sibling coder/reviewer Worker orchestration
- human-gated maintenance and merge readiness
## Child Pods
## Child Workers
Spawned Workers are useful for scoped implementation, review, or exploration. They are not independent project authorities.
@@ -35,7 +35,7 @@ Notifications are hints to inspect state. They are not proof of completion.
Unless explicitly authorized otherwise, final merge, cleanup, design-boundary decisions, and ticket closure remain the orchestrator/human responsibility.
Child Pods may commit in delegated worktrees when the workflow allows it, but the merge-ready dossier should make the final decision auditable from repository records.
Child Workers may commit in delegated worktrees when the workflow allows it, but the merge-ready dossier should make the final decision auditable from repository records.
## Public and dogfood workflow split