@tyroneross/build-loop 0.30.3

package/skills/optimize/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: optimize
+description: Use when the user says "optimize this", "optimization", "make X faster", "reduce <metric>", or "speed up my app". Runs a Design of Experiments test matrix — up to 6 variables in one pass — to find which variable actually moves the number. Falls back to one-at-a-time loop for single variables.
+user-invocable: true
+---
+
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+# Optimize
+
+Improve a number you can measure. Build time. Lines of code. Response time. Token cost. Anything where you can write a one-line command that returns a number.
+
+Two modes.
+
+**Multi-variable mode (default).** Run multiple tests in a single experiment using Design of Experiments. You can test six variables at once instead of one. The skill plans the test matrix, runs each combination, and measures the metric on each. It tells you which variable really moved the number. It also tells you which variables only seemed to matter because they happened to vary alongside the real cause. Two to three variables needs four to eight runs. Four to seven variables needs eight runs. Eight or more uses a screening pass that handles up to eleven in twelve runs.
+
+**One-variable mode (fallback).** When you only have one thing to try, the skill loops one change at a time. Try a tweak. Measure. Keep it if the number improves. Revert if it does not. Cheaper to set up. Cannot see interactions.
+
+Both modes keep what works and revert what does not. The metric is the only judge. No vibes-based "this looks better."
+
+## When to Use
+
+After Phase 4 (Execute) when a mechanical metric exists:
+- Build time (seconds)
+- Line count in changed files (simplification)
+- Test coverage (%)
+- Bundle size (bytes)
+- Response time / latency benchmarks
+- Any command that outputs a number
+
+Skip when the metric is subjective or requires human judgment.
+
+## Phase 1: SETUP (Opus) — Three-Branch Routing
+
+Highest-leverage phase. Wrong metric = Goodhart's Law. Wrong factors = wasted runs.
+
+### Step 1.1 — Detect trigger shape
+
+| Branch | Trigger | Action |
+|---|---|---|
+| **A. Power-user explicit** | User supplied factors via CLI flag, `.build-loop/optimize/factors.json`, or inline ("optimize batch_size, retries, workers for throughput") | Skip suggestion; use the user's factors directly |
+| **B. Vague optimization** *(default)* | "run optimization", "make my app faster", "improve performance", "speed up", "reduce <metric>" without naming factors | Run factor-identification scan; propose candidates; **AskUserQuestion to confirm before running** |
+| **C. Single-variable explicit** | "simplify this file", "reduce build time", scoped `/build-loop:optimize <known-target>` | Skip DOE; run autoresearch (existing behavior, Phase 2 LOOP unchanged) |
+
+### Step 1.2 — Branch A or B: factor identification
+
+**Branch A** (factors pre-supplied): validate shape `[{name, low, high}, ...]` or `[{name, levels: [...]}, ...]`. Skip to Step 1.3.
+
+**Branch B** (suggest factors): run the codebase scanner, present candidates, ask for confirmation.
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/optimize_suggest_factors.py --workdir "$PWD" --top 12 --json
+```
+Returns ranked candidates (UPPER_SNAKE constants near tuning keywords, env vars with numeric defaults, etc.). For each, the scanner suggests low/center/high levels.
+
+**Then AskUserQuestion** (multi-select, all candidates pre-checked):
+> "Which of these should I optimize?"
+> [✓] BATCH_SIZE (currently 32) — try [16, 32, 64]
+> [✓] RETRIES (currently 3) — try [1, 3, 5]
+> [ ] TIMEOUT_MS (currently 5000) — try [3000, 5000, 8000]
+> Free-text: "add my own factor / change levels"
+> Decline path: "skip optimization"
+
+Only proceed once the user confirms. Do NOT auto-run optimization on heuristic candidates without explicit user buy-in — false positives are common (toast delays, breakpoints, port numbers all look numeric to the scanner but aren't perf knobs).
+
+**Optional: research-backed levels (opt-in).** If `availablePlugins.research` is true AND the user explicitly asks for "research-backed levels" (or accepts the prompt below), append `--research-levels` to the scanner invocation:
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/optimize_suggest_factors.py --workdir "$PWD" --top 12 --json --research-levels
+```
+
+The scanner adds `needs_research: true` and a `research_topic` string to high-confidence candidates whose names match known tuning keywords (BATCH_SIZE, TIMEOUT, WORKERS, etc.). For each marked candidate, invoke `Skill("build-loop:research")` with the topic string ("best-practice levels for BATCH_SIZE (currently 32)"). Use the returned ranges to augment — not replace — the scanner's heuristic levels in the AskUserQuestion prompt. Default behavior is heuristic-only because research adds latency (a few minutes per candidate); the opt-in is for cases where the user wants level recommendations grounded in benchmarks rather than evenly-spaced guesses around the current value.
+
+The script never calls research itself — it only flags candidates worth researching. The orchestrator decides whether to invoke the research skill based on the user's explicit opt-in.
+
+### Step 1.3 — Design selection (Branches A + B with k≥2)
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/optimize_doe.py detect <k>
+```
+Auto-routes by factor count: `k=1` → fall back to autoresearch (Branch C), `2 ≤ k ≤ 3` → 2^k full factorial (4–8 runs), `4 ≤ k ≤ 7` → 2^(k-p) fractional R-III/IV (8 runs), `k ≥ 8` → Plackett-Burman 12-run screening (handles up to 11).
+
+Generate the matrix:
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/optimize_doe.py generate \
+  --factors "$(cat .build-loop/optimize/factors.json)" \
+  --design auto --seed "$RANDOM" \
+  > .build-loop/optimize/doe.json
+```
+
+### Step 1.4 — Branch C: autoresearch setup
+
+Single-factor — keep the existing setup. Define:
+1. `target` — what to optimize (name)
+2. `scope` — which files can change (glob or list)
+3. `metric_cmd` — shell command → number
+4. `guard_cmd` — shell command that must exit 0
+5. `budget` — max total iterations (default 5 for post-build, 20 for standalone)
+6. `direction` — `"lower"` or `"higher"`
+7. `metric_samples` — measured benchmark runs per iteration (default 1)
+8. `metric_warmups` — warmup runs discarded before measuring (default 0)
+9. `metric_aggregate` — how to combine samples (`last`, `mean`, `median`, `p95`, etc.)
+
+Auto-detection: run `python3 ${CLAUDE_PLUGIN_ROOT}/scripts/optimize_loop.py --detect --workdir "$PWD"` to discover available single-variable targets.
+
+Initialize:
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/optimize_loop.py   --init --workdir "$PWD"   --target "<name>" --scope "<glob>"   --metric-cmd "<cmd>" --guard-cmd "<cmd>"   --budget <N> --direction "<lower|higher>"   --metric-samples <count> --metric-warmups <count>   --metric-aggregate "<last|min|max|mean|median|p95>"
+```
+
+For latency work such as semantic search, do not optimize on one timer reading. Use a representative query set, run multiple measured samples, discard at least one warmup when cold starts matter, and aggregate with `median` or `p95`.
+
+## Phase 2: LOOP (Sonnet)
+
+### Branch A/B (DOE) — run the matrix
+
+For each row in `.build-loop/optimize/doe.json` (in randomized `run_order`):
+1. Apply the factor values from `runs[i]._factors` to the codebase / config / env
+2. Run `metric_cmd` (with `metric_samples` and `metric_warmups` from setup)
+3. Run `guard_cmd` (must exit 0)
+4. Append to `.build-loop/optimize/results.jsonl`: `{"run_id": i, "value": <number>, "guard_ok": true}`
+5. Revert factor changes (each run is from the same baseline; DOE doesn't accumulate)
+
+After all runs complete, fit effects:
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/optimize_doe.py analyze \
+  --design .build-loop/optimize/doe.json \
+  --results .build-loop/optimize/results.jsonl \
+  --direction "<lower|higher>" \
+  > .build-loop/optimize/effects.json
+```
+
+Output: ranked main effects + interactions, `r2` if non-saturated, best run id with the winning factor levels. The output also includes a `best_factors` block mapping factor names to their concrete values at the best run. Apply the winning combination as a single commit.
+
+**Optional handoff to autoresearch.** For local search around the DOE-identified optimum, initialize an autoresearch experiment using the effects.json as the starting baseline:
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/optimize_loop.py \
+  --init --workdir "$PWD" \
+  --target "<name>" \
+  --metric-cmd "<cmd>" --guard-cmd "<cmd>" \
+  --direction "<lower|higher>" \
+  --baseline-config .build-loop/optimize/effects.json
+```
+
+`--baseline-config` reads the DOE best-run factor levels and records them in `experiment.json.doe_baseline.factors`. The autoresearch agent reads that block before its first iteration, applies those values as the starting point, then iterates from there. Without `--baseline-config`, the loop starts from the current working tree as before.
+
+### Branch C (autoresearch) — single-variable greedy
+
+Dispatch the `optimize-runner` agent. It executes:
+
+```
+1. Read .build-loop/optimize/experiment.json + results.tsv + git log
+2. Hypothesize: ONE atomic change based on what worked/failed before
+3. Edit: only files matching scope
+4. Commit: git commit -m "optimize: <description>"
+5. Measure: run metric_cmd with the configured sampling settings
+6. Guard: run guard_cmd
+7. Decide: improved over best_value AND guard passes → KEEP (update best)
+           worse OR guard fails → git revert HEAD
+8. Log: append to results.tsv with hypothesis text
+9. Convergence check:
+   - 5 consecutive discards → plateau, stop
+   - metric trending worse over 3 kept iterations → regressing, stop
+   - budget exhausted → stop
+10. If not converged → step 1
+```
+
+## Phase 3: REVIEW (Opus + Sonnet)
+
+1. Dispatch `overfitting-reviewer` (Sonnet, read-only): check for removed safety features, fragile shortcuts, test-gaming
+2. Generate summary: iterations, kept/reverted, improvement %, top changes
+3. Archive: `python3 ${CLAUDE_PLUGIN_ROOT}/scripts/optimize_loop.py --archive --workdir "$PWD"`
+
+## Model Tiering
+
+| Component | Model | Why |
+|-----------|-------|-----|
+| Setup | Opus | Wrong metric = Goodhart |
+| Hypothesis generation | Sonnet (pinned) | High volume, 5x cheaper |
+| Metric/guard execution | Bash | No LLM |
+| Keep/revert | Deterministic | Numeric comparison |
+| Overfitting review | Sonnet (read-only) | Pattern matching |
+| Final report | Opus | Judgment |
+
+## Integration with Build-Loop
+
+Phase 4.7 (AUTO-OPTIMIZE): after Phase 4 Execute completes and commits, check for optimization targets. Run sequentially (not parallel with Phase 4).
+
+Standalone: `/build-loop:optimize [target]`
+
+## State Files
+
+```text
+.build-loop/optimize/
+├── experiment.json    # Active config
+├── results.tsv        # Iteration log with hypotheses
+└── experiments/       # Archived pairs (.json + .tsv)
+```
+
+## Built-in Profiles
+
+See `profiles.md`. The `simplify` profile is always available. For latency-sensitive work, start with `semantic-search-latency` or `optimize-perf` plus explicit sampling settings.

package/skills/optimize/profiles.md

@@ -0,0 +1,61 @@
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+# Optimization Profiles
+
+## simplify (always available)
+
+Reduce code complexity in files touched by the current build.
+
+- **Metric**: `wc -l <scope_files> | tail -1 | awk '{print $1}'` (total lines)
+- **Guard**: `npm run build` or `npm test` (must still compile/pass)
+- **Direction**: lower
+- **Budget**: 5
+- **Scope**: Files changed in current build (`git diff --name-only HEAD~N`)
+- **What it finds**: Dead imports, unused variables, redundant files, extractable constants, inlinable one-use helpers
+
+## optimize-build
+
+- **Metric**: `/usr/bin/time -p npm run build 2>&1 | grep ^real | awk '{print $2}'`
+- **Guard**: `npm test -- --passWithNoTests`
+- **Direction**: lower
+- **Budget**: 5
+- **Scope**: Build configs, bundler configs, tsconfig
+
+## optimize-tests
+
+- **Metric**: Coverage % from test runner
+- **Guard**: All existing tests pass
+- **Direction**: higher
+- **Budget**: 5
+- **Scope**: Test files only
+
+## optimize-bundle
+
+- **Metric**: `du -sk .next/static 2>/dev/null | awk '{print $1}'` (KB)
+- **Guard**: `npm run build`
+- **Direction**: lower
+- **Budget**: 5
+- **Scope**: Source files importing large dependencies
+
+## optimize-perf
+
+Use when a workload has a benchmark command but no specialized preset.
+
+- **Metric**: Custom benchmark command that prints one numeric value
+- **Guard**: Test suite passes
+- **Direction**: lower
+- **Budget**: 10
+- **Scope**: Hot-path source files
+- **Benchmark guidance**: Prefer representative workloads over microbenchmarks. For latency, run repeated samples with `--metric-samples 5-9`, discard cold-start noise with `--metric-warmups 1-2`, and aggregate with `median` or `p95`.
+
+## semantic-search-latency
+
+Use when optimizing end-to-end semantic-search response time in a consumer repo.
+
+- **Metric**: A semantic-search benchmark command over a fixed query set, for example `python3 scripts/bench_semantic_search.py --queries bench/semantic_search_queries.txt --stat p95`
+- **Guard**: Relevance / regression checks for the same search flow plus the normal test suite
+- **Direction**: lower
+- **Budget**: 10
+- **Scope**: Search hot path only — embedding prep, query rewriting, ANN/vector lookup, reranking, caching, result shaping
+- **Runner settings**: Start with `--metric-samples 7 --metric-warmups 1 --metric-aggregate p95`
+- **What it finds**: Cold-start penalties, redundant embeddings, unnecessary reranks, inefficient filters, cache misses, slow result formatting

package/skills/plan-verify/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: plan-verify
+description: Use when build-loop Phase 2 wraps plan drafting, the user runs `/build-loop:plan-verify`, asks to "verify the plan" or "lint the plan", or any plan markdown change touches evidence, synthesis-density, risk_reason, or modifies_api fields. Runs deterministic plan-verify rules and emits findings JSON.
+user-invocable: false
+---
+
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+# plan-verify
+
+## Purpose
+
+Catch grep-checkable plan errors before they ship — orphan misclassifications,
+internal numeric drift, route changes without evidence, package-state
+contradictions, missing markers on factual claims, and missing parallel
+dispatch decisions. It also warns when a non-trivial plan omits the clean-sheet
+vs current-constraints approach comparison. The deterministic counterpart to `plan-critic` (LLM,
+non-deterministic checks).
+
+## When to invoke
+
+- During build-loop **Phase 2 (Plan)**, immediately before "Plan accepted".
+- Any time you receive a plan file authored by another tool/agent.
+- Standalone via `/plan-verify <plan.md>` slash command.
+
+## How to invoke
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/plan_verify.py <plan.md> \
+  --repo "$PWD" \
+  --json
+```
+
+Args:
+
+- `<plan.md>` — required path to plan markdown
+- `--repo <path>` — repo root for grep checks (omit if no repo-relative claims)
+- `--json` — emit findings JSON (default: human summary)
+- `--quiet` — suppress human summary
+
+## Exit codes
+
+| Code | Meaning |
+|------|---------|
+| 0 | No BLOCKERs (WARN/INFO findings allowed) |
+| 1 | At least one BLOCKER — plan must be revised before acceptance |
+| 2 | Verifier error (file not found, malformed input, internal exception) |
+
+## Rules
+
+| # | Rule ID | What it catches | Severity |
+|---|---|---|---|
+| 1 | `delete-with-callers` | "delete `path`" / "`path` has 0 callers" claims grep-disprove against repo | **BLOCKER** |
+| 2 | `route-change-evidence` | 308/301 redirect, "remove route", "deprecate path" without ✅/⚠️/❓ marker or rejection-context within 5 lines | **BLOCKER** |
+| 3 | `package-state` | "X is unused" / "X is in package.json" claims contradicted by manifest | **BLOCKER** |
+| 4 | `numeric-drift` | Aggregate orphan-count appears with different values in same doc | **BLOCKER** |
+| 5 | `missing-evidence` | Factual claim with no ✅/⚠️/❓ marker AND no verification hint within 3 lines | WARN |
+| 6 | `scope-split` | More than 5 Phase headings without "Milestone" structure | INFO |
+| 7 | `less-invasive-shim` | Shim phrasing without nearby "considered alternatives" line | WARN |
+| 8 | `tool-without-permission-tier` | Plan introduces a new tool / MCP server / plugin / skill without naming a T0–T5 permission tier or `permission_tier` keyword within 10 lines | **BLOCKER** |
+| 9 | `external-call-without-budget-ceiling` | Plan introduces a new external API or LLM call without a budget / max_tokens / timeout / rate_limit keyword within 10 lines | WARN |
+| 10 | `risk-surface-change-without-threat-model` | Plan surfaces any risk-surface signal (new tool / MCP / LLM call / persistent memory / auth change / external API / user-data handling) without referencing a threat-model artifact, OWASP/ASI ID, or "threat-model: not-applicable: <reason>" anywhere in the doc | **BLOCKER** |
+| 11 | `parallel-decision-record` | A plan names multiple independent / parallel-safe chunks but omits `parallel_batch:` or `parallel_skipped_reason:` | **BLOCKER** |
+| 12 | `approach-lenses-missing` | A non-trivial architecture/workflow/dependency/interface plan omits `## Approach Lenses` or `Approach Lenses: n/a - <reason>` | WARN |
+
+Rules 8–10 ship with the `security-methodology` skill (build-loop 0.7.x). They lint the security boundary at Phase 2 the same way rules 1–4 lint the factual / orphan / package boundary. When rule 10 fires, the orchestrator's Phase 1 trigger-detector should also be flipping `triggers.riskSurfaceChange: true` — if rule 10 fires but the trigger isn't set, that's a Phase 1 detection gap worth investigating.
+
+## What this does NOT check (use `plan-critic` for these)
+
+- Alternatives genuinely considered (only checks the *phrase* nearby)
+- Scope-split MECE quality (overlapping owners, unowned responsibilities)
+- Headline drift across sections
+- Marker level matches the strength of the underlying evidence
+- Whether the verification source actually supports the marker
+
+## Output: Plan Evidence Contract
+
+Each finding conforms to:
+
+```json
+{
+  "claim_text": "...",
+  "claim_kind": "delete|orphan|...|missing_evidence|...",
+  "subject": {"path": null, "symbol": null, "noun": null},
+  "verification_command": "rg -l ...",
+  "evidence": {"file": "<plan>", "line": 42, "snippet": "..."},
+  "result": "match|no_match|inconclusive",
+  "marker": null,
+  "severity": "BLOCKER|WARN|INFO",
+  "confidence": "high|medium|low",
+  "rule_id": "<rule-name>"
+}
+```
+
+## Test fixtures
+
+`skills/plan-verify/test-fixtures/`:
+
+- `example-app-v20.md` — synthetic, 5 known errors. Expected exit 1.
+- `example-app-v22.md` — synthetic full-scale plan, clean by the new standard. Expected exit 0.
+- `unrelated-good-plan.md` — false-positive control. Expected exit 0.
+- `*-findings.json` — per-fixture expectations.
+
+Run the test suite:
+
+```bash
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/test_plan_verify.py
+```
+
+## Integration with build-loop Phase 2
+
+The Phase 2 plan acceptance gate calls this script. On exit 1, the orchestrator
+must either revise the plan or document the override in `.build-loop/state.json.planVerifyOverride[]`
+with rationale before proceeding. On exit 2, treat as a verifier outage and
+fall back to plan-critic alone with a logged warning.

