EDIS WordPress Evidence Exporter

Version 3.7.16, generated by EDIS Enterprise Deterministic Build Platform 3.7.16.

Version 3.7.16 adds the canonical EDIS-DIAGNOSTIC-1 incident record: one bounded, privacy-safe JSON source of truth for pre-Job, Job-bound, and terminal worker failures, with exact authorized retrieval, copy/download, explicit uncertainty, deterministic classifications, and truthful persistence fallbacks. Unsupported deterministic PHP runtime remains a pre-Bootstrap notice-only path, while known Bootstrap failures remain in the existing fail-closed DegradedModeIntegration boundary. Frozen public evidence/package contracts remain unchanged. Product/platform and package producer identity advance to 3.7.16; ExportJobService::IMPLEMENTATION_VERSION remains 3.7.15, so compatible incomplete 3.7.15 Jobs retain their existing Resume contract.

EDIS exports saved WordPress and Elementor evidence for the Python Deterministic Engine. It does not evaluate UX quality, infer browser geometry, resolve final effective values, run formulas, or call an AI service.

3.7.16 canonical diagnostic records

Release 3.7.16 persists one occurrence-specific edis-diag-* record for each material failure when private diagnostic storage is available. The canonical record separates directly recorded facts, deterministic plugin classifications, unresolved evidence, provenance, recovery guidance, and the explicit absence of AI-derived root-cause analysis. The administrator Diagnostics page is a projection of the same JSON, not a second diagnostic truth.

The record uses canonical EDIS-CJ-2 serialization, a 64 KiB hard limit, visible truncation metadata, a positive privacy allowlist, owner and multisite isolation, current object authorization for Job-bound incidents, bounded retention, and exact REST/copy/download bytes. Normal structured preflight blockers remain direct responses and do not create unnecessary incident records.

Safe Worker Test now maps completed→PASS, queued/running→IN_PROGRESS, failed→FAIL, cancelled→ABORTED, and unknown states to UNKNOWN. If diagnostic persistence itself is unavailable, EDIS reports diagnostic_available=false and does not promise an artifact. Bundle Schema 3.3.0, Shared Artifact Envelope 2.0.0, Package Manifest 2.1.0, Selection Snapshot 1.2.0, EDIS-CJ-2 and EDIS-ZIP-1 remain unchanged.

3.7.13 degraded diagnostics recovery

The plugin entrypoint first enforces deterministic-runtime compatibility. If PHP is outside the supported deterministic range, edis_evidence_exporter_runtime_notice is registered and execution returns before Bootstrap; no DegradedModeIntegration recovery shell is registered on that path. For requests that reach Bootstrap, the three current degraded causes are installation-integrity failure, invalid configuration, and private-storage failure. Those three Bootstrap branches route through the shared DegradedModeIntegration, which registers a minimal recovery-only wp-admin surface under manage_options using the existing EDIS Evidence menu identity and Diagnostics slug.

The degraded surface exposes only bounded diagnostic facts already owned by the degraded integration and PrivateStorage: the active diagnostic code, privacy-safe diagnostic message, preferred storage candidate when available, failed storage checks, the existing nonce-protected storage retest, and the existing bounded WP-CLI storage commands.

Bootstrap degraded mode does not initialize AdminModule, DiagnosticsService, export services, operational stores, worker/recovery execution services, or operational REST controllers. Create Export, job operations, downloads, worker tests, Inspector operational APIs, settings requiring operational storage, and scheduled export execution remain unavailable until the relevant installation-integrity, configuration, and private-storage conditions pass. On a later healthy request, the normal AdminModule returns and the degraded shell is not registered. Unsupported deterministic runtime remains a separate pre-Bootstrap notice-only path.

Release 3.7.13 changes only degraded admin recovery. ExportJobService::IMPLEMENTATION_VERSION remains 3.7.12, so an otherwise-compatible persisted 3.7.12 job is not invalidated merely by installing this patch.

3.7.12 repair and recovery behavior

Package contract and final-integrity failures use the existing ExportIntegrityException authority with stable diagnostic codes and bounded privacy-safe context. When collection finishes, current_component is cleared before packaging so a package failure cannot be attributed to the final collector. Generic operational failures remain retryable without exposing raw exception messages or filesystem paths.

A failed job is recovered automatically only when its existing next_retry_at is present and due. Recovery goes through the existing resume() path, retaining the same job lock, worker lease, immutable input snapshot, completed-artifact, step-hash, compatibility and revision checks. A non-retryable integrity failure or a future retry deadline does not auto-advance. Jobs created by implementation version 3.7.11 are incompatible with the 3.7.12 worker and must be recreated; they are not migrated in place.

