Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions .github/ISSUE_TEMPLATE/issue_template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
name: Issue Report
about: Create a report to help us improve
title: ''
labels: ''
assignees: ''

---

**Describe the bug or feature request**
A clear and concise description of what the bug is or what the feature request is about.

**To Reproduce**
Steps to reproduce the behavior (if applicable):
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

**Expected behavior**
A clear and concise description of what you expected to happen.

**Screenshots**
If applicable, add screenshots to help explain your problem.

**Desktop (please complete the following information):**
- OS: [e.g. iOS]
- Browser [e.g. chrome, safari]
- Version [e.g. 22]

**Additional context**
Add any other context about the problem here.
22 changes: 22 additions & 0 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
## Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.

Fixes # (issue)

## Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update

## How Has This Been Tested?
Please describe the tests that you ran to verify your changes.

## Checklist:
- [ ] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
18 changes: 18 additions & 0 deletions .github/workflows/ai-review.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
name: AI Code Review

on:
pull_request:
types: [opened, synchronize]

jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: coderabbitai/openai-pr-reviewer@v1.17.1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
Comment on lines +3 to +14

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

git ls-files .github/workflows/ai-review.yml
printf '\n---\n'
cat -n .github/workflows/ai-review.yml

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 728


Guard the review job for forked PRs .github/workflows/ai-review.yml:3-14pull_request does not pass secrets.OPENAI_API_KEY to PRs from forks, so external contributors will hit a missing-secret path here. Add a fork/secret guard or move the secret-dependent step to a trusted trigger like pull_request_target.

🧰 Tools
🪛 zizmor (1.26.1)

[error] 11-11: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[info] 8-8: workflow or action definition without a name (anonymous-definition): this job

(anonymous-definition)


[warning] 3-5: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting

(concurrency-limits)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/ai-review.yml around lines 3 - 14, The review workflow
currently depends on OPENAI_API_KEY inside the review job, which breaks for
forked pull requests because that secret is unavailable. Update the ai-review
workflow to guard the coderabbitai/openai-pr-reviewer step against forked PRs or
switch the secret-dependent execution to a trusted trigger like
pull_request_target, using the review job and its env block as the main places
to adjust.

with:
debug: false
review_simple_changes: false
review_comment_lgtm: false
Comment on lines +7 to +18

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

git ls-files .github/workflows/ai-review.yml
echo '---'
nl -ba .github/workflows/ai-review.yml | sed -n '1,80p'

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 239


🏁 Script executed:

#!/bin/bash
set -euo pipefail

python3 - <<'PY'
from pathlib import Path
p = Path('.github/workflows/ai-review.yml')
text = p.read_text()
for i, line in enumerate(text.splitlines(), 1):
    print(f"{i:>4} {line}")
PY

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 655


🌐 Web query:

GitHub Actions GITHUB_TOKEN default permissions pull request review comments pull-requests write coderabbitai/openai-pr-reviewer permissions

💡 Result:

The GITHUB_TOKEN used in GitHub Actions defaults to read-only permissions for new repositories and organizations [1]. While it previously had broader read/write access, this change was implemented to improve security [1]. You can modify these permissions in repository or organization settings [2], or explicitly override them within a workflow or job using the permissions key [3][4]. To perform operations such as creating or managing pull request review comments using the coderabbitai/openai-pr-reviewer action (or similar tools), the GITHUB_TOKEN requires the pull-requests: write permission [5][6][7]. A common point of confusion is the distinction between pull request and issue resources in the GitHub API. Even though the REST API path for posting comments on pull requests often includes the word "issues" (e.g., /repos/{owner}/{repo}/issues/{issue_number}/comments), creating these comments is governed by the pull-requests scope [8][7]. Granting issues: write permission is often insufficient or incorrect for these actions, whereas pull-requests: write provides the necessary access to interact with pull request metadata and comments [7]. Additionally, if your workflow is triggered by a pull request from a forked repository, GitHub automatically restricts the GITHUB_TOKEN to read-only mode to prevent security exploits, unless you use the pull_request_target event [4][5][9]. Using pull_request_target allows the workflow to access secrets and have elevated write permissions, but it requires careful configuration to ensure code is checked out safely from the correct commit [5][6].

Citations:


🌐 Web query:

coderabbitai openai-pr-reviewer required permissions pull-requests contents read GitHub Actions

💡 Result:

To configure the CodeRabbit AI PR reviewer GitHub Action, your workflow file must explicitly define the required permissions to allow the action to read your code and post feedback [1][2][3]. The following permissions are required within your GitHub Actions workflow file [1][2][3]: permissions: contents: read pull-requests: write Explanation of these permissions: - contents: read: This is required for the action to check out and analyze your repository's code [1][3]. - pull-requests: write: This is required for the action to post comments, summaries, and review feedback on your pull requests [1][2][3]. These settings ensure the GITHUB_TOKEN used by the action has sufficient scope to perform its tasks [1][3]. If you are using the CodeRabbit GitHub App (rather than just the Actions-only setup), ensure that the app has also been granted the necessary repository access in your GitHub organization or repository settings [4][5][6].

