Distribute Codex features and add non-interactive setup flags#7
Distribute Codex features and add non-interactive setup flags#7
Conversation
- Replace symlinks with managed copies across setup and migration - Update docs (README, templates) to reflect managed-copies workflow - Add Codex session guide injection and auto-refresh on commands - Add CI check to verify copied rules (no symlinks) - Add TypeScript build (allowJs) to dist and run on prepare - Clean ignores: /coverage, /dist, .dev session artifacts
…tion - Introduced TODOs for `.dev/codex-manifest.json` and `.dev/context-index.md` generation. - Added new sections for Codex Web, CI & Diagnostics, and optional MCP integration. - Expanded Docs & DX with Codex-specific enhancements.
…ecks - Generate .dev/codex-manifest.json and .dev/context-index.md on setup/update/commands - Enhance AGENTS.md Codex guide with manifest/index refs and sample files - Add scripts: ci-verify-codex-manifest.js, codex-doctor.js; wire into CI and package.json
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
- Introduced `--auto-yes` flag to streamline setup processes in CI and non-interactive environments. - Updated setup functions to respect `autoYes` for default-safe operations. - Enhanced existing file handling to skip prompts when `autoYes` is enabled. - Adjusted rules/template copying and configuration logic to align with the new flag.
…-contributing.md Add Start Here section and contributing guide
…rary Add Codex prompt templates
…active; ci: add setup smoke step; docs: update TODO
…to-setup Add --no-codex-guide flag to skip Codex guide outputs
|
Skipped: This PR changes more files than the configured file change limit: ( |
WalkthroughThe PR introduces Claude Code Hooks (session-start, session-end, user-prompt-submit) for managing development workflows, adds Codex session integration with manifest and context files, establishes ESLint and TypeScript configuration, refactors setup scripts to copy instead of symlink rules, and updates documentation with contribution guidelines and Codex guidance. Coverage and IDE files are removed. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant SessionStart as session-start.js
participant ProjectCtx as Project Context
participant RulesDir as Rules Directory
participant StateFile as .dev/.session-state.json
User->>SessionStart: Session begins
SessionStart->>RulesDir: Load rules from .dev/rules/*
RulesDir-->>SessionStart: Rules count & status
SessionStart->>ProjectCtx: Check architecture.md, todo.md
ProjectCtx-->>SessionStart: Context loaded
SessionStart->>StateFile: Save initial session state
StateFile-->>SessionStart: State saved
SessionStart->>User: Display session intro & context
sequenceDiagram
participant User
participant SessionEnd as session-end.js
participant StateFile as .dev/.session-state.json
participant TodoFile as .dev/todo.md
participant Git as Git Repository
participant StatsFile as .dev/.session-stats.json
User->>SessionEnd: Session ends
SessionEnd->>StateFile: Load prior state
StateFile-->>SessionEnd: Prior state loaded
SessionEnd->>TodoFile: Diff old vs current
TodoFile-->>SessionEnd: Completed tasks detected
SessionEnd->>Git: Commit completed tasks
Git-->>SessionEnd: Commit created
SessionEnd->>StatsFile: Update session stats
StatsFile-->>SessionEnd: Stats updated
SessionEnd->>User: Display session summary & clean up
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro Knowledge base: Disabled due to ⛔ Files ignored due to path filters (4)
📒 Files selected for processing (25)
💤 Files with no reviewable changes (25)
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.
Actionable comments posted: 11
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
coverage/lcov-report/index.html (1)
1-131: Addcoverage/directory to.gitignoreto prevent future tracking of generated test coverage reports.Verified that coverage files are currently tracked in version control (27 files across the coverage/ directory). The
git rm --cached coverage/command has removed them from the git index, but.gitignoremust be updated to prevent re-tracking on future test runs.Add the following to
.gitignore:# Test coverage coverage/ *.lcovcoverage/lcov-report/bin/setup.js.html (1)
1-4285: 🚨 Auto-generated coverage report should not be committed to version control.This file (
coverage/lcov-report/bin/setup.js.html) is an auto-generated Istanbul coverage report and should be excluded from the repository. Coverage artifacts are transient build outputs, not source code.Recommendations:
- Add
coverage/directory to.gitignore(ensure this directory is not tracked)- Generate coverage reports locally or in CI/CD pipelines only, not in version control
🧹 Nitpick comments (28)
scripts/review.js (1)
315-315: Minor: Optimise redundant interface count check.Line 315 checks
cached.interfaces.length === 1but this value has already been evaluated implicitly in the preceding loop on line 301. Consider caching the length to avoid redundant array traversals if the codebase grows significantly.for (const iface of cached.interfaces) { // Check if interface starts with 'I' if (!iface.name.startsWith('I')) { this.addViolation( 'warning', file, iface.line, 'INTERFACE_NAMING', `Interface '${iface.name}' should be prefixed with 'I' (e.g., I${iface.name})` ); } // Check if file name matches interface name const fileName = path.basename(file, '.ts'); - if (cached.interfaces.length === 1 && fileName !== iface.name) { + const interfaceCount = cached.interfaces.length; + if (interfaceCount === 1 && fileName !== iface.name) { this.addViolation( 'warning', file, iface.line, 'FILE_NAMING', `File name '${fileName}.ts' should match interface name '${iface.name}.ts'` ); } // Check for multiple interfaces in one file - if (cached.interfaces.length > 1) { + if (interfaceCount > 1) { this.addViolation( 'info', file, null, 'MULTIPLE_INTERFACES', `File contains ${cached.interfaces.length} interfaces. Consider splitting into separate files.` ); break; // Only report once per file } }.tmp/test-windows-compatibility.js (1)
34-47: Consider more robust validation for Windows fallback code.The string-based checks (lines 34, 39, 44) rely on exact function/variable name matching. If these identifiers change, tests fail silently without clear indication of which checks passed or failed.
Consider adding more granular logging or using AST parsing (similar to scripts/review.js) for more reliable validation:
// Current: fragile string matching if (!setupContent.includes('copyDirectory')) { console.error('❌ Setup script missing copyDirectory function'); return false; } // Better: explicit validation with clearer context const requiredPatterns = { copyDirectory: /function\s+copyDirectory|const\s+copyDirectory\s*=|copyDirectory\s*:/, usedCopy: /usedCopy\s*=|let\s+usedCopy|const\s+usedCopy/, syncRules: /sync-rules\.js/, }; for (const [name, pattern] of Object.entries(requiredPatterns)) { if (!pattern.test(setupContent)) { console.error(`❌ Setup script missing or misformatted: ${name}`); return false; } }templates/languages/python/rules/coding-standards.md (1)
1-667: Python standards documentation is thorough and idiomatically correct.The coverage is comprehensive: type hints (PEP 484), mypy strict mode, Protocol-based structural typing, idiomatic naming (snake_case modules, PascalCase classes, Protocol suffix), clean architecture patterns (Repository/Service), dependency injection, domain error handling, and async/await. The guidance correctly emphasises Python idioms over Java/C# patterns (e.g., Protocol suffix instead of I prefix at lines 142–157).
Consider expanding the error handling section to briefly mention dataclass inheritance edge cases (e.g., ordering of fields in inheritance) and generic/TypeVar usage within Protocols, as these are common Python type-safety pitfalls.
templates/claude/commands/check-types.md (2)
33-36: Add language specifier to fenced code block.Line 33 has a fenced code block without a language specifier. Add
bashto improve syntax highlighting and readability.-``` +```bash
98-101: Add language specifier to second fenced code block.Line 98 has a fenced code block without a language specifier. Add
bashto improve syntax highlighting.-``` +```bashtemplates/claude/commands/status.md (1)
9-29: Add language specifier to output display code block.Line 9 starts a fenced code block that displays expected output. Add a language specifier for consistency with documentation standards.
-``` +```text.dev/rules/README.md (1)
33-33: Consider minor phrasing adjustment.The line "Survive updates: Never affected by package updates" could be slightly more grammatically precise.
Consider this adjustment:
-- **Survive updates**: Never affected by package updates +- **Survives updates**: Never affected by package updatesOr alternatively:
-- **Survive updates**: Never affected by package updates +- **Update-proof**: Never affected by package updatesscripts/ci-verify-managed-copies.js (1)
16-25: Consider adding temporary directory cleanup.The script creates a temporary directory but doesn't explicitly clean it up. Whilst CI environments typically handle cleanup, it's a good practice to remove temporary directories after use.
Consider adding cleanup at the end of the main function:
ensure(!sharedStat.isSymbolicLink?.() && !langStat.isSymbolicLink?.(), 'rules should be copied, not symlinked'); console.log('CI verify: managed copies present (no symlinks) ✅'); + + // Cleanup + fs.rmSync(tmp, { recursive: true, force: true }); })();.dev/rules/typescript/testing.md (1)
45-57: Add language specification to code block for documentation rendering.The directory structure code block (lines 45–57) is missing a language identifier. This helps markdown renderers and IDEs properly format the content.
Apply this fix to add the language identifier:
-``` +``` tests/ ├── unit/This applies to all 7 static analysis hints across the file for fenced code blocks without language specifications (lines 45, 93, 183, 256, 338, 397, 522).
README.md (4)
42-42: Standardise "to-do" vs "todo" terminology throughout documentation.The README uses both "todo" and "to-do" inconsistently. Static analysis identifies 8+ instances where "to-do" (with hyphen) is the standard form for the noun. Consider establishing a project-wide terminology preference and applying it consistently across all documentation.
Recommend using "to-do" (hyphenated) as the standard noun form throughout the codebase for consistency with English grammar conventions.
Also applies to: 46-46, 62-62, 256-256, 520-520, 934-934
114-114: Replace emphasis-based headings with proper markdown heading syntax.Lines 114–147 use bold emphasis (
**text**) for section headings within the "Migration Options" section. These should be converted to proper markdown headings (e.g.,### Heading) for better document structure and accessibility.Convert these emphasis-based headings to
###level headings for consistent document structure:-**1. Migrate to .local/ (supersede shared rules)** +### 1. Migrate to .local/ (supersede shared rules)Also applies to: 119-119, 124-124, 128-128, 135-135, 141-141, 147-147
347-347: Add language specifications to fenced code blocks for proper rendering.Three code blocks are missing language identifiers (lines 347, 753, 809), which affects markdown rendering and IDE preview accuracy. Add language tags (e.g.,
```bash,```json) to improve documentation quality.Also applies to: 753-753, 809-809
1-1001: Overall documentation expansion is comprehensive and well-aligned with PR objectives.The README has been significantly expanded to document the Codex features, opt-out flags, and setup improvements introduced in this PR. The documentation clearly explains:
- New Codex bootstrap and context generation features
--no-codex-guideflag for teams with custom workflows--yesflag for non-interactive CI/CD setups- Managed copies approach replacing symlinks
- Developer workspace concept
The structure, examples, and feature descriptions are accurate and helpful. Primary suggestions are formatting/terminology refinements rather than content issues.
Consider addressing the terminology and markdown structure issues identified in previous comments to improve documentation consistency and rendering.
.dev/todo.md (1)
1-1: Minor terminology: Title should use "To-do" per English conventions.The title uses "Todo" which, whilst commonly seen in technical contexts, is grammatically "to-do" (hyphenated noun). Not critical for a task list file, but noted for consistency with documentation standards.
.dev/rules/shared/dev-workspace.md (1)
31-31: Use "to-do" (hyphenated) in documentation for terminology consistency.References to "todo" at lines 31 and 40 should use the standard form "to-do" for consistency with English conventions and project documentation standards.
Also applies to: 40-40
CHANGELOG.md (1)
10-10: Add comma in compound sentence for grammatical clarity.Line 10 reads: "...pinned to the top of the Codex manifest/index so sessions always start...". When "so" connects two independent clauses, a comma should precede it: "...manifest/index, so sessions always start...".
.dev/rules/shared/clean-architecture.md (1)
11-11: Add language specifications to all fenced code blocks for documentation consistency.Seven code blocks throughout the file are missing language identifiers. Whilst the content is clear, adding language tags (e.g.,
```bash,```javascript) improves markdown rendering in IDEs and documentation viewers. For example:
- Line 11–23:
```textor```plaintext- Line 86–90:
```text- Line 114–120:
```text- Lines 216–232:
```javascript- Lines 238–253:
```javascript- Lines 246–253:
```javascriptAlso applies to: 86-86, 114-114, 216-216, 224-224, 238-238, 246-246
.dev/rules/shared/repository-pattern.md (1)
192-192: Add language specifications to pseudo-code blocks for consistency.Two code blocks (lines 192–206 and 200–206) show pseudo-code without language identifiers. Adding
```pseudocodeor```textwould improve documentation rendering consistency with other files.Also applies to: 200-200
.dev/rules/typescript/typescript-config-guide.md (2)
11-11: Add language specifications to fenced code blocks for documentation consistency.Six code blocks are missing language identifiers. Adding appropriate tags (
```bash,```json, etc.) would improve rendering consistency:
- Lines 11–26:
```text- Lines 17–20:
```text- Lines 23–26:
```text- Lines 257–276:
```text- Lines 343–348:
```bash(Phase 1 commands)- Lines 350–355:
```bash(Phase 2 commands)Also applies to: 17-17, 23-23, 257-257, 343-343, 350-350
343-343: Replace emphasis-based section headings with proper markdown syntax.Lines 343 and 350 use
**Phase X: ...**with emphasis instead of proper heading syntax (e.g.,### Phase X: ...). This affects document structure and navigation.-**Phase 1: Relax for Development** +### Phase 1: Relax for DevelopmentAlso applies to: 350-350
.dev/rules/typescript/coding-standards.md (1)
368-380: Consider using conventionalindex.tsnaming.The example uses
AgentEnums.tsas the filename for re-exporting interfaces from a directory. The conventional pattern is to useindex.tsfor barrel exports, which allows for cleaner imports without specifying the filename.Apply this diff to use the conventional naming:
-### Index Files for Clean Imports +### Index Files for Clean Imports -Use `AgentEnums.ts` files to export from directories: +Use `index.ts` files to export from directories: ```typescript -// File: src/domain/interfaces/AgentEnums.ts +// File: src/domain/interfaces/index.ts export { IProductRepository } from './IProductRepository'; export { IOrderRepository } from './IOrderRepository'; export { IUserRepository } from './IUserRepository';templates/dev/DESIGNcode.md (1)
1-9: Consider minor grammar improvement.The bootstrap instructions are clear and concise. For improved readability, you could add a comma before "so" in the final step as it connects two independent clauses.
Apply this diff for the grammar improvement:
-3. If any required file is missing, report it so the user can add or repair it at the start of the session. +3. If any required file is missing, report it, so the user can add or repair it at the start of the session.__tests__/README.md (2)
13-25: Specify language for code fence (MD040)Fenced code blocks should specify language for syntax highlighting. The bash code block starting at line 13 lacks a language identifier.
-``` +```bash # Run all tests npm test
88-109: Fix additional markdown heading violations (MD036)Sections for "File System Mocking" and "Console Mocking" use emphasis instead of heading syntax.
-**File System Mocking** +### File System MockingApply the same change to Console Mocking on line 110.
scripts/ci-verify-codex-manifest.js (1)
10-30: Consider validating theprecedencefield.The script validates the
loadarray but doesn't check theprecedencefield that appears in the manifest schema (seen intemplates/dev/codex-manifest.json). Whilst the current validation is adequate, adding a check forprecedencewould ensure complete manifest integrity.Apply this diff to add precedence validation:
if (!Array.isArray(manifest.load) || manifest.load.length === 0) { fail('Manifest has empty or missing "load" array'); } + if (!Array.isArray(manifest.precedence) || manifest.precedence.length === 0) { + fail('Manifest has empty or missing "precedence" array'); + } const missing = manifest.load.filter(p => !fs.existsSync(path.join(root, p))); if (missing.length) { fail(`Manifest references missing files: ${missing.join(', ')}`); }.dev/rules/.local/README.md (1)
42-50: Specify language for fenced code block.The fenced code block showing gitignore syntax should specify the language identifier for proper syntax highlighting and markdown lint compliance.
Apply this diff:
**Commit .local files** to share project-specific rules with your team: -```gitignore +```gitignore # In your .gitignore: # Ignore base rules copied from the package .dev/rules/shared/Actually, the code block already has
gitignorespecified. Let me re-examine...Looking at lines 42-50, the block appears correct. However, the markdownlint hint references lines 9 and 16 which show directory structures. These could benefit from a language identifier.
Apply this diff to lines 9-12:
-``` +```text .local/ └── clean-architecture.md # Overrides shared/clean-architecture.mdAnd to lines 16-20: ```diff -``` +```text .local/ └── custom-api-standards.md └── database-conventions.md</blockquote></details> <details> <summary>scripts/codex-doctor.js (1)</summary><blockquote> `21-21`: **Silent truncation may confuse users.** The script displays only the first 10 load entries without indicating truncation. Users with larger manifests won't know if entries are missing. Consider adding an indicator: ```diff - (m.load || []).slice(0, 10).forEach(p => console.log(` - ${p}`)); + const entries = m.load || []; + entries.slice(0, 10).forEach(p => console.log(` - ${p}`)); + if (entries.length > 10) { + console.log(` ... and ${entries.length - 10} more`); + }.claude/hooks/user-prompt-submit.js (1)
73-86: Consider async I/O for logging.Using
appendFileSyncon every prompt submission could theoretically block the hook execution. For better performance in high-frequency scenarios, consider async logging, though this may be acceptable for a user-prompt hook.If you want to avoid blocking:
function logPrompt(prompt) { const logPath = path.join(DEV_DIR, '.prompt-log.jsonl'); const logEntry = { timestamp: new Date().toISOString(), promptLength: prompt.length, promptPreview: prompt.substring(0, 100) }; try { - fs.appendFileSync(logPath, JSON.stringify(logEntry) + '\n'); + fs.promises.appendFile(logPath, JSON.stringify(logEntry) + '\n').catch(() => {}); } catch (error) { // Silently fail if logging doesn't work } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (85)
.claude/hooks/README.md(1 hunks).claude/hooks/session-end.js(1 hunks).claude/hooks/session-start.js(1 hunks).claude/hooks/user-prompt-submit.js(1 hunks).claude/settings.json(1 hunks).dev/README.md(1 hunks).dev/codex-manifest.json(1 hunks).dev/context-index.md(1 hunks).dev/lint/jetbrains-lint.md(1 hunks).dev/rules/.local/README.md(1 hunks).dev/rules/README.md(1 hunks).dev/rules/shared/clean-architecture.md(1 hunks).dev/rules/shared/code-quality-rules.md(1 hunks).dev/rules/shared/dev-workspace.md(1 hunks).dev/rules/shared/repository-pattern.md(1 hunks).dev/rules/shared/testing-principles.md(1 hunks).dev/rules/typescript/coding-standards.md(1 hunks).dev/rules/typescript/testing.md(1 hunks).dev/rules/typescript/typescript-config-guide.md(1 hunks).dev/todo.md(1 hunks).eslintrc.json(1 hunks).github/workflows/ci.yml(1 hunks).gitignore(1 hunks).idea/.gitignore(1 hunks).idea/ai-dotfiles-manager.iml(1 hunks).idea/misc.xml(1 hunks).idea/modules.xml(1 hunks).idea/vcs.xml(1 hunks).tmp/test-windows-compatibility.js(1 hunks)AGENTS.md(1 hunks)CHANGELOG.md(1 hunks)CONTRIBUTING.md(1 hunks)README.md(1 hunks)STATUS.md(1 hunks)__tests__/README.md(1 hunks)__tests__/fixtures/project-structures.js(1 hunks)__tests__/helpers/fs-mock.js(1 hunks)__tests__/hooks/session-end.test.js(1 hunks)__tests__/hooks/session-start.test.js(1 hunks)__tests__/hooks/user-prompt-submit.test.js(1 hunks)__tests__/lib/language-detector.test.js(1 hunks)__tests__/scripts/code-reviewer.test.js(1 hunks)__tests__/setup.js(1 hunks)coverage/bin/index.html(3 hunks)coverage/bin/setup.js.html(14 hunks)coverage/index.html(3 hunks)coverage/lcov-report/bin/index.html(3 hunks)coverage/lcov-report/bin/setup.js.html(14 hunks)coverage/lcov-report/index.html(3 hunks)coverage/lcov-report/scripts/index.html(1 hunks)coverage/lcov-report/scripts/review.js.html(1 hunks)coverage/lcov.info(6 hunks)coverage/scripts/index.html(1 hunks)coverage/scripts/review.js.html(1 hunks)jest.config.js(1 hunks)lib/codex-session-guide.js(1 hunks)lib/language-detector.js(1 hunks)package.json(1 hunks)scripts/ci-verify-codex-manifest.js(1 hunks)scripts/ci-verify-managed-copies.js(1 hunks)scripts/codex-doctor.js(1 hunks)scripts/migrate-to-centralized.js(4 hunks)scripts/review.js(1 hunks)templates/AGENTS.md(1 hunks)templates/claude/commands/check-types.md(1 hunks)templates/claude/commands/create-error.md(1 hunks)templates/claude/commands/create-repo.md(1 hunks)templates/claude/commands/create-service.md(1 hunks)templates/claude/commands/create-tests.md(1 hunks)templates/claude/commands/status.md(1 hunks)templates/claude/hooks/README.md(1 hunks)templates/claude/hooks/session-end.js(1 hunks)templates/claude/hooks/session-start.js(1 hunks)templates/claude/hooks/user-prompt-submit.js(1 hunks)templates/codex/prompts/add-service-with-di.txt(1 hunks)templates/codex/prompts/harden-tests.txt(1 hunks)templates/codex/prompts/implement-repo-with-tests.txt(1 hunks)templates/codex/prompts/refactor-for-di.txt(1 hunks)templates/codex/prompts/sync-docs.txt(1 hunks)templates/dev/DESIGNcode.md(1 hunks)templates/dev/codex-manifest.json(1 hunks)templates/dev/context-index.md(1 hunks)templates/dev/lint/jetbrains-lint.md(1 hunks)templates/languages/python/rules/coding-standards.md(1 hunks)templates/languages/python/rules/testing.md(1 hunks)
🧰 Additional context used
🪛 Biome (2.1.2)
scripts/review.js
[error] 185-185: Do not shadow the global "constructor" property.
Consider renaming this variable. It's easy to confuse the origin of variables when they're named after a known global.
(lint/suspicious/noShadowRestrictedNames)
🪛 LanguageTool
templates/dev/DESIGNcode.md
[uncategorized] ~9-~9: Use a comma before ‘so’ if it connects two independent clauses (unless they are closely connected and short).
Context: ... any required file is missing, report it so the user can add or repair it at the st...
(COMMA_COMPOUND_SENTENCE_2)
.dev/README.md
[misspelling] ~3-~3: This word is normally spelled as one.
Context: ...r personal developer workspace** that's auto-loaded into AI context for every session. ## ...
(EN_COMPOUNDS_AUTO_LOADED)
[style] ~47-~47: Consider using a less common alternative to make your writing sound more unique and professional.
Context: ...asks with your team. ## Customization Feel free to add more files: - notes.md - Personal...
(FEEL_FREE_TO_STYLE_ME)
CONTRIBUTING.md
[misspelling] ~6-~6: This word is normally spelled as one.
Context: ...the command or change. 2. Plan before multi-step work. Use update_plan when a task i...
(EN_COMPOUNDS_MULTI_STEP)
.dev/rules/shared/repository-pattern.md
[style] ~287-~287: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...ways necessary:
Skip it when:
- Very simple CRUD with no business logic
- Direct O...
(EN_WEAK_ADJECTIVE)
.dev/rules/shared/code-quality-rules.md
[uncategorized] ~418-~418: The official name of this software platform is spelled with a capital “H”.
Context: .../CD Pipeline
For GitHub Actions, add .github/workflows/ci.yml:
name: CI...
(GITHUB)
</details>
<details>
<summary>CHANGELOG.md</summary>
[uncategorized] ~10-~10: Use a comma before ‘so’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...d to the top of the Codex manifest/index so sessions always start with the bootstra...
(COMMA_COMPOUND_SENTENCE_2)
</details>
<details>
<summary>templates/claude/hooks/README.md</summary>
[grammar] ~15-~15: It appears that a hyphen is missing in the noun “to-do” (= task) or did you mean the verb “to do”?
Context: ...re from `.dev/architecture.md`
- Loads todo list from `.dev/todo.md`
- Checks git ...
(TO_DO_HYPHEN)
---
[grammar] ~21-~21: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...nds
**Purpose:** Auto-commit completed todos and track session statistics
**Configu...
(TO_DO_HYPHEN)
---
[uncategorized] ~79-~79: The preposition ‘to’ seems more likely in this position.
Context: ...r project:
1. **Edit the hook file** in `.claude/hooks/`
2. **Test the hook** ...
(AI_HYDRA_LEO_REPLACE_IN_TO)
---
[uncategorized] ~87-~87: The preposition ‘to’ seems more likely in this position.
Context: ...Code:
1. **Create a new `.js` file** in `.claude/hooks/`
2. **Make it executab...
(AI_HYDRA_LEO_REPLACE_IN_TO)
---
[uncategorized] ~165-~165: Possible missing preposition found.
Context: ... readable
### Hook runs but fails
- Run manually to see error messages
- Check...
(AI_HYDRA_LEO_MISSING_TO)
</details>
<details>
<summary>.claude/hooks/README.md</summary>
[grammar] ~15-~15: It appears that a hyphen is missing in the noun “to-do” (= task) or did you mean the verb “to do”?
Context: ...re from `.dev/architecture.md`
- Loads todo list from `.dev/todo.md`
- Checks git ...
(TO_DO_HYPHEN)
---
[grammar] ~21-~21: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...nds
**Purpose:** Auto-commit completed todos and track session statistics
**Configu...
(TO_DO_HYPHEN)
---
[uncategorized] ~79-~79: The preposition ‘to’ seems more likely in this position.
Context: ...r project:
1. **Edit the hook file** in `.claude/hooks/`
2. **Test the hook** ...
(AI_HYDRA_LEO_REPLACE_IN_TO)
---
[uncategorized] ~87-~87: The preposition ‘to’ seems more likely in this position.
Context: ...Code:
1. **Create a new `.js` file** in `.claude/hooks/`
2. **Make it executab...
(AI_HYDRA_LEO_REPLACE_IN_TO)
---
[uncategorized] ~165-~165: Possible missing preposition found.
Context: ... readable
### Hook runs but fails
- Run manually to see error messages
- Check...
(AI_HYDRA_LEO_MISSING_TO)
</details>
<details>
<summary>__tests__/README.md</summary>
[uncategorized] ~3-~3: Possible missing comma found.
Context: ...omprehensive unit tests for ai-dotfiles-manager following best practices and SOLID prin...
(AI_HYDRA_LEO_MISSING_COMMA)
</details>
<details>
<summary>.dev/rules/shared/dev-workspace.md</summary>
[grammar] ~31-~31: It appears that a hyphen is missing in the noun “to-do” (= task) or did you mean the verb “to do”?
Context: ... helping with tasks:**
- Reference the todo list when suggesting what to work on
-...
(TO_DO_HYPHEN)
---
[grammar] ~40-~40: It appears that a hyphen is missing in the noun “To-do” (= task) or did you mean the verb “to do”?
Context: ...cumented patterns and conventions
## Todo List Format
The todo.md uses standar...
(TO_DO_HYPHEN)
</details>
<details>
<summary>.dev/rules/README.md</summary>
[uncategorized] ~33-~33: Possible missing preposition found.
Context: ...ommit these to share with your team - **Survive updates**: Never affected by package up...
(AI_HYDRA_LEO_MISSING_TO)
</details>
<details>
<summary>.dev/rules/shared/testing-principles.md</summary>
[duplication] ~231-~231: Possible typo: you repeated a word.
Context: ...se test database
- Clean up after each test
- Test with real data
## Testing Services
...
(ENGLISH_WORD_REPEAT_RULE)
</details>
<details>
<summary>templates/AGENTS.md</summary>
[uncategorized] ~61-~61: Possible missing preposition found.
Context: ...index.md` (links to key context) Rules precedence: `.local` > language > shared. Codex w...
(AI_HYDRA_LEO_MISSING_OF)
---
[misspelling] ~65-~65: This word is normally spelled as one.
Context: ...tence preamble. - Use `update_plan` for multi-step tasks; keep steps short. - Prefer `rg` ...
(EN_COMPOUNDS_MULTI_STEP)
</details>
<details>
<summary>templates/claude/commands/create-service.md</summary>
[uncategorized] ~8-~8: Possible missing preposition found.
Context: ...ice should have with descriptions
- Repository dependencies (e.g., ICartRepository, IP...
(AI_HYDRA_LEO_MISSING_OF)
</details>
<details>
<summary>AGENTS.md</summary>
[uncategorized] ~61-~61: Possible missing preposition found.
Context: ...index.md` (links to key context) Rules precedence: `.local` > language > shared. Codex w...
(AI_HYDRA_LEO_MISSING_OF)
---
[misspelling] ~65-~65: This word is normally spelled as one.
Context: ...tence preamble. - Use `update_plan` for multi-step tasks; keep steps short. - Prefer `rg` ...
(EN_COMPOUNDS_MULTI_STEP)
</details>
<details>
<summary>.dev/rules/shared/clean-architecture.md</summary>
[uncategorized] ~93-~93: Possible missing preposition found.
Context: ...
- **Domain** has NO dependencies
- **Application** depends on Domain only
- **Infrastru...
(AI_HYDRA_LEO_MISSING_TO)
---
[duplication] ~109-~109: Possible typo: you repeated a word.
Context: ...s)
- Abstractions should not depend on details
- Details should depend on abstractions
### Ex...
(ENGLISH_WORD_REPEAT_RULE)
</details>
<details>
<summary>README.md</summary>
[grammar] ~42-~42: It appears that a hyphen is missing in the noun “to-do” (= task) or did you mean the verb “to do”?
Context: ...utomatic session start/end actions with todo commit enforcement and current task tra...
(TO_DO_HYPHEN)
---
[grammar] ~46-~46: It appears that a hyphen is missing in the noun “to-do” (= task) or did you mean the verb “to do”?
Context: ...th auto-generated architecture docs and todo list
- **Auto-Context Loading**: AI as...
(TO_DO_HYPHEN)
---
[grammar] ~62-~62: It appears that a hyphen is missing in the noun “To-do” (= task) or did you mean the verb “to do”?
Context: ...use in all your projects
- **Automatic Todo Commits**: Enforces git commits when ta...
(TO_DO_HYPHEN)
---
[grammar] ~256-~256: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... Display project context (architecture, todos, git status)
- ✅ Extract and track cur...
(TO_DO_HYPHEN)
---
[grammar] ~258-~258: It appears that a hyphen is missing in the noun “to-do” (= task) or did you mean the verb “to do”?
Context: ...sk from `todo.md`
- ✅ Commit completed todo items automatically on session end
- ✅...
(TO_DO_HYPHEN)
---
[grammar] ~520-~520: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ... - Loaded context (rules, architecture, todos)
- Current task from todo.md
- Git wo...
(TO_DO_HYPHEN)
---
[uncategorized] ~697-~697: Possible missing preposition found.
Context: ...ed for all new features
- Code reviews ensure quality and consistency
- Regular upda...
(AI_HYDRA_LEO_MISSING_TO)
---
[duplication] ~792-~792: Possible typo: you repeated a word.
Context: ...
- All new features must include unit tests
- Tests should follow the AAA pattern (Arrange,...
(ENGLISH_WORD_REPEAT_RULE)
---
[locale-violation] ~908-~908: License must be spelled with a “c” when used as a noun in British English. Use “licence”.
Context: ...t with a project in that language
## License
MIT License - See LICENSE file for d...
(LICENCE_LICENSE_NOUN_SINGULAR)
---
[locale-violation] ~910-~910: License must be spelled with a “c” when used as a noun in British English. Use “licence”.
Context: ...t in that language
## License
MIT License - See LICENSE file for details.
## C...
(LICENCE_LICENSE_NOUN_SINGULAR)
---
[locale-violation] ~910-~910: LICENSE must be spelled with a “c” when used as a noun in British English. Use “licence”.
Context: ...uage
## License
MIT License - See LICENSE file for details.
## Changelog
##...
(LICENCE_LICENSE_NOUN_SINGULAR)
---
[grammar] ~934-~934: It appears that a hyphen is missing in the plural noun “to-dos”?
Context: ...- Added `session-end.js` - Auto-commits todos and tracks statistics
- Added `user-...
(TO_DO_HYPHEN)
---
[misspelling] ~965-~965: This word is normally spelled as one.
Context: ...eloper Workspace** - Personal workspace auto-loaded into AI context
- `architecture.md` ...
(EN_COMPOUNDS_AUTO_LOADED)
</details>
<details>
<summary>templates/languages/python/rules/testing.md</summary>
[uncategorized] ~290-~290: The preposition ‘for’ seems more likely in this position.
Context: ...multiple test cases
- ✅ Use type hints in tests
- ✅ Mock external dependencies
...
(AI_HYDRA_LEO_REPLACE_IN_FOR)
</details>
<details>
<summary>.dev/todo.md</summary>
[grammar] ~1-~1: It appears that a hyphen is missing in the noun “To-do” (= task) or did you mean the verb “to do”?
Context: # Developer Todo List
> Codex CLI + Managed Copies + ...
(TO_DO_HYPHEN)
</details>
</details>
<details>
<summary>🪛 markdownlint-cli2 (0.18.1)</summary>
<details>
<summary>.dev/rules/.local/README.md</summary>
9-9: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
16-16: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
<details>
<summary>.dev/rules/shared/repository-pattern.md</summary>
192-192: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
200-200: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
<details>
<summary>__tests__/README.md</summary>
13-13: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
65-65: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
69-69: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
73-73: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
77-77: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
81-81: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
88-88: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
110-110: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
</details>
<details>
<summary>.dev/rules/README.md</summary>
7-7: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
<details>
<summary>templates/claude/commands/check-types.md</summary>
33-33: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
98-98: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
<details>
<summary>.dev/rules/shared/testing-principles.md</summary>
36-36: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
71-71: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
102-102: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
118-118: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
</details>
<details>
<summary>.dev/rules/shared/clean-architecture.md</summary>
11-11: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
86-86: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
114-114: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
216-216: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
224-224: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
238-238: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
246-246: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
<details>
<summary>README.md</summary>
114-114: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
119-119: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
124-124: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
128-128: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
135-135: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
141-141: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
147-147: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
347-347: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
753-753: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
809-809: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
<details>
<summary>.dev/rules/typescript/typescript-config-guide.md</summary>
11-11: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
17-17: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
23-23: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
257-257: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
---
343-343: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
---
350-350: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
</details>
<details>
<summary>templates/languages/python/rules/testing.md</summary>
46-46: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
<details>
<summary>templates/claude/commands/status.md</summary>
9-9: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
<details>
<summary>.dev/rules/typescript/testing.md</summary>
45-45: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
</details>
</details>
<!-- This is an auto-generated comment by CodeRabbit for review status -->| **Single Responsibility** | ||
| - Each test tests one thing | ||
| - Test files organized by module | ||
| **Open/Closed** | ||
| - Test utilities can be extended without modification | ||
| - Mock helpers provide flexible interfaces | ||
| **Liskov Substitution** | ||
| - Mocks are substitutable for real implementations | ||
| - `createFsMock()` returns object compatible with `fs` module | ||
| **Interface Segregation** | ||
| - Test helpers provide focused interfaces | ||
| - `fs-mock.js` only mocks needed fs functions | ||
| **Dependency Inversion** |
There was a problem hiding this comment.
Fix markdown heading syntax per MD036
SOLID principle descriptions use bold emphasis instead of proper heading syntax. This affects document structure and readability. Convert **Bold Text** to ### Heading Text.
-**Single Responsibility**
+### Single Responsibility
-**Open/Closed**
+### Open/Closed
-**Liskov Substitution**
+### Liskov Substitution
-**Interface Segregation**
+### Interface Segregation
-**Dependency Inversion**
+### Dependency Inversion📝 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.
| **Single Responsibility** | |
| - Each test tests one thing | |
| - Test files organized by module | |
| **Open/Closed** | |
| - Test utilities can be extended without modification | |
| - Mock helpers provide flexible interfaces | |
| **Liskov Substitution** | |
| - Mocks are substitutable for real implementations | |
| - `createFsMock()` returns object compatible with `fs` module | |
| **Interface Segregation** | |
| - Test helpers provide focused interfaces | |
| - `fs-mock.js` only mocks needed fs functions | |
| **Dependency Inversion** | |
| ### Single Responsibility | |
| - Each test tests one thing | |
| - Test files organized by module | |
| ### Open/Closed | |
| - Test utilities can be extended without modification | |
| - Mock helpers provide flexible interfaces | |
| ### Liskov Substitution | |
| - Mocks are substitutable for real implementations | |
| - `createFsMock()` returns object compatible with `fs` module | |
| ### Interface Segregation | |
| - Test helpers provide focused interfaces | |
| - `fs-mock.js` only mocks needed fs functions | |
| ### Dependency Inversion |
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
65-65: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
69-69: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
73-73: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
77-77: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
81-81: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
🤖 Prompt for AI Agents
In __tests__/README.md around lines 65 to 81, the SOLID principle titles are
formatted using bold markup (e.g., **Single Responsibility**) which violates
MD036; change those bolded principle names to proper markdown headings (e.g.,
prepend "### " before the principle title and remove surrounding **), leaving
the descriptive bullet lists unchanged so each principle becomes a heading
followed by its bullets.
| fs.writeFileSync(SESSION_STATS_PATH, JSON.stringify(stats, null, 2)); | ||
|
|
There was a problem hiding this comment.
Ensure the session stats path exists before writing
Line 132 persists .dev/.session-stats.json without guaranteeing the parent directory exists. If .dev/ has not been bootstrapped yet (or was removed mid-session), fs.writeFileSync raises ENOENT and the hook exits with ❌ Session end failed, breaking the automation. Please create the parent directory first so the hook degrades gracefully.
+ fs.mkdirSync(path.dirname(SESSION_STATS_PATH), { recursive: true });
fs.writeFileSync(SESSION_STATS_PATH, JSON.stringify(stats, null, 2));📝 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.
| fs.writeFileSync(SESSION_STATS_PATH, JSON.stringify(stats, null, 2)); | |
| fs.mkdirSync(path.dirname(SESSION_STATS_PATH), { recursive: true }); | |
| fs.writeFileSync(SESSION_STATS_PATH, JSON.stringify(stats, null, 2)); |
🤖 Prompt for AI Agents
In .claude/hooks/session-end.js around lines 132 to 133, fs.writeFileSync writes
SESSION_STATS_PATH (.dev/.session-stats.json) without ensuring the parent
directory exists; this can throw ENOENT and abort the hook. Before writing,
ensure the directory exists by creating the parent directory (e.g.,
fs.mkdirSync(path.dirname(SESSION_STATS_PATH), { recursive: true })) and then
perform the write; keep error handling intact so failures are logged but the
hook degrades gracefully.
|
|
||
| ## CI/CD Pipeline | ||
|
|
||
| For GitHub Actions, add `.github/workflows/ci.yml`: |
There was a problem hiding this comment.
Correct GitHub capitalisation.
The official name uses a capital "H": GitHub, not Github.
Apply this diff:
-For GitHub Actions, add `.github/workflows/ci.yml`:
+For GitHub Actions, add `.github/workflows/ci.yml`:Note: Whilst the rendered text may appear identical, ensure the proper capitalisation "GitHub" is used in the source.
📝 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.
| For GitHub Actions, add `.github/workflows/ci.yml`: | |
| For GitHub Actions, add `.github/workflows/ci.yml`: |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~418-~418: The official name of this software platform is spelled with a capital “H”.
Context: .../CD Pipeline
For GitHub Actions, add .github/workflows/ci.yml:
name: CI...
(GITHUB)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
.dev/rules/shared/code-quality-rules.md around line 418: the text uses incorrect
capitalization "Github" — update the string to the correct "GitHub" in the
source so the official name is capitalized properly (replace "Github" with
"GitHub" in that line).
</details>
<!-- This is an auto-generated comment by CodeRabbit -->
| ## Language-Specific Testing | ||
|
|
||
| For testing frameworks, assertion libraries, and syntax in your language: | ||
|
|
||
| - **TypeScript**: `languages/typescript/testing.md` | ||
| - **Python**: `languages/python/testing.md` | ||
| - **Go**: `languages/go/testing.md` | ||
| - **Java**: `languages/java/testing.md` |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the file path references.
The language-specific testing file paths reference languages/typescript/testing.md, languages/python/testing.md, etc., but based on the repository structure in this PR, these files appear to be located under .dev/rules/ (e.g., .dev/rules/typescript/testing.md).
Run the following script to verify the correct paths:
🏁 Script executed:
#!/bin/bash
# Check for language-specific testing documentation
echo "Checking for testing.md files in languages/ directory:"
fd -t f 'testing.md' languages/
echo -e "\nChecking for testing.md files in .dev/rules/ directory:"
fd -t f 'testing.md' .dev/rules/Length of output: 242
I need to check the actual file content and determine what testing files exist in the repository.
🏁 Script executed:
#!/bin/bash
# Check the exact content at lines 462-469
echo "Content of .dev/rules/shared/testing-principles.md at lines 462-469:"
sed -n '462,469p' .dev/rules/shared/testing-principles.md
echo -e "\n---\n"
echo "Finding all testing.md files in .dev/rules/ recursively:"
find .dev/rules -name 'testing.md' -type fLength of output: 260
I made an error by including `` which prevented repository access. Let me verify the actual file paths with the repository available.
🏁 Script executed:
#!/bin/bash
# Check the exact content at lines 462-469
echo "Content of .dev/rules/shared/testing-principles.md at lines 462-469:"
sed -n '462,469p' .dev/rules/shared/testing-principles.md
echo -e "\n---\n"
echo "Finding all testing.md files in .dev/rules/ recursively:"
find .dev/rules -name 'testing.md' -type f | sortLength of output: 260
Let me explore the repository structure to locate the file:
🏁 Script executed:
#!/bin/bash
# List repository root
echo "Repository root contents:"
ls -la
echo -e "\n---\n"
echo "Searching for the file in the repository:"
find . -name 'testing-principles.md' -type f 2>/dev/null
echo -e "\n---\n"
echo "Searching for any testing.md files:"
find . -name 'testing.md' -type f 2>/dev/null | head -20Length of output: 2375
Now let me check the file content and find all language-specific testing files:
🏁 Script executed:
#!/bin/bash
# Check the exact content at lines 462-469
echo "Content of ./.dev/rules/shared/testing-principles.md at lines 462-469:"
sed -n '462,469p' ./.dev/rules/shared/testing-principles.md
echo -e "\n---\n"
echo "All language-specific testing files in .dev/rules/:"
find ./.dev/rules -name 'testing.md' -type f | sort
echo -e "\n---\n"
echo "All language-specific testing files in templates/languages/:"
find ./templates/languages -name 'testing.md' -type f 2>/dev/null | sortLength of output: 611
Correct the file path references in lines 462-469.
The documented paths reference a non-existent languages/ directory. Only .dev/rules/typescript/testing.md exists; the Python, Go, and Java testing files are missing from .dev/rules/. Update the paths to .dev/rules/typescript/testing.md, or create the missing language-specific testing documentation files (Python, Go, Java) under .dev/rules/.
🤖 Prompt for AI Agents
.dev/rules/shared/testing-principles.md lines 462-469: the document references
non-existent paths under a top-level languages/ directory; update the paths to
point to existing .dev/rules/* files or add the missing files. Either change the
four entries to .dev/rules/typescript/testing.md (and similarly
.dev/rules/python/testing.md, .dev/rules/go/testing.md,
.dev/rules/java/testing.md) if you will create those files, or if only
TypeScript doc exists, replace all entries with the single
.dev/rules/typescript/testing.md entry and remove or comment out the others; if
you choose to add files, create minimal testing.md stubs under
.dev/rules/python/, .dev/rules/go/, and .dev/rules/java/ so the referenced paths
resolve.
| <span class="strong">0% </span> | ||
| <span class="quiet">Statements</span> | ||
| <span class='fraction'>0/563</span> | ||
| <span class='fraction'>0/531</span> |
There was a problem hiding this comment.
🧩 Analysis chain
bin/setup.js has 0% code coverage.
The setup script shows zero coverage across all metrics:
- Statements: 0/531 (0%)
- Branches: 0/282 (0%)
- Functions: 0/35 (0%)
- Lines: 0/523 (0%)
This setup script handles critical functionality (tool configuration, symlink creation, file migrations, hooks installation), yet none of it is being tested. This is a significant risk for a core utility function.
Related PR incomplete checklist item: "Adequate test coverage for new features" — this remains unchecked.
Recommendation: Write unit tests for bin/setup.js, particularly for:
- Tool configuration logic
- Symlink creation and fallback to copy
- File migration scenarios (replace/migrate-preserve/migrate-supersede)
- Error handling paths
Also applies to: 35-35, 42-42, 49-49
I'll help verify this review comment about the test coverage gap. Let me investigate the codebase to confirm the claims.
🏁 Script executed:
#!/bin/bash
# Find bin/setup.js and examine its contents
echo "=== Searching for bin/setup.js ==="
fd -t f "setup.js" --full-path
echo -e "\n=== Examining bin/setup.js if found ==="
if [ -f "bin/setup.js" ]; then
wc -l bin/setup.js
head -30 bin/setup.js
fi
echo -e "\n=== Searching for test files related to setup ==="
fd -t f -e "test.js" -e "spec.js" -e ".test.ts" -e ".spec.ts" | grep -i setup
echo -e "\n=== Checking for test coverage or test directory ==="
fd -type d -name "test*" -o -name "__tests__" -o -name "spec"
echo -e "\n=== Looking for jest/mocha config or test runner config ==="
fd -t f \( -name "jest.config.*" -o -name "mocha.opts" -o -name ".mocharc.*" \)
echo -e "\n=== Checking PR description or test checklist ==="
if [ -f "README.md" ]; then
grep -i "test coverage\|adequate test" README.md || echo "No matching content in README.md"
fiLength of output: 1932
🏁 Script executed:
#!/bin/bash
echo "=== Examining __tests__/setup.js ==="
if [ -f "__tests__/setup.js" ]; then
wc -l __tests__/setup.js
cat __tests__/setup.js
fi
echo -e "\n=== Checking package.json for test scripts ==="
if [ -f "package.json" ]; then
jq '.scripts | select(.test != null) | .test' package.json
fi
echo -e "\n=== Looking for coverage configuration ==="
jq '.jest, .nyc' package.json 2>/dev/null || echo "No jest/nyc config in package.json"
echo -e "\n=== Checking for coverage directory ==="
if [ -d "coverage" ]; then
ls -la coverage/ | head -20
echo ""
if [ -f "coverage/lcov-report/bin/setup.js.html" ]; then
echo "Coverage report HTML found"
head -100 coverage/lcov-report/bin/setup.js.html | grep -i "fraction\|coverage" | head -5
fi
fi
echo -e "\n=== Searching for any test files in __tests__ directory ==="
if [ -d "__tests__" ]; then
find __tests__ -type f | head -20
fiLength of output: 2278
🏁 Script executed:
#!/bin/bash
echo "=== Final verification: searching for any tests that might test bin/setup.js ==="
rg -i "bin/setup|setup\.js" __tests__/ -C 2
echo -e "\n=== Checking if setup.js is imported or referenced in any test ==="
rg "require.*setup|import.*setup" __tests__/ --type js
echo -e "\n=== Listing all test files found ==="
find __tests__ -type f -name "*.test.js" -o -name "*.spec.js"
echo -e "\n=== Checking bin directory contents ==="
ls -la bin/Length of output: 1199
Test coverage gap for bin/setup.js verified—unit tests required
The zero coverage claim has been confirmed. bin/setup.js (1,636 lines) has no corresponding test file, whilst the coverage report accurately shows 0/531 statements covered. The script handles substantial functionality and warrants test coverage before release.
Recommended test cases:
- Tool configuration logic
- Symlink creation and fallback to copy
- File migration scenarios (replace/migrate-preserve/migrate-supersede)
- Error handling paths
🤖 Prompt for AI Agents
In coverage/lcov-report/bin/setup.js.html around line 28: the coverage report
shows bin/setup.js has 0/531 statements covered because there are no unit tests;
add a test suite for bin/setup.js that covers the listed scenarios. Create a new
test file (e.g., test/bin/setup.spec.js) that imports the module (or runs it via
a spawn wrapper) and uses fs and child_process mocks/stubs (or sinon/jest mocks)
to simulate tool configuration parsing, symlink creation and fallback-to-copy
behavior, and the three migration modes (replace, migrate-preserve,
migrate-supersede), plus error paths (permission errors, missing files). For
each scenario assert expected filesystem operations, return codes, logs, and
side effects; use temp directories or a mocked filesystem (memfs) to avoid
touching real filesystems and ensure tests exercise branches to raise coverage
above 0.
| const m = JSON.parse(fs.readFileSync(manifestPath, 'utf-8')); | ||
| console.log(` Load entries: ${Array.isArray(m.load) ? m.load.length : 0}`); | ||
| (m.load || []).slice(0, 10).forEach(p => console.log(` - ${p}`)); | ||
| } catch (e) { | ||
| console.log(` Invalid JSON: ${e.message}`); | ||
| } |
There was a problem hiding this comment.
Consider validating array type before accessing length.
The code checks Array.isArray(m.load) when displaying the count but doesn't validate before slicing. If m.load exists but isn't an array, line 21 could throw.
Apply this diff to ensure consistent validation:
try {
const m = JSON.parse(fs.readFileSync(manifestPath, 'utf-8'));
console.log(` Load entries: ${Array.isArray(m.load) ? m.load.length : 0}`);
- (m.load || []).slice(0, 10).forEach(p => console.log(` - ${p}`));
+ if (Array.isArray(m.load)) {
+ m.load.slice(0, 10).forEach(p => console.log(` - ${p}`));
+ }
} catch (e) {
console.log(` Invalid JSON: ${e.message}`);
}🤖 Prompt for AI Agents
In scripts/codex-doctor.js around lines 19 to 24, the code checks
Array.isArray(m.load) when printing the count but still calls (m.load ||
[]).slice(...) which will throw if m.load exists but is not an array; ensure you
validate and normalize m.load before slicing by creating a local variable like
const load = Array.isArray(m.load) ? m.load : [] and use load.length for the
count and load.slice(0,10).forEach(...) for printing so slicing is only
performed on a confirmed array.
| function loadRules() { | ||
| if (!fs.existsSync(RULES_DIR)) { | ||
| console.error('⚠️ Rules directory not found. Run "ai-dotfiles-manager setup" first.'); | ||
| return false; | ||
| } | ||
| const ruleDirs = ['shared', 'typescript', 'python', 'javascript', 'go', '.local']; | ||
| let rulesLoaded = 0; | ||
| ruleDirs.forEach(dir => { | ||
| const dirPath = path.join(RULES_DIR, dir); | ||
| if (fs.existsSync(dirPath)) { | ||
| const ruleFiles = fs.readdirSync(dirPath).filter(f => f.endsWith('.md')); | ||
| rulesLoaded += ruleFiles.length; | ||
| } | ||
| }); | ||
| console.error(`✅ Loaded ${rulesLoaded} rule files from .dev/rules/`); | ||
| return true; | ||
| } | ||
| /** | ||
| * Load project context (architecture and todos) | ||
| */ | ||
| function loadProjectContext() { | ||
| let context = ''; | ||
| // Load architecture overview | ||
| if (fs.existsSync(ARCHITECTURE_PATH)) { | ||
| console.error('✅ Loaded architecture.md'); | ||
| } else { | ||
| console.error('⚠️ architecture.md not found'); | ||
| } | ||
| // Load and analyze todo list | ||
| if (fs.existsSync(TODO_PATH)) { | ||
| const todoContent = fs.readFileSync(TODO_PATH, 'utf-8'); | ||
| const pendingTasks = (todoContent.match(/- \[ \]/g) || []).length; | ||
| const completedTasks = (todoContent.match(/- \[x\]/gi) || []).length; | ||
| console.error(`✅ Loaded todo.md (${pendingTasks} pending, ${completedTasks} completed)`); | ||
| // Save initial state for session-end comparison | ||
| saveSessionState({ todoContent, startTime: new Date().toISOString() }); | ||
| } else { | ||
| console.error('⚠️ todo.md not found'); | ||
| } | ||
| } | ||
| /** | ||
| * Check git status for uncommitted changes | ||
| */ | ||
| function checkGitStatus() { | ||
| try { | ||
| const { execSync } = require('child_process'); | ||
| const status = execSync('git status --porcelain', { encoding: 'utf-8' }); | ||
| if (status.trim()) { | ||
| const lines = status.trim().split('\n'); | ||
| console.error(`⚠️ ${lines.length} uncommitted change(s)`); | ||
| } else { | ||
| console.error('✅ Working directory is clean'); | ||
| } | ||
| } catch (error) { | ||
| // Not a git repository or git not available | ||
| } | ||
| } |
There was a problem hiding this comment.
Incorrect use of console.error() for non-error diagnostics.
Lines 27, 42, 54, 56, 64, 69 log informational and success messages to stderr using console.error(). These should use console.log() instead, as console.error() is reserved for actual errors. This could interfere with stderr-based error aggregation in CI/monitoring systems.
- console.error(`✅ Loaded ${rulesLoaded} rule files from .dev/rules/`);
+ console.log(`✅ Loaded ${rulesLoaded} rule files from .dev/rules/`);Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In templates/claude/hooks/session-start.js around lines 25 to 90, replace the
use of console.error() for informational/success messages with console.log()
(specifically the messages in loadRules, loadProjectContext, and checkGitStatus
at the referenced lines: the "Rules directory not found" / "Loaded X rule files"
messages, the "Loaded architecture.md" / "architecture.md not found" / "Loaded
todo.md (...)" / "todo.md not found" messages, and the "Working directory is
clean" / "X uncommitted change(s)" messages) while leaving actual error handling
(exceptions or true errors) as console.error(); ensure no other behavior changes
and preserve existing calls such as saveSessionState.
| # JetBrains Inspectopedia: JavaScript & TypeScript Targets | ||
|
|
||
| JetBrains maintains 26 JavaScript/TypeScript inspection groups spanning assignment mistakes, async misuse, type safety, code style, security, testing, and more.citeturn3search6 Use this checklist to sanity-check Codex CLI output before handing code off to JetBrains tooling. | ||
|
|
||
| ## Core Risk Buckets to Scan | ||
| - **Control flow & assignments** – Reject generated snippets that reassign function parameters or hide writes inside nested expressions; both patterns are explicitly flagged as confusing or error-prone.citeturn5search1turn5search2 | ||
| - **General API & documentation hygiene** – Watch for duplicate declarations, invalid ECMAScript constructs, mismatched JSDoc, unresolved references, and non-strict files, all of which are highlighted in the General inspection family.citeturn3search7 | ||
| - **Async discipline** – Ensure every `await` lives inside an `async` function, promises are awaited (or intentionally handled), redundant `await`s are removed, and top-level `await` is avoided unless modules support it.citeturn6search1turn6search6 | ||
| - **TypeScript-specific correctness** – Enforce strict type resolution: surface duplicate union members, unresolved imports/references, explicit-type style breaks, and mismatched assignment/return types before code reaches the IDE.citeturn7search2turn4search4turn4search5turn4search3 | ||
| - **Probable bug patterns** – Guard against loose equality that risks coercion and similar logic errors that JetBrains elevates in the Probable bugs group.citeturn7search0turn7search4 | ||
| - **Dead/unused surface** – Eliminate unused globals and symbols to align with Inspectopedia’s unused symbol checks.citeturn3search11 | ||
| - **External lint parity** – JetBrains can surface ESLint, StandardJS, or JSHint violations directly; keep generated code compatible with those linters.citeturn7search5 | ||
|
|
||
| ## Codex CLI Usage | ||
| 1. Treat each bullet above as a “must confirm” item when proposing JS/TS changes. Inline comments should call out where the code satisfies or intentionally violates these inspections. | ||
| 2. When a violation is unavoidable, annotate the snippet with the matching JetBrains suppression comment (for example, `// noinspection JSIgnoredPromiseFromCall`) so the intent remains explicit.citeturn6search0 | ||
| 3. Prefer running the project’s existing lint command (`npm run lint`, `pnpm lint`, etc.) after generation; this aligns with JetBrains’ Code quality tools integration and catches overlapping issues early.citeturn7search5 |
There was a problem hiding this comment.
Remove citation artefacts from documentation.
The document contains numerous citation markers like "citeturn3search6", "turn5search1", "turn7search2", etc., which appear to be AI assistant artefacts. These should be replaced with proper references or removed entirely to ensure the documentation is professional and readable.
Search and remove all occurrences of patterns like:
.citeturn[0-9]+search[0-9]+turn[0-9]+search[0-9]+
Then replace with proper citations or simply remove if the content stands on its own.
| ``` | ||
| tests/ | ||
| ├── unit/ | ||
| │ ├── domain/ | ||
| │ │ └── services/ | ||
| │ │ └── test_product_service.py | ||
| │ └── application/ | ||
| │ └── services/ | ||
| │ └── test_order_service.py | ||
| └── integration/ | ||
| └── repositories/ | ||
| └── test_product_repository_integration.py | ||
| ``` |
There was a problem hiding this comment.
Add language identifier to fenced code block.
Line 46's code block lacks a language specifier. Specify the language or use a generic format identifier for markdown linting compliance:
-```
+```txt
tests/
├── unit/
│ ├── domain/🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
46-46: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In templates/languages/python/rules/testing.md around lines 46 to 58, the fenced
code block does not include a language identifier; update the opening fence from
``` to ```txt (or another appropriate language identifier) so the block becomes
a labeled fenced code block (keep the closing ``` unchanged) to satisfy markdown
linting.
1 participant
Summary
This pull request introduces and enhances several features aimed at streamlining Codex functionality and improving the developer experience. Key updates include:
Codex Features:
.dev/codex-manifest.json,.dev/context-index.md, and Codex diagnostic scripts.Setup Improvements:
--auto-yesflag to facilitate non-interactive setups, particularly useful in CI environments.--no-codex-guideflag to skip Codex guide generation in setups, enhancing flexibility.Refactor and Maintenance:
Checklist
Additional Notes
Further CI checks and validation for Codex integration have been added to enhance quality assurance.
Summary by CodeRabbit
Release Notes
New Features
Chores