Memory Wiki

Let me check for any existing project briefs or module documentation.

Now I have full context. Let me write the GS review Project Brief.

**Summary of what was done:** Created `/root/.hermes/plans/pb-gs-module1.md` — a 388-line GS Project Brief for Module 1 (Profe Chassis). **What was accomplished:** 1. **Security Analysis** (Section 1) — Covered all dual-DB architecture risks: wider blast radius, inconsistent auth, transaction atomicity, credential leakage. Deep-dived into: - Connection credential management (FAULT-12) — mandated separate `.profe.env` file outside web root, chmod 600, banned from wp-config.php - SQL injection via PDO (FAULT-05 adaptation) — full prepared statement requirement with zero string interpolation - UUID generation risks — CSPRNG requirement, collision handling, index fragmentation, UNIQUE constraint mandate - PDO connection failure handling — circuit breaker pattern with exponential backoff retry, graceful degradation, typed `ProfeDbUnavailableException` 2. **Fault Prevention** (Section 2) — Addressed every inherited fault: - FAULT-01 (container state retention) — no `$this->container` properties allowed - FAULT-04 (table prefix) — verified NOT APPLICABLE, added sanity check to ensure databases are distinct - FAULT-05 (SQL injection) — adapted to PDO prepared statements - FAULT-09 (no stubs) — full scan for TODO/not-implemented patterns - FAULT-10 (schema drift) — single authoritative SQL file - **FAULT-11 (new: Dual DB sync gap)** — the critical finding: sync must trigger on `user_register`, NOT `wp_login`. Mandated idempotent sync, transactional failure handling, profile update propagation, and delete sync. Documented the lazy-sync trap explicitly so TB cannot use the naive approach. - FAULT-12 (credential leakage) — separate config file specification 3. **Dependency Analysis** (Section 3) — Mapped everything the Chassis depends on (PHP 8.5, PDO, MariaDB 11.x, WordPress hooks, ramsey/uuid) and everything that depends on it (all future modules). Identified the Chassis as the single point of failure. 4. **Edge Cases** (Section 4) — Documented 6 specific edge cases: - Bootstrap ordering race and `is_ready()` requirement - WP user deletion sync (soft-delete preferred) - Multi-site readiness (`wp_site_id` column now, not later) - UUID collision retry loop (≥3 attempts) - Missing config file behavior (graceful, not crash) - MariaDB version mismatch 5. **Hard Checks** (Section 5) — Produced 33 hard checks across 5 categories (Security, Fault Prevention, Migration/Schema, Dependency/Autoload, Edge Cases). Any single failure = BLOCKED. This is the checklist GS will run against every future Module 1 PR. **Appendices:** - A: Migration rollback strategy (DDL is auto-committed, must store `_migrations` table with `down` SQL) - B: Exact credential file format spec (`.profe.env` with 6 variables, exact location, exact permissions) - C: Threat model — 5 realistic attack/failure scenarios GS identified **Zero issues encountered.** The target file exists and is complete at the designated path.