Citations:


Add explicit workflow permissions for the review bot.

Declare permissions: contents: read and pull-requests: write on this job instead of inheriting the repository default token scopes; that’s the minimal access the action needs to read the repo and post PR feedback.

Suggested change
 jobs:
   review:
+    permissions:
+      contents: read
+      pull-requests: write
     runs-on: ubuntu-latest
📝 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.

Suggested change
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: coderabbitai/openai-pr-reviewer@latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
with:
debug: false
review_simple_changes: false
review_comment_lgtm: false
jobs:
review:
permissions:
contents: read
pull-requests: write
runs-on: ubuntu-latest
steps:
- uses: coderabbitai/openai-pr-reviewer@latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
with:
debug: false
review_simple_changes: false
review_comment_lgtm: false
🧰 Tools
🪛 zizmor (1.26.1)

[error] 11-11: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[info] 8-8: workflow or action definition without a name (anonymous-definition): this job

(anonymous-definition)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/ai-review.yml around lines 7 - 18, The review job in the
ai-review workflow is relying on default GITHUB_TOKEN scopes instead of
explicitly declaring the minimal permissions needed. Update the review job
definition for coderabbitai/openai-pr-reviewer@latest to include job-level
permissions with contents: read and pull-requests: write so the action can read
the repository and post PR comments without broader access.

Source: Linters/SAST tools

43 changes: 43 additions & 0 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
name: CI

on:
push:
branches: [ "main", "master" ]
pull_request:
branches: [ "main", "master" ]

jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
lfs: true
Comment on lines +13 to +15

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

Restrict token exposure in this job.

This pull_request job executes repository-controlled pytest, npm install, and npm run build steps after checkout. Because the workflow relies on repository-default token scopes and leaves the checkout credential persisted in Git config, those scripts inherit more repository access than they need. Add an explicit read-only permissions block and persist-credentials: false.

Suggested hardening
 name: CI
 
 on:
   push:
     branches: [ "main", "master" ]
   pull_request:
     branches: [ "main", "master" ]
 
+permissions:
+  contents: read
+
 jobs:
   test:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v4
       with:
         lfs: true
+        persist-credentials: false

Also applies to: 31-43

🧰 Tools
🪛 zizmor (1.26.1)

[warning] 13-15: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 13-13: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/ci.yml around lines 13 - 15, The CI job currently exposes
more GitHub token access than needed after checkout. Update the workflow around
the `actions/checkout@v4` step and the job that runs `pytest`, `npm install`,
and `npm run build` to use an explicit read-only `permissions` block and set
`persist-credentials: false` on checkout so repository scripts do not inherit or
reuse the checkout credential.

Source: Linters/SAST tools


- name: Set up Python
uses: actions/setup-python@v5
Comment on lines +13 to +18

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect the workflow and surrounding lines with line numbers.
git ls-files .github/workflows/ci.yml
wc -l .github/workflows/ci.yml
cat -n .github/workflows/ci.yml | sed -n '1,120p'

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 1405


Pin the GitHub Actions to immutable SHAs. .github/workflows/ci.yml:13,18,35 still uses mutable tags (actions/checkout@v4, actions/setup-python@v5, actions/setup-node@v4); pin them to full commit SHAs to avoid unexpected workflow changes.

🧰 Tools
🪛 zizmor (1.26.1)

[warning] 13-15: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 13-13: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 18-18: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/ci.yml around lines 13 - 18, The workflow still uses
mutable GitHub Actions tags, so update the actions in ci.yml to immutable commit
SHAs instead of version tags. Replace the usages of actions/checkout,
actions/setup-python, and actions/setup-node in the CI job with their full
pinned SHAs, keeping the same step structure while ensuring each action
reference is fixed to a specific commit.

Source: Linters/SAST tools

with:
python-version: '3.12'
cache: 'pip'

- name: Install uv
run: curl -LsSf https://astral.sh/uv/install.sh | sh

- name: Install dependencies
run: |
$HOME/.local/bin/uv venv
$HOME/.local/bin/uv pip install -e ".[dev]"

- name: Run Python tests
run: $HOME/.local/bin/uv run pytest tests/

- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '22'

- name: Install Frontend dependencies
run: cd web && npm install

- name: Run Frontend tests
run: cd web && npm run build
Comment on lines +42 to +43

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: Step name suggests tests, but the command only performs a build.

This step is named Run Frontend tests but only runs npm run build, which is usually a production build, not tests. If you have a separate test command (e.g., npm test), either run that here or rename the step to accurately reflect that it’s just building.

