agent-bober 0.1.0

package/skills/bober.sprint/SKILL.md

@@ -0,0 +1,280 @@
+---
+name: bober.sprint
+description: Execute the next pending sprint — negotiate contracts, run the Generator, evaluate output, and iterate until passing or exhausting retries.
+argument-hint: "[sprint-number]"
+---
+
+# bober.sprint — Sprint Execution Skill
+
+You are running the **bober.sprint** skill. Your job is to execute a single sprint from an existing plan through the full Generator-Evaluator loop: negotiate the contract, generate the implementation, evaluate the output, and iterate until the sprint passes or retries are exhausted.
+
+## Prerequisites
+
+Before starting, verify these exist:
+- `bober.config.json` in the project root
+- At least one PlanSpec in `.bober/specs/`
+- At least one SprintContract in `.bober/contracts/`
+
+If any are missing, tell the user to run `/bober:plan` first.
+
+## Step 1: Identify the Target Sprint
+
+**If a sprint number was provided as an argument:**
+- Load the most recent PlanSpec from `.bober/specs/` (sort by `createdAt` descending)
+- Find the contract for that sprint number: `.bober/contracts/sprint-<specId>-<N>.json`
+- Verify it exists and its status is `proposed`, `in-progress`, or `needs-rework`
+
+**If no sprint number was provided:**
+- Load the most recent PlanSpec
+- Find the first sprint contract with status `proposed` or `needs-rework`
+- If all sprints are `completed`, tell the user all sprints are done
+- If a sprint is `in-progress`, resume it
+
+**Validate dependencies:**
+- Check that all sprints listed in `dependsOn` have status `completed`
+- If any dependency is not complete, tell the user which sprints must be completed first
+
+Read the identified contract and the parent PlanSpec.
+
+## Step 2: Contract Negotiation (if status is "proposed")
+
+When a contract status is `proposed`, it has not yet been reviewed for executability. Run a brief negotiation phase:
+
+1. **Review the success criteria** in the contract. For each criterion, assess:
+   - Is the `verificationMethod` actually executable given the current project setup?
+   - Is the criterion specific enough that pass/fail is unambiguous?
+   - Can the Evaluator actually verify this criterion independently?
+
+2. **Review the evaluator strategies** in `bober.config.json`. For each strategy:
+   - Is the required tooling installed? (e.g., if `playwright` is a strategy, is Playwright installed?)
+   - Are the configured commands valid? (e.g., does `commands.test` actually run?)
+
+3. **Adjust if needed:**
+   - If a criterion is too vague, make it more specific
+   - If a verification method requires tooling that is not set up, either:
+     - Add a setup step to the sprint
+     - Change the verification method to something available
+     - Mark the criterion as `required: false` if it cannot be verified
+   - If the sprint scope is too large for the configured sprint size, flag this to the user
+
+4. **Update the contract** status to `in-progress` and save it back to `.bober/contracts/`
+
+5. **Append to `.bober/history.jsonl`:**
+   ```json
+   {"event":"sprint-started","contractId":"...","specId":"...","timestamp":"..."}
+   ```
+
+## Step 3: Create Context Handoff
+
+Create a ContextHandoff document for the Generator. This document is the ONLY context the Generator receives -- it must be self-contained.
+
+**ContextHandoff structure:**
+```json
+{
+  "handoffId": "handoff-<contractId>-gen-<iteration>",
+  "type": "to-generator",
+  "contractId": "<contract ID>",
+  "specId": "<spec ID>",
+  "timestamp": "<ISO-8601>",
+  "iteration": 1,
+  "context": {
+    "projectOverview": "<Brief project description from PlanSpec>",
+    "completedSprints": [
+      {
+        "contractId": "<ID>",
+        "title": "<title>",
+        "summary": "<what was built>"
+      }
+    ],
+    "currentBranch": "<git branch name>",
+    "relevantFiles": [
+      "<key files the generator should read>"
+    ]
+  },
+  "contract": { "<full SprintContract object>" },
+  "config": {
+    "commands": { "<commands section from bober.config.json>" },
+    "generator": { "<generator section from bober.config.json>" }
+  },
+  "evaluatorFeedback": null
+}
+```
+
+Save the handoff to `.bober/handoffs/<handoffId>.json`.
+
+**For retry iterations** (iteration > 1), include the evaluator's feedback:
+```json
+{
+  "evaluatorFeedback": {
+    "evalId": "<ID of the failed evaluation>",
+    "failedCriteria": [
+      {
+        "criterionId": "sc-1-2",
+        "description": "<what failed>",
+        "feedback": "<evaluator's detailed feedback>",
+        "file": "<file path if applicable>",
+        "line": "<line number if applicable>"
+      }
+    ],
+    "regressions": ["<any regressions found>"],
+    "generatorFeedback": ["<structured feedback items>"]
+  }
+}
+```
+
+## Step 4: Spawn the Generator
+
+Invoke the `bober-generator` subagent with the handoff document.
+
+**Before spawning:**
+1. Ensure the correct git branch exists and is checked out:
+   ```bash
+   git checkout -b bober/<feature-slug> 2>/dev/null || git checkout bober/<feature-slug>
+   ```
+2. If this is a retry, the Generator should be on the same branch with the previous attempt's code still present.
+
+**Spawn the Generator:**
+Use the `bober-generator` agent definition. Pass it the handoff file path.
+
+**After the Generator completes:**
+1. Read the Generator's completion report
+2. Verify the Generator committed its changes (check `git log`)
+3. Proceed to evaluation
+
+## Step 5: Spawn the Evaluator
+
+Create an Evaluator handoff document:
+
+```json
+{
+  "handoffId": "handoff-<contractId>-eval-<iteration>",
+  "type": "to-evaluator",
+  "contractId": "<contract ID>",
+  "specId": "<spec ID>",
+  "timestamp": "<ISO-8601>",
+  "iteration": 1,
+  "context": {
+    "generatorReport": { "<Generator's completion report>" },
+    "changedFiles": ["<files the generator reports changing>"],
+    "branch": "<current branch>"
+  },
+  "contract": { "<full SprintContract object>" },
+  "config": {
+    "commands": { "<commands section from bober.config.json>" },
+    "evaluator": { "<evaluator section from bober.config.json>" }
+  }
+}
+```
+
+Save the handoff to `.bober/handoffs/<handoffId>.json`.
+
+**Spawn the Evaluator:**
+Use the `bober-evaluator` agent definition. Pass it the handoff file path.
+
+**After the Evaluator completes:**
+1. Read the EvalResult
+2. Save the EvalResult to `.bober/eval-results/` if the evaluator could not (it lacks Write tools)
+3. Determine pass/fail
+
+## Step 6: Process Evaluation Result
+
+### If the sprint PASSES:
+
+1. **Update the contract status** to `completed`:
+   ```json
+   { "status": "completed", "completedAt": "<ISO-8601>" }
+   ```
+   Save to `.bober/contracts/<contractId>.json`
+
+2. **Update `.bober/progress.md`:**
+   Change the sprint's status from `[in-progress]` to `[completed]`
+
+3. **Append to `.bober/history.jsonl`:**
+   ```json
+   {"event":"sprint-completed","contractId":"...","specId":"...","iteration":N,"timestamp":"..."}
+   ```
+
+4. **Report success to the user:**
+   ```
+   Sprint <N> PASSED on iteration <M>.
+
+   Completed: <sprint title>
+   Key results:
+   - <criterion 1>: PASS
+   - <criterion 2>: PASS
+   ...
+
+   Next sprint: <next sprint title> (run /bober.sprint to continue)
+   ```
+
+### If the sprint FAILS and retries remain:
+
+Check `evaluator.maxIterations` from `bober.config.json` (default: 3). If the current iteration is less than `maxIterations`:
+
+1. **Log the failure:**
+   ```json
+   {"event":"sprint-iteration-failed","contractId":"...","iteration":N,"failedCriteria":["sc-1-2"],"timestamp":"..."}
+   ```
+
+2. **Create a retry handoff** (go back to Step 3 with `iteration + 1` and include evaluator feedback)
+
+3. **Report the retry to the user:**
+   ```
+   Sprint <N> iteration <M> FAILED. <X> of <Y> criteria not met.
+   Retrying (iteration <M+1> of <maxIterations>)...
+
+   Failed criteria:
+   - <criterion>: <brief reason>
+   ```
+
+4. **Go to Step 4** (spawn Generator again with feedback)
+
+### If the sprint FAILS and no retries remain:
+
+1. **Update the contract status** to `needs-rework`:
+   ```json
+   { "status": "needs-rework", "lastEvalId": "<eval ID>" }
+   ```
+
+2. **Update `.bober/progress.md`:**
+   Change the sprint's status to `[needs-rework]`
+
+3. **Append to `.bober/history.jsonl`:**
+   ```json
+   {"event":"sprint-failed","contractId":"...","specId":"...","totalIterations":N,"timestamp":"..."}
+   ```
+
+4. **Report failure to the user with full context:**
+   ```
+   Sprint <N> FAILED after <maxIterations> iterations.
+
+   Contract: <contract title>
+   Failed criteria:
+   - <criterion>: <detailed failure description>
+
+   Last evaluator feedback:
+   <structured feedback>
+
+   Recommended actions:
+   - Review the failed criteria and evaluator feedback
+   - Consider simplifying the sprint scope
+   - Run /bober.sprint <N> to retry from scratch
+   - Run /bober.plan to revise the plan
+   ```
+
+## Step 7: Context Reset
+
+After a sprint completes (pass or fail), manage context:
+
+Read `pipeline.contextReset` from config:
+- `always`: Context is fully reset between sprints. The next sprint starts fresh with only the handoff document.
+- `on-threshold`: Context resets only if the conversation is getting long. Not applicable in single-sprint skill execution.
+- `never`: Context carries forward. Not recommended.
+
+## Error Handling
+
+- **Generator fails to produce any output:** Mark sprint as `needs-rework` with note "Generator produced no output"
+- **Evaluator cannot run strategies:** Report which strategies failed to execute and why. If a required strategy cannot run, mark sprint as `needs-rework` with a configuration issue note.
+- **Git conflicts:** Report the conflict to the user. Do not auto-resolve.
+- **Build broken before sprint started:** Verify the build passes BEFORE starting the Generator. If the build is already broken, report this and do not proceed.
+- **Missing dependencies:** If `npm install` or equivalent has not been run, run it before starting.