package/skills/plan-verify/test-fixtures/example-app-v20-findings.json

@@ -0,0 +1,27 @@
+{
+  "fixture": "example-app-v20.md",
+  "expected_exit_code": 1,
+  "description": "Synthetic fixture with 5 known plan errors. Run with --repo pointing at build-loop repo so grep can disprove the delete claims.",
+  "expectations_by_rule_id": {
+    "delete-with-callers": {
+      "min_blocker_count": 1,
+      "rationale": "Claims to delete scripts/optimize_loop.py (has callers in build-loop repo) and scripts/write_run_entry.py (also has callers). At least one must be flagged BLOCKER."
+    },
+    "numeric-drift": {
+      "min_blocker_count": 1,
+      "rationale": "Phase 1 says '6 orphans', Phase 4 says '5 orphans'. Same noun, different counts in the same doc."
+    },
+    "route-change-evidence": {
+      "min_blocker_count": 1,
+      "rationale": "Claims '308 redirect' and 'deprecate path' without grep-evidence within 3 lines."
+    },
+    "missing-evidence": {
+      "min_warn_count": 1,
+      "rationale": "Factual claim 'recharts is unused' has no ✅/⚠️/❓ marker and no verification source within 3 lines."
+    },
+    "package-state": {
+      "min_warn_count": 0,
+      "rationale": "Optional. Will fire if verifier finds a package manifest to check against."
+    }
+  }
+}

