feat(resource): add fs-mount and fs-file resource types #833

Open
opened 2026-03-13 20:16:03 +00:00 by freemo · 0 comments
Owner

Metadata

  • Commit Message: feat(resource): add fs-mount and fs-file resource types
  • Branch: feature/fs-mount-file-types
  • Type: Feature
  • Priority: Medium
  • MoSCoW: Should have
  • Points: 5
  • Milestone: v3.6.0

Background and Context

The specification defines fs-mount and fs-file as built-in physical resource types. Both are present in the BUILTIN_NAMES constant in the resource schema but are never registered in the bootstrap process. The existing filesystem types are fs-directory (registered and working) and fs-symlink/fs-hardlink (covered by open issue #330).

  • fs-mount — Represents a filesystem mount point (bind mount, NFS, tmpfs, etc.)
  • fs-file — Represents an individual file with metadata (size, permissions, content hash)

fs-file is particularly important as it's the leaf node of the filesystem resource hierarchy and is referenced by virtual resource type file for equivalence tracking.

Acceptance Criteria

  • YAML resource type definitions for fs-mount and fs-file under examples/resource-types/
  • fs-file has correct parent relationship (child of fs-directory)
  • fs-mount has correct scope metadata (mount point, device, filesystem type)
  • Auto-discovery rules detect mount points (from /proc/mounts or df) and files within fs-directory resources
  • Bootstrap registration includes both types
  • fs-file includes content hash metadata for equivalence tracking

Definition of Done

This issue is complete when:

  • All subtasks below 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.
  • 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.

Subtasks

  • Create YAML resource type definitions for fs-mount and fs-file
  • Define parent/child relationships (fs-file -> fs-directory, fs-mount -> parent scope)
  • Add content hash metadata to fs-file for equivalence
  • Implement auto-discovery rules
  • Register types in bootstrap
  • Tests (Behave): Add scenarios for type registration and hierarchy validation
  • Tests (Robot): Add integration test for fs-file discovery within a directory
  • Verify coverage >=97% via nox -s coverage_report
  • Run nox (all default sessions), fix any errors
## Metadata - **Commit Message**: `feat(resource): add fs-mount and fs-file resource types` - **Branch**: `feature/fs-mount-file-types` - **Type**: Feature - **Priority**: Medium - **MoSCoW**: Should have - **Points**: 5 - **Milestone**: v3.6.0 ## Background and Context The specification defines `fs-mount` and `fs-file` as built-in physical resource types. Both are present in the `BUILTIN_NAMES` constant in the resource schema but are **never registered** in the bootstrap process. The existing filesystem types are `fs-directory` (registered and working) and `fs-symlink`/`fs-hardlink` (covered by open issue #330). - `fs-mount` — Represents a filesystem mount point (bind mount, NFS, tmpfs, etc.) - `fs-file` — Represents an individual file with metadata (size, permissions, content hash) `fs-file` is particularly important as it's the leaf node of the filesystem resource hierarchy and is referenced by virtual resource type `file` for equivalence tracking. ## Acceptance Criteria - [ ] YAML resource type definitions for fs-mount and fs-file under `examples/resource-types/` - [ ] fs-file has correct parent relationship (child of fs-directory) - [ ] fs-mount has correct scope metadata (mount point, device, filesystem type) - [ ] Auto-discovery rules detect mount points (from /proc/mounts or df) and files within fs-directory resources - [ ] Bootstrap registration includes both types - [ ] fs-file includes content hash metadata for equivalence tracking ## Definition of Done This issue is complete when: - All subtasks below 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. - 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. ## Subtasks - [ ] Create YAML resource type definitions for fs-mount and fs-file - [ ] Define parent/child relationships (fs-file -> fs-directory, fs-mount -> parent scope) - [ ] Add content hash metadata to fs-file for equivalence - [ ] Implement auto-discovery rules - [ ] Register types in bootstrap - [ ] Tests (Behave): Add scenarios for type registration and hierarchy validation - [ ] Tests (Robot): Add integration test for fs-file discovery within a directory - [ ] Verify coverage >=97% via `nox -s coverage_report` - [ ] Run `nox` (all default sessions), fix any errors
freemo added this to the v3.6.0 milestone 2026-03-13 20:20:03 +00:00
freemo self-assigned this 2026-04-02 06:14:00 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#398 Epic: Post-MVP Resources
cleveragents/cleveragents-core
Reference
cleveragents/cleveragents-core#833
No description provided.