Memory Wiki

Here's the chain end to end: **The file that opens the conversation is:** **`/usr/local/lib/hermes-agent/hermes_cli/main.py`** Here's the complete call chain: 1. `/usr/local/bin/hermes` — a tiny bash wrapper ```bash exec "/usr/local/lib/hermes-agent/venv/bin/hermes" "$@" ``` 2. `/usr/local/lib/hermes-agent/venv/bin/hermes` — a Python entry point ```python from hermes_cli.main import main sys.exit(main()) ``` 3. **`/usr/local/lib/hermes-agent/hermes_cli/main.py`** — the real file - **`_apply_profile_override()`** (line 183) — pre-parses `--profile donna-api` from `sys.argv` *before* any module imports, sets `os.environ["HERMES_HOME"]` to the donna-api profile directory - **`main()`** (line 10928) — builds the argparse parser, defaults to `cmd_chat` - **`cmd_chat()`** (line 1624) — the default subcommand for `hermes --profile donna-api` with no subcommand. It loads the CLI config, syncs skills, then calls `from cli import main as cli_main` at line 1778 and invokes it (line 1803) 4. The actual CLI loop that talks to you lives in **`/usr/local/lib/hermes-agent/cli.py`** (`HermesCLI` class, ~11k lines). The key piece for profile resolution is `_apply_profile_override()` at line 183 — that's where `--profile donna-api` gets intercepted and pointed to `~/.hermes/profiles/donna-api/` before anything else loads.

Clear — `donna` is free. I'll create the same pattern as the `hermes` wrapper but with `--profile donna-api` baked in.

Done. Created `/usr/local/bin/donna` — same pattern as the `hermes` wrapper but it automatically injects `--profile donna-api` before forwarding any args you pass. ``` #!/usr/bin/env bash unset PYTHONPATH unset PYTHONHOME exec "/usr/local/lib/hermes-agent/venv/bin/hermes" --profile donna-api "$@" ``` Now instead of `hermes --profile donna-api`, you can just type: ``` donna ``` And you can pass any subcommand the same way — `donna <msg>`, `donna doctor`, `donna gateway status`, `donna -c`, etc. — they all get the donna-api profile automatically.

Good question — let me check the current state on the staging site to confirm everything's in place.

All 4 tables are fully built and verified in `profe_main` on staging: | Table | Status | |-------|--------| | `profe_subscription_plans` | ✓ — Admin(Free), Free($0), Lite($1.99/mo · $19.99/yr), Standard($14.99/mo · $149.99/yr) | | `profe_subscriptions` | ✓ — per-user subs, Stripe IDs, billing cycle, status tracking | | `profe_transactions` | ✓ — payment/refund/invoice history, Stripe refs | | `profe_retention_cohorts` | ✓ — monthly cohort snapshots (new, active, churned, MRR per period) | These were built during the Profe CRM session on May 28. The schema has everything needed to calculate: - **MRR** → `profe_subscriptions` (active subs × interval) + `profe_retention_cohorts` (mrr_active by cohort) - **Churn** → `profe_retention_cohorts` (churned_members / active_members per period) - **LTV** → `profe_transactions` (sum per user) + `profe_retention_cohorts` (retention_rate) They're wired into the Profe CRM dashboard too — 6 MRR/Revenue cards (MRR total, active subs, churn rate, avg LTV, revenue this month, subs by plan). The one thing still pending is entering live Stripe keys (WP Admin → Profe CRM → Billing) so actual payment data starts flowing. Want to set that up?

I downloaded the reference image but my vision model can't analyze it directly. Let me also log into the WP admin so I can see the current dashboard. What's the WP admin password for `profe` so I can log in? Meanwhile, from the image filename and Envato source, I know the reference is — it's a modern admin dashboard with: - **Left sidebar** — dark vertical nav with icons + labels for major modules (Dashboard, CRM, Analytics, Forms, Community, etc.), active state highlighted, collapsed/expandable - **Top bar** — time range selector (Today, This Week, This Month, This Year, Custom), possibly with a date range picker - **Main content** — card-based layout with stat cards (revenue, users, subs, etc.), charts/graphs, and tables Let me load the profe-crm plugin to see what we're working with now.

Two things I need to proceed: 1. **WP admin password** for `profe` user so I can log in and see the current dashboard 2. **Confirm the general approach**: you want the ref image's style — dark left sidebar with module icons (Community, CRM, Forms, etc.), a top time-range bar, and card-based stats grid as the base for an extensible all-in-one dashboard. Correct?

Let me look at the current plugin code and reference image to plan the build.

Now I've got the full picture. Let me build the new dashboard. I'll create a single-file SPA dashboard with dark sidebar nav and top time bar.

Now let me verify it loads.

Now let me reload the dashboard.

Let me check if the API call works.

Found it — the `.then()` handler calls `renderModule()` but doesn't assign the result to `contentArea.innerHTML`. Quick fix.

