ralphflow 0.5.2 → 0.5.3

package/src/templates/code-review/ralphflow.yaml

@@ -0,0 +1,98 @@
+name: code-review
+description: "Collect → Spec Review → Quality Review → Fix pipeline for multi-stage code review"
+version: 1
+dir: .ralph-flow
+
+entities:
+  CHANGESET:
+    prefix: CS
+    data_file: 00-collect-loop/changesets.md
+  ISSUE:
+    prefix: ISSUE
+    data_file: 02-quality-review-loop/issues.md
+
+loops:
+  collect-loop:
+    order: 0
+    name: "Collect Loop"
+    prompt: 00-collect-loop/prompt.md
+    tracker: 00-collect-loop/tracker.md
+    data_files:
+      - 00-collect-loop/changesets.md
+    entities: [CHANGESET]
+    stages: [discover, catalog]
+    completion: "ALL CHANGESETS COLLECTED"
+    feeds: [spec-review-loop]
+    multi_agent: false
+    model: claude-sonnet-4-6
+    cadence: 0
+
+  spec-review-loop:
+    order: 1
+    name: "Spec Review Loop"
+    prompt: 01-spec-review-loop/prompt.md
+    tracker: 01-spec-review-loop/tracker.md
+    entities: [CHANGESET]
+    stages: [review, verdict]
+    completion: "ALL SPEC REVIEWS COMPLETE"
+    fed_by: [collect-loop]
+    feeds: [quality-review-loop]
+    model: claude-sonnet-4-6
+    multi_agent:
+      enabled: true
+      max_agents: 3
+      strategy: tracker-lock
+      agent_placeholder: "{{AGENT_NAME}}"
+    lock:
+      file: 01-spec-review-loop/.tracker-lock
+      type: echo
+      stale_seconds: 60
+    cadence: 0
+
+  quality-review-loop:
+    order: 2
+    name: "Quality Review Loop"
+    prompt: 02-quality-review-loop/prompt.md
+    tracker: 02-quality-review-loop/tracker.md
+    data_files:
+      - 02-quality-review-loop/issues.md
+    entities: [ISSUE, CHANGESET]
+    stages: [review, categorize]
+    completion: "ALL QUALITY REVIEWS COMPLETE"
+    fed_by: [spec-review-loop]
+    feeds: [fix-loop]
+    model: claude-sonnet-4-6
+    multi_agent:
+      enabled: true
+      max_agents: 3
+      strategy: tracker-lock
+      agent_placeholder: "{{AGENT_NAME}}"
+    lock:
+      file: 02-quality-review-loop/.tracker-lock
+      type: echo
+      stale_seconds: 60
+    cadence: 0
+
+  fix-loop:
+    order: 3
+    name: "Fix Loop"
+    prompt: 03-fix-loop/prompt.md
+    tracker: 03-fix-loop/tracker.md
+    entities: [ISSUE, CHANGESET]
+    stages: [fix, re-review]
+    completion: "ALL ISSUES RESOLVED"
+    fed_by: [quality-review-loop]
+    model: claude-sonnet-4-6
+    multi_agent:
+      enabled: true
+      max_agents: 3
+      strategy: tracker-lock
+      agent_placeholder: "{{AGENT_NAME}}"
+    lock:
+      file: 03-fix-loop/.tracker-lock
+      type: echo
+      stale_seconds: 60
+    worktree:
+      strategy: shared
+      auto_merge: true
+    cadence: 0

package/src/templates/design-review/loops/00-explore-loop/ideas.md

@@ -0,0 +1,3 @@
+# Ideas
+
+<!-- Populated by the Explore Loop -->

package/src/templates/design-review/loops/00-explore-loop/prompt.md

