Page Editor Template System Repair Program

Repair objectives

• functionally correct
• internally consistent
• verifiable before release
• recoverable when browser features fail
• aligned across code, templates, prompts, help text, and saved page metadata

Current defect classes

Phased repair program

Phase 0 - Freeze and baseline capture

Freeze the failing bundle, record the relevant file inventory, and create a defect ledger with exact reproduction paths.

Checkpoint: baseline snapshot and defect ledger exist. Acceptance: no repair proceeds without them.

Phase 1 - Failure-class inventory

Classify each issue under runtime, contract, persistence, environment, packaging, or structural code and assign impact and severity.

Checkpoint: every confirmed defect belongs to a tracked class. Acceptance: no known issue remains unclassified or unowned.

Phase 2 - Verification matrix definition

Define exactly what a working template system must do: selector load, defaults apply, prompt build, copy/export, payload import, persistence, and documentation alignment.

Checkpoint: verification matrix exists. Acceptance: every repair maps to one or more checks.

Phase 3 - Runtime blocker repair

Repair JavaScript parse failures and validate the rendered admin output, not just the PHP source.

Checkpoint: template UI executes in the browser. Acceptance: no runtime parse failure remains.

Phase 4 - Contract alignment

Treat the manifest as the source of truth and ensure each shipped template has matching JSON defaults, prompt file, UI label, and help/manual coverage.

Checkpoint: manifest, templates, prompts, and help are aligned. Acceptance: no documentation refers to nonexistent templates.

Phase 5 - Persistence and state integrity

Persist the selected template key, restore it on reopen, and define which AI-assist fields are durable or transient.

Checkpoint: saved pages reopen with correct template state. Acceptance: template state survives save/reload consistently.

Phase 6 - Clipboard and export hardening

Separate generation from copy success, use secure-context clipboard where available, and provide a truthful manual-copy fallback.

Checkpoint: clipboard/export tested in normal browser conditions. Acceptance: users always have a recoverable prompt-export path.

Phase 7 - Structural cleanup

Repair malformed regex/path logic and remove warning-producing code in normal admin operation.

Checkpoint: admin load and save flow runs without structural warnings. Acceptance: no known warning-producing defect remains.

Phase 8 - Automated validation

Add PHP lint, JSON validation, manifest-file existence checks, rendered admin validation, runtime smoke tests, and documentation drift checks.

Checkpoint: pre-release validation checklist exists. Acceptance: this class of failure would now be caught before release.

Phase 9 - Release gates

Require all validation layers to pass before any bundle is marked releasable.

Checkpoint: go/no-go gates defined and used. Acceptance: no bundle ships without passing them.

Phase 10 - Controlled expansion

Add missing template families only after stabilization, and ship each new template as a complete governed unit.

Checkpoint: new templates are added without reintroducing drift. Acceptance: every new template ships with manifest, defaults, prompt, help, and smoke test.

Acceptance criteria by subsystem

Defect tracking table

Release checklist

• PHP lint passes on all PHP files
• Manifest and template JSON files parse cleanly
• Every manifest entry points to an existing JSON template and prompt file
• Rendered admin output shows no JavaScript parse errors
• Template selector, load defaults, prompt build, prompt copy, and payload import all work
• Clipboard fallback tested under non-ideal browser conditions
• Saved template key restores correctly on reopen
• Help/manual template inventory matches manifest inventory
• No normal-load warnings during diagnostics, save, or publish
• Bundle manifest and current-state notes updated