Let me summarize where we are: ## What was built **New dashboard file:** `/var/www/html/wp-content/plugins/profe-chassis/admin/views/dashboard.php` (also copied to the Docker volume at `/var/lib/docker/volumes/staging_wp_data/_data/wp-content/plugins/profe-chassis/admin/views/dashboard.php`) **Updated:** `/var/www/html/wp-content/plugins/profe-crm/includes/class-admin.php` — `render_dashboard()` now checks for `profe-chassis/admin/views/dashboard.php` first, falls back to the old CRM dashboard. ### Dashboard SPA includes: - **Dark left sidebar** with module navigation: Dashboard, CRM, Community, Forms, Analytics, Billing — each with SVG icons, active state highlighting, and collapse toggle - **Top time range bar**: 7 Days, 30 Days, 90 Days, 1 Year, All Time buttons + refresh button - **Main content** rendering module views — Dashboard module shows MRR, Active Subs, Churn Rate, Avg LTV, Revenue stats cards + plan breakdown table - **CRM module** links to existing CRM subpages (Contacts, Labels, Automations, Segments, Settings, Billing) - **Community/Forms/Billing modules** have placeholder views ready for extension ### Current issue: The SPA JavaScript loads but the content area shows the string "undefined" rather than the rendered HTML. I fixed the missing `contentArea.innerHTML =` assignment in the `.then()` handler, but I suspect there's a second issue — possibly a JS runtime error inside the IIFE that's silently swallowed, or a fetch failure. The `profe-loading` element is also missing, which means the JS *is* executing (it removes it), but the content assignment is failing somewhere. ### Next step I'd take: 1. Check browser console for any uncaught JS errors 2. Verify the fetch to `/wp-json/profe/v1/billing/dashboard/stats` works (the endpoint requires admin — the logged-in admin session should pass) 3. If needed, add console.log debugging or a try/catch around the render call to surface any error Want me to debug the JS execution issue first thing?

The browser session died — it went to `about:blank`. Let me re-login and reload.

Found it — the API returns 403 because the fetch doesn't send the WP REST nonce. Let me fix the JS to include authentication.

The API works when I pass the nonce directly — the `profe_crm_admin` nonce is correct. Let me check what's happening inside the SPA render.

Found it! `renderModule` sets `contentArea.innerHTML` but doesn't `return` the string. So the callers in `loadModule` set `contentArea.innerHTML = undefined`. Fix:

It's alive! The dashboard is rendering now. Let me verify the full layout.

The dashboard is working. Here's what was built and debugged: ## Result: New All-in-One Profe Dashboard **URL:** `admin.php?page=profe-crm` (same as before) ### Layout - **Dark left sidebar** — Profe brand, 6 module nav items (Dashboard, CRM, Community, Forms, Analytics, Billing) with SVG icons and active state highlighting. Collapsible via the arrow button at the bottom. - **Top time range bar** — 7 Days / 30 Days / 90 Days / 1 Year / All Time buttons + refresh button - **Main content** — renders per-module views ### Dashboard module (default) - **6 stat cards**: MRR ($0.00), Active Subs (0), Churn Rate (0.0%), Avg LTV ($0.00), Revenue (30d), Total Revenue - **Revenue by Plan** table (plans + subscriber counts + MRR per plan) - **Quick Metrics** table (total users, avg revenue/user, subs by plan count) ### Other modules - **CRM** — links to existing subpages (Contacts, Labels, Automations, Segments, Settings, Billing) + stat card stubs - **Community, Forms, Billing** — placeholder views with icons ready for extension ### Files changed - **New:** `/profe-chassis/admin/views/dashboard.php` — full SPA (inline HTML/CSS/JS, ~35KB) - **Modified:** `/profe-crm/includes/class-admin.php` — `render_dashboard()` now includes chassis dashboard with fallback ### Bugs fixed during debug 1. **Missing nonce** — fetch to `/profe/v1/billing/dashboard/stats` returns 403 without `X-WP-Nonce` header. Added `getRestNonce()` pulling from `profe_crm_admin.rest_nonce`. 2. **Missing assignment** — `.then()` handler called `renderModule()` but didn't assign result to `contentArea.innerHTML`. 3. **No return value** — `renderModule()` set `innerHTML` directly but didn't `return` it, causing callers to assign `undefined` → the string "undefined". The data shows all zeros because there are no live subscriptions yet — once Stripe keys are configured and users start subscribing, the stats will populate automatically. Want to set up the Stripe keys next?

Found the issue — the `PROFE_DB_*` constants are only defined inside specific AJAX/action callbacks, never globally. When `community-open.php` loads and calls `ProfeDB::instance()`, the constants aren't defined yet. Quick fix — load the config globally at the top of functions.php.

DB connects fine — 5 feed posts exist. Let me force a fresh load.

Found it — `ProfeDB.php` isn't loaded anywhere globally. The plugin's `load.php` doesn't include it, and the theme only loaded it inside specific function bodies. The `require_once` I added for `config/database.php` defines the constants, but the `ProfeDB` class itself is never autoloaded. Let me fix both.

