ci: complete CI/CD pipeline, Dependabot, and repository automation

[Kuldeep2822k]

Summary of CI/CD & Repository Automation

This PR sets up full GitHub Actions CI/CD workflows, Dependabot automation, PR linting, PR templates, and npm package distribution optimizations for the PALEE project.

📄 Workflows & Configs Included:

1. .github/workflows/ci.yml (Continuous Integration):

   • Quality Check: Linting, npx tsc --noEmit (strict type check), and production build validation (npm run build).
   • Multi-OS Test Matrix: Matrix across [ubuntu-latest, windows-latest, macos-latest] x Node [20.x, 22.x].
   • Security Audit: Dependency vulnerability scan (npm audit) and native module verification (npm ls check ensuring zero node-gyp C/C++ dependencies).
   • Global Binary Smoke Test: npm install -g . testing palee --version & palee --help execution on Ubuntu and Windows.

2. .github/workflows/release.yml (Continuous Delivery):

   • Triggers automatically on Git release tags (v*..).
   • Publishes to npm with NPM Build Provenance Attestation (npm publish --provenance).
   • Automatically creates GitHub Releases with release notes.

3. .github/dependabot.yml (Dependabot Automation):

   • Configured weekly automated updates for both npm dependencies (grouped devDependencies) and github-actions.

4. .github/workflows/pr-sanitizer.yml & .github/PULL_REQUEST_TEMPLATE.md (PR Hygiene):

   • Enforces Conventional Commits title formatting (feat:, fix:, docs:, refactor:, ci:).
   • Standardized PR checklist template.

5. .npmignore (Package Optimization):

   • Scopes published package to dist/, bin/, package.json, and docs.
   • Reduced npm package tarball size by 70% (from 104.0 kB down to 32.5 kB).

[Kuldeep2822k]

/qodo review

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[coderabbitai]

Warning

Review limit reached

@Kuldeep2822k, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 13 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Free

Run ID: 7eed4d24-a408-4379-9cd5-edaa4c399f95

📥 Commits

Reviewing files that changed from the base of the PR and between 3996114 and 9b7298e.

📒 Files selected for processing (8)

• .c8rc.json
• .github/workflows/ci.yml
• .github/workflows/release.yml
• .github/workflows/security.yml
• scripts/verify-tarball.js
• src/cli/roadmap.ts
• src/storage/atomic-write.ts
• src/storage/lock.ts

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes

  • Improved roadmap imports by preventing unsafe paths, symlink-based access, and writes outside the vault.
  • Strengthened storage-lock handling to detect conflicts and recover from stale locks across platforms.
  • CLI now displays help when run without arguments and handles command errors more reliably.

• Release Improvements

  • Added automated validation, security checks, packaging, publishing, and cross-platform smoke tests.
  • Updated supported runtime requirements to Node.js 22 or newer.

• Project Maintenance

  • Added contribution guidelines, dependency automation, pull request validation, and expanded coverage.
  • Streamlined published packages and added an MIT license.

Walkthrough

The pull request adds CI, security, dependency, pull request, and release automation. It adds package validation and npm package boundaries. It updates CLI execution, engine exports, atomic writes, lock handling, vault traversal, and roadmap path handling.

Changes

Repository and package automation

Layer / File(s)	Summary
Project checks and package boundaries .github/PULL_REQUEST_TEMPLATE.md, .c8rc.json, eslint.config.mjs, .npmignore, LICENSE, package.json, scripts/verify-tarball.js	Project scripts, linting, coverage thresholds, Node.js requirements, package exclusions, license terms, and tarball validation are added.
Continuous integration and security checks .github/workflows/ci.yml, .github/workflows/security.yml	Workflows run quality checks, matrix tests, coverage enforcement, package smoke tests, CodeQL, dependency audits, native-module checks, license audits, and aggregate status validation.
Release verification and publication .github/workflows/release.yml	Releases validate versions, verify tarballs, publish idempotently, create GitHub releases, and test Windows installation.
Dependency and pull request governance .github/dependabot.yml, .github/workflows/pr-sanitizer.yml	Dependabot schedules grouped updates. The pull request workflow validates Conventional Commit titles.
CI/CD architecture documentation planning/cicd_dependency_management_proposal.md, full_diff.txt	The proposal documents workflow responsibilities, coverage, package verification, security audits, dependency governance, release handling, and rollout phases.

