agent-council 0.1.0

data/examples/prompts/test-coverage-analysis-prompt.md

@@ -0,0 +1,346 @@
+# Test Coverage Analysis by Logical Area Prompt
+
+Give this prompt to an AI coding agent from the root of your Ruby project. It
+uses cov-loupe to produce a report of line coverage organized by the logical
+parts of your system, down to individual classes and methods, and ranks the
+gaps by risk. It never asks for input, so it also works headless (e.g.
+`claude -p`, `codex exec`, CI).
+
+**Requirement:** run your full test suite (every suite that feeds SimpleCov)
+first, make sure it passes, and don't change source or test files until the
+analysis finishes. The prompt does not run tests; it reads the existing
+`coverage.json` and refuses to start if that file looks out of date. This lets
+several agents run it concurrently against the same coverage data.
+
+---
+
+### Unattended Operation
+
+This prompt never asks the user anything, so it runs the same interactively or
+headless. Never stop to wait for input: when a precondition fails, stop with an
+error message instead. The invocation may name a different report location
+(e.g. "write the report to `tmp/reports`") or coverage file location.
+
+### Preconditions
+
+Before you begin the analysis:
+
+1. If your current working directory is not the project root (the output of
+   `git rev-parse --show-toplevel`), stop with an error that states your
+   current working directory and the expected root. Do not run the analysis.
+2. Always open the report by citing the most recent git commit at the time you
+   begin writing.
+3. If `git status` shows uncommitted changes, include them in the analysis:
+   analyze the working tree as it is, and list the `git status` details
+   immediately after the commit citation.
+4. Analyze the files git would consider part of the project: tracked files
+   plus new files not yet added, excluding anything git ignores
+   (`git ls-files --cached --others --exclude-standard`). Mark the untracked
+   files in the `git status` details.
+
+----
+
+- You are a senior engineer assessing the test suite of this project.
+- Your task is to produce a report of line coverage **organized by the logical
+  parts of the system**, not just a per-file list, and to judge where the gaps
+  actually matter.
+- Get every coverage number from cov-loupe. Do not read `coverage.json`
+  directly, and do not estimate coverage by reading tests. Aggregating
+  cov-loupe's per-line output into area totals is expected (see Step 4).
+- Prefer the cov-loupe MCP server. If it is unavailable, use the CLI
+  (`cov-loupe`, or `bundle exec cov-loupe` if it is in the Gemfile; run
+  `cov-loupe --help` for usage), adding `-m cli -fJ` for JSON output. Say in
+  the report which one you used.
+- Use source and test files only to define the logical areas and to judge the
+  importance of uncovered code.
+- Do not run the test suite, and do not modify source files, test files, or
+  coverage output. Other agents may be running this analysis concurrently
+  against the same data. This is a read-only analysis; the only file you
+  write is the report.
+- Before recommending tests for uncovered code, check whether it is
+  intentionally excluded or untested: SimpleCov filters and `# :nocov:`
+  markers, and any project documentation or code comments explaining why.
+
+## Step 1: Verify the coverage data is current
+
+The user must run the full, passing test suite before this analysis. Verify
+what you can, and if any check below fails, stop with an error that names the
+failed check, gives the coverage file's path, size, and modification time (if
+it exists), and tells the user to rerun the full suite. Do not write a report.
+
+1. Find the SimpleCov configuration (`.simplecov`, `spec/spec_helper.rb`,
+   `test/test_helper.rb`, or wherever the project starts SimpleCov) and the
+   coverage file (`coverage/coverage.json` unless the configuration or the
+   invocation says otherwise). The file must exist and be written by
+   SimpleCov 1.x. Record its path, size in bytes, and modification time (in
+   UTC) from the file system (e.g. `ls -l` or `stat`); this metadata is not
+   coverage data, so reading it is allowed.
+2. Run the project totals with the tracked globs from Step 2
+   (`project_coverage_totals` / `cov-loupe -m cli -fJ -g '<globs>' totals`)
+   and the file list with the same globs (`project_coverage` /
+   `cov-loupe -m cli -fJ -g '<globs>' list`). `timestamp_status` must be `ok`,
+   and `newer_files`, `deleted_files`, `length_mismatch_files`,
+   `unreadable_files`, and `skipped_files` must all be empty. These show
+   whether source files changed after the run.
+3. No test, fixture, or configuration file may be newer than the coverage
+   file, since cov-loupe checks only source files. For example:
+   `find spec test features Gemfile.lock .rspec .simplecov -newer coverage/coverage.json`
+   (adjusted to the paths that exist). Include directories in the search,
+   not just files, so that deleted test files show up too.
+4. If the project records test results, they must show no failures: for
+   RSpec, the file named by `example_status_persistence_file_path`
+   (commonly `.rspec_status`) must have no `failed` entries.
+
+These checks cannot prove that the last run was the complete suite. Say in
+the report that the analysis relies on the user's assurance that it was.
+
+`missing_tracked_files` (tracked files the suite never loaded) is not a
+staleness failure; it is a finding for Step 2.
+
+## Step 2: Establish the project baseline
+
+1. Get overall totals with no globs, then with tracked globs matching the
+   code SimpleCov is meant to measure (from its `track_files` and filter
+   settings; typically `lib/**/*.rb`, or `app/**/*.rb,lib/**/*.rb` for Rails).
+   Passing `tracked_globs` makes cov-loupe report tracked files that have
+   **no** coverage data at all (`missing_tracked_files`, `without_coverage`);
+   these are files never loaded by the suite and are often the biggest real
+   gap.
+2. Get the full file list as JSON, sorted ascending (worst first).
+3. Note what the numbers cover: cov-loupe reports **line** coverage only.
+   If SimpleCov also collects branch coverage, say that branch coverage is out
+   of scope for this report.
+
+## Step 3: Identify the logical areas
+
+Before computing any rollups, decide how to carve up the code. The goal is the
+most precise, targeted analysis, so draw boundaries by what the code does, not
+by where it lives. File and directory boundaries are not area boundaries: one
+file may hold a class or module with a critical mission next to code that
+matters little, and those belong in different areas. This takes more reading
+and more tokens than a file-level rollup; that is the point.
+
+1. Read the code to understand its structure: entry points, `require` and
+   autoload structure, namespaces, classes, modules, and methods, and how
+   responsibilities flow between them. Identify the kind of project (Rails
+   app, gem, CLI tool, service) and its conventions.
+2. Define **logical areas at whatever granularity is meaningful**. An area is
+   a set of code units (classes, modules, methods, or line ranges) wherever
+   they live. It can be:
+   - a broad grouping spanning several directories (e.g. "everything in the
+     checkout flow", "the public API"),
+   - a single namespace or class,
+   - a single method or a few methods within a class (e.g. the price
+     calculation inside an order model, or the argument parsing in a CLI
+     command),
+   - or a cross-cutting concern spanning many places (e.g. authorization,
+     error handling, input validation).
+3. Arrange the areas in a hierarchy where that helps (a broad area containing
+   narrower ones), and nest as deep as it is useful. Cross-cutting areas may
+   overlap others; say so where they do.
+4. Record each area's definition precisely as file paths with line ranges, and
+   name the classes, modules, or methods those ranges cover so a reader can
+   follow them. When an area is made of whole files, a glob is a fine
+   shorthand.
+5. Make sure at least one level of the hierarchy is a **complete partition**:
+   every coverable line in the source files under analysis belongs to exactly
+   one area at that level, with an explicit "Other" area for code that fits
+   nowhere. This level is what the totals are reconciled against.
+6. Give each area a **criticality** judgment with a short reason. Treat it as a
+   continuum, not a fixed set of buckets: place each area relative to the
+   others and explain what drives the placement. Weigh user-visible behavior,
+   data correctness and integrity, money and security (authentication,
+   authorization, code evaluation, file system access), error paths, public
+   API, and how often the code runs. Use the framework's usual danger spots as
+   prompts, not as fixed categories: in a Rails app, validations, callbacks,
+   and scopes that guard data; authorization in controllers; background-job
+   retries and failure handling; mailers; CSRF and parameter filtering. In
+   other projects, look at domain rules and calculations, state transitions,
+   external API clients, file I/O and parsing, serialization, and concurrency.
+
+## Step 4: Compute coverage per area
+
+1. For each file touched by an area, get per-line data with
+   `file_coverage_detailed` / `cov-loupe -m cli -fJ detailed <path>`. Each row
+   gives a line number, its hit count, and whether it is covered; lines that
+   are not coverable (comments, blank lines, `end`) do not appear.
+2. For each area, sum the covered and coverable lines that fall in its line
+   ranges, and compute the percentage. Also record the number of code units
+   in the area and its weakest units (e.g. the least-covered methods).
+3. Get a broader area's numbers by summing its children's line counts, never
+   by averaging child percentages.
+4. For an area made of whole files, cross-check your sums against
+   `project_coverage_totals` with `tracked_globs` /
+   `cov-loupe -m cli -fJ -g '<globs>' totals`; they must match exactly.
+5. Confirm that the line totals for the partition level from Step 3 add up to
+   the project's covered and total lines for the same overall globs. If they
+   don't, find the overlap or orphaned lines and fix the map; state any
+   remaining discrepancy.
+6. Keep the aggregation mechanical and reproducible. If you write a helper
+   script to sum the per-line rows, put it in a temporary directory of your
+   own outside the project (e.g. from `mktemp -d`, so concurrent agents don't
+   collide), feed it cov-loupe output only, and include it in the appendix.
+
+## Step 5: Examine the gaps
+
+Decide for yourself which files and areas deserve a close look. Do not apply a
+fixed percentage cutoff: weigh each area's coverage against its criticality,
+so a critical area at a high percentage can still warrant scrutiny while a
+low-stakes area at a lower percentage may not. Always include every tracked
+file with no coverage data. State the reasoning behind your selection in the
+report.
+
+For each selected file or area:
+
+1. Get the uncovered lines (`file_uncovered_lines` /
+   `cov-loupe -m cli -fJ uncovered <path>`); use `file_coverage_detailed` or
+   `cov-loupe -m cli -s uncovered -n 2 uncovered <path>` to see the source in
+   context.
+2. Characterize each cluster of uncovered lines: error/rescue path, edge-case
+   branch, defensive guard, platform-specific code, dead code, debug/logging
+   code, or core logic.
+3. Find the tests for that code, following the project's conventions (e.g.
+   `spec/` mirroring `lib/` or `app/`, or `test/`). Note whether the gap is
+   "no tests at all", "tests exist but miss these paths", or "covered only
+   indirectly by integration tests".
+4. Judge the **risk** of each gap: what goes wrong for a user if this code is
+   broken and no test notices? Be concrete.
+5. Judge, separately from risk, how **hard the gap is to test**: dependencies
+   to set up, I/O, external services, time, concurrency, or missing seams
+   (code that can't be exercised without refactoring).
+6. Flag likely dead code separately: it should be deleted, not tested.
+
+Do not pad the report: a high percentage with an untested critical error path
+is worth more attention than modest coverage of formatting helpers.
+
+## Step 6: Look beyond line percentages
+
+Briefly assess, per major area, using the tests themselves:
+
+- Whether coverage comes from focused unit tests or only from broad
+  integration/end-to-end tests (high coverage via integration alone can hide
+  weak assertions).
+- Whether tests assert on behavior or merely execute code (spot-check a few
+  tests per area; cite them).
+- Consistency across entry points: behavior reachable through more than one
+  interface (e.g. web UI and API, CLI and library) should be tested through
+  each.
+- Testing anti-patterns. Report only those you actually observe, such as:
+  over-mocking that makes tests brittle or hides integration bugs;
+  near-duplicate test code that should use shared examples, helpers, or
+  iteration over input arrays; untested error handling and failure
+  scenarios; missing integration tests for critical user flows; untested
+  authorization logic; controller tests where request specs would serve
+  better (Rails); missing tests for jobs, mailers, external integrations,
+  CLI argument parsing, or data transformation pipelines.
+- Testing infrastructure problems: inadequate fixtures or factories, missing
+  helpers, or code structure that makes tests hard to write.
+- Well-tested areas: where coverage and test quality are both strong, and
+  the testing patterns there that are worth repeating elsewhere.
+
+Keep this qualitative and evidence-based; cite test files and line numbers.
+
+## Report
+
+Write your analysis in the project root (or in the directory the invocation
+names) as a Markdown file whose name is:
+- today's date in UTC `%Y-%m-%d-%H-%M` format +
+- '-test-coverage-analysis-' +
+- your name (e.g. 'codex', 'claude', 'gemini') +
+- the `.md` extension.
+
+If a file with that name already exists (another agent finished in the same
+minute), append `-2`, `-3`, and so on before the extension. Never overwrite an
+existing report.
+
+The file should have the following structure:
+
+---
+
+### Executive Summary
+- Commit cited, cov-loupe interface used (MCP or CLI), and the results of the
+  Step 1 checks.
+- The coverage file's path (relative to the project root), size, and
+  modification time (UTC), so readers can tell which test run the report
+  describes.
+- Overall line coverage (with and without tracked globs).
+- The best- and worst-covered areas, and the top risk areas.
+- A **one-line verdict** (e.g. *"Strong domain coverage; payment error
+  handling is the main gap"*).
+
+### Area Map
+The hierarchy of logical areas from Step 3, showing for each area its parent,
+its definition (file paths with line ranges and the code units they cover, or
+globs for whole files), and criticality with reason. Mark the partition level
+used for reconciliation and any overlapping cross-cutting areas. Explain why
+you carved the code this way.
+
+### Coverage by Area
+One table per hierarchy level that is worth showing, each sorted ascending by
+percentage:
+
+| Area | Criticality | Code units | Covered | Total | % | Weakest unit (%) |
+|------|-------------|------------|---------|-------|---|------------------|
+
+List tracked files with no coverage data separately, with the areas they
+belong to.
+
+Follow with a short interpretation of each area that stands out, positively or
+negatively, relative to its criticality.
+
+### Gap Analysis
+State how you chose what to examine. Then, for each gap from Step 5, grouped by
+area and ordered by risk:
+- File and uncovered line numbers (as reported by cov-loupe).
+- What the code does and the gap's category.
+- Test status (none / partial / indirect only).
+- Risk, with a concrete failure scenario.
+- Difficulty to test, with what makes it hard.
+- Recommendation: test to add (describe the scenario, not the code), code to
+  delete, or "acceptable as is" with the reason.
+
+### Well-Tested Areas
+Areas where coverage and test quality are both strong, and the patterns
+worth repeating, with citations.
+
+### Test Quality Observations
+The remaining findings from Step 6 (unit vs. integration balance, assertion
+strength, entry-point consistency, anti-patterns, infrastructure), with
+citations.
+
+### Data Caveats
+Reliance on the user's assurance that the last run was the complete, passing
+suite; tracked files missing from the coverage data; branch coverage being out
+of scope; ambiguous line assignments at area boundaries; anything else that
+limits confidence in the numbers.
+
+### Prioritized Recommendations
+A table of tasks, sorted by priority (highest first):
+
+| # | Task | Area | Importance (1–10) | Effort (S/M/L) | Priority | Expected improvement |
+|---|------|------|-------------------|----------------|----------|----------------------|
+
+- **Task**: one concrete action (tests to add, code to delete, or an
+  infrastructure fix).
+- **Importance**: the risk the task removes, from the area's criticality and
+  the gap's risk.
+- **Effort**: from the gap's difficulty to test (Step 5).
+- **Priority**: rank by importance relative to effort. Among tasks of similar
+  importance, put the cheaper one first: quick wins are easy to clear, and each
+  one cleared drops out of the next report, so later reports concentrate on
+  what remains. Place infrastructure fixes ahead of the tasks they unblock.
+
+Briefly state the rule you used to combine importance and effort. After the
+table, give each task a ready-to-use prompt the user can give an AI assistant
+to implement it, keyed by its number.
+
+### Appendix: Commands Run
+Every cov-loupe call (MCP tool name and arguments, or CLI command) and
+freshness check used to produce the numbers, plus any aggregation script, so the
+report can be reproduced.
+
+---
+
+End your final message with the report's path and the one-line verdict, or,
+if you stopped early, with the error. A headless caller can then find the
+outcome without parsing the rest of your output.

data/exe/agent-council

@@ -0,0 +1,12 @@
+#!/usr/bin/env ruby
+# frozen_string_literal: true
+
+# agent-council — executable entry point. All code lives in lib/:
+#   lib/agent_council.rb                       orchestration (AgentCouncil)
+#   lib/agent_council/harnesses/pi_harness.rb  pi-specific behavior (AgentCouncil::Harnesses::PiHarness)
+#
+# Usage, options, and AGENT_COUNCIL_OPTS: agent-council -h, and the README.
+
+require_relative '../lib/agent_council'
+
+AgentCouncil.main(ARGV)

data/exe/pi-models

@@ -0,0 +1,39 @@
+#!/usr/bin/env ruby
+# frozen_string_literal: true
+
+require_relative '../lib/agent_council/platform'
+
+AgentCouncil.abort_if_native_windows('pi-models')
+
+require_relative '../lib/agent_council/pi_models'
+
+help_output = ARGV.delete('-h') || ARGV.delete('--help')
+json_output = ARGV.delete('--json') || ARGV.delete('-j')
+ids_output = ARGV.delete('--ids') || ARGV.delete('-i')
+ARGV.delete('--table') || ARGV.delete('-t') # table is the default format; accepted for explicitness
+
+if help_output
+  puts AgentCouncil::PiModels.help_text
+  exit
+end
+
+unless ARGV.empty?
+  warn "pi-models: unknown option(s): #{ARGV.join(' ')}"
+  warn "Try 'pi-models --help' for usage."
+  exit 1
+end
+
+begin
+  models = AgentCouncil::PiModels.fetch_models
+rescue AgentCouncil::PiModels::Error => e
+  warn "pi-models: #{e.message}"
+  exit 1
+end
+
+if json_output
+  puts AgentCouncil::PiModels.format_as_json(models)
+elsif ids_output
+  print AgentCouncil::PiModels.format_as_ids(models)
+else
+  puts AgentCouncil::PiModels.format_as_table(models)
+end

data/lib/agent_council/harnesses/pi_harness.rb

@@ -0,0 +1,169 @@
+# frozen_string_literal: true
+
+# AgentCouncil::Harnesses::PiHarness — all knowledge specific to the pi
+# coding-agent harness: how to invoke the pi CLI for one model run, the
+# tool allowlist, and read-only scaffolding delivered with it, and how to
+# read pi's JSONL event stream afterward.
+#
+# AgentCouncil is harness-agnostic and refers to this module only via
+# AgentCouncil::HARNESS. A second harness (claude, codex, ...) would be
+# another module under AgentCouncil::Harnesses shaped like this one —
+# this is deliberately a plain namespace, not an adapter framework.
+
+require 'json'
+
+module AgentCouncil
+  module Harnesses
+    module PiHarness
+      NAME = 'pi'
+
+      # Analysis toolset (pi's built-in tool names): edit/write (and the
+      # Windows-only powershell) are withheld. bash, a full shell, stays for
+      # investigation (git log/status, dependency inspection, ...); only the
+      # scaffolding text asks the model to use it read-only.
+      TOOLS = 'read,grep,find,ls,bash'
+
+      # Invocation for one model run. The substantive prompt is not part of argv;
+      # it is piped to stdin (byte-identical for every analyst; the
+      # consolidator gets its own).
+      module_function def argv(provider, model, scratch_dir)
+        [
+          NAME,
+          '-p',               # non-interactive: process prompt and exit
+          '--mode', 'json',   # JSONL event stream on stdout
+          '--no-session',     # ephemeral: no session state between runs
+          '--tools', TOOLS,
+          '--provider', provider,
+          '--model', model,
+          '--append-system-prompt', scaffold_text(scratch_dir)
+        ]
+      end
+
+      # Scaffolding appended to pi's system prompt. Identical for every agent
+      # except the scratch dir path.
+      module_function def scaffold_text(scratch_dir)
+        <<~TEXT
+          You are one of the independent agents agent-council runs on this
+          repository. This is a strictly read-only analysis task.
+
+          Rules:
+          - Do not modify, create, rename, or delete any project source or
+            configuration file. Do not change git state, install or remove
+            software, modify user or system configuration, or start persistent
+            services.
+          - Do not run test suites, builds, coverage tools, application servers,
+            or database tasks unless the user's prompt explicitly permits it:
+            other agents may be running concurrently and such commands can collide
+            through shared state (databases, ports, Docker, fixed temp paths).
+            Where the prompt permits them, direct their temporary output to the
+            scratch directory below, and still skip any that need shared
+            services (databases, servers, fixed ports, Docker). Otherwise, if
+            running such a command would materially improve your analysis,
+            describe what you would run and why instead of running it.
+          - You may run clearly read-only commands: reading, searching, and
+            listing files; inspecting git history and status; inspecting
+            dependency and configuration information.
+          - If you need scratch space for temporary artifacts, use this
+            disposable directory that is unique to your run: #{scratch_dir}
+          - Deliver your complete analysis as your final message text. Do not
+            write the report to a file; the orchestrator captures your final
+            message directly.
+        TEXT
+      end
+
+      # --- event stream reading ---
+
+      # The assistant message from a single pi JSONL line, or nil if the line
+      # is not an assistant message_end event.
+      module_function def assistant_message_from_line(line)
+        event =
+          begin
+            JSON.parse(line)
+          rescue JSON::ParserError
+            nil
+          end
+
+        return nil unless event.is_a?(Hash)
+        return nil unless event['type'] == 'message_end'
+
+        message = event['message']
+        return nil unless message && message['role'] == 'assistant'
+
+        message
+      end
+
+      # Assistant messages from all message_end events in a pi JSONL stream,
+      # in order. Unparseable lines are skipped.
+      module_function def assistant_messages(jsonl)
+        jsonl.each_line.filter_map { |line| assistant_message_from_line(line) }
+      end
+
+      module_function def response_text(message)
+        Array(message['content'])
+          .select { |block| block['type'] == 'text' }
+          .map { |block| block['text'] }
+          .join("\n")
+      end
+
+      # The final assistant response: per pi's docs, message_end holds the
+      # authoritative final message of each turn; the last assistant message_end
+      # with actual text is the report (earlier ones belong to tool-use turns).
+      module_function def final_response(jsonl)
+        message = saved_message(assistant_messages(jsonl))
+        message && response_text(message)
+      end
+
+      # The message final_response saves: the last one with text.
+      module_function def saved_message(messages)
+        messages.reverse_each.detect { |m| !response_text(m).empty? }
+      end
+
+      # Our usage keys, each mapped to pi's name for it. pi normalizes usage
+      # across providers; its input excludes cache reads and writes.
+      USAGE_KEYS = { 'input' => 'input', 'output' => 'output',
+                     'cache_read' => 'cacheRead', 'cache_write' => 'cacheWrite' }.freeze
+
+      # Token usage summed over all assistant messages (each is a separate
+      # model request), as AgentCouncil expects it: integer 'input', 'output',
+      # 'cache_read', and 'cache_write', plus 'cost' in US dollars when pi
+      # priced the run. nil when the stream reports no usage, as some
+      # providers don't.
+      module_function def usage(jsonl)
+        usages = assistant_messages(jsonl).map { |m| m['usage'] }.grep(Hash)
+        totals = USAGE_KEYS.transform_values { |key| usages.sum { |u| count(u[key]) } }
+        return nil if totals.values.all?(&:zero?)
+
+        cost = usages.sum { |u| u['cost'].is_a?(Hash) ? count(u['cost']['total']) : 0 }
+        cost.positive? ? totals.merge('cost' => cost.round(6)) : totals
+      end
+
+      module_function def count(value)
+        value.is_a?(Numeric) && value.positive? ? value : 0
+      end
+
+      # Stop reasons meaning a message was cut off, cancelled, or failed, not
+      # completed. error normally comes with an errorMessage, which is reported
+      # instead; this catches one that is missing or blank.
+      UNUSABLE_STOP_REASONS = %w[length aborted error].freeze
+
+      # Why the run produced no usable report, or nil. Pi exits 0 even when the
+      # provider rejects the request or the output hits its token limit, so this
+      # is how such failures are surfaced. Two messages are checked: the final
+      # one (an error in an earlier turn that a later turn recovered from is not
+      # a failure, while an error on the last turn means any earlier text is a
+      # partial fragment) and the one final_response would save (a cut-off
+      # message must not be saved just because a text-less message followed it).
+      # A non-blank string errorMessage on either wins over a cut-off stopReason on
+      # the other, since it says more about what went wrong.
+      module_function def error_message(jsonl)
+        messages = assistant_messages(jsonl)
+        candidates = [messages.last, saved_message(messages)].compact.uniq
+        message = candidates.detect { |m| m['errorMessage'].is_a?(String) && !m['errorMessage'].strip.empty? }
+        return message['errorMessage'] if message
+
+        message = candidates.detect { |m| UNUSABLE_STOP_REASONS.include?(m['stopReason']) }
+        message && "stopped early (stopReason: #{message['stopReason']})"
+      end
+    end
+  end
+end