agents skill does not register when skills are added. #620

Open
opened 2026-03-07 00:52:24 +00:00 by brent.edwards · 11 comments
Member

Metadata

  • Commit Message: fix(skill): persist skill registration to database after add
  • Branch: fix/skill-add-not-registering
  • Type: Bug
  • Priority: Critical
  • MoSCoW: Must have
  • Points: 3
  • Milestone: v3.2.0
  • Assignee: @freemo

Parent

Epic: #401 (E2E Integration Testing — bug discovered during M3 acceptance testing)

Background and Context

Bug reported by @brent.edwards on Day 27. After agents init and agents skill add --config /app/examples/skills/single-tool.yaml, running agents skill list shows "No skills found." The skill add command appears to succeed silently but the skill is not persisted/registered.

Investigation reveals that SkillService (used by the CLI skill add command) is an entirely in-memory service using OrderedDict storage. It has no database persistence layer — skills are lost when the CLI process exits. The service docstring explicitly states: "In-memory skill registration service — will be supplemented by DB when registry lands."

There is a separate SkillRegistryService in the application services layer that needs investigation to determine if it provides the missing persistence infrastructure.

Reproduction Steps

cd ~
mkdir data
uv venv
source .venv/bin/activate
uv pip install -e /app
agents init
agents skill add --config /app/examples/skills/single-tool.yaml

Test ("When")

agents skill list

Expected

To see the single-tool.yaml among the list of skills.

Actual

(devuser) ➜  ~ agents skill list
No skills found.
Register one with 'agents skill add --config <file>'

Acceptance Criteria

  • agents skill add --config <file> persists the skill to the database
  • agents skill list shows previously added skills across CLI invocations
  • Skill add followed by skill list in separate processes shows the skill
  • Existing tests pass (BDD, Robot, ASV)
  • New Behave BDD regression tests for skill add/list persistence
  • New Robot Framework integration smoke tests for skill lifecycle
  • New ASV benchmark for skill add/list round-trip

Subtasks

  • Investigate SkillRegistryService for existing database persistence infrastructure
  • If DB persistence exists: fix wiring between CLI and persistence layer
  • If no DB persistence: implement database persistence for skills (model, repository, service update)
  • Write Behave BDD regression scenarios for skill add/list persistence
  • Write Robot Framework integration smoke tests
  • Write ASV benchmark for skill add/list round-trip
  • Verify coverage >=97% via nox -s coverage_report
  • Run nox (all default sessions), fix any errors

Definition of Done

This issue is complete when:

  • All subtasks above are completed and checked off.
  • A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation.
  • The commit is pushed to the remote on the branch matching the Branch in Metadata exactly.
  • The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.
## Metadata - **Commit Message**: `fix(skill): persist skill registration to database after add` - **Branch**: `fix/skill-add-not-registering` - **Type**: Bug - **Priority**: Critical - **MoSCoW**: Must have - **Points**: 3 - **Milestone**: v3.2.0 - **Assignee**: @freemo ## Parent Epic: #401 (E2E Integration Testing — bug discovered during M3 acceptance testing) ## Background and Context Bug reported by @brent.edwards on Day 27. After `agents init` and `agents skill add --config /app/examples/skills/single-tool.yaml`, running `agents skill list` shows "No skills found." The skill add command appears to succeed silently but the skill is not persisted/registered. Investigation reveals that `SkillService` (used by the CLI `skill add` command) is an entirely in-memory service using `OrderedDict` storage. It has no database persistence layer — skills are lost when the CLI process exits. The service docstring explicitly states: "In-memory skill registration service — will be supplemented by DB when registry lands." There is a separate `SkillRegistryService` in the application services layer that needs investigation to determine if it provides the missing persistence infrastructure. ## Reproduction Steps ``` cd ~ mkdir data uv venv source .venv/bin/activate uv pip install -e /app agents init agents skill add --config /app/examples/skills/single-tool.yaml ``` ### Test ("When") ``` agents skill list ``` ### Expected To see the `single-tool.yaml` among the list of skills. ### Actual ``` (devuser) ➜ ~ agents skill list No skills found. Register one with 'agents skill add --config <file>' ``` ## Acceptance Criteria - [ ] `agents skill add --config <file>` persists the skill to the database - [ ] `agents skill list` shows previously added skills across CLI invocations - [ ] Skill add followed by skill list in separate processes shows the skill - [ ] Existing tests pass (BDD, Robot, ASV) - [ ] New Behave BDD regression tests for skill add/list persistence - [ ] New Robot Framework integration smoke tests for skill lifecycle - [ ] New ASV benchmark for skill add/list round-trip ## Subtasks - [ ] Investigate `SkillRegistryService` for existing database persistence infrastructure - [ ] If DB persistence exists: fix wiring between CLI and persistence layer - [ ] If no DB persistence: implement database persistence for skills (model, repository, service update) - [ ] Write Behave BDD regression scenarios for skill add/list persistence - [ ] Write Robot Framework integration smoke tests - [ ] Write ASV benchmark for skill add/list round-trip - [ ] Verify coverage >=97% via `nox -s coverage_report` - [ ] Run `nox` (all default sessions), fix any errors ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done.
freemo self-assigned this 2026-03-07 23:06:36 +00:00
freemo added this to the v3.2.0 milestone 2026-03-07 23:06:36 +00:00
Owner