Default-enabled Bundle Processors now enter execution planning through the same recursive inclusion mechanism as explicit components, so every transitive REQUIRED dependency exists and precedes its consumer. BridgeContextProcessor fails closed with EDIS_BRIDGE_REQUIRED_INPUT_MISSING when environment or elementor_document_index is absent or malformed.

Explicit collector selection is validated at the application/service boundary against the live CollectorRegistry. Unknown, non-selectable, non-executable, mixed-validity and explicit-empty selections are rejected as a complete request; only true omission may use configured/default collectors.

The existing Elementor 4.1.3 smoke matrix remains PHP 8.2–8.5. Its representative PHP 8.4 lane additionally creates a fresh saved Elementor document and drives the production application services through collection, packaging, validation and deterministic ZIP verification.

The source package includes tools/validation/run-local-validation.php and a machine-readable validation plan. The runner reports only gates that were actually executed. Composer, WordPress, Elementor, Windows/LocalWP and Python-consumer gates remain unresolved until valid external evidence is supplied. Validation files are excluded from the WordPress installation ZIP.

Pipeline boundary

WordPress Evidence Exporter
    Saved source evidence, references, registries, provenance and lightweight indexes

Browser Runtime Collector
    Rendered DOM, geometry, computed styles, relationships and source-binding evidence

Python Deterministic Engine
    Validation, deterministic merge, resolution, formulas, rules, final correlation and TruthReport

LLM
    Explanation and prioritization of Python output only

WordPress Admin

In healthy mode, administrators can open EDIS Evidence and use Overview, Create Export, Data Sources, Data Coverage, Diagnostics, Settings and Help. The Help page and the English/Persian manuals are synchronized with the manifest-backed component registry. In degraded mode, only the recovery-only EDIS Evidence Diagnostics / Recovery surface remains visible to manage_options administrators.

Export execution

The bounded REST worker captures selected saved _elementor_data bytes into a protected immutable input snapshot before collectors execute. A second read detects source drift during capture. The worker then reads selected document source only from the committed snapshot.

Every completed step records:

job_format_version
input_snapshot_format_version
input_snapshot_sha256
component_schema_version
implementation_version
step_input_sha256
artifact_file_sha256

Resume is permitted only when the job and snapshot formats are current, completed components are the exact execution-plan prefix, and all input/artifact hashes still match. In 3.7.9 the Resume transition and subsequent worker advancement occur while one stable per-job lock is held; failure to obtain that lock does not mutate the Job. Jobs created by another implementation version are not silently resumed.

WP-Cron is a recovery mechanism. The authenticated REST worker remains the primary executor. REST operations require edis_export_evidence, job ownership and object-level edit_post authorization for document operations.

EDIS-CJ-2 lossless JSON

Version 3.7.0 introduced the frozen EDIS-CJ-2 profile; version 3.7.16 preserves it unchanged:

• valid UTF-8 is required;
• object keys are sorted by exact UTF-8 bytes;
• Unicode normalization is not performed;
• {} and [] remain distinct;
• numeric-looking object keys remain object keys;
• duplicate object keys are rejected before native PHP conversion;
• source numbers are canonicalized as exact decimal lexical nodes;
• normalization budgets reject hostile exponents and oversized expansions;
• native PHP integers remain limited to the interoperable safe range;
• non-finite native floats are rejected.

The shared vectors are in contracts/edis-cj-2-vectors.json.

Dual artifact hashes

Every artifact envelope contains:

semantic_payload_sha256
artifact_instance_sha256

The semantic hash excludes versioned operational identity only at the contract-defined envelope roots. Nested saved-source and addon properties retain their original meaning even when their names resemble operational keys such as created_at or token. The instance hash covers the complete emitted envelope except its self-referential instance-hash field. File SHA-256 values remain separate and cover emitted bytes.

EDIS-ZIP-1

Final bundles use a pure-PHP deterministic ZIP writer rather than environment-dependent compression defaults:

• method STORE (no compression);
• UTF-8 byte-sorted entry paths;
• fixed DOS timestamp;
• fixed Unix file mode;
• no comments or extra fields;
• no ZIP64;
• fixed limits with fail-closed diagnostics.

This trades package size for reproducible bytes across supported runtimes.

Durable private storage

Critical writes use exclusive temporary-file creation, complete write loops, fflush, fsync, permission application, atomic replacement/rename, parent-directory synchronization on supported POSIX runtimes, and final SHA-256 verification. The active runtime self-test also launches a separate PHP process against the exact private-storage lock file and requires it to be blocked by the held lock. If process execution is unavailable, the filesystem does not provide exclusion, the path is inside the web root, or any ancestor redirects through a symlink/junction-like path, export creation is blocked while diagnostics remain available. Per-job .lock sentinels are not unlinked during normal cleanup because an already-open handle must retain a stable pathname/inode identity.

