Portability proof and release-candidate boundary

Bounded candidate reference — 2026-10-20: 0.2.0-rc.1 is committed locally through 84f415b3098af5653577b2c65eea31fca21df79c, unpublished and not production-approved; stable PHP >=8.5.11 <8.6.0 is required. This is documentation, not adoption: this knowledge base retains its installed 0.1.0-rc.1 dependency and PHP 8.2.11 local profile. Dated PHP 8.2 evidence is historical; earlier dirty-source reports retain their original test provenance, not retroactive clean-commit proof. Candidate examples are illustrative: API signatures were reviewed, but candidate code was not executed by this editorial update. See current checkpoint, open criteria and adoption boundary.

Clean Framework 0.2.0-rc.1 is an unpublished local release candidate. It is not a published package, a production-readiness declaration, or evidence that the framework has passed on every target server. This status means the neutral package, skeleton, optional historical bridge, and an unrelated second application can be checked repeatably from this repository.

Independent application proof

examples/reading-list/ is deliberately unrelated to the application from which the framework was extracted. It owns its own:

• Portability\ReadingList\ namespace and domain value;
• repository contract and in-memory adapter;
• application service and controller;
• routes, configuration schema, and DEV/TEST/STAGE/PROD overlays;
• native PHP views, public front controller, Apache rules, and CSS;
• deterministic application test runner.

Its Composer manifest requires clean/framework through the local path repository. It does not require or load clean/framework-prosperous-pairs-legacy. Domain, repository, and service code do not import framework classes; the HTTP controller and composition root are the intentional adapter boundary.

The example proves that a second domain can compose the public framework API, boot without output, route requests, render escaped native PHP views, negotiate safe failures, and expose a health response. It performs no database, provider, mail, queue, credential, remote-network, or historical-application operation.

Run its independent proof after installing its local path dependency:

cd examples/reading-list
COMPOSER_DISABLE_NETWORK=1 composer install --no-interaction --no-plugins --no-scripts
APP_ENV=TEST composer test
APP_ENV=DEV php -S 127.0.0.1:18090 -t public public/dev-router.php

The root verifier can run the same application tests from a framework source checkout without generating example dependencies. The test runner uses the application's Composer autoloader when installed and a clearly bounded source- checkout fallback otherwise.

Release-candidate gates

From the repository root, run:

composer verify
git diff --check

composer verify locally and without network access:

• validates root, skeleton, compatibility-bridge, and portability-example Composer metadata;
• records required and optional host capabilities;
• runs the deterministic framework and portability-application suites;
• syntax-checks every package PHP file outside generated vendor trees;
• scans neutral runtime/configuration/test surfaces for source-product terms;
• scans those surfaces for high-confidence private-key and provider-token formats;
• requires docblocks on every public method below src/ and the portability application's app/ directory;
• checks relative documentation file links and behavioral summaries on the reviewed non-trivial API set through bin/documentation-check.

The credential scan is a safeguard, not a complete secret-management audit. It intentionally avoids generic words such as password because configuration schemas and deterministic security fixtures use them legitimately. Repository review, ignored-file policy, host secret injection, and credential rotation remain required.

Documentation gates detect structural regressions, not the truth of every explanation. Review changed examples against code and tests; the onboarding entry point is INDEX.md.

What remains outside this proof

The current standard is stable PHP >=8.5.11 <8.6.0 under Decision 0003. Scoped actual 8.5.11 CLI/Apache-FPM, MySQL 8.4.11, real worker signals/concurrency, synthetic encrypted restore, local provider TLS and optional shared-state checks have passed. Historical PHP 8.2/module evidence is retained, not extended to the new candidate. The local proof does not qualify final hosted stacks, MariaDB, whole-application off-host recovery, native video/scanners, browser accessibility, distributed stores, production supervision/on-call, provider sandboxes or live AI/actions. See the exact module profile, PLATFORM_MATRIX.md and VERIFICATION_REPORT.md for those open gates.

Product composition migration is also separate work. The deferred Clean Inventory proposal was not built, and this portability application is not a renamed or copied product implementation.

Candidate packaging rule

Do not package generated vendor/, .env, cache, session, upload, backup, temporary, log, or derivative files. Keep skeleton/ as the new-application starting point and examples/reading-list/ as evidence, not as application boilerplate. A public release or production deployment must satisfy the applicable open rows in RELEASE_CHECKLIST.md and use a clean Git checkpoint.

Editorial provenance

Source: docs/PORTABILITY_AND_RELEASE.md. Source SHA-256: 63b8e41e0c6448c83dd40314c8ad6ea4465a4291089b0363c0c4c5a457db1608.

Framework candidate reference; editorial checkpoint 2026-10-20. See candidate status and adoption boundary.