31 changes: 31 additions & 0 deletions .github/workflows/greetings.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
name: Greetings

on:
issues:
types: [opened]
pull_request:
types: [opened]

jobs:
welcome:
runs-on: ubuntu-latest
steps:
- uses: actions/github-script@v6

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== File list =="
git ls-files .github/workflows/greetings.yml

echo
echo "== greetings.yml with line numbers =="
cat -n .github/workflows/greetings.yml

echo
echo "== Search for github-script usage =="
rg -n "actions/github-script@" .github/workflows . || true

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 1741


🌐 Web query:

actions/github-script v6 current supported release GitHub Actions pin full commit SHA documentation

💡 Result:

As of June 29, 2026, actions/github-script v6 is a legacy version [1]. The latest release is v9.0.0 [1][2]. While v6 remains accessible in the GitHub Marketplace, it is no longer actively maintained [1][2]. Pinning to a full-length commit SHA is a recommended security practice for GitHub Actions [3][4]. It is the only way to ensure an action remains immutable, preventing risks associated with mutable tags (such as v6 or v9) which can be updated or deleted [3][5][6]. GitHub allows administrators to enforce this at the repository or organization level, causing workflows that use tags to fail [3][4][7]. To pin an action to a full-length commit SHA: 1. Identify the repository URL for the action, which for this project is github.com/actions/github-script [2][6]. 2. Locate the specific tag or release you wish to use (e.g., v6.4.1) within the repository's tags/releases [6]. 3. Find the full-length commit SHA associated with that specific tag [5][6]. 4. Update your workflow YAML to use the SHA instead of the tag: - uses: actions/github-script@<FULL_COMMIT_SHA_HERE> You can verify the SHA by checking the repository's commit history or viewing the Setup Job section of a previous workflow run log, which displays the exact SHA used for the action [6]. [3][5][4]

Citations:


Upgrade and pin actions/github-script. v6 is legacy; switch this workflow to the current supported major and pin it to a full commit SHA to avoid tag drift.

🧰 Tools
🪛 actionlint (1.7.12)

[error] 13-13: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🪛 zizmor (1.26.1)

[error] 13-13: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/greetings.yml at line 13, The workflow currently uses a
legacy actions/github-script major, so update the greeting workflow to the
currently supported major and pin it to a specific full commit SHA instead of a
moving tag. Make the change in the step that references actions/github-script so
the action version is both upgraded and immutable.

Source: Linters/SAST tools

with:
script: |
const isPR = !!context.payload.pull_request;
const user = context.payload.sender.login;
const authorAssociation = context.payload.issue?.author_association || context.payload.pull_request?.author_association;

