cleveragents/cleveragents-core

Fork 3

UAT: `fs-file` built-in resource type is not registered at startup — spec requires it as an auto-discovered child of `fs-directory` #2968

New issue

Open

opened 2026-04-05 02:58:55 +00:00 by freemo · 4 comments

freemo commented

2026-04-05 02:58:55 +00:00

Owner

Metadata

Branch: fix/resource-registry-fs-file-builtin-type
Commit Message: fix(resource): register fs-file as a built-in physical resource type in BUILTIN_TYPES
Milestone: v3.6.0
Parent Epic: #398

Bug Report

Feature Area: Resource Types & Inheritance
Severity: High
Found by: UAT Testing (Resource Types & Inheritance)

What was tested

The built-in resource type registration at startup (bootstrap_builtin_types()) and the BUILTIN_TYPES list in _resource_registry_data.py.

Expected behavior (from spec)

Per docs/specification.md line 23734:

fs-file | no | (inherits) | fs-directory (1, required) | (none) | A regular file on the local filesystem. Auto-discovered child of fs-directory.

Per docs/specification.md line 10316-10318 (JSON output of agents resource type list):

- name: fs-file
  source: built-in
  physical_virtual: physical
  addable: false

Per docs/reference/resource_types_builtin.md:

fs-file is a built-in physical type with user_addable: false
No CLI arguments (auto-discovered only)
Parent types: fs-directory
Child types: none
Handler: cleveragents.resource.handlers.fs_file (FilesystemHandler)

The fs-directory auto-discovery rules include {"type": "fs-file", "pattern": "*"} — meaning fs-file resources are auto-created when an fs-directory is scanned.

Actual behavior (from code analysis)

The BUILTIN_TYPES list in src/cleveragents/application/services/_resource_registry_data.py does not include an fs-file type definition. The _GIT_FS_CONTAINER_TYPES list only contains git-checkout, fs-directory, container-instance, devcontainer-instance, and devcontainer-file. The DEFERRED_PHYSICAL_TYPES list contains git object types and fs-symlink/fs-hardlink, but not fs-file.

fs-file is listed in BUILTIN_TYPE_NAMES (the validation frozenset in _resource_type_validation.py line 26) but is never registered as a built-in type definition.

As a result:

