feat(metrics): add epistemic entropy and memory decay indicators#22898
feat(metrics): add epistemic entropy and memory decay indicators#22898BrianCLong wants to merge 1 commit intomainfrom
Conversation
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 16 minutes and 56 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (12)
WalkthroughThis PR standardizes pnpm setup across 140+ GitHub Actions workflows by replacing pnpm action-based installation with corepack-based setup, adds Node 24 environment variable enforcement, updates caching strategies, and introduces metrics tracking for epistemic entropy and memory decay in the intelgraph system. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces metrics for epistemic entropy and memory decay, including calculation logic, unit tests, and telemetry logging across the intelgraph and strands-agents packages. It also adds a new API endpoint to expose these metrics via a MetricsAggregator. Feedback highlights that the aggregator is currently disconnected from the actual data producers, which will result in empty statistics. Additionally, there are recommendations to optimize the statistics calculation into a single pass, eliminate duplicated decay logic by using the shared utility, and replace console.log with a structured logging solution for production-ready telemetry.
| export const MetricsAggregator = { | ||
| entropyScores: [] as number[], | ||
| decayScores: [] as number[], | ||
|
|
||
| recordEntropy(score: number) { | ||
| this.entropyScores.push(score); | ||
| // Keep window bounded | ||
| if (this.entropyScores.length > 1000) this.entropyScores.shift(); | ||
| }, | ||
|
|
||
| recordDecay(score: number) { | ||
| this.decayScores.push(score); | ||
| if (this.decayScores.length > 1000) this.decayScores.shift(); | ||
| }, | ||
|
|
||
| getStats() { | ||
| const calcStats = (arr: number[]) => { | ||
| if (arr.length === 0) return { mean: 0, max: 0, bands: { low: 0, medium: 0, high: 0 }, criticalCount: 0 }; | ||
| const sum = arr.reduce((a, b) => a + b, 0); | ||
| const mean = sum / arr.length; | ||
| const max = Math.max(...arr); | ||
|
|
||
| let low = 0, medium = 0, high = 0; | ||
| let criticalCount = 0; | ||
| arr.forEach(s => { | ||
| if (s < 0.33) low++; | ||
| else if (s < 0.66) medium++; | ||
| else high++; | ||
|
|
||
| if (s > 0.8) criticalCount++; | ||
| }); | ||
| return { mean, max, bands: { low, medium, high }, criticalCount }; | ||
| }; | ||
|
|
||
| const entropyStats = calcStats(this.entropyScores); | ||
| const decayStats = calcStats(this.decayScores); | ||
|
|
||
| return { | ||
| epistemicEntropy: { | ||
| mean: entropyStats.mean, | ||
| max: entropyStats.max, | ||
| distributionBands: entropyStats.bands | ||
| }, | ||
| memoryDecay: { | ||
| averageDecayIndicator: decayStats.mean, | ||
| criticalDecayCount: decayStats.criticalCount | ||
| } | ||
| }; | ||
| } | ||
| }; |
There was a problem hiding this comment.
The MetricsAggregator is defined and exported here, but it is never populated by the metrics producers (upsertNode in NarrativeGraphStore or recall in graph-memory.ts). As a result, the /api/internal/metrics/entropy-decay endpoint will always return empty or zeroed statistics. You should implement a mechanism (e.g., an event emitter or a shared metrics utility) to bridge the gap between the library packages and the API's aggregator.
| const calcStats = (arr: number[]) => { | ||
| if (arr.length === 0) return { mean: 0, max: 0, bands: { low: 0, medium: 0, high: 0 }, criticalCount: 0 }; | ||
| const sum = arr.reduce((a, b) => a + b, 0); | ||
| const mean = sum / arr.length; | ||
| const max = Math.max(...arr); | ||
|
|
||
| let low = 0, medium = 0, high = 0; | ||
| let criticalCount = 0; | ||
| arr.forEach(s => { | ||
| if (s < 0.33) low++; | ||
| else if (s < 0.66) medium++; | ||
| else high++; | ||
|
|
||
| if (s > 0.8) criticalCount++; | ||
| }); | ||
| return { mean, max, bands: { low, medium, high }, criticalCount }; | ||
| }; |
There was a problem hiding this comment.
The calcStats function performs multiple passes over the metrics arrays. While the array size is currently capped at 1000, this can be optimized into a single pass for better efficiency, especially if the metrics endpoint is polled frequently.
| const calcStats = (arr: number[]) => { | |
| if (arr.length === 0) return { mean: 0, max: 0, bands: { low: 0, medium: 0, high: 0 }, criticalCount: 0 }; | |
| const sum = arr.reduce((a, b) => a + b, 0); | |
| const mean = sum / arr.length; | |
| const max = Math.max(...arr); | |
| let low = 0, medium = 0, high = 0; | |
| let criticalCount = 0; | |
| arr.forEach(s => { | |
| if (s < 0.33) low++; | |
| else if (s < 0.66) medium++; | |
| else high++; | |
| if (s > 0.8) criticalCount++; | |
| }); | |
| return { mean, max, bands: { low, medium, high }, criticalCount }; | |
| }; | |
| const calcStats = (arr: number[]) => { | |
| if (arr.length === 0) return { mean: 0, max: 0, bands: { low: 0, medium: 0, high: 0 }, criticalCount: 0 }; | |
| let sum = 0; | |
| let max = -Infinity; | |
| let low = 0, medium = 0, high = 0; | |
| let criticalCount = 0; | |
| for (const s of arr) { | |
| sum += s; | |
| if (s > max) max = s; | |
| if (s < 0.33) low++; | |
| else if (s < 0.66) medium++; | |
| else high++; | |
| if (s > 0.8) criticalCount++; | |
| } | |
| return { mean: sum / arr.length, max, bands: { low, medium, high }, criticalCount }; | |
| }; |
| function computeDecayIndicator(timestamp: string, accessCount: number = 0): number { | ||
| const ageInMs = Date.now() - new Date(timestamp).getTime(); | ||
| const ageInDays = ageInMs / (1000 * 60 * 60 * 24); | ||
| if (ageInDays <= 0) return 0; | ||
|
|
||
| const expectedAccesses = ageInDays; | ||
| if (accessCount >= expectedAccesses) return 0; | ||
| return 1 - (accessCount / expectedAccesses); | ||
| } |
There was a problem hiding this comment.
This logic for computing the decay indicator is duplicated from packages/intelgraph/graphrag/src/metrics/decay.ts. To ensure consistency and maintainability, you should import and use computeMemoryDecay from the graphrag package instead of redefining it here.
| async upsertNode(node: Node, beliefDistribution?: BeliefDistribution): Promise<void> { | ||
| if (beliefDistribution) { | ||
| node.epistemicEntropy = computeEpistemicEntropy(beliefDistribution); | ||
| console.log(`[METRIC] epistemic_entropy | node_id=${node.id} entropy_score=${node.epistemicEntropy}`); |
There was a problem hiding this comment.
Using console.log for metrics telemetry is generally discouraged in production environments. It's better to use a structured logger or a dedicated metrics client that can handle aggregation and reporting more reliably.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 20
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (33)
.github/workflows/hotfix-release.yml (1)
46-50:⚠️ Potential issue | 🔴 CriticalInvalid entry in
permissions:block —FORCE_JAVASCRIPT_ACTIONS_TO_NODE24is not a valid permission scope.The
permissions:block only accepts valid GitHub Actions permission scopes (e.g.,contents,packages,id-token). PlacingFORCE_JAVASCRIPT_ACTIONS_TO_NODE24: truehere is incorrect — it will either be silently ignored or cause workflow validation errors.The environment variable is already correctly set in the
env:block at line 53. Remove line 47.🐛 Proposed fix
permissions: - FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true contents: write packages: write id-token: write🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/hotfix-release.yml around lines 46 - 50, Remove the invalid permission entry by deleting the FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true line from the permissions: block (the permissions: section currently contains FORCE_JAVASCRIPT_ACTIONS_TO_NODE24, contents, packages, id-token); keep only valid scopes (e.g., contents, packages, id-token) and rely on the existing env: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 set later, ensuring the permissions block contains only supported GitHub Actions permission keys..github/workflows/self_flow_eval.yml (1)
19-31:⚠️ Potential issue | 🔴 CriticalUnresolved merge conflict markers will break this workflow.
This file contains unresolved merge conflict markers (
<<<<<<< HEAD,=======,>>>>>>> pr-21884) that will cause the YAML parser to fail. The workflow will not execute until this is resolved.Additionally, lines 29-30 (
with: version: 9.15.4) appear orphaned and syntactically incorrect after the conflict markers.🐛 Suggested resolution (choose one side)
If keeping the
fetch-depthandfetch-tagsoptions:- uses: actions/checkout@v4 -<<<<<<< HEAD with: fetch-depth: 0 fetch-tags: true - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 -======= - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 ->>>>>>> pr-21884 - with: - version: 9.15.4 - uses: actions/setup-node@v4🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/self_flow_eval.yml around lines 19 - 31, Remove the unresolved merge conflict markers (<<<<<<<, =======, >>>>>>>) and consolidate the duplicated "Setup pnpm" step so there is only one step with "run: corepack enable && corepack install --global pnpm@9.15.4"; also remove or reattach the orphaned "with: version: 9.15.4" so it is not floating — ensure that any "with:" block is correctly nested under the appropriate step (e.g., the actions/setup-node@v4 step) and that the YAML is syntactically valid after resolving the conflict..github/workflows/ci-affected.yml (1)
30-34:⚠️ Potential issue | 🟡 MinorUpdate pnpm setup to match codebase standard.
This workflow uses
pnpm/action-setup@v4withversion: 10.0.0at three locations (lines 31, 68, 94), while the codebase standard ispnpm@9.15.4. Some workflows have migrated to corepack-based setup (e.g.,mvp-ga-pilot-gate.yml,self_flow_eval.yml). For consistency, align this file with the predominant version used across active workflows.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-affected.yml around lines 30 - 34, Update the pnpm setup in this workflow to match the codebase standard by replacing the current pnpm/action-setup@v4 usage and version: 10.0.0 with the standard setup used elsewhere (use pnpm@9.15.4 or the corepack-based approach used in mvp-ga-pilot-gate.yml/self_flow_eval.yml); specifically, locate the pnpm/action-setup@v4 block(s) (e.g., the block containing run_install: false and version: 10.0.0) and change the configuration to the agreed project standard (pnpm@9.15.4) or convert to the corepack pattern so all three occurrences are consistent with active workflows..github/workflows/compliance.yml (2)
73-93:⚠️ Potential issue | 🔴 CriticalCritical: Additional unresolved merge conflicts in evidence-generation job.
The
evidence-generationjob has multiple unresolved merge conflicts and duplicate "Setup Node.js" steps. This also contains conflicting node-version values (24vs"24").🔧 Proposed fix
- name: Setup Node.js uses: actions/setup-node@v4 with: -<<<<<<< HEAD - node-version: 24 -======= node-version: "24" ->>>>>>> pr-21902 cache: "pnpm" cache-dependency-path: '**/pnpm-lock.yaml' - - - name: Setup Node.js - uses: actions/setup-node@v4 - with: -<<<<<<< HEAD - node-version: 24 -======= - node-version: "24" ->>>>>>> pr-21902 - cache: "pnpm" - cache-dependency-path: '**/pnpm-lock.yaml' - name: Setup Python🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/compliance.yml around lines 73 - 93, Resolve the unresolved merge markers and duplicate steps in the evidence-generation job by removing the conflict markers (<<<<<<<, =======, >>>>>>>) and keeping a single "Setup Node.js" step; ensure the step uses actions/setup-node@v4 with a consistent node-version value (use the string "24") and the existing cache and cache-dependency-path entries so only one clean, non-duplicated Setup Node.js block remains.
42-57:⚠️ Potential issue | 🔴 CriticalCritical: Unresolved Git merge conflict markers will break this workflow.
This file contains unresolved merge conflict markers (
<<<<<<< HEAD,=======,>>>>>>> pr-21884) that will cause YAML parsing failures. The workflow will not run until these are resolved.Additionally, there are:
- Duplicate "Setup pnpm" steps (lines 46-47, 49-50, 55-56)
- Orphaned
with:block at lines 52-53 that's not attached to any action🔧 Proposed fix (remove conflict markers and duplicates)
- uses: actions/checkout@v4 with: fetch-depth: 0 fetch-tags: true -<<<<<<< HEAD - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 -======= - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 ->>>>>>> pr-21884 - with: - version: 9.15.4 - - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 - name: Install dependencies run: pnpm install --frozen-lockfile --ignore-scripts🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/compliance.yml around lines 42 - 57, Remove the unresolved merge conflict markers (<<<<<<< HEAD, =======, >>>>>>> pr-21884), ensure only a single "Setup pnpm" step remains, and either attach the orphaned with: block (version: 9.15.4) to that single "Setup pnpm" action or remove the redundant with: lines; specifically, delete duplicate "Setup pnpm" steps and merge the intended with: version into the remaining run: corepack enable && corepack install --global pnpm@9.15.4 step so the workflow contains one correct pnpm setup without conflict markers..github/workflows/budget-guard.yml (1)
20-31:⚠️ Potential issue | 🔴 CriticalCritical: Unresolved Git merge conflict markers will break this workflow.
This file contains unresolved merge conflict markers that will cause YAML parsing failures. The orphaned
with: version: 9.15.4block at lines 30-31 is not attached to any action step.🔧 Proposed fix
steps: - uses: actions/checkout@v4 with: fetch-depth: 0 fetch-tags: true - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 - uses: actions/setup-node@v4 with: node-version: 24🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/budget-guard.yml around lines 20 - 31, Remove the Git merge conflict markers (<<<<<<< HEAD and >>>>>>> pr-21884) and consolidate the duplicated "Setup pnpm" step so there is a single step for setting up pnpm; attach the orphaned "with: version: 9.15.4" block to that step (or remove it if redundant) and ensure YAML indentation is valid so the "with:" keys are nested under the "Setup pnpm" step rather than left orphaned..github/workflows/ci-council-evidence.yml (1)
12-28:⚠️ Potential issue | 🔴 CriticalCritical: Unresolved Git merge conflict markers will break this workflow.
This file contains unresolved merge conflict markers. Additionally, lines 22-23 have an orphaned and malformed
with:block with incorrect indentation (version: 9.15.4lacks proper indentation).🔧 Proposed fix
steps: - uses: actions/checkout@v4 with: fetch-depth: 0 fetch-tags: true - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 - uses: actions/setup-node@v4 with: node-version: 18 - run: pnpm install --frozen-lockfile - run: pnpm exec tsx .github/scripts/validate-evidence.ts🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-council-evidence.yml around lines 12 - 28, Remove the unresolved merge markers (<<<<<<<, =======, >>>>>>>) and collapse the duplicated "Setup pnpm" steps into a single valid step; ensure the step has either a proper "run: corepack enable && corepack install --global pnpm@9.15.4" without an orphaned with: block or a correctly formatted "with: version: 9.15.4" under a proper action (e.g., if using "uses: pnpm/action-setup@v2" put "with: version: 9.15.4" indented under that); specifically fix the malformed orphaned "with:"/ "version: 9.15.4" under the "Setup pnpm" section and remove any conflict markers so the workflow runs cleanly..github/workflows/ci-regulatory-early-warning.yml (1)
19-47:⚠️ Potential issue | 🔴 CriticalCritical: Unresolved Git merge conflict markers will break this workflow.
This file contains multiple unresolved merge conflicts from different branches (
pr-21884,HEAD,origin/main). The YAML is invalid and will fail to parse.Issues include:
- Lines 19-28: Conflict in checkout and pnpm setup
- Lines 29-30: Orphaned
with: version: 9.15.4with incorrect indentation- Lines 31-47: Conflict between Node 18/24 versions and test execution
🔧 Proposed fix (resolve conflicts)
steps: - uses: actions/checkout@v4 with: fetch-depth: 0 fetch-tags: true - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 - uses: actions/setup-node@v4 with: node-version: 24 - run: pnpm install --frozen-lockfile - run: npx tsx .github/scripts/verify-regulatory-ew-evidence.ts # We will run tests once we actually have them added `#-` run: pnpm test -- tests/graphrag/regulatory/earlywarning🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-regulatory-early-warning.yml around lines 19 - 47, Remove all Git conflict markers (<<<<<<<, =======, >>>>>>>) and consolidate the duplicated steps into a single coherent workflow: keep one checkout step that includes fetch-depth: 0 and fetch-tags: true, keep one "Setup pnpm" step (the step name "Setup pnpm") with corepack enable && corepack install --global pnpm@9.15.4 and a correctly indented with: version: 9.15.4, keep one actions/setup-node@v4 step (choose the intended node-version, e.g., node-version: 24), and ensure the subsequent steps run pnpm install --frozen-lockfile then run the verify script .github/scripts/verify-regulatory-ew-evidence.ts using the chosen runner (npx tsx ... or node ...) and finally the test step; fix indentation and spacing so the YAML is valid..github/workflows/pr-triage.yml (1)
8-13:⚠️ Potential issue | 🔴 CriticalInvalid entry in
permissionsblock will cause workflow failure.
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: trueis not a valid GitHub Actions permission scope. Thepermissionsblock only accepts predefined permission keys likecontents,pull-requests,actions, etc. This will cause a workflow parsing error.Remove line 9 since the variable is already correctly defined in the
envblock at line 16.🐛 Proposed fix
permissions: - FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true contents: read pull-requests: read checks: read statuses: read🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/pr-triage.yml around lines 8 - 13, The permissions block contains an invalid key FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 which will break workflow parsing; remove the FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true entry from the permissions mapping and rely on the existing env-level definition of that variable (already set in the env block) instead, ensuring only valid permission keys like contents, pull-requests, checks, and statuses remain in the permissions section..github/workflows/mcp-drift.yml (1)
16-27:⚠️ Potential issue | 🔴 CriticalUnresolved merge conflict will break this workflow.
The file contains unresolved git merge conflict markers (
<<<<<<<,=======,>>>>>>>) which will cause YAML parsing to fail. Additionally, lines 26-27 have an orphanedwith: version:block that doesn't belong to any action.Resolve the conflict by keeping the intended version. Based on the PR pattern, the resolved version should be:
🐛 Proposed resolution
- uses: actions/checkout@v4 -<<<<<<< HEAD with: fetch-depth: 0 fetch-tags: true - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 -======= - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 ->>>>>>> pr-21884 - with: - version: 9.15.4 - uses: actions/setup-node@v4🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/mcp-drift.yml around lines 16 - 27, The YAML contains unresolved git conflict markers and an orphaned "with: version:" block; remove the conflict markers (<<<<<<<, =======, >>>>>>>) and the stray "with: version: 9.15.4" lines, and keep a single "Setup pnpm" job step that runs "corepack enable && corepack install --global pnpm@9.15.4" (the "Setup pnpm" step in the diff) so the workflow has no duplicate steps or dangling "with:" stanza..github/workflows/ci-sbom.yml (2)
10-17:⚠️ Potential issue | 🔴 CriticalInvalid permissions key will break the workflow.
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24on line 11 is incorrectly placed under thepermissions:block. This is not a valid GitHub workflow permission and will cause the workflow to fail. It should only appear in theenv:block (which correctly exists on lines 16-17).🐛 Proposed fix to remove invalid permissions key
permissions: - FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true contents: read id-token: write # needed for GitHub OIDC attestations attestations: write env: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-sbom.yml around lines 10 - 17, Remove the invalid permissions key FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 from the permissions: block and ensure it only appears in the env: block; in practice edit the permissions block (containing keys like contents, id-token, attestations) to remove the FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 entry and leave the existing env: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true as the sole declaration of that variable.
28-46:⚠️ Potential issue | 🔴 CriticalUnresolved merge conflicts with invalid pnpm version strings.
This section contains multiple unresolved merge conflict markers from branches
pr-22128,pr-21956,pr-21923, andpr-21902. Additionally, the version strings9.15.4.0.0and9.15.4.0are invalid semver and would fail even if the conflicts were resolved incorrectly.🐛 Proposed fix after resolving conflicts
- name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 -<<<<<<< HEAD -<<<<<<< HEAD -<<<<<<< HEAD -<<<<<<< HEAD - version: 9.15.4 -======= - version: 9.15.4.0.0 ->>>>>>> pr-22128 -======= - version: 9.15.4.0.0 ->>>>>>> pr-21956 -======= - version: 9.15.4.0 ->>>>>>> pr-21923 -======= - version: 9.15.4.0.0 ->>>>>>> pr-21902 - uses: actions/setup-node@v4🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-sbom.yml around lines 28 - 46, There are unresolved merge conflict markers and invalid semver values in the "Setup pnpm" step: remove all conflict markers (<<<<<<<, =======, >>>>>>>) and duplicate entries, pick the correct semver value "9.15.4" for the version field (replace any "9.15.4.0" or "9.15.4.0.0"), and ensure only a single, valid version key remains alongside the existing run: corepack enable && corepack install --global pnpm@9.15.4 so the workflow uses a proper pnpm version..github/workflows/ci-post-merge.yml (1)
9-17:⚠️ Potential issue | 🟡 MinorDuplicate workflow-level
env:blocks should be consolidated.Lines 9-10 and 16-17 define the same environment variable twice. While YAML will accept this (the second block overrides the first), it's redundant and potentially confusing. Consolidate into a single
env:block.🧹 Proposed fix to consolidate env blocks
env: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true permissions: contents: read id-token: write -env: - FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true - jobs:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-post-merge.yml around lines 9 - 17, There are two identical workflow-level env blocks defining FORCE_JAVASCRIPT_ACTIONS_TO_NODE24; remove the duplicate and consolidate into a single env: block containing FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true (keep only one declaration), ensuring you preserve the existing permissions: section and overall YAML structure; update the env: block that remains (or move it to the top-level if you prefer) so the workflow defines FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 exactly once..github/workflows/agent-scaling-monitor.yml (1)
18-23:⚠️ Potential issue | 🔴 CriticalUnresolved merge conflict markers will break the workflow.
This file contains unresolved Git merge conflict markers (
<<<<<<< HEAD,=======,>>>>>>> origin/main). Theversion: 9.15.4on line 22 is a remnant from the oldpnpm/action-setupaction configuration and is now orphaned syntax.🐛 Proposed fix after resolving conflicts
- name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 -<<<<<<< HEAD -======= - version: 9.15.4 ->>>>>>> origin/main - uses: actions/setup-node@v4🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/agent-scaling-monitor.yml around lines 18 - 23, Remove the unresolved Git conflict markers and the orphaned `version: 9.15.4` line from the "Setup pnpm" step so the workflow is valid; locate the step that currently runs `corepack enable && corepack install --global pnpm@9.15.4` (the `name: Setup pnpm` block), delete the `<<<<<<< HEAD`, `=======`, and `>>>>>>> origin/main` markers and the stray `version:` entry, leaving only the intended action/command for setting up pnpm..github/workflows/ci-cos.yml (1)
11-23:⚠️ Potential issue | 🔴 CriticalUnresolved merge conflict markers will break the workflow.
This file contains unresolved Git merge conflict markers (
<<<<<<< HEAD,=======,>>>>>>> pr-21884) that will cause the workflow to fail YAML parsing. Additionally, the orphanedwith: version: 9.15.4block on lines 21-22 appears to be a remnant from the oldpnpm/action-setupaction and is now syntactically invalid.🐛 Proposed fix after resolving conflicts
- uses: actions/checkout@v4 + with: + fetch-depth: 0 + fetch-tags: true -<<<<<<< HEAD - with: - fetch-depth: 0 - fetch-tags: true - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 -======= - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 ->>>>>>> pr-21884 - with: - version: 9.15.4 - run: pnpm test:web - run: pnpm eval:cos🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-cos.yml around lines 11 - 23, Remove the unresolved Git conflict markers (<<<<<<<, =======, >>>>>>>) and reconcile the duplicated "Setup pnpm" steps so only the valid step remains; keep the existing corepack command (run: corepack enable && corepack install --global pnpm@9.15.4) and the surrounding checkout fetch settings (fetch-depth/fetch-tags) but delete the orphaned "with: version: 9.15.4" block that came from the old pnpm/action-setup usage; ensure the final YAML has a single "Setup pnpm" step and no conflict markers so the workflow parses correctly..github/workflows/agentic-plan-gate.yml (1)
11-13:⚠️ Potential issue | 🟡 MinorRemove invalid entry from
permissionsblock.
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: trueis not a valid GitHub Actions permission scope and should not be in thepermissionsblock. Unknown permission keys are silently ignored by GitHub Actions. This entry is redundant since the variable is already correctly defined in theenv:block on line 16, so it should be removed.Proposed fix
permissions: - FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true contents: read🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/agentic-plan-gate.yml around lines 11 - 13, Remove the invalid permission key FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 from the workflow's permissions block: open the permissions map (the block containing "permissions:" and the "contents: read" entry) and delete the line with FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true so only valid GitHub Actions permission keys remain; keep the existing env definition for FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 (already declared under env) unchanged..github/workflows/governance-evidence-contracts.yml (2)
16-24:⚠️ Potential issue | 🟡 MinorRemove duplicate top-level
envblocks.Lines 16–18 and 22–24 define
envtwice at the same level. Keep a single block to avoid parser/tooling ambiguity.Proposed fix
env: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true @@ -env: - FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/governance-evidence-contracts.yml around lines 16 - 24, There are two identical top-level env blocks defining FORCE_JAVASCRIPT_ACTIONS_TO_NODE24; remove the duplicate block so only a single top-level env: exists, leaving the single variable FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true defined once. Ensure no other top-level env entries are duplicated and that the remaining env block is correctly indented and placed with the existing permissions: block.
37-53:⚠️ Potential issue | 🔴 CriticalUnresolved merge markers make this workflow invalid.
Lines 37–53 contain merge conflict markers and inconsistent pnpm versions (including invalid-looking forms like
9.15.4.0.0). This must be resolved before merge.Proposed fix
- name: Setup pnpm uses: pnpm/action-setup@v3 with: -<<<<<<< HEAD -<<<<<<< HEAD -<<<<<<< HEAD -<<<<<<< HEAD version: 9.15.4 -======= - version: 9.15.4.0.0 ->>>>>>> pr-22128 -======= - version: 9.15.4.0.0 ->>>>>>> pr-21956 -======= - version: 9.15.4.0 ->>>>>>> pr-21923 -======= - version: 9.15.4.0.0 ->>>>>>> pr-21902🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/governance-evidence-contracts.yml around lines 37 - 53, Remove the git merge conflict markers (<<<<<<<, =======, >>>>>>>) from the workflow and choose a single valid pnpm version string (replace the invalid forms like "9.15.4.0.0" with the proper semantic version e.g. "9.15.4") so the YAML under the key "version:" is consistent and valid; ensure the resulting file contains only one "version: 9.15.4" line and no leftover conflict markers so the .github/workflows/governance-evidence-contracts.yml workflow parses correctly..github/workflows/disinfo.yml (1)
28-39:⚠️ Potential issue | 🔴 CriticalResolve merge conflicts and invalid step schema before merge.
Lines 28–37 contain unresolved conflict markers, and Lines 38–39 attach
withto arunstep. This makes the workflow invalid and blocks execution.Proposed fix
- uses: actions/checkout@v4 -<<<<<<< HEAD with: fetch-depth: 0 fetch-tags: true - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 -======= - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 ->>>>>>> pr-21884 - with: - version: 9.15.4 - uses: actions/setup-node@v4 with: node-version-file: .nvmrc🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/disinfo.yml around lines 28 - 39, Remove the Git conflict markers (<<<<<<<, =======, >>>>>>>) and consolidate the duplicate "Setup pnpm" step so the workflow has a single valid step: either keep the run step (corepack enable && corepack install --global pnpm@9.15.4) and delete the stray "with: version: 9.15.4" block, or replace the run step with a proper action step (e.g., uses: pnpm/action-setup with: version: 9.15.4). Ensure no conflict markers remain and that the "with:" block is attached to an action step (not a run step) so the "Setup pnpm" step is syntactically valid..github/workflows/ci-selfflow.yml (1)
11-22:⚠️ Potential issue | 🔴 CriticalResolve the merge conflict markers in this workflow.
Lines 11–22 contain unresolved merge conflict markers (
<<<<<<< HEAD,=======,>>>>>>> pr-21884) and invalid YAML structure. Thewith: version: 9.15.4block is placed after therun:statement, which is not valid GitHub Actions syntax. GitHub will reject this workflow file until the merge is resolved.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-selfflow.yml around lines 11 - 22, Remove the unresolved merge markers (<<<<<<< HEAD, =======, >>>>>>> pr-21884) and consolidate the duplicate "Setup pnpm" step into a single valid GitHub Actions step: keep the intended command (run: corepack enable && corepack install --global pnpm@9.15.4) and either remove the stray with: version: 9.15.4 block or relocate its key into a proper action that accepts a with.version input; ensure the final "Setup pnpm" step contains only valid YAML keys (name, run or uses+with) and no conflict markers so the workflow is syntactically correct..github/workflows/graph-guardrail-fuzz.yml (1)
27-38:⚠️ Potential issue | 🔴 CriticalResolve the merge conflict and remove the orphaned
withblock (lines 27–38).This workflow contains unresolved merge conflict markers (
<<<<<<<,=======,>>>>>>>) in the checkout and pnpm setup section, along with a straywith: version: 9.15.4fragment that leaves the YAML invalid. The file must be cleaned up so the workflow can load.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/graph-guardrail-fuzz.yml around lines 27 - 38, Resolve the Git merge conflict markers and remove the orphaned with block so the "Setup pnpm" step is valid: delete the <<<<<<<, =======, and >>>>>>> lines and remove the stray "with: version: 9.15.4" fragment; ensure there is a single "Setup pnpm" step that either uses the existing run: line ("run: corepack enable && corepack install --global pnpm@9.15.4") or replaces it with a properly structured action that accepts a with: version key, but do not leave both forms or any conflict markers in place..github/workflows/agentic-policy-drift.yml (1)
22-33:⚠️ Potential issue | 🔴 CriticalResolve the leftover merge-conflict block.
Lines 22–33 contain unresolved merge-conflict markers and a stale
with: version: 9.15.4input that is not valid for a shell run step. The workflow file cannot be parsed by GitHub Actions in this state.Merge conflict details
<<<<<<< HEAD with: fetch-depth: 0 fetch-tags: true - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 ======= - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 >>>>>>> pr-21884 with: version: 9.15.4🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/agentic-policy-drift.yml around lines 22 - 33, Remove the unresolved merge markers (<<<<<<<, =======, >>>>>>>) and fix the two workflow steps so they are valid: keep the checkout step's with: fetch-depth and fetch-tags settings intact (remove the conflict markers around them), ensure the "Setup pnpm" step contains only the shell run line `run: corepack enable && corepack install --global pnpm@9.15.4` and remove the invalid `with: version: 9.15.4` that was left under that run step; locate the steps by the step name "Setup pnpm" and the stray `with: version: 9.15.4` token to make these corrections..github/workflows/ci-legacy.yml (1)
31-42:⚠️ Potential issue | 🔴 CriticalResolve the unresolved merge conflicts before merging.
The workflow contains raw merge-conflict markers (
<<<<<<< / ======= / >>>>>>>), making the YAML invalid. Additionally, orphanedwith: version: 9.15.4fragments remain after theSetup pnpmstep, breaking GitHub Actions parsing.Affects lines: 31-42, 73-84, 114-125, 202-213, 244-255
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-legacy.yml around lines 31 - 42, The file contains raw git conflict markers (<<<<<<<, =======, >>>>>>>) around the "Setup pnpm" step and leftover orphaned "with: version: 9.15.4" fragments; remove the conflict markers and resolve the two conflicting blocks into a single valid GitHub Actions step (keep the intended corepack command: `corepack enable && corepack install --global pnpm@9.15.4` under the "Setup pnpm" step) and either attach the "with: version: 9.15.4" to the correct action if intended or remove it if not, ensuring no stray `with:` fragments remain and the YAML is syntactically valid..github/workflows/graph-sync.yml (1)
17-26:⚠️ Potential issue | 🔴 CriticalBlocker: unresolved merge conflict markers in workflow file.
The
<<<<<<< / ======= / >>>>>>>markers at lines 17, 23, and 26 must be removed; this prevents GitHub Actions from parsing the workflow.✅ Proposed fix
- uses: actions/checkout@v4 -<<<<<<< HEAD with: fetch-depth: 0 fetch-tags: true - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 -======= - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 ->>>>>>> pr-21884 - uses: actions/setup-node@v4 with: node-version: '24'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/graph-sync.yml around lines 17 - 26, Remove the unresolved merge conflict markers (<<<<<<<, =======, >>>>>>>) in the GitHub Actions workflow so the YAML parses; keep the intended combined block (the checkout "with:" keys fetch-depth: 0 and fetch-tags: true and the subsequent "Setup pnpm" step that runs corepack enable && corepack install --global pnpm@9.15.4). Locate the conflict around the checkout step and the "Setup pnpm" step and delete the conflict markers and the duplicate section so only one valid checkout configuration and one "Setup pnpm" step remain..github/workflows/server-ci.yml (1)
19-31:⚠️ Potential issue | 🔴 CriticalBlocker: unresolved merge conflict markers and invalid step schema in multiple workflows.
Multiple workflow files contain unresolved merge conflicts and malformed step schemas that will prevent workflows from running:
.github/workflows/server-ci.yml(lines 19–31): merge conflict markers with leftoverwith:block underrunstep.github/workflows/graph-sync.yml(lines 17–26): merge conflict markers.github/workflows/omics-drift.yml(line 18):runstep with both leftoverwith:block and invalidrun_installkey✅ Proposed fix for server-ci.yml
- uses: actions/checkout@v4 -<<<<<<< HEAD with: fetch-depth: 0 fetch-tags: true - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 -======= - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 ->>>>>>> pr-21884 - with: - version: 9.15.4 - uses: actions/setup-node@v4 with: node-version: 24Resolve all merge conflicts in all three workflow files and remove invalid schema keys from run steps.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/server-ci.yml around lines 19 - 31, There are unresolved merge conflict markers and malformed step schemas around the "Setup pnpm" step (the duplicate blocks containing "run: corepack enable && corepack install --global pnpm@9.15.4" and stray "with:" lines) and similar blocks that introduce an invalid "run_install" key; remove the conflict markers (<<<<<<<, =======, >>>>>>>), keep a single correct "Setup pnpm" step that either uses "run: corepack enable && corepack install --global pnpm@9.15.4" OR a step with "uses: actions/setup-node@v4" with a proper "with: version: 9.15.4" (not both), and remove any non‑GitHub Actions keys like "run_install" in the run steps; apply the same cleanup to the other affected workflow steps that contain merge markers so each step uses a valid "run" or "uses" schema only..github/workflows/compliance-drift-check.yml (1)
21-39:⚠️ Potential issue | 🔴 CriticalResolve the partial merge in this workflow.
This block still contains nested
<<<<<<</=======/>>>>>>>markers, so the YAML is invalid and the compliance drift job won't start.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/compliance-drift-check.yml around lines 21 - 39, The workflow contains unresolved git merge markers in the "Setup pnpm" step around the version field (the block under the step named "Setup pnpm" with the version: key), leaving lines like <<<<<<<, =======, and >>>>>>>; remove the merge conflict markers and pick the correct version value (e.g., normalize to "9.15.4") for the version: entry so the YAML is valid and the compliance-drift job can run..github/workflows/slsa-provenance.yml (1)
20-31:⚠️ Potential issue | 🔴 CriticalResolve the partial merge in this workflow.
The checkout/pnpm block still contains
<<<<<<</=======/>>>>>>>, and the trailingwith: versionis orphaned. GitHub Actions won't parse the workflow, so the build and provenance jobs never run.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/slsa-provenance.yml around lines 20 - 31, Remove the leftover merge conflict markers and fix the orphaned fields in the workflow: delete the "<<<<<<<", "=======", and ">>>>>>>" lines, ensure there's a single "Setup pnpm" step (the step name "Setup pnpm" should only appear once) that runs "corepack enable && corepack install --global pnpm@9.15.4" and includes the intended "with: version: 9.15.4" only if applicable to that action, and restore the checkout step so its "with: fetch-depth: 0" and "with: fetch-tags: true" remain under the "actions/checkout" step (i.e., move the orphaned with: version block out of the checkout if it belongs to the pnpm setup), ensuring the YAML is valid and no conflict markers remain..github/workflows/lex-governance.yml (1)
28-39:⚠️ Potential issue | 🔴 CriticalResolve the partial merge in this workflow.
This block still contains
<<<<<<</=======/>>>>>>>, and the danglingwith: versionis no longer attached to an action step. GitHub Actions won't parse this file in this state, and the same unresolved block repeats through the rest of the workflow.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/lex-governance.yml around lines 28 - 39, The workflow contains unresolved merge markers around the "Setup pnpm" step; remove the conflict lines (<<<<<<<, =======, >>>>>>>) and collapse the duplicates so there is a single well-formed "Setup pnpm" step (keep the intended run command `corepack enable && corepack install --global pnpm@9.15.4` and ensure any `with: version: 9.15.4` is either removed or properly attached to the correct action for that step). Ensure no dangling `with:` block remains and the YAML is valid..github/workflows/release-reliability.yml (1)
20-31:⚠️ Potential issue | 🔴 CriticalResolve the partial merge in this workflow.
This block still has
<<<<<<</=======/>>>>>>>, and the trailingwith: versionis now orphaned under the shell step. GitHub Actions won't parse the workflow, so release verification never starts.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-reliability.yml around lines 20 - 31, Remove the leftover Git conflict markers and produce a single valid "Setup pnpm" step: delete the lines starting with <<<<<<<, =======, and >>>>>>> and ensure only one "Setup pnpm" step remains (keep the run: corepack enable && corepack install --global pnpm@9.15.4 line and remove the orphaned with: version: 9.15.4 since it is not valid under a shell step); ensure there are no stray "with:" blocks left under the run step so the workflow YAML parses correctly..github/workflows/ci-core.yml (2)
86-93:⚠️ Potential issue | 🟡 MinorRemove duplicate
actions/setup-nodesteps in lint-typecheck job.The
lint-typecheckjob has twoactions/setup-node@v4steps (lines 86-89 and 90-92). Only one is needed. Additionally, this job is missing the "Setup pnpm" step that other jobs have.🐛 Proposed fix
- uses: actions/checkout@v4 # v6 with: fetch-depth: 0 fetch-tags: true + - name: Setup pnpm + run: corepack enable && corepack install --global pnpm@9.15.4 - uses: actions/setup-node@v4 # v6 with: - cache: "pnpm" node-version-file: .nvmrc - - uses: actions/setup-node@v4 - with: - node-version-file: .nvmrc🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-core.yml around lines 86 - 93, In the lint-typecheck job remove the duplicate uses: actions/setup-node@v4 step (the second occurrence) and add the missing "Setup pnpm" step to match other jobs; specifically keep a single actions/setup-node@v4 with node-version-file: .nvmrc and insert the same "Setup pnpm" step used elsewhere in the workflow (named "Setup pnpm") so pnpm caching/installation behaves consistently across jobs.
451-454:⚠️ Potential issue | 🔴 CriticalCritical: Malformed YAML in soc-control-verification job.
The
with:block is incorrectly indented underuses: pnpm/action-setup@v3. This causes a YAML parsing error and breaks the workflow. Additionally, this job still uses the oldpnpm/action-setuppattern instead of the corepack-based approach used elsewhere.🐛 Proposed fix to align with other jobs
- name: Setup pnpm - uses: pnpm/action-setup@v3 - with: - version: 9.15.4 + run: corepack enable && corepack install --global pnpm@9.15.4 - name: Use Node uses: actions/setup-node@v4 with: node-version-file: .nvmrc - cache: "pnpm"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci-core.yml around lines 451 - 454, The "Setup pnpm" step is malformed: the with: block is incorrectly indented under uses: pnpm/action-setup@v3 and should be moved to the same indentation level as uses to fix YAML parsing; additionally replace the legacy uses: pnpm/action-setup@v3 pattern with the project's corepack-based approach (match other jobs) by swapping the step to run corepack enable and corepack prepare pnpm@9.15.4 --activate (or replicate the exact corepack commands used in other jobs) so the job uses corepack consistently..github/workflows/mvp4-gate.yml (2)
22-35:⚠️ Potential issue | 🔴 CriticalCritical: Unresolved merge conflict markers will break this workflow.
This file contains unresolved Git merge conflict markers (
<<<<<<< HEAD,=======,>>>>>>> pr-21884) that will cause the workflow to fail to parse. Additionally, there are duplicate "Setup pnpm" steps in both conflict branches.🐛 Proposed fix to resolve the conflict
- uses: actions/checkout@v4 # v6 with: fetch-depth: 0 fetch-tags: true -<<<<<<< HEAD - with: - fetch-depth: 0 - fetch-tags: true - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 -======= - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 ->>>>>>> pr-21884 - name: Cache pnpm store🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/mvp4-gate.yml around lines 22 - 35, Remove the unresolved Git conflict markers (<<<<<<< HEAD, =======, >>>>>>> pr-21884) and consolidate the duplicated "Setup pnpm" steps into a single step; locate the duplicate steps identified by the job step name "Setup pnpm" and keep one run: corepack enable && corepack install --global pnpm@9.15.4 entry, deleting the other duplicate and all conflict marker lines so the workflow YAML parses cleanly.
65-76:⚠️ Potential issue | 🔴 CriticalCritical: Another unresolved merge conflict with orphaned YAML syntax.
Lines 65-76 contain another merge conflict and orphaned
with:/version:keys (lines 74-75) that are not associated with any action. This will cause a YAML parsing error.🐛 Proposed fix
cache: "pnpm" -<<<<<<< HEAD cache-dependency-path: "**/pnpm-lock.yaml" - name: Setup pnpm run: corepack enable && corepack install --global pnpm@9.15.4 -======= - cache-dependency-path: '**/pnpm-lock.yaml' - - name: Setup pnpm - run: corepack enable && corepack install --global pnpm@9.15.4 ->>>>>>> pr-21884 - with: - version: 9.15.4 - name: Install run: pnpm install --frozen-lockfile🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/mvp4-gate.yml around lines 65 - 76, Remove the unresolved Git conflict markers (<<<<<<<, =======, >>>>>>>) and the orphaned YAML keys by keeping a single valid "Setup pnpm" step; ensure the step's run line is correct (e.g., corepack enable && corepack install --global pnpm@9.15.4) and remove or correctly attach the stray "with:" / "version:" keys (delete them if not required or move them under the intended action). Target the "Setup pnpm" step and eliminate the conflict markers and the orphaned "with:" and "version:" entries so the workflow YAML parses cleanly.
🟡 Minor comments (3)
.github/workflows/hotfix-release.yml-153-159 (1)
153-159:⚠️ Potential issue | 🟡 MinorRedundant cache configuration —
actions/setup-nodealready handles pnpm caching.Lines 147-151 configure
actions/setup-node@v4withcache: "pnpm", which automatically caches the pnpm store. Adding a separateactions/cache@v4step creates redundancy and may lead to cache key collisions or wasted storage.Either remove this explicit cache step (relying on setup-node's built-in caching) or remove
cache: "pnpm"from setup-node if you need custom cache control.🧹 Option 1: Remove redundant cache step
- - name: Cache pnpm store - uses: actions/cache@v4 - with: - path: ~/.local/share/pnpm/store/v3 - key: ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }} - restore-keys: | - ${{ runner.os }}-pnpm- - - name: Install Dependencies run: pnpm install --frozen-lockfile🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/hotfix-release.yml around lines 153 - 159, The workflow currently duplicates pnpm caching: you set cache: "pnpm" on actions/setup-node@v4 and also have a separate actions/cache@v4 step named "Cache pnpm store"; remove the redundant actions/cache@v4 step (the block with name "Cache pnpm store" and uses: actions/cache@v4) so setup-node's built-in pnpm cache is relied upon, or alternatively remove cache: "pnpm" from actions/setup-node@v4 if you prefer to manage caching manually—pick one approach and delete the other to avoid collisions.bulk_patch.cjs-44-54 (1)
44-54:⚠️ Potential issue | 🟡 MinorEnvironment variable injection may target wrong
env:block.The replacement
content.replace(/env:\n/, ...)matches the first occurrence ofenv:\nin the file, which could be a job-level or step-levelenv:block rather than the workflow-level one. This could inject the variable in an unintended location.♻️ Consider anchoring to workflow-level env block
A more robust approach would be to look for the workflow-level
env:block (which appears beforejobs:) or insert at a known position:// Only match workflow-level env (before jobs:) const jobsIndex = content.indexOf('jobs:'); const envMatch = content.substring(0, jobsIndex).match(/^env:\n/m); if (envMatch) { // Insert after workflow-level env: const insertPos = envMatch.index + envMatch[0].length; content = content.substring(0, insertPos) + " FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true\n" + content.substring(insertPos); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@bulk_patch.cjs` around lines 44 - 54, The current logic that injects FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 uses content.replace(/env:\n/, ...) which can match a job/step-level env; change it to only target the workflow-level env by locating the indexOf('jobs:') first, then search for /^env:\n/m inside content.substring(0, jobsIndex); if found, insert the new variable immediately after that workflow-level env block (using the env match's position + length) otherwise fall back to inserting before 'jobs:' (as the existing insertAfter logic does); update the branches that set content and keep setting changed = true when you mutate content (references: content, jobsIndex, insertAfter, changed)..github/workflows/pr-fast.yml-27-41 (1)
27-41:⚠️ Potential issue | 🟡 MinorRemove duplicate "Cache pnpm store" step.
There are two identical
Cache pnpm storesteps (lines 27-33 and 35-41). The second one is redundant and should be removed.🐛 Proposed fix
- name: Cache pnpm store uses: actions/cache@v4 with: path: ~/.local/share/pnpm/store/v3 key: ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }} restore-keys: | ${{ runner.os }}-pnpm- - - name: Cache pnpm store - uses: actions/cache@v4 - with: - path: ~/.local/share/pnpm/store/v3 - key: ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }} - restore-keys: | - ${{ runner.os }}-pnpm- - - name: Install🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/pr-fast.yml around lines 27 - 41, The workflow contains a duplicate "Cache pnpm store" step using actions/cache@v4 (identical path ~/.local/share/pnpm/store/v3 and key expression ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }}); remove the redundant second "Cache pnpm store" step so only one cache step with uses: actions/cache@v4, path: ~/.local/share/pnpm/store/v3 and the existing key/restore-keys remains in the job.
| - name: Setup pnpm | ||
| run: corepack enable && corepack install --global pnpm@9.15.4 | ||
| <<<<<<< HEAD | ||
| ======= | ||
| version: 9.15.4 | ||
| >>>>>>> origin/main | ||
| - uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: 24 | ||
| cache: 'pnpm' | ||
| - run: pnpm install --frozen-lockfile |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify unresolved merge markers are gone from this workflow file
rg -n '^(<<<<<<<|=======|>>>>>>>)' .github/workflows/agent-scaling-gate.ymlRepository: BrianCLong/summit
Length of output: 110
Resolve merge-conflict markers in the workflow; this file will not parse.
Lines 24–27 contain unresolved merge-conflict markers (<<<<<<< HEAD, =======, >>>>>>> origin/main). Additionally, reorder the steps to place setup-node before Corepack/pnpm setup for deterministic pnpm installation.
🛠️ Proposed fix
- - name: Setup pnpm
- run: corepack enable && corepack install --global pnpm@9.15.4
-<<<<<<< HEAD
-
-=======
- version: 9.15.4
->>>>>>> origin/main
- uses: actions/setup-node@v4
with:
node-version: 24
+ - name: Setup pnpm
+ run: corepack enable && corepack install --global pnpm@9.15.4🧰 Tools
🪛 YAMLlint (1.38.0)
[error] 25-25: syntax error: could not find expected ':'
(syntax)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/agent-scaling-gate.yml around lines 22 - 31, Remove the
unresolved merge markers (<<<<<<<, =======, >>>>>>>) and restore a valid step
sequence: first run the actions/setup-node@v4 step (with node-version: 24) and
then run the Corepack/pnpm setup (the command currently shown as corepack enable
&& corepack install --global pnpm@9.15.4), followed by the pnpm install
--frozen-lockfile step; ensure there are no leftover conflict tokens and the
three steps use the exact identifiers actions/setup-node@v4, corepack enable &&
corepack install --global pnpm@9.15.4, and pnpm install --frozen-lockfile so the
workflow parses and installs pnpm deterministically.
bulk_patch.cjs
Outdated
| if (cachePattern.test(content)) { | ||
| content = content.replace(cachePattern, ''); | ||
| changed = true; | ||
| } |
There was a problem hiding this comment.
Same lastIndex issue with cachePattern regex.
The /g flag on cachePattern combined with test() then replace() has the same bug. Additionally, removing cache: 'pnpm' lines without checking surrounding YAML structure could leave orphaned with: blocks if the cache was the only property.
🐛 Proposed fix
- if (cachePattern.test(content)) {
- content = content.replace(cachePattern, '');
+ if (content.match(cachePattern)) {
+ content = content.replace(/ *cache: '?pnpm'?\n/g, '');
changed = true;
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@bulk_patch.cjs` around lines 22 - 25, The current logic using cachePattern
with the /g flag plus cachePattern.test(content) then
content.replace(cachePattern, '') can fail due to regex.lastIndex; remove the
global flag from cachePattern (or reset lastIndex to 0 before test) and perform
a single replace that targets the exact YAML key line including its trailing
newline; additionally update the removal to detect and also remove an orphaned
"with:" block (and its indented child lines) when the cache entry was the only
property under that block so you don't leave empty "with:" blocks — adjust code
around the variables cachePattern, content, and changed to perform these checks
and set changed = true when either the cache line or the orphaned with-block is
removed.
fix.cjs
Outdated
|
|
||
| code = code.replace(" - name: Install", cacheStep + "\n\n - name: Install"); | ||
|
|
||
| code = code.replace("run: pnpm -r build --filter=./services/*", "run: pnpm --filter=\\"./services/*\\" build"); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Inspect Line 26 in fix.cjs:"
rg -n 'code\.replace\("run: pnpm -r build --filter=\./services/\*", "run: pnpm --filter=' fix.cjs -n -C 1
echo "Syntax check:"
node --check fix.cjsRepository: BrianCLong/summit
Length of output: 643
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Create a test file with the proposed fix applied
cat > /tmp/fix_test.cjs << 'EOF'
code = code.replace("run: pnpm -r build --filter=./services/*", "run: pnpm --filter=\"./services/*\" build");
EOF
echo "Syntax check with proposed fix:"
node --check /tmp/fix_test.cjs && echo "✓ Fix resolves the syntax error" || echo "✗ Fix does not resolve the error"Repository: BrianCLong/summit
Length of output: 124
Fix broken escaping in Line 26 (script currently does not parse).
The replacement string uses invalid escaping (\\") in a double-quoted literal, which breaks JS parsing before runtime.
🔧 Proposed fix
-code = code.replace("run: pnpm -r build --filter=./services/*", "run: pnpm --filter=\\"./services/*\\" build");
+code = code.replace("run: pnpm -r build --filter=./services/*", "run: pnpm --filter=\"./services/*\" build");📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| code = code.replace("run: pnpm -r build --filter=./services/*", "run: pnpm --filter=\\"./services/*\\" build"); | |
| code = code.replace("run: pnpm -r build --filter=./services/*", "run: pnpm --filter=\"./services/*\" build"); |
🧰 Tools
🪛 Biome (2.4.10)
[error] 26-26: Expected an identifier but instead found '/'.
(parse)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@fix.cjs` at line 26, The replace call on the variable `code` contains an
incorrectly escaped replacement string ("run: pnpm --filter=\\"./services/*\\"
build") which breaks JS parsing; fix by using a different quoting strategy so
the inner quotes don't need backslash escapes (e.g., use single-quoted outer
string or a template literal) in the `code.replace(...)` call so the replacement
becomes something like 'run: pnpm --filter="./services/*" build' (or backtick
quoted) while keeping the search string `run: pnpm -r build
--filter=./services/*` unchanged.
| export function computeMemoryDecay({ ageInDays, accessCount }: DecayParams): number { | ||
| if (ageInDays <= 0) return 0; // New memories have no decay | ||
|
|
||
| // Expected accesses per day can be an arbitrary baseline, let's use 1 access / day | ||
| // If accessCount >= ageInDays, decay is 0. | ||
| // Otherwise, decay is scaled. | ||
| const expectedAccesses = ageInDays; | ||
|
|
||
| if (accessCount >= expectedAccesses) { | ||
| return 0; | ||
| } | ||
|
|
||
| return 1 - (accessCount / expectedAccesses); |
There was a problem hiding this comment.
Validate or clamp decay inputs before returning the score.
computeMemoryDecay({ ageInDays: 10, accessCount: -1 }) currently returns 1.1, and non-finite inputs turn into NaN. Since the rest of this PR treats decay as a normalized 0..1 metric, please reject invalid values or clamp the result here.
🛠️ Proposed fix
export function computeMemoryDecay({ ageInDays, accessCount }: DecayParams): number {
+ if (!Number.isFinite(ageInDays) || !Number.isFinite(accessCount)) {
+ throw new RangeError('ageInDays and accessCount must be finite numbers');
+ }
if (ageInDays <= 0) return 0; // New memories have no decay
// Expected accesses per day can be an arbitrary baseline, let's use 1 access / day
// If accessCount >= ageInDays, decay is 0.
// Otherwise, decay is scaled.
const expectedAccesses = ageInDays;
+ const safeAccessCount = Math.max(0, accessCount);
- if (accessCount >= expectedAccesses) {
+ if (safeAccessCount >= expectedAccesses) {
return 0;
}
- return 1 - (accessCount / expectedAccesses);
+ return Math.min(1, Math.max(0, 1 - (safeAccessCount / expectedAccesses)));
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/intelgraph/graphrag/src/metrics/decay.ts` around lines 11 - 23,
computeMemoryDecay allows negative or non-finite inputs and can return values
outside 0..1; validate and clamp inputs inside the function: ensure ageInDays
and accessCount are finite and non-negative (treat invalid/non-finite as 0 or
throw per project convention), treat ageInDays<=0 as returning 0 as already
done, clamp accessCount to the range [0, expectedAccesses] (where
expectedAccesses = ageInDays), compute decay as 1 - (accessCount /
expectedAccesses) and finally clamp the result to [0,1] before returning; update
the function handling of DecayParams (ageInDays, accessCount, expectedAccesses)
accordingly so callers always get a normalized 0..1 decay.
| export function computeEpistemicEntropy(distribution: BeliefDistribution): number { | ||
| const values = Object.values(distribution); | ||
| if (values.length <= 1) return 0; // No disagreement possible | ||
|
|
||
| const sum = values.reduce((acc, v) => acc + v, 0); | ||
| if (sum === 0) return 0; // Empty confidence | ||
|
|
||
| const probabilities = values.map(v => v / sum); | ||
|
|
||
| let entropy = 0; | ||
| for (const p of probabilities) { | ||
| if (p > 0) { | ||
| entropy -= p * Math.log2(p); | ||
| } | ||
| } | ||
|
|
||
| // Normalize by the max possible entropy for this number of beliefs (log2 N) | ||
| const maxEntropy = Math.log2(values.length); | ||
| return maxEntropy > 0 ? entropy / maxEntropy : 0; |
There was a problem hiding this comment.
Reject invalid belief weights before computing entropy.
BeliefDistribution accepts arbitrary numbers today, so negative, NaN, or Infinity inputs can drive this metric below 0 or to NaN (for example, { a: 2, b: -1 }). Since this value is later stored on node.epistemicEntropy, please validate the weights at this boundary.
🛠️ Proposed fix
export function computeEpistemicEntropy(distribution: BeliefDistribution): number {
const values = Object.values(distribution);
+ if (values.some(v => !Number.isFinite(v) || v < 0)) {
+ throw new RangeError('Belief weights must be finite and non-negative');
+ }
if (values.length <= 1) return 0; // No disagreement possible
const sum = values.reduce((acc, v) => acc + v, 0);
- if (sum === 0) return 0; // Empty confidence
+ if (sum <= 0) return 0; // Empty confidence📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export function computeEpistemicEntropy(distribution: BeliefDistribution): number { | |
| const values = Object.values(distribution); | |
| if (values.length <= 1) return 0; // No disagreement possible | |
| const sum = values.reduce((acc, v) => acc + v, 0); | |
| if (sum === 0) return 0; // Empty confidence | |
| const probabilities = values.map(v => v / sum); | |
| let entropy = 0; | |
| for (const p of probabilities) { | |
| if (p > 0) { | |
| entropy -= p * Math.log2(p); | |
| } | |
| } | |
| // Normalize by the max possible entropy for this number of beliefs (log2 N) | |
| const maxEntropy = Math.log2(values.length); | |
| return maxEntropy > 0 ? entropy / maxEntropy : 0; | |
| export function computeEpistemicEntropy(distribution: BeliefDistribution): number { | |
| const values = Object.values(distribution); | |
| if (values.some(v => !Number.isFinite(v) || v < 0)) { | |
| throw new RangeError('Belief weights must be finite and non-negative'); | |
| } | |
| if (values.length <= 1) return 0; // No disagreement possible | |
| const sum = values.reduce((acc, v) => acc + v, 0); | |
| if (sum <= 0) return 0; // Empty confidence | |
| const probabilities = values.map(v => v / sum); | |
| let entropy = 0; | |
| for (const p of probabilities) { | |
| if (p > 0) { | |
| entropy -= p * Math.log2(p); | |
| } | |
| } | |
| // Normalize by the max possible entropy for this number of beliefs (log2 N) | |
| const maxEntropy = Math.log2(values.length); | |
| return maxEntropy > 0 ? entropy / maxEntropy : 0; |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/intelgraph/graphrag/src/metrics/entropy.ts` around lines 10 - 28,
The computeEpistemicEntropy function must reject or sanitize invalid belief
weights from the BeliefDistribution before computing entropy: in
computeEpistemicEntropy, filter out or treat as zero any entries whose value is
NaN, Infinity, or negative (e.g., Number.isFinite(v) && v > 0), then compute
sum/probabilities on the sanitized array and return 0 if no valid weights
remain; ensure this prevents NaN/negative entropy values being written to
node.epistemicEntropy and reference computeEpistemicEntropy and
BeliefDistribution so reviewers can locate the change.
| function computeDecayIndicator(timestamp: string, accessCount: number = 0): number { | ||
| const ageInMs = Date.now() - new Date(timestamp).getTime(); | ||
| const ageInDays = ageInMs / (1000 * 60 * 60 * 24); | ||
| if (ageInDays <= 0) return 0; | ||
|
|
||
| const expectedAccesses = ageInDays; | ||
| if (accessCount >= expectedAccesses) return 0; | ||
| return 1 - (accessCount / expectedAccesses); |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In the JavaScript neo4j-driver, when a property is stored with Cypher datetime(...)and returned fromrecord.get(...)or a map projection, what runtime type is produced, and what is the supported way to convert it before passing it tonew Date(...)?
💡 Result:
In the JavaScript neo4j-driver, a property stored with Cypher datetime(...) (which produces a ZONED DATETIME type) and retrieved via record.get(...) or map projection is returned as a DateTime object from the driver's temporal types. This is a custom immutable class (imported as DateTime from 'neo4j-driver-core/lib/temporal-types.js'), with properties like year, month, day, hour, etc. (using driver's Integer type), timeZoneId, and timeZoneOffsetSeconds. The supported way to convert it to a native JavaScript Date for use with new Date(...) is to call the toStandardDate method on the DateTime instance, which returns a Date object (lossy, drops nanosecond precision and follows specific timezone handling to UTC). Example: const dt = record.get('myDateTimeProperty'); // DateTime instance const jsDate = dt.toStandardDate; // native Date // Now safe for new Date(jsDate) or direct use Note: Direct new Date(dt) will fail as DateTime is not a valid constructor argument. Use toStandardDate instead.
Citations:
- 1: https://neo4j.com/docs/api/javascript-driver/current/class/lib6/temporal-types.js~DateTime.html
- 2: https://neo4j.com/docs/javascript-manual/current/data-types/
- 3: https://neo4j.com/docs/javascript-manual/current/data-types
- 4: https://neo4j.com/docs/api/javascript-driver/4.3/class/lib6/temporal-types.js~DateTime.html
🏁 Script executed:
# First, let's examine the graph-memory.ts file to see the computeDecayIndicator function and context around lines 108-115 and 282-287
wc -l packages/strands-agents/src/memory/graph-memory.tsRepository: BrianCLong/summit
Length of output: 115
🏁 Script executed:
# Read the file around the mentioned lines
sed -n '100,125p' packages/strands-agents/src/memory/graph-memory.tsRepository: BrianCLong/summit
Length of output: 832
🏁 Script executed:
# Also check lines around 282-287
sed -n '275,295p' packages/strands-agents/src/memory/graph-memory.tsRepository: BrianCLong/summit
Length of output: 784
🏁 Script executed:
# Find the remember() and recall() function definitions to understand data flow
grep -n "function remember\|function recall\|const remember\|const recall" packages/strands-agents/src/memory/graph-memory.tsRepository: BrianCLong/summit
Length of output: 253
🏁 Script executed:
# Read the remember() function (starts at line 148)
sed -n '148,220p' packages/strands-agents/src/memory/graph-memory.tsRepository: BrianCLong/summit
Length of output: 2182
🏁 Script executed:
# Read the recall() function (starts at line 219)
sed -n '219,300p' packages/strands-agents/src/memory/graph-memory.tsRepository: BrianCLong/summit
Length of output: 2492
🏁 Script executed:
# Check for any imports or use of DateTime/temporal types
grep -n "DateTime\|temporal\|neo4j-driver" packages/strands-agents/src/memory/graph-memory.tsRepository: BrianCLong/summit
Length of output: 155
Convert Neo4j DateTime objects to Date before computing decay.
When recall() retrieves memories, the Neo4j JavaScript driver deserializes the stored datetime value to a DateTime object, not a string. Passing this directly to new Date(m.timestamp) results in NaN. Convert using the DateTime's toStandardDate() method before passing to computeDecayIndicator() and before the age_days calculation in the console.log.
This affects both the function definition and its callsites in recall().
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/strands-agents/src/memory/graph-memory.ts` around lines 108 - 115,
The computeDecayIndicator function currently assumes timestamp is a string;
change it to accept a Date (or a Neo4j DateTime) and normalize inputs by
converting Neo4j DateTime objects via toStandardDate() (or converting strings to
Date) before computing age; update all callsites in recall() so any Neo4j
DateTime returned from the driver is converted with toStandardDate() (and then
to a JS Date) before being passed into computeDecayIndicator and before the
age_days console.log calculation; ensure computeDecayIndicator handles a Date
input (using getTime()) and falls back to parsing strings if necessary.
BrianCLong
force-pushed
the
feat/observability-epistemic-metrics-12171903363096388720
branch
from
f695baa to
7e5f022
Compare
1 participant
computeEpistemicEntropyandcomputeMemoryDecayutilities topackages/intelgraph/graphrag/src/metrics/epistemicEntropyproperty to GraphRAGNodeontologyupsertNodeinNarrativeGraphStorerecallmethod ofpackages/strands-agents/src/memory/graph-memory.tsMetricsAggregatorsingleton inapps/intelgraph-api/src/routes/internalStatus.ts/api/internal/metrics/entropy-decaydashboard endpointpackages/intelgraph/graphrag/src/__tests__/metrics.test.tsPR created automatically by Jules for task 12171903363096388720 started by @BrianCLong
Summary by CodeRabbit
New Features
Chores
Tests