chore(cleanup): remove OPENCODE.md and align repo conventions#101
chore(cleanup): remove OPENCODE.md and align repo conventions#101Steffen025 merged 2 commits intomainfrom
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThis PR migrates repository documentation and runtime paths from older Claude-oriented conventions to OpenCode/AGENTS conventions, removes the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (6)
PAI-Install/engine/steps-migrate.ts (1)
227-238:⚠️ Potential issue | 🔴 CriticalCritical: Shell marker pattern is inconsistent with other installer files.
The marker is now correctly named
# PAI shell setup(line 227), but the implementation writes an unbounded marker without the suffix or end marker (line 238). This creates a critical inconsistency:Current code writes:
# PAI shell setup alias pai='bun ...'Expected pattern (per actions.ts and steps-fresh.ts):
# PAI shell setup — added by PAI installer alias pai='bun ...' # end PAI shell setupImpact: The removal pattern in actions.ts (
/\n?# PAI shell setup — added by PAI installer[\s\S]*?# end PAI shell setup\n?/g) won't match what this migration step writes. Subsequent fresh installs or updates will fail to clean up the migration-written alias, causing duplicate aliases in the user's rc file.As per relevant code snippets from actions.ts:797-810 and steps-fresh.ts:430-445, all shell setup logic must use the same bounded-block pattern with explicit start and end markers.
🔧 Proposed fix to align with the bounded-block pattern
const marker = "# PAI shell setup"; +const endMarker = "# end PAI shell setup"; try { let content = ""; if (existsSync(rcPath)) { content = require("fs").readFileSync(rcPath, "utf-8"); - // Remove old PAI aliases + // Remove old PAI aliases (legacy formats) content = content.replace(/^#\s*(?:PAI|CORE)\s*alias.*\n.*alias pai=.*\n?/gm, ""); content = content.replace(/^alias pai=.*\n?/gm, ""); content = content.replace(/^alias pai\s+.*\n?/gm, ""); + // Remove installer-managed block if it exists + content = content.replace(/\n?# PAI shell setup — added by PAI installer[\s\S]*?# end PAI shell setup\n?/g, ""); } - content = content.trimEnd() + `\n\n${marker}\n${aliasLine}\n`; + content = content.trimEnd() + `\n\n${marker} — added by PAI installer\n${aliasLine}\n${endMarker}\n`; writeFileSync(rcPath, content); } catch (err) {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@PAI-Install/engine/steps-migrate.ts` around lines 227 - 238, The migration writes an unbounded marker ("# PAI shell setup") which doesn’t match the bounded block pattern used elsewhere; update the construction around the marker/aliasLine in steps-migrate.ts (the marker constant and the code that appends to content) so it emits the full bounded block exactly like actions.ts/steps-fresh.ts: use a start marker string " # PAI shell setup — added by PAI installer" followed by aliasLine and then an explicit end marker line "# end PAI shell setup" (ensure content uses trimEnd() + `\n\n${startMarker}\n${aliasLine}\n${endMarker}\n`), so the removal regex in actions.ts will match and clean the block..opencode/skills/Utilities/Parser/Workflows/BatchEntityExtractionGemini3.md (5)
571-579:⚠️ Potential issue | 🔴 CriticalCritical: Incorrect path in verification command.
Line 572 uses
~/.opencode/skills/parser/entity-index.jsonin the bash command. This path is incorrect and should be~/.opencode/skills/Utilities/Parser/entity-index.jsonto match the repository structure.🔧 Proposed fix for verification command
-cat ~/.opencode/skills/parser/entity-index.json | jq '{ +cat ~/.opencode/skills/Utilities/Parser/entity-index.json | jq '{🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.opencode/skills/Utilities/Parser/Workflows/BatchEntityExtractionGemini3.md around lines 571 - 579, The verification command is using the wrong path string "~/.opencode/skills/parser/entity-index.json"; update that path in the command block to "~/.opencode/skills/Utilities/Parser/entity-index.json" so the jq check reads the correct file (look for the literal path in the markdown block and replace it accordingly).
558-563:⚠️ Potential issue | 🔴 CriticalCritical: Incorrect output directory path.
Line 559 constructs the output filename using
~/.opencode/skills/parser/output/(lowercase 'parser'). This should be~/.opencode/skills/Utilities/Parser/output/to match the repository structure and ensure processed articles are saved to the correct location.🔧 Proposed fix to use correct output path
- const filename = `~/.opencode/skills/parser/output/${timestamp}_batch-${index + 1}.json`; + const filename = `${process.env.HOME}/.opencode/skills/Utilities/Parser/output/${timestamp}_batch-${index + 1}.json`;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.opencode/skills/Utilities/Parser/Workflows/BatchEntityExtractionGemini3.md around lines 558 - 563, The output path is wrong: update the filename construction where the const filename is defined (refer to the timestamp constant and the fs.writeFileSync call) to use the correct repository path "~/.opencode/skills/Utilities/Parser/output/" instead of "~/.opencode/skills/parser/output/"; ensure the rest of the filename logic (timestamp, `batch-${index + 1}.json`) and the subsequent fs.writeFileSync(filename, JSON.stringify(fullContent, null, 2)) and console.log(`Saved: ${filename}`) calls remain unchanged so files are written to the corrected directory.
69-79:⚠️ Potential issue | 🔴 CriticalCritical: Incorrect entity-index.json path in pre-flight check.
Line 73 uses
~/.opencode/skills/parser/entity-index.json(lowercase 'parser'), but the canonical path is~/.opencode/skills/Utilities/Parser/entity-index.json. This mismatch means the pre-flight check will either fail (file not found) or read from a stale/incorrect entity index, causing duplicate entity tracking.As per the relevant code snippet from
collision-detection.ts, the collision detection utility expects the entity index at.opencode/skills/Utilities/Parser/entity-index.json.🔧 Proposed fix to use correct path
const entityIndex = JSON.parse( - fs.readFileSync('~/.opencode/skills/parser/entity-index.json', 'utf-8') + fs.readFileSync(`${process.env.HOME}/.opencode/skills/Utilities/Parser/entity-index.json`, 'utf-8') );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.opencode/skills/Utilities/Parser/Workflows/BatchEntityExtractionGemini3.md around lines 69 - 79, The pre-flight check reads the wrong entity-index.json path; update the fs.readFileSync call that populates the entityIndex variable so it points to the canonical path used by collision-detection (replace '~/.opencode/skills/parser/entity-index.json' with '~/.opencode/skills/Utilities/Parser/entity-index.json'), ensuring isContentAlreadyParsed receives the correct index and preventing stale/missing file reads.
455-473:⚠️ Potential issue | 🔴 CriticalCritical: Incorrect entity-index.json path in main processing.
Line 456 hardcodes the entity index path as
~/.opencode/skills/parser/entity-index.json(lowercase 'parser'), which doesn't match the correct path structure~/.opencode/skills/Utilities/Parser/entity-index.json. This will cause the workflow to write the updated entity index to the wrong directory, creating data divergence between what this code writes and what the collision-detection utility reads.🔧 Proposed fix to use correct path
-const entityIndexPath = '~/.opencode/skills/parser/entity-index.json'; +const entityIndexPath = `${process.env.HOME}/.opencode/skills/Utilities/Parser/entity-index.json`;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.opencode/skills/Utilities/Parser/Workflows/BatchEntityExtractionGemini3.md around lines 455 - 473, The entity index path is incorrect: update the hardcoded entityIndexPath used when reading/writing the index so it points to the correct directory (use "~/.opencode/skills/Utilities/Parser/entity-index.json" instead of the lowercase "parser"); locate the entityIndexPath declaration and the fs.readFileSync/fs.writeFileSync calls that read and write entityIndex (and ensure entityIndex.last_updated is preserved) so processArticleEntities and the collision-detection utility use the same file.
486-488:⚠️ Potential issue | 🔴 CriticalCritical: Incorrect schema path.
Line 487 references the schema at
~/.opencode/skills/parser/schema/content-schema.json(lowercase 'parser'). The correct path should be~/.opencode/skills/Utilities/Parser/schema/content-schema.json, consistent with the repository structure.🔧 Proposed fix to use correct schema path
const schema = JSON.parse( - fs.readFileSync('~/.opencode/skills/parser/schema/content-schema.json', 'utf-8') + fs.readFileSync(`${process.env.HOME}/.opencode/skills/Utilities/Parser/schema/content-schema.json`, 'utf-8') );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.opencode/skills/Utilities/Parser/Workflows/BatchEntityExtractionGemini3.md around lines 486 - 488, The code creating the schema constant uses an incorrect path string; update the fs.readFileSync call that assigns the const schema to read the correct schema file location by replacing the lowercase parser path with the repository-correct path (Utilities/Parser/schema/content-schema.json) so JSON.parse(fs.readFileSync(..., 'utf-8')) loads the proper content-schema.json.
🧹 Nitpick comments (1)
PAI-Install/engine/steps-migrate.ts (1)
232-232: Use importedreadFileSyncinstead ofrequire("fs").The file already imports
readFileSyncfrom "node:fs" at line 8, but line 232 usesrequire("fs").readFileSync. This is inconsistent and adds unnecessary overhead.♻️ Proposed fix
+ const { readFileSync: fsRead } = require("node:fs"); if (existsSync(rcPath)) { - content = require("fs").readFileSync(rcPath, "utf-8"); + content = fsRead(rcPath, "utf-8");Or better yet, add
readFileSyncto the import at the top if not already imported with that name:-import { existsSync, cpSync, mkdirSync, writeFileSync } from "node:fs"; +import { existsSync, cpSync, mkdirSync, writeFileSync, readFileSync } from "node:fs";Then use directly:
- content = require("fs").readFileSync(rcPath, "utf-8"); + content = readFileSync(rcPath, "utf-8");🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@PAI-Install/engine/steps-migrate.ts` at line 232, Replace the inline require("fs").readFileSync usage with the module-level imported readFileSync: ensure the top-level import includes readFileSync from "node:fs" (or add it if missing) and change the assignment that sets content = require("fs").readFileSync(rcPath, "utf-8") to use the imported readFileSync(rcPath, "utf-8") instead, removing the unnecessary require call; look for the content variable assignment near rcPath in steps-migrate.ts to update.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In @.opencode/skills/Utilities/Parser/Workflows/BatchEntityExtractionGemini3.md:
- Around line 571-579: The verification command is using the wrong path string
"~/.opencode/skills/parser/entity-index.json"; update that path in the command
block to "~/.opencode/skills/Utilities/Parser/entity-index.json" so the jq check
reads the correct file (look for the literal path in the markdown block and
replace it accordingly).
- Around line 558-563: The output path is wrong: update the filename
construction where the const filename is defined (refer to the timestamp
constant and the fs.writeFileSync call) to use the correct repository path
"~/.opencode/skills/Utilities/Parser/output/" instead of
"~/.opencode/skills/parser/output/"; ensure the rest of the filename logic
(timestamp, `batch-${index + 1}.json`) and the subsequent
fs.writeFileSync(filename, JSON.stringify(fullContent, null, 2)) and
console.log(`Saved: ${filename}`) calls remain unchanged so files are written to
the corrected directory.
- Around line 69-79: The pre-flight check reads the wrong entity-index.json
path; update the fs.readFileSync call that populates the entityIndex variable so
it points to the canonical path used by collision-detection (replace
'~/.opencode/skills/parser/entity-index.json' with
'~/.opencode/skills/Utilities/Parser/entity-index.json'), ensuring
isContentAlreadyParsed receives the correct index and preventing stale/missing
file reads.
- Around line 455-473: The entity index path is incorrect: update the hardcoded
entityIndexPath used when reading/writing the index so it points to the correct
directory (use "~/.opencode/skills/Utilities/Parser/entity-index.json" instead
of the lowercase "parser"); locate the entityIndexPath declaration and the
fs.readFileSync/fs.writeFileSync calls that read and write entityIndex (and
ensure entityIndex.last_updated is preserved) so processArticleEntities and the
collision-detection utility use the same file.
- Around line 486-488: The code creating the schema constant uses an incorrect
path string; update the fs.readFileSync call that assigns the const schema to
read the correct schema file location by replacing the lowercase parser path
with the repository-correct path (Utilities/Parser/schema/content-schema.json)
so JSON.parse(fs.readFileSync(..., 'utf-8')) loads the proper
content-schema.json.
In `@PAI-Install/engine/steps-migrate.ts`:
- Around line 227-238: The migration writes an unbounded marker ("# PAI shell
setup") which doesn’t match the bounded block pattern used elsewhere; update the
construction around the marker/aliasLine in steps-migrate.ts (the marker
constant and the code that appends to content) so it emits the full bounded
block exactly like actions.ts/steps-fresh.ts: use a start marker string " # PAI
shell setup — added by PAI installer" followed by aliasLine and then an explicit
end marker line "# end PAI shell setup" (ensure content uses trimEnd() +
`\n\n${startMarker}\n${aliasLine}\n${endMarker}\n`), so the removal regex in
actions.ts will match and clean the block.
---
Nitpick comments:
In `@PAI-Install/engine/steps-migrate.ts`:
- Line 232: Replace the inline require("fs").readFileSync usage with the
module-level imported readFileSync: ensure the top-level import includes
readFileSync from "node:fs" (or add it if missing) and change the assignment
that sets content = require("fs").readFileSync(rcPath, "utf-8") to use the
imported readFileSync(rcPath, "utf-8") instead, removing the unnecessary require
call; look for the content variable assignment near rcPath in steps-migrate.ts
to update.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 57ae0132-6954-4ab0-9e7e-cd4ed7c06b85
📒 Files selected for processing (5)
.opencode/OPENCODE.md.opencode/PAISYSTEM/PAI-TO-OPENCODE-MAPPING.md.opencode/skills/Utilities/Parser/Workflows/BatchEntityExtractionGemini3.mdPAI-Install/engine/steps-migrate.tsdocs/specs/UPSTREAM-SYNC-v1.8.0-SPEC.md
💤 Files with no reviewable changes (1)
- .opencode/OPENCODE.md
1 participant
This bundles the remaining repository cleanup items into one PR.
Validation:
Summary by CodeRabbit
Documentation
New Features / Workflows
Chores