@open-code-review/agents 1.4.0 → 1.5.1

package/README.md

@@ -2,6 +2,8 @@
 
 The skill definitions, reviewer personas, and workflow references that power Open Code Review.
 
+> Browse review output and map artifacts in the [Dashboard](../dashboard/README.md) or through your AI assistant's slash commands.
+
 ## What This Package Contains
 
 ```
@@ -24,6 +26,7 @@ agents/
 │       └── reviewer-template.md
 ├── commands/                # Slash command definitions
 │   ├── review.md
+│   ├── map.md
 │   ├── doctor.md
 │   ├── history.md
 │   ├── show.md
@@ -33,6 +36,17 @@ agents/
     └── plugin.json
 ```
 
+## Prerequisites
+
+All OCR workflows require the CLI for session state management. Before running any review or map command, ensure the CLI is installed:
+
+```bash
+npm install -g @open-code-review/cli
+ocr init
+```
+
+The CLI provides the `ocr state` commands that track workflow progress through each phase. Without it, reviews will fail at phase transitions.
+
 ## Installation
 
 ### Via CLI (Recommended)
@@ -70,13 +84,24 @@ The `SKILL.md` file defines the **Tech Lead** role—the orchestrator that:
 
 Each reviewer in `references/reviewers/` is a specialized persona. You can customize the built-in reviewers or add your own.
 
+### Map Agent Personas
+
+The `/ocr:map` command uses a separate set of specialized agents defined in `references/map-personas/`:
+
+| Persona | Role |
+|---------|------|
+| **Map Architect** | Analyzes change topology, determines optimal section groupings and review ordering |
+| **Flow Analyst** | Traces upstream/downstream dependencies, groups related changes by data and control flow |
+| **Requirements Mapper** | Maps changes to requirements/specs when provided, identifies coverage gaps |
+
+These agents run with configurable redundancy (default: 2) to increase confidence in groupings. See `.ocr/config.yaml` → `code-review-map.agents` for tuning.
+
 ## Session Structure
 
 OCR uses a **round-first architecture** for session storage:
 
 ```
 .ocr/sessions/{YYYY-MM-DD}-{branch}/
-├── state.json              # Workflow state (current_round, phase)
 ├── discovered-standards.md # Project context (shared across rounds)
 ├── context.md              # Change analysis (shared)
 └── rounds/
@@ -86,10 +111,18 @@ OCR uses a **round-first architecture** for session storage:
     │   └── final.md        # Synthesized review
     └── round-2/            # Created on re-review
         └── ...
+├── maps/
+│   ├── run-1/
+│   │   ├── map.md             # Code Review Map output
+│   │   └── flow-analysis.md   # Dependency graph (Mermaid)
+│   └── run-2/                 # Created on re-map
+│       └── ...
 ```
 
 **Multi-round reviews**: Running `/ocr-review` again on an existing session creates a new round (`round-2/`, `round-3/`, etc.) if the previous round is complete. This enables iterative "review → fix → re-review" workflows while preserving history.
 
+**Map runs**: Running `/ocr-map` creates map artifacts in `maps/run-{n}/`. Like review rounds, subsequent runs create new directories without modifying previous ones.
+
 See `references/session-files.md` for the complete file manifest.
 
 ## Commands
@@ -97,6 +130,7 @@ See `references/session-files.md` for the complete file manifest.
 | File | Windsurf | Claude Code / Cursor |
 |------|----------|----------------------|
 | `review.md` | `/ocr-review` | `/ocr:review` |
+| `map.md` | `/ocr-map` | `/ocr:map` |
 | `doctor.md` | `/ocr-doctor` | `/ocr:doctor` |
 | `reviewers.md` | `/ocr-reviewers` | `/ocr:reviewers` |
 | `history.md` | `/ocr-history` | `/ocr:history` |

package/commands/address.md

