fix(ai): resolve rule file relative paths against the project dir - #758
Conversation
|
📦 Plugin has been packaged for this PR. You can download |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #758 +/- ##
=============================================
- Coverage 66.827% 66.827% -0.000%
=============================================
Files 443 443
Lines 25952 25955 +3
Branches 6195 6196 +1
=============================================
+ Hits 17343 17345 +2
Misses 6289 6289
- Partials 2320 2321 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
|
❌ Some commit messages don't follow the conventional format. Invalid commits:
Please update your commits to follow the format: Valid types:
You can update your commit messages using: git rebase -i HEAD~n # where n is the number of commits to edit
# Change 'pick' to 'reword' for commits you want to edit |
The AI rule-authoring assistant could not read an existing project rule file when it passed a relative path (e.g. `.easy.api.properties`): the read resolved against the process working directory, so the agent generated rules without ever seeing the current configuration. Root cause: both the allow-list resolution in RuleFileResolver and the consent-granted read path in ReadRuleFileTool absolutised relative paths via Paths.toAbsolutePath(), which anchors at the JVM working directory instead of the project. Solution: RuleFileResolver.absolutize() now anchors relative paths at the project base path; resolve() and the consent read path go through it, and the tool description documents the behaviour for the model. Impact: write_rule_file also resolves relative paths against the project now; absolute paths, the allowed-dir security checks and the consent flow are unchanged. Fixes: #754
|
📦 Plugin has been packaged for this PR. You can download |
cdedc7a to
319bff1
Compare
|
📦 Plugin has been packaged for this PR. You can download |
Summary
read_rule_filefailed when the agent passed a relative path (e.g..easy.api.properties): path resolution anchored at the JVM working directory instead of the project, so the agent could not read the existing rules and generated new ones blind.RuleFileResolver.absolutize()now anchors relative paths at the project base path; both the allow-list check inresolve()and the consent-granted read path inReadRuleFileToolgo through it. The tool description documents the behavior for the model.Testing
RuleFileResolverTest— a relative path resolves against the project dir and passes the allow-list check.PerceptionToolsTest—read_rule_filewith a relative path returns the file content../gradlew test --tests "com.itangcent.easyapi.core.config.config.source.RuleFileResolverTest" --tests "com.itangcent.easyapi.core.ai.tools.PerceptionToolsTest"— green.Risks / rollback
write_rule_filerelative paths now land in the project instead of the IDE working directory, which is the intended behavior.