@lvlup-sw/exarchos 2.5.0 → 2.6.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lvlup-sw/exarchos",
-  "version": "2.5.0",
+  "version": "2.6.1",
   "description": "Structure for agentic development — durable SDLC workflows, convergence gates, agent teams, and audit trails for Claude Code",
   "type": "module",
   "bin": {
@@ -25,8 +25,10 @@
     "!**/trigger-tests"
   ],
   "scripts": {
-    "build": "tsc && bun run build:bundle",
+    "build": "tsc && bun run build:bundle && npm run build:skills",
     "build:bundle": "bun run scripts/build-bundle.ts",
+    "build:skills": "node dist/build-skills.js",
+    "skills:guard": "node dist/skills-guard.js",
     "prepare": "tsc",
     "bench": "cd servers/exarchos-mcp && npx vitest bench",
     "test": "vitest",
@@ -55,6 +57,7 @@
   "author": "lvlup-sw",
   "license": "Apache-2.0",
   "devDependencies": {
+    "@types/js-yaml": "^4.0.9",
     "@types/node": "^22.0.0",
     "tsx": "^4.21.0",
     "typescript": "^5.0.0",
@@ -65,7 +68,8 @@
     "node": ">=20.0.0"
   },
   "dependencies": {
-    "@inquirer/prompts": "^8.2.1"
+    "@inquirer/prompts": "^8.2.1",
+    "js-yaml": "^4.1.1"
   },
   "workspaces": [
     "packages/*"

package/skills/{cleanup → claude/cleanup}/SKILL.md

@@ -15,6 +15,12 @@ metadata:
 
 Resolve merged workflows to `completed` state in a single operation. Replaces the manual multi-step process of navigating HSM guards after PR stacks merge.
 
+## Batch Pruning for Stale Workflows
+
+For bulk cleanup of accumulated stale or abandoned workflows (as opposed to resolving a single merged workflow), use `@skills/prune-workflows/SKILL.md`. That skill invokes `exarchos_orchestrate prune_stale_workflows` in dry-run mode, displays candidates, and applies after user confirmation. Safeguards automatically skip workflows with open PRs or recent commits.
+
+**Rule of thumb:** cleanup is per-workflow (one merged feature → `completed`); prune is bulk (N inactive workflows → `cancelled`). They are complementary, not alternatives.
+
 ## Triggers
 
 Activate this skill when:

package/skills/{delegation → claude/delegation}/SKILL.md

@@ -20,6 +20,8 @@ Activate this skill when:
 - Implementation plan is ready with extractable tasks
 - User wants to parallelize work across subagents
 
+**Exception — oneshot workflows skip delegation entirely.** The oneshot playbook runs an in-session TDD loop in the main agent's context, with no subagent dispatch or review phase. If `workflowType === "oneshot"`, do not call this skill — see `@skills/oneshot-workflow/SKILL.md` for the lightweight path.
+
 ## Core Principles
 
 ### Fresh Context Per Task (MANDATORY)
@@ -121,33 +123,20 @@ This runbook provides structured criteria for parallel vs sequential dispatch, t
 
 ### Parallel Dispatch
 
-Dispatch all independent tasks in a **single message** with multiple `Task` calls.
-
-**Claude Code Dispatch (native agents):**
+Dispatch all independent tasks using the runtime's native spawn primitive. On runtimes with subagent support, fan out in a **single message** so the dispatches run in parallel. On runtimes without a subagent primitive, execute each task sequentially against its prepared worktree and emit one operator-visible warning per batch so users know they are not getting parallelism.
 
 ```typescript
 Task({
   subagent_type: "exarchos-implementer",
   run_in_background: true,
   description: "Implement task-001: [title]",
-  prompt: `Task-specific context only: requirements, file paths, acceptance criteria`
+  prompt: "Task-specific context: requirements, file paths, acceptance criteria"
 })
-```
-
-> **Note:** The agent's system prompt, model, isolation, skills, hooks, and memory are defined by the agent specification in `servers/exarchos-mcp/src/agents/definitions.ts`. The dispatch prompt provides ONLY task-specific context.
 
-**Cross-platform Dispatch (non-Claude-Code clients):**
-
-```typescript
-Task({
-  subagent_type: "general-purpose",
-  model: "opus",
-  run_in_background: true,
-  description: "Implement task-001: [title]",
-  prompt: `[Full implementer prompt — self-contained]`
-})
 ```
 
+> **Note:** On Claude Code, the `exarchos-implementer` agent definition already contains the system prompt, model, isolation, skills, hooks, and memory — the dispatch prompt should carry ONLY task-specific context. On runtimes without native agent definitions, include the full implementer prompt template from `references/implementer-prompt.md` in the `prompt` field so the spawned agent has a self-contained context.
+
 For parallel grouping strategy and model selection, see `references/parallel-strategy.md`.
 
 ### Agent Teams Dispatch
@@ -156,6 +145,22 @@ When using `--mode agent-team`, follow the 6-step saga in `references/agent-team
 
 Event emission contract for agent teams: see `references/agent-teams-saga.md` for full payload shapes and compensation protocol.
 
+### Event Emission Contract (REQUIRED)
+
+The delegate phase requires these events (checked by `check-event-emissions`):
+
+| Event | When | Emitted By |
+|-------|------|------------|
+| `team.spawned` | After team creation, before dispatch | Orchestrator |
+| `team.task.planned` | For each task in the plan (use `batch_append`) | Orchestrator |
+| `team.teammate.dispatched` | After each subagent is spawned | Orchestrator |
+| `task.progressed` | After each TDD phase (red/green/refactor) | Subagent |
+| `team.disbanded` | After all subagents complete | Orchestrator |
+
+See `references/agent-teams-saga.md` for full event schemas and emission order.
+
+> **Note:** `task.progressed` events are emitted by subagents during TDD execution, not by the orchestrator. The orchestrator only emits team lifecycle events.
+
 ---
 
 ## Step 3: Monitor and Collect
@@ -233,23 +238,16 @@ For the full recovery flow with a concrete example, see `references/worked-examp
 
 ### Fix Failed Tasks
 
-If a task fails and `agentId` is available in workflow state:
+Dispatch a fix agent with the full failure context and the original task description. On runtimes that support session resume (e.g. Claude Code with an `agentId` in workflow state), prefer resuming the original agent so it retains its implementer context; otherwise dispatch a fresh fixer agent using the runtime's native spawn primitive.
 
-**Resume (Claude Code — preserves full implementer context):**
 ```typescript
 Task({
-  resume: "[agentId from workflow state]",
-  prompt: "Your implementation failed. [failure context from test output]. Apply adversarial verification: do NOT trust your previous self-assessment, re-read actual test output, identify root cause not symptoms."
-})
-```
-
-**Fresh dispatch (cross-platform — when agentId unavailable or platform doesn't support resume):**
-```typescript
-Task({
-  subagent_type: "exarchos-fixer",
+  subagent_type: "exarchos-implementer",
   run_in_background: true,
-  prompt: "[Full failure context + original task context]"
+  description: "Fix failed task-001",
+  prompt: "Your implementation failed. [failure context from test output]. Apply adversarial verification: do NOT trust your previous self-assessment, re-read actual test output, identify root cause not symptoms. [Original task context]."
 })
+
 ```
 
 After fix completes, run the `task-fix` runbook gate chain:
@@ -276,6 +274,29 @@ If context compaction occurs during delegation:
 3. Reconcile: `exarchos_workflow reconcile` replays the event stream and patches stale task state (CAS-protected)
 4. Do NOT re-create branches or re-dispatch agents until confirmed lost
 
+### Worktree State Schema
+
+Worktree entries are stored as `worktrees["<wt-id>"]` in workflow state. Each entry requires:
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `branch` | string | Yes | Git branch name |
+| `taskId` | string | Conditional | Single task ID (use for 1-task worktrees) |
+| `tasks` | string[] | Conditional | Multiple task IDs (use for multi-task worktrees) |
+| `status` | `"active"` \| `"merged"` \| `"removed"` | Yes | Worktree lifecycle status |
+
+Either `taskId` or `tasks` (non-empty array) is required — at least one must be present.
+
+**Single-task example:**
+```json
+{ "branch": "feat/task-001", "taskId": "task-001", "status": "active" }
+```
+
+**Multi-task example:**
+```json
+{ "branch": "feat/integration", "tasks": ["task-001", "task-002"], "status": "active" }
+```
+
 ---
 
 ## Phase Transitions and Guards

package/skills/{delegation → claude/delegation}/references/troubleshooting.md

@@ -60,8 +60,8 @@ If `exarchos_orchestrate` with `action: "task_claim"` returns ALREADY_CLAIMED:
 ```json
 {
   "reviews": {
-    "spec-compliance": { "status": "pass", "issues": [] },
-    "code-quality": { "status": "pass", "issues": [] }
+    "spec-review": { "status": "pass", "issues": [] },
+    "quality-review": { "status": "pass", "issues": [] }
   }
 }
 ```

package/skills/claude/dogfood/SKILL.md

@@ -0,0 +1,235 @@
+---
+name: dogfood
+description: "Review failed Exarchos MCP tool calls from the current session, diagnose root causes, and categorize into code bug, documentation issue, or user error. Use when the user says 'dogfood', 'review failures', 'what went wrong', 'triage errors', or runs /dogfood. Scopes exclusively to Exarchos tools (exarchos_workflow, exarchos_event, exarchos_orchestrate, exarchos_view, exarchos_sync). Do NOT use for debugging application code or non-Exarchos tool failures."
+metadata:
+  author: exarchos
+  version: 2.0.0
+  mcp-server: exarchos
+  category: utility
+---
+
+# Dogfood Skill
+
+## Overview
+
+Retrospective analysis of Exarchos MCP tool usage. Uses the MCP server's own self-service capabilities as the primary diagnostic instrument — describe APIs, views, playbooks, and runbooks turned inward to diagnose failures.
+
+Three distinct failure modes require different fixes — code changes, documentation updates, or skill instruction improvements. Mixing them wastes effort.
+
+### Platform-Agnosticity
+
+Per `docs/designs/2026-03-09-platform-agnosticity.md`: the MCP server is the self-sufficient, platform-agnostic core. The debug trace relies entirely on MCP tools — not conversation introspection — so it works for any MCP client. Conversation scanning is supplementary.
+
+**Diagnostic self-service tools:** `describe(topology)` for HSM verification, `describe(playbook)` for adherence checks, `describe(eventTypes, emissionGuide)` for event schema/catalog comparison, `describe(actions)` for schema/gate metadata, `runbook(phase)` for step conformance, `pipeline`/`convergence`/`telemetry` views for health metrics.
+
+## Triggers
+
+Activate this skill when:
+- User runs `/dogfood` or `/exarchos:dogfood`
+- User asks "what went wrong this session" or "review the failures"
+- User wants to triage errors from a workflow run
+- End of a workflow session to capture learnings
+
+## Process
+
+### Step 1: Debug Trace via MCP Self-Service
+
+Query the MCP server's own self-service capabilities to build a ground-truth diagnostic picture. This is the primary investigation method — it uses the same tools any MCP client has access to.
+
+#### 1a. Identify Active Workflows
+
+Use `exarchos_view` with `action: "pipeline"` to get an aggregated view of active workflows with their phases and task counts.
+
+If `$ARGUMENTS` specifies a workflow or feature ID, scope to that workflow. Otherwise, inspect all non-terminal workflows.
+
+#### 1b. Inspect Workflow State and Topology
+
+For each relevant workflow:
+
+1. **Read state** — `exarchos_workflow get` to retrieve current phase, tasks, reviews, gate results.
+2. **Read topology** — `exarchos_workflow describe(topology: "<workflowType>")` to get the HSM definition. Compare the agent's phase transition attempts against valid transitions. Invalid transition attempts = documentation issue (skill prescribed wrong path) or user error.
+3. **Check guard prerequisites** — For `workflow.guard-failed` events, look up the guard in the topology to understand unmet preconditions.
+
+#### 1c. Playbook Adherence Check
+
+Use `exarchos_workflow describe(playbook: "<workflowType>")` to retrieve phase playbooks. For each phase executed, compare playbook's `tools`, `events`, `transitionCriteria`, `guardPrerequisites`, `humanCheckpoint`, and `compactGuidance` against what the agent actually did and what skill docs prescribe.
+
+**Playbook violations are diagnostic gold:**
+- Agent deviated and skill docs told it to → **documentation issue** (skill contradicts playbook)
+- Agent deviated and skill docs agree with playbook → **user error**
+- Playbook is wrong (prescribes invalid tools/events) → **code bug**
+
+#### 1d. Event Log Analysis
+
+Use `exarchos_event query(stream)` on the workflow's event stream. Look for:
+
+- **Rejected events** — absent from log despite agent attempts (corroborate with conversation errors)
+- **Missing events** — compare against playbook `events` field and `exarchos_event describe(emissionGuide: true)`. Missing model-emitted events = documentation gap or user error.
+- **Sequence anomalies** — wrong order, duplicates, or timeline gaps
+- **Schema mismatches** — use `describe(eventTypes: [...])` to get authoritative JSON Schema. Compare actual payloads against schema for semantically wrong fields.
+
+#### 1e. Orchestrate Action and Gate Analysis
+
+1. **Schema verification** — `exarchos_orchestrate describe(actions: [...])` for authoritative schemas. Compare agent's parameters against schema to detect stale skill docs or improvisation.
+2. **Gate metadata** — Describe output includes `{ blocking, dimension, autoEmits }`. Check: did the agent treat blocking/non-blocking correctly? Did expected auto-emissions fire?
+3. **Gate convergence** — `exarchos_view convergence` for per-dimension (D1-D5) pass rates. Low convergence suggests systemic gate issues.
+
+#### 1f. Runbook Conformance Check
+
+Use `exarchos_orchestrate runbook(phase)` to retrieve relevant runbooks. Check: step ordering, decision branch correctness (steps with `decide` fields), `onFail` directive adherence (`stop`/`continue`/`retry`), and `templateVars` completeness.
+
+#### 1g. Telemetry Review
+
+Use `exarchos_view telemetry` for per-tool performance. Flag: high error rates (systemic issues), high invocation counts (retry loops), and tools never invoked that the playbook prescribes.
+
+### Step 2: Scan Session for Failed Tool Calls
+
+Supplement the debug trace with client-side context — review conversation for failed Exarchos tool calls.
+
+**Note:** Platform-dependent step (requires conversation history). Skip on platforms without introspection; the debug trace is self-sufficient.
+
+**Target tools:** `exarchos_workflow`, `exarchos_event`, `exarchos_orchestrate`, `exarchos_view`, `exarchos_sync`
+
+**Error signals:** `INVALID_INPUT`, `VALIDATION_ERROR`, `BATCH_APPEND_FAILED`, Zod failures (`invalid_type`, `invalid_enum_value`, `unrecognized_keys`), `ENOENT`, `CLAIM_FAILED`, `SEQUENCE_CONFLICT`, CAS exhaustion, retry sequences, successful-after-retry calls.
+
+### Step 3: Diagnose Each Failure
+
+Merge debug trace and conversation scan findings. For each failure document:
+
+1. **What was attempted** — action, parameters, intent
+2. **What went wrong** — error message and validation path
+3. **Server-side evidence** — event log, state, describe output, views
+4. **Authoritative reference** — the self-service query providing ground truth (playbook, topology, schema, runbook)
+5. **Root cause** — per `references/root-cause-patterns.md`
+6. **Fix category** — code, docs, or user behavior
+
+Flag discrepancies only visible via server-side inspection as **trace-only findings**.
+
+### Step 4: Categorize into Buckets
+
+Assign each failure to exactly one root cause bucket:
+
+#### Bucket 1: Code Bug
+The MCP server, event store, or workflow engine has a defect.
+
+**Signals:** Schema rejects valid input (confirmed via `describe`), CAS failures with no concurrent writers, gate over-enforcement, identical-parameter retry succeeds (race condition), state corruption, topology/engine mismatch, auto-emission failure.
+
+**Action:** File bug issue with reproduction steps, expected vs actual, and suggested fix.
+
+#### Bucket 2: Documentation Issue
+Skill docs are wrong, incomplete, or out of sync with the MCP server's self-service output.
+
+**Signals:** Skill payload doesn't match `describe` schema, skill/playbook divergence, skill documents nonexistent topology paths, missing event types (compare emission guide), retry-based field discovery, runbook/skill contradictions, compactGuidance drift.
+
+**Action:** File docs issue with file:line, the discrepancy, and correct information from `describe` output.
+
+#### Bucket 3: User Error
+The agent misused a tool in a way both docs and `describe` output correctly describe.
+
+**Signals:** Format mismatch (confirmed by `describe` + docs agreement), invalid sequence (topology confirms), missing context both skill and playbook prescribe, runbook deviation without justification.
+
+**Action:** Note for skill improvement if errors are frequent.
+
+### Step 5: Generate Report
+
+Produce the report using the template from `references/report-template.md`. Include:
+- Summary counts per bucket
+- Debug trace summary (workflows inspected, events reviewed, describe queries issued, views consulted)
+- Each failure with full diagnosis (including authoritative self-service references)
+- Trace-only findings section (issues only visible via server-side inspection)
+- Playbook/runbook adherence summary
+- Actionable next steps (draft issue bodies for bugs/docs issues)
+
+### Step 6: Offer to File Issues
+
+For findings in the **Code Bug** and **Documentation Issue** buckets, offer to create GitHub issues:
+
+```bash
+gh issue create --title "<type>: <summary>" --body "<issue body>" --label "bug"
+```
+
+Only file issues with user confirmation — present the draft first.
+
+## Required Output Format
+
+```json
+{
+  "session_summary": {
+    "total_tool_calls": 0,
+    "failed_tool_calls": 0,
+    "failure_rate": "0%",
+    "debug_trace": {
+      "workflows_inspected": 0,
+      "events_reviewed": 0,
+      "describe_queries": 0,
+      "views_consulted": [],
+      "trace_only_findings": 0
+    }
+  },
+  "playbook_adherence": {
+    "phases_checked": 0,
+    "violations": [
+      {
+        "phase": "delegate",
+        "field": "events",
+        "expected": "team.spawned, team.task.assigned",
+        "actual": "none emitted",
+        "bucket": "documentation_issue"
+      }
+    ]
+  },
+  "runbook_conformance": {
+    "runbooks_checked": 0,
+    "deviations": []
+  },
+  "buckets": {
+    "code_bug": [],
+    "documentation_issue": [],
+    "user_error": []
+  },
+  "findings": [
+    {
+      "id": 1,
+      "bucket": "code_bug | documentation_issue | user_error",
+      "tool": "exarchos_workflow",
+      "action": "set",
+      "error": "INVALID_INPUT: ...",
+      "root_cause": "Schema rejects null branch on pending tasks",
+      "trace_evidence": "describe(actions: ['set']) shows branch as required string; event log confirms no task.updated event",
+      "authoritative_ref": "exarchos_workflow describe(actions: ['set']) → TaskSchema",
+      "severity": "HIGH | MEDIUM | LOW",
+      "suggested_fix": "Accept nullable branch in TaskSchema",
+      "issue_draft": {
+        "title": "bug: workflow task schema rejects null branch",
+        "labels": ["bug"],
+        "body": "..."
+      }
+    }
+  ],
+  "trace_only_findings": [
+    {
+      "id": "T1",
+      "description": "State drift: agent assumed phase was 'delegate' but server shows 'plan'",
+      "evidence": "exarchos_workflow get shows phase=plan; topology confirms plan→delegate requires planReviewComplete guard",
+      "authoritative_ref": "exarchos_workflow describe(topology: 'feature') → guards",
+      "bucket": "documentation_issue",
+      "suggested_fix": "Skill should instruct agent to verify phase via get before proceeding"
+    }
+  ]
+}
+```
+
+## Anti-Patterns
+
+| Don't | Do Instead |
+|-------|------------|
+| Skip the debug trace and only scan conversation | Always query MCP self-service tools first — conversation scan is supplementary |
+| Guess what the schema expects | Use `describe` to get authoritative schemas — they are the source of truth |
+| Assess playbook adherence from memory | Query `describe(playbook)` to get the actual prescribed tools, events, and criteria |
+| Assume the topology without checking | Query `describe(topology)` to get valid transitions, guards, and effects |
+| Blame the user when skill docs contradict the playbook | If skill docs diverge from playbook/describe output, it's a documentation issue |
+| File duplicate issues | Check existing open/closed issues before drafting |
+| Categorize retries as separate failures | Group retry sequences as a single finding |
+| Ignore successful-after-retry calls | These reveal friction even though they eventually worked |
+| Include non-Exarchos failures | Scope strictly to the 5 Exarchos tools — other MCP failures are out of scope |
+| Report conversation-only findings without trace corroboration | Cross-reference every finding with server-side state when possible |

package/skills/claude/dogfood/references/report-template.md

@@ -0,0 +1,109 @@
+# Dogfood Report Template
+
+```markdown
+## Dogfood Report
+
+**Session:** [workflow name or description]
+**Date:** [ISO 8601]
+**Workflow type:** [feature | debug | refactor | ad-hoc]
+
+### Summary
+
+| Metric | Value |
+|--------|-------|
+| Total Exarchos tool calls | X |
+| Failed tool calls | Y |
+| Failure rate | Z% |
+| Code bugs found | A |
+| Documentation issues found | B |
+| User errors found | C |
+
+### Debug Trace Summary
+
+| Metric | Value |
+|--------|-------|
+| Workflows inspected | X |
+| Events reviewed | Y |
+| Describe queries issued | Z |
+| Views consulted | [pipeline, convergence, telemetry, ...] |
+| Trace-only findings | W |
+
+### Playbook Adherence
+
+| Phase | Tools | Events | Transition Criteria | Guards | Verdict |
+|-------|-------|--------|-------------------|--------|---------|
+| [phase] | [match/mismatch] | [match/mismatch] | [match/mismatch] | [match/mismatch] | [OK/VIOLATION] |
+
+**Violations:**
+- [phase]: [playbook says X, agent did Y — bucket: documentation_issue/user_error]
+
+### Runbook Conformance
+
+| Runbook | Steps Executed | Deviations | Verdict |
+|---------|---------------|------------|---------|
+| [id] | X/Y | [list] | [OK/DEVIATED] |
+
+### Code Bugs
+
+#### [CB-1] [Title]
+- **Tool:** `exarchos_workflow` action `set`
+- **Error:** `INVALID_INPUT: ...`
+- **Root cause:** [diagnosis]
+- **Trace evidence:** [what describe/view/event query revealed]
+- **Authoritative ref:** [e.g., `describe(actions: ['set']) → TaskSchema`]
+- **Impact:** [blocked workflow / degraded experience / minor friction]
+- **Suggested fix:** [specific code change]
+- **Files:** [file:line references]
+
+### Documentation Issues
+
+#### [DOC-1] [Title]
+- **Tool:** `exarchos_event` action `append`
+- **Error:** `VALIDATION_ERROR: invalid_enum_value`
+- **Root cause:** [diagnosis — what the docs say vs what describe output shows]
+- **Trace evidence:** [describe output vs skill doc content]
+- **Authoritative ref:** [e.g., `describe(eventTypes: ['team.spawned']) → JSON Schema`]
+- **Skill/Reference:** [skills/X/SKILL.md:line or references/Y.md:line]
+- **Source of truth:** [describe action + servers/exarchos-mcp/src/file.ts:line]
+- **Suggested fix:** [update docs to match describe output]
+
+### User Errors
+
+#### [UE-1] [Title]
+- **Tool:** `exarchos_orchestrate` action `check_tdd_compliance`
+- **Error:** [error message]
+- **What happened:** [agent did X]
+- **What should have happened:** [both docs and describe agree on Y]
+- **Authoritative ref:** [confirm docs match describe/topology/playbook]
+- **Skill improvement:** [if the error is common, suggest making the skill clearer]
+
+### Trace-Only Findings
+
+Issues discovered solely through debug trace (not visible in conversation errors):
+
+#### [T-1] [Title]
+- **Discovery method:** [describe comparison / event log analysis / view query / playbook check]
+- **Evidence:** [what the trace revealed]
+- **Authoritative ref:** [which self-service query provided the ground truth]
+- **Bucket:** [code_bug / documentation_issue]
+- **Impact:** [silent data loss / state drift / stale guidance / playbook-skill divergence]
+- **Suggested fix:** [specific change]
+
+### Issue Drafts
+
+Ready-to-file issue bodies for Code Bugs and Documentation Issues:
+
+#### Issue: [CB-1 title]
+```
+gh issue create --title "bug: [summary]" --label "bug" --body "..."
+```
+
+#### Issue: [DOC-1 title]
+```
+gh issue create --title "docs: [summary]" --label "bug" --body "..."
+```
+
+### Patterns & Trends
+
+[Observations about recurring failure modes, systemic issues, or improvements to the dogfood process itself]
+```