@@ -0,0 +1,117 @@
+---
+description: Address code review feedback — corroborate, validate, and implement changes from a review's final.md.
+name: "OCR: Address Feedback"
+category: Code Review
+tags: [ocr, address, feedback, review]
+---
+
+**Usage**
+```
+/ocr-address [path-to-final.md]
+```
+
+**Arguments**
+- `path-to-final.md` (optional): Explicit path to a `final.md` review document. If omitted, auto-detects the current session's latest round `final.md`.
+
+**Examples**
+```
+/ocr-address                                                         # Auto-detect current session's latest final.md
+/ocr-address .ocr/sessions/2026-03-06-feat-auth/rounds/round-1/final.md  # Explicit path
+```
+
+**Guardrails**
+
+- You are a distinguished software engineer with deep understanding of software architecture and design patterns.
+- Think step by step — favor composition, clear boundaries, minimal scope, and root-cause fixes.
+- Verify every assumption by reading actual code; never guess at behavior.
+- Do NOT blindly accept every piece of feedback. Use your expertise to corroborate each point against the actual implementation before acting.
+- If feedback is incorrect or based on a misunderstanding of the code, say so clearly with evidence.
+- If feedback is valid but the suggested fix is suboptimal, propose a better alternative.
+- Direct cutover rewrites only — remove all deprecated/dead/unused code; leave nothing behind.
+
+---
+
+## Steps
+
+### 1. Resolve Inputs
+
+Determine the `final.md` to address:
+
+1. If the user provided an explicit file path, use it directly.
+2. If no path is provided, auto-detect the current session:
+   ```bash
+   ocr state show
+   ```
+   Parse the output to find the session directory and current round, then construct the path:
+   ```
+   .ocr/sessions/{session-id}/rounds/round-{N}/final.md
+   ```
+3. Read the `final.md` file in its entirety.
+4. If the file does not exist or cannot be found, stop and inform the user.
+
+Also read any available OCR session context for project awareness:
+- `.ocr/sessions/{session-id}/discovered-standards.md` — project standards
+- `.ocr/sessions/{session-id}/context.md` — change analysis and Tech Lead guidance
+
+### 2. Parse and Catalog Feedback Items
+
+Break the review into discrete, actionable feedback items.
+
+For each item, record:
+- The feedback point (what the reviewer is saying)
+- The file(s) and line(s) referenced (if any)
+- Severity/type: blocker, should-fix, suggestion, nitpick, architecture, performance, security, etc.
+- The originating reviewer persona (if identifiable)
+
+Present a concise numbered summary of all feedback items to the user before proceeding.
+
+### 3. Gather Implementation Context
+
+- Read ALL files referenced by the review feedback.
+- Read any additional files needed to understand the surrounding context (callers, consumers, types, tests).
+- Read project standards from `discovered-standards.md` if available.
+- **DO NOT skip any referenced files** — thorough context is critical for accurate corroboration.
+
+### 4. Corroborate and Validate Each Feedback Item
+
+For each feedback item from Step 2:
+
+- **Read the actual code** at the referenced location.
+- **Assess validity**: Is the feedback accurate? Does the code actually exhibit the issue described?
+- **Classify** each item as one of:
+  - **Valid — Will Address**: Feedback is correct and should be implemented.
+  - **Valid — Alternative Approach**: Feedback identifies a real issue but the suggested fix is suboptimal; propose a better solution.
+  - **Invalid — Respectfully Decline**: Feedback is based on a misunderstanding or is incorrect; explain why with code evidence.
+  - **Needs Clarification**: Feedback is ambiguous or requires more context to evaluate.
+
+Present the corroboration results as a summary table or list, then **immediately proceed** to Step 5. Do NOT wait for user acknowledgment — this workflow runs autonomously.
+
+### 5. Address Feedback
+
+For all items classified as **Valid — Will Address** or **Valid — Alternative Approach**:
+
+- **Spawn sub-agents in parallel** for independent feedback items. Group items that touch the same files or have logical dependencies, and assign independent groups to separate sub-agents.
+- Each sub-agent should:
+  - Implement changes following project coding standards and existing patterns
+  - Ensure every change is minimal, focused, and does not introduce regressions
+  - For **Alternative Approach** items, implement the better solution proposed in Step 4
+- After all sub-agents complete, review the combined changes for consistency and conflicts.
+
+### 6. Report and Verify
+
+**Report** a completion summary:
+- Total feedback items reviewed
+- Items addressed (with brief description of each change)
+- Items declined (with reasoning)
+- Items needing clarification (if any)
+
+**Verify** correctness by running project checks:
+```bash
+# Run type-checking (adapt to project toolchain)
+npx tsc --noEmit
+
+# Run tests (adapt to project toolchain)
+npm test
+```
+
+If verification fails, fix the issues before reporting completion.