if (authorAssociation === 'FIRST_TIMER' || authorAssociation === 'FIRST_TIME_CONTRIBUTOR') {
const body = isPR
? `Welcome @${user}! Thank you for your first pull request. A maintainer will review it shortly. Please ensure all tests pass and your code follows our contribution guidelines.`
: `Welcome @${user}! Thank you for opening your first issue. We will look into it as soon as possible.`;

github.rest.issues.createComment({
issue_number: context.issue.number || context.payload.pull_request.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: body
});
Comment on lines +9 to +30

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect the workflow file and nearby workflow patterns
git ls-files '.github/workflows/*' | sed -n '1,120p'
echo '--- greetings.yml ---'
cat -n .github/workflows/greetings.yml

echo '--- search for explicit permissions in workflows ---'
rg -n "permissions:|issues: write|pull-requests: write|contents: read" .github/workflows || true

echo '--- search for createComment usage ---'
rg -n "issues\.createComment|github\.rest\.issues\.createComment" . || true

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 2498


🌐 Web query:

GitHub Actions issues.createComment GITHUB_TOKEN permissions issues: write documentation

💡 Result:

To resolve permission issues when using issues.createComment in GitHub Actions, you must ensure the GITHUB_TOKEN is explicitly granted the necessary issues: write permission within your workflow file [1][2][3]. The GitHub Issues API—used for both issue and pull request comments—specifically requires the issues: write scope [3]. While some common issues might mistakenly suggest pull-requests: write, that permission is not sufficient for the issues.createComment endpoint [3]. How to fix: 1. Update your workflow YAML to include a permissions block at the job or workflow level [1][4][5]. yaml jobs: comment-job: runs-on: ubuntu-latest permissions: issues: write # Required for issues.createComment steps: - name: Create comment uses: actions/github-script@v7 with: script: | github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: 'Hello from GitHub Actions!' }) 2. Check repository settings: Ensure your repository allows GitHub Actions to write to the repository [5]. Navigate to Settings > Actions > General > Workflow permissions and ensure "Read and write permissions" is selected if you rely on default behavior [5]. Important Considerations: * Forked Repositories: If your workflow is triggered by a pull_request event from a forked repository, the GITHUB_TOKEN will be read-only by default, regardless of your permissions configuration [1][6][5]. This is a security restriction [5]. To work around this, you must use the pull_request_target trigger instead, which runs in the context of the base repository and has access to the repository's secrets and permissions [6][5]. Use pull_request_target with extreme caution, as it can be vulnerable to malicious code injection if not properly scoped [6][5]. * Least Privilege: It is a security best practice to grant only the specific permissions your workflow requires [4][7][8]. If you define a permissions block, it overrides default permissions, meaning you must explicitly include all permissions the job needs [5].

Citations:


Add issues: write to this job’s permissions. github.rest.issues.createComment() needs that scope, and relying on the repository default token settings is broader than necessary. If forked PRs are in scope, pull_request runs still get a read-only token, so they’ll need a different approach.

🧰 Tools
🪛 actionlint (1.7.12)

[error] 13-13: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🪛 zizmor (1.26.1)

[error] 13-13: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[info] 10-10: workflow or action definition without a name (anonymous-definition): this job

(anonymous-definition)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/greetings.yml around lines 9 - 30, The welcome job in
greetings.yml calls github.rest.issues.createComment(), but the workflow job
does not declare the required issues: write permission. Update the welcome job’s
permissions to grant only issues: write, and keep the script logic in the
github-script step unchanged; if this workflow must handle forked pull requests,
note that pull_request runs still receive a read-only token and will need a
different event or permission strategy.

Source: Linters/SAST tools

Comment on lines +25 to +30

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect the workflow file around the referenced lines.
git ls-files .github/workflows/greetings.yml
wc -l .github/workflows/greetings.yml
cat -n .github/workflows/greetings.yml | sed -n '1,120p'

# Also locate any related action/setup details in the workflow.
rg -n "createComment|await |return " .github/workflows/greetings.yml

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 1661


🌐 Web query:

actions/github-script await returned promise script finishes before request completes createComment not awaited

💡 Result:

In the context of the actions/github-script action, failing to await an asynchronous function—such as github.rest.issues.createComment—often causes the action to terminate before the request completes [1][2]. Because the script executes in a Node.js environment, the GitHub Actions runner completes the step as soon as the synchronous portion of your code finishes, ignoring any dangling, un-awaited promises [3][4]. To ensure your asynchronous operations (like creating a comment) complete successfully, you must explicitly use the await keyword for every asynchronous call [1][5][4]. Correct Usage Example: If you are using the github-script action, your script block should await the API call directly [2][6]: - uses: actions/github-script@v9 with: script: | await github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: 'Your comment body here' }) Key Considerations: 1. Top-Level Await: The script input is treated as the body of an async function. You can use await at the top level of your script, but you must ensure that all nested promises are also awaited [1][3]. 2. Separate Files: If you are requiring a separate JavaScript file, ensure that the exported function is marked as async and that you await the call to that function in your workflow YAML [1][7]. 3. Debugging: If your script terminates early or fails silently, verify that no promises are being "fire-and-forgotten." Wrapping code in a try/catch block can help surface errors that might otherwise be swallowed by an unhandled promise rejection [4].

Citations:


🌐 Web query:

GitHub Actions github-script script returns promise await behavior documentation

💡 Result:

The GitHub Actions github-script action is designed to execute the provided script input as the body of an asynchronous JavaScript function [1][2]. Because the code provided in the script input is effectively wrapped in an async function context, you can use the await keyword directly within your script to handle promises [1][3]. Key behaviors regarding promises and await: - Native support for async/await: Since the execution environment handles the script as an asynchronous function body, you do not need to wrap your code in an explicit async declaration to use await at the top level of your script block [1][4]. - External files: If you are running an async function imported from a separate file (e.g., using require), you must explicitly use the await keyword when calling that function within your github-script block to ensure the workflow waits for the promise to resolve [1][5]. - Promise chaining: You can use standard JavaScript Promise patterns, such as Promise.all, within your script, and you should await these calls if you need to ensure they complete before the action finishes [1]. In summary, the github-script action natively supports and encourages the use of await for any asynchronous operations, including GitHub API requests via the provided github client or other asynchronous utilities like exec [1][3]. Failure to await a promise will result in the promise being left unhandled, which may cause the action to complete before your asynchronous operations finish [1].

Citations:


Await the comment request. github.rest.issues.createComment(...) returns a promise, and this actions/github-script step can finish before the comment is sent unless it’s awaited.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/greetings.yml around lines 25 - 30, The comment posting in
the github-script step is not awaited, so the workflow can finish before the
issue comment is actually created. Update the createComment call in the
greetings workflow to be awaited and keep the logic in the same step so the
promise resolves before the action exits. Use the
github.rest.issues.createComment invocation as the target for the fix.

}
35 changes: 35 additions & 0 deletions .github/workflows/pages.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
name: Deploy documentation to GitHub Pages