package/skills/bober.sprint/references/contract-schema.md

@@ -0,0 +1,251 @@
+# SprintContract JSON Schema
+
+This document defines the complete schema for SprintContract documents. Sprint contracts are the binding agreement between the Planner, Generator, and Evaluator for a single sprint.
+
+## Location
+
+SprintContract files are stored at: `.bober/contracts/<contractId>.json`
+
+## Naming Convention
+
+- `contractId` format: `sprint-<specId>-<sprint-number>`
+- Example: `sprint-spec-20260326-user-auth-1`
+- Sprint numbers are 1-indexed (first sprint is 1, not 0)
+
+## Full Schema
+
+```json
+{
+  "contractId": "string (required)",
+  "specId": "string (required, references parent PlanSpec)",
+  "sprintNumber": "number (required, 1-indexed)",
+  "title": "string (required, concise sprint title)",
+  "description": "string (required, what this sprint delivers)",
+  "status": "string (required, one of: proposed, in-progress, completed, needs-rework)",
+  "createdAt": "string (required, ISO-8601)",
+  "updatedAt": "string (required, ISO-8601)",
+  "completedAt": "string (optional, ISO-8601, set when status becomes completed)",
+
+  "dependsOn": [
+    "string — contractId references for sprints that must complete before this one"
+  ],
+
+  "features": [
+    "string — featureId references from the parent PlanSpec"
+  ],
+
+  "successCriteria": [
+    {
+      "criterionId": "string (required, format: sc-<sprint>-<index>)",
+      "description": "string (required, specific testable criterion)",
+      "verificationMethod": "string (required, one of: manual, typecheck, lint, unit-test, playwright, api-check, build, custom)",
+      "required": "boolean (required, true = must pass for sprint to pass)",
+      "customCommand": "string (optional, command to run for custom verification)"
+    }
+  ],
+
+  "generatorNotes": "string (required, guidance for the Generator agent)",
+  "evaluatorNotes": "string (required, guidance for the Evaluator agent)",
+
+  "estimatedFiles": [
+    "string — file paths expected to be created or modified"
+  ],
+
+  "estimatedDuration": "string (required, one of: small, medium, large)",
+
+  "iterationHistory": [
+    {
+      "iteration": "number",
+      "evalId": "string — reference to EvalResult",
+      "result": "string (pass | fail)",
+      "timestamp": "string (ISO-8601)"
+    }
+  ],
+
+  "lastEvalId": "string (optional, reference to most recent EvalResult)"
+}
+```
+
+## Field Descriptions
+
+### Core Fields
+
+| Field | Description |
+|-------|-------------|
+| `contractId` | Unique identifier. Generated by the Planner. Never changes. |
+| `specId` | Reference to the parent PlanSpec. Used to load broader context. |
+| `sprintNumber` | Position in the sprint sequence. 1-indexed. |
+| `title` | Concise description of what this sprint delivers. Should start with a verb: "Implement...", "Add...", "Create...". |
+| `description` | 2-4 sentences describing the sprint's deliverables and scope. |
+| `status` | Lifecycle state. See Status Transitions below. |
+
+### Status Transitions
+
+```
+proposed → in-progress → completed
+                ↓
+          needs-rework → in-progress → completed
+```
+
+- `proposed`: Created by the Planner. Not yet started or reviewed.
+- `in-progress`: Contract negotiated and Generator is working on it.
+- `completed`: All required success criteria passed evaluation.
+- `needs-rework`: Failed evaluation after maximum iterations. Requires human intervention or plan revision.
+
+### Dependencies
+
+| Field | Description |
+|-------|-------------|
+| `dependsOn` | Array of `contractId` values that must have status `completed` before this sprint can start. Empty array for the first sprint. |
+| `features` | Array of `featureId` values from the parent PlanSpec that this sprint implements (partially or fully). |
+
+### Success Criteria
+
+Each success criterion is a single testable statement that the Evaluator checks independently.
+
+| Field | Description |
+|-------|-------------|
+| `criterionId` | Unique within the contract. Format: `sc-<sprintNumber>-<index>` (1-indexed). |
+| `description` | Specific, testable criterion. Must describe observable behavior or measurable outcome. |
+| `verificationMethod` | How the Evaluator should verify this criterion. |
+| `required` | If `true`, this criterion MUST pass for the sprint to pass. If `false`, it is advisory. |
+| `customCommand` | Only for `verificationMethod: "custom"`. The command the Evaluator should run. |
+
+### Verification Methods
+
+| Method | What the Evaluator Does |
+|--------|------------------------|
+| `manual` | Reads source code and assesses whether the criterion is met based on code inspection and logic tracing. |
+| `typecheck` | Runs the configured typecheck command. Criterion passes if zero type errors. |
+| `lint` | Runs the configured lint command. Criterion passes if zero lint errors (warnings OK). |
+| `unit-test` | Runs the configured test command. Criterion passes if all tests pass. |
+| `playwright` | Runs Playwright E2E tests. Criterion passes if all relevant E2E tests pass. |
+| `api-check` | Tests specific API endpoints using curl or similar. Criterion passes if responses match expectations. |
+| `build` | Runs the configured build command. Criterion passes if build succeeds with exit code 0. |
+| `custom` | Runs `customCommand` and interprets the result. Exit code 0 = pass. |
+
+### Agent Notes
+
+| Field | Description |
+|-------|-------------|
+| `generatorNotes` | Free-form guidance for the Generator. Should include: key files to examine for patterns, known gotchas, suggested implementation order, references to similar existing code. |
+| `evaluatorNotes` | Free-form guidance for the Evaluator. Should include: specific things to test, edge cases to check, how to verify UI criteria, expected API response shapes. |
+
+### Estimates
+
+| Field | Description |
+|-------|-------------|
+| `estimatedFiles` | Array of file paths the Generator is expected to create or modify. This is advisory -- the Generator may touch additional files if needed. The Evaluator uses this to check for unexpected changes. |
+| `estimatedDuration` | Relative size estimate: `small` (30-60 min), `medium` (1-3 hours), `large` (3-5 hours). |
+
+### Iteration History
+
+| Field | Description |
+|-------|-------------|
+| `iterationHistory` | Array of past evaluation attempts. Appended after each evaluation. |
+| `lastEvalId` | Reference to the most recent EvalResult. Updated after each evaluation. |
+
+## Complete Example
+
+```json
+{
+  "contractId": "sprint-spec-20260326-user-auth-1",
+  "specId": "spec-20260326-user-auth",
+  "sprintNumber": 1,
+  "title": "Implement user registration with form and API",
+  "description": "Create the user registration flow end-to-end: a React registration form with email, password, and confirm-password fields; an Express API endpoint that validates input and creates a user record in PostgreSQL with a bcrypt-hashed password; and basic form validation on both client and server.",
+  "status": "proposed",
+  "createdAt": "2026-03-26T10:00:00Z",
+  "updatedAt": "2026-03-26T10:00:00Z",
+  "completedAt": null,
+
+  "dependsOn": [],
+
+  "features": ["feat-1"],
+
+  "successCriteria": [
+    {
+      "criterionId": "sc-1-1",
+      "description": "The project builds successfully with zero errors.",
+      "verificationMethod": "build",
+      "required": true
+    },
+    {
+      "criterionId": "sc-1-2",
+      "description": "TypeScript compilation produces zero type errors.",
+      "verificationMethod": "typecheck",
+      "required": true
+    },
+    {
+      "criterionId": "sc-1-3",
+      "description": "A registration form component exists at the /register route with email, password, and confirm-password input fields, each with an associated label.",
+      "verificationMethod": "manual",
+      "required": true
+    },
+    {
+      "criterionId": "sc-1-4",
+      "description": "POST /api/auth/register accepts { email, password } and returns 201 with { id, email } on success.",
+      "verificationMethod": "api-check",
+      "required": true
+    },
+    {
+      "criterionId": "sc-1-5",
+      "description": "POST /api/auth/register returns 400 with an error message when email is already registered.",
+      "verificationMethod": "api-check",
+      "required": true
+    },
+    {
+      "criterionId": "sc-1-6",
+      "description": "The password is stored as a bcrypt hash in the database, never in plain text.",
+      "verificationMethod": "manual",
+      "required": true
+    },
+    {
+      "criterionId": "sc-1-7",
+      "description": "Client-side validation shows an error when password is shorter than 8 characters before form submission.",
+      "verificationMethod": "manual",
+      "required": true
+    },
+    {
+      "criterionId": "sc-1-8",
+      "description": "ESLint reports zero errors on all new and modified files.",
+      "verificationMethod": "lint",
+      "required": false
+    }
+  ],
+
+  "generatorNotes": "Look at existing route definitions in src/routes/ for the Express routing pattern. The project uses Prisma -- check prisma/schema.prisma for the existing schema and add a User model. Use bcrypt (already in package.json) for password hashing. For the React form, follow the pattern in src/components/ -- the project uses controlled components with useState. The registration form should be at src/pages/Register.tsx and the route added to src/App.tsx.",
+
+  "evaluatorNotes": "For sc-1-3: Read the Register component source and verify it renders three labeled input fields. For sc-1-4 and sc-1-5: Start the dev server and use curl to test the endpoint. For sc-1-6: Read the route handler code and verify bcrypt.hash is called before database insertion. For sc-1-7: Read the form component code and verify client-side validation logic exists for password length.",
+
+  "estimatedFiles": [
+    "prisma/schema.prisma",
+    "src/routes/auth.ts",
+    "src/pages/Register.tsx",
+    "src/App.tsx"
+  ],
+
+  "estimatedDuration": "medium",
+
+  "iterationHistory": [],
+  "lastEvalId": null
+}
+```
+
+## Writing Good Success Criteria
+
+### Do
+
+- Start with an observable action or state: "The form displays...", "The API returns...", "The database contains..."
+- Include specific values: "returns 201", "displays 'Invalid email'", "at least 8 characters"
+- Map each criterion to exactly one verification method
+- Include at least one `build` criterion and one functional criterion per sprint
+- Write criteria the Evaluator can verify without guessing
+
+### Do Not
+
+- Use subjective language: "looks good", "works well", "clean code"
+- Combine multiple checks in one criterion (split them)
+- Reference internal implementation details unless checking them IS the criterion
+- Write criteria that require human visual judgment (unless verification method is `manual` and the check is code-inspectable)
+- Assume the Evaluator has context beyond the contract and handoff documents