CLI, engine, and storage behavior

Layer / File(s)	Summary
CLI loading and execution flow bin/palee.ts, src/cli/*.ts	Commands use static configuration imports. Dashboard reads are sequential and tolerate per-file errors. No-argument invocation shows help, and command parsing reports asynchronous failures.
Engine API removal src/engine/dependency.ts, src/engine/index.ts, src/engine/mastery.ts, test/engine-dependency.test.ts, test/engine-mastery.test.ts	Topological sorting, dependency-satisfaction exports, and the mastery module and tests are removed.
Atomic write and lock storage behavior src/storage/atomic-write.ts, src/storage/lock.ts, src/types.ts	Atomic writes use an opened descriptor before syncing and renaming. Lock identities use canonical paths, lock metadata no longer includes heartbeat_at, and stale recovery handles recent empty directories and non-JSON entries.
Canonical roadmap import paths src/cli/roadmap.ts	Roadmap import awaits confirmation, canonicalizes target paths, rejects paths outside the vault, reads existing files through canonical targets, and writes atomically to those targets.
Storage and traversal validation test/storage-atomic-write.test.ts, test/storage-lock.test.ts, test/storage-walker.test.ts, src/storage/vault-walker.ts	Storage tests cover lock isolation, collisions, symlink identity, stale-lock timing, and lifecycle hooks. Vault traversal retains hidden-directory filtering while removing redundant named exclusions.

Estimated code review effort: 5 (Critical) | ~120 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Tag as Version tag
  participant Verify as Verification job
  participant Registry as npm registry
  participant Release as GitHub release
  participant Smoke as Windows smoke test
  Tag->>Verify: Run checks and verify tarball
  Verify->>Registry: Publish verified tarball
  Verify->>Release: Attach tarball and generated notes
  Registry->>Smoke: Provide published package
  Smoke->>Registry: Retry global installation
  Smoke->>Smoke: Verify version and help output

Loading

Poem

A rabbit checks the workflow lane,
With tiny paws on every train.
Paths resolve and locks behave,
Packages hop from build to pave.
“Ship it clean!” the bunny sings,
Beneath the green CI rings.

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login.

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

review

I found a few CI/CD concerns worth addressing:

• Security audit is non-blocking: npm audit --audit-level=high --ignore-dev || true always succeeds, so high-severity vulnerabilities will not fail the workflow. If this is intentional, consider reporting the result explicitly; otherwise remove || true and use the supported production-only form, typically npm audit --omit=dev --audit-level=high.
• Native dependency check is incomplete: searching only for node-gyp does not prove that the tree contains no native modules. Packages can use prebuilds, bindings, node-pre-gyp, or other native toolchains. Prefer checking the dependency tree against an explicit allow/deny policy or documenting this as a heuristic.
• Release trigger is broad: every pushed tag matching v*.*.* publishes to npm and creates a non-draft GitHub release. Protect tag creation and ensure release permissions/branch policies prevent accidental publication.
• Release verification does not verify the exact artifact: the package is checked with npm pack --dry-run, then rebuilt independently before publishing. Building once, inspecting the resulting tarball, and publishing that verified artifact would reduce drift.
• Workflow actions are tag-pinned rather than commit-pinned: actions/checkout, setup-node, and third-party release/PR-title actions can change under mutable tags. Commit pinning is preferable for a hardened release pipeline.

The template and Dependabot additions otherwise look straightforward, and the cross-platform test matrix is a useful addition.

[qodo-code-review]

PR Summary by Qodo

CI/CD: add GitHub Actions CI + npm release pipeline, Dependabot, and PR hygiene

⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Add GitHub Actions CI with lint/typecheck/build, cross-OS test matrix, security audit, and CLI
 smoke tests.
• Add tag-driven CD workflow to verify, publish to npm with provenance, and create GitHub Releases.
• Add Dependabot updates plus PR title linting and a standardized PR template.

Diagram

graph TD
  PR(("Push / PR")) --> CI["CI workflow"] --> Checks["Checks: build/test/audit"]
  PR --> PRLint["PR title lint"]
  Tag(("Tag push vX.Y.Z")) --> Release["Release workflow"] --> Publish["npm publish (provenance)"] --> NPM[("npm Registry")]
  Release --> GHRel["GitHub Release"]
  Dep(("Dependabot")) --> DepPRs["Dependency PRs"]

  subgraph Legend
    direction LR
    _evt(("Event")) ~~~ _wf["Workflow/Job"] ~~~ _db[("Registry")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Adopt Changesets or release-please for versioning/release automation

• ➕ Automates changelog + version bump PRs and tag creation
• ➕ Reduces manual tagging errors and standardizes releases
• ➖ Adds tooling/process overhead
• ➖ May be unnecessary if releases are infrequent or manual tagging is acceptable

2. Use a reusable workflow/composite action for Node CI

• ➕ Keeps CI logic DRY across repos or future workflows
• ➕ Easier to update Node setup/install steps consistently
• ➖ Extra indirection can make debugging harder
• ➖ Not valuable unless you expect multiple repos or many workflows

3. Replace custom native-module check with a dedicated action/scripted allowlist

• ➕ More reliable than grepping npm output; can explicitly detect native addons (node-pre-gyp/node-gyp-build)
• ➕ Easier to tune false positives/negatives
• ➖ More maintenance and/or additional dependency/action
• ➖ Current check may be sufficient for this repo’s dependency profile

Recommendation: The PR’s approach is solid for a single-repo Node CLI: separate CI vs release workflows, explicit permissions for provenance, and cross-OS smoke testing cover the highest-risk areas. If releases become frequent or you want fully automated versioning, consider moving to Changesets/release-please later; otherwise keep the current tag-driven CD and ensure required secrets (NPM_TOKEN) and branch protections are configured to match the workflow expectations.

Files changed (6) +296 / -0

Documentation (1) +18 / -0

PULL_REQUEST_TEMPLATE.mdAdd standardized PR template and contributor checklist +18/-0

Add standardized PR template and contributor checklist

• Introduces a PR template with a description section, change-type checklist, and compilation/test/package sanity checks to standardize submissions.

.github/PULL_REQUEST_TEMPLATE.md

Other (5) +278 / -0

dependabot.ymlConfigure weekly Dependabot updates for npm and GitHub Actions +35/-0

Configure weekly Dependabot updates for npm and GitHub Actions

• Adds Dependabot configuration to open weekly update PRs for npm dependencies (grouped devDependencies) and GitHub Actions, with labeling and PR limits.

.github/dependabot.yml

ci.ymlAdd CI workflow with quality gates, test matrix, security checks, and CLI smoke tests +112/-0

Add CI workflow with quality gates, test matrix, security checks, and CLI smoke tests

• Adds a CI workflow triggered on PRs and main pushes with separate jobs for typecheck/build, multi-OS + multi-Node test matrix, dependency audit + native-module check, and global-install CLI smoke tests.

.github/workflows/ci.yml

pr-sanitizer.ymlEnforce Conventional Commits PR titles via semantic pull request action +33/-0

Enforce Conventional Commits PR titles via semantic pull request action

• Adds a PR hygiene workflow that validates PR titles against a Conventional Commits type allowlist on PR open/edit/sync events.

.github/workflows/pr-sanitizer.yml

release.ymlAdd tag-triggered release pipeline to publish to npm and create GitHub Releases +80/-0

Add tag-triggered release pipeline to publish to npm and create GitHub Releases

• Adds a CD workflow triggered by version tags that verifies build/tests/packaging, publishes to npm with provenance using OIDC, and creates a GitHub Release with generated notes.

.github/workflows/release.yml

.npmignoreRestrict npm package contents to compiled output and required artifacts +18/-0

Restrict npm package contents to compiled output and required artifacts

• Adds npm ignore rules to exclude source, tests, repo metadata, and local tooling/config files from the published package tarball.

.npmignore

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. Smoke test skips build ✓ Resolved 🐞 Bug ≡ Correctness

Description

The smoke-install job installs the CLI globally without building, but the published bin points
to dist/ output, so palee --version/--help will fail when dist/ isn’t present. Each GitHub
Actions job runs in an isolated workspace, so the build artifacts from quality-check are not
available here.

Code

.github/workflows/ci.yml[R105-110]

+      - name: Install CLI globally from source
+        run: npm install -g .
+
+      - name: Test global binary --version
+        run: palee --version
+

Evidence

The workflow installs globally from source and runs palee, but the package’s bin is configured
to execute a file under dist/, which is only created by npm run build and is not produced in the
smoke job.

.github/workflows/ci.yml[88-112]
package.json[5-13]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The smoke test installs from the repo (`npm install -g .`) and immediately executes `palee`, but the package’s `bin` entry points to `./dist/bin/palee.js`. Since the job never runs `npm run build` (and there is no lifecycle script like `prepare`/`postinstall` to build automatically), the global binary points to a file that does not exist.

## Issue Context
- `package.json` defines `bin.palee` as `./dist/bin/palee.js`.
- `dist/` is generated by the `build` script.
- GitHub Actions jobs do not share files unless you explicitly upload/download artifacts.

## Fix Focus Areas
- .github/workflows/ci.yml[105-112]
- package.json[7-13]

## Suggested fix
Choose one:
1) Add `npm ci` + `npm run build` before `npm install -g .`, then run the smoke commands.
2) Prefer testing the actual package artifact:
  - `npm ci`
  - `npm run build`
  - `npm pack`
  - `npm install -g ./palee-*.tgz`
3) Add a lifecycle script (e.g., `prepare` or `prepack`) that runs the build so local installs from source create `dist/` automatically (and keep the workflow as-is).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Audit check always passes ✓ Resolved 🐞 Bug ⛨ Security

Description

The security audit step uses an unsupported npm audit --ignore-dev flag and forces success with
|| true, so CI will not fail even when vulnerabilities exist or when the audit command errors.
This defeats the workflow’s “Security Audit” gate.

Code

.github/workflows/ci.yml[R76-78]

+      - name: Dependency vulnerability audit
+        run: npm audit --audit-level=high --ignore-dev || true
+

Evidence

The workflow explicitly appends || true, masking all non-zero outcomes. npm’s documented way to
omit dependency types is via --omit/shorthands (not --ignore-dev).

.github/workflows/ci.yml[60-87]
🌐 npm audit supports omitting dependency types via --omit and related shorthands (e.g., --production, --only=dev), not --ignore-dev.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`npm audit --audit-level=high --ignore-dev || true` is not an enforceable security gate:
- `|| true` forces a zero exit code even when vulnerabilities are found or the command fails.
- `--ignore-dev` is not the correct npm CLI option for excluding dev dependencies.

## Issue Context
If the intent is to audit all dependencies, run `npm audit --audit-level=high` and let the step fail.
If the intent is to omit dev dependencies, use npm’s omit flags (e.g., `--omit=dev`) and still let the step fail.

## Fix Focus Areas
- .github/workflows/ci.yml[76-78]

## Suggested fix
Replace with one of:
- `npm audit --audit-level=high`
- `npm audit --audit-level=high --omit=dev`
And remove `|| true` so the job fails on findings/errors.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Dependabot group mis-scoped ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The Dependabot group named dev-dependencies matches "*" but does not set dependency-type, so
it can group production dependency updates together with devDependencies. This reduces review
clarity by bundling runtime changes into large grouped PRs.

Code

.github/dependabot.yml[R17-23]

+    groups:
+      dev-dependencies:
+        patterns:
+          - "*"
+        update-types:
+          - "minor"
+          - "patch"

Evidence

The config uses a wildcard pattern without any dependency-type restriction, and GitHub docs show
dependency-type as the mechanism for scoping groups to development vs production dependencies.

.github/dependabot.yml[4-24]
🌐 Dependabot groups can be scoped using dependency-type (e.g., production/development) alongside patterns.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Dependabot group `dev-dependencies` currently matches all packages (`patterns: ['*']`) and does not restrict by dependency type, so it may include production dependencies despite the group name.

## Issue Context
GitHub’s Dependabot grouping supports scoping groups using `dependency-type: development` (or `production`).

## Fix Focus Areas
- .github/dependabot.yml[17-24]

## Suggested fix
Either:
- Add `dependency-type: "development"` under `dev-dependencies`, or
- Rename the group to reflect that it applies to all dependencies (and optionally create a separate group for production deps).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Actions not SHA pinned ✓ Resolved 🐞 Bug ⛨ Security

Description

Workflows reference actions by mutable tags (e.g., @v4, @v5, @v2) instead of full commit SHAs,
increasing supply-chain risk for CI/CD (especially the release workflow that publishes to npm and
creates releases). A compromised or retagged action version could execute attacker-controlled code
with your workflow permissions.

Code

.github/workflows/release.yml[R75-77]

+      - name: Create GitHub Release
+        uses: softprops/action-gh-release@v2
+        with:

Evidence

The new workflows use tag-based action references, and OWASP guidance recommends pinning actions to
commit hashes to mitigate action supply-chain risks from mutable tags.

.github/workflows/release.yml[72-80]
.github/workflows/ci.yml[16-21]
.github/workflows/pr-sanitizer.yml[14-19]
🌐 Recommends pinning actions/workflows to a commit hash to prevent dependency confusion and risks from mutable tags.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflows use version tags for actions (e.g., `actions/checkout@v4`, `softprops/action-gh-release@v2`). Tags are mutable; pinning to a full commit SHA reduces the blast radius of upstream action compromises and improves reproducibility.

## Issue Context
This is most critical in `release.yml`, which has permissions and steps that publish to npm and write GitHub releases.

## Fix Focus Areas
- .github/workflows/ci.yml[16-21]
- .github/workflows/ci.yml[45-53]
- .github/workflows/ci.yml[64-72]
- .github/workflows/ci.yml[96-103]
- .github/workflows/pr-sanitizer.yml[16-18]
- .github/workflows/release.yml[13-18]
- .github/workflows/release.yml[45-52]
- .github/workflows/release.yml[75-77]

## Suggested fix
For each `uses: owner/repo@tag`, replace with `uses: owner/repo@<full_commit_sha>`.
Optionally configure Dependabot for `github-actions` (already present) to keep SHA pins updated.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. PR title lint permissions ✓ Resolved 🐞 Bug ☼ Reliability

Description

The PR title lint job does not declare permissions: pull-requests: read, so it depends on
repository default GITHUB_TOKEN permissions and can fail in repos configured with restricted
defaults. This can cause the PR hygiene check to break or block merges when permissions are
tightened.

Code

.github/workflows/pr-sanitizer.yml[R12-20]

+  lint-pr-title:
+    name: Validate PR Title (Conventional Commits)
+    runs-on: ubuntu-latest
+    steps:
+      - name: Lint PR Title
+        uses: amannn/action-semantic-pull-request@v5
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:

Evidence

The workflow omits a permissions block, while the action’s own README example explicitly
configures pull-requests: read, indicating this is the expected minimum permission for reliable
operation under least-privilege settings.

.github/workflows/pr-sanitizer.yml[1-33]
🌐 README example includes permissions: pull-requests: read for validating PR titles.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR title lint workflow does not set explicit permissions for `GITHUB_TOKEN`. If the repo/org defaults are set to restricted permissions, the semantic PR title action may not be able to read PR metadata and can fail.

## Issue Context
The action’s documentation examples include `permissions: pull-requests: read`.

## Fix Focus Areas
- .github/workflows/pr-sanitizer.yml[1-20]

## Suggested fix
Add either at workflow level or job level:
```yml
permissions:
 pull-requests: read
```
(Optionally also add `contents: read` if you later add checkout/other steps.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context used

✅ Web pages:

  🌐 npm-audit | npm Docs

  🌐 Allow npm audit to ignore dev dependencies

  🌐 npm-audit | npm Docs

  +17 more

Review mode: ⚖️ Balanced: This adds multiple CI/CD workflows and release automation with security, permissions, publishing, and cross-platform behavior, creating substantial independent logic that warrants a complete single-pass review.

Tip of the day

💡 Did you know, you can reply 'qodo' on any finding to push back, ask questions, or dig deeper

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[Kuldeep2822k]

/qodo review

[qodo-code-review]

review

Review summary:

• One active issue remains: finding 3 — the Dependabot group is named dev-dependencies, but its patterns: ["*"] matches both production and development dependencies. Either rename the group to reflect all dependencies or narrow the patterns to the intended dev packages.
• The vault-boundary changes correctly resolve both the vault and candidate paths before comparison, preventing symlink escapes.
• The new lock-collision test validates immediate ECONFLICT behavior. The Windows stale-lock test is appropriately platform-gated, though it should ensure the original lock is released during cleanup if the test fails midway.
• CI now covers typechecking, builds, tests, audits, packaging, and cross-platform smoke installation. The previously identified CI findings are implemented.

Overall, the PR looks close to ready once finding 3 is addressed.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[Kuldeep2822k]

/qodo review

[qodo-code-review]

review

I found two issues worth fixing before merge:

• Lock conflict detection is swallowed: in src/storage/lock.ts, the new ECONFLICT is thrown inside a try whose catch {} immediately suppresses it. Consequently, the “incoming process” 5-second collision check never rejects, and stale-lock cleanup may proceed while another process is acquiring the lock. Catch only filesystem/stat errors, or move the conflict throw outside the catch.
• Vault-prefix validation is incomplete: src/cli/roadmap.ts uses canonicalDir.startsWith(resolvedVault). A vault such as /tmp/vault2 passes validation for /tmp/vault, despite being outside it. Require canonicalDir === resolvedVault or canonicalDir.startsWith(resolvedVault + path.sep).

I also recommend ensuring the file descriptor opened in atomic-write.ts is closed in a finally block if writeSync or fsyncSync fails; otherwise retries can leak descriptors and behave poorly on Windows.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[Kuldeep2822k]

/qodo review

[qodo-code-review]

review

I found two issues worth addressing before merge:

1. Release publishing is not actually using OIDC (.github/workflows/release.yml:81-115). The job grants id-token: write, but npm publish authenticates with secrets.NPM_TOKEN. This leaves the long-lived token in use and contradicts the PR’s Trusted Publishing design. Either configure npm trusted publishing and remove NODE_AUTH_TOKEN/NPM_TOKEN, or remove the OIDC claims and document the token-based model.

2. The native-module guard scans all dependencies, not only production dependencies (.github/workflows/security.yml:78-89). npm ls --omit=dev is used to identify packages, but findBinaries('node_modules') recursively scans dev dependencies too. A development tool containing a .dll, .exe, or .node file can fail the production guardrail. Restrict the filesystem scan to the production dependency tree, or explicitly separate production and development checks.

The rest of the reviewed changes are broadly consistent with the stated goals; the previously indexed Qodo findings are all implemented.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[Kuldeep2822k]

did review the diff as much as possible major changes introduced

• created all ci/cd also created it to handle till the version 2 as after that complete ci need a complete makeover
• imported a globle config the seep thing and better typesafe
• genrated the package file

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[Kuldeep2822k]

/qodo review

[qodo-code-review]

review

Review result

No new blocking issues identified in the supplied diff. The PR’s five Qodo findings are all marked implemented:

• finding 1: CI smoke test now builds before packaging.
• finding 2: audit failures are no longer masked.
• finding 3: Dependabot groups are scoped by dependency type.
• finding 4: release actions are pinned to commit SHAs.
• finding 5: PR-title lint declares pull-requests: read.

The remaining changes are primarily CLI config-loading cleanup, symlink-safe writes and lock identity handling, cross-platform tests, and CI/release hardening. Recommended validation before merge: run npm run check, npm run test:coverage, npm run build, and exercise the Windows smoke-test path.