package/skills/plan-verify/test-fixtures/example-app-v20.md

@@ -0,0 +1,42 @@
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+# Example App Knowledge-Graph Cleanup — v2.0 (synthetic)
+
+> Synthetic fixture reconstructing the five errors caught in example-app v2.0 review cycles.
+> Used to validate `plan_verify.py`. Do not treat as a real plan.
+
+## Goal
+
+Drop dead knowledge-graph tables, simplify backend routes, and remove unused chart libraries.
+
+## Phase 1 — Database
+
+We will **delete** `scripts/optimize_loop.py` because it has 0 callers in the codebase. The orphan scan flagged it during the last NavGator review.
+
+We will also **delete** `scripts/write_run_entry.py` — it is an orphan with zero references.
+
+Total orphans removed: **6 orphans**.
+
+## Phase 2 — Routes
+
+Remove route `/api/optimize` and replace with a 308 redirect to `/api/optimize-loop`. This change touches the optimize-loop module.
+
+We will deprecate the path `/v1/jobs/run` and migrate callers to `/v2/jobs`.
+
+## Phase 3 — Packages
+
+The `recharts` package is unused — remove it from package.json. We never imported it.
+
+The package `react-vega` is in package.json and we'll keep it.
+
+## Phase 4 — Chart migration
+
+Numeric note: removing the **5 orphans** from Phase 1 will cut bundle size by approximately 12 KB.
+
+(Numeric drift: Phase 1 says "6 orphans", this section says "5 orphans".)
+
+## Phase 5 — Cleanup
+
+We will rename three files. Total touched: ~50 files.
+
+The chart system is now stable. ✅ verified

package/skills/plan-verify/test-fixtures/example-app-v22-findings.json

@@ -0,0 +1,15 @@
+{
+  "fixture": "example-app-v22.md",
+  "expected_exit_code": 0,
+  "description": "Copy of the current real Example App plan v2.2 (clean by the new standard). Should produce zero BLOCKERs.",
+  "expectations_by_rule_id": {
+    "delete-with-callers": { "max_blocker_count": 0 },
+    "numeric-drift": { "max_blocker_count": 0 },
+    "route-change-evidence": { "max_blocker_count": 0 },
+    "package-state": { "max_blocker_count": 0 },
+    "missing-evidence": {
+      "max_warn_count": 50,
+      "rationale": "WARN budget is generous because long real plans have stylistic claims; the BLOCKER count is the gate."
+    }
+  }
+}