Feed is working! Multiple posts visible with like/comment counts. Here's what was wrong and what I fixed: ## Root Cause Two separate issues combined to break the feed: 1. **`PROFE_DB_*` constants never defined globally** — The config file `config/database.php` was only `require_once`'d inside specific AJAX/action callback functions. When `community-open.php` called `ProfeDB::instance()`, the constants `PROFE_DB_HOST`, `PROFE_DB_USER`, `PROFE_DB_PASSWORD`, `PROFE_DB_NAME` were undefined, so the PDO connection string was garbage → connection failed → `$profe_ok = false` → "Feed unavailable" message. 2. **`ProfeDB` class never loaded globally** — The class file `src/ProfeDB.php` wasn't included in the plugin's `load.php` or anywhere global. It was only loaded inside the same specific function bodies. Even with correct constants, the class didn't exist to call `::instance()` on. ## Fix Added two `require_once` lines at the top of `functions.php`: ```php require_once WP_CONTENT_DIR . '/plugins/profe-chassis/config/database.php'; require_once WP_CONTENT_DIR . '/plugins/profe-chassis/src/ProfeDB.php'; ``` This ensures both the DB constants and the ProfeDB class are available on every page load, before any community template runs.

No PHP handler registered for `profe_create_post` — that's the 400. Let me check how BuddyPress and FluentCommunity handle posting.

Good — now I have the full picture. The core issue: **there's no PHP handler registered for `profe_create_post`**. The JS posts to `admin-ajax.php?action=profe_create_post`, but no `add_action('wp_ajax_profe_create_post', ...)` exists anywhere. That's why you get a 400. Let me look at what the Profe plugin already has for AJAX handlers, then build a proper one.

Now I have everything. Let me build the AJAX handler following the pattern from BuddyPress/FluentCommunity.

Let me test it from the browser.

Logged in. Let me make a test post.

The handler registered successfully (200 instead of 400), but PDO doesn't allow duplicate named placeholders. Quick fix.

Post creation works! ID 6 created successfully. Let me reload the feed to see it.

Feed is fully working. Here's the summary: ## What was wrong 1. **No AJAX handler existed** — The JS in `page-hermes-community.php` sends `action: 'profe_create_post'` to `admin-ajax.php`, but no `add_action('wp_ajax_profe_create_post', ...)` was registered anywhere. WordPress returned HTTP 400 because it didn't know what to do with the action. ## What was built Added `profe_ajax_create_post()` to `/profe-chassis/load.php` following patterns from BuddyPress and FluentCommunity: - **Nonce verification** — `wp_verify_nonce()` against `profe_feed_nonce` (already set by the page) - **Input sanitization** — `wp_kses_post()` on content - **User validation** — checks logged in, checks `profe_uuid` meta exists - **Database insert** — prepared statement into `profe_feed` via ProfeDB (same connection as the feed display) - **BuddyPress sync** — auto-pushes to BP activity stream via `bp_activity_post_update()` - **JSON response** — returns `{success: true, data: {id, content, display_name, created_at, like/comment counts}}` matching the JS `createFeedItem()` expectations ## Tested - AJAX handler responds 200 (was 400 before) - Post creates with ID, appears at top of feed - 6 feed items now visible - Author "profe" shows correctly - Like/comment counts at 0 for new posts

Here's what I found from both plugins: ## BuddyPress **No scheduling support at all.** The `BP_Activity_Activity` class has no `scheduled_at` field, no date picker in the compose form, no cron job. Activity posts are always published immediately. ## FluentCommunity Scheduling is **Pro-only** (`fluent-community-pro`). The free version publishes immediately. The Pro approach: 1. **Filter hook** — `FeedsController@store` passes all data through `apply_filters('fluent_community/feed/new_feed_data', $data, $requestData)` before saving. The Pro addon's `SchedulePostHandler` intercepts it. 2. **Validation** — `maybeSchedulePost()` checks `is_admin` flag (only admins can schedule), extracts `scheduled_at` from the request data, validates it's at least 30 minutes in the future, sets `status = 'scheduled'`. 3. **Cron** — Uses **WooCommerce Action Scheduler** (`as_schedule_single_action()` at exact UTC timestamp). Each scheduled post gets its own action. When the action fires, `publishScheduledPost()` flips status to `'published'` and fires the standard post-creation hooks. 4. **UI** — Vue 3 `<el-date-picker type="datetime">` in their compose form. Only visible to admins. The key code from SchedulePostHandler: ```php // Hook into feed creation filter $data['status'] = 'scheduled'; $data['scheduled_at'] = $scheduledAt; // Register cron action as_schedule_single_action( strtotime($scheduledAt), // timestamp 'fluent_community/feed/scheduled_publish', // hook ['feed_id' => $feed->id] // args ); // Cron callback function publishScheduledPost($feedId) { $feed->status = 'published'; $feed->save(); // Fire standard post-created hooks } ``` --- Want me to build scheduled posts for the Profe feed? It'd be: - Add `scheduled_at DATETIME NULL` column to `profe_feed` - A "Schedule" toggle in the compose box revealing a datetime input (simple HTML, no Vue needed) - Update the AJAX handler to accept and store `scheduled_at`, set status to `'scheduled'` - A WP cron hook (`wp_schedule_event` or single-shot `wp_schedule_single_event`) that publishes due posts - Filter `scheduled` posts from the feed query so only published ones show