package/commands/map.md

@@ -49,7 +49,7 @@ The map command is for **extremely large changesets** that would take multiple h
 
 ---
 
-## 🔍 Session State Check (Phase 0)
+## Session State Check (Phase 0)
 
 Before starting any map work, verify the current session state:
 
@@ -67,7 +67,13 @@ ls -la .ocr/sessions/$(date +%Y-%m-%d)-* 2>/dev/null
 ls -la .ocr/sessions/{id}/map/runs/ 2>/dev/null
 ```
 
-### Step 3: Determine action
+### Step 3: Check current state
+
+```bash
+ocr state show
+```
+
+### Step 4: Determine action
 
 - **If `--fresh` flag**: Delete the map directory and start from run-1
 - **If map exists and complete**: Start new run (run-{n+1})
@@ -76,7 +82,7 @@ ls -la .ocr/sessions/{id}/map/runs/ 2>/dev/null
 
 ---
 
-## ⚠️ CRITICAL: Required Artifacts (Must Create In Order)
+## CRITICAL: Required Artifacts (Must Create In Order)
 
 > **See `references/map-workflow.md` for the complete workflow.**
 
@@ -84,7 +90,6 @@ You MUST create these files sequentially:
 
 ```
 .ocr/sessions/{YYYY-MM-DD}-{branch}/
-├── state.json              # Session state (shared with review)
 ├── discovered-standards.md # Phase 1: merged project standards (shared)
 ├── requirements.md         # Phase 1: user requirements (if provided, shared)
 └── map/
@@ -96,6 +101,17 @@ You MUST create these files sequentially:
             └── map.md              # Phase 5: final map output
 ```
 
+State is managed via `ocr state` CLI commands (stored in SQLite at `.ocr/data/ocr.db`).
+
+### State Management Commands
+
+| Command | When to Use |
+|---------|-------------|
+| `ocr state init --session-id <id> --branch <branch> --workflow-type map --session-dir <path>` | Create a new session |
+| `ocr state transition --phase <phase> --phase-number <N> --current-map-run <N>` | Each phase boundary |
+| `ocr state show` | Check current session state |
+| `ocr state close` | Close the session (if ending) |
+
 ### Checkpoint Rules
 
 1. **Before Phase 2** (Topology): `discovered-standards.md` MUST exist

package/commands/post.md

@@ -7,11 +7,12 @@ tags: [ocr, github, pr]
 
 **Usage**
 ```
-/ocr-post [session]
+/ocr-post [session] [--human-translated-review <path>]
 ```
 
 **Arguments**
 - `session` (optional): Session ID to post. Defaults to most recent.
+- `--human-translated-review <path>` (optional): Explicit path to a human-translated review file to post instead of `final.md`.
 
 **Prerequisites**
 - GitHub CLI (`gh`) must be installed and authenticated
@@ -21,9 +22,19 @@ tags: [ocr, github, pr]
 
 1. Verify `gh` is available and authenticated
 2. Find the PR for current branch
-3. Determine current round from `state.json` → `current_round` (or enumerate `rounds/` directory)
-4. Read the session's `rounds/round-{current_round}/final.md`
+3. Determine current round from `ocr state show` -> `current_round` (or enumerate `rounds/` directory)
+4. **Select the review content to post** (in priority order):
+   a. If `--human-translated-review <path>` is provided, use that file
+   b. Otherwise, check if `rounds/round-{current_round}/final-human.md` exists -- if yes, prefer it
+   c. Fall back to `rounds/round-{current_round}/final.md`
 5. Post as PR comment via `gh pr comment`
 
+**Convention Over Configuration**
+
+When no `--human-translated-review` flag is given, the post command automatically checks for a human-translated review before falling back to the raw synthesized review. This means if you've run `/ocr-translate-review-to-single-human` beforehand, the translated version is picked up without any extra flags.
+
+The explicit `--human-translated-review` flag overrides this auto-detection and lets you point to any arbitrary file.
+
 **Reference**
+- Run `/ocr-translate-review-to-single-human` to generate a human-voice translation before posting
 - Run `/ocr-doctor` to check GitHub CLI status

package/commands/review.md

@@ -32,7 +32,7 @@ tags: [ocr, review, code-review]
 
 ---
 
-## 🔍 Session State Check (Phase 0)
+## Session State Check (Phase 0)
 
 Before starting any review work, you MUST verify the current session state:
 
@@ -45,7 +45,11 @@ ls -la .ocr/sessions/$(date +%Y-%m-%d)-* 2>/dev/null
 
 ### Step 2: If session exists, verify state
 
-Read `state.json` AND verify actual files match (see `references/session-files.md` for authoritative names):
+Use `ocr state show` to read current session state AND verify actual files match (see `references/session-files.md` for authoritative names):
+
+```bash
+ocr state show
+```
 
 | Phase | Verify file exists |
 |-------|-------------------|
@@ -56,19 +60,20 @@ Read `state.json` AND verify actual files match (see `references/session-files.m
 | discourse | `.ocr/sessions/{id}/rounds/round-{n}/discourse.md` |
 | synthesis | `.ocr/sessions/{id}/rounds/round-{n}/final.md` |
 
