Improve Command Listing Behavior (Groups, Namespace, and Scope Resolution)

[gbenm]

Improve Command Listing Behavior (Groups, Namespace, and Scope Resolution)

We need to formalize and improve how commands are listed, especially regarding group and namespace behavior.

1. Groups Become Mandatory Entry Points

If a file defines a group, then all commands inside that file must only be accessible through that group.

This means:

• Even if the file is inside the project directory,
• If the file defines a group,
• Then its commands cannot be listed or executed directly at the root level.

They must always be accessed via:

fire [namespace] group command

In other words, defining a group promotes it to a required command scope.

---

2. Namespace Becomes Optional Inside Its Own Directory

When executing commands inside a directory that has a namespace defined:

• The namespace becomes optional.
• All groups are listed at the top level.

Example

If we are inside a directory with:

namespace: myapp

Then commands should be usable as:

fire group command

Instead of:

fire myapp group command

However, from outside that directory, the namespace remains required:

fire myapp group command

---

3. Commands Without Group

Commands that do not belong to a group should:

• Always be listed under their namespace
• Or, if inside the local namespace directory, be accessible without explicitly specifying the namespace

Behavior Summary

• Inside namespace directory:
  • group commands → listed at top level
  • non-group commands → available without needing namespace
• Outside namespace directory:
  • group commands → require namespace + group
  • non-group commands → require namespace

---

Expected Outcome

• Clear and predictable command resolution
• Consistent separation between namespace and group
• Logical behavior depending on current working directory
• No accidental exposure of grouped commands at root level