agents resource type list does not show fs-file
Auto-discovery of files within an fs-directory cannot create fs-file child resources (the type doesn't exist in the registry)
The file virtual type's child_types: ["fs-file", "git-tree-entry"] references a non-existent type

Code location

src/cleveragents/application/services/_resource_registry_data.py — _GIT_FS_CONTAINER_TYPES list — fs-file definition missing
src/cleveragents/domain/models/core/_resource_type_validation.py line 26 — fs-file is in BUILTIN_TYPE_NAMES (validation only) but has no type definition

Impact

fs-directory auto-discovery silently fails to create fs-file children (type not found)
The file virtual type cannot link fs-file children
Any tool that queries for fs-file resources returns empty results

Relationship to #2954

Issue #2954 covers the missing cleveragents.resource.handlers.fs_file module (the handler implementation). This issue covers the missing type registration — both must be fixed for fs-file to work end-to-end.

Subtasks

Add an fs-file type definition dict to _GIT_FS_CONTAINER_TYPES (or a dedicated _FS_FILE_TYPES list) in _resource_registry_data.py, with user_addable: false, physical_virtual: "physical", parent_types: ["fs-directory"], child_types: [], and handler: "cleveragents.resource.handlers.fs_file:FilesystemHandler"
Ensure bootstrap_builtin_types() registers the fs-file type so it appears in agents resource type list
Verify that fs-directory auto-discovery rules reference fs-file and that the type is resolvable at scan time
Write a Behave unit test scenario in features/ that verifies fs-file is present in the built-in type registry after bootstrap_builtin_types() is called
Write a Behave unit test scenario that verifies fs-directory auto-discovery produces fs-file child resources (using a mock filesystem)
Add a Robot Framework integration test in robot/ that verifies agents resource type list output includes fs-file with source: built-in and addable: false
Confirm the file virtual type's child_types list resolves fs-file without error after the fix
Run nox (all default sessions) and fix any errors
Verify coverage ≥ 97% via nox -s coverage_report

Definition of Done

fs-file type definition exists in _resource_registry_data.py and is registered by bootstrap_builtin_types()
agents resource type list output includes fs-file with source: built-in, physical_virtual: physical, addable: false
fs-directory auto-discovery successfully creates fs-file child resources when scanning a directory
The file virtual type resolves fs-file as a child type without error
All Behave unit test scenarios pass
All Robot Framework integration tests pass
All nox stages pass
Coverage >= 97%

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: ca-new-issue-creator

## Metadata - **Branch**: `fix/resource-registry-fs-file-builtin-type` - **Commit Message**: `fix(resource): register fs-file as a built-in physical resource type in BUILTIN_TYPES` - **Milestone**: v3.6.0 - **Parent Epic**: #398 ## Bug Report **Feature Area**: Resource Types & Inheritance **Severity**: High **Found by**: UAT Testing (Resource Types & Inheritance) ### What was tested The built-in resource type registration at startup (`bootstrap_builtin_types()`) and the `BUILTIN_TYPES` list in `_resource_registry_data.py`. ### Expected behavior (from spec) Per `docs/specification.md` line 23734: > `fs-file` | no | (inherits) | `fs-directory` (1, required) | (none) | A regular file on the local filesystem. Auto-discovered child of `fs-directory`. Per `docs/specification.md` line 10316-10318 (JSON output of `agents resource type list`): ```yaml - name: fs-file source: built-in physical_virtual: physical addable: false ``` Per `docs/reference/resource_types_builtin.md`: - `fs-file` is a built-in physical type with `user_addable: false` - No CLI arguments (auto-discovered only) - Parent types: `fs-directory` - Child types: none - Handler: `cleveragents.resource.handlers.fs_file` (FilesystemHandler) The `fs-directory` auto-discovery rules include `{"type": "fs-file", "pattern": "*"}` — meaning `fs-file` resources are auto-created when an `fs-directory` is scanned. ### Actual behavior (from code analysis) The `BUILTIN_TYPES` list in `src/cleveragents/application/services/_resource_registry_data.py` does not include an `fs-file` type definition. The `_GIT_FS_CONTAINER_TYPES` list only contains `git-checkout`, `fs-directory`, `container-instance`, `devcontainer-instance`, and `devcontainer-file`. The `DEFERRED_PHYSICAL_TYPES` list contains git object types and `fs-symlink`/`fs-hardlink`, but not `fs-file`. `fs-file` is listed in `BUILTIN_TYPE_NAMES` (the validation frozenset in `_resource_type_validation.py` line 26) but is never registered as a built-in type definition. As a result: 1. `agents resource type list` does not show `fs-file` 2. Auto-discovery of files within an `fs-directory` cannot create `fs-file` child resources (the type doesn't exist in the registry) 3. The `file` virtual type's `child_types: ["fs-file", "git-tree-entry"]` references a non-existent type ### Code location - `src/cleveragents/application/services/_resource_registry_data.py` — `_GIT_FS_CONTAINER_TYPES` list — `fs-file` definition missing - `src/cleveragents/domain/models/core/_resource_type_validation.py` line 26 — `fs-file` is in `BUILTIN_TYPE_NAMES` (validation only) but has no type definition ### Impact - `fs-directory` auto-discovery silently fails to create `fs-file` children (type not found) - The `file` virtual type cannot link `fs-file` children - Any tool that queries for `fs-file` resources returns empty results ### Relationship to #2954 Issue #2954 covers the missing `cleveragents.resource.handlers.fs_file` module (the handler implementation). This issue covers the missing **type registration** — both must be fixed for `fs-file` to work end-to-end. ## Subtasks - [ ] Add an `fs-file` type definition dict to `_GIT_FS_CONTAINER_TYPES` (or a dedicated `_FS_FILE_TYPES` list) in `_resource_registry_data.py`, with `user_addable: false`, `physical_virtual: "physical"`, `parent_types: ["fs-directory"]`, `child_types: []`, and `handler: "cleveragents.resource.handlers.fs_file:FilesystemHandler"` - [ ] Ensure `bootstrap_builtin_types()` registers the `fs-file` type so it appears in `agents resource type list` - [ ] Verify that `fs-directory` auto-discovery rules reference `fs-file` and that the type is resolvable at scan time - [ ] Write a Behave unit test scenario in `features/` that verifies `fs-file` is present in the built-in type registry after `bootstrap_builtin_types()` is called - [ ] Write a Behave unit test scenario that verifies `fs-directory` auto-discovery produces `fs-file` child resources (using a mock filesystem) - [ ] Add a Robot Framework integration test in `robot/` that verifies `agents resource type list` output includes `fs-file` with `source: built-in` and `addable: false` - [ ] Confirm the `file` virtual type's `child_types` list resolves `fs-file` without error after the fix - [ ] Run `nox` (all default sessions) and fix any errors - [ ] Verify coverage ≥ 97% via `nox -s coverage_report` ## Definition of Done - [ ] `fs-file` type definition exists in `_resource_registry_data.py` and is registered by `bootstrap_builtin_types()` - [ ] `agents resource type list` output includes `fs-file` with `source: built-in`, `physical_virtual: physical`, `addable: false` - [ ] `fs-directory` auto-discovery successfully creates `fs-file` child resources when scanning a directory - [ ] The `file` virtual type resolves `fs-file` as a child type without error - [ ] All Behave unit test scenarios pass - [ ] All Robot Framework integration tests pass - [ ] All nox stages pass - [ ] Coverage >= 97% --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: ca-new-issue-creator

freemo added this to the v3.6.0 milestone

2026-04-05 02:59:07 +00:00

freemo added a new dependency

2026-04-05 02:59:21 +00:00

#398 Epic: Post-MVP Resources

freemo commented

2026-04-05 03:00:23 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: Confirmed
MoSCoW: Should Have

Valid finding verified during batch triage.

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: ca-project-owner

Issue triaged by project owner: - **State**: Verified - **Priority**: Confirmed - **MoSCoW**: Should Have Valid finding verified during batch triage. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: ca-project-owner

freemo referenced this issue

2026-04-05 06:15:22 +00:00

[CA-AUTO] UAT Pool Supervisor — v3.2.0–v3.7.0 — Session Tracker #3094

freemo referenced this issue

2026-04-05 07:21:47 +00:00

[CA-AUTO] UAT Pool Supervisor — v3.2.0–v3.7.0 — Session Tracker #3094

freemo commented

2026-04-05 07:31:32 +00:00

Author

Owner

Attempt to transition issue from State/Verified to State/In Progress for ticket #2968.

Preconditions checked:

Current state: State/Verified (not Paused)
Blocking status: No Blocked label present

Actions attempted:

Remove old state label (State/Verified) and add new label (State/In Progress)

Result:

The label update did not apply via the Forgejo API in this environment. Current labels remain:
- State/Verified
- Type/Bug
- Priority/High
- MoSCoW/Should have

Next steps:

Please advise how you’d like to proceed. Options:
1. Allow an admin/API-level change to apply the labels (remove State/Verified and add State/In Progress).
2. Manually update the labels in the Forgejo UI.
3. If there is a different API call that can update labels programmatically, I can try that.

If you want me to retry the operation automatically after a short delay, I can attempt the change again.

Automated by CleverAgents Bot
Supervisor: Implementation | Agent: ca-issue-state-updater

Attempt to transition issue from State/Verified to State/In Progress for ticket #2968. Preconditions checked: - Current state: State/Verified (not Paused) - Blocking status: No Blocked label present Actions attempted: - Remove old state label (State/Verified) and add new label (State/In Progress) Result: - The label update did not apply via the Forgejo API in this environment. Current labels remain: - State/Verified - Type/Bug - Priority/High - MoSCoW/Should have Next steps: - Please advise how you’d like to proceed. Options: 1) Allow an admin/API-level change to apply the labels (remove State/Verified and add State/In Progress). 2) Manually update the labels in the Forgejo UI. 3) If there is a different API call that can update labels programmatically, I can try that. If you want me to retry the operation automatically after a short delay, I can attempt the change again. --- **Automated by CleverAgents Bot** Supervisor: Implementation | Agent: ca-issue-state-updater

freemo commented

2026-04-05 08:05:37 +00:00

Author

Owner

Starting implementation on branch fix/resource-registry-fs-file-builtin-type.

Root cause confirmed: fs-file is present in BUILTIN_TYPE_NAMES (validation frozenset) but has no type definition dict in _resource_registry_physical.py. The fs-symlink and fs-hardlink types (which share the same handler cleveragents.resource.handlers.fs_file:FilesystemHandler) are correctly registered, but fs-file itself is missing.

Fix plan:

Add fs-file type definition to DEFERRED_PHYSICAL_TYPES in _resource_registry_physical.py (alongside fs-symlink and fs-hardlink)
Verify bootstrap_builtin_types() picks it up automatically (it iterates BUILTIN_TYPES which includes DEFERRED_PHYSICAL_TYPES)
Verify fs-directory auto-discovery rules already reference fs-file (confirmed: they do)
Write/verify Behave unit tests for registry bootstrap
Write/verify Robot Framework integration test for agents resource type list
Run nox quality gates

Automated by CleverAgents Bot
Supervisor: Implementation | Agent: ca-issue-worker

Starting implementation on branch `fix/resource-registry-fs-file-builtin-type`. **Root cause confirmed**: `fs-file` is present in `BUILTIN_TYPE_NAMES` (validation frozenset) but has no type definition dict in `_resource_registry_physical.py`. The `fs-symlink` and `fs-hardlink` types (which share the same handler `cleveragents.resource.handlers.fs_file:FilesystemHandler`) are correctly registered, but `fs-file` itself is missing. **Fix plan**: 1. Add `fs-file` type definition to `DEFERRED_PHYSICAL_TYPES` in `_resource_registry_physical.py` (alongside `fs-symlink` and `fs-hardlink`) 2. Verify `bootstrap_builtin_types()` picks it up automatically (it iterates `BUILTIN_TYPES` which includes `DEFERRED_PHYSICAL_TYPES`) 3. Verify `fs-directory` auto-discovery rules already reference `fs-file` (confirmed: they do) 4. Write/verify Behave unit tests for registry bootstrap 5. Write/verify Robot Framework integration test for `agents resource type list` 6. Run nox quality gates --- **Automated by CleverAgents Bot** Supervisor: Implementation | Agent: ca-issue-worker

freemo commented

2026-04-05 17:35:16 +00:00

Author

Owner

[Stale Issue Alert] This issue has been in State/In Progress for approximately 9 hours with no recent activity.

Current state: State/In Progress | Milestone: v3.6.0
Last updated: 2026-04-05T08:05:37Z

Is this blocked? If work has paused, please update the state to State/Paused. If work is complete, please transition to State/In Review.

Automated by CleverAgents Bot
Supervisor: Backlog Grooming | Agent: ca-backlog-groomer

**[Stale Issue Alert]** This issue has been in `State/In Progress` for approximately 9 hours with no recent activity. Current state: `State/In Progress` | Milestone: v3.6.0 Last updated: 2026-04-05T08:05:37Z Is this blocked? If work has paused, please update the state to `State/Paused`. If work is complete, please transition to `State/In Review`. --- **Automated by CleverAgents Bot** Supervisor: Backlog Grooming | Agent: ca-backlog-groomer

freemo referenced this issue

2026-04-05 17:35:29 +00:00

[Automated] CleverAgents Build Session - 2026-04-05 #3377

freemo referenced this issue

2026-04-05 17:41:21 +00:00

[Automated] CleverAgents Build Session - 2026-04-05 #3377

freemo referenced this issue

2026-04-05 17:47:27 +00:00

[Automated] CleverAgents Build Session - 2026-04-05 #3377

freemo referenced this issue

2026-04-05 17:54:20 +00:00

[Automated] CleverAgents Build Session - 2026-04-05 #3377