-> **Note**: Phase completion is derived from filesystem (file existence), not from `state.json`. The `current_phase` field indicates which phase is active.
+> **Note**: Phase completion is derived from filesystem (file existence), not from session state. The `current_phase` field indicates which phase is active.
 
 ### Step 3: Determine action
 
 - **If `--fresh` flag**: Delete the session directory and start from Phase 1
-- **If state.json missing but files exist**: Recreate state.json from file existence
-- **If state.json exists and files match**: Resume from `current_phase`
-- **If state.json and files mismatch**: Report discrepancy and ask user which to trust
+- **If session exists and status is `closed`**: Start new round (round-{n+1}) — reuse existing `discovered-standards.md` and `context.md`, create new `rounds/round-{n+1}/` directory
+- **If session exists, status is `active`, and files match**: Resume from `current_phase`
+- **If session exists but state and files mismatch**: Report discrepancy and ask user which to trust
+- **If no state in SQLite but session files exist**: Start new round — use `ocr state init` to recreate the session, then start round-{n+1} from Phase 4 (reuse existing standards and context)
 - **If no session exists**: Start fresh from Phase 1
 
 ---
 
-## ⚠️ CRITICAL: Required Artifacts (Must Create In Order)
+## CRITICAL: Required Artifacts (Must Create In Order)
 
 > **See `references/session-files.md` for the authoritative file manifest.**
 
@@ -76,8 +81,7 @@ You MUST create these files sequentially. **Do NOT skip to `final.md`.**
 
 ```
 .ocr/sessions/{YYYY-MM-DD}-{branch}/
-├── state.json              # Phase 1: session state (REQUIRED)
-├── discovered-standards.md # Phase 1: merged project standards  
+├── discovered-standards.md # Phase 1: merged project standards
 ├── requirements.md         # Phase 1: user requirements (if provided)
 ├── context.md              # Phase 2+3: change summary + Tech Lead guidance
 └── rounds/
@@ -91,6 +95,17 @@ You MUST create these files sequentially. **Do NOT skip to `final.md`.**
         └── final.md            # Phase 7: ONLY after all above exist
 ```
 
+State is managed via `ocr state` CLI commands (stored in SQLite at `.ocr/data/ocr.db`).
+
+### State Management Commands
+
+| Command | When to Use |
+|---------|-------------|
+| `ocr state init --session-id <id> --branch <branch> --workflow-type review --session-dir <path>` | Phase 1: Create the session |
+| `ocr state transition --phase <phase> --phase-number <N> [--current-round <N>]` | Each phase boundary |
+| `ocr state show` | Check current session state |
+| `ocr state close` | Phase 8: Close the session |
+
 ### Checkpoint Rules
 
 1. **Before Phase 2** (Change Analysis): `discovered-standards.md` MUST exist
@@ -101,7 +116,7 @@ You MUST create these files sequentially. **Do NOT skip to `final.md`.**
 
 ### Why This Matters
 
-The `ocr progress` CLI watches these files to show real-time progress. If you skip files, the progress display breaks and users see incorrect state.
+The `ocr progress` CLI reads session state from SQLite for real-time progress display. If you skip phases or don't call `ocr state transition`, the progress display breaks and users see incorrect state.
 
 ---
 

package/commands/show.md

@@ -16,7 +16,7 @@ tags: [ocr, history, sessions]
 **Steps**
 
 1. If no session specified, find most recent in `.ocr/sessions/`