Triage — Day 27

Status: Confirmed bug. Triaged and labeled.

Actions Taken

  • Added labels: Type/Bug, Priority/Critical, MoSCoW/Must have, State/Unverified, Points/3
  • Assigned to: @freemo (CTO — best positioned to diagnose persistence/registry path)
  • Milestone: v3.2.0 (M3 — all bugs are top priority)
  • Removed redundant bug label (repo-level default; use org-level Type/Bug)
  • Created TDD counterpart: #637

Issue Body Compliance Note

The issue body does not conform to CONTRIBUTING.md issue template. It is missing:

  • ## Metadata table (Commit Message, Branch, Type, Priority, MoSCoW, Points, Milestone, Assignee)
  • ## Background and Context section with root cause analysis
  • ## Expected Behavior / ## Current Behavior sections
  • ## Acceptance Criteria checklist
  • ## Subtasks checklist
  • ## Definition of Done section

@brent.edwards — thank you for the clear reproduction steps. The Given/When/Expected/Actual format is excellent for bug reports. The metadata and structural sections will be added during the fix workflow by the assignee.

Root Cause Hypothesis

The skill add command likely shares a persistence pattern with project create (#589) — the add operation may call session.flush() without session.commit(), or the registry may not be updated after the database write. Investigation needed.

Dependencies

  • TDD tests (#637) must be written first per CONTRIBUTING.md Bug Fix Workflow
  • TDD infrastructure (#627, #628) blocks TDD test execution but not creation
  • Likely shares root cause with #621 (tool add not registering)
## Triage — Day 27 **Status**: Confirmed bug. Triaged and labeled. ### Actions Taken - Added labels: `Type/Bug`, `Priority/Critical`, `MoSCoW/Must have`, `State/Unverified`, `Points/3` - Assigned to: @freemo (CTO — best positioned to diagnose persistence/registry path) - Milestone: v3.2.0 (M3 — all bugs are top priority) - Removed redundant `bug` label (repo-level default; use org-level `Type/Bug`) - Created TDD counterpart: #637 ### Issue Body Compliance Note The issue body does not conform to CONTRIBUTING.md issue template. It is missing: - `## Metadata` table (Commit Message, Branch, Type, Priority, MoSCoW, Points, Milestone, Assignee) - `## Background and Context` section with root cause analysis - `## Expected Behavior` / `## Current Behavior` sections - `## Acceptance Criteria` checklist - `## Subtasks` checklist - `## Definition of Done` section @brent.edwards — thank you for the clear reproduction steps. The Given/When/Expected/Actual format is excellent for bug reports. The metadata and structural sections will be added during the fix workflow by the assignee. ### Root Cause Hypothesis The `skill add` command likely shares a persistence pattern with `project create` (#589) — the add operation may call `session.flush()` without `session.commit()`, or the registry may not be updated after the database write. Investigation needed. ### Dependencies - TDD tests (#637) must be written first per CONTRIBUTING.md Bug Fix Workflow - TDD infrastructure (#627, #628) blocks TDD test execution but not creation - Likely shares root cause with #621 (tool add not registering)
Owner

Verification — Day 28

Status: Verified. Bug confirmed and root cause investigated.

Root Cause Analysis

Investigation reveals that SkillService (used by the CLI skill add path via _get_skill_service() in skill.py) is an entirely in-memory service using OrderedDict storage. The service docstring at line 28 of skill_service.py explicitly states: "In-memory skill registration service" and at line 44: "will be supplemented by DB when registry lands."

There is no SkillRepository, no SkillModel in the database layer, and no database persistence path for skills. Data is lost when the CLI process exits.

A separate SkillRegistryService exists in application/services/skill_registry_service.py — investigation is needed to determine if it provides the missing persistence infrastructure.

Actions Taken

  • Updated issue body with CONTRIBUTING.md-compliant template (Metadata, Subtasks, DoD)
  • Transitioned from State/UnverifiedState/Verified
  • Branch assigned: fix/skill-add-not-registering
  • Commit message: fix(skill): persist skill registration to database after add

Investigation Plan

  1. Check SkillRegistryService for existing DB CRUD
  2. If DB persistence exists: fix the wiring between CLI and the persistent service
  3. If no DB persistence: assess scope — may need new model, repository, migration
## Verification — Day 28 **Status**: Verified. Bug confirmed and root cause investigated. ### Root Cause Analysis Investigation reveals that `SkillService` (used by the CLI `skill add` path via `_get_skill_service()` in `skill.py`) is an **entirely in-memory service** using `OrderedDict` storage. The service docstring at line 28 of `skill_service.py` explicitly states: *"In-memory skill registration service"* and at line 44: *"will be supplemented by DB when registry lands."* There is no `SkillRepository`, no `SkillModel` in the database layer, and no database persistence path for skills. Data is lost when the CLI process exits. A separate `SkillRegistryService` exists in `application/services/skill_registry_service.py` — investigation is needed to determine if it provides the missing persistence infrastructure. ### Actions Taken - Updated issue body with CONTRIBUTING.md-compliant template (Metadata, Subtasks, DoD) - Transitioned from `State/Unverified` → `State/Verified` - Branch assigned: `fix/skill-add-not-registering` - Commit message: `fix(skill): persist skill registration to database after add` ### Investigation Plan 1. Check `SkillRegistryService` for existing DB CRUD 2. If DB persistence exists: fix the wiring between CLI and the persistent service 3. If no DB persistence: assess scope — may need new model, repository, migration
Owner

Implementation Complete — PR #640

Root Cause Analysis

The CLI skill.py used SkillService which stored skills in a pure in-memory OrderedDict. Each CLI invocation created a new empty SkillService, so data was never persisted between process runs.

The database infrastructure was already in place:

  • SkillModel + SkillItemModel (SQLAlchemy models for skills and skill_items tables)
  • SkillRepository (full CRUD with session-factory pattern)
  • SkillRegistryService (service layer wrapping the repo)
  • Alembic migrations (c0_001, c0_002, m4_002)

The wiring between the CLI and the database layer was missing.

Fix

  1. SkillService now accepts optional skill_repo + session_factory parameters. When provided, add_skill() and remove_skill() persist to DB alongside the in-memory dict. The constructor pre-loads existing skills from DB rows.

  2. _get_skill_service() in CLI creates a DB-backed service following the same engine → sessionmaker → repository pattern used by tool.py.

  3. _reset_skill_service() now installs a fresh in-memory SkillService instead of None to avoid parallel test runner interference.

Test Results

Gate Result
nox -s lint Passed
nox -s typecheck 0 errors
nox -s unit_tests 9110 scenarios passed
nox -s coverage_report 97%
Integration tests Skill tests all passed

Subtask Status

  • Investigation — root cause identified
  • Implementation — CLI wired to DB via SkillRepository
  • Behave BDD tests — 4 scenarios in features/skill_add_persist.feature
  • Robot Framework tests — 3 smoke tests in robot/skill_add_persist.robot
  • ASV benchmark — benchmarks/skill_add_persist_bench.py
  • All quality gates passed
## Implementation Complete — PR #640 ### Root Cause Analysis The CLI `skill.py` used `SkillService` which stored skills in a pure in-memory `OrderedDict`. Each CLI invocation created a new empty `SkillService`, so data was never persisted between process runs. The database infrastructure was already in place: - `SkillModel` + `SkillItemModel` (SQLAlchemy models for `skills` and `skill_items` tables) - `SkillRepository` (full CRUD with session-factory pattern) - `SkillRegistryService` (service layer wrapping the repo) - Alembic migrations (`c0_001`, `c0_002`, `m4_002`) The **wiring** between the CLI and the database layer was missing. ### Fix 1. **`SkillService`** now accepts optional `skill_repo` + `session_factory` parameters. When provided, `add_skill()` and `remove_skill()` persist to DB alongside the in-memory dict. The constructor pre-loads existing skills from DB rows. 2. **`_get_skill_service()`** in CLI creates a DB-backed service following the same `engine → sessionmaker → repository` pattern used by `tool.py`. 3. **`_reset_skill_service()`** now installs a fresh in-memory `SkillService` instead of `None` to avoid parallel test runner interference. ### Test Results | Gate | Result | |------|--------| | `nox -s lint` | Passed | | `nox -s typecheck` | 0 errors | | `nox -s unit_tests` | 9110 scenarios passed | | `nox -s coverage_report` | 97% | | Integration tests | Skill tests all passed | ### Subtask Status - [x] Investigation — root cause identified - [x] Implementation — CLI wired to DB via SkillRepository - [x] Behave BDD tests — 4 scenarios in `features/skill_add_persist.feature` - [x] Robot Framework tests — 3 smoke tests in `robot/skill_add_persist.robot` - [x] ASV benchmark — `benchmarks/skill_add_persist_bench.py` - [x] All quality gates passed
Owner

closed by pr #640

closed by pr #640
Author
Member

Here is how to replicate this bug:

Given

Check out branch b90f2cccdcf0ddb84f0c7fa05 of CleverAgents.

Start a terminal

Type

cd ~
mkdir data
uv venv
source .venv/bin/activate
uv pip install -e /app
agents init --yes
agents skill add --config /app/examples/skills/single-tool.yaml

Notice that the agents skill add command reports that it is successful.

When

agents skill list

Expected

The skill added when agents skill add --config /app/examples/skills/single-tool.yaml was listed should appear.

Actual

(devuser) ➜  ~ agents skill list
2026-03-12 23:56:41 [debug    ] Starting attempt               attempt_number=1 outcome=None
No skills found.
Register one with 'agents skill add --config <file>'
Here is how to replicate this bug: # Given Check out branch `b90f2cccdcf0ddb84f0c7fa05` of CleverAgents. Start a terminal Type ``` cd ~ mkdir data uv venv source .venv/bin/activate uv pip install -e /app agents init --yes agents skill add --config /app/examples/skills/single-tool.yaml ``` Notice that the `agents skill add` command reports that it is successful. # When `agents skill list` # Expected The skill added when `agents skill add --config /app/examples/skills/single-tool.yaml` was listed should appear. # Actual ``` (devuser) ➜ ~ agents skill list 2026-03-12 23:56:41 [debug ] Starting attempt attempt_number=1 outcome=None No skills found. Register one with 'agents skill add --config <file>' ```
Owner

PM Status — Day 34: Regression Report

@brent.edwards reported a regression on Day 33 — the bug appears to still be present after PR #640 was merged. agents skill list returns "No skills found" after agents skill add.

History

  • Day 27: Bug reported by Brent. TDD counterpart #637 created.
  • Day 28: Root cause identified (in-memory SkillService). Fix implemented in PR #640 by @freemo.
  • Day 28: PR #640 reportedly merged. Issue was marked "closed by PR #640."
  • Day 33: @brent.edwards reports the bug is still present on commit b90f2ccc — skill add succeeds silently but skill list shows nothing.

Analysis

This issue is currently marked State/In Review and is still open. The regression report indicates that either:

  1. PR #640 was reverted or overwritten by a later merge, or
  2. The fix in PR #640 was incomplete (e.g., works in-process but not cross-process), or
  3. The test commit Brent is using predates the fix.

Required Action

@freemo — Please investigate the regression. Check whether PR #640's changes are present on master at commit b90f2ccc. If the fix was lost, this needs to be re-applied. Bug #620 remains Priority/Critical and blocks M3 closure.

TDD counterpart: #637 (status unknown — please verify).


PM status comment — Day 34

## PM Status — Day 34: Regression Report @brent.edwards reported a regression on Day 33 — the bug appears to still be present after PR #640 was merged. `agents skill list` returns "No skills found" after `agents skill add`. ### History - **Day 27**: Bug reported by Brent. TDD counterpart #637 created. - **Day 28**: Root cause identified (in-memory `SkillService`). Fix implemented in PR #640 by @freemo. - **Day 28**: PR #640 reportedly merged. Issue was marked "closed by PR #640." - **Day 33**: @brent.edwards reports the bug is **still present** on commit `b90f2ccc` — skill add succeeds silently but `skill list` shows nothing. ### Analysis This issue is currently marked `State/In Review` and is still open. The regression report indicates that either: 1. PR #640 was reverted or overwritten by a later merge, or 2. The fix in PR #640 was incomplete (e.g., works in-process but not cross-process), or 3. The test commit Brent is using predates the fix. ### Required Action @freemo — Please investigate the regression. Check whether PR #640's changes are present on master at commit `b90f2ccc`. If the fix was lost, this needs to be re-applied. Bug #620 remains **Priority/Critical** and blocks M3 closure. **TDD counterpart**: #637 (status unknown — please verify). --- *PM status comment — Day 34*
Owner

PM Status — Day 36: Regression Follow-up

REGRESSION STILL UNRESOLVED. Day 34 identified that bug #620 regressed despite PR #640 being merged. No follow-up investigation has been posted.

Status escalation:

Item Status
Original fix (PR #640) Merged Day 28
Regression report (@brent.edwards) Day 33
PM regression acknowledgment Day 34
Investigation result MISSING — 2 days overdue

Action required — CRITICAL:

@freemo — This is now 2 days overdue. Please investigate immediately:

  1. Verify whether PR #640's changes are present on current master. Run git log --oneline --all -- src/cleveragents/application/services/skill_service.py to check.
  2. If the fix was reverted or overwritten by a later merge, the changes need to be re-applied.
  3. If the fix is present but insufficient (e.g., works in-process but not cross-process due to the in-memory OrderedDict still being primary), the fix strategy needs revision.

Impact: This bug blocks M3 (v3.2.0) closure. M3 is now 18 days past target (due 2026-02-26).

TDD counterpart: #637 — status should also be verified. If the TDD tests pass despite the bug persisting, the tests may be insufficient.


PM status comment — Day 36

## PM Status — Day 36: Regression Follow-up **REGRESSION STILL UNRESOLVED.** Day 34 identified that bug #620 regressed despite PR #640 being merged. No follow-up investigation has been posted. **Status escalation:** | Item | Status | |------|--------| | Original fix (PR #640) | Merged Day 28 | | Regression report (@brent.edwards) | Day 33 | | PM regression acknowledgment | Day 34 | | Investigation result | **MISSING — 2 days overdue** | **Action required — CRITICAL:** @freemo — This is now 2 days overdue. Please investigate immediately: 1. Verify whether PR #640's changes are present on current master. Run `git log --oneline --all -- src/cleveragents/application/services/skill_service.py` to check. 2. If the fix was reverted or overwritten by a later merge, the changes need to be re-applied. 3. If the fix is present but insufficient (e.g., works in-process but not cross-process due to the in-memory `OrderedDict` still being primary), the fix strategy needs revision. **Impact**: This bug blocks M3 (v3.2.0) closure. M3 is now **18 days past target** (due 2026-02-26). **TDD counterpart**: #637 — status should also be verified. If the TDD tests pass despite the bug persisting, the tests may be insufficient. --- *PM status comment — Day 36*
Owner

Regression confirmed — new bug #980 created with full TDD workflow.

@brent.edwards, your regression report on Day 33 has been verified and escalated. The fix from PR #640 did not resolve the underlying issue.

Actions taken:

  1. Created regression bug #980: bug(skill): skill add regression — persistence fix from PR #640 did not resolve the issue
  2. Created TDD counterpart #981: TDD: Write failing test for #980 — skill add cross-process persistence
  3. Assigned TDD #981 to @hamza.khyari (independent verification)
  4. Assigned bug fix #980 to @CoreRasurae (Python architecture expertise)
  5. Both assigned to v3.2.0 (M3) milestone — Critical priority

Key insight for the TDD test: The original TDD tests (#637) likely pass because they verify in-process behavior (same CLI invocation). The regression manifests only across separate process invocations. The new TDD test (#981) explicitly requires subprocess-based verification.

This issue (#620) remains open as the original bug. The regression bug #980 tracks the specific investigation and fix needed post-PR-#640. Once #980 is fixed and merged, both issues should be closable.

Investigation status: 4 days overdue. M3 is now 18 days past target. This regression is one of the primary blockers.

**Regression confirmed — new bug #980 created with full TDD workflow.** @brent.edwards, your regression report on Day 33 has been verified and escalated. The fix from PR #640 did not resolve the underlying issue. **Actions taken:** 1. Created regression bug #980: `bug(skill): skill add regression — persistence fix from PR #640 did not resolve the issue` 2. Created TDD counterpart #981: `TDD: Write failing test for #980 — skill add cross-process persistence` 3. Assigned TDD #981 to @hamza.khyari (independent verification) 4. Assigned bug fix #980 to @CoreRasurae (Python architecture expertise) 5. Both assigned to v3.2.0 (M3) milestone — Critical priority **Key insight for the TDD test:** The original TDD tests (#637) likely pass because they verify in-process behavior (same CLI invocation). The regression manifests only across separate process invocations. The new TDD test (#981) explicitly requires subprocess-based verification. **This issue (#620) remains open** as the original bug. The regression bug #980 tracks the specific investigation and fix needed post-PR-#640. Once #980 is fixed and merged, both issues should be closable. **Investigation status: 4 days overdue.** M3 is now 18 days past target. This regression is one of the primary blockers.
Owner

PM Status — Day 37

Status: REGRESSION CONFIRMED — new tracking issues created.

Timeline:

  • Day 28: Original fix PR #640 merged
  • Day 33: @brent.edwards reported regression (skill add still not persisting cross-process)
  • Day 36: Regression confirmed. New bug #980 + TDD #981 created

Current assignments:

  • Bug fix #980 → @CoreRasurae (Python architecture expertise)
  • TDD #981 → @hamza.khyari (independent verification, subprocess-based test)
  • Both Priority/Critical, v3.2.0 (M3)

Key insight: Original TDD tests (#637) verify in-process behavior only. The regression manifests across separate CLI invocations. New TDD #981 requires subprocess-based verification.

Action items:

  1. @hamza.khyari: Complete TDD #981 (failing cross-process test)
  2. @CoreRasurae: Fix #980 once TDD test is available
  3. @freemo: Original investigation still 4+ days overdue. M3 is 18+ days past target.

This issue remains open until #980 is resolved and merged.


PM status comment — Day 37

## PM Status — Day 37 **Status:** REGRESSION CONFIRMED — new tracking issues created. **Timeline:** - Day 28: Original fix PR #640 merged - Day 33: @brent.edwards reported regression (skill add still not persisting cross-process) - Day 36: Regression confirmed. New bug #980 + TDD #981 created **Current assignments:** - Bug fix #980 → @CoreRasurae (Python architecture expertise) - TDD #981 → @hamza.khyari (independent verification, subprocess-based test) - Both Priority/Critical, v3.2.0 (M3) **Key insight:** Original TDD tests (#637) verify in-process behavior only. The regression manifests across separate CLI invocations. New TDD #981 requires subprocess-based verification. **Action items:** 1. **@hamza.khyari:** Complete TDD #981 (failing cross-process test) 2. **@CoreRasurae:** Fix #980 once TDD test is available 3. **@freemo:** Original investigation still 4+ days overdue. M3 is 18+ days past target. **This issue remains open** until #980 is resolved and merged. --- *PM status comment — Day 37*
Owner

TDD workflow initiated for this bug:

  • Created TDD issue #1091 to write a tagged test that captures this bug.
  • Dependency link added: this issue is blocked by #1091.
  • Once #1091 is merged to master, the bug fix assignee should create the bugfix branch and implement the fix.
  • The fix must remove the @tdd_expected_fail tag from the test so it runs normally.
TDD workflow initiated for this bug: - Created TDD issue #1091 to write a tagged test that captures this bug. - Dependency link added: this issue is blocked by #1091. - Once #1091 is merged to `master`, the bug fix assignee should create the bugfix branch and implement the fix. - The fix must remove the `@tdd_expected_fail` tag from the test so it runs normally.
Owner

Day 43 Status Update — Skill Add Bug Pipeline

This bug has a complex history that spans multiple issues and PRs. Here is the current consolidated status:

TDD Workflow Status

Component Issue PR Status
Original bug #620 (fixed by PR #640, then regressed) Open — regression confirmed
Regression bug #980 PR #1120 (bugfix/m3-skill-add-regression) PR open, mergeable, reviewed
TDD for regression #981 / #1091 PR #1110 (tdd/m3-skill-add-regression) APPROVED — awaiting 2nd review
Bug fix for regression #980 PR #1120 Reviewed — awaiting 2 peer approvals

Summary

The original fix (PR #640) resolved the symptoms but did not address the root cause — the SkillRepository session was not committed and the skills table was not explicitly created. Bug #980 tracks the regression with a proper root cause analysis.

The TDD test (PR #1110) correctly captures the cross-process persistence failure. The fix (PR #1120) adds explicit table creation checks and auto_commit support in SkillRepository.

Remaining Actions

  1. PR #1110 needs a 2nd approving review from @hamza.khyari or @brent.edwards
  2. PR #1120 needs 2 approving reviews from @hamza.khyari and @brent.edwards
  3. Once both PRs merge, this issue (#620) and #980 should be closed

@freemo — assigned as fix developer. @brent.edwards — assigned as TDD developer.

**Day 43 Status Update — Skill Add Bug Pipeline** This bug has a complex history that spans multiple issues and PRs. Here is the current consolidated status: ## TDD Workflow Status | Component | Issue | PR | Status | |---|---|---|---| | **Original bug** | #620 | (fixed by PR #640, then regressed) | Open — regression confirmed | | **Regression bug** | #980 | PR #1120 (bugfix/m3-skill-add-regression) | PR open, mergeable, reviewed | | **TDD for regression** | #981 / #1091 | PR #1110 (tdd/m3-skill-add-regression) | **APPROVED** — awaiting 2nd review | | **Bug fix for regression** | #980 | PR #1120 | Reviewed — awaiting 2 peer approvals | ## Summary The original fix (PR #640) resolved the symptoms but did not address the root cause — the `SkillRepository` session was not committed and the skills table was not explicitly created. Bug #980 tracks the regression with a proper root cause analysis. The TDD test (PR #1110) correctly captures the cross-process persistence failure. The fix (PR #1120) adds explicit table creation checks and `auto_commit` support in `SkillRepository`. ## Remaining Actions 1. **PR #1110** needs a 2nd approving review from @hamza.khyari or @brent.edwards 2. **PR #1120** needs 2 approving reviews from @hamza.khyari and @brent.edwards 3. Once both PRs merge, this issue (#620) and #980 should be closed @freemo — assigned as fix developer. @brent.edwards — assigned as TDD developer.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
cleveragents/cleveragents-core#620
No description provided.