workspace git status / show: ability callbacks crash on non-pristine repo states (WP_Error return, null schema fields)

[chubes4]

Summary

Two related bugs in the workspace ability layer that crash when a repo is in any non-pristine state (no upstream, detached HEAD, etc). Both reproduce reliably and block agents from using the workspace tooling to inspect repo state before making changes.

Bug 1: datamachine/workspace-git-status fatals on WP_Error

Reproduction

studio wp datamachine-code workspace git status intelligence

Actual behavior

Error: Ability "datamachine/workspace-git-status" callback threw an exception:
DataMachineCode\Abilities\WorkspaceAbilities::gitStatus(): Return value must be of type array,
WP_Error returned

Root cause

Workspace::git_status() is typed array|\WP_Error (Workspace.php:337) but the ability callback:

public static function gitStatus( array $input ): array {
    $workspace = new Workspace();
    return $workspace->git_status( $input['name'] ?? '' );
}

is declared : array and returns the Workspace::git_status() result directly. When the underlying method returns WP_Error (e.g. on any git failure path), PHP throws a TypeError.

Fix

Either (a) widen the callback's return type and handle WP_Error in the output, or (b) catch WP_Error inside the callback and translate to an error-shaped array (['success' => false, 'error' => $err->get_error_message()]). Option (b) matches what most other ability callbacks do.

Same pattern likely affects other gitX callbacks that forward a Workspace method typed array|\WP_Error — worth auditing all of them:

• gitStatus (confirmed)
• gitPull, gitAdd, gitCommit, gitPush, gitBranch, gitCheckout, gitDiff, gitLog — all likely affected

---

Bug 2: datamachine/workspace-show rejects output when branch/remote are empty

Reproduction

On a workspace repo that's on a WIP branch without a configured upstream remote:

studio wp datamachine-code workspace show intelligence

Actual behavior

Error: Ability "datamachine/workspace-show" has invalid output.
Reason: output[branch] is not of type string.

Root cause

The workspace-show ability registers this output schema (WorkspaceAbilities.php:130):

'output_schema' => array(
    'type'       => 'object',
    'properties' => array(
        'success' => array( 'type' => 'boolean' ),
        'name'    => array( 'type' => 'string' ),
        'path'    => array( 'type' => 'string' ),
        'branch'  => array( 'type' => 'string' ),
        'remote'  => array( 'type' => 'string' ),
        'commit'  => array( 'type' => 'string' ),
        'dirty'   => array( 'type' => 'integer' ),
    ),
),

But Workspace::show_repo() legitimately returns null (or an empty/non-string value) for branch/remote in normal states: detached HEAD has no branch name, a newly-cloned local-only branch has no upstream remote. The Abilities API validates output against the declared schema and rejects these values.

Fix

Either:

• (a) Make the schema fields nullable — declare 'type' => array('string', 'null') for branch and remote. Most correct; reflects reality.
• (b) Coerce nulls to empty strings in show_repo() before returning. Simpler but lossy (consumer can't distinguish "no branch" from "branch named ''").

Recommendation: (a). The schema should tell the truth.

---

Why this matters

These two bugs together mean an agent cannot:

1. Check git state before operating on a workspace repo (bug 1)
2. Inspect what's in a workspace repo at all when it's on a feature branch without upstream (bug 2)

Which makes the workspace tooling effectively unusable for any repo that isn't freshly cloned and on a tracked branch. Hit both back-to-back while trying to pick up an in-progress feature/intelligence-search branch on ~/Developer/intelligence before starting new work on that repo.

Environment

• data-machine-code 0.4.0
• PHP 8.x (ability callback TypeError is a strict-types thing)
• macOS / Studio-hosted site, but not environment-specific