docs: add cross-repo dependency graph from the repo audit - #1689
docs: add cross-repo dependency graph from the repo audit#1689seonghobae wants to merge 4 commits into
Conversation
New file, not touching profile/README.md. Built from the per-repo Topics/Description audit run earlier in this session (each repo's own README/manifest/file tree, read directly via gh api) plus the existing architecture brief in CWL-MASTER-CONTEXT.md. Distinguishes dependencies confirmed by a dependent repo's own current README/manifest (solid arrows) from relationships CWL-MASTER-CONTEXT.md documents but this session's audit couldn't independently corroborate in the dependent repo's own docs (dashed arrows) — several "naruon plugin" and "contextual-orchestrator calibrates/routes" claims fall in the latter category, which is worth knowing before relying on them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Warning Review limit reachedNext included review available in 57 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough새 문서는 73개 활성 저장소의 교차 저장소 의존성 그래프를 정의합니다. 자체 README·매니페스트에서 확인한 관계와 아키텍처 문서에만 기록된 관계를 구분하고, 관계 표와 감사 한계를 추가합니다. Changes저장소 의존성 그래프
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: 🟡 Moderate · up to This documentation-only PR adds a dependency graph, but the current document labels several relationships inconsistently and cites the wrong side of some dependencies, which could mislead architectural or maintenance decisions; it also lists one repository twice, making the count ambiguous. Merge should wait for these bounded documentation corrections or explicit owner acceptance. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Companion to docs/repo-dependency-graph.md: a self-contained page (loads mermaid.js from cdnjs) rendering the same dependency diagram plus a snapshot of the three PRs this session's audit produced (#1679 closed, #1687 narrowed to the vooster-v2-mvp fix, #1689 this one, untouched). Point-in-time snapshot, timestamped, not live data. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… own README, fix pin descriptions Addresses review comments on PR #1689 (Devin + CodeRabbit): - Five "OIDC relying party" edges (naruon, pg-erd-cloud, semantic-data-portal, clearfolio, newsdom-api -> keyverse) were solid arrows sourced only from keyverse's own README claiming them as relying parties -- none of those five repos' own READMEs mention keyverse at all. Downgraded to dashed and moved to the "documented, not independently re-verified" table, consistent with the legend's own definition of what "solid" requires. Kept saju-caldav and contextual-orchestrator solid -- both independently confirmed in their own README. - Three edges (four-pillars/pg-llm-batch/RankWeave) were drawn dashed despite being listed as confirmed in the table -- fixed to solid, matching the legend. - LineageWeave's dependency on ThreadWeave and RankWeave was described identically as "real git-pinned" for both; re-checked pyproject.toml directly -- ThreadWeave is a PyPI version-range pin (threadweave>=0.1.0), only RankWeave is actually git-commit-pinned. Corrected both the diagram labels and the table. - Re-read LineageWeave's README section "How it fits with the rest of the ecosystem" and found three real, previously-missing edges: TEPP (consumed via its own wire contract, tepp_client.py), an optional LLM-adjudication call to contextual-orchestrator, and an optional git-pinned fast-mlsirm backend dependency for IRT calibration. Added all three with their own evidence. - nonnest2 was listed in both "Psychometrics & research" and "Forks" under the no-known-dependency section; kept it only under Forks (its more defining categorical fact) and noted why. - Standalone HTML page was missing </head> and <body> tags entirely (browsers silently recover; validators/tooling would not) -- added both, and regenerated the embedded diagram/PR-status panel to match the corrected .md content and current PR state. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Noema LLM review
The PR adds two documentation files describing cross-repo dependencies. The markdown file is well-structured and addresses prior review feedback. However, the HTML file has a confirmed security issue: the mermaid script is loaded from a CDN without a Subresource Integrity (SRI) attribute, allowing a compromised CDN to execute arbitrary JavaScript in the page's origin. This is a blocking security concern. Additionally, the HTML introduction states 'three PRs' while the panel lists four, an inconsistency that should be corrected.
Reviewed changed lines
docs/repo-dependency-graph.html:245 (RIGHT): The mermaid script is loaded from cdnjs without an integrity attribute. This is a confirmed security finding (Semgrep html.security.audit.missing-integrity.missing-integrity). A compromised CDN response could execute arbitrary JavaScript in the page's origin.docs/repo-dependency-graph.html:92 (RIGHT): The introduction text says 'three PRs' but the panel below lists four PR cards (#1687, #1689, #1692, #1729). This inconsistency makes the scope of the session snapshot unclear.docs/repo-dependency-graph.md:156 (RIGHT): Three solid edges (naruon→ThreadWeave, naruon→CalendarWeave, LineageWeave→CalendarWeave) cite only the dependency's README (ThreadWeave README, CalendarWeave README) rather than the dependent repo's own README/manifest, which the legend requires for solid arrows. This is an open review thread that remains unaddressed.
Adversarial validation
docs/repo-dependency-graph.html:245 (RIGHT)confirmed: The mermaid script tag lacks an SRI integrity attribute, allowing a compromised CDN to execute arbitrary JavaScript. — Line 245: <script src="https://cdnjs.cloudflare.com/ajax/libs/mermaid/10.9.1/mermaid.min.js"></script> — no integrity attribute present. Semgrep finding html.security.audit.missing-integrity.missing-integrity confirms this.docs/repo-dependency-graph.html:92 (RIGHT)confirmed: The introduction's 'three PRs' claim matches the number of PR cards in the panel. — Line 92: 'alongside the current state of the three PRs that came out of that work.' Lines 190-220 contain four pr-card divs.docs/repo-dependency-graph.md:156 (RIGHT)confirmed: All solid edges in the confirmed table cite evidence from the dependent repo's own README/manifest, as required by the legend. — Lines 154-156: '|naruon|ThreadWeave| ... | ThreadWeave README ("importable standalone by naruon or any other host") |', '|naruon|CalendarWeave| consumes fail-closed | CalendarWeave README |', '|LineageWeave|CalendarWeave| consumes fail-closed | CalendarWeave README |'. The legend at lines 17-19 requires 'the dependent repo's own README, manifest, or file tree names the target repo directly.'- Residual risk: The HTML file executes third-party JavaScript without integrity verification, creating a supply-chain attack vector. The markdown file has evidence-tier inconsistencies that undermine the document's stated methodology.
Findings
- [high] docs/repo-dependency-graph.html:245 (RIGHT): Missing Subresource Integrity (SRI) attribute on the mermaid CDN script. A compromised CDN response can execute arbitrary JavaScript in the page's origin. Add an integrity attribute with the correct hash for mermaid 10.9.1.
- [medium] docs/repo-dependency-graph.html:92 (RIGHT): Inconsistent PR count: the introduction says 'three PRs' but the panel lists four (#1687, #1689, #1692, #1729). Update the text to 'four PRs' or clarify which three are in scope.
- [medium] docs/repo-dependency-graph.md:156 (RIGHT): Three solid edges (naruon→ThreadWeave, naruon→CalendarWeave, LineageWeave→CalendarWeave) cite only the dependency's README, not the dependent repo's own README/manifest as the legend requires. Either reclassify these edges as dashed or provide dependent-side evidence.
- Result: REQUEST_CHANGES
- Head SHA:
2dce37bb29e93cb1938bef71d3540f72683b6f5f - Reviewer credential:
noema-review-github-app-refresh - Actor:
cwl-noema-review[bot]
…ence edges Fixes the failing "Semgrep (multi-language SAST)" required check (html.security.audit.missing-integrity): the mermaid CDN script tag had no subresource-integrity attribute, so a compromised cdnjs response could execute arbitrary JS in the page's origin. The sha384 was computed from the exact pinned file (mermaid 10.9.1) and cross-checked against cdnjs's own published sha512 for the same bytes; a browser load confirms the script still executes and the diagram still renders under the constraint. Also applies the outstanding evidence-tier finding. Three solid edges cited only the *target's* README, which the doc's own legend forbids for solid arrows. Re-checked each against the dependent's own sources and demoted them: - naruon -> ThreadWeave: naruon's README, backend/pyproject.toml and requirements.txt carry no threadweave; repo-wide code search returns 0 hits. - naruon -> CalendarWeave: no mention in naruon's README; code search 0 hits. - LineageWeave -> CalendarWeave: LineageWeave's own docs/adr/0183 does name CalendarWeave, but records the wiring as "a later consume-only slice" that currently fail-closes unwired -- planned, not shipped. The legend and the dashed-section intro now say a dashed arrow may also rest on the target's own README, which is what the five already-demoted OIDC rows were resting on too. Corrects the HTML lede's "three PRs" against the four PR cards the panel actually renders. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Summary
New file:
docs/repo-dependency-graph.md. Does not touchprofile/README.md— kept deliberately separate from #1679/#1687.Built from the per-repo Topics/Description audit run earlier in this session (a workflow that read each of the 73 active repos' own README, manifest, and file tree directly via
gh api) plus the existing "Inter-component architecture" brief inCWL-MASTER-CONTEXT.md.The graph distinguishes two confidence tiers, drawn as different arrow styles:
keyverse's README lists its OIDC relying parties;Orgmetra's repo tree has literalkeyverse-adapter/naruon-adapterpackages;LineageWeave'spyproject.tomlpinsThreadWeave/RankWeave).CWL-MASTER-CONTEXT.md's architecture brief, but this session's audit did not find independent confirmation in the dependent repo's own current README (e.g. several "naruon plugin" and "contextual-orchestrator calibrates/routes" claims). This isn't a claim they're wrong — early-stage repos often haven't caught up to the architecture doc yet — but it's useful to know which relationships rest on the architecture brief alone versus on the repo's own documentation.Also includes an evidence table for every edge, and a grouped list of the ~46 repos with no known cross-repo dependency (standalone products, forks, private employer-scoped assets, bare scaffolds).
Test plan
tests/for anything enumeratingdocs/or asserting file lists — none found that would be affected by adding a new file🤖 Generated with Claude Code
Summary by CodeRabbit