resource-management

Feature: ResourceX Concepts ResourceX is the resource system that powers RoleX's content management. Resources are typed content bundles identified by tag and digest, stored locally in a CAS (Content-Addressable Storage) or in a remote registry.

Scenario: What is a resource Given a resource is a directory containing content and metadata Then it has a resource.json manifest defining name, type, tag, and author And it contains content files specific to its type (e.g. .feature files, SKILL.md) And it is identified by a locator string

Scenario: Tag + digest model Given ResourceX uses a tag + digest model similar to Docker Then tag is a human-readable label — like "stable" or "0.1.0" And tag is mutable — the same tag can point to different content over time And digest is a sha256 content fingerprint — deterministic and immutable And digest is computed from the archive's file-level hashes And the format is sha256:<64-char-hex> And content uniqueness is guaranteed by digest, not by tag

Scenario: Locator formats Given a locator is how you reference a resource Then it can be just a name — nuwa (tag defaults to latest) And it can be a name with digest — name@sha256:abc123... And it can include a path — path/name:tag (e.g. prompts/hello:stable) And it can include a registry — registry.example.com/name:tag And it can be a local directory path — ./path/to/resource or /absolute/path And when tag is omitted, it defaults to latest

Scenario: Resource types in RoleX Given RoleX registers resource types with ResourceX Then "role" type — individual manifests with .feature files (alias: "individual") And "organization" type — organization manifests with .feature files (alias: "org") And "skill" type — SKILL.md files loaded via the skill process

Scenario: resource.json structure Given every resource directory must contain a resource.json Then the structure is: """ { "name": "my-resource", "type": "role", "tag": "0.1.0", "author": "deepractice", "description": "What this resource is" } """ And name is the resource identifier And type determines how the resource is resolved (role, organization, skill) And tag is a human-readable label, not a semantic version — omit for latest

Scenario: Storage location Given resources are stored locally at ~/.deepractice/resourcex by default And the location is configurable via LocalPlatform resourceDir option And prototype registrations are stored at ~/.deepractice/rolex/prototype.json

Feature: Resource Operations Manage resources through the use tool with !resource namespace. Operations cover the full lifecycle: add, push, pull, search, remove.

Scenario: add — import a resource from a local directory Given you have a resource directory with resource.json When you call use with !resource.add Then the resource is archived and stored in local CAS And it gets a digest computed from its content And it can then be pushed to a remote registry And parameters are: """ locator: "!resource.add" args: path: "/absolute/path/to/resource" """

Scenario: push — publish a resource to a remote registry Given a resource has been added to local CAS When you call use with !resource.push Then the resource archive is uploaded to the configured registry And the registry stores it by name, tag, and digest And parameters are: """ locator: "!resource.push" args: locator: "name:tag" registry: "https://..." # optional """

Scenario: pull — download a resource from a remote registry Given a resource exists in a remote registry When you call use with !resource.pull Then the resource is downloaded and cached in local CAS And subsequent resolves use the local cache And parameters are: """ locator: "!resource.pull" args: locator: "name:tag" """