@@ -0,0 +1,207 @@
+# Explore Loop — Discover and Scope Ideas Before Design
+
+**App:** `{{APP_NAME}}` — all flow files live under `.ralph-flow/{{APP_NAME}}/`.
+
+Read `.ralph-flow/{{APP_NAME}}/00-explore-loop/tracker.md` FIRST to determine where you are.
+
+> **Design-first thinking starts with understanding.** Before any design or code, explore what exists, clarify what the user wants, and define sharp boundaries. Ambiguity killed here saves days of rework later.
+
+> **READ-ONLY FOR SOURCE CODE.** Only write to: `.ralph-flow/{{APP_NAME}}/00-explore-loop/tracker.md`, `.ralph-flow/{{APP_NAME}}/00-explore-loop/ideas.md`.
+
+**Pipeline:** `ideas.md → YOU → designs.md → 01-design-loop → design specs`
+
+---
+
+## Visual Communication Protocol
+
+When communicating scope, structure, relationships, or status, render **ASCII diagrams** using Unicode box-drawing characters. These help the user see the full picture at the terminal without scrolling through prose.
+
+**Character set:** `┌ ─ ┐ │ └ ┘ ├ ┤ ┬ ┴ ┼ ═ ● ○ ▼ ▶`
+
+**Diagram types to use:**
+
+- **Scope/Architecture Map** — components and their relationships in a bordered grid
+- **Decomposition Tree** — hierarchical breakdown with `├──` and `└──` branches
+- **Data Flow** — arrows (`──→`) showing how information moves between components
+- **Comparison Table** — bordered table for trade-offs and design options
+- **Status Summary** — bordered box with completion indicators (`✓` done, `◌` pending)
+
+**Rules:** Keep diagrams under 20 lines and under 70 characters wide. Populate with real data from current context. Render inside fenced code blocks. Use diagrams to supplement, not replace, prose.
+
+---
+
+## State Machine (3 stages per idea)
+
+**FIRST — Check completion.** Read the tracker. If the Ideas Queue has entries
+AND every entry is `[x]` (no pending ideas):
+1. **Re-scan `ideas.md`** — read all `## IDEA-{N}:` headers and compare
+   against the Ideas Queue in the tracker.
+2. **New ideas found** (in `ideas.md` but not in the queue) → add them as
+   `- [ ] IDEA-{N}: {title}` to the Ideas Queue, update the Dependency Graph
+   from their `**Depends on:**` tags, then proceed to process the lowest-numbered
+   ready idea via the normal state machine.
+3. **No new ideas** → go to **"No Ideas? Collect Them"** to ask the user.
+
+Only write `<promise>ALL IDEAS SCOPED</promise>` when the user explicitly
+confirms they have no more ideas to add AND `ideas.md` has no ideas
+missing from the tracker queue.
+
+Pick the lowest-numbered `ready` idea. NEVER process a `blocked` idea.
+
+---
+
+## No Ideas? Collect Them
+
+**Triggers when:**
+- `ideas.md` has no ideas at all (first run, empty queue with no entries), OR
+- All ideas in the queue are completed (`[x]`), no `pending` ideas remain, AND
+  `ideas.md` has been re-scanned and contains no ideas missing from the queue
+
+**Flow:**
+1. Tell the user: *"No pending ideas. Tell me what you want to build — describe features, problems, or goals in your own words."*
+2. Use `AskUserQuestion` to prompt: "What do you want to build or change?" (open-ended)
+3. As the user narrates, capture each distinct concept as a `## IDEA-{N}: {Title}` in `ideas.md` (continue numbering from existing ideas) with a brief description and `**Depends on:** None` (or dependencies if mentioned)
+4. **Confirm ideas & dependencies** — present all captured ideas back. Use `AskUserQuestion` (up to 3 questions) to validate: correct ideas? right dependency order? any to split/merge?
+5. Apply corrections, finalize `ideas.md`, add new entries to tracker queue, proceed to normal flow
+
+---
+
+```
+CONTEXT → Explore project state, read docs, understand what exists → stage: clarify
+CLARIFY → Ask questions one at a time, nail down intent and constraints → stage: scope
+SCOPE   → Define boundaries, write structured IDEA entry, mark done    → kill
+```
+
+## First-Run / New Idea Detection
+
+If Ideas Queue in tracker is empty OR all entries are `[x]`: read `ideas.md`,
+scan `## IDEA-{N}:` headers + `**Depends on:**` tags. For any idea NOT already
+in the queue, add as `- [ ] IDEA-{N}: {title}` and build/update the Dependency Graph.
+If new ideas were added, proceed to process them. If the queue is still empty
+after scanning, go to **"No Ideas? Collect Them"**.
+
+---
+
+## STAGE 1: CONTEXT
+
+1. Read tracker → pick lowest-numbered `ready` idea
+2. Read the idea from `ideas.md` (if it exists — on first run it may be empty)
+3. **Explore the project state:**
+   - Read `CLAUDE.md` for project context, architecture, conventions, stack
+   - Read **15+ key files** across the project: configs, entry points, core modules, recent changes
+   - Check recent git commits (`git log --oneline -20`) to understand momentum and active areas
+   - Identify existing patterns, conventions, and architectural decisions
+4. **Render a Project State Map** — output an ASCII architecture diagram showing:
+   - Current project structure (major components and modules)
+   - Active areas of development (`●` = stable, `○` = recently changed)
+   - Where this idea might touch the codebase
+5. Update tracker: `active_idea: IDEA-{N}`, `stage: clarify`, log entry
+
+## STAGE 2: CLARIFY
+
+> **One question at a time, multiple choice preferred.** Reduce cognitive load on the user. Do not dump a wall of questions — guide the conversation.
+
+1. Formulate questions about purpose, constraints, success criteria, and scope
+2. **Present understanding first** — render an ASCII scope diagram showing your current understanding of the idea. Give the user a visual anchor before asking questions.
+3. **Ask up to 20 questions, 5 at a time** via `AskUserQuestion`:
+   - **Round 1 — Purpose & Intent:**
+     - What problem does this solve? Who benefits?
+     - What does success look like? (measurable criteria)
+     - Are there existing solutions or workarounds?
+   - **Round 2 — Constraints & Boundaries:**
+     - What must NOT change? (protected areas, APIs, contracts)
+     - Performance, security, or compatibility requirements?
+     - Timeline or effort constraints?
+   - **Round 3 — Scope & Priority:**
+     - What is the smallest useful version? (MVP thinking)
+     - What can be deferred to a follow-up?
+     - Dependencies on other work?
+   - **Round 4+ — Clarification:** Based on prior answers, dig deeper
+   - **Stop early** if the idea is clear enough
+   - For multi-option decisions: numbered list with one-line descriptions
+   - For trade-offs: include a comparison table
+4. **Flag scope concerns:** If the idea seems too large for a single design cycle, suggest splitting it. Present a decomposition tree showing how it could break down.
+5. Save Q&A summary in tracker log
+6. Update tracker: `stage: scope`, log entry with key decisions
+
+## STAGE 3: SCOPE
+
+1. Synthesize all context and clarification into a structured IDEA entry
+2. **Render a Scope Boundary Diagram** — ASCII diagram showing:
+   - In-scope items (`✓`) vs. out-of-scope items (`✗`)
+   - Dependencies on existing systems or components
+   - Data flow for the proposed change
+3. Write the IDEA entry to `ideas.md` (or update if skeleton exists) using the format below
+4. **Present the scoped idea to the user** — show the IDEA summary and ask for confirmation via `AskUserQuestion`: "Does this capture what you want? Anything to add, remove, or change?"
+5. Apply any corrections from the user
+6. Mark done in tracker: check off queue, completed mapping, `active_idea: none`, `stage: context`, update Dependency Graph, log
+7. Exit: `kill -INT $PPID`
+
+**IDEA entry format:**
+```markdown
+## IDEA-{N}: {Title}
+
+**Depends on:** {IDEA-{M} or "None"}
+**Status:** scoped
+
+### Description
+{2-4 sentences describing what this idea is about — the problem, the user need, the opportunity.}
+
+### Constraints
+{Bullet list of hard constraints: must not break X, must work with Y, performance budget, etc.}
+
+### Success Criteria
+- [ ] {Specific, measurable condition — at least 3}
+- [ ] {Observable outcome the user can verify}
+- [ ] {Edge case or failure mode that must be handled}
+
+### In Scope
+- {Concrete deliverable or behavior change}
+- {Another concrete deliverable}
+
+### Out of Scope
+- {Explicitly deferred item — with brief reason}
+- {Another deferred item}
+
+### Open Questions
+- {Any remaining ambiguity that the design loop should resolve}
+```
+
+---
+
+## Decision Reporting Protocol
+
+When you make a substantive decision a human reviewer would want to know about, report it to the dashboard:
+
+**When to report:**
+- Scope boundary decisions (what is in vs. out of scope for an idea)
+- Splitting or merging ideas (decomposition choices)
+- Interpretation of ambiguous user intent (how you resolved unclear descriptions)
+- Constraint identification (constraints you surfaced that the user did not mention)
+- Priority or ordering decisions (why one idea comes before another)
+
+**How to report:**
+```bash
+curl -s --connect-timeout 2 --max-time 5 -X POST "http://127.0.0.1:4242/api/decision?app=$RALPHFLOW_APP&loop=$RALPHFLOW_LOOP" -H 'Content-Type: application/json' -d '{"item":"IDEA-{N}","agent":"explore-loop","decision":"{one-line summary}","reasoning":"{why this choice}"}'
+```
+
+**Do NOT report** routine operations: picking the next idea, updating tracker, stage transitions. Only report substantive choices that affect the scoped idea.
+
+**Best-effort only:** If the dashboard is unreachable (curl fails), continue working normally. Decision reporting must never block or delay your work.
+
+---
+
+## Rules
+
+- One idea at a time. All 3 stages run in one iteration, one `kill` at the end.
+- Read tracker first, update tracker last.
+- Append to `ideas.md` — never overwrite. Numbers globally unique and sequential.
+- Ideas must be self-contained — the design loop should not need to re-ask the user basic intent questions.
+- Flag ideas that are too large — suggest splitting before scoping.
+- **One question at a time, multiple choice preferred.** Reduce cognitive load.
+- Always present your understanding visually before asking questions.
+- Capture explicit out-of-scope items — these prevent scope creep downstream.
+
+---
+
+Read `.ralph-flow/{{APP_NAME}}/00-explore-loop/tracker.md` now and begin.

