forked from HAL9000/cleveragents-core
freemo
9704281bdd
Wire SkillService to use SkillRepository for database persistence, fixing the bug where `agents skill add` stored skills only in an in-memory OrderedDict that was lost when the CLI process exited. Changes: - SkillService now accepts optional skill_repo and session_factory parameters. When provided, add_skill() persists to the database and the constructor pre-loads existing skills from DB rows. - _get_skill_service() in the CLI now creates a DB-backed service following the same engine/sessionmaker/repository pattern used by the tool CLI (tool.py). - _reset_skill_service() now installs a fresh in-memory SkillService (instead of setting None) to avoid DB side-effects during unit testing with parallel runners. - remove_skill() also persists the deletion to the database. Test coverage: - Behave BDD: features/skill_add_persist.feature (4 scenarios) - Robot Framework: robot/skill_add_persist.robot (3 smoke tests) - ASV benchmark: benchmarks/skill_add_persist_bench.py ISSUES CLOSED: #620
47 lines
2.4 KiB
Gherkin
47 lines
2.4 KiB
Gherkin
@phase1 @domain @skill_add_persist
|
|
Feature: Skill add persists to database
|
|
As a developer
|
|
I want skills added via the CLI to persist across process invocations
|
|
So that skill list shows previously added skills
|
|
|
|
Background:
|
|
Given a fresh skill service backed by an in-memory database
|
|
|
|
# ───────────────────────────────────────────────────────
|
|
# Persistence round-trip
|
|
# ───────────────────────────────────────────────────────
|
|
|
|
@skill_add_persist_roundtrip
|
|
Scenario: Skill add followed by skill list shows the added skill
|
|
Given a skill config YAML for "local/persist-test" at a temp path
|
|
When I add the skill via the persistent service
|
|
And I create a second service instance from the same database
|
|
And I list skills from the second service instance
|
|
Then the listed persistent skills should contain "local/persist-test"
|
|
|
|
@skill_add_persist_multiple
|
|
Scenario: Multiple skills added and listed
|
|
Given a skill config YAML for "local/alpha-skill" at a temp path
|
|
And a skill config YAML for "local/beta-skill" at a temp path
|
|
When I add all pending skill configs via the persistent service
|
|
And I create a second service instance from the same database
|
|
And I list skills from the second service instance
|
|
Then the listed persistent skills should contain "local/alpha-skill"
|
|
And the listed persistent skills should contain "local/beta-skill"
|
|
And the listed persistent skills count should be 2
|
|
|
|
@skill_add_persist_duplicate
|
|
Scenario: Skill add with duplicate name produces error
|
|
Given a skill config YAML for "local/dup-skill" at a temp path
|
|
When I add the skill via the persistent service
|
|
Then adding a duplicate "local/dup-skill" should raise ValueError
|
|
|
|
@skill_add_persist_remove
|
|
Scenario: Skill remove persists deletion to database
|
|
Given a skill config YAML for "local/remove-me" at a temp path
|
|
When I add the skill via the persistent service
|
|
And I remove the skill "local/remove-me" via the persistent service
|
|
And I create a second service instance from the same database
|
|
And I list skills from the second service instance
|
|
Then the listed persistent skills should not contain "local/remove-me"
|