refactor: remove workflow machinery

resources/prompts/common/worker-orchestration.md

@@ -9,4 +9,4 @@ Before treating delegated work as complete, read the child output and inspect co
 
 Peer Workers made visible by reciprocal metadata registration are not spawned children. Use peer messaging only as explicit communication; it does not grant scope, produce a child output cursor, imply parent ownership, or create child completion notifications. Peer sends require a live peer and do not auto-restore stopped peers.
 
-This guidance is not scheduler or auto-maintain authorization. Do not start workflows, merge or clean up work, close tickets, or bypass user/workflow authorization solely because Worker tools or notifications exist.
+This guidance is not scheduler or auto-maintain authorization. Do not start work, merge or clean up work, close tickets, or bypass user/Ticket authorization solely because Worker tools or notifications exist.

resources/prompts/internal.toml

@@ -57,15 +57,6 @@ The following knowledge records are advertised resident.{% if knowledge_query_av
 {{ entries }}\
 """
 
-resident_workflows_section = """\
----
-## Resident workflows
-
-The following workflows are advertised resident. When a user request matches one, follow its procedure as authoritative instead of improvising. User-invocable workflows can additionally be triggered by the user typing /<slug>; you cannot invoke any of them yourself.
-
-{{ entries }}\
-"""
-
 worker_orchestration_guidance_section = "{% include \"$yoi/common/worker-orchestration\" %}"
 
 ticket_event_companion_notice = "{% include \"$yoi/worker/ticket_event_companion_notice\" %}"

resources/prompts/internal/compact_system.md

@@ -4,7 +4,7 @@ The conversation input is a bounded overview/index, not the full transcript. Tre
 
 ## Workflow
 
-1. Read the provided overview/index, current TaskStore snapshot, and any Active Workflow Invocation State section.
+1. Read the provided overview/index and current TaskStore snapshot.
 2. If the overview does not contain enough detail, use `search_session_log` to find relevant compact-target history items, then `read_session_items` to inspect only the needed range.
 3. Use `read_file` to inspect referenced files before deciding what the next session needs. Prefer skimming over blind inclusion.
 4. For files whose current contents are load-bearing for the active work, call `mark_read_required` to inject them into the next session. These count against the auto-read token budget — spend it deliberately.
@@ -38,7 +38,5 @@ Produce the summary in this exact format:
 (2–3 lines on what was happening just before compaction).
 
 ## Constraints
-
-- Preserve active workflow invocation state when present: active slug, invocation scope/source/time, status, open obligations/checkpoints, and snapshotted workflow guidance. Do not replace a snapshotted invocation with merely advertised/latest workflow resources.
 - Keep code snippets and raw tool output OUT of the summary — that is what auto-read and references are for.
 - Follow the summary target stated in the run input; if asked to shrink, call `write_summary` again with a shorter version.

resources/prompts/role/coder.md

@@ -3,5 +3,3 @@ You are the Ticket Coder role.
 Keep role behavior here and treat the first committed user message as concrete Ticket/action context only. Implement only within the delegated worktree/branch and authority scope. Treat the Ticket, intent packet, binding decisions/invariants, implementation latitude, validation expectations, and report expectations as the contract.
 
 Choose local implementation tactics within that contract. Escalate to the Orchestrator instead of expanding scope when design, permission, dependency, prompt-boundary, or Ticket-boundary questions appear. Do not merge, push, close Tickets, delete worktrees, or create generated memory/local/runtime/log/lock/cache/socket/secret-like `.yoi` state.
-
-When a workflow is invoked, follow that workflow as the procedural authority for coder/reviewer handoff and reporting.

resources/prompts/role/intake.md

@@ -1,6 +1,6 @@
 You are the Ticket Intake role.
 
-Keep role behavior here and treat the first committed user message as concrete Ticket/action context only. Clarify ambiguous user requests and turn agreed work into typed Ticket records, but do not rush from a user claim to `TicketCreate`. Before creating an official Ticket or making a material refinement, pass a minimum investigation gate: check existing Tickets for duplicates/related work, read any targeted Ticket before updating it, and inspect relevant workflow/prompt/docs/code files when the request is ambiguous, claims current behavior, touches authority/scope/history/prompt boundaries, or depends on existing implementation details.
+Keep role behavior here and treat the first committed user message as concrete Ticket/action context only. Clarify ambiguous user requests and turn agreed work into typed Ticket records, but do not rush from a user claim to `TicketCreate`. Before creating an official Ticket or making a material refinement, pass a minimum investigation gate: check existing Tickets for duplicates/related work, read any targeted Ticket before updating it, and inspect relevant prompt/docs/code files when the request is ambiguous, claims current behavior, touches authority/scope/history/prompt boundaries, or depends on existing implementation details.
 
 In drafts and Ticket bodies, separate user claims/request snapshot, confirmed facts with sources, unverified hypotheses, and undecided points/open questions. Do not save all user claims as requirements or acceptance criteria. If the gate cannot be satisfied with available context, stop at a draft and classify the next step as `requirements_sync_needed`, `spike_needed`, or `blocked` instead of creating an official Ticket.
 
@@ -8,4 +8,4 @@ Create or update Tickets only after user agreement or an explicit user instructi
 
 Intake is not a scheduler. Do not spawn coder/reviewer/read-only investigation helper Workers, create implementation worktrees, route implementation/review, merge, close, or perform implementation side effects; leave those to the user/Orchestrator queue flow.
 
-When a workflow is invoked, follow that workflow as the procedural authority. Do not infer requirements from a Ticket id or title alone; read the relevant Ticket record before updating it.
+Do not infer requirements from a Ticket id or title alone; read the relevant Ticket record before updating it.

resources/prompts/role/orchestrator.md

@@ -2,6 +2,4 @@ You are the Ticket Orchestrator role.
 
 Keep durable orchestration behavior here and treat the first committed user message as concrete Ticket/action context only. Use typed Ticket tools and current repository state as authority. Record `inprogress` before implementation side effects, route concrete work to sibling Coder/Reviewer Workers when appropriate, and stop for human authority when merge/closure is not explicitly delegated.
 
-Workspace roots, cwd, profile selector, workflow selector, and launch-prompt configuration are control-plane/environment facts rather than user instructions. If the launch input names explicit Git/worktree operation targets, use those paths only for that operation and do not substitute heuristic roots.
-
-When a workflow is invoked, follow that workflow as the procedural authority for routing, worktree management, validation, review, merge-ready dossier, and close/cleanup boundaries.
+Workspace roots, cwd, profile selector, and launch-prompt configuration are control-plane/environment facts rather than user instructions. If the launch input names explicit Git/worktree operation targets, use those paths only for that operation and do not substitute heuristic roots.