package/src/templates/design-review/loops/00-explore-loop/tracker.md

@@ -0,0 +1,16 @@
+# Explore Loop — Tracker
+
+- active_idea: none
+- stage: context
+- completed_ideas: []
+- pending_ideas: []
+
+---
+
+## Ideas Queue
+
+## Dependency Graph
+
+## Completed Mapping
+
+## Log

package/src/templates/design-review/loops/01-design-loop/designs.md

@@ -0,0 +1,3 @@
+# Designs
+
+<!-- Populated by the Design Loop -->

package/src/templates/design-review/loops/01-design-loop/prompt.md

@@ -0,0 +1,201 @@
+# Design Loop — Produce Design Specs from Scoped Ideas
+
+**App:** `{{APP_NAME}}` — all flow files live under `.ralph-flow/{{APP_NAME}}/`.
+
+Read `.ralph-flow/{{APP_NAME}}/01-design-loop/tracker.md` FIRST to determine where you are.
+
+> **Design for isolation and clarity — smaller units with one clear purpose, well-defined interfaces.** Every component should be replaceable without rippling through the system. Prefer boring, proven patterns over clever abstractions.
+
+> **READ-ONLY FOR SOURCE CODE.** Only write to: `.ralph-flow/{{APP_NAME}}/01-design-loop/tracker.md`, `.ralph-flow/{{APP_NAME}}/01-design-loop/designs.md`. Read `ideas.md` for input.
+
+**Pipeline:** `ideas.md → YOU → designs.md → 02-review-loop → reviewed specs`
+
+---
+
+## Visual Communication Protocol
+
+When communicating scope, structure, relationships, or status, render **ASCII diagrams** using Unicode box-drawing characters. These help the user see the full picture at the terminal without scrolling through prose.
+
+**Character set:** `┌ ─ ┐ │ └ ┘ ├ ┤ ┬ ┴ ┼ ═ ● ○ ▼ ▶`
+
+**Diagram types to use:**
+
+- **Scope/Architecture Map** — components and their relationships in a bordered grid
+- **Decomposition Tree** — hierarchical breakdown with `├──` and `└──` branches
+- **Data Flow** — arrows (`──→`) showing how information moves between components
+- **Comparison Table** — bordered table for trade-offs and design options
+- **Status Summary** — bordered box with completion indicators (`✓` done, `◌` pending)
+
+**Rules:** Keep diagrams under 20 lines and under 70 characters wide. Populate with real data from current context. Render inside fenced code blocks. Use diagrams to supplement, not replace, prose.
+
+---
+
+## State Machine (3 stages per design)
+
+**FIRST — Check completion.** Read the tracker. If the Designs Queue has entries
+AND every entry is `[x]` (no pending designs):
+1. **Re-scan `ideas.md`** — read all `## IDEA-{N}:` headers with `**Status:** scoped`
+   and compare against the Designs Queue in the tracker.
+2. **New scoped ideas found** (in `ideas.md` but not in the queue) → add them as
+   `- [ ] DESIGN-{N}: {title}` to the Designs Queue (DESIGN number matches IDEA number),
+   then proceed to process the lowest-numbered ready design.
+3. **No new scoped ideas** → write `<promise>ALL DESIGNS WRITTEN</promise>`.
+
+Pick the lowest-numbered `ready` design. NEVER process a `blocked` design.
+
+---
+
+```
+ALTERNATIVES → Propose 2-3 approaches with trade-offs, recommend one  → stage: design
+DESIGN       → Present design incrementally, get user approval         → stage: document
+DOCUMENT     → Write full design spec as DESIGN entry, mark done       → kill
+```
+
+## First-Run / New Design Detection
+
+If Designs Queue in tracker is empty OR all entries are `[x]`: read `ideas.md`,
+scan `## IDEA-{N}:` headers with `**Status:** scoped`. For any scoped idea NOT
+already in the queue, add as `- [ ] DESIGN-{N}: {title}` and build/update the
+Dependency Graph from `**Depends on:**` tags. If new designs were added, proceed.
+If the queue is still empty after scanning, write `<promise>ALL DESIGNS WRITTEN</promise>`.
+
+---
+
+## STAGE 1: ALTERNATIVES
+
+1. Read tracker → pick lowest-numbered `ready` design
+2. Read the corresponding IDEA from `00-explore-loop/ideas.md` — understand description, constraints, success criteria, in-scope/out-scope
+3. **Explore the codebase** — read `CLAUDE.md` and **20+ key files** across affected areas to understand current architecture, patterns, and constraints
+4. **Propose 2-3 alternative approaches** — for each approach:
+   - Name and one-line summary
+   - How it works (2-3 sentences)
+   - Key trade-offs: complexity, performance, maintainability, risk
+   - What it does well and where it falls short
+5. **Render an Alternatives Comparison Table** — ASCII bordered table:
+   ```
+   ┌──────────────┬────────────┬─────────┬──────────────┐
+   │ Approach      │ Complexity │ Risk    │ Maintenance  │
+   ├──────────────┼────────────┼─────────┼──────────────┤
+   │ A: {name}     │ Low        │ Low     │ Easy         │
+   │ B: {name}     │ Medium     │ Medium  │ Moderate     │
+   │ C: {name}     │ High       │ Low     │ Hard         │
+   └──────────────┴────────────┴─────────┴──────────────┘
+   ```
+6. **Recommend one approach** with clear reasoning — why it best fits the constraints and success criteria from the IDEA
+7. **Ask the user** via `AskUserQuestion`: present the comparison and recommendation, ask which approach to proceed with (or if they want a different direction)
+8. Record the chosen approach in tracker log
+9. Update tracker: `active_design: DESIGN-{N}`, `stage: design`, log entry
+
+## STAGE 2: DESIGN
+
+> **Present design incrementally. Get approval on each section before moving to the next.** Do not dump a complete design — walk the user through it piece by piece.
+
+1. Using the chosen approach from ALTERNATIVES, build the design section by section:
+2. **Architecture Overview** — render an ASCII architecture diagram showing major components, their responsibilities, and how they connect. Ask user: "Does this architecture make sense?"
+3. **Component Breakdown** — for each component:
+   - Name, responsibility (one sentence), inputs/outputs
+   - Key design decisions within this component
+   - Ask user after every 2-3 components: "Any concerns so far?"
+4. **Data Flow** — render an ASCII data flow diagram showing how information moves through the system. Cover happy path and key error paths.
+5. **Error Handling Strategy** — how errors propagate, where they are caught, what the user sees. Present as a bordered list.
+6. **Testing Approach** — what to test, how to test it, what coverage looks like. Unit vs. integration vs. e2e breakdown.
+7. **After each section**, ask the user via `AskUserQuestion` (multiple choice preferred):
+   - "Approve and continue to next section"
+   - "Revise this section (tell me what to change)"
+   - "Go back to alternatives (this approach is not working)"
+8. If the user wants to go back to alternatives, reset to ALTERNATIVES stage
+9. Update tracker: `stage: document`, log entry with design decisions
+
+## STAGE 3: DOCUMENT
+
+1. Compile all approved sections into a formal DESIGN entry
+2. Write the DESIGN entry to `01-design-loop/designs.md` using the format below
+3. **Render a Design Summary** — ASCII status diagram showing:
+   - All components with their status (`✓` designed)
+   - Data flow overview in compact form
+   - Success criteria mapping (which criteria each component addresses)
+4. Mark done in tracker: check off queue, completed mapping, `active_design: none`, `stage: alternatives`, update Dependency Graph, log
+5. Exit: `kill -INT $PPID`
+
+**DESIGN entry format:**
+```markdown
+## DESIGN-{N}: {Title}
+
+**Source:** IDEA-{N}
+**Depends on:** {DESIGN-{M} or "None"}
+**Approach:** {Name of chosen approach from alternatives}
+**Status:** drafted
+
+### Architecture Overview
+{2-3 paragraphs describing the high-level architecture. Reference the components below.}
+
+### Components
+
+#### {Component Name}
+- **Responsibility:** {One sentence}
+- **Inputs:** {What it receives}
+- **Outputs:** {What it produces}
+- **Key Decisions:** {Design choices made for this component}
+
+### Data Flow
+{Description of how data moves through the system. Reference components by name.}
+
+### Interfaces
+{Public APIs, function signatures, event contracts, or file formats that other components depend on. Be specific — these are the contracts.}
+
+### Error Handling
+{How errors propagate, where they are caught, recovery strategies, what the user sees.}
+
+### Testing Strategy
+- **Unit:** {What to unit test, key scenarios}
+- **Integration:** {What to integration test, component boundaries}
+- **E2E:** {End-to-end scenarios to verify}
+
+### File Structure Plan
+{Which files to create, modify, or delete. Group by component.}
+
+### Success Criteria Mapping
+{Map each success criterion from the IDEA to the component(s) that address it.}
+- [ ] {Criterion} → {Component(s)}
+```
+
+---
+
+## Decision Reporting Protocol
+
+When you make a substantive decision a human reviewer would want to know about, report it to the dashboard:
+
+**When to report:**
+- Approach selection (why one alternative was chosen over others)
+- Architecture decisions (component boundaries, data flow choices)
+- Trade-off resolutions (performance vs. simplicity, flexibility vs. complexity)
+- Scope adjustments during design (things that turned out harder or simpler than expected)
+- User feedback integration (how you incorporated user revisions into the design)
+
+**How to report:**
+```bash
+curl -s --connect-timeout 2 --max-time 5 -X POST "http://127.0.0.1:4242/api/decision?app=$RALPHFLOW_APP&loop=$RALPHFLOW_LOOP" -H 'Content-Type: application/json' -d '{"item":"DESIGN-{N}","agent":"design-loop","decision":"{one-line summary}","reasoning":"{why this choice}"}'
+```
+
+**Do NOT report** routine operations: picking the next design, updating tracker, stage transitions. Only report substantive choices that affect the design spec.
+
+**Best-effort only:** If the dashboard is unreachable (curl fails), continue working normally. Decision reporting must never block or delay your work.
+
+---
+
+## Rules
+
+- One design at a time. All 3 stages run in one iteration, one `kill` at the end.
+- Read tracker first, update tracker last.
+- Append to `designs.md` — never overwrite. DESIGN numbers match IDEA numbers.
+- **Design for isolation and clarity** — smaller units with one clear purpose, well-defined interfaces.
+- Present design incrementally — get approval on each section before proceeding.
+- Always propose alternatives before committing to an approach. Never jump to "the obvious solution."
+- If the user rejects the approach during DESIGN, go back to ALTERNATIVES gracefully.
+- Designs must be self-contained — the review loop should not need to read `ideas.md` to understand the spec.
+- Include concrete interfaces — these are the contracts that implementation will follow.
+- Map every success criterion to a component. If a criterion has no owner, the design is incomplete.
+
+---
+
+Read `.ralph-flow/{{APP_NAME}}/01-design-loop/tracker.md` now and begin.

package/src/templates/design-review/loops/01-design-loop/tracker.md

@@ -0,0 +1,16 @@
+# Design Loop — Tracker
+
+- active_design: none
+- stage: alternatives
+- completed_designs: []
+- pending_designs: []
+
+---
+
+## Designs Queue
+
+## Dependency Graph
+
+## Completed Mapping
+
+## Log