on:
push:
branches: ["main"]

workflow_dispatch:
Comment on lines +3 to +7

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

This workflow deploys stale docs instead of the generated ones.

actions/upload-pages-artifact is publishing ./docs from the checked-out commit, but .github/workflows/repo-maintenance.yml is what generates docs/index.md and docs/knowledge_graph.json in a separate workflow. Every source push can therefore deploy stale content until the maintenance bot commit retriggers Pages, and a failed auto-commit leaves Pages permanently behind. Generate the docs in this workflow, or trigger Pages from the maintenance workflow/artifacts instead.

Also applies to: 29-35

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/pages.yml around lines 3 - 7, The Pages workflow is
uploading the checked-out ./docs directory instead of the freshly generated
docs, so update the deployment flow around the Pages job in pages.yml to use
generated artifacts rather than stale source files. Either add the docs
generation step to this workflow before the upload, or change the Pages publish
inputs to consume the output from repo-maintenance.yml; reference the workflow
jobs that use actions/upload-pages-artifact and any docs generation step so the
deployment always reflects the latest generated docs.


permissions:
contents: read
pages: write
id-token: write

concurrency:
group: "pages"
cancel-in-progress: false

jobs:
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Pages
uses: actions/configure-pages@v5
- name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path: './docs'
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
Comment on lines +26 to +35

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf 'Repository root: '; pwd

echo
echo '--- pages workflow ---'
nl -ba .github/workflows/pages.yml | sed -n '1,120p'

echo
echo '--- workflow action refs used in repository ---'
rg -n "actions/(checkout|configure-pages|upload-pages-artifact|deploy-pages)@" .github/workflows .github -g '*.yml' -g '*.yaml' || true

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 263


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo '--- pages workflow ---'
cat -n .github/workflows/pages.yml | sed -n '1,120p'

echo
echo '--- all workflow action refs in .github/workflows ---'
grep -RInE "uses: actions/(checkout|configure-pages|upload-pages-artifact|deploy-pages)@" .github/workflows || true

echo
echo '--- any SHA-pinned action refs in workflows ---'
grep -RInE "uses: .+@[0-9a-f]{40}" .github/workflows || true

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 2148


Pin the Pages actions to immutable SHAs. These deployment steps still use moving tags (@v4, @v5, @v3, @v4); pin them to full commit SHAs to reduce supply-chain risk.

🧰 Tools
🪛 zizmor (1.26.1)

[error] 26-26: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 28-28: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 30-30: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 35-35: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/pages.yml around lines 26 - 35, The GitHub Pages workflow
still references moving action tags in the
checkout/configure-pages/upload-pages-artifact/deploy-pages steps, so update
those action references to immutable full commit SHAs. Keep the same jobs and
step names, but replace the version tags on actions/checkout,
actions/configure-pages, actions/upload-pages-artifact, and actions/deploy-pages
with pinned SHAs so the workflow remains stable and safer.

Source: Linters/SAST tools

56 changes: 56 additions & 0 deletions .github/workflows/repo-maintenance.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
name: Repository Maintenance

on:
push:
branches: [ "main", "master" ]
pull_request:
branches: [ "main", "master" ]

permissions:
contents: write
Comment on lines +3 to +10

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🔴 Critical | 🏗️ Heavy lift

Do not run this write-enabled maintenance job on pull_request.

For same-repo PRs, this workflow checks out the PR head, executes repository-controlled Python/tooling steps, and then pushes with contents: write. That creates a privilege-escalation path from unreviewed branch code to repository writes. Split this into a read-only PR validation job and a separate write-enabled job that runs only on trusted push events.

Also applies to: 16-18, 32-56

🧰 Tools
🪛 YAMLlint (1.37.1)

[warning] 3-3: truthy value should be one of [false, true]

(truthy)


[error] 5-5: too many spaces inside brackets

(brackets)


[error] 5-5: too many spaces inside brackets

(brackets)


[error] 7-7: too many spaces inside brackets

(brackets)


[error] 7-7: too many spaces inside brackets

(brackets)

🪛 zizmor (1.26.1)

[error] 10-10: overly broad permissions (excessive-permissions): contents: write is overly broad at the workflow level

(excessive-permissions)


[warning] 10-10: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment

(undocumented-permissions)


[warning] 3-7: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting

(concurrency-limits)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/repo-maintenance.yml around lines 3 - 10, The maintenance
workflow is currently triggered on pull_request with contents: write, which
allows unreviewed PR code to run before a write-enabled push step. Update the
repo-maintenance workflow so the job that uses checkout and
repository-controlled tooling runs only on trusted push events, and separate any
PR validation into a read-only path. Keep the push-based maintenance logic in
the workflow jobs that invoke the checkout/tooling steps and the write-back
action, and remove pull_request from the trigger for the write-enabled path.