LocalWP path discovery

Local documents the WordPress document root as <site>/app/public. In WP_ENVIRONMENT_TYPE=local, EDIS 3.7.16 prefers <site>/edis-private-storage, retains <site>/app/edis-private-storage as a safe compatibility fallback, and never writes evidence under app/public. A storage failure activates degraded mode instead of aborting plugin activation. Use Local’s Open Site Shell and run wp edis storage paths followed by wp edis storage self-test.

Package schemas

WordPress Bundle Schema: 3.3.0
Shared Artifact Envelope: 2.0.0
Package Manifest: 2.1.0
Package Validation: 1.3.0
Selection Snapshot Schema: 1.2.0
Private Job Format: 2.1.0
Private Input Snapshot Format: 2.0.0

Browser and Python compatibility with Bundle Schema 3.3.0 remains insufficient_evidence until both products route the new envelope, EDIS-CJ-2 vectors and dual hashes explicitly.

Privacy modes

• Strict: excludes original saved document objects.
• Standard: balanced source evidence for controlled local analysis.
• Diagnostic: includes additional operational metadata and requires explicit authorization confirmation.

Credentials, cookies, form values, nonces, bearer tokens and unrestricted page text are not intentionally exported.

WordPress runtime hardening in 3.7.1

Version 3.7.1 does not change Bundle Schema 3.3.0, Shared Envelope 2.0.0, Selection Snapshot 1.2.0, EDIS-CJ-2 or EDIS-ZIP-1. It hardens the WordPress integration boundary:

• conditional boot avoids loading the export application on ordinary frontend requests;
• activation/deactivation are network-aware and network activation rolls back changed sites if one site fails preflight;
• newly created multisite sites receive capability, option, storage and cleanup initialization when the plugin is network-active;
• each multisite site receives a separate private-storage namespace;
• WordPress Site Health exposes deterministic runtime, recovery schedule and asynchronous storage-integrity checks;
• WordPress privacy exporters/erasers expose and remove owner-bound operational job records;
• deleting a WordPress document removes jobs and private artifacts whose immutable selection includes that document;
• operational user meta is site-scoped on multisite;
• WordPress Filesystem transport detection is reported without allowing interactive credentials to weaken the deterministic direct-storage contract;
• WP-CLI provides status, worker, stale-job repair and storage self-test commands;
• private Job Format 2.1.0 adds explicit worker leases and heartbeat-bound recovery;
• uninstall behavior is controlled by the documented retention option and remains separate from deactivation;
• the WordPress-facing layer is subject to full WordPress-Core, WordPress-Extra and WordPress-Docs checks with documented naming exceptions for the PSR-4 core.

WP-Cron is only a wake-up/recovery trigger. Correctness remains owned by the versioned job state machine, leases, hashes and idempotent step records.

Development quality gates

The source repository defines:

• PHP 8.2, 8.3, 8.4 and 8.5 CI lanes;
• PHPUnit tests;
• security-focused WordPress Coding Standards and PHPCompatibilityWP checks;
• E_ALL runtime smoke tests;
• static and runtime WordPress Plugin Check jobs;
• deterministic package reconstruction checks;
• a real production-service export-completion check on the PHP 8.4 Elementor lane;
• a real WordPress 7.0 degraded-admin recovery check that isolates the production degraded integration and proves recovery-only menu visibility and authorization.

These gates are not considered passed unless the corresponding CI commands actually execute successfully.

Documentation

• Help.md — complete English guide
• Help_FA.md — complete Persian guide
• docs/collector-encyclopedia.md — English component encyclopedia
• docs/collector-encyclopedia-fa.md — Persian component encyclopedia
• docs/export-workflow.md — snapshot, worker, hash and package lifecycle
• docs/troubleshooting.md — recovery and integrity diagnostics
• docs/quality-gates.md — release verification commands
• docs/MIGRATION-V3.7.0-TO-V3.7.1.md — WordPress runtime, multisite and rollback guidance
• docs/MIGRATION-V3.7.1-TO-V3.7.2.md — 3.7.2 debugging and mixed-install guidance
• docs/MIGRATION-V3.7.2-TO-V3.7.7.md — active lock proof, semantic identity, Resume and cleanup migration guidance
• contracts/EDIS-Cross-Product-Contract-Freeze-v1.2.0.md — frozen coordinated addendum

Compatibility boundary

The WordPress layer still exports saved source evidence and deterministic indexes only. EDIS-CJ-2, dual hashing, durable storage and deterministic packaging do not move reference resolution, breakpoint resolution, class precedence, formulas, rules, runtime correlation or TruthReport generation into WordPress.

Package manifests define an explicit semantic_identity from the source-export root and versioned packaging policy; the per-run file inventory remains instance evidence and does not pollute semantic identity.