package/templates/base/CLAUDE.md

@@ -0,0 +1,20 @@
+# Project Guide
+
+## Overview
+
+This project uses the bober agent harness for autonomous development with Claude.
+
+## Getting Started
+
+Check `bober.config.json` for the configured commands and evaluator strategies. Customize them for your stack.
+
+## Conventions
+
+- Write clear, well-typed code.
+- Include tests for new functionality.
+- Keep changes focused and minimal per sprint.
+- Follow the patterns established in the sprint contracts.
+
+## Commands
+
+Update the `commands` section of `bober.config.json` with your project's build, test, lint, and dev commands.

package/templates/base/bober.config.json

@@ -0,0 +1,35 @@
+{
+  "project": {
+    "name": "",
+    "mode": "greenfield",
+    "description": ""
+  },
+  "planner": {
+    "maxClarifications": 5,
+    "model": "opus"
+  },
+  "generator": {
+    "model": "sonnet",
+    "maxTurnsPerSprint": 50,
+    "autoCommit": true,
+    "branchPattern": "bober/{feature-name}"
+  },
+  "evaluator": {
+    "model": "sonnet",
+    "strategies": [
+      { "type": "build", "required": true }
+    ],
+    "maxIterations": 3
+  },
+  "sprint": {
+    "maxSprints": 10,
+    "requireContracts": true,
+    "sprintSize": "medium"
+  },
+  "pipeline": {
+    "maxIterations": 20,
+    "requireApproval": false,
+    "contextReset": "always"
+  },
+  "commands": {}
+}

