v4.3.0: sync with superpowers 7.0.0, demo monorepo, services-pane mod

.claude-plugin/marketplace.json

@@ -9,7 +9,16 @@
       "name": "py-micro-superpowers",
       "source": "./",
       "description": "Superpowers for Python microservices. 25 agents, 17 commands, 21 skills, 1 MCP server.",
-      "version": "4.0.0",
+      "version": "4.3.0",
+      "author": {
+        "name": "BaronVonSario"
+      }
+    },
+    {
+      "name": "services-pane",
+      "source": "./mods/services-pane",
+      "description": "Live pane of monorepo services: planned vs actual changes, waves, progress, tests; start work per service.",
+      "version": "0.1.0",
       "author": {
         "name": "BaronVonSario"
       }

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "py-micro-superpowers",
-  "version": "4.0.0",
+  "version": "4.3.0",
   "description": "Superpowers for Python microservices \u2014 Django, FastAPI, pytest, PostgreSQL review agents and skills built on the superpowers plugin. 25 agents, 17 commands, 21 skills, 1 MCP server.",
   "hooks": {
     "SessionStart": [

.github/workflows/validate.yml

@@ -9,9 +9,27 @@ jobs:
   validate:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-python@v5
+      - uses: actions/checkout@v5
+      - uses: actions/setup-python@v6
         with:
           python-version: "3.12"
       - name: Structural validation
         run: bash scripts/validate.sh
+
+  example:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v5
+      - uses: actions/setup-python@v6
+        with:
+          python-version: "3.12"
+      - name: Install Poetry
+        run: pipx install poetry
+      - name: Test demo monorepo (pytest + ruff + mypy)
+        working-directory: examples/monorepo
+        run: |
+          for s in lib-common orders payments; do
+            echo "::group::$s"
+            (cd "$s" && poetry install -q && poetry run pytest -q && poetry run ruff check . && poetry run mypy .) || exit 1
+            echo "::endgroup::"
+          done

CHANGELOG.md

@@ -5,6 +5,68 @@ All notable changes to the compound-engineering-feat-python plugin will be docum
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [4.3.0] - 2026-11-05
+
+### Added
+- `mods/services-pane/`: optional, separately installable mod (early-access mod API)
+  that shows monorepo services in a pane: planned vs actual changes, waves, plan
+  progress, last test result, with Start work and Ship actions. Listed as a second
+  entry in `.claude-plugin/marketplace.json`; install with
+  `/plugin install services-pane@py-micro-superpowers`.
+- `/workflows:work --no-ship`: run tasks and the Python quality gate, then stop
+  before the PR.
+- Ship-only run: `/workflows:work <root plan>` when every per-service plan is
+  `status: completed` skips execution and goes straight to the quality gate and one PR.
+- `/workflows:work` sets `status: completed` on each per-service plan it finishes
+  once the quality gate passes.
+- `scripts/validate.sh` checks mod manifests and hooks, and runs
+  `claude plugin validate` per mod when `claude` is installed.
+
+### Changed
+- Per-service plans written by `/workflows:plan` no longer copy the `services:`
+  frontmatter, so a per-service run cannot pick up the whole dependency graph.
+
+## [4.2.0] - 2026-11-04
+
+### Added
+- `examples/monorepo/`: a demo with three small FastAPI services (`lib-common`,
+  `orders`, `payments`) and a walkthrough README for testing the workflow commands
+  end to end.
+- `scripts/sandbox.sh`: copies the demo into a throwaway git repo (optionally
+  `--install` runs `poetry install` per service) and prints the
+  `claude --plugin-dir` command to load this checkout.
+- CI job `example`: runs the demo's pytest, ruff and mypy on every push.
+
+### Fixed
+- `.claude-plugin/marketplace.json` version was stuck at 4.0.0.
+
+## [4.1.0] - 2026-11-04
+
+### Changed
+- **Synced with superpowers v7.0.0** (was v6.1.1). superpowers v7.0.0 or later is now required.
+- `/workflows:brainstorm` handles brainstorming's new sizing. For a quick task or a
+  small change no spec is written, so the per-service spec split and the
+  `/workflows:plan` suggestion are skipped. For a project, brainstorming now hands
+  control back to the wrapper instead of invoking `writing-plans` itself, so the
+  focus gate and the per-service split still run. `<focus_context>` is passed to the
+  builder-check subagent.
+- `/workflows:plan` stops after the user reviews the plan and chooses an execution
+  method. It no longer jumps straight into execution and around the Python quality
+  gate. The per-service split now also carries the `**Spec:**` pointer (rewritten to
+  the service's spec) and gives each `## Review Focus` item to the service that owns
+  it.
+- `/workflows:work` supports both upstream executors through a new
+  `--method subagent|native` flag (Native = the rebuilt `executing-plans`). The
+  per-plan workspace path is documented as `.superpowers/sdd/<plan-basename>/`. The
+  test command must run the project's full suite.
+- `/workflows:review` sends the reviewers' "Declined to judge" items to the user for
+  a decision instead of filing them as todos.
+- CI: `actions/checkout@v5`, `actions/setup-python@v6`.
+
+### Fixed
+- `scripts/check-dependencies.sh` now honors `CLAUDE_CONFIG_DIR` and symlinked plugin
+  directories, and warns when the installed superpowers version is older than 7.0.0.
+
 ## [4.0.0] - 2026-07-21
 
 ### Changed (BREAKING)
@@ -64,7 +126,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 - Removed all remaining references to the original template's company/author:
-  `holafly-domain` example skill (now `my-company-domain`), holafly template
+  the company-specific example skill (now `my-company-domain`), template
   attributions in CHANGELOG history, and the author's personal R2 bucket
   (`r2:kieran-claude`) in `/feature-video`.
 - Ported leftover Ruby/Rails idioms to Python across agents: Bundler commands →

README.md

@@ -7,7 +7,7 @@
 <p align="center"><strong>Superpowers for Python microservices.</strong></p>
 
 <p align="center">
-  <a href="CHANGELOG.md"><img src="https://img.shields.io/badge/version-4.0.0-6366f1" alt="Version 4.0.0"></a>
+  <a href="CHANGELOG.md"><img src="https://img.shields.io/badge/version-4.2.0-6366f1" alt="Version 4.2.0"></a>
   <img src="https://img.shields.io/badge/agents-25-4b8bbe" alt="25 agents">
   <img src="https://img.shields.io/badge/commands-17-4b8bbe" alt="17 commands">
   <img src="https://img.shields.io/badge/skills-21-4b8bbe" alt="21 skills">
@@ -40,7 +40,7 @@ For monorepos, every command detects your services (`*/pyproject.toml`), scopes
 
 ## Installation
 
-Requires the `superpowers` plugin (process primitives):
+Requires the `superpowers` plugin **v7.0.0 or later** (process primitives). The session-start check warns if it is missing or older:
 
 ```
 /plugin marketplace add anthropics/claude-plugins-official
@@ -91,7 +91,7 @@ Commands use the `workflows:` prefix to avoid collisions with Claude Code built-
 |---------|---------|
 | `/workflows:brainstorm` | Explore requirements before planning (delegates to `superpowers:brainstorming`) |
 | `/workflows:plan` | Generate implementation plans (delegates to `superpowers:writing-plans`) |
-| `/workflows:work` | Execute a plan with Python quality gates (delegates to `superpowers:subagent-driven-development` / `superpowers:executing-plans`) |
+| `/workflows:work` | Execute a plan with Python quality gates (`--method subagent` → `superpowers:subagent-driven-development`, `--method native` → `superpowers:executing-plans`; `--no-ship` stops after the quality gate, before the PR) |
 | `/workflows:review` | Multi-agent Python code review (delegates to `superpowers:requesting-code-review`) |
 
 Each workflow command:
@@ -285,12 +285,33 @@ All workflow commands accept `--services` for automated invocation (skips all in
 `/workflows:work` is the engine that turns plans into shipped code:
 
 1. **Load context** — project workflow skills + microservice focus gate (execution order for multi-service plans)
-2. **Delegate execution** — `superpowers:subagent-driven-development` runs the task loop with per-task commits and reviews
+2. **Delegate execution** — Subagent-driven (`superpowers:subagent-driven-development`: fresh implementer + reviewer per task) or Native (`superpowers:executing-plans`: this session implements, one whole-branch review). Pick with `--method`, or reuse the choice made at the end of `/workflows:plan`
 3. **Python quality gate (mandatory)** — full pytest suite + ruff + mypy + pre-commit hooks must all pass; loops until clean
 4. **Ship** — commit via the `commit` skill, push, open a PR that includes a Post-Deploy Monitoring & Validation plan
 
 Never ships with failing tests, never skips hooks.
 
+## Services pane (optional)
+
+`mods/services-pane/` is a separate, optional plugin in this repository: a live pane beside the chat that shows each service's planned vs actual changes, run waves, plan progress and last test result, with buttons to start work per service. The main plugin does not depend on it. Early access: it uses Claude Code's mod API, which may change.
+
+```
+/plugin install services-pane@py-micro-superpowers
+```
+
+Open it with `/services`. See [mods/services-pane/README.md](mods/services-pane/README.md).
+
+## Try It Locally
+
+[`examples/monorepo/`](examples/monorepo/README.md) holds three tiny FastAPI services (`lib-common`, `orders`, `payments`). Spin up a throwaway copy as its own git repo and load this checkout of the plugin:
+
+```bash
+./scripts/sandbox.sh --install
+cd <printed path> && claude --plugin-dir <this repo>
+```
+
+The example README walks through brainstorm → plan → work → review on a cross-service feature and says what to check at each step. CI runs the example's pytest, ruff and mypy so it stays green.
+
 ## Development
 
 `scripts/validate.sh` runs the structural checks CI enforces on every push: frontmatter integrity, reference-link resolution, script compilation, stale-reference guards, and component-count consistency.
@@ -299,7 +320,7 @@ Never ships with failing tests, never skips hooks.
 
 See [CHANGELOG.md](CHANGELOG.md) for detailed version history.
 
-**Current version: 4.0.0** — renamed from `compound-engineering-feat-python`; the repository URL is unchanged.
+**Current version: 4.3.0** — adds the optional `services-pane` mod and `--no-ship` for `/workflows:work`.
 
 ## Contributing
 

commands/workflows/brainstorm.md

@@ -45,14 +45,26 @@ Invoke the `superpowers:brainstorming` skill. Pass:
 - The user's feature description from `<feature_description>` as the topic.
 - The `<focus_context>` block returned from Step 2 (so the superpowers skill includes it in any sub-agent prompts it spawns).
 - A note that any Python `workflow_skills` listed above are already loaded in the conversation as additional context.
+- An instruction to include the `<focus_context>` block in the builder-check subagent prompt it dispatches.
+- **An instruction to return control to this wrapper once the design is approved, instead of invoking `superpowers:writing-plans`.** This wrapper owns the plan handoff so `/workflows:plan` can run the focus gate and the per-service split.
 
-The superpowers skill drives the rest of the conversation (clarifying questions, approach exploration, design presentation, spec writing) and returns when the spec is written to the default path. Control then returns to this wrapper for Step 4.
+The superpowers skill drives the rest of the conversation: it draws out intent, plays back what it heard, sizes the work, and (for a project) writes the design and runs the builder check. It returns once the user approves the description. Control then returns to this wrapper.
+
+### Size outcome
+
+`superpowers:brainstorming` (v7+) picks one of three sizes:
+
+| Size | What exists afterwards | This wrapper then |
+|------|------------------------|-------------------|
+| Quick, clear task | Nothing written; the task is done | Skip Step 4. Report what was done. |
+| Small change | Description agreed in chat | Skip Step 4. Restate the agreed description; the user builds it through the normal workflow. |
+| Project | Approved spec at `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` | Run Step 4 (multi-service only), then suggest `/workflows:plan`. |
 
 ## Step 4: Multi-service spec post-processing (multi-service only)
 
 `superpowers:brainstorming` always writes ONE spec to the default path: `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`. It does not know about per-service paths.
 
-If Step 2 returned a non-empty service list, **after the superpowers skill returns**, this wrapper post-processes the spec:
+If Step 2 returned a non-empty service list **and** brainstorming wrote a spec, **after the superpowers skill returns**, this wrapper post-processes the spec:
 
 1. Read the spec at `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`.
 2. For each focused service, write a copy to `{service}/docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` (create the directory with `mkdir -p` first).
@@ -74,6 +86,7 @@ In single-service mode (Step 2 returned empty service list), this entire step is
 
 After the superpowers skill returns, summarize:
 
-- Spec path(s) written.
+- The size brainstorming chose.
+- Spec path(s) written (project size only).
 - The focused services (if multi-service mode).
-- Suggested next step: `/workflows:plan <spec-path>`.
+- Suggested next step for project size: `/workflows:plan <spec-path>`. For a small change, no plan step is needed.

commands/workflows/plan.md

@@ -45,8 +45,10 @@ Invoke the `superpowers:writing-plans` skill. Pass:
 - The input (spec path or feature description) as the planning topic.
 - The `<focus_context>` block from Step 2.
 - A note that loaded Python `workflow_skills` are available in conversation.
+- **An instruction to stop after the user has reviewed the saved plan and chosen an execution method (Subagent-driven or Native), and NOT to invoke `superpowers:subagent-driven-development` or `superpowers:executing-plans`.** Execution goes through `/workflows:work`, which owns the Python quality gate. Record the chosen method for the Output step.
+- **Pipeline mode:** skip the plan-review prompt and the method question; record Subagent-driven.
 
-The superpowers skill drives plan writing: file structure, task decomposition, bite-sized steps, self-review. It returns when the plan is written to its default path `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`. Control then returns to this wrapper for Step 4.
+The superpowers skill drives plan writing: the `**Spec:**` pointer, `## Global Constraints`, `## Review Focus`, task decomposition with `**Interfaces:**` blocks, and self-review. It saves the plan to `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`. Control then returns to this wrapper for Step 4.
 
 ## Step 4: Multi-service plan post-processing (multi-service only)
 
@@ -55,9 +57,10 @@ The superpowers skill drives plan writing: file structure, task decomposition, b
 If Step 2 returned a non-empty service list, **after the superpowers skill returns**, this wrapper post-processes the plan:
 
 1. Read the plan at `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`.
-2. Add or update the YAML frontmatter to include a `services:` section so `/workflows:work` can execute in dependency order:
+2. Add or update the YAML frontmatter to include `status: active` and a `services:` section so `/workflows:work` can execute in dependency order:
 
    ```yaml
+   status: active
    services:
      service-a:
        depends_on: []
@@ -69,12 +72,16 @@ If Step 2 returned a non-empty service list, **after the superpowers skill retur
 
    Determine dependencies from the `<focus_context>` block's `dependencies:` section. Ask the user to confirm or adjust the graph before writing the final plan.
 
-3. **Per-service plan files** — for each focused service, write a copy of the plan to `{service}/docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md` (create the directory with `mkdir -p` first). Each per-service plan contains the tasks scoped to that service, the acceptance criteria, and the file changes for that service only. Copy the plan header — including the `## Global Constraints` section and each task's `**Interfaces:**` block (both part of the superpowers plan format) — verbatim into every per-service plan; task implementers only ever see their own plan file, so cross-service signatures must not be lost in the split.
+3. **Per-service plan files** — for each focused service, write a copy of the plan to `{service}/docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md` (create the directory with `mkdir -p` first). Each per-service plan gets YAML frontmatter containing only `status: active`. Do not copy the `services:` section into per-service plans: a per-service run must not pick up the whole dependency graph. Each per-service plan contains the tasks scoped to that service, the acceptance criteria, and the file changes for that service only. Task implementers only ever see their own plan file, so carry the shared header into every per-service plan:
+   - **`**Spec:**` pointer** — rewrite it to that service's spec copy (`{service}/docs/superpowers/specs/...`) when one exists; otherwise keep the original path.
+   - **`## Global Constraints`** — copy verbatim.
+   - **`**Interfaces:**` blocks** — keep each task's block verbatim, so cross-service signatures are not lost in the split.
+   - **`## Review Focus`** — give each item to the service whose code it exercises, together with the test that pins it. Items that span services stay in the root overview.
 
-4. **Root overview** — keep the root-level plan at `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`. **Rewrite** its body to contain only: the dependency graph, execution order, links to the per-service plans (from sub-step 3), and any cross-cutting concerns. The detailed per-service tasks now live in the per-service files — they should NOT be duplicated in the root.
+4. **Root overview** — keep the root-level plan at `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`. **Rewrite** its body to contain only: the dependency graph, execution order, links to the per-service plans (from sub-step 3), cross-cutting concerns, and cross-service Review Focus items. The detailed per-service tasks now live in the per-service files — they should NOT be duplicated in the root.
 
 In single-service mode (Step 2 returned empty service list), this entire step is skipped — the root plan is the final artifact.
 
 ## Output
 
-Confirm: "Plan written to `<path>`" (and per-service locations if applicable). Suggest next step: `/workflows:work <plan-path>`.
+Confirm: "Plan written to `<path>`" (and per-service locations if applicable). Suggest the next step with the method the user chose: `/workflows:work <plan-path> --method subagent` or `--method native`.

commands/workflows/review.md

@@ -104,6 +104,8 @@ Invoke the `superpowers:requesting-code-review` skill. Pass:
 
 The superpowers skill handles parallel agent execution and findings collection. After it returns, **by default** use the `file-todos` skill to create one todo file per finding under `todos/`, using the standard naming `{issue_id}-pending-{priority}-{description}.md`.
 
+**Declined to judge** — superpowers reviewers list behavior they declined to rule on. Do not file these as P1/P2/P3 todos. Present them to the user as a separate list and ask which ones to treat as findings; file todos only for those.
+
 **Exception** — if the user invoked the command with `--no-todos`, or if the user explicitly requested an inline summary during the conversation, surface findings as a categorized list (P1/P2/P3) without writing files.
 
 ## Step 9: Browser Test Offer (Optional)
@@ -121,5 +123,6 @@ If the user accepts, spawn a sub-agent to run `/test-browser` for the PR. The su
 Summarize:
 - PR/branch reviewed.
 - Number of P1/P2/P3 findings.
+- "Declined to judge" items awaiting the user's decision (if any).
 - Path to todos/ (if file-todos was used).
 - Next-step recommendation (e.g., "Address P1 findings before merging").