-2. Determine current round from `state.json` → `current_round` (or enumerate `rounds/` directory)
+2. Determine current round from `ocr state show` → `current_round` (or enumerate `rounds/` directory)
 3. Read and display `rounds/round-{current_round}/final.md` (synthesized review)
 4. Optionally show individual reviewer files from `rounds/round-{n}/reviews/` if requested
 

package/commands/translate-review-to-single-human.md

@@ -0,0 +1,116 @@
+---
+description: Translate a multi-reviewer code review into a single human-voice GitHub PR comment.
+name: "OCR: Translate Review to Single Human"
+category: Code Review
+tags: [ocr, post, github, human-voice]
+---
+
+**Usage**
+```
+/ocr-translate-review-to-single-human [session] [--round <N>]
+```
+
+**Arguments**
+- `session` (optional): Session ID to translate. Defaults to most recent.
+- `--round <N>` (optional): Round number to translate. Defaults to current round.
+
+**Examples**
+```
+/ocr-translate-review-to-single-human                        # Translate latest round of latest session
+/ocr-translate-review-to-single-human --round 2              # Translate round 2
+/ocr-translate-review-to-single-human 2026-03-06-feat-auth   # Translate specific session
+```
+
+**Prerequisites**
+- A completed review round with `final.md` and reviewer outputs in `reviews/*.md`
+
+---
+
+## Steps
+
+1. **Locate the session and round**
+   - If no session specified, find the most recent in `.ocr/sessions/`
+   - Determine the round number from `ocr state show` -> `current_round`, or use `--round` if provided
+   - Verify the round directory exists: `.ocr/sessions/{id}/rounds/round-{N}/`
+
+2. **Read the source material**
+   - Read `rounds/round-{N}/final.md` for the synthesized review
+   - Read ALL individual reviewer outputs in `rounds/round-{N}/reviews/*.md` for raw findings
+
+3. **Apply the human voice translation** following the rules below
+
+4. **Write the output** to `rounds/round-{N}/final-human.md` in the same round directory
+
+---
+
+## Translation Rules
+
+You are rewriting a multi-reviewer code review into a single PR comment that reads like one real person wrote it after carefully reading through the code. Not an AI. Not a committee. Just a developer who spent time on this and has opinions.
+
+### Voice & Tone (Google code review guidelines)
+
+- Comment on the CODE, never the developer. "This function could be simplified" not "you wrote this wrong."
+- Always explain WHY something matters. Don't just say "change this" -- say why it's worth changing.
+- Label severity naturally: prefix minor stuff with "Nit:" or "Minor:", flag blockers clearly.
+- When something is good, say so briefly. Don't over-praise, but acknowledge solid work where you see it.
+- Be direct. "This needs a bounds check" is better than "It might be worth considering whether bounds checking could potentially be beneficial."
+
+### Writing Style -- Sound Like a Human
+
+Your writing must be indistinguishable from a real person's PR review. Follow these rules:
+
+**Sentence variety**: Mix short punchy sentences with longer ones. Start some with "So", "Also", "Oh and", "One thing --". Real people don't start every sentence the same way.
+
+**Word choice**: Pick unexpected but natural words. Say "this is a bit gnarly" not "this is complex". Say "nice catch" not "good observation". Say "I'd probably" not "I would recommend".
+
+**Banned words and phrases** (these are AI tells -- NEVER use them):
+- "comprehensive", "robust", "leverage", "utilize", "furthermore", "additionally"
+- "ensure", "facilitate", "streamline", "encompass", "delve"
+- "it's worth noting", "it should be noted", "upon review"
+
+**Structure disruption**: Don't use the classic AI pattern of intro paragraph -> numbered list -> conclusion. Instead, jump right into the review. Maybe start with the most interesting finding, or a quick overall impression. Let the structure feel organic -- group related things but don't over-organize.
+
+**Natural imperfections**: Real reviews have personality. Use dashes for asides -- like this -- and parenthetical thoughts (when they fit). An occasional "tbh" or "fwiw" is fine. Contractions are mandatory ("don't", "isn't", "I'd").
+
+**Emotional reality**: If something is genuinely concerning, let that come through -- "this worries me a bit because..." If something is clever, say so -- "oh this is a neat approach." If something is tedious but necessary, acknowledge it -- "I know this is annoying but we really need..."
+
+### Severity Labels
+
+Every technical finding must include a severity label:
+
+| Label | Meaning |
+|-------|---------|
+| **Blocker** | Must fix before merge. Bugs, data loss risks, security issues. |
+| **Should-fix** | Strongly recommended. Not a ship-blocker but will cause pain later. |
+| **Suggestion** | Take it or leave it. A better approach exists but current code works. |
+| **Nit** | Style, naming, minor readability. Prefix with "Nit:" naturally in the text. |
+
+### Content Rules (NON-NEGOTIABLE)
+
+- Preserve EVERY substantive technical finding from the source material. Do not drop, skip, or summarize away any concrete issue.
+- Include specific file paths and line numbers exactly as referenced in the source material.
+- Consolidate duplicates -- if two reviewers flagged the same thing, mention it once.
+- Strip all meta-commentary about "the review process" or "analysis methodology."
+- Use GitHub-flavored markdown.
+
+### Absolute Don'ts
+
+- Never mention multiple reviewers, AI, agents, automated analysis, or tools.
+- Never use "the team", "our analysis", "upon review", "it was noted that".
+- Never write a formulaic sign-off or summary conclusion paragraph.
+- Never start with "Overall, this is a..." -- that's the number one AI tell.
+- Never mention this translation process or that you're rewriting anything.
+
+---
+
+## Output Format
+
+Write ONLY the review comment in GitHub-flavored markdown. Jump straight into the review -- no meta-preamble, no explanation of what you're doing, no wrapper text.
+
+The output goes directly into `final-human.md` and will be posted as-is to a GitHub PR.
+
+---
+
+**Reference**
+- Use `/ocr-post` to post the translated review to GitHub
+- Use `/ocr-show` to view the original synthesized review

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@open-code-review/agents",
-  "version": "1.4.0",
+  "version": "1.5.1",
   "description": "AI-native skills, commands, and reviewer personas for Open Code Review",
   "type": "module",
   "files": [

package/skills/ocr/SKILL.md

@@ -141,7 +141,6 @@ All review artifacts are stored in `.ocr/sessions/{YYYY-MM-DD}-{branch}/`:
 
 | File | Description |
 |------|-------------|
-| `state.json` | Session state for progress tracking |
 | `discovered-standards.md` | Merged project context (shared) |
 | `requirements.md` | User-provided requirements (shared, if any) |
 | `context.md` | Change summary and Tech Lead guidance (shared) |

package/skills/ocr/assets/ocr-gitignore

@@ -1,12 +1,6 @@
-# OCR Session Directory .gitignore
-# Copy this to .ocr/.gitignore to exclude review sessions from git
-
-# Exclude all session data by default
+# OCR:START — managed by open-code-review (do not edit this block)
 sessions/
-
-# Or selectively include/exclude:
-# sessions/*
-# !sessions/important-review/
-
-# Keep the directory structure
-!.gitignore
+data/
+*.db-shm
+*.db-wal
+# OCR:END

package/skills/ocr/references/map-template.md

@@ -143,6 +143,17 @@ Template for the final map output (`map.md`). Optimized for reviewer workflow: u
 
 ---
 
+## Section Dependencies
+
+> How sections connect. Used by the dashboard dependency graph.
+
+| From | To | Relationship |
+|------|-----|-------------|
+| 1: {Section Title} | 2: {Section Title} | {3-8 word description of dependency} |
+| 2: {Section Title} | 3: {Section Title} | {3-8 word description of dependency} |
+
+---
+
 ## File Index
 
 | File | Section |
@@ -200,6 +211,16 @@ Map suggestions to requirements or concerns. Do NOT perform code review — just
 **Good**: "Complex pricing conditionals — verify tier logic matches REQ-4"
 **Bad**: "This function has a bug on line 42" (that's code review)
 
+### Section Dependencies
+
+Populate from cross-file flows identified during flow analysis:
+
+- Use `{number}: {Title}` format matching section headings (e.g., `1: Authentication Flow`)
+- Direction follows call/data flow: caller section → callee section
+- Relationship is a 3-8 word description (e.g., "Auth middleware protects routes")
+- Only include meaningful cross-section dependencies — not every possible connection
+- If sections are independent, leave the table body empty (keep headers)
+
 ### Requirements Coverage Indicators
 
 - ✅ Full coverage