docs: add backlog item 84 — call-count annotations on sequence diagram arrows#401
docs: add backlog item 84 — call-count annotations on sequence diagram arrows#401carlos-alm merged 4 commits intomainfrom
Conversation
|
Claude finished @carlos-alm's task —— View job PR Review Complete ✅Todo List:
Analysis CompletePhase 1: Root Cause Analysis ✅Problem Being Solved: This PR addresses two separate issues:
Why This Approach: The husky hook changes add Risk Assessment: Low risk - the changes are defensive and improve reliability without weakening validation. Phase 2: Configuration Change Detection ✅The husky hook modifications are JUSTIFIED and IMPROVE robustness: .husky/commit-msg changes:
.husky/pre-push changes:
Assessment: These are defensive improvements, not rule relaxations. The hooks still perform their intended function but gracefully degrade when tools are unavailable. Phase 3: Test Integrity ✅No test-related changes detected. No red flags. Phase 4: Code Quality ✅BACKLOG.md changes:
Shell script improvements:
Final AssessmentRoot Cause AnalysisProblem Being Solved: (1) Documents a valid feature request for sequence diagram call-count annotations, (2) Improves husky hook reliability by adding error handling to prevent git command failures when codegraph CLI is unavailable Why This Approach: Documentation update is standard practice; shell script hardening with Risk Assessment: Very low risk - changes are purely defensive and additive Critical ConcernsNone. The husky hook changes are defensive improvements that prevent git operation failures without weakening validation logic. The backlog addition is legitimate documentation. Final Recommendation
|
|
Claude finished @carlos-alm's task —— View job PR Review Complete ✅Todo List:
Analysis CompletePhase 1: Root Cause Analysis ✅Problem Being Solved: This PR addresses two separate issues:
Why This Approach: The husky hook changes add Risk Assessment: Low risk - the changes are defensive and improve reliability without weakening validation. Phase 2: Configuration Change Detection ✅The husky hook modifications are JUSTIFIED and IMPROVE robustness: .husky/commit-msg changes:
.husky/pre-push changes:
Assessment: These are defensive improvements, not rule relaxations. The hooks still perform their intended function but gracefully degrade when tools are unavailable. Phase 3: Test Integrity ✅No test-related changes detected. No red flags. Phase 4: Code Quality ✅BACKLOG.md changes:
Shell script improvements:
Final AssessmentRoot Cause AnalysisProblem Being Solved: (1) Documents a valid feature request for sequence diagram call-count annotations, (2) Improves husky hook reliability by adding error handling to prevent git command failures when codegraph CLI is unavailable Why This Approach: Documentation update is standard practice; shell script hardening with Risk Assessment: Very low risk - changes are purely defensive and additive Critical ConcernsNone. The husky hook changes are defensive improvements that prevent git operation failures without weakening validation logic. The backlog addition is legitimate documentation. Final Recommendation
|
Greptile SummaryThis PR adds backlog item 84 (call-count annotations on
Confidence Score: 4/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["pre-push triggered"] --> B["Run codegraph diff-impact origin/main --json -T"]
B -- "exit 0 + output" --> D["IMPACT = JSON output"]
B -- "exit != 0" --> C["Run node src/cli.js diff-impact origin/main --json -T"]
C -- "exit 0 + output" --> D
C -- "exit != 0" --> E["|| true → IMPACT = empty string"]
E --> F{"[ -n IMPACT ]?"}
D --> F
F -- "false (empty)" --> Z["Skip — exit 0"]
F -- "true" --> G["Pipe IMPACT to node -e (parse JSON)\n2>/dev/null || true"]
G -- "node exits 0" --> H["AFFECTED = totalAffected or 0"]
G -- "node exits != 0" --> I["AFFECTED = empty string (|| true)"]
H --> J{"[ -n AFFECTED ] AND AFFECTED > 50?"}
I --> J
J -- "false" --> Z
J -- "true" --> K["echo Warning: pushing changes that affect N functions"]
K --> Z
|
| @@ -134,6 +135,7 @@ Six commands already produce Mermaid/DOT output: `export`, `diff-impact -f merma | |||
| | 68 | Symbol-level messages in `sequence` | Use 60's `edge_symbols` data to label sequence diagram messages with the specific exports being called between participants. | Visualization | Sequence diagrams show which symbols drive each file-to-file interaction | ✓ | ✓ | 3 | No | 60 | | |||
| | 69 | Node annotations in `diff-impact` / `branch-compare` / `communities` | Use 61's annotation formatter to show top exports on file nodes in `diff-impact -f mermaid`, `branch-compare --format mermaid`, and `communities` output. | Visualization | All visual tools show file API surfaces inline, not just in `export` | ✓ | ✓ | 3 | No | 61 | | |||
| | 70 | Drift/risk subgraph labels in `communities` and `triage` | Use 62's semantic label system to annotate `communities` subgraphs with drift status (`**(drifted)**` / `**(cohesive)**`) and add a new `--format mermaid` to `triage` with risk-severity group labels. | Intelligence | Community and triage diagrams communicate structural health directly in the layout | ✓ | ✓ | 3 | No | 62 | | |||
There was a problem hiding this comment.
Item 84 placed out of numeric order in Tier 1g
Item 84 is appended to Tier 1g after items 59–70, but items 71–83 live in Tier 1h/1i/later sections. While the item number is globally unique (assigned by creation order), readers scanning Tier 1g chronologically will notice a jump from 70 → 84 without explanation. Consider adding a short parenthetical next to the ID, e.g. 84 ✦ with a legend note, or simply a comment row like <!-- items 71–83 are in later tiers --> to clarify that the gap is intentional and not a missing entry.
b91fc6e to
3986e20
Compare
|
Claude finished @carlos-alm's task —— View job PR Review Complete ✅Todo List:
Analysis CompletePhase 1: Root Cause Analysis ✅Problem Being Solved: This PR adds backlog item 84 to document a future enhancement for sequence diagrams. The current Why This Approach: This is standard backlog management - documenting a concrete improvement to the sequence diagram visualization feature. The item is properly categorized in Tier 1g (Visualization leverage) and follows the established format. Risk Assessment: Zero risk - this is purely documentation of a future feature, no code changes. Phase 2: Configuration Change Detection ✅No configuration changes detected. Previous comments mentioned husky hook changes, but the current commit (HEAD: Phase 3: Test Integrity ✅No test-related changes detected. No red flags. Phase 4: Code Quality ✅BACKLOG.md changes:
Content Quality:
Final AssessmentRoot Cause AnalysisProblem Being Solved: Documents a legitimate enhancement to sequence diagram visualization - showing call counts when the same caller→callee pair appears multiple times instead of deduplicating with Why This Approach: Standard backlog documentation practice - captures the feature request in the proper tier and format for future implementation Risk Assessment: Zero risk - documentation-only change with no impact on functionality Critical ConcernsNone identified. This is a straightforward documentation addition following established patterns. Final Recommendation
|
|
Claude finished @carlos-alm's task —— View job PR Review Complete ✅Todo List:
Analysis CompletePhase 1: Root Cause Analysis ✅Problem Being Solved: This PR adds backlog item 84 to document a future enhancement for sequence diagrams. The current Why This Approach: This is standard backlog management - documenting a concrete improvement to the sequence diagram visualization feature. The item is properly categorized in Tier 1g (Visualization leverage) and follows the established format. Risk Assessment: Zero risk - this is purely documentation of a future feature, no code changes. Phase 2: Configuration Change Detection ✅No configuration changes detected. This PR only touches documentation in Phase 3: Test Integrity ✅No test-related changes detected. No red flags. Phase 4: Code Quality ✅BACKLOG.md changes:
Content Quality:
Final AssessmentRoot Cause AnalysisProblem Being Solved: Documents a legitimate enhancement to sequence diagram visualization - showing call counts when the same caller→callee pair appears multiple times instead of deduplicating with Why This Approach: Standard backlog documentation practice - captures the feature request in the proper tier and format for future implementation Risk Assessment: Zero risk - documentation-only change with no impact on functionality Critical ConcernsNone identified. This is a straightforward documentation addition following established patterns. Final Recommendation
|
|
Claude finished @carlos-alm's task —— View job PR Review Complete ✅Todo List:
Analysis CompletePhase 1: Root Cause Analysis ✅Problem Being Solved: This PR adds backlog item 84 to document a future enhancement for sequence diagrams. The current Why This Approach: This is standard backlog management - documenting a concrete improvement to the sequence diagram visualization feature. The item is properly categorized in Tier 1g (Visualization leverage) and follows the established format. Risk Assessment: Zero risk - this is purely documentation of a future feature, no code changes. Phase 2: Configuration Change Detection ✅No configuration changes detected. This PR only touches documentation in Phase 3: Test Integrity ✅No test-related changes detected. No red flags. Phase 4: Code Quality ✅BACKLOG.md changes:
Content Quality:
Final AssessmentRoot Cause AnalysisProblem Being Solved: Documents a legitimate enhancement to sequence diagram visualization - showing call counts when the same caller→callee pair appears multiple times instead of deduplicating with Why This Approach: Standard backlog documentation practice - captures the feature request in the proper tier and format for future implementation Risk Assessment: Zero risk - documentation-only change with no impact on functionality Critical ConcernsNone identified. This is a straightforward documentation addition following established patterns. Final Recommendation
|
Summary
sequencediagram arrows with call counts when the same caller→callee pair appears multiple times (CallerFile ->> CalleeFile: fnName (×3))Context:
findCalleescurrently usesSELECT DISTINCTto avoid duplicate arrows. Item 84 tracks the follow-up to restore that information as call-count labels instead.