Clean Framework · DOCUMENTATION
Candidate maintenance, reporting and release policy
Candidate maintenance, reporting and release policy
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.
REL-02 and PORT-03 exceptions are PENDING / NOT ACCEPTED. Assignments do not prove independence/unfamiliar-participant eligibility. No automatic bridge removal or retirement date is supplied.
Ownership requiring assignment
Current requested assignments and unresolved contacts are tracked in Urgent owner decisions. No deployment, commit/push or release authority is implied by local implementation completion.
| Responsibility | Current assignment |
|---|---|
| Scope, release approval and proprietary distribution | Daniel Horowitz; no release authorized |
| Primary/backup framework maintainer | Daniel Horowitz for both; no separate-person backup coverage |
| Independent security reviewer | Daniel Horowitz assigned; independence and dated disposition TO VERIFY |
| Dependency/license reviewer | Daniel Horowitz; actual review/signature TO VERIFY |
| On-call, incident commander, backup/DB/storage operator | Daniel Horowitz; actual host drill/coverage TO VERIFY |
Private security reporting and response
Contact owner: Daniel Horowitz. Owner-designated private reporting email: danielhorowitz1984@gmail.com, explicitly provided on 2026-10-17. The address is a reporting destination, not an SMTP credential, deployed alert adapter or proof that the mailbox has been monitored/tested. No message, sender account, mail transport, automation or subscription is created by documenting it.
For an initial report, send the minimum necessary: framework version, source/ artifact hash if available, a concise impact description, affected framework component, synthetic reproduction steps and a safe reply route. Use a subject such as Clean Framework security report — <report reference>. Do not attach populated env files, credentials, actual customer/private data, raw request bodies/signatures, private payload paths or a proprietary source archive. Arrange a separately approved private transfer if sensitive evidence is needed. Do not copy the report into public issues, operational logs or metric labels.
Pre-release handling procedure, recorded under the owner's delegated instruction to complete open local work:
- Daniel records an opaque report reference, receipt time, affected candidate/ hash and safe summary in an access-controlled issue record, not this Git repo.
- Acknowledge the report, reproduce only within separately authorized synthetic fixtures, assess impact/severity and record the scope/owner. A report never grants permission to test a consumer application, host or live provider.
- Prioritize suspected critical/high issues. If confirmed, disable/contain the affected capability where an operator has authority, preserve evidence and prepare a bounded fix plus failing-before/passing-after regression.
- Have an independent reviewer disposition the exact corrected candidate. Keep unknown effects and high-risk activation held until evidence exists.
- Communicate status and an evidence-based next update. Decide remediation dates and any coordinated disclosure per case; never promise a fix date before scope and safe verification are known. Release/deployment still needs separate owner authorization.
Proposed planning targets, not a production support SLA or measured result: acknowledge within two business days; initial triage within five business days; update accepted active reports weekly, with critical/high review prioritized. Business-day planning uses Monday–Friday in America/New_York. The owner must confirm actual mailbox monitoring/coverage and operational acceptance before presenting these as externally committed response times. No 24/7 staffing, automated escalation, deliverability or remediation deadline is claimed.
Single-person primary/backup assignments provide no independent availability coverage. If Daniel is unavailable, no alternate person/channel has yet been appointed; document that gap rather than pretending an escalation exists. Actual alert transport delivery and human acknowledgement belong to OPS-06/ U-025, and independent security disposition to SEC-16/U-023. Recording the contact/policy completes U-028/REL-06's documentation condition only.
Candidate support/deprecation
0.2.0-rc.1 remains an unpublished local candidate until reviewed and approved. The owner's local Git/backup checkpoint does not confer release or production approval. Historical evidence retains its original dirty-tree provenance; see checkpoint/backup guidance. It requires stable PHP >=8.5.11 <8.6.0; the earlier 8.2 candidate was not upgraded in any consuming application. Never use --ignore-platform-reqs or disable the pure guard to force old-runtime boot. Apply/requalify security patches within the selected minor; a new PHP minor is a new owner decision.
Proposed policy, pending owner acceptance: critical/high reports triaged as soon as a maintainer is available, security patches prioritized over features, and ordinary API removals announced for at least one minor/90 days where safe. These are proposals, not a support SLA. Pre-release security/ownership repairs can intentionally break unsafe behavior and must have explicit migration notes. No genuine prior supported production release/upgrade evidence is fabricated.
New candidate compatibility notes
- Direct queue/outbox consumers must use each returned per-claim token, not a reused process label. Drain/stop incompatible old workers before starting the reviewed new set; never overlap mixed ownership contracts. Expired outbox sends and arbitrary handler/transport exceptions hold UNKNOWN; only explicit definitely-safe results retry. Reconcile effects before manual replay.
- Advisory-lock name shortening changes the lock namespace; do not mix old/new scheduler/worker versions during the switch. No application schema was changed.
- Bounded header/framing/image decode checks reject formerly accepted unsafe inputs. Multipart filenames now correctly reject controls, quotes and separators.
- ErrorLogLogger accepts stable event codes rather than arbitrary secret-bearing messages and tightens redaction. Alert/error metadata rejects sensitive keys.
- AuthenticationMiddleware forces no-store; SecurityHeadersMiddleware adds a same-origin CSP. Review existing inline/external assets with an exact nonce/ source policy, never blanket unsafe-inline. No cross-user HTML cache is added.
- File quota/circuit stores are single-host only and deny corrupt/over-capacity state. See qualification profile.
Local artifact provenance, not publication
php bin/build-candidate --epoch=1792195200 reads local tracked source plus the explicit reviewed-additions registry. It excludes populated env/vendor/runtime data, rejects symlinks/binary/private-key/token patterns, bounds source size, fixes ZIP times/order/modes, records per-file SHA-256 plus source HEAD/dirty state, and writes a private candidate ZIP under an exact new temp directory. It never commits/tags/signs/pushes/deploys. The credential-pattern check is not a comprehensive secret audit. Inspect the manifest/diff and actual package.
Repeat with the same source/epoch/toolchain and compare archive hashes. The isolated test mode uses only its read-only source receipt, records HEAD=null instead of inventing Git history, and tests byte-for-byte repeat builds and every entry checksum. There is no supported-release upgrade claim. ZIP entry mode is normalized 0644; invoke packaged scripts through PHP/sh as documented.
Only after a clean reviewed checkpoint, required evidence/signoffs, maintained contacts, license review and owner authority may an operator sign/publish an artifact or deploy STAGE/PROD. Candidate packaging does not satisfy that gate. Runtime dependencies and isolated development-tool pins are in the inventory; host OS/SBOM/notices require their own exact deployment artifact review.
Editorial provenance
Source: docs/MAINTENANCE_AND_RELEASE.md. Source SHA-256: 8170d82448e88753d1fb697fae27cd2b95703c402c449c1cfa29ac301e7f3122.
Framework candidate reference; editorial checkpoint 2026-10-20. See candidate status and adoption boundary.