jobs:
maintenance:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.head_ref || github.ref }}
lfs: true

- name: Set up Python
uses: actions/setup-python@v5
Comment on lines +16 to +22

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "=== .github/workflows/repo-maintenance.yml ==="
wc -l .github/workflows/repo-maintenance.yml
cat -n .github/workflows/repo-maintenance.yml | sed -n '1,220p'

echo
echo "=== search permissions/triggers in .github/workflows/repo-maintenance.yml ==="
rg -n "permissions:|pull_request_target|workflow_dispatch|repository_dispatch|write|checkout@|setup-python@" .github/workflows/repo-maintenance.yml

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 2308


Pin the GitHub Actions to commit SHAs. .github/workflows/repo-maintenance.yml:16-22 has contents: write and can push back to the repo, so actions/checkout@v4 and actions/setup-python@v5 should be replaced with immutable SHAs before merge.

🧰 Tools
🪛 zizmor (1.26.1)

[warning] 16-19: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)


[error] 16-16: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[error] 22-22: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/repo-maintenance.yml around lines 16 - 22, The
repo-maintenance workflow uses mutable GitHub Actions tags for steps that can
write back to the repository, so replace the `actions/checkout` and
`actions/setup-python` versions in the workflow with pinned commit SHAs. Update
the existing checkout and Python setup steps in
`.github/workflows/repo-maintenance.yml` to use immutable references instead of
`@v4` and `@v5`, keeping the same step names and inputs.

Source: Linters/SAST tools

with:
python-version: '3.12'

- name: Install dependencies
run: |
curl -LsSf https://astral.sh/uv/install.sh | sh
$HOME/.local/bin/uv venv
$HOME/.local/bin/uv pip install --system pydeps xdg-utils cyclonedx-bom ruff

- name: Run Ruff autofix
run: $HOME/.local/bin/uv run ruff check --fix . || true

- name: Generate Knowledge Graph
run: python tools/generate_knowledge_graph.py

- name: Sync Docs
run: python tools/docs_sync.py

- name: Generate Architecture Diagram
run: pydeps . -o docs/arch.svg || true

- name: Generate SBOM
run: |
$HOME/.local/bin/uv venv
$HOME/.local/bin/uv pip install -e ".[dev]"
$HOME/.local/bin/uv run cyclonedx-py environment -o bom.json || true

- name: Commit changes
run: |
git config --local user.email "action@github.com"
git config --local user.name "GitHub Action"
git add docs/ bom.json || true
git commit -m "Auto-generated repository artifacts" || true
git push || true
20 changes: 20 additions & 0 deletions .github/workflows/stale.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
name: Manage Stale Issues

on:
schedule:
- cron: "0 0 * * *"

permissions:
issues: write
pull-requests: write
Comment on lines +7 to +9

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

git ls-files .github/workflows/stale.yml
echo "---"
cat -n .github/workflows/stale.yml

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 1021


Scope the write permissions to jobs.stale.
That keeps the issues/pull-requests grants limited to the stale action instead of inheriting them across any future jobs in this workflow.

🧰 Tools
🪛 zizmor (1.26.1)

[error] 8-8: overly broad permissions (excessive-permissions): issues: write is overly broad at the workflow level

(excessive-permissions)


[error] 9-9: overly broad permissions (excessive-permissions): pull-requests: write is overly broad at the workflow level

(excessive-permissions)


[warning] 8-8: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment

(undocumented-permissions)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/stale.yml around lines 7 - 9, The workflow grants write
permissions at the top level, which makes them apply to every job in the file.
Move the `issues` and `pull-requests` write permissions into the `jobs.stale`
job instead, keeping the scope limited to the stale action and preventing future
jobs from inheriting them.

Source: Linters/SAST tools


jobs:
stale:
runs-on: ubuntu-latest
steps:
- uses: actions/stale@v8
with:
stale-issue-message: 'This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.'
stale-pr-message: 'This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.'
days-before-stale: 60
days-before-close: 7
Comment on lines +3 to +20

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Add concurrency to this scheduled mutating workflow.

Without a concurrency group, a delayed daily run can overlap with the next one and double-post stale comments or race close operations.

Suggested change
 on:
   schedule:
     - cron: "0 0 * * *"

+concurrency:
+  group: stale-${{ github.workflow }}
+  cancel-in-progress: true
+
 jobs:
   stale:
📝 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.

Suggested change
on:
schedule:
- cron: "0 0 * * *"
permissions:
issues: write
pull-requests: write
jobs:
stale:
runs-on: ubuntu-latest
steps:
- uses: actions/stale@v8
with:
stale-issue-message: 'This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.'
stale-pr-message: 'This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.'
days-before-stale: 60
days-before-close: 7
on:
schedule:
- cron: "0 0 * * *"
concurrency:
group: stale-${{ github.workflow }}
cancel-in-progress: true
permissions:
issues: write
pull-requests: write
jobs:
stale:
runs-on: ubuntu-latest
steps:
- uses: actions/stale@v8
with:
stale-issue-message: 'This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.'
stale-pr-message: 'This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.'
days-before-stale: 60
days-before-close: 7
🧰 Tools
🪛 actionlint (1.7.12)

