Handle guide-only repositories in wiki, docs, tests, metrics, and reports

[coisa]

Summary

dev-tools still assumes that every consumer repository has PHP source code, PHPUnit coverage, and a wiki submodule. That breaks repositories such as php-fast-forward/agents, which currently ship guides and Composer-installed assets but intentionally have no src/, no PHPUnit test suite, and no local PHP API surface to document.

Today this causes command and workflow failures in places that should degrade gracefully:

• wiki fails when the repository has no wiki submodule or no meaningful PHP API to render.
• tests fails when the configured tests path does not exist even though there is also no src/ tree to test.
• docs fails when phpDocumentor receives no API package/autoload information. One concrete error is:
  • phpDocumentor\\Configuration\\ApiSpecification::__construct(): Argument #6 ($defaultPackageName) must be of type string, null given
• metrics fails when there is no code or tests to measure.
• reports still orchestrates all of the above as if every repository were a PHP package with coverage, API docs, wiki, and metrics.
• wiki-oriented workflows fail when the consumer repository does not even contain a .github/wiki submodule.

Problem

We need dev-tools to support repositories that only ship guides, assets, agents, skills, or other non-PHP deliverables, while still allowing repositories with normal PHP packages to behave exactly as they do today.

The current behavior is too strict for mixed repository shapes across the Fast Forward organization, and it blocks reusable workflows from being applied consistently.

Scope

Adapt the runtime behavior of these commands and workflows:

• wiki
• tests
• docs
• metrics
• reports
• wiki maintenance / preview / publish workflows that currently assume .github/wiki exists

Expected Behavior

wiki

• If the consumer repository has no .github/wiki repository or submodule, the command should emit a controlled warning and exit successfully without trying to render wiki output.
• If the repository has no usable PHP source/autoload surface for API documentation, the command should also avoid generating an empty or vendor-driven wiki by mistake.
• In particular, repositories with no project PSR-4 namespace should not silently generate wiki content based on vendor packages.

tests

• If the configured tests path does not exist and there is also no src/ tree or equivalent PHP source surface to validate, the command should emit a controlled warning and skip test execution successfully.
• Repositories with nothing to test should not fail only because coverage/reporting was requested.

docs

• If the repository has no PHP source files or no Composer autoload definition for the package itself, the command should still render guide documentation from docs/ when present.
• In that scenario it should skip API/default-package generation instead of failing phpDocumentor configuration.
• It must not pass a null defaultPackageName or otherwise build an invalid API specification when there is no package API to document.

metrics

• If there is no PHP source and no tests, the command should emit a controlled warning and exit successfully instead of failing.

reports

• reports should orchestrate only the outputs that are actually available for the current repository shape.
• For a repository like php-fast-forward/agents, that means it may generate only guide docs and should skip coverage, metrics, and wiki/API outputs that do not apply.
• The command should still surface clear warnings so maintainers understand what was intentionally skipped.

Wiki workflows

• Wiki-related workflows should not fail when the repository does not contain a .github/wiki submodule/repository.
• In that case they should skip the wiki-specific flow with a clear warning/summary instead of hard-failing the workflow.

Implementation Notes

• Prefer centralizing repository-shape detection instead of duplicating one-off guards in every command.
• The detection should distinguish between:
  • guide-only repositories
  • repositories with PHP source but no tests yet
  • repositories with tests and code
  • repositories with or without a managed wiki repository
• Command surfaces should remain deterministic: warn clearly, skip intentionally, and avoid masking real failures for repositories that actually do have code/tests/wiki configured.

Acceptance Criteria

• wiki exits successfully with a warning when no wiki repository exists.
• wiki does not generate vendor-derived output for repositories with no project namespace/autoload surface.
• tests exits successfully with a warning when there is no tests directory and no PHP source to validate.
• docs can generate guide-only output when there is no package API surface, without failing phpDocumentor.
• metrics exits successfully with a warning when there is no code/test surface to measure.
• reports generates the subset of outputs that apply to the current repository instead of failing the entire run.
• Wiki workflows skip cleanly when .github/wiki is absent.
• Existing repositories that do have PHP source, tests, metrics, and wiki support continue to behave as before.
• Add regression coverage for at least one guide-only repository shape.

Non-Goals

• This issue does not introduce the future wiki template that renders guides into markdown.
• This issue does not redefine how fully fledged PHP packages generate API docs, coverage, or metrics when those inputs are present.