Bug: `gh aw logs` and `gh aw status` ignore `--repo` and fail without local .github/workflows

[rabo-unumed]

Summary

When using gh aw logs or gh aw status and specifying the --repo flag to operate on a remote repository, both commands unexpectedly depend on local .github/workflows resolution or the current working directory. As a result, the commands fail if the local directory does not contain .github/workflows, even though --repo was intended to direct all resolution to the remote repo. This makes remote and cross-repo use of these commands unreliable.

Failure Modes

gh aw status --repo <owner>/<repo>

• Expected: Lists workflows and their status for the target repo, regardless of the caller's working directory.
• Actual: Tries to enumerate local .github/workflows/*.md files first. If no such files or directory exist locally, it errors or shows nothing even if the remote repo has workflows.
• User Impact: Impossible to run gh aw status for another repository unless you have a checked-out working tree for that repo in your current directory.

gh aw logs --repo <owner>/<repo> [workflow]

• Expected: Retrieves and displays logs for workflows in the target repo regardless of local files.
• Actual: If a positional workflow name/path is specified, attempts to resolve it using local filesystem rules (e.g., .github/workflows) even with --repo. Fails unless the correct files/directories exist locally.
• User Impact: Cross-repo log review and scripting (e.g., CI, MCP tools) breaks unless the exact directory structure exists locally.

Diagnostic Evidence

• status: Calls getMarkdownWorkflowFiles("") even when --repo is set, e.g.:

  // status_command.go
  mdFiles, err := getMarkdownWorkflowFiles("")

• logs/positional workflow: Resolves file or name using the local filesystem:

  // resolver.go
  if _, err := os.Stat(searchPath); err == nil { ... }
  // Or in workflows.go
  if _, err := os.Stat(fileOrWorkflowName); err == nil { ... }

• Both: Only after these (potentially failing) local calls is --repo passed down to the GitHub API layer.

Full indexed locations for reference:

• status_command.go usage
• resolver.go logic
• workflows.go workflow file lookup

Severity

• This breaks remote, CI, MCP-server, and scripting/automation use cases relying on the documented --repo support.
• Impacts anyone using gh aw for non-local/remote repo investigation or automation.

Steps to Reproduce

1. Run gh aw status --repo github/gh-aw from any directory not containing a .github/workflows folder.
   • Expected: Should list remote workflows
   • Actual: Errors or empty list.
2. Run gh aw logs --repo github/gh-aw PR-review-helper from a directory without local workflows.
   • Expected: Should show workflow run logs for the named workflow from the remote repo
   • Actual: Fails with a message indicating missing local files or .github/workflows directory.

Proposed Fix

• Both commands should entirely bypass local workflow resolution/discovery when --repo is provided, and resolve workflow names/paths remotely using only the specified repo.
• logs and status should mirror the behavior of list (which does operate remotely) and only use local state if no --repo is set.

Environment

• gh-aw version: [latest/main]
• OS: [all]

---

Related code search references:

• ResolveWorkflowPath
• getMarkdownWorkflowFiles
• status_command.go
• workflows.go
• resolver.go

_{Reported by user: @rabo-unumed (via Copilot Issue Agent)}