[error] 15-15: the runner of "actions/stale@v8" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🪛 zizmor (1.26.1)

[error] 8-8: overly broad permissions (excessive-permissions): issues: write is overly broad at the workflow level

(excessive-permissions)


[error] 9-9: overly broad permissions (excessive-permissions): pull-requests: write is overly broad at the workflow level

(excessive-permissions)


[error] 15-15: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)


[warning] 8-8: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment

(undocumented-permissions)


[info] 12-12: workflow or action definition without a name (anonymous-definition): this job

(anonymous-definition)


[warning] 3-5: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting

(concurrency-limits)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/stale.yml around lines 3 - 20, The scheduled stale
workflow is mutating and currently has no concurrency control, so overlapping
runs can duplicate comments or race closures. Add a concurrency group to the
workflow in the stale job configuration so only one run of the scheduled
workflow proceeds at a time, and make sure the group is unique to this workflow
(using the workflow name or similar identifier) with in-progress cancellation
enabled.

Source: Linters/SAST tools

Comment on lines +15 to +20

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf 'stale workflow:\n'
cat -n .github/workflows/stale.yml

printf '\nother workflow uses:\n'
rg -n "actions/stale@|uses: .*`@v`[0-9]+|uses: .*@[0-9a-f]{7,40}" .github/workflows -S

Repository: NITISH-R-G/ev-grid-oracle

Length of output: 2889


🌐 Web query:

actions/stale v8 supported release current version runner compatibility pin commit sha

💡 Result:

As of June 2026, the current version of the actions/stale GitHub Action is v10.2.0 [1][2]. Runner Compatibility: Starting with version v10.0.0, the action requires the GitHub runner to be on version v2.327.1 or later due to an upgrade to Node 24 [3][1][4]. Pinning to a Commit SHA: To enhance supply-chain security and prevent tag-retargeting risks, it is recommended to pin the action to a specific immutable commit SHA instead of using a floating tag (e.g., @v10) [5][6][7]. You can implement this by replacing the tag with the full-length commit SHA in your workflow YAML file [5][8]. For maintainability, it is best practice to include the original version tag as a trailing comment [5][7]. Example configuration: - uses: actions/stale@b5d41d4 # v10.2.0 To find the correct SHA for a specific release, visit the official actions/stale repository on GitHub, navigate to the "Tags" or "Releases" section, and copy the full-length SHA associated with the desired version [8].

Citations:


🌐 Web query:

actions/stale v8 node version runner compatibility release notes

💡 Result:

The actions/stale GitHub Action upgraded its runtime to Node.js 24 in version 10.0.0 [1]. To ensure compatibility with this release, your GitHub runner must be version v2.327.1 or later [2][1]. Key context regarding this upgrade: - Version 10.0.0: Released on September 4, 2025, this version shifted the action's runtime from Node.js 20 to Node.js 24 [1]. - Runner Requirement: Because Node.js 24 support requires specific runner capabilities, users must ensure their runners are updated to at least version v2.327.1 [2][1]. - Historical Context: Prior to this, version 9.0.0 (released December 2023) had upgraded the action to use Node.js 20, replacing Node.js 16 [3]. For GitHub Actions users, please note that GitHub has initiated the migration of all actions to run on Node.js 24, with runners beginning to use Node.js 24 as the default starting in mid-2026 [4]. Ensure your workflow references the latest version of actions/stale (v10 or later) to maintain compatibility with these platform-wide changes [2][5][1].

Citations:


🌐 Web query:

site:github.com/actions/stale v8.0.0 node16 node20 runner compatibility

💡 Result:

The version v8.0.0 typically refers to a release of the actions/stale GitHub action [1][2]. Regarding Node.js compatibility and runner requirements for this specific version: 1. Node.js Compatibility: Version 8.0.0 of actions/stale was designed to run on Node.js 16 [3]. The transition to Node.js 20 was a primary feature of the subsequent major release, version 9.0.0 [2][4]. 2. Runner Compatibility: GitHub Actions runners generally support actions configured for Node.js 16. However, since Node.js 16 has reached its end-of-life, GitHub has been migrating its actions and runner environments to newer Node.js versions (specifically Node.js 20 and later) [5]. If you are currently using actions/stale v8.0.0, it is recommended to upgrade to a newer version (such as v9.0.0 or later) to utilize the Node.js 20 runtime and ensure continued compatibility with modern GitHub Actions runner environments [5][2]. There are no specific "v8.0.0" restrictions against Node.js 20 runners, but the action itself was built and tested against the Node.js 16 environment [3].

