bigpowers 2.87.4 → 2.87.5

package/.gemini/extensions/bigpowers/commands/prompts/wire-observability.md

@@ -0,0 +1,96 @@
+---
+name: wire-observability
+description: "Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development."
+---
+
+# Wire Observability
+> **HARD GATE** — **HARD GATE** — Observability is not optional. Before shipping, verify: structured logging is in place, key metrics are instrumented, error cases emit signals. 'We'll add metrics later' becomes 'never.'
+
+
+Add structured logging, observability commands, and idempotent setup scripts. Can be invoked at any phase — recommended at the end of the first working slice, before the first deploy.
+
+## What this sets up
+
+1. **Structured JSON logging** — machine-readable logs for debugging and observability
+2. **Observability commands** — how to check the system's health documented in CLAUDE.md
+3. **Idempotent setup scripts** — scripts that can be run repeatedly without side effects
+
+## Process
+
+### 1. Assess current state
+
+Check what's already in place:
+- Is there a logging library? (pino, winston, structlog, zap, slog, etc.)
+- Is logging JSON or plain text?
+- Is there a health check endpoint or command?
+- Are there setup scripts? Are they idempotent?
+
+### 2. Add structured JSON logging
+
+**For user-facing CLI output:** plain text is fine.
+**For everything else:** structured JSON.
+
+Structured log entry format:
+```json
+{
+  "level": "info",
+  "timestamp": "2025-01-15T10:23:45.123Z",
+  "message": "User created",
+  "userId": "usr_abc123",
+  "requestId": "req_xyz789"
+}
+```
+
+Guidelines:
+- Include `level`, `timestamp`, `message` in every entry
+- Add context fields relevant to the operation (userId, requestId, traceId)
+- Log at boundaries: HTTP requests in/out, DB queries, external API calls, background job start/end
+- Log errors with stack traces: `logger.error({ err, context }, "Operation failed")`
+- **Never log secrets, passwords, tokens, or PII**
+
+### 3. Document observability commands in CLAUDE.md
+
+Add an "Observability" section to the project's CLAUDE.md:
+
+```markdown
+## Observability
+
+| What | Command |
+|------|---------|
+| View logs | `<log tail command>` |
+| Health check | `<health check command>` |
+| Check DB connection | `<db ping command>` |
+| View metrics | `<metrics command>` |
+```
+
+### 4. Write idempotent setup scripts
+
+An idempotent script can be run multiple times and always produces the same result (no errors on re-run).
+
+Pattern: check if the thing already exists before creating it.
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Idempotent: only create if not exists
+if ! psql -c "SELECT 1 FROM pg_database WHERE datname = 'myapp'" | grep -q 1; then
+  createdb myapp
+  echo "Database created"
+else
+  echo "Database already exists, skipping"
+fi
+```
+
+Place setup scripts in `scripts/setup.sh` (or language-appropriate equivalent). Document the command in CLAUDE.md under Commands.
+
+### 5. Verify
+
+- [ ] Run the app and confirm JSON logs appear in the correct format
+- [ ] Run `scripts/setup.sh` twice — second run should produce no errors
+- [ ] Health check command returns success
+- [ ] No sensitive data in log output
+
+## BCP Plus Integration
+
+This skill maps to **BCP Plus dimension 11 (Quality Attributes)** — specifically performance, reliability, and availability instrumentation. Structured logging, health checks, and idempotent setup scripts are observable manifestations of quality-attribute requirements. The NFR Gate rule applies: standard-expectation items (e.g., "the app should log errors") score 0 with a one-line rationale; only above-standard quality requirements (e.g., p99 latency tracking, SLO-based alerting) contribute to the dimension 11 count. See `docs/references/bcp-plus.md` for the full 13-dimension framework and NFR Gate pattern.

package/.gemini/extensions/bigpowers/commands/prompts/write-document.md

@@ -0,0 +1,280 @@
+---
+name: write-document
+description: "Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs/ directory."
+---
+
+# Write Document (BMAD)
+
+Create high-signal technical documentation that serves as an expert collaborator for both humans and AI. This skill enforces the BMAD principles to prevent context rot and ensure architectural durability.
+
+**Distinct from `edit-document`:** Use this skill to create a document that does not yet exist. Use `edit-document` when a document already exists and needs restructuring, clarity, or prose improvements.
+
+> **HARD GATE** — Every document must have a clear "Reason for Existence." If a document doesn't provide actionable leverage for a caller or test, do not create it.
+
+## The BMAD Principles
+
+| Principle | Execution |
+| :--- | :--- |
+| **B**old | Make strong assertions. Define clear boundaries and "Never" rules. No "it might" or "usually." |
+| **M**inimal | High-density, low-filler. **Circuit Breaker**: If the file exceeds 300 lines or the session exceeds 20 turns, you MUST run `terse-mode` and compact state before saving. |
+| **A**ctionable | Link every doc to a verifiable outcome. **Architectural Docs**: Verify via Gherkin features (`specs/verifications/features/`) or grep-based structure checks (`grep -c "pattern" file`) that prove the design's *constraints* are present. |
+| **D**urable | Design for the long-term. **Scalability**: Use "Nested Indexing"—root files link to module-level `GEMINI.md` indexes; do not list individual sub-files in the root. |
+
+## Process
+
+### 1. Identify the Artifact Type & Scope
+
+Choose the correct BMAD-BigPowers artifact:
+- **Decision Record (ADR)**: For "Why" decisions (saved to `specs/adr/`).
+- **Context Map**: For system-wide architectural mapping (`specs/tech-architecture/tech-stack.md`).
+- **Technical Guide**: For "How-to" with verification (saved to `<module>/REFERENCE.md`).
+- **Behavioral Feature**: Gherkin-style compliance specs (saved to `specs/verifications/features/`).
+- **Project README**: Project-facing documentation (saved to `README.md` at project root).
+
+**Cross-Cutting Concerns**: If a doc affects multiple modules, place the authoritative source in the lowest common ancestor directory and use "Delegates" (one-line pointers) in sub-directories to maintain the Single Source of Truth without violating the Stepdown Rule.
+
+### 2. Draft with Semantic Velocity
+
+> **STREAM CONTINUITY** — When writing file content, output in continuous chunks of ~200 lines. Do not pause. Continue immediately until complete. If you need time, emit a placeholder comment rather than going silent.
+
+Write the document focusing on "Expert Collaboration":
+- **Instructions over Descriptions**: Tell the reader (human or AI) exactly how to interact with the system.
+- **Provenance Links**: Link to ADRs, Issues, or Commits to preserve intent.
+- **The Stepdown Rule**: Information should descend exactly one level of abstraction. If a root doc needs to explain a leaf-level detail, it must point to a sub-index first.
+
+### Quick README (Project READMEs only)
+
+1. Ask: "Project name? One-sentence description?"
+2. Generate `README.md` at project root using the template in [REFERENCE.md](REFERENCE.md) — no TOC, no second interview round.
+3. Fill gaps from `CLAUDE.md` / `AGENTS.md` commands if available (prefer `AGENTS.md`); use `TODO` markers otherwise.
+4. Output and suggest `edit-document` for polish.
+
+→ verify: `test -f README.md && [ "$(grep -c '^## ' README.md)" -ge 7 ]`
+
+### 3. Apply the 94% Quality Gate
+
+Before finalizing, audit the document against these red flags:
+- [ ] **Filler Language**: Are there pleasantries or "I hope this helps"? (Delete them).
+- [ ] **Ambiguity**: Are there "usually," "often," or "it depends" without specific conditions?
+- [ ] **Dead Ends**: Does the document end without a "Next Step" or "Verification" command?
+- [ ] **Shallow Content**: Does it restate the code without explaining the *intent* or *contracts*?
+
+### 4. Sync and Organize
+
+- **Big Powers Hierarchy**: Place the document in the correct tier (Global -> Project -> Sub-directory). Project READMEs are an exception — they go to project root (`README.md`), not `specs/`.
+- **Nested Indexing**: If adding a module-level doc, ensure the module's `GEMINI.md` is updated. If the module's index is new, add it to the root `GEMINI.md`.
+- **Sync**: Run `scripts/sync-skills.sh` if the document is a `SKILL.md` or affects generated artifacts.
+
+## Rules
+
+- **Minimalism is a requirement**: If a document can be a 5-line table, do not make it a 5-line essay.
+- **Verifiable outcomes**: Every technical document must include at least one `verify:` command. For architecture, this can be a `grep` or `run_shell_command` that validates the existence of required files or patterns.
+- **No speculative docs**: Do not write documentation for features that do not exist yet unless explicitly doing `elaborate-spec`.
+
+
+Suggest next skill: `audit-code` or `sync-skills.sh`.
+
+---
+
+# Project README Template
+
+Combined from dbader/readme-template and jehna/readme-best-practices. No TOC.
+
+## Navigation
+
+| Lines | Section |
+|-------|---------|
+| 1 | Title |
+| 5–40 | Navigation |
+| 41–42 | Sections |
+| 43–54 | 1. Title + Badges |
+| 55–60 | 2. Tagline |
+| 61–64 | 3. Description |
+| 65–67 | 4. Prerequisites |
+| 68–75 | Prerequisites |
+| 76–78 | 5. Installation |
+| 79–89 | Installation |
+| 90–92 | 6. Usage |
+| 93–102 | Usage |
+| 103–105 | 7. Features |
+| 106–113 | Features |
+| 114–116 | 8. Configuration |
+| 117–125 | Configuration |
+| 126–128 | 9. Development Setup |
+| 129–139 | Development |
+| 140–142 | 10. Running Tests |
+| 143–152 | Tests |
+| 153–155 | 11. Contributing |
+| 156–164 | Contributing |
+| 165–167 | 12. Changelog |
+| 168–172 | Changelog |
+| 173–175 | 13. Links |
+| 176–181 | Links |
+| 182–184 | 14. License |
+| 185–191 | License |
+| 192–194 | 15. Credits (optional) |
+| 195–199 | Credits |
+| 200–202 | Verify |
+
+## Sections
+
+### 1. Title + Badges
+
+```markdown
+# Project Name
+
+![License](https://img.shields.io/badge/License-MIT-yellow.svg)
+![npm version](https://img.shields.io/npm/v/your-package.svg)
+
+```
+
+Fill badges from CLAUDE.md stack info if available. Default to license + version badges.
+
+### 2. Tagline
+
+```markdown
+> One-line description of what this project does and why it matters.
+```
+
+### 3. Description
+
+2-3 paragraphs: what problem it solves, who it's for, and what makes it different.
+
+### 4. Prerequisites
+
+```markdown
+## Prerequisites
+
+- **Runtime**: Node.js v18+ (from CLAUDE.md)
+- **Package manager**: npm (or pnpm/yarn)
+```
+
+Auto-fill from CLAUDE.md commands section when possible.
+
+### 5. Installation
+
+```markdown
+## Installation
+
+```bash
+npm install -g your-package
+# or
+npx your-package
+```
+```
+
+Prefer npx one-shot if applicable; list global install as alternative.
+
+### 6. Usage
+
+```markdown
+## Usage
+
+```bash
+your-command --help
+your-command do-something
+```
+```
+
+Include the most common 1-2 commands. Link to full docs if they exist.
+
+### 7. Features
+
+```markdown
+## Features
+
+- Feature 1: short description
+- Feature 2: short description
+```
+
+3-6 bullet points of what the project does. Derived from the project's purpose.
+
+### 8. Configuration
+
+```markdown
+## Configuration
+
+| Variable | Default | Description |
+|----------|---------|-------------|
+| `VAR_NAME` | `value` | What it controls |
+```
+
+Use `TODO` markers if unknown.
+
+### 9. Development Setup
+
+```markdown
+## Development
+
+```bash
+git clone <repo-url>
+cd project
+npm install
+```
+```
+
+Auto-fill from CLAUDE.md `Run` and `Build` commands.
+
+### 10. Running Tests
+
+```markdown
+## Tests
+
+```bash
+npm test
+npm run lint
+```
+```
+
+Auto-fill from CLAUDE.md `Test` and `Lint` commands.
+
+### 11. Contributing
+
+```markdown
+## Contributing
+
+1. Fork the repo.
+2. Create a feature branch (`git checkout -b feature/my-thing`).
+3. Commit changes (`git commit -am 'Add my thing'`).
+4. Push (`git push origin feature/my-thing`).
+5. Open a Pull Request.
+```
+
+### 12. Changelog
+
+```markdown
+## Changelog
+
+See [CHANGELOG.md](../../CHANGELOG.md) or [Releases](https://github.com/user/repo/releases).
+```
+
+### 13. Links
+
+```markdown
+## Links
+
+- Repository: https://github.com/user/repo
+- Issue tracker: https://github.com/user/repo/issues
+```
+
+### 14. License
+
+```markdown
+## License
+
+MIT — see [LICENSE](../../LICENSE) for details.
+```
+
+Detect from CLAUDE.md or project LICENSE file.
+
+### 15. Credits (optional)
+
+```markdown
+## Credits
+
+Built with [bigpowers](https://www.npmjs.com/package/bigpowers).
+```
+
+## Verify
+
+After generation, run: `grep -c "^## " README.md` — expect ≥ 7 section headings.

package/.gemini/extensions/bigpowers/gemini-extension.json

@@ -0,0 +1,16 @@
+{
+  "name": "bigpowers",
+  "version": "2.87.5",
+  "description": "81 skills — 73 agent skills synthesizing 17 years of software engineering discipline into a prescriptive methodology for solo developers",
+  "keywords": [
+    "gemini-extension"
+  ],
+  "gemini": {
+    "skills": [
+      "./skills"
+    ],
+    "commands": [
+      "./commands"
+    ]
+  }
+}

package/.gemini/extensions/bigpowers/hooks/HOOKS.md

@@ -0,0 +1,43 @@
+# Gemini CLI Hook Events — bigpowers Extension
+
+**Config path:** `~/.gemini/settings.json` (global) or `.gemini/settings.json` (project)  
+**Hook scripts (installed):** `~/.gemini/hooks/` — symlinked from this directory in Wave B via `install_gemini()`  
+**Naming:** Gemini uses `BeforeTool`/`AfterTool` (not Claude's `PreToolUse`/`PostToolUse`).
+
+## All 11 events
+
+| Event | Fires when | bigpowers status |
+|-------|------------|------------------|
+| `BeforeTool` | Before a tool executes | **Shipped** — git guard, RTK, token-mgmt wrappers |
+| `AfterTool` | After a tool completes | Documented — no default hook |
+| `BeforeAgent` | Before agent loop iteration | Documented — no default hook |
+| `AfterAgent` | After agent loop iteration | Documented — no default hook |
+| `BeforeModel` | Before model call | Documented — no default hook |
+| `BeforeToolSelection` | Before tool selection | Documented — no default hook |
+| `AfterModel` | After model response | Documented — no default hook |
+| `SessionStart` | Session startup / clear / compact | **Shipped** — `session-start` |
+| `SessionEnd` | Session ends | Documented — no default hook |
+| `Notification` | User notification | Documented — no default hook |
+| `PreCompress` | Before context compression | Documented — no default hook |
+
+## Shipped templates (this directory)
+
+| Script | Event | Matcher | Purpose |
+|--------|-------|---------|---------|
+| `session-start` | SessionStart | `startup\|clear\|compact` | Project survey + using-bigpowers bootstrap |
+| `run-hook.cmd` | (polyglot launcher) | — | Windows + Unix hook runner |
+| `before-tool-git-guard.sh` | BeforeTool | `run_shell_command` | Delegates to `guard-git` with `GIT_GUARDRAILS_MODE=gemini` |
+| `before-tool-rtk.sh` | BeforeTool | `run_shell_command` | RTK passthrough when installed (optional) |
+| `before-tool-token-mgmt.sh` | BeforeTool | `read_file`, `glob`, `run_shell_command` | Token backstop (optional) |
+
+See `settings.json.example` for wiring snippets. Machine-readable list: `hooks-manifest.json`.
+
+## Wave B (install hub)
+
+Hub install (`scripts/install.sh` → `install_gemini()`) symlinks these scripts to `~/.gemini/hooks/` and merges hook entries into `~/.gemini/settings.json`. See `scripts/test-gemini-hub.sh` for regression checks.
+
+## Verify locally
+
+```bash
+bash scripts/test-gemini-adapter.sh
+```

package/.gemini/extensions/bigpowers/hooks/before-tool-git-guard.sh

@@ -0,0 +1,26 @@
+#!/usr/bin/env bash
+# story: e64s01
+# BeforeTool wrapper — git guardrails for Gemini CLI (GIT_GUARDRAILS_MODE=gemini).
+set -euo pipefail
+
+find_repo_root() {
+  local d
+  d="$(cd "$(dirname "$0")" && pwd)"
+  while [[ "$d" != "/" && ! -d "$d/scripts" ]]; do
+    d="$(dirname "$d")"
+  done
+  if [[ ! -d "$d/scripts" ]]; then
+    echo "before-tool-git-guard: repo root not found" >&2
+    echo '{"decision":"allow"}'
+    exit 0
+  fi
+  echo "$d"
+}
+
+ROOT="$(find_repo_root)"
+GUARD="$ROOT/skills/guard-git/scripts/block-dangerous-git.sh"
+if [[ ! -x "$GUARD" && ! -f "$GUARD" ]]; then
+  echo '{"decision":"allow"}'
+  exit 0
+fi
+exec env GIT_GUARDRAILS_MODE=gemini bash "$GUARD"

package/.gemini/extensions/bigpowers/hooks/before-tool-rtk.sh

@@ -0,0 +1,14 @@
+#!/usr/bin/env bash
+# story: e64s01
+# BeforeTool wrapper — RTK command rewrite (optional; passthrough when rtk absent).
+set -euo pipefail
+
+if command -v rtk >/dev/null 2>&1; then
+  if rtk hook gemini 2>/dev/null; then
+    exit 0
+  fi
+  if rtk hook claude 2>/dev/null; then
+    exit 0
+  fi
+fi
+exit 0

package/.gemini/extensions/bigpowers/hooks/before-tool-token-mgmt.sh

@@ -0,0 +1,19 @@
+#!/usr/bin/env bash
+# story: e64s01
+# BeforeTool wrapper — token management backstop (delegates to repo hook when present).
+set -euo pipefail
+
+find_repo_root() {
+  local d
+  d="$(cd "$(dirname "$0")" && pwd)"
+  while [[ "$d" != "/" && ! -d "$d/scripts" ]]; do
+    d="$(dirname "$d")"
+  done
+  [[ -d "$d/scripts" ]] && echo "$d" && return 0
+  return 1
+}
+
+ROOT="$(find_repo_root)" || exit 0
+HOOK="$ROOT/scripts/hooks/token-mgmt-pre-tool-use.sh"
+[[ -f "$HOOK" ]] || exit 0
+exec bash "$HOOK"

package/.gemini/extensions/bigpowers/hooks/hooks-manifest.json

@@ -0,0 +1,36 @@
+{
+  "schema_version": 1,
+  "target": "gemini",
+  "config_path": "~/.gemini/settings.json",
+  "events_total": 11,
+  "events": [
+    "BeforeTool",
+    "AfterTool",
+    "BeforeAgent",
+    "AfterAgent",
+    "BeforeModel",
+    "BeforeToolSelection",
+    "AfterModel",
+    "SessionStart",
+    "SessionEnd",
+    "Notification",
+    "PreCompress"
+  ],
+  "shipped_hooks": [
+    {
+      "event": "SessionStart",
+      "script": "session-start",
+      "matcher": "startup|clear|compact",
+      "wave": "a",
+      "status": "shipped"
+    },
+    {
+      "event": "BeforeTool",
+      "script": "before-tool-git-guard.sh",
+      "matcher": "run_shell_command",
+      "wave": "a",
+      "status": "template"
+    }
+  ],
+  "polyglot_launcher": "run-hook.cmd"
+}

package/.gemini/extensions/bigpowers/hooks/run-hook.cmd

@@ -0,0 +1,29 @@
+: << 'CMDBLOCK'
+@echo off
+REM Cross-platform polyglot wrapper for hook scripts.
+REM On Windows: cmd.exe runs the batch portion, which finds and calls bash.
+REM On Unix: the shell interprets this as a script (: is a no-op in bash).
+
+if "%~1"=="" (
+    echo run-hook.cmd: missing script name >&2
+    exit /b 1
+)
+
+set "HOOK_DIR=%~dp0"
+
+REM Try bash on PATH
+where bash >nul 2>nul
+if %ERRORLEVEL% equ 0 (
+    bash "%HOOK_DIR%%~1" %2 %3 %4 %5 %6 %7 %8 %9
+    exit /b %ERRORLEVEL%
+)
+
+REM No bash found - exit silently
+exit /b 0
+CMDBLOCK
+
+# Unix: run the named script directly
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+SCRIPT_NAME="$1"
+shift
+exec bash "${SCRIPT_DIR}/${SCRIPT_NAME}" "$@"

package/.gemini/extensions/bigpowers/hooks/session-start

@@ -0,0 +1,48 @@
+#!/usr/bin/env bash
+# session-start hook for bigpowers
+
+set -euo pipefail
+
+# 1. Find the project root (contains scripts/ and .gemini/)
+FIND_ROOT="$(cd "$(dirname "$0")" && pwd)"
+while [[ "$FIND_ROOT" != "/" && ! -d "$FIND_ROOT/scripts" ]]; do
+  FIND_ROOT="$(dirname "$FIND_ROOT")"
+done
+
+if [[ ! -d "$FIND_ROOT/scripts" ]]; then
+  # Fallback to a relative guess if we can't find it by walking up
+  SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+  FIND_ROOT="$(cd "${SCRIPT_DIR}/../../.." && pwd)"
+fi
+
+# 2. Run the project survey
+survey_content=$("${FIND_ROOT}/scripts/project-survey.sh" 2>&1 || echo "Error running project survey at ${FIND_ROOT}")
+
+# 3. Read the Bigpowers bootstrap skill
+bootstrap_content=$(cat "${FIND_ROOT}/.gemini/extensions/bigpowers/commands/using-bigpowers.md" 2>/dev/null || echo "Bigpowers skills system active.")
+
+# Escape string for JSON embedding
+escape_for_json() {
+    local s="$1"
+    s="${s//\\/\\\\}"
+    s="${s//\"/\\\"}"
+    s="${s//$'\n'/\\n}"
+    s="${s//$'\r'/\\r}"
+    s="${s//$'\t'/\\t}"
+    printf '%s' "$s"
+}
+
+survey_escaped=$(escape_for_json "$survey_content")
+bootstrap_escaped=$(escape_for_json "$bootstrap_content")
+
+# Combined context
+session_context="<BIGPOWERS_BOOTSTRAP>\n${survey_escaped}\n\n---\n\n${bootstrap_escaped}\n</BIGPOWERS_BOOTSTRAP>"
+
+# Output based on platform
+if [ -n "${CURSOR_PLUGIN_ROOT:-}" ]; then
+  printf '{\n  "additional_context": "%s"\n}\n' "$session_context"
+elif [ -n "${CLAUDE_PLUGIN_ROOT:-}" ] && [ -z "${COPILOT_CLI:-}" ]; then
+  printf '{\n  "hookSpecificOutput": {\n    "hookEventName": "SessionStart",\n    "additionalContext": "%s"\n  }\n}\n' "$session_context"
+else
+  printf '{\n  "additionalContext": "%s"\n}\n' "$session_context"
+fi

package/.gemini/extensions/bigpowers/hooks/settings.json.example

@@ -0,0 +1,41 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "startup|clear|compact",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"$HOME/.gemini/hooks/run-hook.cmd\" session-start",
+            "async": false
+          }
+        ]
+      }
+    ],
+    "BeforeTool": [
+      {
+        "matcher": "run_shell_command",
+        "hooks": [
+          {
+            "name": "git-guardrails",
+            "type": "command",
+            "command": "GIT_GUARDRAILS_MODE=gemini \"$HOME/.gemini/hooks/before-tool-git-guard.sh\"",
+            "timeout": 5000
+          }
+        ]
+      },
+      {
+        "matcher": "run_shell_command",
+        "hooks": [
+          {
+            "name": "rtk-rewrite",
+            "type": "command",
+            "command": "\"$HOME/.gemini/hooks/before-tool-rtk.sh\"",
+            "timeout": 3000
+          }
+        ]
+      }
+    ]
+  },
+  "_comment": "Example only — Wave B install_gemini() merges into ~/.gemini/settings.json. Copy paths after install.sh symlinks hooks."
+}