cleveragents/cleveragents-core

Fork 3

Same concept is called "path" in command, but "location" in output. #2626

New issue

Closed

opened 2026-04-03 20:41:52 +00:00 by brent.edwards · 8 comments

brent.edwards commented

2026-04-03 20:41:52 +00:00

Member

The command to add a new program is

agents resource add --description "The diff executable" executable diff --path "/usr/bin/diff"

When the command is listed in agents resource list, the result is:

                                  Resources (1 total)                                   
┏━━━━━━━━━━━━━━━━━┳━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┓
┃ ID              ┃ Name ┃ Type       ┃ Kind     ┃ Location      ┃ Description         ┃
┡━━━━━━━━━━━━━━━━━╇━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━┩
│ 01KNAGY5M0D8... │ diff │ executable │ physical │ /usr/bin/diff │ The diff executable │
└─────────────────┴──────┴────────────┴──────────┴───────────────┴─────────────────────┘

Should they match? And which word is better -- "path" or "location"?

The command to add a new program is ``` agents resource add --description "The diff executable" executable diff --path "/usr/bin/diff" ``` When the command is listed in `agents resource list`, the result is: ``` Resources (1 total) ┏━━━━━━━━━━━━━━━━━┳━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┓ ┃ ID ┃ Name ┃ Type ┃ Kind ┃ Location ┃ Description ┃ ┡━━━━━━━━━━━━━━━━━╇━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━┩ │ 01KNAGY5M0D8... │ diff │ executable │ physical │ /usr/bin/diff │ The diff executable │ └─────────────────┴──────┴────────────┴──────────┴───────────────┴─────────────────────┘ ``` Should they match? And which word is better -- "path" or "location"?

brent.edwards added the

labels

2026-04-03 20:41:52 +00:00

freemo commented

2026-04-04 19:10:36 +00:00

Owner

Thank you for reporting this inconsistency, @brent.edwards.

This issue is a proposal awaiting human review (needs feedback label). I will not modify its state — a human must approve or reject it.

Observation: You've identified a valid UX inconsistency. The CLI uses --path as the flag name when adding a resource, but the resource list output displays the same data under a Location column header. Per the specification, the terminology should be consistent across the CLI interface. A human reviewer should decide which term is canonical — path or location — and whether this is a CLI flag rename, an output column rename, or both.

Automated by CleverAgents Bot
Supervisor: Human Liaison | Agent: ca-human-liaison

Thank you for reporting this inconsistency, @brent.edwards. This issue is a proposal awaiting human review (`needs feedback` label). I will not modify its state — a human must approve or reject it. **Observation**: You've identified a valid UX inconsistency. The CLI uses `--path` as the flag name when adding a resource, but the `resource list` output displays the same data under a `Location` column header. Per the specification, the terminology should be consistent across the CLI interface. A human reviewer should decide which term is canonical — `path` or `location` — and whether this is a CLI flag rename, an output column rename, or both. --- **Automated by CleverAgents Bot** Supervisor: Human Liaison | Agent: ca-human-liaison

freemo referenced this issue

2026-04-04 20:29:40 +00:00

[CA-AUTO] Backlog Groomer — groomer-1 — Session Tracker #2771

freemo commented

2026-04-04 20:30:02 +00:00

Owner

Architect Assessment (architect-1)

The specification (docs/specification.md, lines 11048-11067) defines the agents resource list output columns as: Name, ID, Type, Phys/Virt, Children, Projects. There is no "Location" column in the spec.

The CLI flag for adding resources uses --path (e.g., agents resource add git-checkout local/api-repo --path /repos/api), which is consistent throughout the spec.

The domain model uses the term "location" in the glossary for physical resources ("a resource bound to a concrete, located artifact"), but the CLI consistently uses --path for the user-facing flag.

Recommendation: The implementation should match the spec. If a location/path column is desired in resource list output, it should be added to the spec first. The term --path is the correct CLI flag name (consistent with the spec). If a display column is added, "Path" would be more consistent with the CLI flag naming than "Location".

This is a minor spec compliance issue — the implementation added a column not defined in the spec. The fix should either (a) remove the extra column to match the spec, or (b) update the spec to include it (which would be a minor spec change).

**Architect Assessment** (architect-1) The specification (`docs/specification.md`, lines 11048-11067) defines the `agents resource list` output columns as: **Name, ID, Type, Phys/Virt, Children, Projects**. There is no "Location" column in the spec. The CLI flag for adding resources uses `--path` (e.g., `agents resource add git-checkout local/api-repo --path /repos/api`), which is consistent throughout the spec. The domain model uses the term "location" in the glossary for physical resources ("a resource bound to a concrete, **located** artifact"), but the CLI consistently uses `--path` for the user-facing flag. **Recommendation**: The implementation should match the spec. If a location/path column is desired in `resource list` output, it should be added to the spec first. The term `--path` is the correct CLI flag name (consistent with the spec). If a display column is added, "Path" would be more consistent with the CLI flag naming than "Location". This is a minor spec compliance issue — the implementation added a column not defined in the spec. The fix should either (a) remove the extra column to match the spec, or (b) update the spec to include it (which would be a minor spec change).

freemo commented

2026-04-04 20:34:12 +00:00

Owner

Label compliance fix applied:

Removed duplicate labels: Priority/Low (repo-level ID 1332), State/Unverified (repo-level ID 1320), Type/Bug (repo-level ID 1325)
Reason: Issue had duplicate org-level and repo-level labels for the same state/priority/type. Kept the org-level labels (IDs 861, 846, 849) as canonical.

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

Label compliance fix applied: - Removed duplicate labels: `Priority/Low` (repo-level ID 1332), `State/Unverified` (repo-level ID 1320), `Type/Bug` (repo-level ID 1325) - Reason: Issue had duplicate org-level and repo-level labels for the same state/priority/type. Kept the org-level labels (IDs 861, 846, 849) as canonical. --- **Automated by CleverAgents Bot** Supervisor: Backlog Grooming | Agent: ca-backlog-groomer

freemo referenced this issue

2026-04-04 20:36:40 +00:00

[CA-AUTO] Backlog Groomer — groomer-1 — Session Tracker #2771

freemo commented

2026-04-04 23:04:35 +00:00

Owner

Each resource-type can have its own custom arguments. In this case the executable resource type has its own argument called "--path" which is the path to the executable. The real problem here is two fold 1) when listing resources how should we gracefully show a resource-specific argument (table doesnt work for that if it shows all resource types and 2) I dont think executable has been added to the spec as a resource type at all, has it?

freemo commented

2026-04-05 04:50:10 +00:00

Owner

Good points, @freemo. To address both questions directly:

1. "executable" is not in the spec. The specification (docs/specification.md, lines 10567-10575) defines these resource types: git-checkout, git, fs-mount, fs-directory, fs-file, container-instance, and devcontainer-instance. There is no executable resource type. If executable was added to the implementation, it was done without a corresponding spec update. This needs a spec change before it can be considered a supported resource type.

2. The spec-defined resource list columns do not include "Location" or "Path". Per line 11051, the columns are: Name, ID, Type, Phys/Virt, Children, Projects. The current implementation appears to have added both the executable type and a Location column beyond what the spec defines.

Recommended path forward:

If executable is a desired resource type, a spec update should be proposed to add it (along with its custom arguments like --path).
The resource list output should match the spec columns. If resource-specific attributes (like path for executables) need to be visible, a resource show <name> detail view would be more appropriate than adding variable columns to the list table — as you noted, a table doesn't work well when different resource types have different custom arguments.
Until the spec is updated, the implementation should be brought into compliance with the current spec columns.

Should I create a spec update proposal for adding executable as a resource type, or should the implementation be corrected to remove it?

Automated by CleverAgents Bot
Supervisor: Human Liaison | Agent: ca-human-liaison

Good points, @freemo. To address both questions directly: **1. "executable" is not in the spec.** The specification (`docs/specification.md`, lines 10567-10575) defines these resource types: `git-checkout`, `git`, `fs-mount`, `fs-directory`, `fs-file`, `container-instance`, and `devcontainer-instance`. There is no `executable` resource type. If `executable` was added to the implementation, it was done without a corresponding spec update. This needs a spec change before it can be considered a supported resource type. **2. The spec-defined `resource list` columns do not include "Location" or "Path".** Per line 11051, the columns are: `Name`, `ID`, `Type`, `Phys/Virt`, `Children`, `Projects`. The current implementation appears to have added both the `executable` type and a `Location` column beyond what the spec defines. **Recommended path forward:** - If `executable` is a desired resource type, a spec update should be proposed to add it (along with its custom arguments like `--path`). - The `resource list` output should match the spec columns. If resource-specific attributes (like `path` for executables) need to be visible, a `resource show <name>` detail view would be more appropriate than adding variable columns to the list table — as you noted, a table doesn't work well when different resource types have different custom arguments. - Until the spec is updated, the implementation should be brought into compliance with the current spec columns. Should I create a spec update proposal for adding `executable` as a resource type, or should the implementation be corrected to remove it? --- **Automated by CleverAgents Bot** Supervisor: Human Liaison | Agent: ca-human-liaison

freemo commented

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

Owner

The implementation should remove executable entirely, as its not in the spec. Close this ticket and instead open a ticket to do this.

freemo commented

2026-04-05 05:22:44 +00:00

Owner

Understood. I will close this issue and create a new issue to remove the executable resource type from the implementation, since it is not defined in the specification.

Automated by CleverAgents Bot
Supervisor: Human Liaison | Agent: ca-human-liaison

Understood. I will close this issue and create a new issue to remove the `executable` resource type from the implementation, since it is not defined in the specification. --- **Automated by CleverAgents Bot** Supervisor: Human Liaison | Agent: ca-human-liaison

freemo referenced this issue

2026-04-05 05:22:58 +00:00

fix(resources): remove unsupported executable resource type from implementation #3077

freemo closed this issue

2026-04-05 05:22:59 +00:00

freemo commented

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

Owner

Closed per @freemo's directive. Replacement issue created: #3077 — fix(resources): remove unsupported executable resource type from implementation.

Automated by CleverAgents Bot
Supervisor: Human Liaison | Agent: ca-human-liaison

Closed per @freemo's directive. Replacement issue created: #3077 — `fix(resources): remove unsupported executable resource type from implementation`. --- **Automated by CleverAgents Bot** Supervisor: Human Liaison | Agent: ca-human-liaison

freemo referenced this issue

2026-04-05 05:24:04 +00:00

Task: Autonomous build progress report — 2026-04-05 #3075

freemo referenced this issue

2026-04-05 06:00:51 +00:00

fix(resources): remove unsupported executable resource type from implementation #3077