Citations:


Pin actions/stale to a full SHA. actions/stale@v8 is a mutable tag, and it’s behind the current release line, so this workflow can drift on upstream changes.

🧰 Tools
🪛 actionlint (1.7.12)

[error] 15-15: the runner of "actions/stale@v8" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🪛 zizmor (1.26.1)

[error] 15-15: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/stale.yml around lines 15 - 20, The stale workflow uses
the mutable actions/stale@v8 tag, so update the action reference in the stale
job to a pinned full commit SHA instead of the tag. Keep the existing
stale-issue-message, stale-pr-message, days-before-stale, and days-before-close
settings unchanged, and adjust only the actions/stale step to use the immutable
SHA.

Source: Linters/SAST tools

27 changes: 27 additions & 0 deletions CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# Code of Conduct

## Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

## Our Standards

Examples of behavior that contributes to creating a positive environment include:

* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident.
Comment on lines +25 to +27

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add a reporting contact method to the Enforcement section.

The Enforcement section directs people to contact "the project team" but provides no email, form, or other route. Add a dedicated email or link to a reporting form so the CoC is enforceable in practice.

🧰 Tools
🪛 LanguageTool

[style] ~27-~27: ‘with regard to’ might be wordy. Consider a shorter alternative.
Context: ...s obligated to maintain confidentiality with regard to the reporter of an incident.

(EN_WORDINESS_PREMIUM_WITH_REGARD_TO)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@CODE_OF_CONDUCT.md` around lines 25 - 27, The Enforcement section in
CODE_OF_CONDUCT.md currently mentions contacting “the project team” without a
concrete reporting path; update that section to include a specific reporting
contact such as a dedicated email address or reporting form link so incidents
can be submitted directly. Keep the change localized to the Enforcement text and
make sure the new contact method is clearly identified alongside the existing
confidentiality language.

25 changes: 25 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Contributing

First off, thank you for considering contributing to this project. It's people like you that make open source such a great community.

## Where do I go from here?

If you've noticed a bug or have a feature request, make sure to check our Issues to see if someone else in the community has already created a ticket. If not, go ahead and make one!

## Fork & create a branch

If this is something you think you can fix, then fork the repository and create a branch with a descriptive name.

## Implement your fix or feature

At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first.

## Make a Pull Request

At this point, you should switch back to your master branch and make sure it's up to date with the main project's master branch.
Then run `uv run pytest tests/` and `cd web && npm test` to ensure tests are passing.
Once tests pass, open a Pull Request.
Comment on lines +17 to +21

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Replace "master" with "main" for default branch terminology.

Line 19 refers to "your master branch" and "master branch" of the main project. The PR objectives and modern GitHub defaults use main. Update to avoid confusion.

📝 Proposed fix
-At this point, you should switch back to your master branch and make sure it's up to date with the main project's master branch.
+At this point, you should switch back to your main branch and make sure it's up to date with the main project's main branch.
📝 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.

Suggested change
## Make a Pull Request
At this point, you should switch back to your master branch and make sure it's up to date with the main project's master branch.
Then run `uv run pytest tests/` and `cd web && npm test` to ensure tests are passing.
Once tests pass, open a Pull Request.
## Make a Pull Request
At this point, you should switch back to your main branch and make sure it's up to date with the main project's main branch.
Then run `uv run pytest tests/` and `cd web && npm test` to ensure tests are passing.
Once tests pass, open a Pull Request.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@CONTRIBUTING.md` around lines 17 - 21, Update the branch terminology in the
Pull Request instructions to use main instead of master. In the “Make a Pull
Request” section, revise the wording around the default branch reference so both
mentions in that paragraph consistently refer to main; this change is isolated
to the CONTRIBUTING.md guidance text and should preserve the rest of the
instructions unchanged.


## Keeping your Pull Request updated

If a maintainer asks you to rebase your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.
26 changes: 26 additions & 0 deletions tools/docs_sync.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
import os


def sync_docs(docs_dir="docs"):
index_path = os.path.join(docs_dir, "index.md")

markdown_files = []
for root, _, files in os.walk(docs_dir):
for file in files:
if file.endswith(".md") and file != "index.md":
rel_path = os.path.relpath(os.path.join(root, file), docs_dir)
markdown_files.append(rel_path)

markdown_files.sort()

os.makedirs(docs_dir, exist_ok=True)
with open(index_path, "w", encoding="utf-8") as f:
f.write("# Documentation Index\n\n")
f.write("This index is automatically generated.\n\n")
for file in markdown_files:
title = file.replace(".md", "").replace("_", " ").title()
f.write(f"* [{title}]({file})\n")


if __name__ == "__main__":
sync_docs()
Comment thread
coderabbitai[bot] marked this conversation as resolved.
Loading
Loading