Development pipeline and evidence gates

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.

The proposed pipeline remains a planning model, not an installed CI/CD service. Current WP-00..10, Urgent/Major/Minor, module/operations A–C, consolidated A–E and post-E/Q03 evidence is summarized in candidate status. The original register is 148 PASS / 15 TO VERIFY / four N/A; local implementation does not close external or release acceptance. REL-02/PORT-03 remain pending, and benchmark comparison remains unselected.

Current Next Generation source/qualification status is recorded in the final local report: 145 scoped PASS, 18 TO VERIFY and four optional benchmark N/A on the documented PHP 8.5 pilot profile. Older dated counts/roadmap statements below remain historical or broader host requirements; do not relabel them as current production proof.

Purpose and current status

Next-generation execution began 2026-10-16 under the owner's supplied program. Track its WP-00 through WP-11 and 167 acceptance cases in the active register. The next candidate uses PHP >=8.5.11 <8.6.0; actual local verifier/FPM and scoped MySQL 8.4.11 exercises now pass. This is not the entire integration or hosted pipeline. See the current checkpoint. This does not authorize the knowledge-base import commands or external operations below.

Recorded 2026-10-15, America/New_York. This is the proposed development and release procedure for closing the framework gaps and demonstrating selected advantages over Laravel and Symfony. It is a runbook, not installed CI/CD, a configured workflow, or permission to execute every stage. New automation, adapters and comparator applications are NOT STARTED. Existing local verification commands are identified below.

CF-G01 is now a separately authorized partial implementation of D1: PHP 8.2.x is selected and local module/FPM acceptance exists. Current-patch/final-host qualification remains open; D1 database work and later stages are not thereby complete. See current evidence. This chat updates framework logs only; the knowledge-base chat owns documentation imports.

Preserve native PHP templates, readable descriptive names, explicit dependency injection, strict types, PSR-4/PSR-12, and comments explaining public behavior, ownership, security and failure modes. Use coding standards and behavioral API documentation; do not optimize for fewer comments or opaque generated code.

Pipeline overview

Scoped work item and permission
  -> inspect current source and evidence
  -> contract/threat model and acceptance tests
  -> focused implementation and documentation
  -> local lint, deterministic tests and review
  -> approved isolated integration and recovery checks
  -> approved comparative or usability experiments
  -> candidate artifact and support decision
  -> separately authorized STAGE acceptance
  -> separately authorized PROD release and observation

Failed gate -> fix, rerun affected gates, update evidence; never silently skip.

Environment and authority boundaries

Do not copy runtime identities, private uploads, sessions, logs, actual backups or secrets between these environments. AI remains disabled in the knowledge base unless separately approved. CI services and dependency downloads are also external access; select and authorize them before installation or upload.

Ordered development workstreams

These workstreams follow the prior implementation phases; they do not replace or retroactively complete their acceptance records. P0 means blocking support for the affected capability, not a claim of an already discovered exploit.

Documentation-only changes can use proportionate local gates without running every external stage. They must not convert historical TO VERIFY rows to PASS. Implementation-first development may defer an acceptance gate, but affected capabilities remain IMPLEMENTED - UNVERIFIED and cannot be released as proven.

Per-change procedure

• Read AGENTS.md, current working-tree diff, active-work marker and the relevant subsystem guide. Preserve existing changes. Distinguish the independent framework from the knowledge-base application and its mirrored dependency.
• Create or select a CF-G work item. Name the contract, users, risks, owner, reviewer, allowed paths, affected environments, dependencies and exit tests. Record NOT STARTED or IN PROGRESS truthfully before editing.
• For stateful or security work, write the threat model and success/denial/ malformed-input/concurrency/failure cases first. Decide transaction, retry, lock, lifetime and idempotency ownership. Document API/BC impact.
• Make one reviewable change. Keep framework mechanics neutral and policy in applications. Use prepared values and allowlisted identifiers; never enable unsafe debug output or relax authorization to improve benchmark scores.
• Update focused tests, API comments, examples, migration/upgrade notes and relevant guides in the same change. Add immutable corrective migrations; never rewrite an applied migration to make tests pass.
• Run the local gates and inspect the diff. A failed or skipped gate is not a pass. Save sanitized evidence; assign any finding before proceeding.
• Ask for missing authority before integrations, providers, dependency uploads or deployments. Do not infer permission from a continuation request or this pipeline document.
• Update CHANGELOG.md, IMPLEMENTATION_STATUS.md and ACTIVE_WORK.md with exact results, remaining risk and next action. Publish approved knowledge-base documentation only after the source and allowlist checks pass.

Existing local commands

From the independent framework root, with dependencies already installed:

# Validate package metadata without publishing the proprietary package.
composer validate --strict --no-check-publish
# Run deterministic framework and documented regression scenarios.
composer test
# Check local documentation links and reviewed behavioral summaries.
php bin/documentation-check
# Run the existing composite local release checks; not hosted acceptance.
composer verify
# Inspect whitespace errors without reverting any existing change.
git diff --check

Read scripts before running them on a changed checkout. The commands above exist now; this guide does not add static analysis, vulnerability scanning, multi-runtime CI, performance tests, or automatic deployment. Select and wire those tools as separately reviewed work. When dependencies are absent, use reviewed lockfiles and an approved install procedure; do not silently update the framework's mirrored copy in a consuming application.

Proposed automated gates

No tool, remote CI repository, threshold baseline or release workflow is configured by this table. Do not assert a gate exists in automation until its implementation and negative-case behavior are verified.

Knowledge-base documentation pipeline

Canonical framework guidance belongs in the independent framework's docs directory, not vendor or generated snapshots. The competitive roadmap and this pipeline are imported through the knowledge base's fixed editorial allowlist as protected Operations articles.

• Edit and review the canonical Markdown; check examples against the exact package source. Add new guides to the framework index and explicit knowledge-base allowlist. Do not crawl logs, credentials or the legacy bridge.
• Run framework documentation checks. In the knowledge-base directory run:

# Publish only fixed, approved source documents into a private revision.
APP_ENV=DEV php bin/import-docs
# Check source syntax, public exposure, application/PWA/native HTTP contracts.
composer verify

• The importer writes immutable content and checksums before atomically switching current.json. An interrupted import leaves the previous revision selected; never hand-edit a generated manifest/article to force publication.
• Confirm both new articles render for a permitted reader, resolve their mutual links, participate in permission-filtered search, and deny anonymous access. They must remain outside public and offline/service-worker caches.
• Record article IDs, source and published revision hashes, actual check results, and any skipped host/device/live-provider acceptance. Update current catalog counts; preserve historical build logs as historical evidence.
• Request deployment permission before distributing a snapshot to a host. Documentation publication here is local private catalog publication, not public hosting. A framework code release and a knowledge-base content import are separate artifacts; neither silently updates the other's dependencies.

Evidence record template

Use this template in a tracked work item or the implementation ledger. Place large sanitized artifacts in an owner-approved private evidence location; record references/hashes, not credentials, private payloads or full dumps.

Work item: CF-Gxx / related CF-Txx
Owner / reviewer / date:
Status: NOT STARTED | IN PROGRESS | IMPLEMENTED - UNVERIFIED | VERIFIED
Source revision / dirty-diff hash / artifact / dependency lock hash:
Scope, requirement and invariant:
Environment, versions, fixtures and approved resource owner:
Permission and boundaries:
Commands, timestamps, expected result and actual result:
Failure/denial/concurrency/recovery cases:
Sanitized evidence location and checksums:
Open findings, skipped checks and risk acceptance/expiry:
Rollback/forward-recovery and compatibility impact:
Next exact safe action:

VERIFIED always names a tested scope and environment. Preserve DEFERRED and BLOCKED where applicable using the existing implementation-ledger definitions; the abbreviated template does not remove those statuses.

Release and interruption checklist

• Use a reviewed immutable artifact in STAGE and PROD, not a changed checkout. Bind acceptance evidence to the artifact hash and supported environment; requalify when code, dependencies, runtime or relevant configuration changes.
• Keep signed/checksummed artifact and evidence manifests in an approved private registry. Assign signing-key ownership and recovery before signing is claimed; a checksum alone is not authenticity or reproducibility proof.
• Before any deployment, confirm a recent restorable backup, least-privilege configuration, compatible database plan, TLS/private-path protections, feature flags, release owner and explicit target-specific authorization.
• Prefer expand/contract schema changes. Rolling code back is unsafe if the old version cannot read the new schema; use the rehearsed restore or forward corrective migration instead. Never improvise destructive down migrations.
• After release, observe agreed latency/errors/queue lag and reconciliation, verify alert delivery and log redaction, and stop/roll back under the pre-agreed policy. PROD is not the first integration-test environment.
• At every checkpoint record changed paths, last completed command, results, remaining gates and next action. After interruption, inspect actual files and owned processes before resuming; do not trust a stale log over source.

See the gap register and comparison protocol, testing guide, release checklist and implementation ledger. All future stages require their own evidence; this documentation change completes none of the open gaps.

Editorial provenance

Source: docs/DEVELOPMENT_PIPELINE.md. Source SHA-256: 611fe87fcbaa3d0a24731d93d5e3f84b53433936fc100adc86baa99fc8becabe.

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