Minimal workspace runtime omits abilities required by mutating CLI commands

[chubes4]

Problem

DMC 0.59.12 classifies every datamachine-code workspace request as a minimal runtime request. datamachine_code_bootstrap() returns for that profile before constructing WorkspaceAbilities, but mutating CLI routes such as worktree add still dispatch through wp_get_ability().

Live reproduction after upgrading from 0.59.9 to 0.59.12:

$ studio wp datamachine-code workspace worktree add data-machine-code fix/example ...
Error: Worktree ability not available: datamachine-code/workspace-worktree-add

This prevents DMC from creating managed repair worktrees and blocks Homeboy provider ensure.

Acceptance

• Minimal synchronous workspace commands retain the specific workspace abilities required by CLI dispatch.
• Unrelated runtime integrations and deferred shutdown work remain disabled.
• worktree add reaches and executes its registered ability under the minimal profile.
• Targeted worktree get remains direct and does not require Abilities.
• An executable contract test covers mutation dispatch, not only command registration.

Found while implementing #1076.

AI assistance

OpenAI GPT-5.6-sol via OpenCode reproduced the release regression, traced CLI dispatch and bootstrap classification, and drafted this issue. Chris Huber remains responsible for the report and implementation.

[chubes4]

Live v0.60.0 validation shows PR #1079 restored construction but not registration:

Error: Worktree ability not available: datamachine-code/workspace-worktree-add

Root cause: WorkspaceAbilities::__construct() calls registerAbilities() immediately whenever wp_register_ability() exists. In WordPress 7.1 the function exists before the lazy abilities registry is initialized, while wp_register_ability() accepts registration only during wp_abilities_api_init. The early calls are rejected; later wp_get_ability() initializes an empty registry.

The constructor needs the current lifecycle contract: register immediately only while doing_action( wp_abilities_api_init ); defer when the hook has not fired; handle an already-initialized registry explicitly. The regression test must execute against lifecycle-aware wp_register_ability/wp_get_ability stubs and prove the add ability is retrievable, not only that the class was instantiated.

AI assistance: OpenAI GPT-5.6-sol via OpenCode ran the released plugin against WordPress 7.1, traced Core’s lazy registry initialization, and identified the invalid registration window. Chris Huber remains responsible for this diagnosis.

[chubes4]

Post-merge validation on the released copied runtime v0.60.1 still fails the mutating workspace ability route:

studio wp datamachine-code workspace git pull data-machine-code --allow-primary-refresh
Error: Workspace git ability not available: datamachine-code/workspace-git-pull

Evidence:

• studio wp datamachine-code runtime doctor --format=json reports active copied deployment version 0.60.1.
• origin/main contains PR fix(abilities): register workspace surface in lifecycle #1082 followed by release commit v0.60.1.
• workspace git --help advertises the pull operation and --allow-primary-refresh, but executable dispatch cannot retrieve the ability.
• Direct worktree get remains available and allowed the recovered Homeboy promotion after its lookup budget was raised; this residual defect specifically blocks canonical managed-primary refresh.

The acceptance contract still needs a real released-runtime WP-CLI invocation proving workspace-git-pull is retrievable after normal WordPress bootstrap, not only lifecycle-aware stubs.

AI assistance: OpenAI openai/gpt-5.6-sol via OpenCode verified the active release identity, reproduced the post-#1082 failure, distinguished it from direct worktree resolution, and drafted this evidence update. Chris Huber reviewed and remains responsible.