package/templates/brownfield/CLAUDE.md

@@ -0,0 +1,34 @@
+# Brownfield Project Guide
+
+## Working with Existing Code
+
+This is a brownfield project. The codebase has existing patterns, conventions, and tests that must be respected.
+
+### Before Making Changes
+
+1. **Read first.** Before modifying any file, read the surrounding code to understand local conventions (naming, patterns, abstractions).
+2. **Run existing tests.** Execute the full test suite before starting work. Record the baseline pass/fail state so you can detect regressions.
+3. **Understand the dependency graph.** Check imports and exports to know what depends on the code you are changing.
+
+### While Making Changes
+
+- **Follow existing patterns.** If the codebase uses a particular abstraction (e.g., repository pattern, custom hooks, service layer), use the same abstraction. Do not introduce competing patterns.
+- **Match the style.** Match indentation, naming conventions, comment style, and file organization of the surrounding code. Consistency matters more than personal preference.
+- **Minimal surface area.** Change only what is necessary to deliver the feature. Avoid drive-by refactors unless they are part of the sprint contract.
+- **Preserve public APIs.** Do not change function signatures, type exports, or module interfaces unless the sprint contract explicitly requires it. Other code depends on them.
+- **Add tests for new behavior.** Every new code path needs a corresponding test. Use the same test framework and patterns already in the project.
+
+### After Making Changes
+
+1. **Run the full test suite.** All previously passing tests must still pass.
+2. **Run the linter.** Zero new warnings or errors.
+3. **Run type checking.** Zero new type errors.
+4. **Review the diff.** The changeset should be focused and minimal. Remove accidental changes (whitespace, formatting, unrelated files).
+
+## Commands
+
+Commands are auto-detected from the existing project. Check `bober.config.json` for the resolved command map, or inspect `package.json` / `Makefile` / `pyproject.toml` for the project's native commands.
+
+## Architecture
+
+Refer to the project's own README, CLAUDE.md, or architecture docs for structural guidance. The bober planner will analyze the codebase during planning and encode relevant context into sprint contracts.

package/templates/brownfield/bober.config.json

@@ -0,0 +1,37 @@
+{
+  "project": {
+    "name": "",
+    "mode": "brownfield",
+    "description": "Existing codebase — conservative, incremental changes"
+  },
+  "planner": {
+    "maxClarifications": 5,
+    "model": "opus"
+  },
+  "generator": {
+    "model": "sonnet",
+    "maxTurnsPerSprint": 50,
+    "autoCommit": true,
+    "branchPattern": "bober/{feature-name}"
+  },
+  "evaluator": {
+    "model": "sonnet",
+    "strategies": [
+      { "type": "typecheck", "required": true },
+      { "type": "lint", "required": true },
+      { "type": "unit-test", "required": true }
+    ],
+    "maxIterations": 5
+  },
+  "sprint": {
+    "maxSprints": 10,
+    "requireContracts": true,
+    "sprintSize": "small"
+  },
+  "pipeline": {
+    "maxIterations": 15,
+    "requireApproval": true,
+    "contextReset": "always"
+  },
+  "commands": {}
+}