@sienklogic/plan-build-run 2.1.0 → 2.1.1

package/dashboard/src/views/partials/todos-content.ejs

@@ -1,53 +0,0 @@
-<h1>Todos</h1>
-
-<p><a href="/todos/new" role="button"
-      hx-get="/todos/new"
-      hx-target="#main-content"
-      hx-push-url="true">Create Todo</a></p>
-
-<% if (todos.length > 0) { %>
-<article>
-  <div class="table-wrap">
-  <table>
-    <thead>
-      <tr>
-        <th scope="col">ID</th>
-        <th scope="col">Title</th>
-        <th scope="col">Priority</th>
-        <th scope="col">Phase</th>
-        <th scope="col">Status</th>
-        <th scope="col">Created</th>
-      </tr>
-    </thead>
-    <tbody>
-      <% todos.forEach(function(todo) { %>
-      <tr>
-        <td><%= todo.id %></td>
-        <td>
-          <a href="/todos/<%= todo.id %>">
-            <%= todo.title %>
-          </a>
-        </td>
-        <td>
-          <span class="status-badge" data-priority="<%= todo.priority %>">
-            <%= todo.priority %>
-          </span>
-        </td>
-        <td><%= todo.phase %></td>
-        <td>
-          <span class="status-badge" data-status="<%= todo.status %>">
-            <%= todo.status %>
-          </span>
-        </td>
-        <td><%= todo.created %></td>
-      </tr>
-      <% }); %>
-    </tbody>
-  </table>
-  </div>
-</article>
-<% } else { %>
-<article>
-  <p>No pending todos found. Add a todo file to <code>.planning/todos/pending/</code> to see it here.</p>
-</article>
-<% } %>

package/dashboard/src/views/phase-detail.ejs

@@ -1,5 +0,0 @@
-<%- include('partials/layout-top', { title: title, activePage: 'phases' }) %>
-
-<%- include('partials/phase-content') %>
-
-<%- include('partials/layout-bottom') %>

package/dashboard/src/views/phase-doc.ejs

@@ -1,5 +0,0 @@
-<%- include('partials/layout-top', { title: title, activePage: 'phases' }) %>
-
-<%- include('partials/phase-doc-content') %>
-
-<%- include('partials/layout-bottom') %>

package/dashboard/src/views/phases.ejs

@@ -1,5 +0,0 @@
-<%- include('partials/layout-top', { title: 'Phases', activePage: 'phases' }) %>
-
-<%- include('partials/phases-content') %>
-
-<%- include('partials/layout-bottom') %>

package/dashboard/src/views/roadmap.ejs

@@ -1,5 +0,0 @@
-<%- include('partials/layout-top', { title: 'Roadmap', activePage: 'roadmap' }) %>
-
-<%- include('partials/roadmap-content') %>
-
-<%- include('partials/layout-bottom') %>

package/dashboard/src/views/todo-create.ejs

@@ -1,5 +0,0 @@
-<%- include('partials/layout-top', { title: 'Create Todo', activePage: 'todos' }) %>
-
-<%- include('partials/todo-create-content') %>
-
-<%- include('partials/layout-bottom') %>

package/dashboard/src/views/todo-detail.ejs

@@ -1,5 +0,0 @@
-<%- include('partials/layout-top', { title: title, activePage: 'todos' }) %>
-
-<%- include('partials/todo-detail-content') %>
-
-<%- include('partials/layout-bottom') %>

package/dashboard/src/views/todos.ejs

@@ -1,5 +0,0 @@
-<%- include('partials/layout-top', { title: 'Todos', activePage: 'todos' }) %>
-
-<%- include('partials/todos-content') %>
-
-<%- include('partials/layout-bottom') %>

package/plugins/cursor-pbr/references/agent-anti-patterns.md

