docs: add a runnable Composer manifest walkthrough

[fly1d]

User workflow

A PHP or Composer maintainer wants to shrink a valid composer.json around a dependency or autoload-related failure, then verify the exported reproduction before sharing it. The repository already has a deterministic, network-free fixture at benchmarks/composer-package, but the main examples guide does not currently show the end-to-end Composer manifest workflow.

Scope

Add one concise, copy-pasteable Composer manifest section to docs/EXAMPLES.md. Reuse the existing fixture, --adapter composer, and its Python oracle. Keep this documentation-only: do not add dependencies, invoke PHP or Composer, install packages, or change reducer semantics.

The section should show, from the repository root:

• creating a temporary output parent outside the fixture;
• running the existing reduction with the stable ORIGINAL_FAILURE marker;
• the two retained files (composer.json and reproduce.py);
• the retained repomin/required == 1.0.0 requirement and autoload.psr-4 entry, plus representative removed manifest entries;
• that top-level extra is outside the current adapter categories and remains unchanged;
• report validate --payload --json, including the expected valid/exact fingerprint evidence; and
• an independent oracle rerun from the exported payload, with expected exit code 1 and ORIGINAL_FAILURE on stderr.

Explain that this fixture deliberately uses a Python oracle, so it exercises structural composer.json reduction without PHP, Composer, dependency installation, repository access, lifecycle scripts, or external network. It is adapter evidence for the configured oracle, not proof that an arbitrary minimized Composer project installs, autoloads, or behaves correctly. Link the fixture README and the host-backend boundary in SECURITY.md.

Do not pin attempt counts, byte counts, cache hits, or JSON whitespace; those are not the user contract and may change as the reducer evolves.

Acceptance criteria

• docs/EXAMPLES.md contains one complete Composer manifest workflow runnable from the repository root.
• The example keeps output outside benchmarks/composer-package and documents the exact retained files and required/removed manifest semantics.
• The validation and independent-rerun commands are copy-pasteable, with their expected fingerprint mode, marker, and exit behavior stated accurately.
• The text clearly states the no-PHP/no-Composer/no-install/network boundary and the descriptive oracle/security limitations.
• python3 scripts/check_docs.py passes.
• python3 benchmarks/run_offline.py --only composer-package passes.
• The change remains documentation-only and does not duplicate the fixture README verbatim.

Before starting, comment here so the scope stays coordinated. In the PR, include Closes #<issue-number> and paste the two check results. If a command cannot be run locally, say exactly what was skipped and why.

[shoaibyazdani]

Picking this up — I'd like to take it on. Will dig into reproduction shortly and post a focused fix proposal. Happy to coordinate if a maintainer has a preferred direction, or if someone else is already mid-flight.

[fly1d]

Thanks for picking this up. The scope is ready and assigned to you. Please keep the change documentation-only and reuse the existing fixture and Python oracle; do not invoke PHP or Composer, install packages, or pin attempt/byte/cache counts. The two acceptance checks in the issue are sufficient for this contribution. A focused PR with Closes #22 and the observed check results is the intended next step.

[fly1d]

Maintainer correction: the acceptance text saying ORIGINAL_FAILURE is on stderr was inaccurate. The existing Composer fixture uses plain print(), so the marker is on stdout. The intended contract is a nonzero exit plus ORIGINAL_FAILURE in command output. PR #24 has been asked to correct the wording only; the fixture should not change.