[Bug] Module install state can report installed while commands remain unavailable

[djm81]

Describe the Bug

SpecFact module installation and runtime availability can disagree. A workflow module can physically exist under a module root, while the next command invocation still reports the provided command group as not installed. Running specfact module install ... can then say the module is already installed or already available, leaving the user in a loop.

The investigation found multiple inconsistent decision points:

• install skip logic treats an existing module-package.yaml as success without reconciling modules.json enablement;
• missing-command help reports every absent command group as "not installed", even when the module may be disabled, shadowed, incompatible, dependency-skipped, or failed integrity/schema checks;
• specfact init --profile ... rewrites global module state from the current discovery view, while discovery is cwd-sensitive for project module roots;
• install normalization and discovery/state identifiers can differ between bare names, specfact/<name>, and manifest names such as nold-ai/specfact-codebase.

To Reproduce

Steps observed/reported:

specfact init --profile solo-developer
specfact code --help
specfact module install nold-ai/specfact-codebase
specfact init --profile solo-developer

Additional variants that appear to worsen the issue:

cd /path/to/repo-a
specfact module install nold-ai/specfact-codebase --scope project

cd /path/to/repo-b
specfact init --profile solo-developer
specfact code --help

Expected Behavior

SpecFact should have one coherent module availability contract:

• if a module is physically present but disabled, install should enable it or clearly report that it is installed but disabled;
• if a command group is unavailable, diagnostics should identify the reason, not just say "not installed";
• init/profile flows should not silently remove or disable unrelated modules based on cwd-dependent discovery;
• project/user scope shadowing should be explicit and should not make global state appear unreliable.

Actual Behavior

A command group can be reported as not installed, while specfact module install ... reports the module as already installed or already available. Reinstalling sometimes temporarily fixes the state, but repeated install/init/profile operations from different paths or environments can make another module appear unavailable.

Environment

• OS: Linux
• Python Version: observed in Python 3.11 runtime
• SpecFact CLI Version: current dev/runtime around 0.46.x
• Installation Method: observed across source checkout and installed user runtime scenarios

Command Output

Module 'nold-ai/specfact-codebase' is not installed.
Install with specfact module install nold-ai/specfact-codebase, or run specfact init --profile <profile> to install bundles.

Module 'specfact-codebase' is already installed in /home/<user>/.specfact/modules.
# or
Module 'specfact-codebase' is already available from source 'user'. No marketplace install needed.

Codebase Context (for brownfield issues)

Not brownfield-codebase-specific. This affects SpecFact CLI module lifecycle, discovery, init/profile bootstrap, and command registration.

Additional Context

Initial analysis points to these source areas:

• src/specfact_cli/modules/module_registry/src/commands.py install skip and scope resolution;
• src/specfact_cli/registry/module_packages.py state merge, runtime registration, and installed bundle detection;
• src/specfact_cli/registry/module_discovery.py cwd-derived project root precedence;
• src/specfact_cli/modules/init/src/commands.py profile install and global state rewrite;
• src/specfact_cli/cli.py missing-command diagnostics.

Parent feature candidate: #353 [Feature] Marketplace Module Distribution.

Source tracking:

• Reported from direct user workflow feedback on 2026-04-28.
• Follow-up OpenSpec change will be synced as a linked user story.

[djm81]

Synced OpenSpec user story: #534. OpenSpec change: marketplace-07-module-install-state-consistency. Parent feature: #353.