@@ -1,25 +0,0 @@
-<!-- canonical: ../../pbr/references/agent-anti-patterns.md -->
-# Universal Agent Anti-Patterns
-
-These anti-patterns apply to ALL Plan-Build-Run agents. Each agent also has role-specific anti-patterns defined in its own agent file.
-
-## Evidence and Verification
-
-1. **DO NOT** guess, assume, or rely on cached knowledge when codebase evidence is available. Read the actual files.
-2. **DO NOT** trust claims in SUMMARY.md, PLAN.md, or other agent outputs without verifying against the real codebase.
-3. **DO NOT** use subjective or vague language ("seems okay", "looks fine", "probably works"). Be specific and evidence-based.
-4. **DO NOT** present training knowledge as verified fact. Flag unverified claims explicitly.
-
-## Scope and Boundaries
-
-5. **DO NOT** exceed your role. If a task belongs to another agent, stop and recommend the correct agent.
-6. **DO NOT** modify files outside your designated scope. Read-only agents must not attempt fixes. Executors must not modify plans.
-7. **DO NOT** add features, ideas, or scope not requested. Log scope creep to deferred items instead.
-8. **DO NOT** skip steps in your verification or execution protocol, even for "obvious" cases.
-
-## Context and State
-
-9. **DO NOT** contradict locked decisions in CONTEXT.md. These are non-negotiable.
-10. **DO NOT** implement deferred ideas from CONTEXT.md. They do not exist for your purposes.
-11. **DO NOT** consume more than 50% of your context window before producing output. Write incrementally.
-12. **DO NOT** read agent definition files from `agents/*.md`. Agent definitions are auto-loaded by Claude Code via `subagent_type`. Reading them wastes context.

package/plugins/cursor-pbr/references/agent-interactions.md

@@ -1,135 +0,0 @@
-<!-- canonical: ../../pbr/references/agent-interactions.md -->
-# Agent Interaction Map
-
-This document shows how Plan-Build-Run agents communicate through files on disk. Agents never message each other directly -- they read and write shared files in `.planning/`.
-
-## Interaction Graph
-
-```
-                    User / Orchestrator
-                     |           ^
-                     v           |
-              +--------------+   |
-              |  researcher  |---+---> planner
-              +--------------+         |    ^
-                     |                 v    |
-              +--------------+   +--------------+
-              | synthesizer  |   | plan-checker |
-              +--------------+   +--------------+
-                                       |
-                                       v
-                                 +-----------+
-                                 |  executor  |
-                                 +-----------+
-                                       |
-                                       v
-                                 +-----------+
-                                 |  verifier  |----> planner (gap closure)
-                                 +-----------+
-                                       |
-                                       v
-                              +--------------------+
-                              | integration-checker|
-                              +--------------------+
-```
-
-## Per-Agent Interaction Details
-
-### researcher
-
-| Direction | Agent/Role | What |
-|-----------|-----------|------|
-| Receives from | User/Orchestrator | Research topics, CONTEXT.md constraints, phase goals |
-| Produces for | planner | Research documents with technology details and recommendations |
-| Produces for | synthesizer | Research documents to be combined |
-| Produces for | User | Direct reading for decision-making |
-
-### synthesizer
-
-| Direction | Agent/Role | What |
-|-----------|-----------|------|
-| Receives from | researcher | Research documents to synthesize |
-| Receives from | Orchestrator | Paths to research documents, synthesis request |
-| Produces for | planner | SUMMARY.md as consolidated research input for planning |
-| Produces for | User | High-level project/phase research overview |
-
-### planner
-
-| Direction | Agent/Role | What |
-|-----------|-----------|------|
-| Receives from | researcher | Research documents with technology details and recommendations |
-| Receives from | plan-checker | Issue reports requiring plan revision |
-| Receives from | verifier | VERIFICATION.md reports requiring gap closure plans |
-| Receives from | User/Orchestrator | Phase goals, CONTEXT.md, planning requests |
-| Produces for | plan-checker | Plan files for quality verification |
-| Produces for | executor | Plan files for execution |
-| Produces for | verifier | Must-have definitions for verification (embedded in plan frontmatter) |
-
-### plan-checker
-
-| Direction | Agent/Role | What |
-|-----------|-----------|------|
-| Receives from | Orchestrator/User | Plan files to check, phase context |
-| Receives from | planner | Newly created or revised plan files |
-| Produces for | planner | Issue reports for revision |
-| Produces for | Orchestrator/User | Pass/fail decision on plan quality |
-
-### executor
-
-| Direction | Agent/Role | What |
-|-----------|-----------|------|
-| Receives from | Orchestrator | Plan files to execute, continuation instructions |
-| Receives from | planner | The plans themselves (indirectly, via files) |
-| Produces for | verifier | SUMMARY.md for verification, committed code for inspection |
-| Produces for | Orchestrator | Checkpoint responses, completion status |
-| Produces for | planner | Deferred ideas (in SUMMARY.md) for future planning |
-
-### verifier
-
-| Direction | Agent/Role | What |
-|-----------|-----------|------|
-| Receives from | Orchestrator | Phase to verify, timing trigger |
-| Receives from | executor | Completed work (via codebase and SUMMARY.md) |
-| Receives from | Previous VERIFICATION.md | Gaps to re-check (in re-verification mode) |
-| Produces for | planner | Gap list for gap-closure planning (via VERIFICATION.md) |
-| Produces for | Orchestrator | Phase status (passed/gaps_found/human_needed) |
-| Produces for | User | Human verification items with specific test instructions |
-
-### integration-checker
-
-| Direction | Agent/Role | What |
-|-----------|-----------|------|
-| Receives from | Orchestrator | Phases to check, trigger event (milestone/review) |
-| Receives from | verifier | Phase-level verification reports (for context on per-phase status) |
-| Produces for | planner | Integration gap list for cross-phase fix plans |
-| Produces for | Orchestrator | Integration status for milestone decisions |
-| Produces for | User | Integration health overview and security issues |
-
-### debugger
-
-| Direction | Agent/Role | What |
-|-----------|-----------|------|
-| Receives from | Orchestrator/User | Bug reports, symptoms, reproduction steps |
-| Receives from | executor | Errors encountered during execution (via checkpoint responses) |
-| Receives from | verifier | Issues discovered during verification |
-| Produces for | Orchestrator/User | Root cause analysis, fix commits, checkpoint requests |
-| Produces for | planner | Findings requiring architectural changes |
-| Produces for | executor | Simple fix instructions for executor to apply |
-
-### codebase-mapper
-
-| Direction | Agent/Role | What |
-|-----------|-----------|------|
-| Receives from | Orchestrator/User | Focus area to analyze, project path |
-| Receives from | researcher | May be invoked alongside researcher for new projects |
-| Produces for | planner | STACK.md, ARCHITECTURE.md, STRUCTURE.md for informed planning |
-| Produces for | executor | CONVENTIONS.md for code style, TESTING.md for test patterns |
-| Produces for | verifier | All documents as reference for what "correct" looks like |
-| Produces for | User | Direct reading for project understanding |
-
-### general
-
-| Direction | Agent/Role | What |
-|-----------|-----------|------|
-| Receives from | Orchestrator/User | Ad-hoc task instructions |
-| Produces for | Orchestrator/User | Task output (files, formatting, config changes) |

package/plugins/cursor-pbr/references/checkpoints.md

@@ -1,158 +0,0 @@
-<!-- canonical: ../../pbr/references/checkpoints.md -->
-# Checkpoints Reference
-
-How Plan-Build-Run uses checkpoint tasks to pause execution and involve the human.
-
----
-
-## What Are Checkpoints?
-
-Checkpoints are special task types that cause the executor agent to **stop execution** and return control to the orchestrator (or the human). They exist because some tasks require human judgment, manual action, or verification that cannot be automated.
-
-Checkpoints are defined in plan task XML via the `type` attribute. When the executor encounters a checkpoint task, it follows a specific protocol depending on the checkpoint type.
-
----
-
-## Checkpoint Types
-
-Plan-Build-Run supports three checkpoint types:
-
-### checkpoint:human-verify
-
-**Purpose**: The executor has completed work, but a human needs to visually inspect or manually test the result before proceeding.
-
-**Executor behavior**:
-1. Execute the task's `<action>` steps normally
-2. Commit the changes
-3. **STOP execution**
-4. Return a structured `CHECKPOINT: HUMAN-VERIFY` response containing:
-   - What was done (summary of action taken)
-   - What to verify (from the task's `<done>` condition)
-   - How to verify (instructions derived from `<verify>`)
-   - Completed tasks table
-   - Remaining tasks list
-
-**Use when**: The result requires subjective judgment (UI looks correct, behavior feels right, output makes sense) that automated verification cannot cover.
-
-**Example scenario**: A template was created and needs visual review in the browser, or an API integration needs manual testing with real credentials.
-
-### checkpoint:decision
-
-**Purpose**: The plan reaches a point where a human decision is needed before the executor can continue. The task is NOT executed — execution pauses before the task starts.
-
-**Executor behavior**:
-1. **STOP before executing the task**
-2. Return a structured `CHECKPOINT: DECISION` response containing:
-   - The decision that needs to be made (from `<action>`)
-   - Available options
-   - Context to help the human decide
-   - Completed tasks table
-
-**Use when**: The plan has a fork point where different approaches are possible and the right choice depends on human preference, business context, or information the planner could not determine.
-
-**Example scenario**: Choosing between two authentication providers, deciding whether to use a specific third-party library or build in-house.
-
-### checkpoint:human-action
-
-**Purpose**: The task requires something the executor cannot do — a manual step that involves the human interacting with external systems, creating accounts, or performing physical actions.
-
-**Executor behavior**:
-1. **STOP before executing the task**
-2. Return a structured `CHECKPOINT: HUMAN-ACTION` response containing:
-   - What the human needs to do (from `<action>`)
-   - Step-by-step instructions
-   - Prompt to tell the executor when done
-   - Completed tasks table
-
-**Use when**: External setup is required — creating API keys, configuring DNS, setting up OAuth applications, or any action that requires credentials or permissions the agent does not have.
-
-**Example scenario**: The human needs to create a Discord application in the Developer Portal and paste the client ID and secret into `.env`.
-
----
-
-## Checkpoint in Plan Format
-
-Checkpoints are declared in the task's `type` attribute in the plan XML:
-
-```xml
-<task id="02-01-T3" type="checkpoint:human-verify" tdd="false">
-  <name>Verify OAuth login flow in browser</name>
-  <files>...</files>
-  <action>...</action>
-  <verify>Open browser to localhost:3000/auth/login and complete the flow</verify>
-  <done>User can log in via Discord OAuth and see their profile</done>
-</task>
-```
-
-Valid checkpoint type values:
-- `checkpoint:human-verify`
-- `checkpoint:decision`
-- `checkpoint:human-action`
-
-Non-checkpoint task types use `type="auto"`.
-
----
-
-## Autonomous vs Non-Autonomous Plans
-
-The plan frontmatter field `autonomous: true|false` indicates whether a plan contains checkpoint tasks:
-
-| Value | Meaning |
-|-------|---------|
-| `autonomous: true` | No checkpoint tasks. The executor can complete all tasks without human intervention. |
-| `autonomous: false` | Contains at least one checkpoint task. Execution will pause at some point. |
-
-The build orchestrator uses this field to determine execution strategy:
-- Autonomous plans can be executed in parallel with other autonomous plans in the same wave
-- Non-autonomous plans may block the wave while waiting for human input
-- The orchestrator tracks checkpoint state in `.checkpoint-manifest.json`
-
----
-
-## Continuation Protocol
-
-After a checkpoint is resolved (human provides their answer, completes their action, or confirms verification), the orchestrator spawns a **fresh continuation executor** to resume from where the checkpoint paused.
-
-The continuation executor receives:
-1. The full plan content
-2. A table of completed tasks with their commit hashes
-3. The checkpoint resolution (what the human decided or confirmed)
-4. The task number to resume from
-5. The same project context as the original executor
-
-**Key rules for continuation**:
-- The continuation executor does NOT re-execute completed tasks
-- It reads the partial SUMMARY.md if one exists
-- It verifies prior commits exist via `git log`
-- It resumes from the next uncompleted task after the checkpoint
-
----
-
-## Authentication Gate (Implicit Checkpoint)
-
-The executor also supports an implicit checkpoint for authentication failures. If the executor encounters an authentication error (missing API key, expired token, invalid credentials) during any task, it immediately stops and returns a `CHECKPOINT: AUTH-GATE` response.
-
-This is not declared in the plan — it triggers automatically when an auth error is detected. The response includes:
-- Which task was blocked
-- What credential is needed
-- Where to configure it
-- The actual error message
-
----
-
-## Architectural Deviation (Implicit Checkpoint)
-
-Similarly, if the executor discovers that the plan's approach cannot work (API changed, framework limitation, dependency conflict), it stops with a `CHECKPOINT: ARCHITECTURAL-DEVIATION` response. This follows Deviation Rule 4 from the executor's deviation handling protocol.
-
----
-
-## Best Practices for Planners
-
-When creating plans that include checkpoints:
-
-1. **Minimize checkpoint tasks** — each one pauses execution and requires human attention
-2. **Place checkpoints at natural boundaries** — after a feature is complete, not in the middle of wiring
-3. **Group manual actions** — combine related human actions into a single checkpoint rather than multiple stops
-4. **Provide clear instructions** — the `<action>` and `<verify>` elements should give the human everything they need
-5. **Consider autonomous alternatives** — if a task CAN be verified automatically, prefer `type="auto"` with a robust `<verify>` command
-6. **Set `autonomous: false`** in the plan frontmatter when any task is a checkpoint

package/plugins/cursor-pbr/references/planning-config.md

@@ -1,214 +0,0 @@
-<!-- canonical: ../../pbr/references/planning-config.md -->
-# Planning Config Reference
-
-Schema, fields, defaults, and behavioral effects of Plan-Build-Run's `config.json`.
-
----
-
-## Overview
-
-Plan-Build-Run's configuration lives at `.planning/config.json` in the project root. It is created by `/pbr:begin` and can be modified via `/pbr:config` or by editing the file directly. The config controls workflow behavior, model selection, parallelization, git integration, and confirmation gates.
-
----
-
-## Schema Version
-
-```json
-{ "version": 2 }
-```
-
-The `version` field tracks schema migrations. Current version is `2`. When loading a config with an older version, Plan-Build-Run runs automatic migration (e.g., v1 to v2 adds missing fields with defaults, renames `model_profile` to per-agent `models` object).
-
----
-
-## Top-Level Fields
-
-| Field | Type | Default | Description |
-|-------|------|---------|-------------|
-| `version` | number | `2` | Config schema version |
-| `context_strategy` | string | `"aggressive"` | Context budget strategy: `aggressive`, `balanced`, `minimal` |
-| `mode` | string | `"interactive"` | Workflow mode: `interactive` |
-| `depth` | string | `"standard"` | Research/planning depth: `quick`, `standard`, `comprehensive` |
-
-### depth
-
-Controls how thorough research and planning phases are:
-
-| Value | Behavior |
-|-------|----------|
-| `quick` | Minimal research, smaller plans, faster execution |
-| `standard` | Balanced research depth, standard plan detail |
-| `comprehensive` | Deep research with multiple sources, detailed plans with more tasks |
-
-### context_strategy
-
-Controls how aggressively Plan-Build-Run manages context budget:
-
-| Value | Behavior |
-|-------|----------|
-| `aggressive` | Proactive compaction warnings, strict context isolation, minimal file reads in main context |
-| `balanced` | Moderate context management with some inline reads |
-| `minimal` | Relaxed context management, more inline content allowed |
-
----
-
-## features
-
-Boolean toggles that enable or disable specific workflow capabilities.
-
-| Field | Default | Description |
-|-------|---------|-------------|
-| `structured_planning` | `true` | Use phased planning with ROADMAP and plan files |
-| `goal_verification` | `true` | Run verifier agent after builds to check goals are met |
-| `integration_verification` | `true` | Run cross-phase integration checks |
-| `context_isolation` | `true` | Isolate work into subagents to protect main context |
-| `atomic_commits` | `true` | Require one commit per task (vs. batched commits) |
-| `session_persistence` | `true` | Persist state across sessions via STATE.md |
-| `research_phase` | `true` | Run research before planning |
-| `plan_checking` | `true` | Run plan-checker agent before execution |
-| `tdd_mode` | `false` | Enable Test-Driven Development for all tasks (Red-Green-Refactor) |
-| `status_line` | `true` | Show status line in session UI |
-| `auto_continue` | `false` | Write `.auto-next` signal on phase completion for automatic continuation |
-| `auto_advance` | `false` | Chain build→review→plan automatically in autonomous mode (requires `mode: autonomous`) |
-| `team_discussions` | `false` | Enable team-based discussion workflows (never used for execution) |
-| `inline_verify` | `false` | Run per-task verification after each executor commit (opt-in, adds latency) |
-
-### Notable interactions
-
-- `goal_verification: false` skips the post-build verification step. The build skill appends a note suggesting `/pbr:review` manually.
-- `tdd_mode: true` causes all task types to follow Red-Green-Refactor, producing 3 commits per task instead of 1.
-- `auto_continue: true` writes a `.planning/.auto-next` file containing the next command (e.g., `/pbr:plan 4`), allowing wrapper scripts to chain phases.
-- `auto_advance: true` + `mode: autonomous` enables full phase cycling: build completes → auto-invoke review → if verification passes → auto-invoke plan for next phase. Hard stops at: checkpoints, verification gaps, errors, milestone boundaries.
-- `inline_verify: true` spawns a haiku-model verifier after each plan completes within a wave. Adds ~10-20s latency per plan but catches issues before dependent plans run.
-
----
-
-## models
-
-Per-agent model selection. See `references/model-profiles.md` for full details.
-
-```json
-{
-  "models": {
-    "researcher": "sonnet",
-    "planner": "inherit",
-    "executor": "inherit",
-    "verifier": "sonnet",
-    "integration_checker": "sonnet",
-    "debugger": "inherit",
-    "mapper": "sonnet",
-    "synthesizer": "haiku"
-  }
-}
-```
-
-Valid values: `sonnet`, `opus`, `haiku`, `inherit`.
-
----
-
-## parallelization
-
-Controls whether and how plans execute concurrently.
-
-| Field | Type | Default | Description |
-|-------|------|---------|-------------|
-| `enabled` | boolean | `true` | Enable parallel plan execution within a wave |
-| `plan_level` | boolean | `true` | Parallelize at plan level (multiple plans in same wave) |
-| `task_level` | boolean | `false` | Parallelize at task level within a plan (not currently used) |
-| `max_concurrent_agents` | number | `3` | Maximum simultaneous executor subagents |
-| `min_plans_for_parallel` | number | `2` | Minimum plans in a wave to trigger parallel execution |
-| `use_teams` | boolean | `false` | Use Agent Teams for coordination (discussion only, never execution) |
-
-### Behavior
-
-When `enabled: true` and a wave has >= `min_plans_for_parallel` plans, the build orchestrator spawns up to `max_concurrent_agents` executor Task() calls in parallel using `run_in_background: true`.
-
-When `enabled: false` or a wave has only 1 plan, executors run sequentially.
-
-Git lock conflicts can occur with parallel execution. Executors handle this with retry logic (wait 2s, max 3 attempts). If conflicts persist, reduce `max_concurrent_agents` to 1.
-
----
-
-## planning
-
-Controls planning behavior and documentation.
-
-| Field | Type | Default | Description |
-|-------|------|---------|-------------|
-| `commit_docs` | boolean | `true` | Commit planning docs (SUMMARY, VERIFICATION) after builds |
-| `max_tasks_per_plan` | number | `3` | Maximum tasks per plan (keeps plans focused and atomic) |
-| `search_gitignored` | boolean | `false` | Include gitignored files in codebase scanning |
-
-### commit_docs
-
-When `true`, after all plans in a phase complete, the build orchestrator stages and commits planning artifacts:
-```
-docs({phase}): add build summaries and verification
-```
-
-When `false`, planning docs remain unstaged/uncommitted.
-
----
-
-## git
-
-Controls git integration and branching.
-
-| Field | Type | Default | Description |
-|-------|------|---------|-------------|
-| `branching` | string | `"none"` | Branching strategy: `none`, `phase`, `milestone`, `disabled` |
-| `commit_format` | string | `"{type}({phase}-{plan}): {description}"` | Commit message template |
-| `phase_branch_template` | string | `"plan-build-run/phase-{phase}-{slug}"` | Phase branch naming |
-| `milestone_branch_template` | string | `"plan-build-run/{milestone}-{slug}"` | Milestone branch naming |
-| `mode` | string | `"enabled"` | Git mode: `enabled` or `disabled` |
-
-See `references/git-integration.md` for full branching strategy details.
-
-### mode: disabled
-
-When `git.mode` is `"disabled"`, no git commands are run at all -- no commits, no branching, no hook validation. Useful for prototyping or non-git projects.
-
----
-
-## gates
-
-Confirmation gates that pause execution to ask the user before proceeding.
-
-| Field | Default | When Triggered |
-|-------|---------|----------------|
-| `confirm_project` | `true` | Before creating a new Plan-Build-Run project (`/pbr:begin`) |
-| `confirm_roadmap` | `true` | Before finalizing a roadmap |
-| `confirm_plan` | `true` | Before finalizing plans for a phase |
-| `confirm_execute` | `false` | Before starting phase execution (`/pbr:build`) |
-| `confirm_transition` | `true` | Before transitioning to the next phase |
-| `issues_review` | `true` | Before proceeding when issues are detected |
-
-Setting a gate to `false` makes that step automatic (no user prompt).
-
----
-
-## safety
-
-Safety controls for destructive or external operations.
-
-| Field | Type | Default | Description |
-|-------|------|---------|-------------|
-| `always_confirm_destructive` | boolean | `true` | Always ask before destructive git operations |
-| `always_confirm_external_services` | boolean | `true` | Always ask before calling external APIs or services |
-
-These cannot be disabled via `/pbr:config` -- they require manual editing of `config.json` as a deliberate action.
-
----
-
-## Validation Rules
-
-When modifying config (via `/pbr:config` or direct edit):
-
-| Field | Valid Values |
-|-------|-------------|
-| `depth` | `quick`, `standard`, `comprehensive` |
-| `models.*` | `sonnet`, `inherit`, `haiku`, `opus` |
-| `context_strategy` | `aggressive`, `balanced`, `minimal` |
-| `git.branching` | `none`, `phase`, `milestone`, `disabled` |
-| `git.mode` | `enabled`, `disabled` |
-| All boolean fields | `true`, `false` |